linux-kernel - Re: [PATCH 1/2] spi: dt-bindings: spi-controller: add wakeup-source and interrupts

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: <CAKdAkRQBrKOUTW8puakA26ODYW9=0H4VhwFhGQAqMs-cMmj3CQ@mail.gmail.com>
Date:   Thu, 14 Nov 2019 15:08:54 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Rob Herring <robh@...nel.org>
Cc:     Mark Brown <broonie@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        linux-spi <linux-spi@...r.kernel.org>,
        Mark Rutland <mark.rutland@....com>,
        DTML <devicetree@...r.kernel.org>
Subject: Re: [PATCH 1/2] spi: dt-bindings: spi-controller: add wakeup-source
 and interrupts

On Thu, Nov 14, 2019 at 2:26 PM Rob Herring <robh@...nel.org> wrote:
>
> On Tue, Nov 12, 2019 at 11:36:53AM -0800, Dmitry Torokhov wrote:
> > On Tue, Nov 12, 2019 at 07:15:47PM +0000, Mark Brown wrote:
> > > On Tue, Nov 12, 2019 at 11:03:28AM -0800, Dmitry Torokhov wrote:
> > > > On Tue, Nov 12, 2019 at 12:03:07PM +0000, Mark Brown wrote:
> > > > > On Mon, Nov 11, 2019 at 09:54:10PM -0800, Dmitry Torokhov wrote:
> > >
> > > > > > +      interrupts:
> > > > > > +        items:
> > > > > > +          - description: main interrupt (attention) line.
> > > > > > +          - description: dedicated wakeup interrupt.
> > > > > > +        minItems: 1 # The wakeup interrupt is optional.
> > >
> > > > > > +      interrupt-names:
> > > > > > +        items:
> > > > > > +          - const: irq
> > > > > > +          - const: wakeup
> > > > > > +        minItems: 1
> > >
> > > > > How will this interact with a SPI device that defines interrupts at the
> > > > > device level, possibly more than one of them?  Especially if the device
> > > > > has its own idea what the interrupts should be called.
> > >
> > > > My understanding that individual drivers should be able to override
> > > > whatever the default behavior core has configured, and the device can
> > > > establish their own mapping. We have this in I2C and I believe this
> > > > works well.
> > >
> > > > Is the concern about the device tree scheme or SPI core handling?
> > >
> > > Both really.
> >
> > So as I mentioned, the driver is not forced to use the interrupt
> > supplied by the SPI core, and the worst thing is that the core
> > configures the main IRQ as wakeirq and driver would need to call
> > dev_pm_clear_wake_irq() before switching to correct one. I expect there
> > will be just a few drivers needing that and many more would benefit from
> > the default behavior and not needing to repeat the same boilerplate
> > code.
> >
> > As far as scheme goes - I hope that Rob could confirm that we can
> > override number of interrupts and names in consumers of the binding, as
> > needed.
>
> This won't work. A device schema doesn't override what's defined here,
> but just further constrains this schema.
>
> You could define a "spi irq" schema which devices can include if they
> want to, but I don't think this pattern is that common to SPI devices.
> There's not any spec behind compared to say alert irq for SMBus.
>
> The 'wakeup' irq name is standardized (for DT), but that's not SPI
> specific. About all we could define there is 'wakeup-source' is boolean
> and if there is more than one interrupt, one should be named 'wakeup'.

OK, so what I am hearing is "interrupt"/"interrupt-names" properties
should be defined in individual device's bindings, and wakeup-source
can stay in spi-controller.yaml, right?

And as far as SPI core goes, we can still do what I proposed, because
we already handle "first" interrupt as the default one and the drivers
can override as needed anyway...

Thanks.

-- 
Dmitry