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

Hi Stephen

Thanks for your comments and sorry for a delay.

On Wed, 23 May 2012, Stephen Warren wrote:

> On 05/23/2012 09:03 AM, Guennadi Liakhovetski wrote:
> > On Wed, 23 May 2012, Stephen Warren wrote:
> > 
> >> On 05/22/2012 04:23 PM, Guennadi Liakhovetski wrote:
> >>> This patch adds a new function to allow clients to verify, whether a
> >>> certain group is selected in the currently active setting or not.
> >>>
> >>> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@....de>
> >>> ---
> >>>
> >>> Maybe there is already a way to do this without adding a new function, I 
> >>> haven't found one, hence this patch.
> >>
> >> This function doesn't currently exist because it breaks the pinctrl
> >> conceptual model, which is that devices ask pinctrl for certain settings
> >> whenever they need them, rather than information flowing the other way.
> > 
> > Well, yes, we could tra to ask for each thinkable configuration and see 
> > which one(s) succeed, but that doesn't seem very optimal either, even if 
> > we only have 3 possibilities for now.
> > 
> >> What's the use case for this new functionality?
> > 
> > It's MMC. MMC interfaces can use 1, 4, or 8 data lines, depending on the 
> > board configuration. The board knows, that it has, say, only 4 data lines 
> > routed to the interface, so, it specifies the respective pinctrl 
> > configuration as default. Now in the driver we have to know how many 
> > data-lines are connected.
> 
> 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?

> An alternative (only when not using DT, since there's already a property
> for DT) is that the driver doesn't select pinctrl state "default", but
> instead first looks for e.g. "8bit" and if found uses it, then falls
> back to "4bit", then falls back to "1bit". Whichever state name is
> defined indicates which bus width is available.

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? 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?

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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/