linux-kernel - Re: [PATCH 5/6] soundwire: qcom: update register read/write routine

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:   Tue, 2 Feb 2021 10:58:05 -0600
From:   Pierre-Louis Bossart <pierre-louis.bossart@...ux.intel.com>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>,
        vkoul@...nel.org
Cc:     yung-chuan.liao@...ux.intel.com, sanyog.r.kale@...el.com,
        linux-kernel@...r.kernel.org, alsa-devel@...a-project.org
Subject: Re: [PATCH 5/6] soundwire: qcom: update register read/write routine


>>>>> generates interrupt after it successfully finishes. This is really
>>>>> overhead, limiting and not really necessary unless we are doing
>>>>> something special.
>>>>>
>>>>> We can simply read/write the fifo that should also give exactly
>>>>> what we need! This will also allow to read/write registers in
>>>>> interrupt context, which was not possible with the special
>>>>> command approach.
>>>>
>>>> This is really unclear, sorry.
>>>
>>> If read/writes are waiting for an interrupt, it becomes difficult to 
>>> read or write to any registers from same interrupt handler!
>>
>> Well, yes, you need to handle the complete() at a lower level than the 
>> code that initiates the transactions otherwise you self-deadlock.
>>
>> IIRC in the Intel initial code, the complete was in the handler and 
>> the register IOs in the thread.
>>
> Yes, we did the same in previous version of the code, however with this 
> patch reading/writing fifo directly without need of completion should 
> remove that need of another thread!

Right, but you'll also write-off some command/control efficiency by 
either sleeping too much before checking the status, or sleeping too 
little and reading status from a transaction that's not finished.