summaryrefslogtreecommitdiffstats
path: root/drivers
AgeCommit message (Collapse)AuthorFilesLines
2020-06-22net: atlantic: A2: report link partner capabilitiesDmitry Bogdanov3-0/+81
This patch adds link partner capabilities reporting support on A2. In particular, the following capabilities are available for reporting: * link rate; * EEE; * flow control. Signed-off-by: Dmitry Bogdanov <dbogdanov@marvell.com> Signed-off-by: Mark Starovoytov <mstarovoitov@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: atlantic: A2: flow control supportIgor Russkikh4-1/+42
This patch adds flow control support on A2. Co-developed-by: Dmitry Bogdanov <dbogdanov@marvell.com> Signed-off-by: Dmitry Bogdanov <dbogdanov@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: atlantic: A2: EEE supportNikita Danilov3-5/+91
This patch adds EEE support on A2. Signed-off-by: Nikita Danilov <ndanilov@marvell.com> Co-developed-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: atlantic: remove baseX usageNikita Danilov1-3/+0
This patch removes 2.5G baseX wrong usage/reporting, since it shouldn't have been mixed with baseT. Signed-off-by: Nikita Danilov <ndanilov@marvell.com> Signed-off-by: Mark Starovoytov <mstarovoitov@marvell.com> Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: atlantic: A2: half duplex supportIgor Russkikh7-23/+70
This patch adds support for 10M/100M/1G half duplex rates, which are supported by A2 in additional to full duplex rates supported by A1. Signed-off-by: Igor Russkikh <irusskikh@marvell.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: mtk_eth_soc: use resolved link config in mac_link_up()Russell King1-20/+25
Convert the mtk_eth_soc driver to use the finalised link parameters in mac_link_up() rather than the parameters in mac_config(). Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: mscc: ocelot: support IPv4, IPv6 and plain Ethernet mdb entriesVladimir Oltean2-15/+80
The current procedure for installing a multicast address is hardcoded for IPv4. But, in the ocelot hardware, there are 3 different procedures for IPv4, IPv6 and for regular L2 multicast. For IPv6 (33-33-xx-xx-xx-xx), it's the same as for IPv4 (01-00-5e-xx-xx-xx), except that the destination port mask is stuffed into first 2 bytes of the MAC address except into first 3 bytes. For plain Ethernet multicast, there's no port-in-address stuffing going on, instead the DEST_IDX (pointer to PGID) is used there, just as for unicast. So we have to use one of the nonreserved multicast PGIDs that the hardware has allocated for this purpose. This patch classifies the type of multicast address based on its first bytes, then redirects to one of the 3 different hardware procedures. Note that this gives us a really better way of redirecting PTP frames sent at 01-1b-19-00-00-00 to the CPU. Previously, Yangbo Lu tried to add a trapping rule for PTP EtherType but got a lot of pushback: https://patchwork.ozlabs.org/project/netdev/patch/20190813025214.18601-5-yangbo.lu@nxp.com/ But right now, that isn't needed at all. The application stack (ptp4l) does this for the PTP multicast addresses it's interested in (which are configurable, and include 01-1b-19-00-00-00): memset(&mreq, 0, sizeof(mreq)); mreq.mr_ifindex = index; mreq.mr_type = PACKET_MR_MULTICAST; mreq.mr_alen = MAC_LEN; memcpy(mreq.mr_address, addr1, MAC_LEN); err1 = setsockopt(fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP, &mreq, sizeof(mreq)); Into the kernel, this translates into a dev_mc_add on the switch network interfaces, and our drivers know that it means they should translate it into a host MDB address (make the CPU port be the destination). Previously, this was broken because all mdb addresses were treated as IPv4 (which 01-1b-19-00-00-00 obviously is not). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: mscc: ocelot: introduce macros for iterating over PGIDsVladimir Oltean2-5/+5
The current iterators are impossible to understand at first glance without switching back and forth between the definitions and their actual use in the for loops. So introduce some convenience names to help readability. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: dsa: felix: call port mdb operations from ocelotVladimir Oltean4-20/+60
This adds the mdb hooks in felix and exports the mdb functions from ocelot. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: mscc: ocelot: make the NPI port a proper target for FDB and MDBVladimir Oltean1-1/+11
When used in DSA mode (as seen in Felix), the DEST_IDX in the MAC table should point to the PGID for the CPU port (PGID_CPU) and not for the Ethernet port where the CPU queues are redirected to (also known as Node Processor Interface - NPI). Because for Felix this distinction shouldn't really matter (from DSA perspective, the NPI port _is_ the CPU port), make the ocelot library act upon the CPU port when NPI mode is enabled. This has no effect for the mscc_ocelot driver for VSC7514, because that does not use NPI (and ocelot->npi is -1). Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: mscc: ocelot: fix encoding destination ports into multicast IPv4 addressVladimir Oltean1-8/+8
The ocelot hardware designers have made some hacks to support multicast IPv4 and IPv6 addresses. Normally, the MAC table matches on MAC addresses and the destination ports are selected through the DEST_IDX field of the respective MAC table entry. The DEST_IDX points to a Port Group ID (PGID) which contains the bit mask of ports that frames should be forwarded to. But there aren't a lot of PGIDs (only 80 or so) and there are clearly many more IP multicast addresses than that, so it doesn't scale to use this PGID mechanism, so something else was done. Since the first portion of the MAC address is known, the hack they did was to use a single PGID for _flooding_ unknown IPv4 multicast (PGID_MCIPV4 == 62), but for known IP multicast, embed the destination ports into the first 3 bytes of the MAC address recorded in the MAC table. The VSC7514 datasheet explains it like this: 3.9.1.5 IPv4 Multicast Entries MAC table entries with the ENTRY_TYPE = 2 settings are interpreted as IPv4 multicast entries. IPv4 multicasts entries match IPv4 frames, which are classified to the specified VID, and which have DMAC = 0x01005Exxxxxx, where xxxxxx is the lower 24 bits of the MAC address in the entry. Instead of a lookup in the destination mask table (PGID), the destination set is programmed as part of the entry MAC address. This is shown in the following table. Table 78: IPv4 Multicast Destination Mask Destination Ports Record Bit Field --------------------------------------------- Ports 10-0 MAC[34-24] Example: All IPv4 multicast frames in VLAN 12 with MAC 01005E112233 are to be forwarded to ports 3, 8, and 9. This is done by inserting the following entry in the MAC table entry: VALID = 1 VID = 12 MAC = 0x000308112233 ENTRY_TYPE = 2 DEST_IDX = 0 But this procedure is not at all what's going on in the driver. In fact, the code that embeds the ports into the MAC address looks like it hasn't actually been tested. This patch applies the procedure described in the datasheet. Since there are many other fixes to be made around multicast forwarding until it works properly, there is no real reason for this patch to be backported to stable trees, or considered a real fix of something that should have worked. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22mlxsw: spectrum_acl: Support FLOW_ACTION_MANGLE for TCP, UDP portsPetr Machata3-0/+51
Spectrum-2 supports an ACL action L4_PORT, which allows TCP and UDP source and destination port number change. Offload suitable mangles to this action. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22mlxsw: core_acl_flex_actions: Add L4_PORT_ACTIONPetr Machata1-0/+26
Add fields related to L4_PORT_ACTION, which is used for changing of TCP and UDP port numbers. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22mlxsw: spectrum: Split handling of pedit mangle by chip typePetr Machata3-7/+60
Certain ACL actions are only available on some Spectrum revisions. In particular, L4_PORT_ACTION is not available on Spectrum-1. Introduce a new ops struct intended to hold these differences, mlxsw_sp_rulei_ops. Prime it with a sole member, act_mangle_field, meant for handling of pedit mangles. Create two ops structures, one for Spectrum-1, the other for Spectrum-2 and above. Add callbacks for act_mangle_field and dispatch to the common handler. Invoke mlxsw_sp_rulei_ops.act_mangle_field from the field mangler instead of calling the common handler directly. Signed-off-by: Petr Machata <petrm@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: Ido Schimmel <idosch@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: phy: marvell: Add Marvell 88E1548P supportMaxim Kochetkov1-0/+23
Add support for this new phy ID. Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: phy: marvell: Add Marvell 88E1340S supportMaxim Kochetkov1-0/+23
Add support for this new phy ID. Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: phy: marvell: use a single style for referencing functionsMaxim Kochetkov1-111/+111
The kernel in general does not use &func referencing format. Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22r8169: improve rtl8169_runtime_resumeHeiner Kallweit1-10/+3
Simplify rtl8169_runtime_resume() by calling rtl8169_resume(). Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22r8169: remove driver-specific mutexHeiner Kallweit1-45/+0
Now that the critical sections are protected with RTNL lock, we don't need a separate mutex any longer. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22r8169: use RTNL to protect critical sectionsHeiner Kallweit1-0/+8
Most relevant ops (open, close, ethtool ops) are protected with RTNL lock by net core. Make sure that such ops can't be interrupted by e.g. (runtime-)suspending by taking the RTNL lock in suspend ops and the PCI error handler. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22r8169: add rtl8169_upHeiner Kallweit1-32/+16
Factor out bringing device up to a new function rtl8169_up(), similar to rtl8169_down() for bringing the device down. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22r8169: remove no longer needed checks for device being runtime-activeHeiner Kallweit1-48/+6
Because the netdevice is marked as detached now when parent is not accessible we can remove quite some checks. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22r8169: mark device as not present when in PCI D3Heiner Kallweit1-11/+14
Mark the netdevice as detached whenever we go into PCI D3hot. This allows to remove some checks e.g. from ethtool ops because dev_ethtool() checks for netif_device_present() in the beginning. In this context move waking up the queue out of rtl_reset_work() because in cases where netif_device_attach() is called afterwards the queue should be woken up by the latter function only. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: stmmac: dwmac-meson8b: add a compatible string for G12A SoCsMartin Blumenstingl1-0/+4
Amlogic Meson G12A, G12B and SM1 have the same (at least as far as we know at the time of writing) PRG_ETHERNET glue register implementation. This implementation however is slightly different from AXG as it now has an undocument "auto cali idx val" register in PRG_ETH1[17:16] which seems to be related to RGMII Ethernet. Add a new compatible string for G12A SoCs so the logic for this new register can be implemented in the future. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22bnxt_en: Add board.serial_number field to info_get cbVasundhara Volam1-0/+6
Add board.serial_number field info to info_get cb via devlink, if driver can fetch the information from the device. Cc: Jiri Pirko <jiri@mellanox.com> Cc: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com> Reviewed-by: Michael Chan <michael.chan@broadcom.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: dsa: sja1105: make the instantiations of struct sja1105_info constantVladimir Oltean2-12/+17
Since struct sja1105_private only holds a const pointer to one of these structures based on device tree compatible string, the structures themselves can be made const. Also add an empty line between each structure definition, to appease checkpatch. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: dsa: sja1105: make config table operation structures constantVladimir Oltean4-16/+16
The per-chip instantiations of struct sja1105_table_ops and struct sja1105_dynamic_table_ops can be made constant, so do that. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: dsa: sja1105: remove empty structures from config table opsVladimir Oltean2-45/+0
Sparse is complaining and giving the following warning message: 'Using plain integer as NULL pointer'. This is not what's going on, instead {0} is used as a zero initializer for the structure members, to indicate that the particular chip revision does not support those particular config tables. But since the config tables are declared globally, the unpopulated elements are zero-initialized anyway. So, to make sparse shut up, let's remove the zero initializers. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: dsa: qca8k: Minor comment spelling fixJonathan McDowell1-1/+1
Signed-off-by: Jonathan McDowell <noodles@earth.li> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: dsa: qca8k: Improve SGMII interface handlingJonathan McDowell2-1/+45
This patch improves the handling of the SGMII interface on the QCA8K devices. Previously the driver did no configuration of the port, even if it was selected. We now configure it up in the appropriate PHY/MAC/Base-X mode depending on what phylink tells us we are connected to and ensure it is enabled. Tested with a device where the CPU connection is RGMII (i.e. the common current use case) + one where the CPU connection is SGMII. I don't have any devices where the SGMII interface is brought out to something other than the CPU. Signed-off-by: Jonathan McDowell <noodles@earth.li> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net: dsa: qca8k: Switch to PHYLINK instead of PHYLIBJonathan McDowell1-96/+210
Update the driver to use the new PHYLINK callbacks, removing the legacy adjust_link callback. Signed-off-by: Jonathan McDowell <noodles@earth.li> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22bonding: support hardware encryption offload to slavesJarod Wilson1-2/+125
Currently, this support is limited to active-backup mode, as I'm not sure about the feasilibity of mapping an xfrm_state's offload handle to multiple hardware devices simultaneously, and we rely on being able to pass some hints to both the xfrm and NIC driver about whether or not they're operating on a slave device. I've tested this atop an Intel x520 device (ixgbe) using libreswan in transport mode, succesfully achieving ~4.3Gbps throughput with netperf (more or less identical to throughput on a bare NIC in this system), as well as successful failover and recovery mid-netperf. v2: just use CONFIG_XFRM_OFFLOAD for wrapping, isolate more code with it CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: "David S. Miller" <davem@davemloft.net> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com> CC: Jakub Kicinski <kuba@kernel.org> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: netdev@vger.kernel.org CC: intel-wired-lan@lists.osuosl.org Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22mlx5: become aware of when running as a bonding slaveJarod Wilson1-0/+6
I've been unable to get my hands on suitable supported hardware to date, but I believe this ought to be all that is needed to enable the mlx5 driver to also work with bonding active-backup crypto offload passthru. CC: Boris Pismenny <borisp@mellanox.com> CC: Saeed Mahameed <saeedm@mellanox.com> CC: Leon Romanovsky <leon@kernel.org> CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: "David S. Miller" <davem@davemloft.net> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com> CC: Jakub Kicinski <kuba@kernel.org> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: netdev@vger.kernel.org Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22ixgbe_ipsec: become aware of when running as a bonding slaveJarod Wilson1-8/+31
Slave devices in a bond doing hardware encryption also need to be aware that they're slaves, so we operate on the slave instead of the bonding master to do the actual hardware encryption offload bits. CC: Jay Vosburgh <j.vosburgh@gmail.com> CC: Veaceslav Falico <vfalico@gmail.com> CC: Andy Gospodarek <andy@greyhouse.net> CC: "David S. Miller" <davem@davemloft.net> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com> CC: Jakub Kicinski <kuba@kernel.org> CC: Steffen Klassert <steffen.klassert@secunet.com> CC: Herbert Xu <herbert@gondor.apana.org.au> CC: netdev@vger.kernel.org CC: intel-wired-lan@lists.osuosl.org Acked-by: Jeff Kirsher <Jeffrey.t.kirsher@intel.com> Signed-off-by: Jarod Wilson <jarod@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net/mlx5: E-switch, Supporting setting devlink port function mac addressParav Pandit3-0/+41
Enable user to set mac address of the PCI PF and VF port function. Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net/mlx5: Split mac address setting function for using state_lockParav Pandit1-14/+24
Refactor mac address setting function to let caller hold the necessary state_lock mutex, so that subsequent patch and use this helper routine. Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net/mlx5: E-switch, Support querying port function mac addressParav Pandit3-0/+55
Support querying mac address of the eswitch devlink port function. Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Acked-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net/mlx5: Move helper to eswitch layerParav Pandit2-7/+8
To use port number to port index conversion at eswitch level, move it to eswitch header. Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net/mlx5: E-switch, Introduce and use eswitch support check helperParav Pandit3-40/+50
Introduce an helper routine to get esw from a devlink device and use it at eswitch callbacks and in subsequent patch. Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-22net/mlx5: Constify mac address pointerParav Pandit3-4/+4
Since none of the functions need to modify the input mac address, constify them. Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Roi Dayan <roid@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20net: mvpp2: set xlg flow control in mvpp2_mac_link_up()Russell King1-12/+11
Set the flow control settings in mvpp2_mac_link_up() for 10G links just as we do for 1G and slower links. This is now the preferred location. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20net: mvpp2: add register modification helperRussell King1-42/+46
Add a helper to read-modify-write a register, and use it in the phylink helpers. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20net: mvpp2: add mvpp2_phylink_to_port() helperRussell King1-15/+14
Add a helper to convert the struct phylink_config pointer passed in from phylink to the drivers internal struct mvpp2_port. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20net: mvpp2: add port support helpersRussell King1-16/+27
The mvpp2 code has tests scattered amongst the code to determine whether the port supports the XLG, and whether the port supports RGMII mode. Rather than having these tests scattered, provide a couple of helper functions, so that future additions can ensure that they get these tests correct. Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20of: mdio: preserve phy dev_flags in of_phy_connect()Tao Ren1-1/+1
Replace assignment "=" with OR "|=" for "phy->dev_flags" so "dev_flags" configured in phy probe() function can be preserved. The idea is similar to commit e7312efbd5de ("net: phy: modify assignment to OR for dev_flags in phy_attach_direct"). Signed-off-by: Tao Ren <rentao.bupt@gmail.com> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20net: mscc: ocelot: unexpose ocelot_vcap_policer_{add,del}Vladimir Oltean2-56/+45
Remove the function prototypes from ocelot_police.h and make these functions static. We need to move them above their callers. Note that moving the implementations to ocelot_police.c is not trivially possible due to dependency on is2_entry_set() which is static to ocelot_vcap.c. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20net: mscc: ocelot: generalize the "ACE/ACL" namesVladimir Oltean5-249/+255
Access Control Lists (and their respective Access Control Entries) are specifically entries in the VCAP IS2, the security enforcement block, according to the documentation. Let's rename the structures and functions to something more generic, so that VCAP IS1 structures (which would otherwise have to be called Ingress Classification Entries) can reuse the same code without confusion. Some renaming that was done: struct ocelot_ace_rule -> struct ocelot_vcap_filter struct ocelot_acl_block -> struct ocelot_vcap_block enum ocelot_ace_type -> enum ocelot_vcap_key_type struct ocelot_ace_vlan -> struct ocelot_vcap_key_vlan enum ocelot_ace_action -> enum ocelot_vcap_action struct ocelot_ace_stats -> struct ocelot_vcap_stats enum ocelot_ace_type -> enum ocelot_vcap_key_type struct ocelot_ace_frame_* -> struct ocelot_vcap_key_* No functional change is intended. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20net: mscc: ocelot: rename ocelot_ace.{c, h} to ocelot_vcap.{c,h}Vladimir Oltean6-5/+5
Access Control Lists (and their respective Access Control Entries) are specifically entries in the VCAP IS2, the security enforcement block, according to the documentation. Let's rename the files that deal with generic operations on the VCAP TCAM, so that VCAP IS1 and ES0 can reuse the same code without confusion. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20net: mscc: ocelot: move net_device related functions to ocelot_net.cVladimir Oltean10-1159/+1151
The ocelot hardware library shouldn't contain too much net_device specific code, since it is shared with DSA which abstracts that structure away. So much as much of this code as possible into the mscc_ocelot driver and outside of the common library. We're making an exception for MDB and LAG code. That is not yet exported to DSA, but when it will, most of the code that's already in ocelot.c will remain there. So, there's no point in moving code to ocelot_net.c just to move it back later. We could have moved all net_device code to ocelot_vsc7514.c directly, but let's operate under the assumption that if a new switchdev ocelot driver gets added, it'll define its SoC-specific stuff in a new ocelot_vsc*.c file and it'll reuse the rest of the code. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-06-20net: mscc: ocelot: move ocelot_regs.c into ocelot_vsc7514.cVladimir Oltean4-452/+442
ocelot_regs.c actually shouldn't be part of the common library. It describes the register map of the VSC7514 switch. The way ocelot switches work, they'll have highly optimized register maps, so another SoC will likely have the same registers but laid out completely different in memory (so there's little room for reusing this structure). So move it to ocelot_vsc7514.c instead. Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-31 01:14:54 +0000