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] [day] [month] [year] [list]

Message-ID: <CACRpkdZRgCnQktd7Q37Mho2uVWcxY2JS=tqkbFfg3MB5E97xCA@mail.gmail.com>
Date:	Tue, 12 Jun 2012 13:21:02 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Stephen Warren <swarren@...dotorg.org>
Cc:	Guennadi Liakhovetski <g.liakhovetski@....de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] pinctrl: add a pinctrl_mux_group_selected() function

On Thu, Jun 7, 2012 at 6:25 PM, Stephen Warren <swarren@...dotorg.org> wrote:
> On 06/06/2012 08:05 PM, Guennadi Liakhovetski wrote:

>> Sorry for not mentioning this in my previous reply, but there's more to
>> it, not just data lines can optionally be present. Each of the 3 possible
>> data-bus widths can also have Card Detection and Write Protect lines
>> present, which brings the number of possible configurations to 4 * 3 =
>> 12... We don't want to try all of them, right?

No that seems tiresome. And as noted elsewhere pinctrl is not
about maximum exercise of combinatorics. Nor should you encode
all possible combinations in you map, only put in a "default" map which
applied to that very board.

>> Whereas just querying the
>> pinctrl framework about which pins have been selected and configured seems
>> to be quite straight forward to me. Or should we request several
>> configurations from the driver? One of the 3 bus widthes, and additionally
>> a card-detection and a write-protect configurations?
>
> I would personally recommend not deriving any information from the
> selected pinctrl configuration at all. That way, you /can/ just use a
> "default" state, and never have to search through multiple pinctrl
> states. The board file will define that one state as setting up pinctrl
> however it needs to be for that board - 1/4/8 bit, with/without
> CD/WP/... signals/GPIOs etc.

I second this, if possible.

> If you're using built-in CD/WP logic on the SD host controller and don't
> have the ability to make those pins plain GPIOs, I think it's entirely
> reasonable to require DT to contain properties to enable/disable those
> features, e.g. I see fsl-imx-esdhc.txt already has fsl,cd-internal and
> fsl,wp-internal properties for this purpose.

This looks good to me.

I'm just guessing that the case is such that the SD controller has
built-in lines for CD and WP, but on its way to the external pin it
passes a piece of hardware that has pin configuration capabilities,
and in this case I'm semi-guessing that this piece of hardware
has a mode for that pin/line called "gpio" and that is where all
confusion comes from. But actually that has nothing to do with
the Linux concept of GPIOs (which is just gpiolib and a big
numberspace) as far as Linux is concerned, this is a pin config
setting part of the "default" state and nothing else.

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/