- 28 Feb, 2022 7 commits
-
-
Shannon Nelson authored
Make sure we don't try to transition the fw_status_ready while we're still in the FW_STOPPING state, else we can get stuck in limbo waiting on a transition that already happened. While we're here we can remove a superfluous check on the lif pointer. Signed-off-by:
Shannon Nelson <snelson@pensando.io> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Eric Dumazet authored
Both rps_sock_flow_sysctl() and flow_limit_cpu_sysctl() are using synchronize_rcu() right before freeing memory either by vfree() or kfree() They can switch to kvfree_rcu(ptr) and kfree_rcu(ptr) to benefit from asynchronous mode, instead of blocking the current thread. Note that kvfree_rcu(ptr) and kfree_rcu(ptr) eventually can have to use synchronize_rcu() in some memory pressure cases. Signed-off-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
Lorenzo Bianconi authored
Similar to mvneta or mvpp2, enable page_pool skb recycling for netsec dirver. Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by:
-
Tony Lu authored
This also calls trace_smc_tx_sendmsg() even if data is corked. For ease of understanding, if statements are not expanded here. Link: https://lore.kernel.org/all/f4166712-9a1e-51a0-409d-b7df25a66c52@linux.ibm.com/ Fixes: 139653bc ("net/smc: Remove corked dealyed work") Suggested-by:
Stefan Raspl <raspl@linux.ibm.com> Signed-off-by:
Tony Lu <tonylu@linux.alibaba.com> Signed-off-by:
-
David S. Miller authored
Jianbo Liu says: ==================== flow_offload: add tc police parameters As a preparation for more advanced police offload in mlx5 (e.g., jumping to another chain when bandwidth is not exceeded), extend the flow offload API with more tc-police parameters. Adjust existing drivers to reject unsupported configurations. Changes since v2: * Rename index to extval in exceed and notexceed acts. * Add policer validate functions for all drivers. Changes since v1: * Add one more strict validation for the control of drop/ok. ==================== Signed-off-by: -
Jianbo Liu authored
As more police parameters are passed to flow_offload, driver can check them to make sure hardware handles packets in the way indicated by tc. The conform-exceed control should be drop/pipe or drop/ok. Besides, for drop/ok, the police should be the last action. As hardware can't configure peakrate/avrate/overhead, offload should not be supported if any of them is configured. Signed-off-by:
Jianbo Liu <jianbol@nvidia.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Signed-off-by:
-
Jianbo Liu authored
The current police offload action entry is missing exceed/notexceed actions and parameters that can be configured by tc police action. Add the missing parameters as a pre-step for offloading police actions to hardware. Signed-off-by:
Roi Dayan <roid@nvidia.com> Reviewed-by:
-
- 27 Feb, 2022 20 commits
-
-
David S. Miller authored
Vladimir Oltean says: ==================== DSA FDB isolation There are use cases which need FDB isolation between standalone ports and bridged ports, as well as isolation between ports of different bridges. Most of these use cases are a result of the fact that packets can now be partially forwarded by the software bridge, so one port might need to send a packet to the CPU but its FDB lookup will see that it can forward it directly to a bridge port where that packet was autonomously learned. So the source port will attempt to shortcircuit the CPU and forward autonomously, which it can't due to the forwarding isolation we have in place. So we will have packet drops instead of proper operation. Additionally, before DSA can implement IFF_UNICAST_FLT for standalone ports, we must have control over which database we install FDB entries corresponding to port MAC addresses in. We don't want to hinder the operation of the bridging layer. DSA does not have a driver API that encourages FDB isolation, so this needs to be created. The basis for this is a new struct dsa_db which annotates each FDB and MDB entry with the database it belongs to. The sja1105 and felix drivers are modified to observe the dsa_db argument, and therefore, enforce the FDB isolation. Compared to the previous RFC patch series from August: https://patchwork.kernel.org/project/netdevbpf/cover/20210818120150.892647-1-vladimir.oltean@nxp.com/ what is different is that I stopped trying to make SWITCHDEV_FDB_{ADD,DEL}_TO_DEVICE blocking, instead I'm making use of the fact that DSA waits for switchdev FDB work items to finish before a port leaves the bridge. This is possible since: https://patchwork.kernel.org/project/netdevbpf/patch/20211024171757.3753288-7-vladimir.oltean@nxp.com/ Additionally, v2 is also rebased over the DSA LAG FDB work. ==================== Signed-off-by:
-
Vladimir Oltean authored
Currently ocelot uses a pvid of 0 for standalone ports and ports under a VLAN-unaware bridge, and the pvid of the bridge for ports under a VLAN-aware bridge. Standalone ports do not perform learning, but packets received on them are still subject to FDB lookups. So if the MAC DA that a standalone port receives has been also learned on a VLAN-unaware bridge port, ocelot will attempt to forward to that port, even though it can't, so it will drop packets. So there is a desire to avoid that, and isolate the FDBs of different bridges from one another, and from standalone ports. The ocelot switch library has two distinct entry points: the felix DSA driver and the ocelot switchdev driver. We need to code up a minimal bridge_num allocation in the ocelot switchdev driver too, this is copied from DSA with the exception that ocelot does not care about DSA trees, cross-chip bridging etc. So it only looks at its own ports that are already in the same bridge. The ocelot switchdev driver uses the bridge_num it has allocated itself, while the felix driver uses the bridge_num allocated by DSA. They are both stored inside ocelot_port->bridge_num by the common function ocelot_port_bridge_join() which receives the bridge_num passed by value. Once we have a bridge_num, we can only use it to enforce isolation between VLAN-unaware bridges. As far as I can see, ocelot does not have anything like a FID that further makes VLAN 100 from a port be different to VLAN 100 from another port with regard to FDB lookup. So we simply deny multiple VLAN-aware bridges. For VLAN-unaware bridges, we crop the 4000-4095 VLAN region and we allocate a VLAN for each bridge_num. This will be used as the pvid of each port that is under that VLAN-unaware bridge, for as long as that bridge is VLAN-unaware. VID 0 remains only for standalone ports. It is okay if all standalone ports use the same VID 0, since they perform no address learning, the FDB will contain no entry in VLAN 0, so the packets will always be flooded to the only possible destination, the CPU port. The CPU port module doesn't need to be member of the VLANs to receive packets, but if we use the DSA tag_8021q protocol, those packets are part of the data plane as far as ocelot is concerned, so there it needs to. Just ensure that the DSA tag_8021q CPU port is a member of all reserved VLANs when it is created, and is removed when it is deleted. Signed-off-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by:
-
Vladimir Oltean authored
For sja1105, to enforce FDB isolation simply means to turn on Independent VLAN Learning unconditionally, and to remap VLAN-unaware FDB and MDB entries towards the private VLAN allocated by tag_8021q for each bridge. Standalone ports each have their own standalone tag_8021q VLAN. No learning happens in that VLAN due to: - learning being disabled on standalone user ports - learning being disabled on the CPU port (we use assisted_learning_on_cpu_port which only installs bridge FDBs) VLAN-aware ports learn FDB entries with the bridge VLANs. VLAN-unaware bridge ports learn with the tag_8021q VLAN for bridging. Signed-off-by:
-
Vladimir Oltean authored
As FDB isolation cannot be enforced between VLAN-aware bridges in lack of hardware assistance like extra FID bits, it seems plausible that many DSA switches cannot do it. Therefore, they need to reject configurations with multiple VLAN-aware bridges from the two code paths that can transition towards that state: - joining a VLAN-aware bridge - toggling VLAN awareness on an existing bridge The .port_vlan_filtering method already propagates the netlink extack to the driver, let's propagate it from .port_bridge_join too, to make sure that the driver can use the same function for both. Signed-off-by:
-
Vladimir Oltean authored
For DSA, to encourage drivers to perform FDB isolation simply means to track which bridge does each FDB and MDB entry belong to. It then becomes the driver responsibility to use something that makes the FDB entry from one bridge not match the FDB lookup of ports from other bridges. The top-level functions where the bridge is determined are: - dsa_port_fdb_{add,del} - dsa_port_host_fdb_{add,del} - dsa_port_mdb_{add,del} - dsa_port_host_mdb_{add,del} aka the pre-crosschip-notifier functions. Changing the API to pass a reference to a bridge is not superfluous, and looking at the passed bridge argument is not the same as having the driver look at dsa_to_port(ds, port)->bridge from the ->port_fdb_add() method. DSA installs FDB and MDB entries on shared (CPU and DSA) ports as well, and those do not have any dp->bridge information to retrieve, because they are not in any bridge - they are merely the pipes that serve the user ports that are in one or multiple bridges. The struct dsa_bridge associated with each FDB/MDB entry is encapsulated in a larger "struct dsa_db" database. Although only databases associated to bridges are notified for now, this API will be the starting point for implementing IFF_UNICAST_FLT in DSA. There, the idea is to install FDB entries on the CPU port which belong to the corresponding user port's port database. These are supposed to match only when the port is standalone. It is better to introduce the API in its expected final form than to introduce it for bridges first, then to have to change drivers which may have made one or more assumptions. Drivers can use the provided bridge.num, but they can also use a different numbering scheme that is more convenient. DSA must perform refcounting on the CPU and DSA ports by also taking into account the bridge number. So if two bridges request the same local address, DSA must notify the driver twice, once for each bridge. In fact, if the driver supports FDB isolation, DSA must perform refcounting per bridge, but if the driver doesn't, DSA must refcount host addresses across all bridges, otherwise it would be telling the driver to delete an FDB entry for a bridge and the driver would delete it for all bridges. So introduce a bool fdb_isolation in drivers which would make all bridge databases passed to the cross-chip notifier have the same number (0). This makes dsa_mac_addr_find() -> dsa_db_equal() say that all bridge databases are the same database - which is essentially the legacy behavior. Signed-off-by: -
Vladimir Oltean authored
The dsa_8021q_bridge_tx_fwd_offload_vid is no longer used just for bridge TX forwarding offload, it is the private VLAN reserved for VLAN-unaware bridging in a way that is compatible with FDB isolation. So just rename it dsa_tag_8021q_bridge_vid. Signed-off-by:
-
Vladimir Oltean authored
In the old Shared VLAN Learning mode of operation that tag_8021q previously used for forwarding, we needed to have distinct concepts for an RX and a TX VLAN. An RX VLAN could be installed on all ports that were members of a given bridge, so that autonomous forwarding could still work, while a TX VLAN was dedicated for precise packet steering, so it just contained the CPU port and one egress port. Now that tag_8021q uses Independent VLAN Learning and imprecise RX/TX all over, those lines have been blurred and we no longer have the need to do precise TX towards a port that is in a bridge. As for standalone ports, it is fine to use the same VLAN ID for both RX and TX. This patch changes the tag_8021q format by shifting the VLAN range it reserves, and halving it. Previously, our DIR bits were encoding the VLAN direction (RX/TX) and were set to either 1 or 2. This meant that tag_8021q reserved 2K VLANs, or 50% of the available range. Change the DIR bits to a hardcoded value of 3 now, which makes tag_8021q reserve only 1K VLANs, and a different range now (the last 1K). This is done so that we leave the old format in place in case we need to return to it. In terms of code, the vid_is_dsa_8021q_rxvlan and vid_is_dsa_8021q_txvlan functions go away. Any vid_is_dsa_8021q is both a TX and an RX VLAN, and they are no longer distinct. For example, felix which did different things for different VLAN types, now needs to handle the RX and the TX logic for the same VLAN. Signed-off-by:
-
Vladimir Oltean authored
The felix driver, which also has a tagging protocol implementation based on tag_8021q, does not care about adding the RX VLAN that is pvid on one port on the other ports that are in the same bridge with it. It simply doesn't need that, because in its implementation, the RX VLAN that is pvid of a port is only used to install a TCAM rule that pushes that VLAN ID towards the CPU port. Now that tag_8021q no longer performs Shared VLAN Learning based forwarding, the RX VLANs are actually segregated into two types: standalone VLANs and VLAN-unaware bridging VLANs. Since you actually have to call dsa_tag_8021q_bridge_join() to get a bridging VLAN from tag_8021q, and felix does not do that because it doesn't need it, it means that it only gets standalone port VLANs from tag_8021q. Which is perfect because this means it can drop its workarounds that avoid the VLANs it does not need. Signed-off-by:
-
Vladimir Oltean authored
After change "net: dsa: tag_8021q: replace the SVL bridging with VLAN-unaware IVL bridging", tag_8021q enforces two different pvids on a port, depending on whether it is standalone or in a VLAN-unaware bridge. Up until now, there was a single pvid, represented by dsa_tag_8021q_rx_vid(), and that was used as the VLAN for VLAN-unaware virtual link rules, regardless of whether the port was bridged or standalone. To keep VLAN-unaware virtual links working, we need to follow whether the port is in a bridge or not, and update the VLAN ID from those rules. In fact we can't fully do that. Depending on whether the switch is VLAN-aware or not, we can accept Virtual Link rules with just the MAC DA, or with a MAC DA and a VID. So we already deny changes to the VLAN awareness of the switch. But the VLAN awareness may also change as a result of joining or leaving a bridge. One might say we could just allow the following: a port may leave a VLAN-unaware bridge while it has VLAN-unaware VL (tc-flower) rules, and the driver will update those with the new tag_8021q pvid for standalone mode, but the driver won't accept joining a bridge at all while VL rules were installed in standalone mode. This is sort of a compromise made because leaving a bridge is an operation that cannot be vetoed. But this sort of setup change is not fully supported, either: as mentioned, VLAN filtering changes can also be triggered by leaving a bridge, therefore, the existing veto we have in place for turning VLAN filtering off with VLAN-aware VL rules active still isn't fully effective. I really don't know how to deal with this in a way that produces predictable behavior for user space. Since at the moment, keeping this feature fully functional on constellation changes (not changing the tag_8021q port pvid when joining a bridge) is blocking progress for the DSA FDB isolation, I'd rather document it as a (potentially temporary) limitation and go on without it. Signed-off-by:
-
Vladimir Oltean authored
The sja1105 switch can't populate the PORT field of the tag_8021q header when sending a frame to the CPU with a non-zero VBID. Similar to dsa_find_designated_bridge_port_by_vid() which performs imprecise RX for VLAN-aware bridges, let's introduce a helper in tag_8021q for performing imprecise RX based on the VLAN that it has allocated for a VLAN-unaware bridge. Signed-off-by:
-
Vladimir Oltean authored
For VLAN-unaware bridging, tag_8021q uses something perhaps a bit too tied with the sja1105 switch: each port uses the same pvid which is also used for standalone operation (a unique one from which the source port and device ID can be retrieved when packets from that port are forwarded to the CPU). Since each port has a unique pvid when performing autonomous forwarding, the switch must be configured for Shared VLAN Learning (SVL) such that the VLAN ID itself is ignored when performing FDB lookups. Without SVL, packets would always be flooded, since FDB lookup in the source port's VLAN would never find any entry. First of all, to make tag_8021q more palatable to switches which might not support Shared VLAN Learning, let's just use a common VLAN for all ports that are under the same bridge. Secondly, using Shared VLAN Learning means that FDB isolation can never be enforced. But if all ports under the same VLAN-unaware bridge share the same VLAN ID, it can. The disadvantage is that the CPU port can no longer perform precise source port identification for these packets. But at least we have a mechanism which has proven to be adequate for that situation: imprecise RX (dsa_find_designated_bridge_port_by_vid), which is what we use for termination on VLAN-aware bridges. The VLAN ID that VLAN-unaware bridges will use with tag_8021q is the same one as we were previously using for imprecise TX (bridge TX forwarding offload). It is already allocated, it is just a matter of using it. Note that because now all ports under the same bridge share the same VLAN, the complexity of performing a tag_8021q bridge join decreases dramatically. We no longer have to install the RX VLAN of a newly joining port into the port membership of the existing bridge ports. The newly joining port just becomes a member of the VLAN corresponding to that bridge, and the other ports are already members of it from when they joined the bridge themselves. So forwarding works properly. This means that we can unhook dsa_tag_8021q_bridge_{join,leave} from the cross-chip notifier level dsa_switch_bridge_{join,leave}. We can put these calls directly into the sja1105 driver. With this new mode of operation, a port controlled by tag_8021q can have two pvids whereas before it could only have one. The pvid for standalone operation is different from the pvid used for VLAN-unaware bridging. This is done, again, so that FDB isolation can be enforced. Let tag_8021q manage this by deleting the standalone pvid when a port joins a bridge, and restoring it when it leaves it. Signed-off-by: -
David S. Miller authored
Dimitris Michailidis says: ==================== new Fungible Ethernet driver This patch series contains a new network driver for the Ethernet functionality of Fungible cards. It contains two modules. The first one in patch 2 is a library module that implements some of the device setup, queue managenent, and support for operating an admin queue. These are placed in a separate module because the cards provide a number of PCI functions handled by different types of drivers and all use the same common means to interact with the device. Each of the drivers will be relying on this library module for them. The remaining patches provide the Ethernet driver for the cards. v2: - Fix set_pauseparam, remove get_wol, remove module param (Andrew Lunn) - Fix a register poll loop (Andrew) - Replace constants defined with 'static const' - make W=1 C=1 is clean - Remove devlink FW update (Jakub) - Remove duplicate ethtool stats covered by structured API (Jakub) v3: - Make TLS stats unconditional (Andrew) - Remove inline from .c (Andrew) - Replace some ifdef with IS_ENABLED (Andrew) - Fix build failure on 32b arches (build robot) - Fix build issue with make O= (Jakub) v4: - Fix for newer bpf_warn_invalid_xdp_action() (Jakub) - Remove 32b dma_set_mask_and_coherent() v5: - Make XDP enter/exit non-disruptive to active traffic - Remove dormant port state - Style fixes, unused stuff removal (Jakub) v6: - When changing queue depth or numbers allocate the new queues before shutting down the existing ones (Jakub) v7: - Convert IRQ bookeeping to use XArray. - Changes to the numbers of Tx/Rx queues are now incremental and do not disrupt ongoing traffic. - Implement .ndo_eth_ioctl instead of .ndo_do_ioctl. - Replace deprecated irq_set_affinity_hint. - Remove TLS 1.3 support (Jakub) - Remove hwtstamp_config.flags check (Jakub) - Add locking in SR-IOV enable/disable. (Jakub) v8: - Remove dropping of <33B packets and the associated counter (Jakub) - Report CQE size. - Show last MAC stats when the netdev isn't running (Andrew) ==================== Signed-off-by: -
Dimitris Michailidis authored
Hook up the new driver to configuration and build. Signed-off-by:
Dimitris Michailidis <dmichail@fungible.com> Signed-off-by:
-
Dimitris Michailidis authored
This provides the control pieces for kTLS Tx offload, implementinng the offload operations. Signed-off-by:
-
Dimitris Michailidis authored
Add the driver's data path. Tx handles skbs, XDP, and kTLS, Rx has skbs and XDP. Also included are Rx and Tx queue creation/tear-down and tracing. Signed-off-by:
-
Dimitris Michailidis authored
The devlink part, which is minimal at this time giving just the driver name. Signed-off-by:
-
Dimitris Michailidis authored
Add ethtool operations, primarily related to queues and ports, as well as device statistics. Signed-off-by:
-
Dimitris Michailidis authored
This is the first part of the Fungible ethernet driver. It deals with device probing, net_device creation, and netdev ops. Signed-off-by:
-
Dimitris Michailidis authored
Fungible cards have a number of different PCI functions and thus different drivers, all of which use a common method to initialize and interact with the device. This commit adds a library module that collects these common mechanisms. They mainly deal with device initialization, setting up and destroying queues, and operating an admin queue. A subset of the FW interface is also included here. Signed-off-by:
-
Dimitris Michailidis authored
Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: linux-pci@vger.kernel.org Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
- 26 Feb, 2022 13 commits
-
-
David S. Miller authored
Menglong Dong says: ==================== net: use kfree_skb_reason() for ip/neighbour In the series "net: use kfree_skb_reason() for ip/udp packet receive", reasons for skb drops are added to the packet receive process of IP layer. Link: https://lore.kernel.org/netdev/20220205074739.543606-1-imagedong@tencent.com/ And in the first patch of this series, skb drop reasons are added to the packet egress path of IP layer. As kfree_skb() is not used frequent, I commit these changes at once and didn't create a patch for every functions that involed. Following functions are handled: __ip_queue_xmit() ip_finish_output() ip_mc_finish_output() ip6_output() ip6_finish_output() ip6_finish_output2() Following new drop reasons are introduced (what they mean can be seen in the document of them): SKB_DROP_REASON_IP_OUTNOROUTES SKB_DROP_REASON_BPF_CGROUP_EGRESS SKB_DROP_REASON_IPV6DISABLED SKB_DROP_REASON_NEIGH_CREATEFAIL In the 2th and 3th patches, kfree_skb_reason() is used in neighbour subsystem instead of kfree_skb(). __neigh_event_send() and arp_error_report() are involed, and following new drop reasons are introduced: SKB_DROP_REASON_NEIGH_FAILED SKB_DROP_REASON_NEIGH_QUEUEFULL SKB_DROP_REASON_NEIGH_DEAD Changes since v2: - fix typo in the 1th patch of 'SKB_DROP_REASON_IPV6DSIABLED' reported by Roman Changes since v1: - introduce SKB_DROP_REASON_NEIGH_CREATEFAIL for some path in the 1th patch - introduce SKB_DROP_REASON_NEIGH_DEAD in the 2th patch - simplify the document for the new drop reasons, as David Ahern suggested ==================== Signed-off-by:
-
Menglong Dong authored
When neighbour become invalid or destroyed, neigh_invalidate() will be called. neigh->ops->error_report() will be called if the neighbour's state is NUD_FAILED, and seems here is the only use of error_report(). So we can tell that the reason of skb drops in arp_error_report() is SKB_DROP_REASON_NEIGH_FAILED. Replace kfree_skb() used in arp_error_report() with kfree_skb_reason(). Reviewed-by:
Mengen Sun <mengensun@tencent.com> Reviewed-by:
Hao Peng <flyingpeng@tencent.com> Signed-off-by:
Menglong Dong <imagedong@tencent.com> Reviewed-by:
David Ahern <dsahern@kernel.org> Signed-off-by:
-
Menglong Dong authored
Replace kfree_skb() used in __neigh_event_send() with kfree_skb_reason(). Following drop reasons are added: SKB_DROP_REASON_NEIGH_FAILED SKB_DROP_REASON_NEIGH_QUEUEFULL SKB_DROP_REASON_NEIGH_DEAD The first two reasons above should be the hot path that skb drops in neighbour subsystem. Reviewed-by:
-
Menglong Dong authored
Replace kfree_skb() which is used in the packet egress path of IP layer with kfree_skb_reason(). Functions that are involved include: __ip_queue_xmit() ip_finish_output() ip_mc_finish_output() ip6_output() ip6_finish_output() ip6_finish_output2() Following new drop reasons are introduced: SKB_DROP_REASON_IP_OUTNOROUTES SKB_DROP_REASON_BPF_CGROUP_EGRESS SKB_DROP_REASON_IPV6DISABLED SKB_DROP_REASON_NEIGH_CREATEFAIL Reviewed-by:
-
David S. Miller authored
Russell King says: ==================== net: dsa: ocelot: phylink updates This series updates the Ocelot DSA driver for some of the recent phylink changes. Specifically, we fill in the supported_interfaces fields, convert to mac_select_pcs and mark the driver as non-legacy. We do not convert to phylink_generic_validate() as Ocelot has special support for its rate adapting PCS which makes the generic validate method unsuitable for this driver. The three changes mentioned above are implemented in their own separate patches with one additional cleanup: 1) Populate the supported_interfaces bitmap 2) Remove the now unnecessary interface checks in the validate methods 3) Convert from phylink_set_pcs() to .mac_select_pcs. 4) Mark the driver as non-legacy Thanks. RFC -> non-RFC: add reviewed-by/tested-by's, update patch 1 to set the supported_interfaces bitmap in felix.c rather than the sub-drivers as requested by Vladimir. ==================== Signed-off-by: -
Russell King (Oracle) authored
The ocelot DSA driver does not make use of the speed, duplex, pause or advertisement in its phylink_mac_config() implementation, so it can be marked as a non-legacy driver. Reviewed-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King (Oracle) authored
Convert the PCS selection to use mac_select_pcs, which allows the PCS to perform any validation it needs, and removes the need to set the PCS in the mac_config() callback, delving into the higher DSA levels to do so. Reviewed-by:
-
Russell King (Oracle) authored
When the supported interfaces bitmap is populated, phylink will itself check that the interface mode is present in this bitmap. Drivers no longer need to perform this check themselves. Remove these checks. Reviewed-by:
-
Russell King (Oracle) authored
Populate the supported interfaces bitmap for the Ocelot DSA switches. Since all sub-drivers only support a single interface mode, defined by ocelot_port->phy_mode, we can handle this in the main driver code without reference to the sub-driver. Signed-off-by:
-
Jakub Kicinski authored
Matt Johnston says: ==================== Small fixes for MCTP This series has 3 fixes for MCTP. ==================== Link: https://lore.kernel.org/r/20220225053938.643605-1-matt@codeconstruct.com.auSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Matt Johnston authored
We should be testing the length before fitting into the u8 byte_count. This is just a sanity check, the MCTP stack should have limited to MTU which is checked, and we check consistency later in mctp_i2c_xmit(). Found by Smatch mctp_i2c_header_create() warn: impossible condition '(hdr->byte_count > 255) => (0-255 > 255)' Signed-off-by:Matt Johnston <matt@codeconstruct.com.au> Signed-off-by:
-
Matt Johnston authored
The skb is handed off to netif_rx() which may free it. Found by Smatch. Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Matt Johnston authored
Previously if an unregister notify handler ran twice (waiting for netdev to be released) it would print a warning in mctp_unregister() every subsequent time the unregister notify occured. Instead we only need to worry about the case where a mctp_ptr is set on an unknown device type. Signed-off-by:
-
