linux-kernel - Re: [RFC PATCH v2 4/4] mmc: sdhci-esdhc-imx: using pinmux subsystem

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, 15 Dec 2011 09:26:40 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Shawn Guo <shawn.guo@...escale.com>
Cc:	Sascha Hauer <s.hauer@...gutronix.de>,
	Dong Aisheng <b29396@...escale.com>,
	linus.walleij@...ricsson.com, linux-kernel@...r.kernel.org,
	rob.herring@...xeda.com, grant.likely@...retlab.ca,
	linux-arm-kernel@...ts.infradead.org, kernel@...gutronix.de
Subject: Re: [RFC PATCH v2 4/4] mmc: sdhci-esdhc-imx: using pinmux subsystem

On Thu, Dec 15, 2011 at 8:05 AM, Shawn Guo <shawn.guo@...escale.com> wrote:
>[Me]
>> So if you want to do this for i.MX you need something like
>> selectable dummy pinmuxes, i.e. pinmux_get() to return something
>> that just say "OK" to everything like the dummy regulators.
>>
>> Shall I try to create something like that?
>>
> Isn't the empty functions defined in include/linux/pinctrl/pinmux.h
> for this purpose?

No, these are for compiling it *out*, dummy pinmuxes would
be if you compile it *in*, but don't find an apropriate pinmux,
you still get something that does nothing and still works.

Dummy regulators work exactly this way.

> It does not solve the problem with single image.

I think it does.

> You might probably mean that we create a dummy_pinctrl_desc and register
> it to pinctrl core with pinctrl_register() if we detect that the kernel
> is running on a soc that has no pinctrl support?

No. You have a #ifdef CONFIG_PINMUX_DUMMY in pinmux_get()
that makes sure you return a working no-op pinmux handle even
though there is no real pinmux behind it.

> This is not a problem to pinctrl migration only.  We have the same
> problem with common clk migration.  Unless we migrate imx3, imx5 and
> imx6 to common clk at the same time, single image build just does not
> cope with clk_* api.

And  you could have the same problem with regulator migration...
Luckily dummy regulators saves you in that case.

Thanks,
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/