| Message ID | 20131120175814.GC27423@saruman.home (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
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.
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...
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.
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.
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
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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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:-) -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
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.
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)
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(-)