[PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Ulf Hansson]

According to the eMMC/SD/SDIO specs the VDD voltage level must not be changed
during the initialization, without a complete power cycle of the card.

Before this patchset, some host drivers were trying to change voltage level
at MMC_POWER_ON state, which is also what the protocol layer advised them to.
This was not correctly done and is the reason to why quite messy code in
the protocol layer has been needed, to handle a re-initialization sequence,
typically triggered from a power_restore or resume.

I have tried to make each patch in the patchset as small and separate as
possible, surely the is room for improvments. Any suggestions are appreciated.

An important note; MMC_CAP2_FULL_PWR_CYCLE, will need to be set by a host
to tell the protocol layer that the host is able to perform a complete power
cycle. Thus the protocol layer will try to negotiate the lowest possible VDD
voltage level between the card and host.


Ulf Hansson (7):
  mmc: core: Let mmc_power_up|cycle take ocr as parameter
  mmc: core: Let mmc_set_signal_voltage take ocr as parameter
  mmc: core: Remove unnecessary retry mechanism at SDIO attach
  mmc: core: Cleanup code for setting ocr mask for SDIO
  mmc: core: Move cached value of the negotiated ocr mask to card
    struct
  mmc: core: Prevent violation of specs while initializing cards
  mmc: core: Collect common code for card ocr validation

 drivers/mmc/core/core.c  |   66 +++++++++++++++++--------------------
 drivers/mmc/core/core.h  |    6 ++--
 drivers/mmc/core/mmc.c   |   29 +++++-----------
 drivers/mmc/core/sd.c    |   41 +++++++----------------
 drivers/mmc/core/sdio.c  |   82 ++++++++++++++--------------------------------
 include/linux/mmc/card.h |    1 +
 include/linux/mmc/host.h |    1 -
 7 files changed, 79 insertions(+), 147 deletions(-)

-- 
1.7.9.5

[PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Ulf Hansson]

According to the eMMC/SD/SDIO specs the VDD voltage level must not be changed
during the initialization, without a complete power cycle of the card.

Before this patchset, some host drivers were trying to change voltage level
at MMC_POWER_ON state, which is also what the protocol layer advised them to.
This was not correctly done and is the reason to why quite messy code in
the protocol layer has been needed, to handle a re-initialization sequence,
typically triggered from a power_restore or resume.

I have tried to make each patch in the patchset as small and separate as
possible, surely the is room for improvments. Any suggestions are appreciated.

An important note; MMC_CAP2_FULL_PWR_CYCLE, will need to be set by a host
to tell the protocol layer that the host is able to perform a complete power
cycle. Thus the protocol layer will try to negotiate the lowest possible VDD
voltage level between the card and host.


Ulf Hansson (7):
  mmc: core: Let mmc_power_up|cycle take ocr as parameter
  mmc: core: Let mmc_set_signal_voltage take ocr as parameter
  mmc: core: Remove unnecessary retry mechanism at SDIO attach
  mmc: core: Cleanup code for setting ocr mask for SDIO
  mmc: core: Move cached value of the negotiated ocr mask to card
    struct
  mmc: core: Prevent violation of specs while initializing cards
  mmc: core: Collect common code for card ocr validation

 drivers/mmc/core/core.c  |   66 +++++++++++++++++--------------------
 drivers/mmc/core/core.h  |    6 ++--
 drivers/mmc/core/mmc.c   |   29 +++++-----------
 drivers/mmc/core/sd.c    |   41 +++++++----------------
 drivers/mmc/core/sdio.c  |   82 ++++++++++++++--------------------------------
 include/linux/mmc/card.h |    1 +
 include/linux/mmc/host.h |    1 -
 7 files changed, 79 insertions(+), 147 deletions(-)

-- 
1.7.9.5

Re: [PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Guennadi Liakhovetski]

Hi Ulf

On Mon, 16 Sep 2013, Ulf Hansson wrote:

