linux-kernel - Re: [PATCH 11/16] spi: bcm63xx-hsspi: Add prepend feature 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: <88534207-6b1c-75c1-26a1-be88a19eeecb@broadcom.com>
Date:   Fri, 6 Jan 2023 19:52:35 -0800
From:   William Zhang <william.zhang@...adcom.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     Linux SPI List <linux-spi@...r.kernel.org>,
        Broadcom Kernel List <bcm-kernel-feedback-list@...adcom.com>,
        anand.gore@...adcom.com, tomer.yacoby@...adcom.com,
        dan.beygelman@...adcom.com, joel.peshkin@...adcom.com,
        f.fainelli@...il.com, jonas.gorski@...il.com,
        kursad.oney@...adcom.com, dregan@...l.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 11/16] spi: bcm63xx-hsspi: Add prepend feature support



On 01/06/2023 02:00 PM, Mark Brown wrote:
> On Fri, Jan 06, 2023 at 12:08:03PM -0800, William Zhang wrote:
>> Multiple transfers within a SPI message may be combined into one
>> transfer to the controller using its prepend feature. A SPI message is
>> prependable only if the following are all true:
>>    * One or more half duplex write transfer
>>    * Optional full duplex read/write at the end
>>    * No delay and cs_change between transfers
> 
> There is nothing driver specific here, this should be implemented in the
> core - we have existing logic to rewrite messages to match driver
> constraints, this could be added there possibly with flags to allow
> drivers to disable or enable the merging if they've got special
> requirements.
> 
My understanding of combining the spi transfer in the core level does 
not quite work out to our controller.  For example, for a spi message 
with three transfers, tx, tx and rx. We can possibly combine them in 
single duplex tx/rx transfer in the core. But this will be treated as 
duplex transaction in our controller level which require tx and rx data 
happens at the same time. Obviously this won't work when rx depends on 
tx happening first. We can not differentiate this combined duplex 
transfer from the true duplex transfer unless there is some flag to 
indicate that. Also there is limit of max tx length as the prepend 
buffer so maybe another parameter.  And another reason to be done in the 
driver level is this prepend mode has dependency on dummy cs workaround 
which is driver level parameter currently.  I am not sure how practical 
and useful this is to factor them out to the core level?  Maybe I didn't 
fully understand your comments and appreciate if you can elaborate or 
point me to the related core code.

Download attachment "smime.p7s" of type "application/pkcs7-signature" (4212 bytes)