[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c124efe0-0b2e-4d8e-b16c-8a8afd0814c1@gmx.net>
Date: Sun, 9 Jun 2024 20:42:42 +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 15.48, Russell King (Oracle) wrote:
> On Sun, Jun 09, 2024 at 02:40:03PM +0200, Hans-Frieder Vogt wrote:
>> --- 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;
> This shouldn't be done - host_interfaces is really only for SFPs, and
> it suggests that the 88x3310 isn't properly configured with pinstrapping
> for the correct MAC type (which determines the interface mode to be used
> to communicate with the MAC.)
I already wondered why host_interfaces was only used in the 88x3310, but
not in the aqr105 phy driver. Makes sense because the 88x3310 supports
both directly BASE-T and an SFP+ cage.
>
> I'm not sure what to suggest here, other than further debug (e.g. what
> interface mode is the 88x3310 trying to use without this?)
The message is:
tn40xx 0000:10:00.0 enp16s0: PHY has no common interfaces
tn40xx 0000:10:00.0 enp16s0: validation of xaui with support
00,00000000,00018000,0000706f and advertisement
00,00000000,00018000,0000706f failed: -22
You are probably right that the interfaceis not properly pinstrapped.
bits 2:0 in 1f.f001 are initially 0, which means RXAUI, and the vendor
driver just forces the bits to 1 (XAUI with rate matching). Maybe it is
a quirk (or a design flaw of the Tehuti reference card). Just a thought:
if it cannot be autodetected then maybe the simplest solution is adding
a module parameter.
>> 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.
> That's problematical - as I understand it, the 88x3310 firmware at least
> is not freely redistributable (we've run into this with other
> platforms that do not program the SPI flash attached to the 88x3310
> and been told my Marvell that the firmware can't be made available as
> part of e.g. linux-firmware.)
>
> So quite what we do with the 88x3310 based boards that don't have
> firmware, I'm not sure, but it seems given the non-distributable
> firmware issue, that's going to be hard.
>
I followed this discussion, but was hoping that the situation would change.
I think I will give the card with AQR105 phy priority, assuming that the
firmware topic is easier to solve for the Aquantia line of Marvell products.
Thanks, Russel!
BR, Hans
Powered by blists - more mailing lists