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] [thread-next>] [day] [month] [year] [list]

Message-ID: <6acbbdca-d492-2efb-a0da-bd23d38085f8@gmail.com>
Date:   Fri, 23 Sep 2016 09:29:01 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Tim Harvey <tharvey@...eworks.com>, netdev <netdev@...r.kernel.org>
Subject: Re: device-tree support for writing to phy registers?

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.

> 
> 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