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_JsqJ8rjRzaqasjbdq-jkYfWxdo72YnmKAVNxDwo6wtyv1xg@mail.gmail.com>
Date:   Wed, 23 May 2018 10:11:47 -0500
From:   Rob Herring <robh@...nel.org>
To:     Jae Hyun Yoo <jae.hyun.yoo@...ux.intel.com>
Cc:     Mark Rutland <mark.rutland@....com>,
        Haiyue Wang <haiyue.wang@...ux.intel.com>,
        Vernon Mauery <vernon.mauery@...ux.intel.com>,
        James Feist <james.feist@...ux.intel.com>,
        devicetree@...r.kernel.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Andrew Jeffery <andrew@...id.au>,
        Arnd Bergmann <arnd@...db.de>,
        Jason M Biils <jason.m.bills@...ux.intel.com>,
        Joel Stanley <joel@....id.au>
Subject: Re: [v4 07/11] dt-bindings: hwmon: Add documents for PECI hwmon
 client drivers

On Tue, May 22, 2018 at 12:18 PM, Jae Hyun Yoo
<jae.hyun.yoo@...ux.intel.com> wrote:
> On 5/22/2018 9:42 AM, Rob Herring wrote:
>>
>> On Mon, May 21, 2018 at 12:59:05PM -0700, Jae Hyun Yoo wrote:
>>>
>>> This commit adds dt-bindings documents for PECI hwmon client drivers.
>>>
>>> Signed-off-by: Jae Hyun Yoo <jae.hyun.yoo@...ux.intel.com>
>>> Reviewed-by: Haiyue Wang <haiyue.wang@...ux.intel.com>
>>> Reviewed-by: James Feist <james.feist@...ux.intel.com>
>>> Reviewed-by: Vernon Mauery <vernon.mauery@...ux.intel.com>
>>> Cc: Andrew Jeffery <andrew@...id.au>
>>> Cc: Arnd Bergmann <arnd@...db.de>
>>> Cc: Jason M Biils <jason.m.bills@...ux.intel.com>
>>> Cc: Joel Stanley <joel@....id.au>
>>> ---
>>>   .../bindings/hwmon/peci-cputemp.txt           | 23 ++++++++++++++++++
>>>   .../bindings/hwmon/peci-dimmtemp.txt          | 24 +++++++++++++++++++
>>>   2 files changed, 47 insertions(+)
>>>   create mode 100644
>>> Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>>   create mode 100644
>>> Documentation/devicetree/bindings/hwmon/peci-dimmtemp.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>> b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>> new file mode 100644
>>> index 000000000000..2f59aee12d9e
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/hwmon/peci-cputemp.txt
>>> @@ -0,0 +1,23 @@
>>> +Bindings for Intel PECI (Platform Environment Control Interface) cputemp
>>> driver.
>>> +
>>> +Required properties:
>>> +- compatible : Should be "intel,peci-cputemp".
>>> +- reg        : Should contain address of a client CPU. Address range of
>>> CPU
>>> +              clients is starting from 0x30 based on PECI specification.
>>> +
>>> +Example:
>>> +       peci-bus@0 {
>>> +               #address-cells = <1>;
>>> +               #size-cells = <0>;
>>> +               < more properties >
>>> +
>>> +               peci-cputemp@30 {
>>> +                       compatible = "intel,peci-cputemp";
>>> +                       reg = <0x30>;
>>> +               };
>>
>>
>> [...]
>>
>>> +               peci-dimmtemp@30 {
>>> +                       compatible = "intel,peci-dimmtemp";
>>> +                       reg = <0x30>;
>>> +               };
>>
>>
>> As I said in the prior version, 2 nodes at the same address is wrong.
>>
>> Rob
>>
>
> In PECI bus, there is one and only bus host (adapter) and multiple
> clients on a PECI bus, and PECI spec doesn't allow multiple originators
> so only the host device can originate message.

Yes, I get that. A single host still has to address slave devices.

> In this implementation,
> all message transactions on a bus from client driver modules and user
> space will be serialized well in the PECI core bus driver so bus
> occupation and traffic arbitration will be managed well in the PECI core
> bus driver even in case of a bus has 2 client drivers at the same
> address. I'm sure that this implementation doesn't make that kind of
> problem to OS.

Multiple clients to a single device is common, but that is a software
problem and doesn't belong in DT.

I don't think there is a single other case in the kernel where
multiple drivers can bind to the same device at a given bus address.
That is why we have things like MFD. Though in this case, why can't
one hwmon driver register multiple hwmon devices (cpu and dimm temps)?

Rob

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