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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 23 Sep 2016 10:40:12 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Tim Harvey <tharvey@...eworks.com>
Cc:     netdev <netdev@...r.kernel.org>
Subject: 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 <f.fainelli@...il.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