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