Re: [PATCH 0/3] net: phy: initialize PHYs via device tree properties

From: Florian Fainelli
Date: Tue Oct 29 2019 - 16:59:14 EST


On 10/29/19 1:54 PM, Michael Walle wrote:
> Am 29. Oktober 2019 18:59:07 MEZ schrieb Florian Fainelli <f.fainelli@xxxxxxxxx>:
>> On 10/29/19 10:48 AM, Michael Walle wrote:
>>> I was trying to configure the Atheros PHY for my board. There are
>> fixups
>>> all over the place, for example to enable the 125MHz clock output in
>> almost
>>> any i.MX architecture. Instead of adding another fixup in
>> architecture
>>> specific code, try to provide a generic way to init the PHY
>> registers.
>>>
>>> This patch series tries to pick up the "broadcom,reg-init" and
>>> "marvell,reg-init" device tree properties idea and make it a more
>> generic
>>> "reg-init" which is handled by phy_device instead of a particular phy
>>> driver.
>>
>> These two examples are actually quite bad and were symptomatic of a few
>> things at the time:
>>
>> - rush to get a specific feature/device supported without thinking
>> about
>> the big picture
>> - lack of appropriate review on the Device Tree bindings
>>
>> Fortunately, the last item is now not happening anymore.
>>
>> The problem with letting that approach go through is that the Device
>> Tree can now hold a configuration policy which is passed through as-is
>>from DT to the PHY device, this is bad on so many different levels,
>> starting with abstraction.
>
> I see.
>
>> If all you need is to enable a particular clock, introduce device
>> specific properties that describe the hardware, and make the necessary
>> change to the local driver that needs to act on those. You can always
>> define a more generic scope property if you see a recurring pattern.
>
> Could you have a quick look at the following patch I made for u-boot, which adds a binding for the Atheros PHY. If that is the right direction. Yeah, I should have made it first to Linux to get some feedback on the binding :p
>
> https://patchwork.ozlabs.org/patch/1184516/
>
> I'd then prepare another patch for Linux based on your suggestions.

This looks like the right direction IMHO.
--
Florian