[...] >> >> Currently drivers return error codes according to when they can't set >> the requested voltage level, so that's all fine - right? > > Yes, they should. Hovever it seems like my fsl controller cannot. > There is VS18,VS30 and VS33 bits in hostcap register but theses are > always set :( If there are set in the *hostcap* register, doesn't that indicates that they are supported? Not what's currently used!? What controller/driver are you using here? > >> >> Moreover, the above code snippet is modified by you (or someone else) >> locally, since in the upstream version of the code, the prints are > > ahh, yes a did that while debugging. > >> done a debug level. That's also okay, I think. >> Perhaps changing the last print to warn level instead, since reaching >> that point would mean all attempts have failed. > > Since not all controllers can tell what VS is you have to specify that, in my case I > do it in my device tree as there is a way to do that already. > > So I think mmc_power_up() should mask away VS not supported and then try the remaining. > The exact way to do this escapes me as I am not familiar with this area yet. Okay, I think we could potentially look at the host caps and figure out what IO voltage level the host supports before trying to set them. Although it does complicates things, so before going there I just want to be sure that we really have an issue here. I haven't yet really understood why your driver is unable to return error codes when failing to set an unsupported voltage level, you need to convince me on that. 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
