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: <CACRpkdbN26q1_d4tPkJp4f4_KdvoEEk9uCCRyOfEU97DOWAnEw@mail.gmail.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