> According to the eMMC/SD/SDIO specs the VDD voltage level must not be changed
> during the initialization, without a complete power cycle of the card.
> 
> Before this patchset, some host drivers were trying to change voltage level
> at MMC_POWER_ON state, which is also what the protocol layer advised them to.
> This was not correctly done and is the reason to why quite messy code in
> the protocol layer has been needed, to handle a re-initialization sequence,
> typically triggered from a power_restore or resume.
> 
> I have tried to make each patch in the patchset as small and separate as
> possible, surely the is room for improvments. Any suggestions are appreciated.
> 
> An important note; MMC_CAP2_FULL_PWR_CYCLE, will need to be set by a host
> to tell the protocol layer that the host is able to perform a complete power
> cycle. Thus the protocol layer will try to negotiate the lowest possible VDD
> voltage level between the card and host.

I've got a question to this one. You mean a power cycle of a card, right? 
What if the card power is supplied by a regulator. How do you tell whether 
you can power cycle it or not? Maybe you can theoretically switch that 
regulator - sometimes. On other occasions other users might be preventing 
it from really powering off. Do you really need a guarantee, that every 
time you issue a power down .set_ios() the card will really be switched 
off? I don't see how this can be possible in my example?

Thanks
Guennadi

> 
> 
> Ulf Hansson (7):
>   mmc: core: Let mmc_power_up|cycle take ocr as parameter
>   mmc: core: Let mmc_set_signal_voltage take ocr as parameter
>   mmc: core: Remove unnecessary retry mechanism at SDIO attach
>   mmc: core: Cleanup code for setting ocr mask for SDIO
>   mmc: core: Move cached value of the negotiated ocr mask to card
>     struct
>   mmc: core: Prevent violation of specs while initializing cards
>   mmc: core: Collect common code for card ocr validation
> 
>  drivers/mmc/core/core.c  |   66 +++++++++++++++++--------------------
>  drivers/mmc/core/core.h  |    6 ++--
>  drivers/mmc/core/mmc.c   |   29 +++++-----------
>  drivers/mmc/core/sd.c    |   41 +++++++----------------
>  drivers/mmc/core/sdio.c  |   82 ++++++++++++++--------------------------------
>  include/linux/mmc/card.h |    1 +
>  include/linux/mmc/host.h |    1 -
>  7 files changed, 79 insertions(+), 147 deletions(-)
> 
> -- 
> 1.7.9.5
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Ulf Hansson]

On 16 September 2013 22:57, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> Hi Ulf
>
> On Mon, 16 Sep 2013, Ulf Hansson wrote:
>
>> According to the eMMC/SD/SDIO specs the VDD voltage level must not be changed
>> during the initialization, without a complete power cycle of the card.
>>
>> Before this patchset, some host drivers were trying to change voltage level
>> at MMC_POWER_ON state, which is also what the protocol layer advised them to.
>> This was not correctly done and is the reason to why quite messy code in
>> the protocol layer has been needed, to handle a re-initialization sequence,
>> typically triggered from a power_restore or resume.
>>
>> I have tried to make each patch in the patchset as small and separate as
>> possible, surely the is room for improvments. Any suggestions are appreciated.
>>
>> An important note; MMC_CAP2_FULL_PWR_CYCLE, will need to be set by a host
>> to tell the protocol layer that the host is able to perform a complete power
>> cycle. Thus the protocol layer will try to negotiate the lowest possible VDD
>> voltage level between the card and host.

Hi Guennadi,

>
> I've got a question to this one. You mean a power cycle of a card, right?

Correct!

> What if the card power is supplied by a regulator. How do you tell whether
> you can power cycle it or not? Maybe you can theoretically switch that
> regulator - sometimes. On other occasions other users might be preventing
> it from really powering off. Do you really need a guarantee, that every
> time you issue a power down .set_ios() the card will really be switched
> off? I don't see how this can be possible in my example?

