On 09/23/2016 10:36 AM, Tim Harvey wrote: > On Fri, Sep 23, 2016 at 9:29 AM, Florian Fainelli <f.faine...@gmail.com> > wrote: >> On 09/23/2016 08:40 AM, Tim Harvey wrote: >>> Greetings, >>> >>> I've got a TI DP83867 GbE phy that requires some register writes to >>> configure its refclock output. Is there a generic device-tree API for >>> writing to raw registers or is that something that would be need to be >>> added to a specific phy driver with a device-tree binding? >> >> There are no standard properties that indicate how to write to register >> from Device Tree (unfortunately there are non standard that allow this >> to happen, e.g: marvell,reg-init), because that would mean that Device >> Tree acts as some kind of firmware/binary interface, which is a bit of >> stretch. Some bindings may indicate how to write to registers in a way >> that accepts a address = value pair, but quite frankly, this is >> absolutely horrible and not controllable nor easily transferable from >> one model of device to the other, strongly discouraged. >> >>> There is a >>> DP83867 phy driver but it doesn't contain anything related to >>> configuring its CLKOUT via register 0x170. >> >> Then, I guess you should add a set of properties and corresponding code >> reading these properties that would result in getting the register >> programmed with the values you need. >> > > Florian, > > agreed - this seems like the right thing to do and takes care of the > important detail about power-management you mention below. > > Are there any phy drivers you know of that do and CLKOUT configuration > that I could use as inspiration for dt prop names?
The micrel binding has some clock related configuration: Documentation/devicetree/bindings/net/micrel.txt could be used as an inspirational source ;) > > Thanks, > > Tim > >>> >>> Alternatively, is it generally considered 'ok' to take care of this in >>> the bootloader and not provide the MAC driver the gpio for phy-reset >>> so that bootloader configuration persists through the kernel? >> >> It depends on what your platform does, punting on the bootloader is >> usually fine, but also breaks nicely when you start implementing power >> management in the kernel properly (e.g: deep sleep states) and you are >> not calling back into the bootloader, yet your hardware lost its state >> between power transitions. >> >> -- >> Florian -- Florian
