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: <50A70EE6.3050101@wwwdotorg.org>
Date:	Fri, 16 Nov 2012 21:13:26 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Jonas Gorski <jonas.gorski@...il.com>
CC:	linux-mips@...ux-mips.org, devicetree-discuss@...ts.ozlabs.org,
	Kevin Cernekee <cernekee@...il.com>,
	linux-kernel@...r.kernel.org, Ralf Baechle <ralf@...ux-mips.org>,
	Maxime Bizon <mbizon@...ebox.fr>,
	Florian Fainelli <florian@...nwrt.org>
Subject: Re: [RFC] MIPS: BCM63XX: add Device Tree glue code for IRQ handling

On 11/14/2012 05:09 AM, Jonas Gorski wrote:
> On 13 November 2012 06:00, Stephen Warren <swarren@...dotorg.org> wrote:
>> On 11/11/2012 05:50 AM, Jonas Gorski wrote:
>>> Register IRQ domains through Device Tree for the internal and external
>>> interrupt controllers. Register the same IRQ ranges as previously to
>>> provide backward compatibility for non-DT drivers.
>>
>>> diff --git a/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt b/Documentation/devicetree/bindings/mips/bcm63xx/epic.txt
>>
>> Rather than putting binding docs in an arch-specific directory, perhaps
>> put them into a device-type-specific directory, such as
>> bindings/interrupt-controller/brcm,bcm63xx-epic.txt?
> 
> Almost everyone has their interrupt-controller bindings in
> $arch/$platform, but if interrupt-controller is the preferred
> location, I can certainly move it there; I have no hard preference for
> any location.

Yes, people have been putting them in arch/platform, but I think there's
a move to more type-based locations.

>>> diff --git a/arch/mips/bcm63xx/dts/bcm6328.dtsi b/arch/mips/bcm63xx/dts/bcm6328.dtsi
>>
>>>               ranges = <0 0x10000000 0x20000>;
>>>               compatible = "simple-bus";
>>> +
>>> +             interrupt-parent = <&ipic>;
>>> +
>>> +             perf@0 {
>>> +                     epic: interrupt-controller@18 {
>>
>> Don't you need some reg properties in the perf and interrupt-controller
>> nodes so that the register address can be determined?
> 
> Since there is no support code for that property yet I did not add it.
> I haven't quite finished yet how the final bindings will be (since
> there are/were a few things I haven't finished researching yet, e.g.
> how this controller works in SMP context, and how interrupt
> controllers are supposed to work).
> 
> I can add all expected properties now and add support for them later,
> but I feel that this might add properties that will then never
> supported, and nobody updates the documentation for that, so I'd
> rather like to keep the documentation/dts(i) in sync with what the
> actual code expects/supports.

The DT bindings and DT content are supposed to be fully defined the
first time around, such that even if the kernel doesn't use the reg
property yet, if you were to use the DT created now with a future kernel
that does use the reg property, it's already there.

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