Yes, we need a guarantee to be able to conform to the specs.

In one of my cases I am also using a regulator, but from a board
configuration point of view I know I am the only user on this
regulator, thus I can be sure I can switch it off when I want.

I see your point though, and I am not sure how to adapt to this
configuration. I suggest you to not set the MMC_CAP2_FULL_PWR_CYCLE
for that mmc host - unless you can find a way to make sure you can cut
and restore power when needed.

Kind regards
Ulf Hansson

>
> Thanks
> Guennadi
>
>>
>>
>> Ulf Hansson (7):
>>   mmc: core: Let mmc_power_up|cycle take ocr as parameter
>>   mmc: core: Let mmc_set_signal_voltage take ocr as parameter
>>   mmc: core: Remove unnecessary retry mechanism at SDIO attach
>>   mmc: core: Cleanup code for setting ocr mask for SDIO
>>   mmc: core: Move cached value of the negotiated ocr mask to card
>>     struct
>>   mmc: core: Prevent violation of specs while initializing cards
>>   mmc: core: Collect common code for card ocr validation
>>
>>  drivers/mmc/core/core.c  |   66 +++++++++++++++++--------------------
>>  drivers/mmc/core/core.h  |    6 ++--
>>  drivers/mmc/core/mmc.c   |   29 +++++-----------
>>  drivers/mmc/core/sd.c    |   41 +++++++----------------
>>  drivers/mmc/core/sdio.c  |   82 ++++++++++++++--------------------------------
>>  include/linux/mmc/card.h |    1 +
>>  include/linux/mmc/host.h |    1 -
>>  7 files changed, 79 insertions(+), 147 deletions(-)
>>
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/

Re: [PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Guennadi Liakhovetski]

(adding Mark to cc)

On Tue, 17 Sep 2013, Ulf Hansson wrote:

> On 16 September 2013 22:57, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> > Hi Ulf
> >
> > On Mon, 16 Sep 2013, Ulf Hansson wrote:
> >
> >> According to the eMMC/SD/SDIO specs the VDD voltage level must not be changed
> >> during the initialization, without a complete power cycle of the card.
> >>
> >> Before this patchset, some host drivers were trying to change voltage level
> >> at MMC_POWER_ON state, which is also what the protocol layer advised them to.
> >> This was not correctly done and is the reason to why quite messy code in
> >> the protocol layer has been needed, to handle a re-initialization sequence,
> >> typically triggered from a power_restore or resume.
> >>
> >> I have tried to make each patch in the patchset as small and separate as
> >> possible, surely the is room for improvments. Any suggestions are appreciated.
> >>
> >> An important note; MMC_CAP2_FULL_PWR_CYCLE, will need to be set by a host
> >> to tell the protocol layer that the host is able to perform a complete power
> >> cycle. Thus the protocol layer will try to negotiate the lowest possible VDD
> >> voltage level between the card and host.
> 
> Hi Guennadi,
> 
> >
> > I've got a question to this one. You mean a power cycle of a card, right?
> 
> Correct!
> 
> > What if the card power is supplied by a regulator. How do you tell whether
> > you can power cycle it or not? Maybe you can theoretically switch that
> > regulator - sometimes. On other occasions other users might be preventing
> > it from really powering off. Do you really need a guarantee, that every
> > time you issue a power down .set_ios() the card will really be switched
> > off? I don't see how this can be possible in my example?
> 
> Yes, we need a guarantee to be able to conform to the specs.
> 
> In one of my cases I am also using a regulator, but from a board
> configuration point of view I know I am the only user on this
> regulator, thus I can be sure I can switch it off when I want.
> 
> I see your point though, and I am not sure how to adapt to this
> configuration. I suggest you to not set the MMC_CAP2_FULL_PWR_CYCLE
> for that mmc host - unless you can find a way to make sure you can cut
> and restore power when needed.

