linux-kernel - Re: [PATCH v3 13/27] ALSA: hda/cs8409: Dont disable I2C clock between consecutive accesses

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]

Date:   Wed, 11 Aug 2021 19:33:07 +0100
From:   Vitaly Rodionov <vitalyr@...nsource.cirrus.com>
To:     Takashi Iwai <tiwai@...e.de>
CC:     Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
        <alsa-devel@...a-project.org>, <patches@...nsource.cirrus.com>,
        <linux-kernel@...r.kernel.org>,
        Lucas Tanure <tanureal@...nsource.cirrus.com>,
        Stefan Binding <sbinding@...nsource.cirrus.com>
Subject: Re: [PATCH v3 13/27] ALSA: hda/cs8409: Dont disable I2C clock between
 consecutive accesses

On 01/08/2021 9:03 am, Takashi Iwai wrote:
> On Fri, 30 Jul 2021 17:18:30 +0200,
> Vitaly Rodionov wrote:
>> From: Lucas Tanure <tanureal@...nsource.cirrus.com>
>>
>> Only disable I2C clock 25 ms after not being used.
>>
>> The current implementation enables and disables the I2C clock for each
>> I2C transaction. Each enable/disable call requires two verb transactions.
>> This means each I2C transaction requires a total of four verb transactions
>> to enable and disable the clock.
>> However, if there are multiple consecutive I2C transactions, it is not
>> necessary to enable and disable the clock each time, instead it is more
>> efficient to enable the clock for the first transaction, and disable it
>> after the final transaction, which would improve performance.
>> This is achieved by using a timeout which disables the clock if no request
>> to enable the clock has occurred for 25 ms.
>>
>> Signed-off-by: Lucas Tanure <tanureal@...nsource.cirrus.com>
>> Signed-off-by: Vitaly Rodionov <vitalyr@...nsource.cirrus.com>
>> Signed-off-by: Stefan Binding <sbinding@...nsource.cirrus.com>
>> ---
>>
>> Changes in v2:
>> - Improved delayed work start/cancel implementation, and re-worked commit message
>>   adding more explanation why this was required.
>>
>> Changes in v3:
>> - Cancel the disable timer, but do not wait for any running disable functions to finish.
>>   If the disable timer runs out before cancel, the delayed work thread will be blocked,
>>   waiting for the mutex to become unlocked. This mutex will be locked for the duration of
>>   any i2c transaction, so the disable function will run to completion immediately
>>   afterwards in the scenario. The next enable call will re-enable the clock, regardless.
> This looks almost fine, but just a couple of thoughts:
>
> - cancel_delayed_work_sync() means to it might keep the i2c enabled
>    after that point (just cancel the pending work).
>    Would it cause a inconsistency afterwards?
>
> - A similar procedure is needed for suspend callback to cancel / flush
>    the work.
>    The shutdown is another question, but usually it's fine to without
>    any special handling as long as the resource is kept.

Hi Takashi,

Thank you very much for your comments. It all make sense.

We will make further improvement and submit next version.

Thanks,

Vitaly

>
> thanks,
>
> Takashi