linux-kernel - Re: [v2 3/3] hwmon: Add Aspeed ast2600 TACH support

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: <4EC60594-E1F5-4F05-A9E6-3BDCFAE62A65@aspeedtech.com>
Date:   Tue, 8 Nov 2022 07:17:48 +0000
From:   Billy Tsai <billy_tsai@...eedtech.com>
To:     Guenter Roeck <linux@...ck-us.net>
CC:     "jdelvare@...e.com" <jdelvare@...e.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "joel@....id.au" <joel@....id.au>,
        "andrew@...id.au" <andrew@...id.au>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "thierry.reding@...il.com" <thierry.reding@...il.com>,
        "u.kleine-koenig@...gutronix.de" <u.kleine-koenig@...gutronix.de>,
        "p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
        "linux-hwmon@...r.kernel.org" <linux-hwmon@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pwm@...r.kernel.org" <linux-pwm@...r.kernel.org>,
        BMC-SW <BMC-SW@...eedtech.com>,
        "garnermic@...a.com" <garnermic@...a.com>
Subject: Re: [v2 3/3] hwmon: Add Aspeed ast2600 TACH support


On 2022/11/3, 10:31 PM, "Guenter Roeck" <groeck7@...il.com on behalf of linux@...ck-us.net> wrote:

    On Thu, Nov 03, 2022 at 05:40:44AM +0000, Billy Tsai wrote:
    > > On 2022/11/3, 12:30 PM, "Guenter Roeck" <groeck7@...il.com on behalf of linux@...ck-us.net> wrote:
    > > 
    > >     On Thu, Nov 03, 2022 at 03:52:59AM +0000, Billy Tsai wrote:
    > >     > > 
    > >     > > Can't I use a min/max RPM to let the driver know a reasonable timeout/polling period when
    > >     > > the driver is trying to get RPM?
    > >     > > Beacause that our tach controller have the falg to indicates the hardware detected the change
    > >     > > in the input signal. I need the proper timout to rule out slow RPMs.
    > > 
    > >     > If the chip measures the fan speed continuously, why would that ever be a
    > >     > problem, and why wait in the first place instead of just taking the most
    > >     > recent result ?
    > > 
    > >     > Pretty much every other driver is doing that, so I really don't understand
    > >     > why that would not work here.
    > > 
    > > When the fan speed drop from a very fast RPM to a very slow RPM. Especially when it is close to stopping.
    > > The most recent result will be no meaningful value. The slower RPM needs more time to sample it. E.g., If
    > > we want to measure the fan with 600 RPM, the controller needs at least 100ms. During this time period, we
    > > will always get the wrong value. So, our tach controller have the flag to avoid this problem:
    > > TACH_ASPEED_VALUE_UPDATE: tach value updated since last read
    > > This flag will be set when the controller detected the change of the signal and clear by read it.
    > > In order to use this flag, the controller needs the proper timeout based on minimum RPM to avoid waiting forever.
    > > 

    > I am not going to accept this patch as-is. If userspace wants to have
    > values accurate down to ms, this kind of approach is just wrong. Users
    > will have to live with the fact that measurements may be a bit (in the 
    > < 1 second range) out of date. Many older drivers even implement code
    > which avoids reading registers again for a second or longer. Older
    > temperature sensors may take several seconds to provide new readings.
    > That is not a reason to block userspace until a new value is available.
    > I do not see that as a problem. In my opinion it is much more of a
    > problem if the driver returns a completely bad value such as 0 or even
    > an error code because its software parameters did not match reality and
    > the driver didn't wait long enough for a new value. That would be _much_
    > worse than providing a value which is a few 100 ms out of date, and your
    > code is vulnerable to that problem.

    > Besides, for a fan to reduce its speed that quickly, it has to be manually
    > stopped. Normally fans take several seconds to stop if power is taken away
    > completely. Your code is adding a lot of complexity (and unnecessary
    > attributes) for no good reason.

Thanks for your detailed explanations.
I will remove the min and max RPMs and return the tach value directly without any polling or delay.

Best Regards,
Billy Tsai