So, do I understand correctly, that if we get a regulator exclusively and 
it is capable of changing status (REGULATOR_CHANGE_STATUS) and it is not 
always on, then we can assume, that every call to regulator_enable() / 
regulator_disable() with a suitable use count _will_ switch power off or 
on? Maybe then we could adjust mmc_regulator_get_supply() accordingly - 
first try to get the regulator exclusively, if it fails, try shared. If 
succeeded and the conditions are satisfied - set the new PWR_CYCLE flag.

Thanks
Guennadi

> Kind regards
> Ulf Hansson
> 
> >
> > Thanks
> > Guennadi
> >
> >>
> >>
> >> Ulf Hansson (7):
> >>   mmc: core: Let mmc_power_up|cycle take ocr as parameter
> >>   mmc: core: Let mmc_set_signal_voltage take ocr as parameter
> >>   mmc: core: Remove unnecessary retry mechanism at SDIO attach
> >>   mmc: core: Cleanup code for setting ocr mask for SDIO
> >>   mmc: core: Move cached value of the negotiated ocr mask to card
> >>     struct
> >>   mmc: core: Prevent violation of specs while initializing cards
> >>   mmc: core: Collect common code for card ocr validation
> >>
> >>  drivers/mmc/core/core.c  |   66 +++++++++++++++++--------------------
> >>  drivers/mmc/core/core.h  |    6 ++--
> >>  drivers/mmc/core/mmc.c   |   29 +++++-----------
> >>  drivers/mmc/core/sd.c    |   41 +++++++----------------
> >>  drivers/mmc/core/sdio.c  |   82 ++++++++++++++--------------------------------
> >>  include/linux/mmc/card.h |    1 +
> >>  include/linux/mmc/host.h |    1 -
> >>  7 files changed, 79 insertions(+), 147 deletions(-)
> >>
> >> --
> >> 1.7.9.5

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/

Re: [PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Ulf Hansson]

On 17 September 2013 10:16, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> (adding Mark to cc)
>
> On Tue, 17 Sep 2013, Ulf Hansson wrote:
>
>> On 16 September 2013 22:57, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
>> > Hi Ulf
>> >
>> > On Mon, 16 Sep 2013, Ulf Hansson wrote:
>> >
>> >> According to the eMMC/SD/SDIO specs the VDD voltage level must not be changed
>> >> during the initialization, without a complete power cycle of the card.
>> >>
>> >> Before this patchset, some host drivers were trying to change voltage level
>> >> at MMC_POWER_ON state, which is also what the protocol layer advised them to.
>> >> This was not correctly done and is the reason to why quite messy code in
>> >> the protocol layer has been needed, to handle a re-initialization sequence,
>> >> typically triggered from a power_restore or resume.
>> >>
>> >> I have tried to make each patch in the patchset as small and separate as
>> >> possible, surely the is room for improvments. Any suggestions are appreciated.
>> >>
>> >> An important note; MMC_CAP2_FULL_PWR_CYCLE, will need to be set by a host
>> >> to tell the protocol layer that the host is able to perform a complete power
>> >> cycle. Thus the protocol layer will try to negotiate the lowest possible VDD
>> >> voltage level between the card and host.
>>
>> Hi Guennadi,
>>
>> >
>> > I've got a question to this one. You mean a power cycle of a card, right?
>>
>> Correct!
>>
>> > What if the card power is supplied by a regulator. How do you tell whether
>> > you can power cycle it or not? Maybe you can theoretically switch that
>> > regulator - sometimes. On other occasions other users might be preventing
>> > it from really powering off. Do you really need a guarantee, that every
>> > time you issue a power down .set_ios() the card will really be switched
>> > off? I don't see how this can be possible in my example?
>>
>> Yes, we need a guarantee to be able to conform to the specs.
>>
>> In one of my cases I am also using a regulator, but from a board
>> configuration point of view I know I am the only user on this
>> regulator, thus I can be sure I can switch it off when I want.
>>
>> I see your point though, and I am not sure how to adapt to this
>> configuration. I suggest you to not set the MMC_CAP2_FULL_PWR_CYCLE
>> for that mmc host - unless you can find a way to make sure you can cut
>> and restore power when needed.
>
> So, do I understand correctly, that if we get a regulator exclusively and
> it is capable of changing status (REGULATOR_CHANGE_STATUS) and it is not
> always on, then we can assume, that every call to regulator_enable() /
> regulator_disable() with a suitable use count _will_ switch power off or
> on? Maybe then we could adjust mmc_regulator_get_supply() accordingly -
> first try to get the regulator exclusively, if it fails, try shared. If
> succeeded and the conditions are satisfied - set the new PWR_CYCLE flag.

