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, 30 Aug 2016 15:34:25 +0930
From:   Joel Stanley <joel@....id.au>
To:     Andrew Jeffery <andrew@...id.au>
Cc:     Rob Herring <robh@...nel.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Alexandre Courbot <gnurou@...il.com>,
        Mark Rutland <mark.rutland@....com>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Jeremy Kerr <jk@...abs.org>, linux-gpio@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH v2 4/8] gpio: dt-bindings: Add documentation for Aspeed
 GPIO controllers

On Mon, Aug 22, 2016 at 9:46 AM, Andrew Jeffery <andrew@...id.au> wrote:
> On Fri, 2016-08-19 at 09:36 -0500, Rob Herring wrote:
>> On Fri, Aug 19, 2016 at 10:14:10PM +0930, Andrew Jeffery wrote:
>> >
>> > Signed-off-by: Andrew Jeffery <andrew@...id.au>
>> > ---
>> >
>> > Since v1:
>> >
>> > Rob: I haven't added your Acked-by here as I've made the following changes and
>> > wanted to get your input:
>> >
>> > * Remove interrupt-controller as an optional property
>> > * Defer to interrupt-controller bindings document for sub-node properties
>> >
>> > I had a discussion with Joel about whether the interrupt-controller capability
>> > should be optional and the conclusion was that it should always be configured
>> > by the driver. This makes an optional interrupt-controller property feel
>> > redundant (and possibly inaccurate if left out) so I've removed it.
>> I don't follow. What do you mean byt "configured by the driver". If the
>> block supports interrupts, then it should be marked as an
>> interrupt-controller. It never should have been optional. The OS can
>> ignore the interrupt properties if it chooses.
>
> Right, clearly there was some confusion on my part. I will fix that up.
> Thanks for clarifying.
>

Thanks for clarifying this Rob. With this cleared up,

Acked-by: Joel Stanley <joel@....id.au>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