[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Zqyau+JjwQdzBNaI@shell.armlinux.org.uk>
Date: Fri, 2 Aug 2024 09:37:15 +0100
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Ronnie.Kunin@...rochip.com
Cc: Raju.Lakkaraju@...rochip.com, netdev@...r.kernel.org,
davem@...emloft.net, kuba@...nel.org, andrew@...n.ch,
horms@...nel.org, hkallweit1@...il.com, richardcochran@...il.com,
rdunlap@...radead.org, Bryan.Whitehead@...rochip.com,
edumazet@...gle.com, pabeni@...hat.com,
linux-kernel@...r.kernel.org, UNGLinuxDriver@...rochip.com
Subject: Re: [PATCH net-next V3 3/4] net: lan743x: Migrate phylib to phylink
On Thu, Aug 01, 2024 at 11:46:41PM +0000, Ronnie.Kunin@...rochip.com wrote:
> Hi Russell,
> Raju can comment more on it when he comes online tomorrow (IST time), but I recall this was discussed with you last year and my understanding is that the outcome was that as long as the need to use the dynamic fallback from phy to fixed_phy mode is explained in the commit message - which Raju did in the commit description - , it was acceptable to do this in phylink. Unless the "mechanism where a MAC driver can tell phylink to switch to using a fixed-link with certain parameters" has been implemented since then (apologize if it has, I am not a linux expert by any means, but don't seem to see it), I would guess the reasons for doing this are still valid.
>
> Attached is the email thread with that discussion and the relevant comments are copied below.
>
> > The reason this should work is because the fixed-phy support does emulate a real PHY in software, and phylink will treat that exactly the same way as a real PHY (because when in phylink is in PHY mode, it delegates PHY management to phylib.)
> >
> >Using fixed-phy with phylink will certainly raise some eyebrows, so the reasons for it will need to be set out in the commit message - and as you've dropped Andrew from this thread, I suspect he will still raise some comments about it.
> >
> >In the longer term, it would probably make sense for phylink to provide a mechanism where a MAC driver can tell phylink to switch to using a fixed-link with certain parameters.
Note the last two paragraphs...
What I never understand is why many software engineers working on Linux
are focused purely on the driver code and seem to have a complete
aversion to touching/improving anything outside of their driver,
prefering instead to come up with hacks.
Given that what you quote from me was from 26th September, I have to
wonder what you would define as "longer term" as we're 10 months on
from that statement.
I think it's time to implement the suggestion in the last paragraph
rather than using fixed-phy.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists