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
