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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <7FE21149F4667147B645348EC60578850564C5@039-SN2MPN1-013.039d.mgd.msft.net>
Date:	Thu, 15 Dec 2011 08:59:28 +0000
From:	Dong Aisheng-B29396 <B29396@...escale.com>
To:	Linus Walleij <linus.walleij@...aro.org>,
	Guo Shawn-R65073 <r65073@...escale.com>
CC:	Sascha Hauer <s.hauer@...gutronix.de>,
	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>
Subject: RE: [RFC PATCH v2 4/4] mmc: sdhci-esdhc-imx: using pinmux subsystem

> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@...aro.org]
> Sent: Thursday, December 15, 2011 4:27 PM
> To: Guo Shawn-R65073
> Cc: Sascha Hauer; Dong Aisheng-B29396; 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
> Importance: High
> 
> 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.
> 

I did not read the dummy regulator code too much.
But does it mean that the dummy regulator or dummy pinmux will also hide the
Real errors since it will always get a available one?
How do we distinguish between the two case(real error and fake error)?

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