> [...]
>
> >>
> >> Well, the good news is that it didn't cause a regression for me on R-Car
> >> E2 (Alt board) and H3 (Salvator X board).
> >>
> >> Sadly, it doesn't also fix the SDR104 problems on Alt. I had a little
> >> hope this could be the culprit, but sadly it is not. But this is not a
> >> problem with this patch. It still fixes a valid issue.
> >>
> >> Looking how other drivers deal with the issue, though, I noticed they
> >> only bail out on -EPROBE_DEFER and would continue on other errors (if
> >> mmc_regulator_get_supply would throw them, but it doesn't). So some
> >> digging why other drivers do it that way seems to be apropriate to me.
> >
> > Good point!
> > Maybe if this patch explicitly tested for -EPROBE_DEFER the maintenance
> > of mmc_regulator_get_supply would be easier as all of the drivers behaved
> > similarly.
> > On the other hand, both "vmmc" and "vqmmc" are considered optional by
> > mmc_regulator_get_supply, therefore their absence is tolerated (0 is
> > returned), and as you said the only other possible value returned by
> > mmc_regulator_get_supply is -EPROBE_DEFER.
> > If in the future the logic of mmc_regulator_get_supply changes, I guess
> > even the driver needs to adapt as there may be something wrong with the
> > regulators, therefore I personally rather the driver to bail out whatever
> > the error returned by mmc_regulator_get_supply. Looking at the history
> > of the other drivers I couldn't spot any meaningful comment connected
> > to the return value of mmc_regulator_get_supply.
>
> It has been a bit tricky to deal with these regulators in *one* common
> way. For some platforms a regulator are optional, while for other it
> isn't.
>
> In the end we decided to pick the "optional" way for both vmmc and
> vqmmc, and then leave the details in the error path to be sorted out
> by each an every mmc host driver.
>
> >
> >> Or asking Ulf :)
> >
> > I guess you are right! ;)
> >
> > Ulf, what's the best option here?
>
> I think it's perfectly okay to return an error if
> mmc_regulator_get_supply() propagates that. That's likely what all
> host driver should be doing, instead of explicitly check for
> -EPROBE_DEFER.
Thank you Uffe. I guess the patch is alright then.
Wolfram, do you want to add a Tested-by?
Kind regards,
Fabrizio
>
> Of course, even when mmc_regulator_get_supply() returns 0, that's not
> a guarantee that the regulator(s) was actually hooked up.
>
> Kind regards
> Uffe
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709.
��.n��������+%������w��{.n�����{��i��)�� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
