[U-Boot, v2, 1/1] net: phy: Add the Airoha EN8811H PHY driver

[Marek Vasut]

On 6/29/25 6:10 PM, Lucien.Jheng wrote:

Hi,

I'm sorry for my abysmally slow response.

>>> +config PHY_AIROHA_FW_IN_MMC
>>> +    bool "Airoha firmware in MMC partition"
>>> +    help
>>> +      Airoha PHYs use firmware which can be loaded automatically
>>> +      from storage directly attached to the PHY, and then loaded
>>> +      via MDIO commands by the boot loader. The firmware is loaded
>>> +      from a file specified by the PHY_AIROHA_FW_PART,
>>> +      PHY_AIROHA_FW_DM_FILEPATH and PHY_AIROHA_FW_DSP_FILEPATH options.
>> I ran into the same firmware loading problem recently. I took a 
>> different approach, have a look at [1] and specifically function 
>> rcar_gen4_pcie_load_firmware() . This invokes U-Boot shell script , 
>> which has to be defined by the user, and which loads the firmware by 
>> whatever means necessary, from whatever storage or location . I think 
>> that might be the generic approach to U-Boot firmware loading . If the 
>> user needs to change the firmware loading location, they do not need 
>> to rebuild the U-Boot itself, they simply update their environment and 
>> the matching script. What do you think ?
>>
>> [1] https://patchwork.ozlabs.org/project/uboot/ 
>> patch/20250617081641.8385-5-marek.vasut+renesas at mailbox.org/
> 
> Hi Marek
> 
> I've looked at the `rcar_gen4_pcie_load_firmware` API. As you mentioned, 
> it allows users to set the storage and location from the U-Boot shell, 
> meaning they don't need to recompile U-Boot.

Yes, that's the goal there.

> However, I recently checked out `FS_LOADER` and realized it's 
> essentially the same approach as how I'm currently placing firmware on 
> eMMC, just with a unified API(request_firmware_into_buf).
> 
> I'm wondering if there's a future possibility to integrate U-Boot shell 
> scripts into `FS_LOADER`?

I think it would be ideal to have one unified firmware loading code, so 
the answer to the "if" part of the question is "yes".

I have yet to think about the "how" part. If you want to give it a try, 
please do.

> Also, given that the Kernel has a built-in firmware mechanism where 
> files are compiled directly into the Kernel image, I'm curious if U-Boot 
> might adopt a similar approach in the future. I'm also considering if 
> `binman_sym` could be a viable alternative.

I'm not a lawyer. My understanding of this firmware bundling is, that 
this is a legal minefield which is better avoided, and also causes 
redistribution problems with prebuilt U-boot binaries. You end up 
bundling together GPL code (U-Boot) and non-GPL code (firmware blobs), 
and the final license of the result is unclear to me.

+CC Vagrant, since they have insight into this from Debian side.

> For the short term, though, I'll go ahead and submit the EN8811H 
> firmware loading method using the `rcar_gen4_pcie_load_firmware` 
> approach. I'll then explore potential improvements later.
Please wait a bit for input from the others. Also keep in mind, that 
rcar_gen4_pcie_load_firmware() is non-generic interface specific to that 
one driver, you would have to implement something similar in this driver 
, with different variable names .