linux-kernel - Re: [PATCH] of/irq: lookup 'interrupts-extended' property first

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:	Wed, 06 Aug 2014 15:12:42 -0700
From:	Florian Fainelli <f.fainelli@...il.com>
To:	Tim Bird <tbird20d@...il.com>,
	Brian Norris <computersforpeace@...il.com>
CC:	Rob Herring <robherring2@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] of/irq: lookup 'interrupts-extended' property first

On 08/06/2014 02:50 PM, Tim Bird wrote:
> On Wed, Aug 6, 2014 at 1:12 PM, Brian Norris
> <computersforpeace@...il.com> wrote:
>> On Wed, Aug 06, 2014 at 01:42:08PM -0500, Rob Herring wrote:
>>> On Wed, Aug 6, 2014 at 11:54 AM, Brian Norris <computersforpeace@...il.com> wrote:
>>>> On Thu, Jul 31, 2014 at 11:00:01AM -0700, Florian Fainelli wrote:
>>>> I think it is important that a device tree provide some flexibility on
>>>> kernel versions. We only invented 'interrupts-extended' in Linux 3.13,
>>>> so it's easy to have device trees that could work only on 3.13+.
>>>>
>>>> Typically, we might say that new features require new kernels, but this
>>>> is a very basic piece of the DT infrastructure. In our case, we have
>>>> hardware whose basic features can be supported by a single interrupt
>>>> parent, and so we used the 'interrupts' property pre-3.13. But when we
>>>> want to add some power management features, there's an additional
>>>> interrupt parent. Under the current DT binding, we have to switch over
>>>> to using 'interrupts-extended' exclusively, and thus we must have a
>>>> completely new DTB for >=3.13, and this DTB no longer works with the old
>>>> kernels.
>>>
>>> "Must have" to enable the new features?
>>
>> Yes. The new feature requires an additional interrupt parent, and so it
>> requires interrupts-extended.
> 
> Hold on there.  What about interrupt-map?  That was the traditional DT
> feature for
> supporting multi-parented interrupts.  Why couldn't the feature have been added
> using that instead of interrupts-extended?

As far as I read it from the ePAPR specification, you have a good point
here, it looks like 'interrupt-map' could have been used as-is instead
of 'interrupts-extended'. In fact it is a little more general than
'interrupts-extended' since it allows any sort of "child unit address",
whether that is an actual interrupt number, or something else, is
dependent on the type of node being used.

> 
> I know interrupts-extended is preferred, but has interrupt-map support been
> removed from recent kernels?  I'm a bit confused.

'interrupt-map' support has not been removed since that is heavily used
to cross interrupt domains, e.g: PCI relies heavily on it, other buses
as well most likely.

> 
>  -- Tim Bird
> Senior Software Engineer, Sony Mobile
> Architecture Group Chair, CE Workgroup, Linux Foundation
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/