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 10:10:23 -0800
From:   Guenter Roeck <linux@...ck-us.net>
To:     Zev Weiss <zev@...ilderbeest.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 2/28/22 09:11, Zev Weiss wrote:
> 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?
> 

The i2c/i2c-mux maintainers will need to accept it, and you'll need
approval for the DT changes from a DT maintainer (presumably Rob).

Guenter