commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Felipe Balbi]

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

Hi,

commit c368e5fc2a190923b786f2de3e79430ea3566a25 (regulator: fixed: get
rid of {get|list}_voltage()) regresses any MMC host controller which
uses fixed regulator for functionality.

Note that mmc core uses regulator_list_voltage() to setup OCR mask and
that has a check for missing ->list_voltage() method.

Reverting that commit makes beablebone black and white work with today's
Linus' HEAD.

That commit should either be reverted or regulator_list_voltages()
should be fixed up accordingly.

Proposed patch below:

8<------------------------ cut here -----------------------------------

From 807bb4e91eea46390f184b737f7f8dc634e62a01 Mon Sep 17 00:00:00 2001
From: Felipe Balbi <balbi@ti.com>
Date: Wed, 20 Nov 2013 11:52:33 -0600
Subject: [PATCH] regulator: core: fix regulator_list_voltage()

commit c368e5f (regulator: fixed: get rid of
{get|list}_voltage()) caused a regression
for any MMC host which uses a fixed regulator.

MMC core uses regulator_list_voltage() to
setup card's OCR mask. Unfortunately, said
commit missed the fact that regulator_list_voltage()
would bail out early if ->list_voltage()
implementation is missing.

This was not a problem before, since fixed
regulator implemented that callback.

The best solution is to patch regulator_list_voltage()
itself, since MMC core shouldn't have to know
which regulator type it's using.

Signed-off-by: Felipe Balbi <balbi@ti.com>
---
 drivers/regulator/core.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 6382f0a..0da48ae 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2181,15 +2181,21 @@ EXPORT_SYMBOL_GPL(regulator_count_voltages);
 int regulator_list_voltage(struct regulator *regulator, unsigned selector)
 {
 	struct regulator_dev	*rdev = regulator->rdev;
-	struct regulator_ops	*ops = rdev->desc->ops;
+	const struct regulator_desc *desc = rdev->desc;
+	struct regulator_ops	*ops = desc->ops;
 	int			ret;
 
-	if (!ops->list_voltage || selector >= rdev->desc->n_voltages)
+	if ((!ops->list_voltage && !desc->fixed_uV) ||
+			selector >= rdev->desc->n_voltages)
 		return -EINVAL;
 
-	mutex_lock(&rdev->mutex);
-	ret = ops->list_voltage(rdev, selector);
-	mutex_unlock(&rdev->mutex);
+	if (ops->list_voltage) {
+		mutex_lock(&rdev->mutex);
+		ret = ops->list_voltage(rdev, selector);
+		mutex_unlock(&rdev->mutex);
+	} else /* if (desc->fixed_uV) */ {
+		ret = desc->fixed_uV;
+	}
 
 	if (ret > 0) {
 		if (ret < rdev->constraints->min_uV)
-- 
1.8.4.GIT


-- 
balbi

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

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Mark Brown]

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

On Wed, Nov 20, 2013 at 11:58:14AM -0600, Felipe Balbi wrote:

> commit c368e5fc2a190923b786f2de3e79430ea3566a25 (regulator: fixed: get
> rid of {get|list}_voltage()) regresses any MMC host controller which
> uses fixed regulator for functionality.

This is already fixed in -next.  Please remember to always CC
maintainers on mails and please try to write subject lines which are
readable by humans - full SHA1s for commits that obscure any actual
content don't help.

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

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Felipe Balbi]

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

Hi,

On Wed, Nov 20, 2013 at 08:34:00PM +0000, Mark Brown wrote:
> On Wed, Nov 20, 2013 at 11:58:14AM -0600, Felipe Balbi wrote:
> 
> > commit c368e5fc2a190923b786f2de3e79430ea3566a25 (regulator: fixed: get
> > rid of {get|list}_voltage()) regresses any MMC host controller which
> > uses fixed regulator for functionality.
> 
> This is already fixed in -next.  Please remember to always CC
> maintainers on mails and please try to write subject lines which are

that's why Liam and Laxman are in Cc. Looks like only you were missed.

> readable by humans - full SHA1s for commits that obscure any actual
> content don't help.

