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-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
