Hi Wolfram, Ulf > 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... No worries at all! And thank you for getting back to me. > > 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. > Or asking Ulf :) I guess you are right! ;) Ulf, what's the best option here? Kind regards, Fabrizio > > Kind regards, > > Wolfram Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered No. 04586709. -- 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