For SD and SDIO cards, that would be enough - but not for eMMC since
we have both VCC and VCCQ.

If you want to change voltage level for eMMC, both VCC and VCCQ must
be possible to power cycle, unless you have a hw-reset wire connected
to the eMMC which is implemented by a host->ops callback. This
complicates things for SD/SDIO as well, while trying to setup the
conditions for when to set the PWR_CYCLE flag.

BTW, thanks for bringing up this discussion! I have been thinking a
bit around this as well. :-)

Kind regards
Ulf Hansson

>
> Thanks
> Guennadi
>
>> Kind regards
>> Ulf Hansson
>>
>> >
>> > Thanks
>> > Guennadi
>> >
>> >>
>> >>
>> >> Ulf Hansson (7):
>> >>   mmc: core: Let mmc_power_up|cycle take ocr as parameter
>> >>   mmc: core: Let mmc_set_signal_voltage take ocr as parameter
>> >>   mmc: core: Remove unnecessary retry mechanism at SDIO attach
>> >>   mmc: core: Cleanup code for setting ocr mask for SDIO
>> >>   mmc: core: Move cached value of the negotiated ocr mask to card
>> >>     struct
>> >>   mmc: core: Prevent violation of specs while initializing cards
>> >>   mmc: core: Collect common code for card ocr validation
>> >>
>> >>  drivers/mmc/core/core.c  |   66 +++++++++++++++++--------------------
>> >>  drivers/mmc/core/core.h  |    6 ++--
>> >>  drivers/mmc/core/mmc.c   |   29 +++++-----------
>> >>  drivers/mmc/core/sd.c    |   41 +++++++----------------
>> >>  drivers/mmc/core/sdio.c  |   82 ++++++++++++++--------------------------------
>> >>  include/linux/mmc/card.h |    1 +
>> >>  include/linux/mmc/host.h |    1 -
>> >>  7 files changed, 79 insertions(+), 147 deletions(-)
>> >>
>> >> --
>> >> 1.7.9.5
>
> ---
> Guennadi Liakhovetski, Ph.D.
> Freelance Open-Source Software Developer
> http://www.open-technology.de/

Re: [PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 522 bytes --]

On Tue, Sep 17, 2013 at 11:29:21AM +0200, Ulf Hansson wrote:

> If you want to change voltage level for eMMC, both VCC and VCCQ must
> be possible to power cycle, unless you have a hw-reset wire connected
> to the eMMC which is implemented by a host->ops callback. This
> complicates things for SD/SDIO as well, while trying to setup the
> conditions for when to set the PWR_CYCLE flag.

Should the hardware resets not be being converted over to be represented
as GPIOs (or the reset controller API) to factor things out?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Ulf Hansson]

On 17 September 2013 13:04, Mark Brown <broonie@kernel.org> wrote:
> On Tue, Sep 17, 2013 at 11:29:21AM +0200, Ulf Hansson wrote:
>
>> If you want to change voltage level for eMMC, both VCC and VCCQ must
>> be possible to power cycle, unless you have a hw-reset wire connected
>> to the eMMC which is implemented by a host->ops callback. This
>> complicates things for SD/SDIO as well, while trying to setup the
>> conditions for when to set the PWR_CYCLE flag.
>
> Should the hardware resets not be being converted over to be represented
> as GPIOs (or the reset controller API) to factor things out?

