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: <CACRpkdZdweyWJefttiuiYAJ9qhahLbnj7eHUiLV_83UA41X_uQ@mail.gmail.com>
Date:	Tue, 26 Nov 2013 14:46:05 +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 Thu, Nov 21, 2013 at 11:34 AM, boris brezillon
<b.brezillon@...rkiz.com> wrote:
> On 21/11/2013 10:48, Linus Walleij wrote:

>> No matter whether it's a switch or a GPIO regulator it seems we
>> are in violent agreement that it should not be controlled by the
>> pin control states at least.
>>
>> Start with making it a GPIO then you can figure out whether
>> a GPIO regulator or drivers/extcon/extcon-gpio.c should be
>> used.
>
> Thanks for pointing this out. I wasn't aware of the extcon subsystem.
>
> Actually, I think it's a little bit more tricky.

Hm, yeah extcon is for things like audio jacks on phones that
userspace need to detect.

drivers/input/keyboard/gpio_keys* is for things that actually
input characters to userspace stuff.

None of it is applicable here it seems ...

> The switch connected to gpio PB22 is used to enable one device or the other:
>  - PB22 set to high level enables slot0 of mmc0 (connect mmc signals to the
> mmc
>    connector)
>  - PB22 set to low level enables the dataflash (connect to the SPI0 signals
> to the
>    dataflash device)

So this is something like a "jumper" of the old type, configuring
the entire system?

Something like that:
http://www.mignonette-game.com/images/v2/21-arduino-com-jumper.jpg

But in this case it is a mechanical switch rather than a jumper?

This is not much different from the GPIOs people use to e.g. encode
the board type, just that it can change.

Do people switch this thing at runtime?

> The pinctrl approach has the benefit of providing a transparent way (no
> existing
> drivers modifications) to enable one device or the other.
>
> But if you think this is better done (or cleaner) with an extcon or a
> regulator device,
> I'll try to find a way to do it this way.

I'm uncertain. If this is something that changes at runtime, the
input from the switch should be read through GPIO and used
to select the "default" state of one device and something like
"sleep" on the other (I suspect more things than pin control
may be affected by that!)

If this is a switch that you want to take the simple shortcut
of just reading at boot, the approach would still be similar, just
less code.

So use gpio_get() to read the value, and then select which
*entire device* goes active depending on the setting would
be the right approach I guess?

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/