linux-kernel - Re: [PATCH] pinctrl: add a pinctrl_mux_group

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 Jun 2012 13:28:29 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Guennadi Liakhovetski <g.liakhovetski@....de>
Cc:	Stephen Warren <swarren@...dotorg.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pinctrl: add a pinctrl_mux_group_selected() function

On Thu, Jun 7, 2012 at 4:05 AM, Guennadi Liakhovetski
<g.liakhovetski@....de> wrote:

> [Stephen]
>> If using device tree, the bus-width property should be used. If not
>> using device tree, presumably you'd add an equivalent field to the
>> platform data.
>
> Wouldn't adding a bus-width field to the platform data be redundant,
> considering it's already available in the pinctrl configuration?

Maybe, but Documentation/devicetree/bindings/mmc/mmc.txt
mandates that you specify this width anyway I think, it's
stated as "requiered".

The bindings should be useable also for systems which does not
have pinctrl.

> Or should we request several configurations from the driver?

Do you mean several states?

> One of the 3 bus widthes, and additionally
> a card-detection and a write-protect configurations?

Isn't the card detection and write protect GPIO lines that
will be requested with gpio_request()? This is usually the case,
so I need to ask. GPIOs are usually muxed in on a per-pin basis
as a result of the gpio_request() call.

I don't know how your setup works but we have something like
this for an external SD card:

NB: I use these macros to shorten the lines, it's just simple hogs
on our primary pin controller:

#define DB8500_MUX(group,func,dev) \
        PIN_MAP_MUX_GROUP_DEFAULT(dev, "pinctrl-db8500", group, func)
#define DB8500_PIN(pin,conf,dev) \
        PIN_MAP_CONFIGS_PIN_DEFAULT(dev, "pinctrl-db8500", pin, conf)

/* Mux in SDI0 (here called MC0) used for removable MMC/SD/SDIO cards */
DB8500_MUX("mc0_a_1", "mc0", "sdi0"),
DB8500_PIN("GPIO18_AC2", out_hi, "sdi0"), /* CMDDIR */
DB8500_PIN("GPIO19_AC1", out_hi, "sdi0"), /* DAT0DIR */
DB8500_PIN("GPIO20_AB4", out_hi, "sdi0"), /* DAT2DIR */
DB8500_PIN("GPIO22_AA3", in_nopull, "sdi0"), /* FBCLK */
DB8500_PIN("GPIO23_AA4", out_lo, "sdi0"), /* CLK */
DB8500_PIN("GPIO24_AB2", in_pu, "sdi0"), /* CMD */
DB8500_PIN("GPIO25_Y4", in_pu, "sdi0"), /* DAT0 */
DB8500_PIN("GPIO26_Y2", in_pu, "sdi0"), /* DAT1 */
DB8500_PIN("GPIO27_AA2", in_pu, "sdi0"), /* DAT2 */
DB8500_PIN("GPIO28_AA1", in_pu, "sdi0"), /* DAT3 */

When "default" is selected, the group mc0_a_1 is muxed in
on function mc0, and the 10 pins are configured.(out_hi etc
are lists of configuration values).

We coul name this state "4bitsd" or so, and have another state
called "8bitemmc". Nothing stops you from also configuring pull-ups
on GPIO pins etc in this table.

We have several ports, here is an eMMC:

/* Mux in SDI2 (here called MC2) used for for PoP eMMC */
DB8500_MUX("mc2_a_1", "mc2", "sdi2"),
DB8500_PIN("GPIO128_A5", out_lo, "sdi2"), /* CLK */
DB8500_PIN("GPIO129_B4", in_pu, "sdi2"), /* CMD */
DB8500_PIN("GPIO130_C8", in_nopull, "sdi2"), /* FBCLK */
DB8500_PIN("GPIO131_A12", in_pu, "sdi2"), /* DAT0 */
DB8500_PIN("GPIO132_C10", in_pu, "sdi2"), /* DAT1 */
DB8500_PIN("GPIO133_B10", in_pu, "sdi2"), /* DAT2 */
DB8500_PIN("GPIO134_B9", in_pu, "sdi2"), /* DAT3 */
DB8500_PIN("GPIO135_A9", in_pu, "sdi2"), /* DAT4 */
DB8500_PIN("GPIO136_C7", in_pu, "sdi2"), /* DAT5 */
DB8500_PIN("GPIO137_A7", in_pu, "sdi2"), /* DAT6 */
DB8500_PIN("GPIO138_C5", in_pu, "sdi2"), /* DAT7 */

Isn't you board similarly hard-coded from the platform or
device tree? It seems less kludgy to ask DT or platform data
about the bus width if that is all.

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/