- 07 Sep, 2020 30 commits
-
-
Jakub Kicinski authored
Edward Cree says: ==================== sfc: ethtool for EF100 and related improvements This series adds the ethtool support to the EF100 driver that was held back from the original submission as the lack of phy_ops caused issues. Patch #2, removing the phy_op indirection, deals with this. There are a lot of checkpatch warnings / xmastree violations but they're all in pure code movement so I've left the code as it is. While patch #1 is technically a fix and possibly could go to 'net', I've put it in this series since it only becomes triggerable with the added 'ethtool --reset' support. ==================== Signed-off-by:Jakub Kicinski <kuba@kernel.org>
-
Edward Cree authored
Christoph says[1] that dma_set_mask_and_coherent() is smart enough to truncate the mask itself if it's too long. So we can get rid of our "lop off one bit and retry" loop in efx_init_io(). [1]: https://www.spinics.net/lists/netdev/msg677266.htmlSigned-off-by:
Edward Cree <ecree@solarflare.com> Signed-off-by:
-
Edward Cree authored
Per-module versions for in-tree drivers are deprecated. Signed-off-by:
-
Edward Cree authored
If the reported PHY capabilities do not include a given FEC mode, don't attempt to select that FEC mode anyway. If the user tries to set a mode through ethtool that is not supported, return an error. The _REQUESTED bits don't appear in the supported caps, but are implied by the corresponding FEC bits. Signed-off-by:
-
Edward Cree authored
Mostly just calls to existing common functions. Signed-off-by:
-
Edward Cree authored
Originally there were several implementations of PHY operations for the several different PHYs used on Falcon boards. But Falcon is now in a separate driver, and all sfc NICs since then have had MCDI-managed PHYs. Thus, there is no need to indirect through function pointers in efx->phy_op; we can simply call the efx_mcdi_phy_* functions directly. This also hooks up these functions for EF100, which was previously using the dummy_phy_ops. Signed-off-by:
-
Edward Cree authored
dev_close(), by way of ef100_net_stop(), already brings down the filter table, so there's no need to do it again (which just causes lots of WARN_ONs). Similarly, don't bring it up ourselves, as dev_open() -> ef100_net_open() will do it, and will fail if it's already been brought up. Fixes: a9dc3d56 ("sfc_ef100: RX filter table management and related gubbins") Signed-off-by:
-
Wang Hai authored
Fixes gcc '-Wunused-but-set-variable' warning: drivers/net/ethernet/dnet.c: In function dnet_start_xmit drivers/net/ethernet/dnet.c:511:15: warning: variable ‘len’ set but not used [-Wunused-but-set-variable] commit 47964174 ("dnet: Dave DNET ethernet controller driver (updated)") involved this unused variable, remove it. Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Wang Hai <wanghai38@huawei.com> Signed-off-by:
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by:
Zhang Changzhong <zhangchangzhong@huawei.com> Signed-off-by:
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by:
Fugang Duan <fugang.duan@nxp.com> Signed-off-by:
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by:
-
Zhang Changzhong authored
Because clk_prepare_enable() and clk_disable_unprepare() already checked NULL clock parameter, so the additional checks are unnecessary, just remove them. Reported-by:
Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Signed-off-by:
-
Jakub Kicinski authored
Nikolay Aleksandrov says: ==================== net: bridge: mcast: initial IGMPv3/MLDv2 support (part 1) This patch-set implements the control plane for initial IGMPv3/MLDv2 support which takes care of include/exclude sets and state transitions based on the different report types. Patch 01 arranges the structure better by moving the frequently used fields together, patch 02 factors out the port group deletion code which is used in a few places. Patches 03 and 04 add support for source lists and group modes per port group which are dumped. Patch 05 adds support for group-and-source specific queries required for IGMPv3/MLDv2. Then patch 06 adds support for group and group-and-source query retransmissions via a new rexmit timer. Patches 07 and 08 make use of the already present mdb fill functions when sending notifications so we can have the full mdb entries' state filled in (with sources, mode etc). Patch 09 takes care of port group expiration, it switches the group mode to include and deletes it if there are no sources with active timers. Patches 10-13 are the core changes which add support for IGMPv3/MLDv2 reports and handle the source list set operations as per RFCs 3376 and 3810, all IGMPv3/MLDv2 report types with their transitions should be supported after these patches. I've used RFCs 3376, 3810 and FRR as a reference implementation. The source lists are capped at 32 entries, we can remove that limitation at a later point which would require a better data structure to hold them. IGMPv3 processing is hidden behind the bridge's multicast_igmp_version option which must be set to 3 in order to enable it. MLDv2 processing is hidden behind the bridge's multicast_mld_version which must be set to 2 in order to enable it. Patch 14 improves other querier processing a bit (more about this below). And finally patch 15 transforms the src gc so it can be used with all mcast objects since now we have multiple timers that can be running and we need to make sure they have all finished before freeing the objects. This is part 1, it only adds control plane support and doesn't change the fast path. A following patch-set will take care of that. Here're the sets that will come next (in order): - Fast path patch-set which adds support for (S, G) mdb entries needed for IGMPv3/MLDv2 forwarding, entry add source (kernel, user-space etc) needed for IGMPv3/MLDv2 entry management, entry block mode needed for IGMPv3/MLDv2 exclude mode. This set will also add iproute2 support for manipulating and showing all the new state. - Selftests patches which will verify all state transitions and forwarding - Explicit host tracking patch-set, needed for proper fast leave and with it fast leave will be enabled for IGMPv3/MLDv2 Not implemented yet: - Host IGMPv3/MLDv2 filter support (currently we handle only join/leave as before) - Proper other querier source timer and value updates - IGMPv3/v2 MLDv2/v1 compat (I have a few rough patches for this one) v4: move old patch 05 to 02 (group del patch), before src lists patch 02: set pg's fast leave flag when deleting due to fast leave patch 03: now can use the new port del function add igmpv2/mldv1 bool which are set when the entry is added in those modes (later will be passed as update_timer) patch 10: rename update_timer to igmpv2_mldv1 and use the passed value from br_multicast_add_group's callers v3: add IPv6/MLDv2 support, most patches are changed v2: patches 03-04: make src lists RCU friendly so they can be traversed when dumping, reduce limit to a more conservative 32 src group entries for a start patches 11-13: remove helper and directly do bitops patch 15: force mcast gc on bridge port del to make sure port group timers have finished before freeing the port ==================== Signed-off-by: -
Nikolay Aleksandrov authored
Since each entry type has timers that can be running simultaneously we need to make sure that entries are not freed before their timers have finished. In order to do that generalize the src gc work to mcast gc work and use a callback to free the entries (mdb, port group or src). v3: add IPv6 support v2: force mcast gc on port del to make sure all port group timers have finished before freeing the bridge port Signed-off-by:Nikolay Aleksandrov <nikolay@cumulusnetworks.com> Signed-off-by:
-
Nikolay Aleksandrov authored
When an IGMPv3/MLDv2 query is received and we're operating in such mode then we need to avoid updating group timers if the suppress flag is set. Also we should update only timers for groups in exclude mode. v3: add IPv6/MLDv2 support Signed-off-by:
-
Nikolay Aleksandrov authored
We already have all necessary helpers, so process IGMPV3/MLDv2 BLOCK_OLD_SOURCES as per the RFCs. v3: add IPv6/MLDv2 support v2: directly do flag bit operations Signed-off-by:
-
Nikolay Aleksandrov authored
In order to process IGMPV3/MLDv2 CHANGE_TO_INCLUDE/EXCLUDE report types we need new helpers which allow us to mark entries based on their timer state and to query only marked entries. v3: add IPv6/MLDv2 support, fix other_query checks v2: directly do flag bit operations Signed-off-by:
-
Nikolay Aleksandrov authored
In order to process IGMPV3/MLDv2_MODE_IS_INCLUDE/EXCLUDE report types we need some new helpers which allow us to set/clear flags for all current entries and later delete marked entries after the report sources have been processed. v3: add IPv6/MLDv2 support v2: drop flag helpers and directly do flag bit operations Signed-off-by:
-
Nikolay Aleksandrov authored
This patch adds handling for the ALLOW_NEW_SOURCES IGMPv3/MLDv2 report types and limits them only when multicast_igmp_version == 3 or multicast_mld_version == 2 respectively. Now that IGMPv3/MLDv2 handling functions will be managing timers we need to delay their activation, thus a new argument is added which controls if the timer should be updated. We also disable host IGMPv3/MLDv2 handling as it's not yet implemented and could cause inconsistent group state, the host can only join a group as EXCLUDE {} or leave it. v4: rename update_timer to igmpv2_mldv1 and use the passed value from br_multicast_add_group's callers v3: Add IPv6/MLDv2 support Signed-off-by: -
Nikolay Aleksandrov authored
If an expired port group is in EXCLUDE mode, then we have to turn it into INCLUDE mode, remove all srcs with zero timer and finally remove the group itself if there are no more srcs with an active timer. For IGMPv2 use there would be no sources, so this will reduce to just removing the group as before. Signed-off-by:
-
Nikolay Aleksandrov authored
We have to use mdb and port entries when sending mdb notifications in order to fill in all group attributes properly. Before this change we would've used a fake br_mdb_entry struct to fill in only partial information about the mdb. Now we can also reuse the mdb dump fill function and thus have only a single central place which fills the mdb attributes. v3: add IPv6 support Signed-off-by:
-
Nikolay Aleksandrov authored
This change is in preparation for using the mdb port group entries when sending a notification, so their full state and additional attributes can be filled in. Signed-off-by:
-
Nikolay Aleksandrov authored
We need to be able to retransmit group-specific and group-and-source specific queries. The new timer takes care of those. v3: add IPv6 support Signed-off-by:
-
Nikolay Aleksandrov authored
Allows br_multicast_alloc_query to build queries with the port group's source lists and sends a query for sources over and under lmqt when necessary as per RFCs 3376 and 3810 with the suppress flag set appropriately. v3: add IPv6 support Signed-off-by:
-
Nikolay Aleksandrov authored
Support per port group src list (address and timer) and filter mode dumping. Protected by either multicast_lock or rcu. v3: add IPv6 support v2: require RCU or multicast_lock to traverse src groups Signed-off-by:
-
Nikolay Aleksandrov authored
Initial functions for group source lists which are needed for IGMPv3 and MLDv2 include/exclude lists. Both IPv4 and IPv6 sources are supported. User-added mdb entries are created with exclude filter mode, we can extend that later to allow user-supplied mode. When group src entries are deleted, they're freed from a workqueue to make sure their timers are not still running. Source entries are protected by the multicast_lock and rcu. The number of src groups per port group is limited to 32. v4: use the new port group del function directly add igmpv2/mldv1 bool to denote if the entry was added in those modes, it will later replace the old update_timer bool v3: add IPv6 support v2: allow src groups to be traversed under rcu Signed-off-by: -
Nikolay Aleksandrov authored
In order to avoid future errors and reduce code duplication we should factor out the port group del sequence. This allows us to have one function which takes care of all details when removing a port group. v4: set pg's fast leave flag when deleting due to fast leave move the patch before adding source lists Signed-off-by: -
Nikolay Aleksandrov authored
Before this patch we'd need 2 cache lines for fast-path, now all used fields are in the first cache line. Signed-off-by:
-
Linus Walleij authored
This switches the RTL8366RB over to using phylink callbacks instead of .adjust_link(). This is a pretty template switchover. All we adjust is the CPU port so that is why the code only inspects this port. We enhance by adding proper error messages, also disabling the CPU port on the way down and moving dev_info() to dev_dbg(). Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Hoang Huu Le authored
In the commit fdeba99b ("tipc: fix use-after-free in tipc_bcast_get_mode"), we're trying to make sure the tipc_net_finalize_work work item finished if it enqueued. But calling flush_scheduled_work() is not just affecting above work item but either any scheduled work. This has turned out to be overkill and caused to deadlock as syzbot reported: ====================================================== WARNING: possible circular locking dependency detected 5.9.0-rc2-next-20200828-syzkaller #0 Not tainted ------------------------------------------------------ kworker/u4:6/349 is trying to acquire lock: ffff8880aa063d38 ((wq_completion)events){+.+.}-{0:0}, at: flush_workqueue+0xe1/0x13e0 kernel/workqueue.c:2777 but task is already holding lock: ffffffff8a879430 (pernet_ops_rwsem){++++}-{3:3}, at: cleanup_net+0x9b/0xb10 net/core/net_namespace.c:565 [...] Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pernet_ops_rwsem); lock(&sb->s_type->i_mutex_key#13); lock(pernet_ops_rwsem); lock((wq_completion)events); *** DEADLOCK *** [...] v1: To fix the original issue, we replace above calling by introducing a bit flag. When a namespace cleaned-up, bit flag is set to zero and: - tipc_net_finalize functionial just does return immediately. - tipc_net_finalize_work does not enqueue into the scheduled work queue. v2: Use cancel_work_sync() helper to make sure ONLY the tipc_net_finalize_work() stopped before releasing bcbase object. Reported-by: syzbot+d5aa7e0385f6a5d0f4fd@syzkaller.appspotmail.com Fixes: fdeba99b ("tipc: fix use-after-free in tipc_bcast_get_mode") Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
Hoang Huu Le <hoang.h.le@dektech.com.au> Signed-off-by:
-
- 06 Sep, 2020 5 commits
-
-
Christophe JAILLET authored
The wrappers in include/linux/pci-dma-compat.h should go away. The patch has been generated with the coccinelle script below and has been hand modified to replace GFP_ with a correct flag. It has been compile tested. When memory is allocated in 'vnic_dev_classifier()', 'vnic_dev_fw_info()', 'vnic_dev_notify_set()' and 'vnic_dev_stats_dump()' (vnic_dev.c) GFP_ATOMIC must be used because its callers take a spinlock before calling these functions. When memory is allocated in '__enic_set_rsskey()' and 'enic_set_rsscpu()' GFP_ATOMIC must be used because they can be called with a spinlock. The call chain is: enic_reset <-- takes 'enic->enic_api_lock' --> enic_set_rss_nic_cfg --> enic_set_rsskey --> __enic_set_rsskey <-- uses dma_alloc_coherent --> enic_set_rsscpu <-- uses dma_alloc_coherent When memory is allocated in 'vnic_dev_init_prov2()' GFP_ATOMIC must be used because a spinlock is hidden in the ENIC_DEVCMD_PROXY_BY_INDEX macro, when this function is called in 'enic_set_port_profile()'. When memory is allocated in 'vnic_dev_alloc_desc_ring()' GFP_KERNEL can be used because it is only called from 5 functions ('vnic_dev_init_devcmd2()', 'vnic_cq_alloc()', 'vnic_rq_alloc()', 'vnic_wq_alloc()' and 'enic_wq_devcmd2_alloc()'. 'vnic_dev_init_devcmd2()': already uses GFP_KERNEL and no lock is taken in the between. 'enic_wq_devcmd2_alloc()': is called from ' vnic_dev_init_devcmd2()' which already uses GFP_KERNEL and no lock is taken in the between. 'vnic_cq_alloc()', 'vnic_rq_alloc()', 'vnic_wq_alloc()': are called from 'enic_alloc_vnic_resources()' 'enic_alloc_vnic_resources()' has only 2 call chains: 1) enic_probe --> enic_dev_init --> enic_alloc_vnic_resources 'enic_probe()' is a probe function and no lock is taken in the between 2) enic_set_ringparam --> enic_alloc_vnic_resources 'enic_set_ringparam()' is a .set_ringparam function (see struct ethtool_ops). It seems to only take a mutex and no spinlock. So all paths are safe to use GFP_KERNEL. @@ @@ - PCI_DMA_BIDIRECTIONAL + DMA_BIDIRECTIONAL @@ @@ - PCI_DMA_TODEVICE + DMA_TO_DEVICE @@ @@ - PCI_DMA_FROMDEVICE + DMA_FROM_DEVICE @@ @@ - PCI_DMA_NONE + DMA_NONE @@ expression e1, e2, e3; @@ - pci_alloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3; @@ - pci_zalloc_consistent(e1, e2, e3) + dma_alloc_coherent(&e1->dev, e2, e3, GFP_) @@ expression e1, e2, e3, e4; @@ - pci_free_consistent(e1, e2, e3, e4) + dma_free_coherent(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_single(e1, e2, e3, e4) + dma_map_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_single(e1, e2, e3, e4) + dma_unmap_single(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4, e5; @@ - pci_map_page(e1, e2, e3, e4, e5) + dma_map_page(&e1->dev, e2, e3, e4, e5) @@ expression e1, e2, e3, e4; @@ - pci_unmap_page(e1, e2, e3, e4) + dma_unmap_page(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_map_sg(e1, e2, e3, e4) + dma_map_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_unmap_sg(e1, e2, e3, e4) + dma_unmap_sg(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_cpu(e1, e2, e3, e4) + dma_sync_single_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_single_for_device(e1, e2, e3, e4) + dma_sync_single_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_cpu(e1, e2, e3, e4) + dma_sync_sg_for_cpu(&e1->dev, e2, e3, e4) @@ expression e1, e2, e3, e4; @@ - pci_dma_sync_sg_for_device(e1, e2, e3, e4) + dma_sync_sg_for_device(&e1->dev, e2, e3, e4) @@ expression e1, e2; @@ - pci_dma_mapping_error(e1, e2) + dma_mapping_error(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_dma_mask(e1, e2) + dma_set_mask(&e1->dev, e2) @@ expression e1, e2; @@ - pci_set_consistent_dma_mask(e1, e2) + dma_set_coherent_mask(&e1->dev, e2) Signed-off-by:Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by:
-
Linus Walleij authored
It's nice if the phy is online before we register the netdev so try to do that first. Stop trying to do "second tried" to register the phy, it works perfectly fine the first time. Stop remvoving the phy in uninit. Remove it when the driver is remove():d, symmetric to where it is added, in probe(). Suggested-by:
Andrew Lunn <andrew@lunn.ch> Reviewed-by:
David Miller <davem@davemloft.net> Signed-off-by:
-
Jonathan Neuschäfer authored
Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
-
Linus Walleij authored
This implements the missing MTU setting for the RTL8366RB switch. Apart from supporting jumboframes, this rids us of annoying boot messages like this: realtek-smi switch: nonfatal error -95 setting MTU on port 0 Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Wang Hai authored
BLOCK_PRIV is never used after it was introduced. So better to remove it. Reported-by:
Willem de Bruijn <willemb@google.com> Signed-off-by:
-
- 05 Sep, 2020 5 commits
-
-
Wang Hai authored
DIGITAL_NFC_DEP_REQ_RES_TAILROOM is never used after it was introduced. DIGITAL_NFC_DEP_REQ_RES_HEADROOM is no more used after below commit e8e7f421 ("NFC: digital: Remove useless call to skb_reserve()") Remove them. Reported-by:
-
Wang Hai authored
Remove SRVL_CTRL_PKT_SIZE which is defined more than once. Reported-by:
-
Lukas Bulwahn authored
Commit 0da4c3d3 ("net: phy: add Lynx PCS module") added the files in ./drivers/net/pcs/, but the new LYNX PCS MODULE section refers to ./drivers/net/phy/. Hence, ./scripts/get_maintainer.pl --self-test=patterns complains: warning: no file matches F: drivers/net/phy/pcs-lynx.c Repair the LYNX PCS MODULE section by referring to the right location. Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by:
Ioana Ciornei <ioana.ciornei@nxp.com> Signed-off-by:
-
Jakub Kicinski authored
Florian Fainelli says: ==================== net: dsa: bcm_sf2: Ensure MDIO diversion is used Changes in v2: - export of_update_property() to permit building bcm_sf2 as a module - provided a better explanation of the problem being solved after explaining it to Andrew during the v1 review ==================== Signed-off-by: -
Florian Fainelli authored
Registering our slave MDIO bus outside of the OF infrastructure is necessary in order to avoid creating double references of the same Device Tree nodes, however it is not sufficient to guarantee that the MDIO bus diversion is used because of_phy_connect() will still resolve to a valid PHY phandle and it will connect to the PHY using its parent MDIO bus which is still the SF2 master MDIO bus. The reason for that is because BCM7445 systems were already shipped with a Device Tree blob looking like this (irrelevant parts omitted for simplicity): ports { #address-cells = <1>; #size-cells = <0>; port@1 { phy-mode = "rgmii-txid"; phy-handle = <&phy0>; reg = <1>; label = "rgmii_1"; }; ... mdio@403c0 { ... phy0: ethernet-phy@0 { broken-turn-around; device_type = "ethernet-phy"; max-speed = <0x3e8>; reg = <0>; compatible = "brcm,bcm53125", "ethernet-phy-ieee802.3-c22"; }; }; There is a hardware issue with chip revisions (Dx) that lead to the development of the following commits: 461cd1b0 ("net: dsa: bcm_sf2: Register our slave MDIO bus") 536fab5b ("net: dsa: bcm_sf2: Do not register slave MDIO bus with OF") b8c6cd1d ("net: dsa: bcm_sf2: do not use indirect reads and writes for 7445E0") There should have been an internal MDIO bus node created for the chip revision (Dx) that suffers from this problem, but it did not happen back then. Had that happen, that we should have correctly parented phy@0 (bcm53125 below) as child node of the internal MDIO bus, but the production Device Tree blob that was shipped with the firmware targeted the fixed version of the chip, despite both the affected and corrected chips being shipped into production. The problem is that of_phy_connect() for port@1 will happily resolve the 'phy-handle' from the mdio@403c0 node, which bypasses the diversion completely. This results in this double programming that the diversion refers to and aims to avoid. In order to force of_phy_connect() to fail, and have DSA call to dsa_slave_phy_connect(), we must deactivate ethernet-phy@0 from mdio@403c0, and the best way to do that is by removing the phandle property completely. Signed-off-by:
-
