> [...] > > >> > >> 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.
