linux-kernel - Re: [PATCH v3 2/2] hwmon: (ltq-cputemp) add devicetree bindings documentation

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: <CAL_Jsq+udc2p_jqQN+m4R69zW=7RBfJCDrQgNXOiMycErP43LQ@mail.gmail.com>
Date:   Wed, 13 Sep 2017 10:25:51 -0500
From:   Rob Herring <robh@...nel.org>
To:     Florian Eckert <fe@....tdt.de>
Cc:     Guenter Roeck <linux@...ck-us.net>,
        Mark Rutland <mark.rutland@....com>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Linux HWMON List <linux-hwmon@...r.kernel.org>,
        Jean Delvare <jdelvare@...e.com>
Subject: Re: [PATCH v3 2/2] hwmon: (ltq-cputemp) add devicetree bindings documentation

On Wed, Sep 13, 2017 at 12:36 AM, Florian Eckert <fe@....tdt.de> wrote:
> Hello Rob
>
>>> > --- /dev/null
>>> > +++ b/Documentation/devicetree/bindings/hwmon/ltq-cputemp.txt
>>> > @@ -0,0 +1,10 @@
>>> > +Lantiq cpu temperatur sensor
>>
>>
>> s/temperatur/temperature/
>
>
> Will update this in a follow up page based on the old one. So no v4?
>
>>
>>> > +
>>> > +Requires node properties:
>>> > +- compatible value :
>>> > +     "lantiq,cputemp"
>>
>>
>> Kind of non-specific. How is this device even accessed without any other
>> property?
>
>
> It does not need any further properties. If this is set in the device tree
> then the driver is loaded.

DT is not the only way to instantiate drivers.

What I meant is how do you access the hardware? That should be evident
from the binding and it is not.

Looking at the driver, you have some memory mapped system control
registers which get ioremapped in arch/mips/lantiq/xway/sysctrl.c and
accesses thru some platform specific macros. That is not the ideal way
to do things as we use syscon and regmap for such things. But that's
all mostly kernel details not so relevant to the DT binding.

For DT, I'd expect this is a child node of the sysctrl block with a
reg property value of <0x40 4> (along with any other child devices).
You could also not even put this in DT and the system controller can
have it's own driver that instantiates the child device for this
driver.

Rob