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: <20191112193653.GB13374@dtor-ws>
Date:   Tue, 12 Nov 2019 11:36:53 -0800
From:   Dmitry Torokhov <dmitry.torokhov@...il.com>
To:     Mark Brown <broonie@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-spi@...r.kernel.org,
        Mark Rutland <mark.rutland@....com>,
        Rob Herring <robh+dt@...nel.org>, devicetree@...r.kernel.org
Subject: Re: [PATCH 1/2] spi: dt-bindings: spi-controller: add wakeup-source
 and interrupts

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.

-- 
Dmitry