right...

-- 
balbi

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

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Felipe Balbi]

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

On Wed, Nov 20, 2013 at 02:51:43PM -0600, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Nov 20, 2013 at 08:34:00PM +0000, Mark Brown wrote:
> > On Wed, Nov 20, 2013 at 11:58:14AM -0600, Felipe Balbi wrote:
> > 
> > > commit c368e5fc2a190923b786f2de3e79430ea3566a25 (regulator: fixed: get
> > > rid of {get|list}_voltage()) regresses any MMC host controller which
> > > uses fixed regulator for functionality.
> > 
> > This is already fixed in -next.  Please remember to always CC
> > maintainers on mails and please try to write subject lines which are
> 
> that's why Liam and Laxman are in Cc. Looks like only you were missed.

actually, I didn't miss you at all. your broonie@linaro.org was in Cc
of original email thread. The same email which was used to sign-off on
original commit.

-- 
balbi

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

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Mark Brown]

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

On Wed, Nov 20, 2013 at 08:48:41PM -0600, Felipe Balbi wrote:

> actually, I didn't miss you at all. your broonie@linaro.org was in Cc
> of original email thread. The same email which was used to sign-off on
> original commit.

It's not what's advertised in MAINTAINERS, you should be sending stuff
to that address.  My work account is completely separate and for various
reasons (including the fact that a lot of the mails for upstream sent
there are duplicates of mails sent here) non-automatic upstream stuff
has a good chance of getting dropped on the floor and at the very least
will be dealt with more slowly.

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

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Felipe Balbi]

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

Hi,

On Thu, Nov 21, 2013 at 10:49:11AM +0000, Mark Brown wrote:
> On Wed, Nov 20, 2013 at 08:48:41PM -0600, Felipe Balbi wrote:
> 
> > actually, I didn't miss you at all. your broonie@linaro.org was in Cc
> > of original email thread. The same email which was used to sign-off on
> > original commit.
> 
> It's not what's advertised in MAINTAINERS, you should be sending stuff
> to that address.  My work account is completely separate and for various
> reasons (including the fact that a lot of the mails for upstream sent
> there are duplicates of mails sent here) non-automatic upstream stuff
> has a good chance of getting dropped on the floor and at the very least
> will be dealt with more slowly.

still, your claim that I didn't Cc any maintainer is completely bogus

-- 
balbi

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

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Stephen Warren]

On 11/21/2013 03:49 AM, Mark Brown wrote:
> On Wed, Nov 20, 2013 at 08:48:41PM -0600, Felipe Balbi wrote:
> 
>> actually, I didn't miss you at all. your broonie@linaro.org was
>> in Cc of original email thread. The same email which was used to
>> sign-off on original commit.
> 
> It's not what's advertised in MAINTAINERS, you should be sending
> stuff to that address.  My work account is completely separate and
> for various reasons (including the fact that a lot of the mails for
> upstream sent there are duplicates of mails sent here)
> non-automatic upstream stuff has a good chance of getting dropped
> on the floor and at the very least will be dealt with more slowly.

FYI, the way I deal with this is that my preferred email account
subscribes to the mailing list, and I have a filter such that anything
that's to/cc either *that* email address *or* any of my other email
addresses gets handled the same, and dumped in my (list) inbox rather
than in a mailing list folder.

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Mark Brown]

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

On Thu, Nov 21, 2013 at 09:43:03AM -0700, Stephen Warren wrote:

> FYI, the way I deal with this is that my preferred email account
> subscribes to the mailing list, and I have a filter such that anything
> that's to/cc either *that* email address *or* any of my other email
> addresses gets handled the same, and dumped in my (list) inbox rather
> than in a mailing list folder.

I used to do that but I found it tended to create annoying duplicates
more often than it was helpful.  It's also a bit of an issue for me that
there are other people with the same name who work upstream so I do also
find people from time to time picking the wrong Mark Brown to e-mail.

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

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Stephen Warren]

