- 06 May, 2019 40 commits
-
-
Heiner Kallweit authored
Move adjusting the EEE LED frequency to rtl8168_config_eee_mac. Exclude RTL8411 (version 38) like in the existing code. Signed-off-by:
Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
Make both functions macros to allow omitting the ARRAY_SIZE(x) argument. Signed-off-by:
-
David S. Miller authored
Vladimir Oltean says: ==================== Traffic support for SJA1105 DSA driver This patch set is a continuation of the "NXP SJA1105 DSA driver" v3 series, which was split in multiple pieces for easier review. Supporting a fully-featured (traffic-capable) driver for this switch requires some rework in DSA and also leaves behind a more generic infrastructure for other dumb switches that rely on 802.1Q pseudo-switch tagging for port separation. Among the DSA changes required are: * Generic xmit and rcv functions for pushing/popping 802.1Q tags on skb's. These are modeled as a tagging protocol of its own but which must be customized by drivers to fit their own hardware possibilities. * Permitting the .setup callback to invoke switchdev operations that will loop back into the driver through the switchdev notifier chain. The SJA1105 driver then proceeds to extend this 8021q switch tagging protocol while adding its own (tag_sja1105). This is done because the driver actually implements a "dual tagger": * For normal traffic it uses 802.1Q tags * For management (multicast DMAC) frames the switch has native support for recognizing and annotating these with source port and switch id information. Because this is a "dual tagger", decoding of management frames should still function when regular traffic can't (under a bridge with VLAN filtering). There was intervention in the DSA receive hotpath, where a new filtering function called from eth_type_trans() is needed. This is useful in the general sense for switches that might actually have some limited means of source port decoding, such as only for management traffic, but not for everything. In order for the 802.1Q tagging protocol (which cannot be enabled under all conditions, unlike the management traffic decoding) to not be an all-or-nothing choice, the filtering function matches everything that can be decoded, and everything else is left to pass to the master netdevice. Lastly, DSA core support was added for drivers to request skb deferral. SJA1105 needs this for SPI intervention during transmission of link-local traffic. This is not done from within the tagger. Some patches were carried over unchanged from the previous patchset (01/09). Others were slightly reworked while adapting to the recent changes in "Make DSA tag drivers kernel modules" (02/09). The introduction of some structures (DSA_SKB_CB, dp->priv) may seem a little premature at this point and the new structures under-utilized. The reason is that traffic support has been rewritten with PTP timestamping in mind, and then I removed the timestamping code from the current submission (1. it is a different topic, 2. it does not work very well yet). On demand I can provide the timestamping patchset as a RFC though. "NXP SJA1105 DSA driver" v3 patchset can be found at: https://lkml.org/lkml/2019/4/12/978 v1 patchset can be found at: https://lkml.org/lkml/2019/5/3/877 Changes in v2: * Made the deferred xmit workqueue also be drained on the netdev suspend callback, not just on ndo_stop. * Added clarification about how other netdevices may be bridged with the switch ports. v2 patchset can be found at: https://www.spinics.net/lists/netdev/msg568818.html Changes in v3: * Exported the dsa_port_vid_add and dsa_port_vid_del symbols to fix an error reported by the kbuild test robot * Fixed the following checkpatch warnings in 05/10: Macro argument reuse 'skb' - possible side-effects? Macro argument reuse 'clone' - possible side-effects? * Added a commit description to the documentation patch (10/10) ==================== Signed-off-by:
-
Vladimir Oltean authored
This adds a table which illustrates what combinations of management / regular traffic work depending on the state the switch ports are in. Signed-off-by:
Vladimir Oltean <olteanv@gmail.com> Reviewed-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
While not explicitly documented as supported in UM10944, compliance with the STP states can be obtained by manipulating 3 settings at the (per-port) MAC config level: dynamic learning, inhibiting reception of regular traffic, and inhibiting transmission of regular traffic. In all these modes, transmission and reception of special BPDU frames from the stack is still enabled (not inhibited by the MAC-level settings). On ingress, BPDUs are classified by the MAC filter as link-local (01-80-C2-00-00-00) and forwarded to the CPU port. This mechanism works under all conditions (even without the custom 802.1Q tagging) because the switch hardware inserts the source port and switch ID into bytes 4 and 5 of the MAC-filtered frames. Then the DSA .rcv handler needs to put back zeroes into the MAC address after decoding the source port information. On egress, BPDUs are transmitted using management routes from the xmit worker thread. Again this does not require switch tagging, as the switch port is programmed through SPI to hold a temporary (single-fire) route for a frame with the programmed destination MAC (01-80-C2-00-00-00). STP is activated using the following commands and was tested by connecting two front-panel ports together and noticing that switching loops were prevented (one port remains in the blocking state): $ ip link add name br0 type bridge stp_state 1 && ip link set br0 up $ for eth in $(ls /sys/devices/platform/soc/2100000.spi/spi_master/spi0/spi0.1/net/); do ip link set ${eth} master br0 && ip link set ${eth} up; done Signed-off-by:Andrew Lunn <andrew@lunn.ch> Reviewed-by:
-
Vladimir Oltean authored
In order to support this, we are creating a make-shift switch tag out of a VLAN trunk configured on the CPU port. Termination of normal traffic on switch ports only works when not under a vlan_filtering bridge. Termination of management (PTP, BPDU) traffic works under all circumstances because it uses a different tagging mechanism (incl_srcpt). We are making use of the generic CONFIG_NET_DSA_TAG_8021Q code and leveraging it from our own CONFIG_NET_DSA_TAG_SJA1105. There are two types of traffic: regular and link-local. The link-local traffic received on the CPU port is trapped from the switch's regular forwarding decisions because it matched one of the two DMAC filters for management traffic. On transmission, the switch requires special massaging for these link-local frames. Due to a weird implementation of the switching IP, by default it drops link-local frames that originate on the CPU port. It needs to be told where to forward them to, through an SPI command ("management route") that is valid for only a single frame. So when we're sending link-local traffic, we are using the dsa_defer_xmit mechanism. Signed-off-by: -
Vladimir Oltean authored
This is supposed to share information between the driver and the tagger, or used by the tagger to keep some state. Its use is optional. Signed-off-by:
Vivien Didelot <vivien.didelot@gmail.com> Signed-off-by:
-
Vladimir Oltean authored
Some hardware needs to take work to get convinced to receive frames on the CPU port (such as the sja1105 which takes temporary L2 forwarding rules over SPI that last for a single frame). Such work needs a sleepable context, and because the regular .ndo_start_xmit is atomic, this cannot be done in the tagger. So introduce a generic DSA mechanism that sets up a transmit skb queue and a workqueue for deferred transmission. The new driver callback (.port_deferred_xmit) is in dsa_switch and not in the tagger because the operations that require sleeping typically also involve interacting with the hardware, and not simply skb manipulations. Therefore having it there simplifies the structure a bit and makes it unnecessary to export functions from the driver to the tagger. The driver is responsible of calling dsa_enqueue_skb which transfers it to the master netdevice. This is so that it has a chance of performing some more work afterwards, such as cleanup or TX timestamping. To tell DSA that skb xmit deferral is required, I have thought about changing the return type of the tagger .xmit from struct sk_buff * into a enum dsa_tx_t that could potentially encode a DSA_XMIT_DEFER value. But the trailer tagger is reallocating every skb on xmit and therefore making a valid use of the pointer return value. So instead of reworking the API in complicated ways, right now a boolean property in the newly introduced DSA_SKB_CB is set. Signed-off-by:
-
Vladimir Oltean authored
Map a DSA structure over the 48-byte control block that will hold skb info on transmit and receive. This is only for use within the DSA processing layer (e.g. communicating between DSA core and tagger) and not for passing info around with other layers such as the master net device. Also add a DSA_SKB_CB_PRIV() macro which retrieves a pointer to the space up to 48 bytes that the DSA structure does not use. This space can be used for drivers to add their own private info. One use is for the PTP timestamping code path. When cloning a skb, annotate the original with a pointer to the clone, which the driver can then find easily and place the timestamp to. This avoids the need of a separate queue to hold clones and a way to match an original to a cloned skb. Signed-off-by:
-
Vladimir Oltean authored
Frames get processed by DSA and redirected to switch port net devices based on the ETH_P_XDSA multiplexed packet_type handler found by the network stack when calling eth_type_trans(). The running assumption is that once the DSA .rcv function is called, DSA is always able to decode the switch tag in order to change the skb->dev from its master. However there are tagging protocols (such as the new DSA_TAG_PROTO_SJA1105, user of DSA_TAG_PROTO_8021Q) where this assumption is not completely true, since switch tagging piggybacks on the absence of a vlan_filtering bridge. Moreover, management traffic (BPDU, PTP) for this switch doesn't rely on switch tagging, but on a different mechanism. So it would make sense to at least be able to terminate that. Having DSA receive traffic it can't decode would put it in an impossible situation: the eth_type_trans() function would invoke the DSA .rcv(), which could not change skb->dev, then eth_type_trans() would be invoked again, which again would call the DSA .rcv, and the packet would never be able to exit the DSA filter and would spiral in a loop until the whole system dies. This happens because eth_type_trans() doesn't actually look at the skb (so as to identify a potential tag) when it deems it as being ETH_P_XDSA. It just checks whether skb->dev has a DSA private pointer installed (therefore it's a DSA master) and that there exists a .rcv callback (everybody except DSA_TAG_PROTO_NONE has that). This is understandable as there are many switch tags out there, and exhaustively checking for all of them is far from ideal. The solution lies in introducing a filtering function for each tagging protocol. In the absence of a filtering function, all traffic is passed to the .rcv DSA callback. The tagging protocol should see the filtering function as a pre-validation that it can decode the incoming skb. The traffic that doesn't match the filter will bypass the DSA .rcv callback and be left on the master netdevice, which wasn't previously possible. Signed-off-by:
-
Vladimir Oltean authored
This patch provides generic DSA code for using VLAN (802.1Q) tags for the same purpose as a dedicated switch tag for injection/extraction. It is based on the discussions and interest that has been so far expressed in https://www.spinics.net/lists/netdev/msg556125.html. Unlike all other DSA-supported tagging protocols, CONFIG_NET_DSA_TAG_8021Q does not offer a complete solution for drivers (nor can it). Instead, it provides generic code that driver can opt into calling: - dsa_8021q_xmit: Inserts a VLAN header with the specified contents. Can be called from another tagging protocol's xmit function. Currently the LAN9303 driver is inserting headers that are simply 802.1Q with custom fields, so this is an opportunity for code reuse. - dsa_8021q_rcv: Retrieves the TPID and TCI from a VLAN-tagged skb. Removing the VLAN header is left as a decision for the caller to make. - dsa_port_setup_8021q_tagging: For each user port, installs an Rx VID and a Tx VID, for proper untagged traffic identification on ingress and steering on egress. Also sets up the VLAN trunk on the upstream (CPU or DSA) port. Drivers are intentionally left to call this function explicitly, depending on the context and hardware support. The expected switch behavior and VLAN semantics should not be violated under any conditions. That is, after calling dsa_port_setup_8021q_tagging, the hardware should still pass all ingress traffic, be it tagged or untagged. For uniformity with the other tagging protocols, a module for the dsa_8021q_netdev_ops structure is registered, but the typical usage is to set up another tagging protocol which selects CONFIG_NET_DSA_TAG_8021Q, and calls the API from tag_8021q.h. Null function definitions are also provided so that a "depends on" is not forced in the Kconfig. This tagging protocol only works when switch ports are standalone, or when they are added to a VLAN-unaware bridge. It will probably remain this way for the reasons below. When added to a bridge that has vlan_filtering 1, the bridge core will install its own VLANs and reset the pvids through switchdev. For the bridge core, switchdev is a write-only pipe. All VLAN-related state is kept in the bridge core and nothing is read from DSA/switchdev or from the driver. So the bridge core will break this port separation because it will install the vlan_default_pvid into all switchdev ports. Even if we could teach the bridge driver about switchdev preference of a certain vlan_default_pvid (task difficult in itself since the current setting is per-bridge but we would need it per-port), there would still exist many other challenges. Firstly, in the DSA rcv callback, a driver would have to perform an iterative reverse lookup to find the correct switch port. That is because the port is a bridge slave, so its Rx VID (port PVID) is subject to user configuration. How would we ensure that the user doesn't reset the pvid to a different value (which would make an O(1) translation impossible), or to a non-unique value within this DSA switch tree (which would make any translation impossible)? Finally, not all switch ports are equal in DSA, and that makes it difficult for the bridge to be completely aware of this anyway. The CPU port needs to transmit tagged packets (VLAN trunk) in order for the DSA rcv code to be able to decode source information. But the bridge code has absolutely no idea which switch port is the CPU port, if nothing else then just because there is no netdevice registered by DSA for the CPU port. Also DSA does not currently allow the user to specify that they want the CPU port to do VLAN trunking anyway. VLANs are added to the CPU port using the same flags as they were added on the user port. So the VLANs installed by dsa_port_setup_8021q_tagging per driver request should remain private from the bridge's and user's perspective, and should not alter the VLAN semantics observed by the user. In the current implementation a VLAN range ending at 4095 (VLAN_N_VID) is reserved for this purpose. Each port receives a unique Rx VLAN and a unique Tx VLAN. Separate VLANs are needed for Rx and Tx because they serve different purposes: on Rx the switch must process traffic as untagged and process it with a port-based VLAN, but with care not to hinder bridging. On the other hand, the Tx VLAN is where the reachability restrictions are imposed, since by tagging frames in the xmit callback we are telling the switch onto which port to steer the frame. Some general guidance on how this support might be employed for real-life hardware (some comments made by Florian Fainelli): - If the hardware supports VLAN tag stacking, it should somehow back up its private VLAN settings when the bridge tries to override them. Then the driver could re-apply them as outer tags. Dedicating an outer tag per bridge device would allow identical inner tag VID numbers to co-exist, yet preserve broadcast domain isolation. - If the switch cannot handle VLAN tag stacking, it should disable this port separation when added as slave to a vlan_filtering bridge, in that case having reduced functionality. - Drivers for old switches that don't support the entire VLAN_N_VID range will need to rework the current range selection mechanism. Signed-off-by:
-
Vladimir Oltean authored
This is needed so that the newly introduced tag_8021q may access these core DSA functions when built as a module. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Vladimir Oltean authored
This allows the driver to perform some manipulations of its own during setup, using generic switchdev calls. Having the notifiers registered at setup time is important because otherwise any switchdev transaction emitted during this time would be ignored (dispatched to an empty call chain). One current usage scenario is for the driver to request DSA to set up 802.1Q based switch tagging for its ports. There is no danger for the driver setup code to start racing now with switchdev events emitted from the network stack (such as bridge core) even if the notifier is registered earlier. This is because the network stack needs a net_device as a vehicle to perform switchdev operations, and the slave net_devices are registered later than the core driver setup anyway (ds->ops->setup in dsa_switch_setup vs dsa_port_setup). Luckily DSA doesn't need a net_device to carry out switchdev callbacks, and therefore drivers shouldn't assume either that net_devices are available at the time their switchdev callbacks get invoked. Signed-off-by:
-
Vivien Didelot authored
The Marvell SOHO switches have several ways to access the internal registers. One of them being the System Management Interface (SMI), using the MDC and MDIO pins, with direct and indirect variants. In preparation for adding support for other register accesses, move the SMI code into its own files. At the same time, refine the code to make it clear that the indirect variant is implemented using the direct variant accessing only two registers for command and data. Signed-off-by:
-
David S. Miller authored
Jakub Kicinski says: =================== net: act_police offload support this set starts by converting cls_matchall to the new flow offload infrastructure. It so happens that all drivers implementing cls_matchall offload today also offload cls_flower, so its a little easier for them to handle the actions in unified flow_rule format, even though in cls_matchall there is no flow to speak of. If a driver ever appears which would prefer the old, direct access to TC exts, we can add the pointer in the offload structure back and support both. Next the act_police is added to actions supported by flow offload API. NFP support for act_police offload is added as the final step. The flower firmware is configured to perform TX rate limiting in a way which matches act_police's behaviour. It does not use DMA.IN back pressure, and instead drops packets after they had been already DMAed into the NIC. IOW it uses our standard traffic policing implementation, future patches will extend it to other ports and traffic directions. =================== Signed-off-by: -
Pieter Jansen van Vuuren authored
Add stats request function that sends a stats request message to hw for a specific police-filter. Process stats reply from hw and update the stored qos structure. Signed-off-by:
Pieter Jansen van Vuuren <pieter.jansenvanvuuren@netronome.com> Reviewed-by:
Jakub Kicinski <jakub.kicinski@netronome.com> Signed-off-by:
-
Pieter Jansen van Vuuren authored
Add install and remove offload functionality for qos offloads. We first check that a police filter can be implemented by the VF rate limiting feature in hw, then we install the filter via the qos infrastructure. Finally we implement the mechanism for removing these types of filters. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Introduce matchall filter offload infrastructure that is needed to offload qos features like policing. Subsequent patches will make use of police-filters for ingress rate limiting. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Some actions like the police action are stateful and could share state between devices. This is incompatible with offloading to multiple devices and drivers might want to test for shared blocks when offloading. Store a pointer to the tcf_block structure in the tc_cls_common_offload structure to allow drivers to determine when offloads apply to a shared block. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Implement the stats_update callback for the police action that will be used by drivers for hardware offload. Signed-off-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
-
Pieter Jansen van Vuuren authored
Introduce a new command for matchall classifiers that allows hardware to update statistics. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Add police action to the hardware intermediate representation which would subsequently allow it to be used by drivers for offload. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Move tcf_police_params, tcf_police and tc_police_compat structures to a header. Making them usable to other code for example drivers that would offload police actions to hardware. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Cleanup unused functions and variables after porting to the newer intermediate representation. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Updates dsa hardware switch handling infrastructure to use the newer intermediate representation for flow actions in matchall offloads. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Updates the Mellanox spectrum driver to use the newer intermediate representation for flow actions in matchall offloads. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Extends matchall offload to make use of the hardware intermediate representation. More specifically, this patch moves the native TC actions in cls_matchall offload to the newer flow_action representation. This ultimately allows us to avoid a direct dependency on native TC actions for matchall. Signed-off-by:
-
Pieter Jansen van Vuuren authored
Add sample action to the hardware intermediate representation model which would subsequently allow it to be used by drivers for offload. Signed-off-by:
-
David S. Miller authored
Petr Štetiar says: ==================== of_net: Add NVMEM support to of_get_mac_address this patch series is a continuation of my previous attempt[1], where I've tried to wire MTD layer into of_get_mac_address, so it would be possible to load MAC addresses from various NVMEMs as EEPROMs etc. Predecessor of this patch which used directly MTD layer has originated in OpenWrt some time ago and supports already about 497 use cases in 357 device tree files. During the review process of my 1st attempt I was told, that I shouldn't be using MTD directly, but that I should rather use new NVMEM subsystem and during the review process of v2 I was told, that I should handle EPROBE_DEFFER error as well, during the review process of v3 I was told, that returning pointer/NULL/ERR_PTR is considered as wrong API design, so this v4 patch series tries to accommodate all this previous remarks. First patch is wiring NVMEM support directly into of_get_mac_address as it's obvious, that adding support for NVMEM into every other driver would mean adding a lot of repetitive code. This patch allows us to configure MAC addresses in various devices like ethernet and wireless adapters directly from of_get_mac_address, which is used by quite a lot of drivers in the tree already. Second patch is simply updating documentation with NVMEM bits, and cleaning up all current binding documentation referencing any of the MAC address related properties. Third and fourth patches are simply removing duplicate NVMEM code which is no longer needed as the first patch has wired NVMEM support directly into of_get_mac_address. Patches 5-10 are converting all current users of of_get_mac_address to the new ERR_PTR encoded error value, as of_get_mac_address could now return valid pointer, NULL and ERR_PTR. Just for a better picture, this patch series and one simple patch[2] on top of it, allows me to configure 8Devices Carambola2 board's MAC addresses with following DTS (simplified): &spi { flash@0 { partitions { art: partition@ff0000 { label = "art"; reg = <0xff0000 0x010000>; read-only; nvmem-cells { compatible = "nvmem-cells"; #address-cells = <1>; #size-cells = <1>; eth0_addr: eth-mac-addr@0 { reg = <0x0 0x6>; }; eth1_addr: eth-mac-addr@6 { reg = <0x6 0x6>; }; wmac_addr: wifi-mac-addr@1002 { reg = <0x1002 0x6>; }; }; }; }; }; }; ð0 { nvmem-cells = <ð0_addr>; nvmem-cell-names = "mac-address"; }; ð1 { nvmem-cells = <ð1_addr>; nvmem-cell-names = "mac-address"; }; &wmac { nvmem-cells = <&wmac_addr>; nvmem-cell-names = "mac-address"; }; 1. https://patchwork.ozlabs.org/patch/1086628/ 2. https://patchwork.ozlabs.org/patch/890738/ ==================== Signed-off-by: -
Petr Štetiar authored
There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by:
Petr Štetiar <ynezz@true.cz> Signed-off-by:
-
Petr Štetiar authored
There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by:
-
Petr Štetiar authored
There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by:
-
Petr Štetiar authored
There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by:
-
Petr Štetiar authored
There was NVMEM support added to of_get_mac_address, so it could now return ERR_PTR encoded error values, so we need to adjust all current users of of_get_mac_address to this new fact. Signed-off-by:
-
Petr Štetiar authored
There was NVMEM support added directly to of_get_mac_address, and it uses nvmem_get_mac_address under the hood, so we can remove it. As of_get_mac_address can now return ERR_PTR encoded error values, adjust to that as well. Signed-off-by:
-
Petr Štetiar authored
There was NVMEM support added directly to of_get_mac_address, and it uses nvmem_get_mac_address under the hood, so we can remove it. As of_get_mac_address can now return ERR_PTR encoded error values, adjust to that as well. Signed-off-by:
-
Petr Štetiar authored
As of_get_mac_address now supports NVMEM under the hood, we need to update the bindings documentation with the new nvmem-cell* properties, which would mean copy&pasting a lot of redundant information to every binding documentation currently referencing some of the MAC address properties. So I've just removed all the references to the optional MAC address properties and replaced them with the small note referencing net/ethernet.txt file. Signed-off-by:
-
Petr Štetiar authored
Many embedded devices have information such as MAC addresses stored inside NVMEMs like EEPROMs and so on. Currently there are only two drivers in the tree which benefit from NVMEM bindings. Adding support for NVMEM into every other driver would mean adding a lot of repetitive code. This patch allows us to configure MAC addresses in various devices like ethernet and wireless adapters directly from of_get_mac_address, which is already used by almost every driver in the tree. Predecessor of this patch which used directly MTD layer has originated in OpenWrt some time ago and supports already about 497 use cases in 357 device tree files. Cc: Alban Bedel <albeu@free.fr> Signed-off-by:
Felix Fietkau <nbd@nbd.name> Signed-off-by:
John Crispin <john@phrozen.org> Signed-off-by:
-
David S. Miller authored
Michael Chan says: ==================== bnxt_en: Driver updates. This patch series adds some extended statistics available with the new firmware interface, package version from firmware, aRFS support on 57500 chips, new PCI IDs, and some miscellaneous fixes and improvements. ==================== Signed-off-by: -
Michael Chan authored
0x1806 and 0x1752 are VF variant and PF variant of the 57500 chip family. Signed-off-by:
Michael Chan <michael.chan@broadcom.com> Signed-off-by:
-
