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: <E9E92BC7-CB1A-487F-9E5D-2A403A01CB17@aspeedtech.com>
Date:   Thu, 3 Nov 2022 05:40:44 +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, 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.

Best Regards,
Billy Tsai