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

[Lucien.Jheng]

Marek Vasut 於 2025/6/30 上午 06:49 寫道:
> On 6/29/25 6:10 PM, Lucien.Jheng wrote:
>
> Hi,
>
> I'm sorry for my abysmally slow response.
>
Thank you very much for your reply and sharing; I've learned a lot.
>>>> +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 .
Okay, I'll wait a bit for feedback from others. Thanks!