[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <651ef153-7555-4ae1-a068-cbe5f0da7e34@lunn.ch>
Date: Tue, 25 Apr 2023 05:20:35 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Daniel Golle <daniel@...rotopia.org>,
Heiner Kallweit <hkallweit1@...il.com>, netdev@...r.kernel.org,
linux-mediatek@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Paolo Abeni <pabeni@...hat.com>,
Qingfang Deng <dqfext@...il.com>,
SkyLake Huang <SkyLake.Huang@...iatek.com>,
Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com>
Subject: Re: [PATCH v2] net: phy: add driver for MediaTek SoC built-in GE PHYs
On Mon, Apr 24, 2023 at 06:37:55PM -0700, Jakub Kicinski wrote:
> On Sat, 22 Apr 2023 13:36:58 +0100 Daniel Golle wrote:
> > Some of MediaTek's Filogic SoCs come with built-in gigabit Ethernet
> > PHYs which require calibration data from the SoC's efuse.
> > Despite the similar design the driver doesn't share any code with the
> > existing mediatek-ge.c, so add support for these PHYs by introducing a
> > new driver for only MediaTek's ARM64 SoCs.
>
> Andrew, Heiner, how do you feel about this driver?
It is 95% magic values in magic registers which nobody is every going
to understand without the datasheet. Assuming any of it is actually in
the data sheet. I really think the firmware in this PHY needs a
re-write to avoid exposing all this to the OS. But i don't know if we
have that level of NACK. Having said that, there is a nice quote in
LWN from Thomas Gleixer about this:
https://lwn.net/Articles/928946/
This does seem like a case of 'throw hardware/firmware over the fence
and let software folks deal with it.' There is no other PHY like it in
Linux. So i would like to reject it, but i then suspect we are
punishing the wrong people, Daniel not MediaTek.
I would also drop the LED configuration parts. Leave it at reset
defaults for the moment. It seems like the generic support for
controlling PHY LEDs is making progress and will be merged next cycle.
Andrew
Powered by blists - more mailing lists