[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <39660d10-69b9-fa52-5a49-67d5f7e1acaf@seco.com>
Date: Thu, 5 Jan 2023 13:03:49 -0500
From: Sean Anderson <sean.anderson@...o.com>
To: Vladimir Oltean <olteanv@...il.com>
Cc: Andrew Lunn <andrew@...n.ch>,
Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
Russell King <linux@...linux.org.uk>,
"David S . Miller" <davem@...emloft.net>,
Paolo Abeni <pabeni@...hat.com>, linux-kernel@...r.kernel.org,
Jakub Kicinski <kuba@...nel.org>,
Eric Dumazet <edumazet@...gle.com>,
Tim Harvey <tharvey@...eworks.com>
Subject: Re: [PATCH net-next v5 4/4] phy: aquantia: Determine rate adaptation
support from registers
On 1/5/23 12:55, Vladimir Oltean wrote:
> On Thu, Jan 05, 2023 at 07:52:06PM +0200, Vladimir Oltean wrote:
>> On Thu, Jan 05, 2023 at 12:43:47PM -0500, Sean Anderson wrote:
>> > Again, this is to comply with the existing API assumptions. The current
>> > code is buggy. Of course, another way around this is to modify the API.
>> > I have chosen this route because I don't have a situation like you
>> > described. But if support for that is important to you, I encourage you
>> > to refactor things.
>>
>> I don't think I'm aware of a practical situation like that either.
>> I remember seeing some S32G boards with Aquantia PHYs which use 2500BASE-X
>> for 2.5G and SGMII for <=1G, but that's about it in terms of protocol switching.
>> As for Layerscape boards, SERDES protocol switching is a very new concept there,
>> so they're all going to be provisioned for PAUSE all the way down
>> (or USXGMII, where that is available).
>>
>> I just pointed this out because it jumped out to me. I don't have
>> something against this patch getting accepted as it is.
>
> A real-life (albeit niche) scenario where someone might have an Aquantia
> firmware provisioned like this would be a 10G capable port that also
> wants to support half duplex at 10/100 speeds. Although I'm not quite
> sure who cares about half duplex all that much these days.
IMO if we really want to support this, the easier way would be to teach
the phy driver how to change the rate adaptation mode. That way we could
always advertise rate adaptation, but if someone came along and
requested 10HD we could reconfigure the phy to support it. However, this
was deemed too risky in the discussion for v1, since we don't really
know how the firmware interacts with the registers.
--Sean
Powered by blists - more mailing lists