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]

Date:   Tue, 12 Nov 2019 11:03:28 -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 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.
> > +        description:
> > +          Specifies interrupt lines a device is connected to. Typically a
> > +          device is wired to a single interrupt line that is used as
> > +          "attention" signal and also to wake up system when device is
> > +          set up as wakeup source. However on some systems a dedicated
> > +          wakeup line might be used.
> 
> > +      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?

Thanks.

-- 
Dmitry