Re: device-tree support for writing to phy registers?

On 09/23/2016 10:36 AM, Tim Harvey wrote:

On Fri, Sep 23, 2016 at 9:29 AM, Florian Fainelli [off-list ref] wrote:

quoted

On 09/23/2016 08:40 AM, Tim Harvey wrote:

quoted

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.

quoted

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

quoted

quoted

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