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

[Marek Vasut <marek.vasut@mailbox.org>]

On 11/2/25 5:57 AM, Beiyan Yun wrote:

Hi,

>>>>>> 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.
>>
>> See example above, you can read anything from the U-Boot control DT both in U-Boot shell and in U-Boot env scripts, using 'fdt' command .
>>
> 
> To make sure I understand the preferred architecture: are you suggesting that FW_LOADER is the preferred method, and that all the logic for finding, mounting, and reading from storage should be handled by board-specific scripts that parse the DT using fdt?
> 
> My main objective with FS_LOADER was to provide a "zero-script" default for most common use case. While scripting is powerful, it seems beneficial to have a C-based driver that can natively read from a filesystem described by a standard DT binding, rather than requiring every board to script the same "find-and-mount" logic.

Maybe the scripts can be made common, similar to what distro bootcommand 
did ?

The upside of doing the loading in a script is, that it allows users to 
tweak the scripts without rebuilding and updating the bootloader, which 
may be beneficial in case they need to load firmware from a device which 
was not considered when the bootloader was built.

> Am I overlooking al drawback to that C-based approach, or perhaps missing some prior discussion on this?

See above.

-- 
Best regards,
Marek Vasut