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]
Message-ID: <0b818aa2-e776-3554-8d7b-79fd856e2e1f@roeck-us.net>
Date:   Mon, 28 Mar 2022 09:37:57 -0700
From:   Guenter Roeck <linux@...ck-us.net>
To:     Michael Walle <michael@...le.cc>
Cc:     Jean Delvare <jdelvare@...e.com>, Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        linux-hwmon@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 4/4] hwmon: add driver for the Microchip LAN966x SoC

On 3/28/22 04:28, Michael Walle wrote:
> Am 2022-03-27 20:22, schrieb Guenter Roeck:
>> On 3/27/22 07:18, Michael Walle wrote:
>>> Am 2022-03-27 03:34, schrieb Guenter Roeck:
>>>
>>>>> +    /*
>>>>> +     * Data is given in pulses per second. According to the hwmon ABI we
>>>>> +     * have to assume two pulses per revolution.
>>>>
>>>> The hwmon ABI doesn't make any such assumptions. It wants to see RPM,
>>>> that is all. Pulses per revolution is a fan property.
>>>
>>> There is fanY_pulses according to Documentation/ABI/testing/sysfs-class-hwmon:
>>>
>>>    Should only be created if the chip has a register to configure
>>>    the number of pulses. In the absence of such a register (and
>>>    thus attribute) the value assumed by all devices is 2 pulses
>>>    per fan revolution.
>>>
>>> The hardware returns just the pulses per second. Doesn't that
>>> mean I have to divide that value by two?
>>>
>>
>> The above refers to hardware which reports RPM.
>>
>> It is up to the driver to calculate and return RPM. How you do it is your
>> decision. Drivers should report the most likely correct RPM value to
>> userspace, one that rarely needs manual adjustment. Almost all fans
>> report two pulses per revolution, so normally that assumption is used
>> to convert PPM to RPM. That isn't mandated (or supposed to be mandated)
>> by the ABI. I would call it common sense.
>>
>> I'll be happy to accept a patch clarifying this.
> 
> Where would that go? into the sysfs abi description of the
> fanY_input?
> 

For example.

Thanks,
Guenter

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