lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <56227e76-f01f-4b90-b325-1cd9ecb8d5a3@lunn.ch> Date: Thu, 5 Oct 2023 04:43:51 +0200 From: Andrew Lunn <andrew@...n.ch> To: Jakub Kicinski <kuba@...nel.org> Cc: Robert Marko <robimarko@...il.com>, hkallweit1@...il.com, linux@...linux.org.uk, davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com, netdev@...r.kernel.org, linux-kernel@...r.kernel.org, Christian Marangi <ansuelsmth@...il.com>, Luis Chamberlain <mcgrof@...nel.org>, devicetree@...r.kernel.org Subject: Re: [RFC PATCH net-next] net: phy: aquantia: add firmware load support On Wed, Oct 04, 2023 at 04:28:31PM -0700, Jakub Kicinski wrote: > On Sat, 30 Sep 2023 12:39:44 +0200 Robert Marko wrote: > > + ret = of_property_read_string(dev->of_node, "firmware-name", > > + &fw_name); > > Perhaps a well established weirdness of the embedded world but why read > the fw name from OF?! You can identify what PHY it is and decide the > file name based on that. And also put that fw name in MODULE_FIRMWARE() > so that initramfs can be built with appropriate file in place :S The Aquantia PHY and its `firmware` is just weird. It is more than just firmware, it also contains what i think they call provisioning. That is basically the reset defaults for registers. And not everything is documented, and i think parts of that provision contains SERDES eye configuration. So i think you end up with a custom firmware per board? And you can never trust the firmware in one device will do the same thing as a different firmware in another device, because the reset defaults are a bit fuzzy. The PHY driver is somewhat built on sand, since you cannot really trust any register to have any specific reset value. So i can understand putting the board specific firmware name in DT, and that the firmware will never be in linux-firmware because it would not scale, and there never being one firmware usable for all boards. And this odd way of doing things means the usual mechanisms for getting the firmware in initramfs does not work. I suppose the question is, do we want to say this is all too ugly for Linux, solve it in the bootloader, or spend the extra $0.50 for a flash chip and put the firmware in at the factory. As a kernel developer i would want the boot loader to solve this, so i can TFTP boot the kernel. I would also like having a rescue mechanism for when i brick Linux on the box and need to boot a Debian install image to recover it. Andrew
Powered by blists - more mailing lists