[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <65cb9118.050a0220.8421f.c47a@mx.google.com>
Date: Tue, 13 Feb 2024 16:56:04 +0100
From: Christian Marangi <ansuelsmth@...il.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Heiner Kallweit <hkallweit1@...il.com>,
Russell King <linux@...linux.org.uk>,
"David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
"Russell King (Oracle)" <rmk+kernel@...linux.org.uk>,
Robert Marko <robimarko@...il.com>, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [net-next PATCH] net: phy: aquantia: add AQR111 and AQR111B0 PHY
ID
On Tue, Feb 13, 2024 at 04:46:47PM +0100, Andrew Lunn wrote:
> > With the amount of things we are noticing on these PHY it can be
> > anything from Marvell itself, from OEM messing up with the Provision to
> > a buf in the FW itself...
>
> Ideally, we want to get Marvell to release one universal firmware for
> each PHY. Get the OEM out of the picture. This is something i said to
> then Aquantia years ago, that provisioning is going to make driver
> support a real problem. Seems like i predicted it correctly :-(
>
I can totally see them answer to this request with:
OEM should just attach a SPI to the PHY if major modification are
needed, making us (Marvell) releasing an universal firmware irrelevant
since it should be handled internally by the Aquantia PHY.
Reality is that on Router or more Consumer devices where OEM try to cut
cost everywhere, FW are getting placed on NAND partition or even part of
the OEM FW and then userspace tools are used to setup and load the
Aquantia PHY FW.
This cause the side effect of OEM building one Aquantia PHY FW and then
fixing the Provision data at runtime making all the idea of Marvell to
include these configuration values in the FW broken. (example OEM build
one Aquantia PHY FW for all kind of PHY ID and then apply specific
fixup to setup 10base-r or uxsgmii based on what is actually present on
the board on the MAC side) (yes the PHY can support both and there is a
way to tweak this... this is actually required on AQR112 and other
version that we currently don't support, ideally it should be handled by
the FW internally but reality is that we have case where the FW
provision one mode and the other is actually present in the system)
--
Ansuel
Powered by blists - more mailing lists