On Thu, 16 Apr 2020 at 16:45, Marek Vasut <marex@xxxxxxx> wrote: > > On 4/16/20 2:07 PM, Ulf Hansson wrote: > > On Thu, 16 Apr 2020 at 12:29, Marek Vasut <marex@xxxxxxx> wrote: > >> > >> On 4/15/20 10:40 AM, Ulf Hansson wrote: > >>> On Wed, 1 Apr 2020 at 21:57, Marek Vasut <marex@xxxxxxx> wrote: > >>>> > >>>> Patch all drivers and core code which uses mmc_set_signal_voltage() > >>>> and prepare it for the fact that mmc_set_signal_voltage() can return > >>>> a value > 0, which would happen if the signal voltage switch did NOT > >>>> happen, because the voltage was already set correctly. > >>> > >>> I am not sure why you want to change mmc_set_signal_voltage(), can you > >>> elaborate on that? > >>> > >>> I thought we discussed changing mmc_regulator_set_vqmmc(), what am I missing? > >> > >> Because mmc_set_signal_voltage() optionally calls > >> host->ops_>start_signal_voltage_switch() , which can now return value > > >> 0 , so the rest of the core needs to be patched to cater for that. > > > > The issue that you wanted to solve (at least by looking at the > > original patch) was to understand whether the vqmmc regulator changes > > voltage level and then take different actions based on that in the > > mmci host driver. > > > > You don't need to change anything related to mmc_set_signal_voltage() > > to accomplish that, do you? Moreover, I am worried that it may affect > > the host driver's expectations from when > > ->start_signal_voltage_switch() may be called. > > So, shall I just patch all the sites which use mmc_regulator_set_vqmmc() > with something like > > return mmc_regulator_set_vqmmc(); > becomes > ret = mmc_regulator_set_vqmmc(); > if (ret > 0) > ret = 0; > return ret; Yes, something along the lines of that. Or if you think it's better to make mmc_regulator_set_vqmmc() to pass an out parameter. Whatever you think looks best, I am fine with whatever. Kind regards Uffe