netdev - Re: [PATCH net-next v9 0/6] add ethernet driver for Tehuti Networks TN40xx chips

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sun, 9 Jun 2024 14:40:03 +0200
From: Hans-Frieder Vogt <hfdevel@....net>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>, netdev@...r.kernel.org,
 andrew@...n.ch, horms@...nel.org, kuba@...nel.org, jiri@...nulli.us,
 pabeni@...hat.com, naveenm@...vell.com, jdamato@...tly.com
Subject: Re: [PATCH net-next v9 0/6] add ethernet driver for Tehuti Networks
 TN40xx chips

On 09.06.2024 12.42, Russell King (Oracle) wrote:
> On Sun, Jun 09, 2024 at 11:10:54AM +0200, Hans-Frieder Vogt wrote:
>> I have also tested your driver, however since I have 10GBASE-T cards
>> with x3310 and aqr105 phys I had to add a few lines (very few!) to make
>> them work. Therefore, formally I cannot claim to have tested exactly
>> your patches.
>> Once your driver is out, I will post patches for supporting the other phys.
>> Thanks for taking the effort of mainlining this driver!
> Still, it would be useful to know what those changes were, even if they
> aren't formal patches.
>
> Thanks.
>
Sure. So, here, for info (and later addition to the driver), small
adjustments needed in the tn40 driver to support cards with Marvell
88X3310 and Aquantia/Marvell AQR105:

First the trivial change (I just also added also the e2010 phy, because
it seems to have a lot of commonality with the x3310, but I don't have a
card with this phy, so it is atm just speculation. Same applies to the
Promise card):

in tn40.c:

@@ -1752,6 +1754,10 @@ static const struct pci_device_id tn40_i
               PCI_VENDOR_ID_ASUSTEK, 0x8709) },
      { PCI_DEVICE_SUB(PCI_VENDOR_ID_TEHUTI, 0x4022,
               PCI_VENDOR_ID_EDIMAX, 0x8103) },
+    { PCI_VDEVICE(TEHUTI, 0x4025), 0 }, /* AQR105 */
+    { PCI_VDEVICE(TEHUTI, 0x4027), 0 }, /* MV88X3310 */
+    { PCI_VDEVICE(TEHUTI, 0x4527), 0 }, /* MV88E2010 */
+    { PCI_VDEVICE(PROMISE, 0x7203), 0 }, /* AQR105 */
      { }
  };

then the AQR105 seems to need the MDIO bus set at 1MHz to allow for
detection:

@@ -1681,6 +1681,8 @@ static int tn40_probe(struct pci_dev *pd
          goto err_unset_drvdata;
      }

+    tn40_mdio_set_speed(priv, TN40_MDIO_SPEED_1MHZ);
+
      ret = tn40_mdiobus_init(priv);
      if (ret) {
          dev_err(&pdev->dev, "failed to initialize mdio bus.\n");

This is not needed for the x3310 and may be related to, that the AQR105
is connected to phy address 1 on my card. Strange enough the
manufacturer's offline driver seems not to need this (but there the
sequence of initialization is also different, so it is likely due to
this reason).
Note: having set the speed to 1MHz here does NOT allow to skip the
similar call in tn40_priv_init, because BIT(3) seems to be lost on the
way, but is needed for the AQR phy to finish probing, but not for the
x3310 (don't really understand this).

On the other hand, the x3310 requires to add XAUI to host_interfaces.
Otherwise it will not switch to this interface on its own. So, adding
this to tn40_phy.c.

--- a/drivers/net/ethernet/tehuti/tn40_phy.c    2024-06-06
06:43:40.865474664 +0200
+++ b/drivers/net/ethernet/tehuti/tn40_phy.c    2024-06-06
18:57:01.978776712 +0200
@@ -54,6 +54,8 @@ int tn40_phy_register(struct tn40_priv *
                 return -1;
         }

+       __set_bit(PHY_INTERFACE_MODE_XAUI, phydev->host_interfaces);
+
         config = &priv->phylink_config;
         config->dev = &priv->ndev->dev;
         config->type = PHYLINK_NETDEV;

I have to mention, though, that the phy-drivers for x3310 and aqr105 are
not yet ready and will also need some changes related to the firmware
loading, because for most (all?) of the Tehuti-based cards the phy
firmware has to be uploaded via MDIO.

For AQR phys there is already support for firmware loading in the
driver. However, this is so far only working for systems using
device-tree. A few rather trivial changes (sorry, I know I should have
posted them already) will sort this. Further to this I have
"switched-on" some features coming from AQR107. I need to investigate
whether they are essential for operation.

For x3310 the patch provided by Tobias Waldekranz (or a similar patch
posted some year or two ago) will be needed for firmware-uploading.

I'll prepare a patch for the AQR105. Then we have at least one BASE-T
card fully supported.