linux-kernel - Re: [PATCH 13/14] ARM: ux500: enable AB8500 GPIO for HREF

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:	Thu, 7 Feb 2013 08:30:22 +0000
From:	Arnd Bergmann <arnd@...db.de>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	Stephen Warren <swarren@...dia.com>,
	Anmar Oueja <anmar.oueja@...aro.org>,
	Lee Jones <lee.jones@...aro.org>, arm@...nel.org,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH 13/14] ARM: ux500: enable AB8500 GPIO for HREF

On Thursday 07 February 2013, Stephen Warren wrote:
> On 02/05/2013 12:48 PM, Linus Walleij wrote:
> > From: Lee Jones <lee.jones@...aro.org>
> > 
> > The AB8500 GPIO driver has been un-BROKEN and rewritten as a pinctrl
> > driver. Now that it's back in use, let's ensure that it's available
> > when booting HREF with Device Tree enabled.
> 
> > diff --git a/arch/arm/boot/dts/hrefprev60.dts b/arch/arm/boot/dts/hrefprev60.dts
> 
> >       soc-u9500 {
> > +             prcmu@...57000 {
> > +                     ab8500@5 {
> > +                             ab8500-gpio {
> > +                                     compatible = "stericsson,ab8500-gpio";
> 
> The MFDs I've looked at (which admittedly might not be that many) all
> have the top-level chip described in device tree, but not all the
> component sub-devices, since they're all a static part of the top-level
> chip. Instead, the top-level MFD instantiates all the sub-devices
> itself. I'm curious why this MFD device works differently - do many work
> like this?

I think in general, describing only the top level in DT is preferred.
However, that does not work if you have devices outside of the MFD
refer to devices inside of it, such as GPIO, clocks or interrupts:

In order to connect a button or an LED to this GPIO controller
in DT, you need to have a node you can refer to that follows the
GPIO binding. Putting all of that into the top-level device
would get messy here.

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