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: <Y73WL3Gwo6w6dJJr@sirena.org.uk>
Date:   Tue, 10 Jan 2023 21:18:39 +0000
From:   Mark Brown <broonie@...nel.org>
To:     William Zhang <william.zhang@...adcom.com>
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 Mon, Jan 09, 2023 at 12:43:53PM -0800, William Zhang wrote:
> On 01/09/2023 11:31 AM, Mark Brown wrote:

> > If this relies on software control of the chip select (which is what I
> > *think* your dummy CS workaround thing is about, the other patch about
> > that is really hard to understand) then I'm confused about what the
> > advantage is?

> Dummy CS workaround is implemented by Jonas when he first upstream the
> driver. It does not work on all the board designs so prepend mode is
> introduced. I have some detail explanation on this in [PATCH 10/16] spi:
> bcm63xx-hsspi: Make dummy cs workaround as an option.

Yes, it is the description in patch 10 that I was having a lot of
trouble following.

> The controller only work in one mode and that's why driver code has some
> dependency between these two modes. The advantage of the premode is it works
> on all hw design however it does not support all types mem_ops operation.
> That is why you see the patch 14 to disable the dual io mem op. But dummy cs
> workaround can support this and in case there is such pattern from non mem
> op spi transaction, dummy cs workaround can be used as long as it does not
> have the board design limitation.   So neither one is perfect but hopefully
> with both options available, we can cover all the cases.

We can't switch modes per message?

> You mentioned there is some existing logic to rewrite messages to match
> driver constraints in the core driver.  I didn't see it when I did a quick
> search on spi.c. I will take a deep look into the file. But if you can point
> me where this logic is so I can be sure that I am looking at the right place
> and will double check if this can be done or not in the core level.  Thanks!

spi_replace_transfers().

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)