In some cases the power is controlled from inside the mmc controller,
thus writing to some of it's registers will affect the power to the
card. In other cases I believe we should be able to consider them as
GPIOs. I think this is the reason to why a specific mmc host->ops is
being used, to cover all cases.

Maybe converting them to the "reset controller API" would be suitable
for all cases, not sure.

Note that, as of today only some sdhci variants have implemented the
hw-reset support.

Kind regards
Ulf Hansson

Re: [PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Ulf Hansson]

On 17 September 2013 14:50, Ulf Hansson <ulf.hansson@linaro.org> wrote:
> On 17 September 2013 13:04, Mark Brown <broonie@kernel.org> wrote:
>> On Tue, Sep 17, 2013 at 11:29:21AM +0200, Ulf Hansson wrote:
>>
>>> If you want to change voltage level for eMMC, both VCC and VCCQ must
>>> be possible to power cycle, unless you have a hw-reset wire connected
>>> to the eMMC which is implemented by a host->ops callback. This
>>> complicates things for SD/SDIO as well, while trying to setup the
>>> conditions for when to set the PWR_CYCLE flag.
>>
>> Should the hardware resets not be being converted over to be represented
>> as GPIOs (or the reset controller API) to factor things out?
>
> In some cases the power is controlled from inside the mmc controller,
> thus writing to some of it's registers will affect the power to the
> card. In other cases I believe we should be able to consider them as
> GPIOs. I think this is the reason to why a specific mmc host->ops is
> being used, to cover all cases.
>
> Maybe converting them to the "reset controller API" would be suitable
> for all cases, not sure.
>
> Note that, as of today only some sdhci variants have implemented the
> hw-reset support.
>
> Kind regards
> Ulf Hansson

Hi Mark & Guennadi,

I appreciated you ideas and thoughts around this patchset.

To go forward, I suppose our discussion shall not prevent Chris from
merging this patchset? We shall be able to address your input as work
on top if this patchset, right?

Kind regards
Ulf Hansson

Re: [PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 372 bytes --]

On Fri, Sep 27, 2013 at 11:56:26AM +0200, Ulf Hansson wrote:

> To go forward, I suppose our discussion shall not prevent Chris from
> merging this patchset? We shall be able to address your input as work
> on top if this patchset, right?

To be honest I don't think I saw the original patches so I can't offer
much comment either way but that seems like a sensible idea.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH 0/7] mmc: core: Fixup ocr mask setup to prevent spec violation

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1338 bytes --]

On Tue, Sep 17, 2013 at 10:16:06AM +0200, Guennadi Liakhovetski wrote:

*Please* remember to trim context when replying.

> On Tue, 17 Sep 2013, Ulf Hansson wrote:
> 
> > In one of my cases I am also using a regulator, but from a board
> > configuration point of view I know I am the only user on this
> > regulator, thus I can be sure I can switch it off when I want.

> So, do I understand correctly, that if we get a regulator exclusively and 
> it is capable of changing status (REGULATOR_CHANGE_STATUS) and it is not 
> always on, then we can assume, that every call to regulator_enable() / 
> regulator_disable() with a suitable use count _will_ switch power off or 
> on? Maybe then we could adjust mmc_regulator_get_supply() accordingly - 
> first try to get the regulator exclusively, if it fails, try shared. If 
> succeeded and the conditions are satisfied - set the new PWR_CYCLE flag.

This use case is what regulator_get_exclusive() was added for.  The
method you are suggesting there is not a good one, though - if the
supply is shared it will cause the first MMC controller to get the
regulator and the others to fail.  However I think we should probably
fix this by having code in the regulator core which checks if multiple
consumers are mapped and refuses to allow get_exclusive() in that case.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]