[PATCH v4 5/5] net: phy: aquantia: use generic firmware loader

[Beiyan Yun]

> On 1 Nov 2025, at 12:51 AM, Marek Vasut <marek.vasut at mailbox.org> wrote:
> 
> On 10/31/25 5:34 PM, Beiyan Yun wrote:
>>> On 31 Oct 2025, at 11:57 PM, Marek Vasut <marek.vasut at mailbox.org> wrote:
>>> 
>>> On 10/31/25 4:21 PM, Beiyan Yun wrote:
>>>> Aquantia PHYs are being used w/o SPI flash in some routers recently.
>>>> Current firmware loader only attempts to load from FS on top of MMC,
>>>> limiting the use on many devices.
>>>> Removed the old firmware loader, migrate to generic firmware loader to
>>>> allow a wider range and runtime override of firmware source. (e.g., USB).
>>>> Tested on Buffalo WXR18000BE10P with UBIFS.
>>>> Signed-off-by: Beiyan Yun <root at infi.wang>
>>>> ---
>>>> Changes in v4:
>>>> - Split firmware upload helpers change
>>>> - Reorder `aquantia_read_fw`
>>>> - Make `aquantia_read_fw` weak to allow overide
>>>> - Rename exit label in `aquantia_read_fw`
>>>> - Kconfig polish
>>>> Changes in v3:
>>>> - Select FW_LOADER with PHY_AQUANTIA_UPLOAD_FW
>>>> Changes in v2:
>>>> - Add support for script based loader
>>>>  drivers/net/phy/Kconfig    |  28 +++++----
>>>>  drivers/net/phy/aquantia.c | 122 ++++++++++++++++++++++---------------
>>>>  2 files changed, 91 insertions(+), 59 deletions(-)
>>>> diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
>>>> index 018be98705a..4a74a0d4e8c 100644
>>>> --- a/drivers/net/phy/Kconfig
>>>> +++ b/drivers/net/phy/Kconfig
>>>> @@ -1,4 +1,3 @@
>>>> -
>>>>  config BITBANGMII
>>>>  	bool "Bit-banged ethernet MII management channel support"
>>>>  @@ -91,23 +90,30 @@ menuconfig PHY_AQUANTIA
>>>>  config PHY_AQUANTIA_UPLOAD_FW
>>>>  	bool "Aquantia firmware loading support"
>>>>  	depends on PHY_AQUANTIA
>>>> +	select FS_LOADER
>>>> +	select FW_LOADER
>>> Can you not use the plain FW_LOADER to load the firmware from either storage, UBI or Block ? Is FS_LOADER even needed ?
>> Thanks for the suggestion, and yes you can, but that API is script-only—it expects the board to stage the blob and just copies from the address exposed via *_addr/_size. The current users of this driver expect the old pattern: the bootloader mounts a filesystem (MMC before, now possibly UBI/USB/etc.), reads the firmware, and applies it. Keeping an fs-loader node in the DT is effectively the same contract as the legacy MMC setup, just generalized.
> 
> Can you maybe write a script which implements the old loader behavior in a compatible manner ?
> 
>> The fs_loader driver gives us several things the script path doesn’t: a standard way to describe the storage via "/chosen/firmware-loader"
> 
> Try this:
> 
> "fdt addr $fdtcontroladdr ; fdt print /chosen"
> 
> And then look at the "fdt" command and what it can do regarding reading content of DT properties into variables.
> 
>> , runtime overrides through "storage_interface/fw_dev_part/fw_ubi_*, and no requirement for a board-specific script. So FS_LOADER isn’t redundant—it’s the part that replaces the hard-coded MMC flow with a configurable backend, while the script helper stays available for boards that want extra logic.
> Maybe a more generic script can be a replacement for the older hard-coded approach ?

Fair enough, I’ll remove fsloader for now.

I still believe it would be valuable someday: if reading from nvmem cell is implemented, the same DT could be used for both U-Boot and Linux.

Regards,
Yun