linux-kernel - Re: [PATCH v2 0/2] ic2: mux: pca9541: add delayed-release 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]

Date:   Mon, 28 Feb 2022 09:11:47 -0800
From:   Zev Weiss <zev@...ilderbeest.net>
To:     Guenter Roeck <linux@...ck-us.net>
Cc:     linux-i2c@...r.kernel.org, Peter Rosin <peda@...ntia.se>,
        Rob Herring <robh+dt@...nel.org>, openbmc@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Wolfram Sang <wsa@...nel.org>
Subject: Re: [PATCH v2 0/2] ic2: mux: pca9541: add delayed-release support

On Mon, Feb 28, 2022 at 05:57:27AM PST, Guenter Roeck wrote:
>On 2/28/22 00:43, Zev Weiss wrote:
>>On Mon, Jan 31, 2022 at 04:18:08PM PST, Zev Weiss wrote:
>>>Hello,
>>>
>>>This series adds support for a new pca9541 device-tree property
>>>("release-delay-us"), which delays releasing ownership of the bus
>>>after a transaction for a configurable duration, anticipating that
>>>another transaction may follow shortly.  By avoiding a
>>>release/reacquisition between transactions, this can provide a
>>>substantial performance improvement for back-to-back operations -- on
>>>a Delta AHE-50DC (ASPEED AST1250) system running OpenBMC with dozens
>>>of LM25066 PMICs on PCA9541-arbitrated busses, a setting of 10000 (10
>>>ms) reduces the median latency the psusensor daemon's hwmon sysfs file
>>>reads from 2.28 ms to 0.99 ms (a 57% improvement).
>>>
>>
>>Ping...Guenter, any thoughts on this?
>>
>
>It sounds reasonable to me, but I don't have access to hardware anymore
>to test it, so I have no means to confirm that it actually works.
>

Ack, thanks.  In that case, what's the path forward on getting changes 
to this driver merged?  I see sign-offs from Wolfram and Peter on the 
last few commits that touched it -- any input from the i2c/i2c-mux 
maintainers?


Zev