[PATCHv2 1/2] ARM: dts: socfpga: Fix SD card detect

[Mark Rutland]

On Tue, Oct 21, 2014 at 01:02:28AM +0100, Doug Anderson wrote:
> Mark,
> 
> On Mon, Oct 20, 2014 at 3:41 PM, Mark Rutland <mark.rutland at arm.com> wrote:
> > On Mon, Oct 20, 2014 at 08:26:55PM +0100, Doug Anderson wrote:
> >> Mark,
> >>
> >> On Mon, Oct 20, 2014 at 11:41 AM, Mark Rutland <mark.rutland at arm.com> wrote:
> >> > On Mon, Oct 20, 2014 at 04:31:18PM +0100, dinguyen at opensource.altera.com wrote:
> >> >> From: Dinh Nguyen <dinguyen at opensource.altera.com>
> >> >>
> >> >> Without this patch, the booting the SOCFPGA platform would hang at the
> >> >> SDMMC driver loading. There were 2 patches that caused this to happen:
> >> >>
> >> >> - Patch 9795a846e10 "mmc: dw_mmc: remove dw_mci_of_cd_gpio/wp_gpio()" removed
> >> >>   looking for "cd-gpios", since mmc_of_parse was getting called.
> >> >> - Patch 3cf890fc42b "mmc: dw_mmc: Pass back errors from mmc_of_parse()" would
> >> >>   hang the system at the SDMMC driver loading.
> >> >
> >> > Regardless of which patches caused the issue, the existing DTB should
> >> > continue to function. This is a kernel bug, not a DTB bug.
> >>
> >> Right.  The kernel bug is that there is no "dtb fixup" stage of the
> >> kernel to fix up old dtbs with this dtb bug.
> >>
> >> Said another way:
> >>
> >> 1. The old dtb was (possibly) not specifying the cd-gpio properly.
> >>
> >> 2. The kernel had a bug where it was ignoring that error.  Things may
> >> have been working because of some other side effect (maybe polling was
> >> working).
> >>
> >> 3. If we fix the kernel bug, what should we do?  The only sensible
> >> thing (if we need to support old DTB with no changes) is to add a DTB
> >> fixup stage.
> >>
> >> ...or did someone add that stage and I missed it?
> >
> > Unfortunately, we have no generic DTB fixup stage currently.
> 
> Right.  ...and that's the bug.
> 
> I think we may need to modify the general inclination to respond to
> dts change requests with "the DTS can't have a bug in it".  DTS files
> can indeed have bugs in it.  In this case the dts file was claiming
> that the card detect GPIO was a GPIO on a controller that the same dts
> claimed was "disabled".  If that's not a bug in the DTS I'm not sure
> what it is.

While it's unusual, it's not necessarily a bug in general-- the link
might be true (i.e. that particular GPIO might be attached to the CD
line), but for some reason the GPIO controller is unusable on a
particular board. Perhaps we need to distinguish not ready yet from will
never be ready -- at least for provider nodes with status = "disabled"
that should be obvious.

That said, this was not an intentional property of this DTB.

> There are all sorts of broken ways that we could work around this in
> the driver.  We could pretend that EPROBE_DEFER really meant "I'm all
> good".  We could add a special case for this particular board in
> dw_mmc (do we check the overall device tree compatible string?).  We
> could do all sorts of hacks.  None of them are right.  The "right"
> behavior if we really care about maintaining compatbility with old DTB
> files is to add a fixup stage for this particular broken board.

While a DTB fixup stage is something which we are likely to need at some
point, it comes with its own (rather large) cost. I disagree that DTB
fixup is the one and only way of handling this kind of issue.

> Given that no such fixup stage exists, if someone really wants old DTB
> files to work then we should add one.

Perhaps. In this case I guess this comes down to whether socfpga users
are happy to update their DTBs.

Thanks,
Mark.