linux-kernel - Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi

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: <CAMuHMdWv4MAdqf1EBGSybw=2-hNeeEf3TWiH7ZhQBa-Ad9++Ag@mail.gmail.com>
Date:   Thu, 19 Nov 2020 20:30:12 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Mark Brown <broonie@...nel.org>
Cc:     Serge Semin <Sergey.Semin@...kalelectronics.ru>,
        Serge Semin <fancer.lancer@...il.com>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Ramil Zaripov <Ramil.Zaripov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        linux-spi <linux-spi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] spi: Take the SPI IO-mutex in the spi_setup() method

Hi Mark,

On Thu, Nov 19, 2020 at 7:45 PM Mark Brown <broonie@...nel.org> wrote:
> On Wed, Nov 18, 2020 at 07:29:31PM +0300, Serge Semin wrote:
> > On Wed, Nov 18, 2020 at 01:16:04PM +0000, Mark Brown wrote:
> > > Yeah, problems with it are very common as the documentation has noted
> > > since forever.  IIRC there was some problem triggered by trying to force
> > > it to be serialised but I can't remember what it was.
>
> > Does it mean nack for this patch from you? So you suggest to fix the controller
> > driver instead, right? If so the best solution would be to just lock the
> > IO mutex in the set_cs callback of the DW APB SSI driver...
>
> I'm not 100% clear what the original issue was, given that this is a
> constant source of errors in drivers it seems like it should be better
> to change the core but since I don't know why we have this the way it is
> it's hard to tell what special cases we might have that could explode if
> we try to do so.  I *think* the main issue is things that don't actually
> have separate per device registers trying to configure the single set of
> controler registers shared by all devices in which case the locking is
> fine and helps with this specific case where it's a read/modify/write
> operation on per device stuff and this makes sense.

It's also an issue on SPI controllers with a single native chipselect,
tricking the driver author into believing that writing to registers
during .setup() is not an issue.  Until an integrator starts using
cs-gpios...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds