linux-kernel - Re: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

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: <CACRpkdag5=QYsWe81ocpkMp2APaoBAOOn2r0iAVdf9DHTKrSXA@mail.gmail.com>
Date:	Fri, 29 Nov 2013 14:31:21 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	boris brezillon <b.brezillon@...rkiz.com>
Cc:	Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>,
	Rob Herring <rob.herring@...xeda.com>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Russell King <linux@....linux.org.uk>,
	Nicolas Ferre <nicolas.ferre@...el.com>,
	Joachim Eastwood <manabian@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 5/9] ARM: at91/dt: add mmc0 slot0 support to at91rm9200ek board

On Fri, Nov 29, 2013 at 11:30 AM, boris brezillon
<b.brezillon@...rkiz.com> wrote:
> On 29/11/2013 11:03, Linus Walleij wrote:

>> I guess one way is to obtain this GPIO in board code and just
>> flick it depending on which device you register.
(...)
> The whole goal of moving from board files to dt is to drop all board
> specific processing or initialization and only keep a common description
> with generic drivers capable of handling common use cases.
>
> I'm not sure providing new board specific drivers is a good solution
> (even if it is the simplest way to achieve our goal).
>
> Could we have something similar to pinctrl but with gpios :
> when the device is probed the device/driver core code request the gpio
> configure it appropriately and set it to the requested value (if configured
> as output).

This has been suggested under the name "GPIO hogs" in the past.

It would work similar to how pinctrl hogs work by associating the
GPIO line the controller itself, using some specific string
like gpio-input-hogs = <...> / gpio-output-hogs = <...>;

The gpiolib core will then grab and set up these before
returning from the registration call so noone ever gets a chance
to use them.

> These are just thoughts, and I guess introducing new code in the
> device/driver core
> code is not that easy, especially when this code is here to handle specific
> case
> like ours.

It is very easy, just write the patch, iterate it (these patches get
a lot of scrutiny as it is core code, so expect some work and time
to get it done), and then unless there is a blocker, I would merge it.
The concept is entirely sound, just that someone needs to step
up and do the work...

Yours,
Linus Walleij
--
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/