| Message ID | 1355389980-5532-2-git-send-email-paolo.pisati@canonical.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Dec 13, 2012 at 10:13:00AM +0100, Paolo Pisati wrote: > Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> > Tested-by: Robert Nelson <robertcnelson@gmail.com> please read Documentation/stable_kernel_rules.txt, you'll see this is wrong.
On Thu, Dec 13, 2012 at 11:47:15AM +0200, Felipe Balbi wrote: > On Thu, Dec 13, 2012 at 10:13:00AM +0100, Paolo Pisati wrote: > > Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> > > Tested-by: Robert Nelson <robertcnelson@gmail.com> > > please read Documentation/stable_kernel_rules.txt, you'll see this is > wrong. you mean that i should have waited for the commit to hit Linus's tree before cc-ing stable?
Hi, On Fri, Dec 14, 2012 at 04:39:43PM +0100, Paolo Pisati wrote: > On Thu, Dec 13, 2012 at 11:47:15AM +0200, Felipe Balbi wrote: > > On Thu, Dec 13, 2012 at 10:13:00AM +0100, Paolo Pisati wrote: > > > Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> > > > Tested-by: Robert Nelson <robertcnelson@gmail.com> > > > > please read Documentation/stable_kernel_rules.txt, you'll see this is > > wrong. > > you mean that i should have waited for the commit to hit Linus's tree before > cc-ing stable? No no, I mean that before you SoB you should have a: Cc: <stable@vger.kernel.org> # v3.x v3.y ... Something like the commit below: commit 041d81f493d90c940ec41f0ec98bc7c4f2fba431 Author: Felipe Balbi <balbi@ti.com> Date: Thu Oct 4 11:58:00 2012 +0300 usb: dwc3: gadget: fix 'endpoint always busy' bug If a USB transfer has already been started, meaning we have already issued StartTransfer command to that particular endpoint, DWC3_EP_BUSY flag has also already been set. When we try to cancel this transfer which is already in controller's cache, we will not receive XferComplete event and we must clear DWC3_EP_BUSY in order to allow subsequent requests to be properly started. The best place to clear that flag is right after issuing DWC3_DEPCMD_ENDTRANSFER. Cc: stable@vger.kernel.org # v3.4 v3.5 v3.6 Reported-by: Moiz Sonasath <m-sonasath@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com>
On Fri, Dec 14, 2012 at 05:40:30PM +0200, Felipe Balbi wrote: > No no, I mean that before you SoB you should have a: > Cc: <stable@vger.kernel.org> # v3.x v3.y ... It's perfectly OK to omit this unless there's an awareness that the backport won't work on some kernels.
On Thu, Dec 13, 2012 at 10:13:00AM +0100, Paolo Pisati wrote: > Signed-off-by: Paolo Pisati <paolo.pisati@canonical.com> > Tested-by: Robert Nelson <robertcnelson@gmail.com> Applied, thanks.
Hi, On Sat, Dec 15, 2012 at 11:15:20PM +0900, Mark Brown wrote: > On Fri, Dec 14, 2012 at 05:40:30PM +0200, Felipe Balbi wrote: > > > No no, I mean that before you SoB you should have a: > > > Cc: <stable@vger.kernel.org> # v3.x v3.y ... > > It's perfectly OK to omit this unless there's an awareness that the > backport won't work on some kernels. that's not what Greg says, but fair enough. Won't discuss it...
On Sat, Dec 15, 2012 at 04:57:38PM +0200, Felipe Balbi wrote: > On Sat, Dec 15, 2012 at 11:15:20PM +0900, Mark Brown wrote: > > It's perfectly OK to omit this unless there's an awareness that the > > backport won't work on some kernels. > that's not what Greg says, but fair enough. Won't discuss it... Uh, no. Think about this for a minute - we want bug fixes backporting, we don't want to be putting process blockers in the way of that especially not in the cases where fixes apply to all the stable kernels that are currently active.
Hi, On Mon, Dec 17, 2012 at 02:15:36PM +0000, Mark Brown wrote: > On Sat, Dec 15, 2012 at 04:57:38PM +0200, Felipe Balbi wrote: > > On Sat, Dec 15, 2012 at 11:15:20PM +0900, Mark Brown wrote: > > > > It's perfectly OK to omit this unless there's an awareness that the > > > backport won't work on some kernels. > > > that's not what Greg says, but fair enough. Won't discuss it... > > Uh, no. Think about this for a minute - we want bug fixes backporting, > we don't want to be putting process blockers in the way of that > especially not in the cases where fixes apply to all the stable kernels > that are currently active. then omit the # v3.x, v3.y part, but Cc: stable@vger.kernel.org should still be there
On Mon, Dec 17, 2012 at 05:18:48PM +0200, Felipe Balbi wrote: > On Mon, Dec 17, 2012 at 02:15:36PM +0000, Mark Brown wrote: > > Uh, no. Think about this for a minute - we want bug fixes backporting, > > we don't want to be putting process blockers in the way of that > > especially not in the cases where fixes apply to all the stable kernels > > that are currently active. > then omit the # v3.x, v3.y part, but Cc: stable@vger.kernel.org should > still be there Oh, yes - that's needed. Sorry, I thought it was the v3.x bit you were complaining was missing.
diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c index e872c8b..c347fd0 100644 --- a/drivers/regulator/core.c +++ b/drivers/regulator/core.c @@ -2250,6 +2250,7 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV) { struct regulator_dev *rdev = regulator->rdev; int ret = 0; + int old_min_uV, old_max_uV; mutex_lock(&rdev->mutex); @@ -2271,18 +2272,29 @@ int regulator_set_voltage(struct regulator *regulator, int min_uV, int max_uV) ret = regulator_check_voltage(rdev, &min_uV, &max_uV); if (ret < 0) goto out; + + /* restore original values in case of error */ + old_min_uV = regulator->min_uV; + old_max_uV = regulator->max_uV; regulator->min_uV = min_uV; regulator->max_uV = max_uV; ret = regulator_check_consumers(rdev, &min_uV, &max_uV); if (ret < 0) - goto out; + goto out2; ret = _regulator_do_set_voltage(rdev, min_uV, max_uV); - + if (ret < 0) + goto out2; + out: mutex_unlock(&rdev->mutex); return ret; +out2: + regulator->min_uV = old_min_uV; + regulator->max_uV = old_max_uV; + mutex_unlock(&rdev->mutex); + return ret; } EXPORT_SYMBOL_GPL(regulator_set_voltage);