Hi Fabrizio, On Wed, Oct 04, 2017 at 10:50:54AM +0000, Fabrizio Castro wrote: > Thank you guys for your comments! > > > > > However, there are side effects to it as the mmc devices will be enumerated > > > > in a different order (due to -EPROBE_DEFER), this means this patch would likely > > > > break existing platforms. > > > > > > However this doesn't. The user daemon should never relies on the > > > sequency of probing the mmc block part. We neither support to provide > > > alias for the device id, nor guarantee the first probed controller get > > > the first block id. Please use PARTUUID for rootfs, etc. So this > > > shouldn't be a big deal. > > > > That's exactly what I thought as well... > > > > Thanks for the patch! Will test it the next days, but it looks good > > already. > > How is the testing going? Any problem with the patch? Sorry for the delay, there were some other things in the queue... 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. Or asking Ulf :) Kind regards, Wolfram
Attachment:
signature.asc
Description: PGP signature
