- 22 Jun, 2020 40 commits
-
-
Maxim Kochetkov authored
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>
-
Maxim Kochetkov authored
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>
-
Maxim Kochetkov authored
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>
-
David S. Miller authored
Heiner Kallweit says: ==================== r8169: mark device as detached in PCI D3 and improve locking Mark the netdevice as detached whenever parent is in PCI D3hot and not accessible. This mainly applies to runtime-suspend state. In addition take RTNL lock in suspend calls, this allows to remove the driver-specific mutex and improve PM callbacks in general. ==================== Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Heiner Kallweit authored
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>
-
Heiner Kallweit authored
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>
-
Heiner Kallweit authored
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>
-
Heiner Kallweit authored
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>
-
Heiner Kallweit authored
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>
-
Heiner Kallweit authored
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>
-
Heiner Kallweit authored
A netdevice may be marked as detached because the parent is runtime-suspended and not accessible whilst interface or link is down. An example are PCI network devices that go into PCI D3hot, see e.g. __igc_shutdown() or rtl8169_net_suspend(). If netdevice is down and marked as detached we can only open it if we runtime-resume it before __dev_open() calls netif_device_present(). Therefore, if netdevice is detached, try to runtime-resume the parent and only return with an error if it's still detached. Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Martin Blumenstingl says: ==================== prepare dwmac-meson8b for G12A specific initialization Some users are reporting that RGMII (and sometimes also RMII) Ethernet is not working for them on G12A/G12B/SM1 boards. Upon closer inspection of the vendor code for these SoCs new register bits are found. It's not clear yet how these registers work. Add a new compatible string as the first preparation step to improve Ethernet support on these SoCs. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Martin Blumenstingl authored
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>
-
Martin Blumenstingl authored
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 compatible string for G12A and newer so the new registers can be used. Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
David S. Miller authored
Vasundhara Volam says: ==================== devlink: Add board.serial_number field to info_get cb. This patchset adds support for board.serial_number to devlink info_get cb and also use it in bnxt_en driver. Sample output: $ devlink dev info pci/0000:af:00.1 pci/0000:af:00.1: driver bnxt_en serial_number 00-10-18-FF-FE-AD-1A-00 board.serial_number 433551F+172300000 versions: fixed: board.id 7339763 Rev 0. asic.id 16D7 asic.rev 1 running: fw 216.1.216.0 fw.psid 0.0.0 fw.mgmt 216.1.192.0 fw.mgmt.api 1.10.1 fw.ncsi 0.0.0.0 fw.roce 216.1.16.0 v2: - Modify board_serial_number to board.serial_number for maintaining consistency. - Combine 2 lines in second patchset as column limit is 100 now ==================== Reviewed-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vasundhara Volam authored
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>
-
Vasundhara Volam authored
Board serial number is a serial number, often available in PCI *Vital Product Data*. Also, update devlink-info.rst documentation file. 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>
-
David S. Miller authored
Vladimir Oltean says: ==================== Cosmetic cleanup in SJA1105 DSA driver This removes the sparse warnings from the sja1105 driver and makes some structures constant. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Vladimir Oltean authored
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>
-
Vladimir Oltean authored
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>
-
Vladimir Oltean authored
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>
-
David S. Miller authored
Jonathan McDowell says: ==================== net: dsa: qca8k: Improve SGMII interface handling This 3 patch series migrates the qca8k switch driver over to PHYLINK, and then adds the SGMII clean-ups (i.e. the missing initialisation) on top of that as a second patch. The final patch is a simple spelling fix in a comment. As before, 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. v5: - Move spelling fix to separate patch - Use ds directly rather than ds->priv v4: - Enable pcs_poll so we keep phylink updated when doing in-band negotiation - Explicitly check for PHY_INTERFACE_MODE_1000BASEX when setting SGMII port mode. - Address Vladimir's review comments v3: - Move phylink changes to separate patch - Address rmk review comments v2: - Switch to phylink - Avoid need for device tree configuration options ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jonathan McDowell authored
Signed-off-by: Jonathan McDowell <noodles@earth.li> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jonathan McDowell authored
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>
-
Jonathan McDowell authored
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>
-
David S. Miller authored
Jarod Wilson says: ==================== bonding: initial support for hardware crypto offload This is an initial functional implementation for doing pass-through of hardware encryption from bonding device to capable slaves, in active-backup bond setups. This was developed and tested using ixgbe-driven Intel x520 interfaces with libreswan and a transport mode connection, primarily using netperf, with assorted connection failures forced during transmission. The failover works quite well in my testing, and overall performance is right on par with offload when running on a bare interface, no bond involved. Caveats: this is ONLY enabled for active-backup, because I'm not sure how one would manage multiple offload handles for different devices all running at the same time in the same xfrm, and it relies on some minor changes to both the xfrm code and slave device driver code to get things to behave, and I don't have immediate access to any other hardware that could function similarly, but the NIC driver changes are minimal and straight-forward enough that I've included what I think ought to be enough for mlx5 devices too. v2: reordered patches, switched (back) to using CONFIG_XFRM_OFFLOAD to wrap the code additions and wrapped overlooked additions. v3: rebase w/net-next open, add proper cc list to cover letter ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Jarod Wilson authored
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>
-
Jarod Wilson authored
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>
-
Jarod Wilson authored
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>
-
Jarod Wilson authored
This is prep work for initial support of bonding hardware encryption pass-through support. The bonding driver will fill in the slave_dev pointer, and we use that to know not to skb_push() again on a given skb that was already processed on the bond device. 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>
-
David S. Miller authored
Parav Pandit says: ==================== devlink: Support get,set mac address of a port function Currently, ip link set dev <pfndev> vf <vf_num> <param> <value> has below few limitations. 1. Command is limited to set VF parameters only. It cannot set the default MAC address for the PCI PF. 2. It can be set only on system where PCI SR-IOV capability exists. In smartnic based system, eswitch of a NIC resides on a different embedded cpu which has the VF and PF representors for the SR-IOV functions of a host system in which this smartnic is plugged-in. 3. It cannot setup the function attributes of sub-function described in detail in comprehensive RFC [1] and [2]. This series covers the first small part to let user query and set MAC address (hardware address) of a PCI PF/VF which is represented by devlink port pcipf, pcivf port flavours respectively. Whenever a devlink port manages a function connected to a devlink port, it allows to query and set its hardware address. Driver implements necessary get/set callback functions if it supports port function for a given port type. Patch summary: Patch-1 Prepares devlink port fill routines for extack Patch-2 and 3 extended devlink interface to get/set port function attributes, mainly hardware address to start with. Patch-2 Extended port dump command to query port function hardware address Patch-3 Introduces a command to set the hardware address of a port function Patch-4 to 9 refactors and implement devlink callbacks in mlx5_core driver. Patch-4 Constify the mac address pointer in set routines Patch-5 Introduces eswich check helper to use in devlink facing callbacks Patch-6 Moves port index, port number conversion routine to eswitch header file Patch-7 Implements port function query devlink callback Patch-8 Refactors mac address setting routine to uniformly use state_lock Patch-9 Implements port function set devlink callback [1] https://lore.kernel.org/netdev/20200519092258.GF4655@nanopsycho/ [2] https://marc.info/?l=linux-netdev&m=158555928517777&w=2 ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
-
Parav Pandit authored
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>
-
Parav Pandit authored
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>
-
Parav Pandit authored
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>
-
Parav Pandit authored
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>
-
Parav Pandit authored
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>
-
Parav Pandit authored
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>
-
Parav Pandit authored
PCI PF and VF devlink port can manage the function represented by a devlink port. Allow users to set port function's hardware address. Example of a PCI VF port which supports a port function: $ devlink port show pci/0000:06:00.0/2 pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1 function: hw_addr 00:00:00:00:00:00 $ devlink port function set pci/0000:06:00.0/2 hw_addr 00:11:22:33:44:55 $ devlink port show pci/0000:06:00.0/2 pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1 function: hw_addr 00:11:22:33:44:55 Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Parav Pandit authored
PCI PF and VF devlink port can manage the function represented by a devlink port. Enable users to query port function's hardware address. Example of a PCI VF port which supports a port function: $ devlink port show pci/0000:06:00.0/2 pci/0000:06:00.0/2: type eth netdev enp6s0pf0vf1 flavour pcivf pfnum 0 vfnum 1 function: hw_addr 00:11:22:33:44:66 $ devlink port show pci/0000:06:00.0/2 -jp { "port": { "pci/0000:06:00.0/2": { "type": "eth", "netdev": "enp6s0pf0vf1", "flavour": "pcivf", "pfnum": 0, "vfnum": 1, "function": { "hw_addr": "00:11:22:33:44:66" } } } } Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-
Parav Pandit authored
Prepare devlink port related functions to optionally fill up the extack information which will be used in subsequent patch by port function attribute(s). Signed-off-by: Parav Pandit <parav@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
-