linux-kernel - Re: [PATCH] mmc: mmci.c: Defer probe() in case of missing GPIOs

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: <20120616150125.GD7628@n2100.arm.linux.org.uk>
Date:	Sat, 16 Jun 2012 16:01:25 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Roland Stigge <stigge@...com.de>
Cc:	cjb@...top.org, grant.likely@...retlab.ca, rob.herring@...xeda.com,
	ulf.hansson@...ricsson.com, linus.walleij@...aro.org,
	sebastian.rasmussen@...ricsson.com, linux-mmc@...r.kernel.org,
	linux-kernel@...r.kernel.org, aletes.xgr@...il.com,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] mmc: mmci.c: Defer probe() in case of missing GPIOs

On Sat, Jun 16, 2012 at 04:57:48PM +0200, Roland Stigge wrote:
> On 16/06/12 16:26, Russell King - ARM Linux wrote:
> > On Sat, Jun 16, 2012 at 04:14:59PM +0200, Roland Stigge wrote:
> >> If the GPIOs used by the MMCI driver are not registered yet when the
> >> driver is probe()d, they can't be used. This happens if the mmci driver
> >> is probed before the respective GPIO controller (e.g. on the LPC32xx
> >> EA3250 board, the PCA9532 GPIO controller would be initialized via DT
> >> after mmci). Therefore, we defer mmci in this case.
> > 
> > This code is wrong.  There are platforms where plat->gpio_cd is negative
> > (because there isn't an associated GPIO) and we still expect the driver
> > to successfully bind.  In that case, the driver gets the CD and WP
> > information via the status callback.
> > 
> > So this is an incompatible change with existing (and required) driver
> > behaviour.
> 
> As someone just told me, in the case of no GPIO, we would have gpio_cd
> == -ENODEV. Would it be sufficient to check for -ENODEV (in which case
> we would do without GPIO), and otherwise return -EPROBE_DEFER?

Sigh.  New rules which jump up when no one's read the bloody code.
That's intensely frustrating.

Why can't the *new* DT parsing code set the GPIOs to -EPROBE_DEFER when
*it* wants them to mean "we should defer" ?  Why should the DT code
have sole use over "-1" ?  That would be *far* more logical and wouldn't
clash with anything in existing use.
--
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/