- 27 Jul, 2023 8 commits
-
-
Ido Schimmel authored
Old firmware versions could only read up to 48 bytes from a transceiver module's EEPROM in one go. Newer versions can read up to 128 bytes, resulting in fewer transactions. Query support for the new capability during driver initialization and if supported, read up to 128 bytes in one go. This is going to be especially useful for upcoming transceiver module firmware flashing support. Before: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 3 devlink:devlink_hwmsg After: # perf stat -e devlink:devlink_hwmsg -- ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50 [...] Performance counter stats for 'ethtool -m swp11 page 0x1 offset 128 length 128 i2c 0x50': 1 devlink:devlink_hwmsg Signed-off-by:Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Ido Schimmel authored
The layout of the register always supported 128 bytes payloads, but the driver defined the register with a shorter length because it uses a maximum payload size of 48 bytes. Increase the register's length in preparation for using 128 bytes payloads. Signed-off-by:
-
Ido Schimmel authored
The 'lock' argument is always set to the default value of '0'. Remove it from the arguments list. Signed-off-by:
-
Amit Cohen authored
MCAM register reports the device supported management features. Querying this register exposes if features are supported with the current firmware version in the current ASIC. Then, the driver can separate between different implementations dynamically. MCAM register supports querying whether the MCIA register supports 128 bytes payloads or only 48 bytes. Add support for the register as preparation for allowing larger MCIA transactions. Note that the access to the bits in the field 'mng_feature_cap_mask' is not same to other mask fields in other registers. In most of the cases bit #0 is the first one in the last dword, in MCAM register, bits #0-#31 are in the first dword and so on. Declare the mask field using bits arrays per dword to simplify the access. Signed-off-by:
Amit Cohen <amcohen@nvidia.com> Signed-off-by:
-
Amit Cohen authored
The array 'mlxsw_reg_infos' is ordered by registers' IDs. The ID of MPSC register is 0x9080, so it should be after MCDA (register ID 0x9063) and not after MTUTC (register ID 0x9055). Note that the register's fields are defined in the correct place in the file, only the definition in 'mlxsw_reg_infos' is wrong. This issue was found while adding new register which supposed to be before mpsc. Signed-off-by:
-
Krzysztof Kozlowski authored
Each regulator node, which references common regulator.yaml schema, should disallow additional or unevaluated properties. Otherwise mistakes in properties will go unnoticed. Signed-off-by:
Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Acked-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230725123711.149230-1-krzysztof.kozlowski@linaro.orgSigned-off-by:
-
Geert Uytterhoeven authored
The Broadcom ASP 2.0 Ethernet controller is only present on Broadcom STB SoCs. Hence add a dependency on ARCH_BRCMSTB, to prevent asking the user about this driver when configuring a kernel without Broadcom ARM-based set-top box chipset support. Fixes: 490cb412 ("net: bcmasp: Add support for ASP2.0 Ethernet controller") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Acked-by:
Florian Fainelli <florian.fainelli@broadcom.com> Acked-by:
Justin Chen <justin.chen@broadcom.com> Link: https://lore.kernel.org/r/1e8b998aa8dcc6e38323e295ee2430b48245cc79.1690299794.git.geert+renesas@glider.beSigned-off-by:
-
Tristram Ha authored
Microchip LAN8740/LAN8742 PHYs support basic unicast, broadcast, and Magic Packet WoL. They have one pattern filter matching up to 128 bytes of frame data, which can be used to implement ARP or multicast WoL. ARP WoL matches any ARP frame with broadcast address. Multicast WoL matches any multicast frame. Signed-off-by:
Tristram Ha <Tristram.Ha@microchip.com> Reviewed-by:
-
- 26 Jul, 2023 6 commits
-
-
Peter Seiderer authored
Remove unused HAVE_HW_TIME_STAMP feature define (introduced by commit ac45f602 ("net: infrastructure for hardware time stamping"). Signed-off-by:
Peter Seiderer <ps.report@gmx.net> Reviewed-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queueJakub Kicinski authored
Tony Nguyen says: ==================== ice: switchdev bridge offload Wojciech Drewek says: Linux bridge provides ability to learn MAC addresses and vlans detected on bridge's ports. As a result of this, FDB (forward data base) entries are created and they can be offloaded to the HW. By adding VF's port representors to the bridge together with the uplink netdev, we can learn VF's and link partner's MAC addresses. This is achieved by slow/exception-path, where packets that do not match any filters (FDB entries in this case) are send to the bridge ports. Driver keeps track of the netdevs added to the bridge by listening for NETDEV_CHANGEUPPER event. We distinguish two types of bridge ports: uplink port and VF's representor port. Linux bridge always learns src MAC of the packet on rx path. With the current slow-path implementation, it means that we will learn VF's MAC on port repr (when the VF transmits the packet) and link partner's MAC on uplink (when we receive it on uplink from LAN). The driver is notified about learning of the MAC/VLAN by SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events. This is followed by creation of the HW filter. The direction of the filter is based on port type (uplink or VF repr). In case of the uplink, rule forwards the packets to the LAN (matching on link partner's MAC). When the notification is received on VF repr then the rule forwards the packets to the associated VF (matching on VF's MAC). This approach would not work on its own however. This is because if one of the directions is offloaded, then the bridge would not be able to learn the other one. If the egress rule is added (learned on uplink) then the response from the VF will be sent directly to the LAN. The packet will not got through slow-path, it would not be seen on VF's port repr. Because of that, the bridge would not learn VF's MAC. This is solved by introducing guard rule. It prevents forward rule from working until the opposite direction is offloaded. Aging is not fully supported yet, aging time is static for now. The follow up submissions will introduce counters that will allow us to keep track if the rule is actually being used or not. A few fixes/changes are needed for this feature to work with ice driver. These are introduced in first 5 patches. Reviewed-by:Vlad Buslov <vladbu@nvidia.com> * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue: ice: add tracepoints for the switchdev bridge ice: implement static version of ageing ice: implement bridge port vlan ice: Add VLAN FDB support in switchdev mode ice: Add guard rule when creating FDB in switchdev ice: Switchdev FDB events support ice: Implement basic eswitch bridge setup ice: Unset src prune on uplink VSI ice: Disable vlan pruning for uplink VSI ice: Don't tx before switchdev is fully configured ice: Prohibit rx mode change in switchdev mode ice: Skip adv rules removal upon switchdev release ==================== Link: https://lore.kernel.org/r/20230724161152.2177196-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Johannes Zink authored
The IEEE1588 Standard specifies that the timestamps of Packets must be captured when the PTP message timestamp point (leading edge of first octet after the start of frame delimiter) crosses the boundary between the node and the network. As the MAC latches the timestamp at an internal point, the captured timestamp must be corrected for the additional path latency, as described in the publicly available datasheet [1]. This patch only corrects for the MAC-Internal delay, which can be read out from the MAC_Ingress_Timestamp_Latency register, since the Phy framework currently does not support querying the Phy ingress and egress latency. The Closs Domain Crossing Circuits errors as indicated in [1] are already being accounted in the stmmac_get_tx_hwtstamp() function and are not corrected here. As the Latency varies for different link speeds and MII modes of operation, the correction value needs to be updated on each link state change. As the delay also causes a phase shift in the timestamp counter compared to the rest of the network, this correction will also reduce phase error when generating PPS outputs from the timestamp counter. [1] i.MX8MP Reference Manual, rev.1 Section 11.7.2.5.3 "Timestamp correction" Signed-off-by:
Johannes Zink <j.zink@pengutronix.de> Link: https://lore.kernel.org/r/20230719-stmmac_correct_mac_delay-v2-1-3366f38ee9a6@pengutronix.deSigned-off-by:
-
Russell King (Oracle) authored
mdiobus_is_registered_device() doesn't checking that "addr" was valid before dereferencing bus->mdio_map[]. Extract the code that checks this from mdiobus_get_phy(), and use it here as well. Signed-off-by:
Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Link: https://lore.kernel.org/r/E1qNxvu-00111m-1V@rmk-PC.armlinux.org.ukSigned-off-by:
-
Alexandra Winter authored
The last s390 machine that supported FDDI was z900 ('7th generation', released in 2000). The oldest machine generation currently supported by the Linux kernel is MARCH_Z10 (released 2008). If there is still a usecase for connecting a Linux on s390 instance to a LAN Channel Station (LCS), it can only do so via Ethernet. Randy Dunlap[1] found that LCS over FDDI has never worked, when FDDI was compiled as module. Instead of fixing that, remove the FDDI option from the lcs driver. While at it, make the CONFIG_LCS description a bit more helpful. References: [1] https://lore.kernel.org/netdev/20230621213742.8245-1-rdunlap@infradead.org/Signed-off-by:Alexandra Winter <wintera@linux.ibm.com> Acked-by:
Christian Borntraeger <borntraeger@linux.ibm.com> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Reviewed-by:
-
Zhengchao Shao authored
There are currently two paths that call remove_xps_queue(): 1. __netif_set_xps_queue -> remove_xps_queue 2. clean_xps_maps -> remove_xps_queue_cpu -> remove_xps_queue There is no need to check dev_maps in remove_xps_queue() because dev_maps has been checked on these two paths. Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Link: https://lore.kernel.org/r/20230724023735.2751602-1-shaozhengchao@huawei.comSigned-off-by:
-
- 25 Jul, 2023 11 commits
-
-
Paolo Abeni authored
Leon Romanovsky says: ==================== Support UDP encapsulation in packet offload mode As was raised by Ilia in this thread [1], the ESP over UDP feature is supported in packet offload mode. So comes this series, which adds relevant bits to the mlx5 driver and opens XFRM core code to accept such configuration. NAT-T is part of IKEv2 and strongswan uses it automatically [2]. [1] https://lore.kernel.org/all/20230718092405.4124345-1-quic_ilial@quicinc.com [2] https://wiki.strongswan.org/projects/1/wiki/NatTraversal ==================== Link: https://lore.kernel.org/r/cover.1689757619.git.leon@kernel.orgSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Leon Romanovsky authored
Since mlx5 supports UDP encapsulation in packet offload, change the XFRM core to allow users to configure it. Signed-off-by:
Leon Romanovsky <leonro@nvidia.com> Acked-by:
Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by:
-
Leon Romanovsky authored
Extend mlx5 IPsec packet offload to support UDP encapsulation of IPsec ESP packets. Signed-off-by:
-
Leon Romanovsky authored
Set relevant IPsec capability to indicate if flow steering supports UDP encapsulation and decapsulation of IPsec ESP packets. Signed-off-by:
-
Leon Romanovsky authored
Provide an ability to check if flow steering supports UDP encapsulation and decapsulation of IPsec ESP packets. Signed-off-by:
-
Paolo Abeni authored
Russell King says: ==================== Remove legacy phylink behaviour This series removes the - as far as I can tell - unreachable code in mtk_eth_soc that relies upon legacy phylink behaviour, and then removes the support in phylink for this legacy behaviour. Patch 1 removes the clocking configuration from mtk_eth_soc for non- TRGMII, non-serdes based interface modes, and disables those interface modes prior to phylink configuration. Patch 2 removes the mac_pcs_get_state() method from mtk_eth_soc which I believe is also not used - mtk_eth_soc appears not to be used with SFPs (which would use a kind of in-band mode) nor does any DT appear to specify in-band mode for any non-serdes based interface mode. With both of those dealt with, the kernel is now free of any driver relying on the phylink legacy mode. Therefore, patch 3 removes support for this. Finally, with the advent of a new driver being submitted today that makes use of state->speed in the mac_config() path, patch 4 ensures that any phylink_link_state member that should not be used in mac_config is either cleared or set to an invalid value. ==================== Link: https://lore.kernel.org/r/ZLw8DoRskRXLQK37@shell.armlinux.org.ukSigned-off-by:
-
Russell King (Oracle) authored
Explicitly invalidate the phylink_link_state structure members in mac_config that do not contain reliable information for this function, thereby preventing their future incorrect use. Reviewed-by:
Daniel Golle <daniel@makrotopia.org> Tested-by:
Frank Wunderlich <frank-w@public-files.de> Signed-off-by:
-
Russell King (Oracle) authored
Strip out all the pre-March 2020 legacy code from phylink now that the last user of it is gone. Reviewed-by:
-
Russell King (Oracle) authored
Remove the .mac_pcs_get_state function, since as far as I can tell is never called - no DT appears to specify an in-band-status management nor SFP support for this driver. Removal of this, along with the previous patch to remove the incorrect clocking configuration, means that the driver becomes non-legacy, so we can remove the "legacy_pre_march2020" status from this driver. Reviewed-by:
-
Russell King (Oracle) authored
MT7623 GMAC0 attempts to configure the system clocking according to the required speed in the .mac_config callback for non-SGMII, non-baseX and non-TRGMII modes. state->speed setting has never been reliable in the .mac_config callback - there are cases where this is not the link speed, particularly via ethtool paths, so this has always been unreliable (as detailed in phylink's documentation.) There is the additional issue that mtk_gmac0_rgmii_adjust() will only be called if state->interface changes, which means it only configures the system clocking on the very first .mac_config call, which will be made when the network device is first brought up before any link is established. Essentially, this code is incredibly buggy, and probably never worked. Moreover, checking the in-kernel DT files, it seems no platform makes use of this code path. Therefore, let's remove it, and disable interface modes for port 0 that are not SGMII, 1000base-X, 2500base-X or TRGMII on the MT7623. Reviewed-by:
-
Suman Ghosh authored
As of today, hardware does not support installing tc filter rules based on priority. This patch adds support to install the hardware rules based on priority. The final hardware rules will not be dependent on rule installation order, it will be strictly priority based, same as software. Signed-off-by:
Suman Ghosh <sumang@marvell.com> Reviewed-by:
-
- 24 Jul, 2023 15 commits
-
-
Paolo Abeni authored
The MPTCP code uses the assumption that the tcp_win_from_space() helper does not use any TCP-specific field, and thus works correctly operating on an MPTCP socket. The commit dfa2f048 ("tcp: get rid of sysctl_tcp_adv_win_scale") broke such assumption, and as a consequence most MPTCP connections stall on zero-window event due to auto-tuning changing the rcv buffer size quite randomly. Address the issue syncing again the MPTCP auto-tuning code with the TCP one. To achieve that, factor out the windows size logic in socket independent helpers, and reuse them in mptcp_rcv_space_adjust(). The MPTCP level scaling_ratio is selected as the minimum one from the all the subflows, as a worst-case estimate. Fixes: dfa2f048 ("tcp: get rid of sysctl_tcp_adv_win_scale") Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
Eric Dumazet <edumazet@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Link: https://lore.kernel.org/r/20230720-upstream-net-next-20230720-mptcp-fix-rcv-buffer-auto-tuning-v1-1-175ef12b8380@tessares.netSigned-off-by:
-
Breno Leitao authored
Replace kstrtoint() by kstrtobool() in the sysfs _store() functions. This improves the user usability and simplify the code. With this fix, it is now possible to use [YyNn] to set and unset a feature. Old behaviour is still unchanged. kstrtobool() is also safer and doesn't need the extra validation that is required when converting a string to bool (end field in the struct), which makes the code simpler. Suggested-by:
Petr Mladek <pmladek@suse.com> Signed-off-by:
Breno Leitao <leitao@debian.org> Reviewed-by:
-
Breno Leitao authored
According to the sysfs.rst documentation, _show() functions should only use sysfs_emit() instead of snprintf(). Since snprintf() shouldn't be used in the sysfs _show() path, replace it by sysfs_emit(). Suggested-by:
-
Maciej Fijalkowski authored
Cited commit under 'Fixes' tag introduced new member to struct net_device without providing description of it - fix it. Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/all/20230720141613.61488b9e@canb.auug.org.au/ Fixes: 13ce2daa ("xsk: add new netlink attribute dedicated for ZC max frags") Signed-off-by:
Maciej Fijalkowski <maciej.fijalkowski@intel.com> Reviewed-by:
-
Daniel Borkmann authored
On qdisc destruction, the ingress_destroy() needs to update the correct entry, that is, tcx_entry_update must NULL the dev->tcx_ingress pointer. Therefore, fix the typo. Fixes: e420bed0 ("bpf: Add fd-based tcx multi-prog infra with link support") Reported-by: syzbot+bdcf141f362ef83335cf@syzkaller.appspotmail.com Reported-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com Reported-by: syzbot+14736e249bce46091c18@syzkaller.appspotmail.com Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Tested-by: syzbot+bdcf141f362ef83335cf@syzkaller.appspotmail.com Tested-by: syzbot+b202b7208664142954fa@syzkaller.appspotmail.com Tested-by: syzbot+14736e249bce46091c18@syzkaller.appspotmail.com Tested-by:
-
Pawel Chmielewski authored
Add tracepoints for the following events: - Add FDB entry - Delete FDB entry - Create bridge VLAN - Cleanup bridge VLAN - Link port to the bridge - Unlink port from the bridge Signed-off-by:
Pawel Chmielewski <pawel.chmielewski@intel.com> Signed-off-by:
Wojciech Drewek <wojciech.drewek@intel.com> Tested-by:
Sujai Buvaneswaran <sujai.buvaneswaran@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Michal Swiatkowski authored
Remove fdb entries always when ageing time expired. Allow user to set ageing time using port object attribute. Reviewed-by:
Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Signed-off-by:
-
Michal Swiatkowski authored
Port VLAN in this case means push and pop VLAN action on specific vid. There are a few limitation in hardware: - push and pop can't be used separately - if port VLAN is used there can't be any trunk VLANs, because pop action is done on all traffic received by VSI in port VLAN mode - port VLAN mode on uplink port isn't supported Reflect these limitations in code using dev_info to inform the user about unsupported configuration. In bridge mode there is a need to configure port vlan without resetting VFs. To do that implement ice_port_vlan_on/off() functions. They are only configuring correct vlan_ops to allow setting port vlan. We also need to clear port vlan without resetting the VF which is not supported right now. Change it by implementing clear_port_vlan ops. As previous VLAN configuration isn't always the same, store current config while creating port vlan and restore it in clear function. Configuration steps: - configure switchdev with bridge - #bridge vlan add dev eth0 vid 120 pvid untagged - #bridge vlan add dev eth1 vid 120 pvid untagged - ping from VF0 to VF1 Reviewed-by:
-
Marcin Szycik authored
Add support for matching on VLAN tag in bridge offloads. Currently only trunk mode is supported. To enable VLAN filtering (existing FDB entries will be deleted): ip link set $BR type bridge vlan_filtering 1 To add VLANs to bridge in trunk mode: bridge vlan add dev $PF1 vid 110-111 bridge vlan add dev $VF1_PR vid 110-111 Signed-off-by:
Marcin Szycik <marcin.szycik@intel.com> Signed-off-by:
-
Marcin Szycik authored
Introduce new "guard" rule upon FDB entry creation. It matches on src_mac, has valid bit unset, allow_pass_l2 set and has a nop action. Previously introduced "forward" rule matches on dst_mac, has valid bit set, need_pass_l2 set and has a forward action. With these rules, a packet will be offloaded only if FDB exists in both directions (RX and TX). Let's assume link partner sends a packet to VF1: src_mac = LP_MAC, dst_mac = is VF1_MAC. Bridge adds FDB, two rules are created: 1. Guard rule matching on src_mac == LP_MAC 2. Forward rule matching on dst_mac == LP_MAC Now VF1 responds with src_mac = VF1_MAC, dst_mac = LP_MAC. Before this change, only one rule with dst_mac == LP_MAC would have existed, and the packet would have been offloaded, meaning the bridge wouldn't add FDB in the opposite direction. Now, the forward rule matches (dst_mac == LP_MAC), but it has need_pass_l2 set an there is no guard rule with src_mac == VF1_MAC, so the packet goes through slow-path and the bridge adds FDB. Two rules are created: 1. Guard rule matching on src_mac == VF1_MAC 2. Forward rule matching on dst_mac == VF1_MAC Further packets in both directions will be offloaded. The same example is true in opposite direction (i.e. VF1 is the first to send a packet out). Reviewed-by:
-
Wojciech Drewek authored
Listen for SWITCHDEV_FDB_{ADD|DEL}_TO_DEVICE events while in switchdev mode. Accept these events on both uplink and VF PR ports. Add HW rules in newly created workqueue. FDB entries are stored in rhashtable for lookup when removing the entry and in the list for cleanup purpose. Direction of the HW rule depends on the type of the ports on which the FDB event was received: ICE_ESWITCH_BR_UPLINK_PORT: TX rule that forwards the packet to the LAN (egress). ICE_ESWITCH_BR_VF_REPR_PORT: RX rule that forwards the packet to the VF associated with the port representor. In both cases the rule matches on the dst mac address. All the FDB entries are stored in the bridge structure. When the port is removed all the FDB entries associated with this port are removed as well. This is achieved thanks to the reference to the port that FDB entry holds. In the fwd rule we use only one lookup type (MAC address) but lkups_cnt variable is already introduced because we will have more lookups in the subsequent patches. Signed-off-by: -
Wojciech Drewek authored
With this patch, ice driver is able to track if the port representors or uplink port were added to the linux bridge in switchdev mode. Listen for NETDEV_CHANGEUPPER events in order to detect this. ice_esw_br data structure reflects the linux bridge and stores all the ports of the bridge (ice_esw_br_port) in xarray, it's created when the first port is added to the bridge and freed once the last port is removed. Note that only one bridge is supported per eswitch. Bridge port (ice_esw_br_port) can be either a VF port representor port or uplink port (ice_esw_br_port_type). In both cases bridge port holds a reference to the VSI, VF's VSI in case of the PR and uplink VSI in case of the uplink. VSI's index is used as an index to the xarray in which ports are stored. Add a check which prevents configuring switchdev mode if uplink is already added to any bridge. This is needed because we need to listen for NETDEV_CHANGEUPPER events to record if the uplink was added to the bridge. Netdevice notifier is registered after eswitch mode is changed to switchdev. Reviewed-by:
-
Wojciech Drewek authored
In switchdev mode uplink VSI is supposed to receive all packets that were not matched by existing filters. If ICE_AQ_VSI_SW_FLAG_LOCAL_LB bit is unset and we have a filter associated with uplink VSI which matches on dst mac equal to MAC1, then packets with src mac equal to MAC1 will be pruned from reaching uplink VSI. Fix this by updating uplink VSI with ICE_AQ_VSI_SW_FLAG_LOCAL_LB bit set when configuring switchdev mode. Reviewed-by:
-
Wojciech Drewek authored
In switchdev mode, uplink VSI is configured to be default VSI which means it will receive all unmatched packets. In order to receive vlan packets we need to disable vlan pruning as well. This is done by dis_rx_filtering vlan op. Reviewed-by:
Paul Menzel <pmenzel@molgen.mpg.de> Reviewed-by:
-
Wojciech Drewek authored
There is possibility that ice_eswitch_port_start_xmit might be called while some resources are still not allocated which might cause NULL pointer dereference. Fix this by checking if switchdev configuration was finished. Reviewed-by:
-