On 11/21/2013 11:36 AM, Mark Brown wrote:
> On Thu, Nov 21, 2013 at 09:43:03AM -0700, Stephen Warren wrote:
> 
>> FYI, the way I deal with this is that my preferred email account 
>> subscribes to the mailing list, and I have a filter such that
>> anything that's to/cc either *that* email address *or* any of my
>> other email addresses gets handled the same, and dumped in my
>> (list) inbox rather than in a mailing list folder.
> 
> I used to do that but I found it tended to create annoying
> duplicates more often than it was helpful.  It's also a bit of an
> issue for me that there are other people with the same name who
> work upstream so I do also find people from time to time picking
> the wrong Mark Brown to e-mail.

Ah yes. I also have a delivery-time filter that remembers the last n
Message-Id headers I've received, and it dumps any duplicates into a
separate folder that I ignore. It seems to work pretty well. It looks
like n==10000 for me right now.

I could post the scripts on github if people think they're useful.
Hopefully there aren't security bugs:-)

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Mark Brown]

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

On Thu, Nov 21, 2013 at 11:44:23AM -0700, Stephen Warren wrote:

> Ah yes. I also have a delivery-time filter that remembers the last n
> Message-Id headers I've received, and it dumps any duplicates into a
> separate folder that I ignore. It seems to work pretty well. It looks
> like n==10000 for me right now.

Yeah, that wasn't working great - I think because I was doing it in the
wrong place and it was catching lists too.

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

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Olof Johansson]

On Thu, Nov 21, 2013 at 2:49 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Nov 20, 2013 at 08:48:41PM -0600, Felipe Balbi wrote:
>
>> actually, I didn't miss you at all. your broonie@linaro.org was in Cc
>> of original email thread. The same email which was used to sign-off on
>> original commit.
>
> It's not what's advertised in MAINTAINERS, you should be sending stuff
> to that address.  My work account is completely separate and for various
> reasons (including the fact that a lot of the mails for upstream sent
> there are duplicates of mails sent here) non-automatic upstream stuff
> has a good chance of getting dropped on the floor and at the very least
> will be dealt with more slowly.

If you have one email address listed in MAINTAINERS, and do all your
actual work with another identity, you might want to look at your
workflow a bit. I suggest either signing off with the MAINTAINERS
email address, or changing the entries of that file. People should
expect to be able to email you on the address you sign off with.


-Olof

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Mark Brown]

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

On Thu, Nov 21, 2013 at 12:27:06PM -0800, Olof Johansson wrote:

> If you have one email address listed in MAINTAINERS, and do all your
> actual work with another identity, you might want to look at your
> workflow a bit. I suggest either signing off with the MAINTAINERS

The only thing that uses the work address is patches and signoffs, all
my e-mail traffic is done from my kernel.org address (including patch
posts).

> email address, or changing the entries of that file. People should
> expect to be able to email you on the address you sign off with.

Unfortunately my employer can't cope with that at present and I don't
really want to use my work address for everything since all the stuff
from upstream DoSs the stuff that pays the bills.  I wouldn't mind if
people mailed both, but if you're going to pick a single one then the
one listed in MAINTAINERS is the way forwards (which generally is the
address people manage to pick).

/me notes that he'd probably have been less grumpy if the message had
a subject line that had content in it, even had it gone to the right
mailbox there's a good chance I'd never even have opened the mail due to
that - if anything it going to the wrong place actually worked around
the subject line here.

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

Re: commit c368e5fc2a190923b786f2de3e79430ea3566a25 regresses MMC

[Felipe Balbi]

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

Hi,

On Thu, Nov 21, 2013 at 08:50:50PM +0000, Mark Brown wrote:
> /me notes that he'd probably have been less grumpy if the message had
> a subject line that had content in it, even had it gone to the right

oh cut the crap already. It contained the commit sha1 and a pretty
self-explanatory "regresses MMC". You can't expect me to put everything
in the subject and you're only "grumpy" because you're too lazy to move
your neck 5 degrees to the right to read the rest of the line.

what a long thread for such a small issue Mark, just stop it already.
The issue is fixed in -next and that's what matters, everybody's happy.

I know I am with my working MMC on BBB.

-- 
balbi

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