Message ID | 1358511445-26656-1-git-send-email-rogerq@ti.com |
---|---|
State | New |
Headers | show |
On 01/18/2013 02:17 PM, Roger Quadros wrote: > This driver does not request any gpios so don't free them. > Fixes L3 bus error on multiple modprobe/rmmod of ehci_hcd > with ehci-omap in use. > > Without this patch, EHCI will break on repeated insmod/rmmod > of ehci_hcd for all OMAP2+ platforms that use EHCI and > set 'phy_reset = true' in usbhs_omap_board_data. > i.e. > > board-3430sdp.c: .phy_reset = true, > board-3630sdp.c: .phy_reset = true, > board-am3517crane.c: .phy_reset = true, > board-am3517evm.c: .phy_reset = true, > board-cm-t3517.c: .phy_reset = true, > board-cm-t35.c: .phy_reset = true, > board-devkit8000.c: .phy_reset = true, > board-igep0020.c: .phy_reset = true, > board-igep0020.c: .phy_reset = true, > board-omap3beagle.c: .phy_reset = true, > board-omap3evm.c: .phy_reset = true, > board-omap3pandora.c: .phy_reset = true, > board-omap3stalker.c: .phy_reset = true, > board-omap3touchbook.c: .phy_reset = true, > board-omap4panda.c: .phy_reset = false, > board-overo.c: .phy_reset = true, > board-zoom.c: .phy_reset = true, > > CC: Alan Stern <stern@rowland.harvard.edu> > Cc: stable@kernel.org I messed up with the stable list id, so will resend just this one and update the git repo. > > Signed-off-by: Roger Quadros <rogerq@ti.com> > Reviewed-by: Felipe Balbi <balbi@ti.com> > Acked-by: Alan Stern <stern@rowland.harvard.edu> cheers, -roger
On Fri, Jan 18, 2013 at 02:17:08PM +0200, Roger Quadros wrote: > + tll->ch_clk = devm_kzalloc(dev, sizeof(struct clk * [tll->nch]), > + GFP_KERNEL); > + if (!tll->ch_clk) { > + ret = -ENOMEM; > + dev_err(dev, "Couldn't allocate memory for channel clocks\n"); > + goto err_clk_alloc; > + } > + > + for (i = 0; i < tll->nch; i++) { > + char clkname[] = "usb_tll_hs_usb_chx_clk"; > + struct clk *fck; > + > + snprintf(clkname, sizeof(clkname), > + "usb_tll_hs_usb_ch%d_clk", i); > + fck = clk_get(dev, clkname); > + > + if (IS_ERR(fck)) > + dev_dbg(dev, "can't get clock : %s\n", clkname); > + else > + tll->ch_clk[i] = fck; Hmm. I'd actually suggest that this becomes: tll->ch_clk[i] = fck; if (IS_ERR(fck) dev_dbg(dev, "can't get clock: %s\n", clkname); so that tll->ch_clk is always written to. > static int usbtll_omap_remove(struct platform_device *pdev) > { > struct usbtll_omap *tll = platform_get_drvdata(pdev); > + int i; > + > + for (i = 0; i < tll->nch; i++) > + clk_put(tll->ch_clk[i]); And change this to: for (i = 0; i < tll->nch; i++) if (!IS_ERR(tll->ch_clk[i])) clk_put(tll->ch_clk[i]); so that you're not passing a NULL pointer in. > + for (i = 0; i < tll->nch; i++) { > + if (is_ehci_tll_mode(pdata->port_mode[i])) { > + int r; > > - if (is_ehci_tll_mode(pdata->port_mode[1])) > - clk_enable(tll->usbtll_p2_fck); > + if (!tll->ch_clk[i]) if (IS_ERR(tll->ch_clk[i])) > + continue; > + > + r = clk_enable(tll->ch_clk[i]); > + if (r) { > + dev_err(dev, > + "Error enabling ch %d clock: %d\n", i, r); > + } > + } > + } > @@ -387,11 +409,12 @@ static int usbtll_runtime_suspend(struct device *dev) > > spin_lock_irqsave(&tll->lock, flags); > > - if (is_ehci_tll_mode(pdata->port_mode[0])) > - clk_disable(tll->usbtll_p1_fck); > - > - if (is_ehci_tll_mode(pdata->port_mode[1])) > - clk_disable(tll->usbtll_p2_fck); > + for (i = 0; i < tll->nch; i++) { > + if (is_ehci_tll_mode(pdata->port_mode[i])) { > + if (tll->ch_clk[i]) if (!IS_ERR(tll->ch_clk[i])) > + clk_disable(tll->ch_clk[i]); > + } > + } > > spin_unlock_irqrestore(&tll->lock, flags); > > -- > 1.7.4.1 >
On Fri, Jan 18, 2013 at 02:17:09PM +0200, Roger Quadros wrote: > +/* only PHY and UNUSED modes don't need TLL */ > +#define omap_usb_mode_needs_tll(x) ((x != OMAP_USBHS_PORT_MODE_UNUSED) &&\ > + (x != OMAP_EHCI_PORT_MODE_PHY)) Growl. These parens do not make anything safer at all - they just obfuscate. The safe version of the above macro would have been: #define omap_usb_mode_needs_tll(x) ((x) != OMAP_USBHS_PORT_MODE_UNUSED &&\ (x) != OMAP_EHCI_PORT_MODE_PHY) If you're going to use a macro argument in an expression, it needs parens. Simple expressions like a != b && c != d do _not_ need parens.
On 01/18/2013 04:59 PM, Russell King - ARM Linux wrote: > On Fri, Jan 18, 2013 at 02:17:08PM +0200, Roger Quadros wrote: >> + tll->ch_clk = devm_kzalloc(dev, sizeof(struct clk * [tll->nch]), >> + GFP_KERNEL); >> + if (!tll->ch_clk) { >> + ret = -ENOMEM; >> + dev_err(dev, "Couldn't allocate memory for channel clocks\n"); >> + goto err_clk_alloc; >> + } >> + >> + for (i = 0; i < tll->nch; i++) { >> + char clkname[] = "usb_tll_hs_usb_chx_clk"; >> + struct clk *fck; >> + >> + snprintf(clkname, sizeof(clkname), >> + "usb_tll_hs_usb_ch%d_clk", i); >> + fck = clk_get(dev, clkname); >> + >> + if (IS_ERR(fck)) >> + dev_dbg(dev, "can't get clock : %s\n", clkname); >> + else >> + tll->ch_clk[i] = fck; > > Hmm. I'd actually suggest that this becomes: > > tll->ch_clk[i] = fck; > if (IS_ERR(fck) > dev_dbg(dev, "can't get clock: %s\n", clkname); > > so that tll->ch_clk is always written to. Yes, I'll fix this. > >> static int usbtll_omap_remove(struct platform_device *pdev) >> { >> struct usbtll_omap *tll = platform_get_drvdata(pdev); >> + int i; >> + >> + for (i = 0; i < tll->nch; i++) >> + clk_put(tll->ch_clk[i]); > > And change this to: > > for (i = 0; i < tll->nch; i++) > if (!IS_ERR(tll->ch_clk[i])) > clk_put(tll->ch_clk[i]); > > so that you're not passing a NULL pointer in. > ok. >> + for (i = 0; i < tll->nch; i++) { >> + if (is_ehci_tll_mode(pdata->port_mode[i])) { >> + int r; >> >> - if (is_ehci_tll_mode(pdata->port_mode[1])) >> - clk_enable(tll->usbtll_p2_fck); >> + if (!tll->ch_clk[i]) > > if (IS_ERR(tll->ch_clk[i])) ok. > >> + continue; >> + >> + r = clk_enable(tll->ch_clk[i]); >> + if (r) { >> + dev_err(dev, >> + "Error enabling ch %d clock: %d\n", i, r); >> + } >> + } >> + } > >> @@ -387,11 +409,12 @@ static int usbtll_runtime_suspend(struct device *dev) >> >> spin_lock_irqsave(&tll->lock, flags); >> >> - if (is_ehci_tll_mode(pdata->port_mode[0])) >> - clk_disable(tll->usbtll_p1_fck); >> - >> - if (is_ehci_tll_mode(pdata->port_mode[1])) >> - clk_disable(tll->usbtll_p2_fck); >> + for (i = 0; i < tll->nch; i++) { >> + if (is_ehci_tll_mode(pdata->port_mode[i])) { >> + if (tll->ch_clk[i]) > > if (!IS_ERR(tll->ch_clk[i])) ok. > >> + clk_disable(tll->ch_clk[i]); >> + } >> + } >> >> spin_unlock_irqrestore(&tll->lock, flags); >> -- cheers, -roger
On 01/18/2013 05:02 PM, Russell King - ARM Linux wrote: > On Fri, Jan 18, 2013 at 02:17:09PM +0200, Roger Quadros wrote: >> +/* only PHY and UNUSED modes don't need TLL */ >> +#define omap_usb_mode_needs_tll(x) ((x != OMAP_USBHS_PORT_MODE_UNUSED) &&\ >> + (x != OMAP_EHCI_PORT_MODE_PHY)) > > Growl. > > These parens do not make anything safer at all - they just obfuscate. The > safe version of the above macro would have been: > > #define omap_usb_mode_needs_tll(x) ((x) != OMAP_USBHS_PORT_MODE_UNUSED &&\ > (x) != OMAP_EHCI_PORT_MODE_PHY) > > If you're going to use a macro argument in an expression, it needs parens. > Simple expressions like a != b && c != d do _not_ need parens. > Yikes, that was brain dead stuff from me ;). Will fix. cheers, -roger
Hi Roger, On Fri, 18 Jan 2013, Roger Quadros wrote: > We don't need multiple aliases for the OMAP USB host clocks and neither > the dummy clocks so remove them. > > CC: Paul Walmsley <paul@pwsan.com> > CC: Rajendra Nayak <rnayak@ti.com> > CC: Benoit Cousson <b-cousson@ti.com> > CC: Mike Turquette <mturquette@linaro.com> > > Signed-off-by: Roger Quadros <rogerq@ti.com> > Reviewed-by: Felipe Balbi <balbi@ti.com> > Acked-by: Paul Walmsley <paul@pwsan.com> Per Tony's earlier request, you can drop this patch and patch 20 from your series now. I've got them queued for 3.10 or late 3.9 merge window. - Paul
On 01/18/2013 10:27 PM, Paul Walmsley wrote: > Hi Roger, > > On Fri, 18 Jan 2013, Roger Quadros wrote: > >> We don't need multiple aliases for the OMAP USB host clocks and neither >> the dummy clocks so remove them. >> >> CC: Paul Walmsley <paul@pwsan.com> >> CC: Rajendra Nayak <rnayak@ti.com> >> CC: Benoit Cousson <b-cousson@ti.com> >> CC: Mike Turquette <mturquette@linaro.com> >> >> Signed-off-by: Roger Quadros <rogerq@ti.com> >> Reviewed-by: Felipe Balbi <balbi@ti.com> >> Acked-by: Paul Walmsley <paul@pwsan.com> > > Per Tony's earlier request, you can drop this patch and patch 20 from your > series now. I've got them queued for 3.10 or late 3.9 merge window. > Should have mentioned it earlier, but just this patch without the rest of the cleanup patches will break USB Host on OMAP3, as the old driver bails out if optional clock nodes are missing. Including patch 20 doesn't seem to cause a problem with OMAP4 though. regards, -roger
Hi On Mon, 21 Jan 2013, Roger Quadros wrote: > On 01/18/2013 10:27 PM, Paul Walmsley wrote: > > On Fri, 18 Jan 2013, Roger Quadros wrote: > > > >> We don't need multiple aliases for the OMAP USB host clocks and neither > >> the dummy clocks so remove them. > >> > >> CC: Paul Walmsley <paul@pwsan.com> > >> CC: Rajendra Nayak <rnayak@ti.com> > >> CC: Benoit Cousson <b-cousson@ti.com> > >> CC: Mike Turquette <mturquette@linaro.com> > >> > >> Signed-off-by: Roger Quadros <rogerq@ti.com> > >> Reviewed-by: Felipe Balbi <balbi@ti.com> > >> Acked-by: Paul Walmsley <paul@pwsan.com> > > > > Per Tony's earlier request, you can drop this patch and patch 20 from your > > series now. I've got them queued for 3.10 or late 3.9 merge window. > > > > Should have mentioned it earlier, but just this patch without the rest > of the cleanup patches will break USB Host on OMAP3, as the old driver > bails out if optional clock nodes are missing. > > Including patch 20 doesn't seem to cause a problem with OMAP4 though. I've got these two patches queued for merging after your other patches go upstream -- e.g., probably 3.10. Do you foresee any problems with that? - Paul
On Mon, Jan 21, 2013 at 01:04:46PM +0200, Roger Quadros wrote: > Every channel has a functional clock that is similarly named. > It makes sense to use a for loop to manage these clocks as OMAPs > can come with up to 3 channels. > > Dynamically allocate and get channel clocks depending on the > number of clocks avaiable on the platform. > > Signed-off-by: Roger Quadros <rogerq@ti.com> > Reviewed-by: Felipe Balbi <balbi@ti.com> Much better from the clk API usage, thanks. Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
On 01/21/2013 05:03 PM, Paul Walmsley wrote: > Hi > > On Mon, 21 Jan 2013, Roger Quadros wrote: > >> On 01/18/2013 10:27 PM, Paul Walmsley wrote: >>> On Fri, 18 Jan 2013, Roger Quadros wrote: >>> >>>> We don't need multiple aliases for the OMAP USB host clocks and neither >>>> the dummy clocks so remove them. >>>> >>>> CC: Paul Walmsley <paul@pwsan.com> >>>> CC: Rajendra Nayak <rnayak@ti.com> >>>> CC: Benoit Cousson <b-cousson@ti.com> >>>> CC: Mike Turquette <mturquette@linaro.com> >>>> >>>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>>> Reviewed-by: Felipe Balbi <balbi@ti.com> >>>> Acked-by: Paul Walmsley <paul@pwsan.com> >>> >>> Per Tony's earlier request, you can drop this patch and patch 20 from your >>> series now. I've got them queued for 3.10 or late 3.9 merge window. >>> >> >> Should have mentioned it earlier, but just this patch without the rest >> of the cleanup patches will break USB Host on OMAP3, as the old driver >> bails out if optional clock nodes are missing. >> >> Including patch 20 doesn't seem to cause a problem with OMAP4 though. > > I've got these two patches queued for merging after your other patches go > upstream -- e.g., probably 3.10. Do you foresee any problems with that? > That should be fine. Thanks :). -- cheers, -roger
Hi Paul, On 01/21/2013 05:03 PM, Paul Walmsley wrote: > Hi > > On Mon, 21 Jan 2013, Roger Quadros wrote: > >> On 01/18/2013 10:27 PM, Paul Walmsley wrote: >>> On Fri, 18 Jan 2013, Roger Quadros wrote: >>> >>>> We don't need multiple aliases for the OMAP USB host clocks and neither >>>> the dummy clocks so remove them. >>>> >>>> CC: Paul Walmsley <paul@pwsan.com> >>>> CC: Rajendra Nayak <rnayak@ti.com> >>>> CC: Benoit Cousson <b-cousson@ti.com> >>>> CC: Mike Turquette <mturquette@linaro.com> >>>> >>>> Signed-off-by: Roger Quadros <rogerq@ti.com> >>>> Reviewed-by: Felipe Balbi <balbi@ti.com> >>>> Acked-by: Paul Walmsley <paul@pwsan.com> >>> >>> Per Tony's earlier request, you can drop this patch and patch 20 from your >>> series now. I've got them queued for 3.10 or late 3.9 merge window. >>> >> >> Should have mentioned it earlier, but just this patch without the rest >> of the cleanup patches will break USB Host on OMAP3, as the old driver >> bails out if optional clock nodes are missing. >> >> Including patch 20 doesn't seem to cause a problem with OMAP4 though. > > I've got these two patches queued for merging after your other patches go > upstream -- e.g., probably 3.10. Do you foresee any problems with that? > FYI, the usbhost patches are already in linux-next. cheers, -roger
Hi Roger,
On Tue, 5 Feb 2013, Roger Quadros wrote:
> FYI, the usbhost patches are already in linux-next.
Thanks, I think I'll wait for 3.10 cleanup to send the clock cleanup
patches, they seem non-critical...
- Paul
Hi Roger, On Tue, 5 Feb 2013, Roger Quadros wrote: > On 01/21/2013 05:03 PM, Paul Walmsley wrote: > > Hi > > > > On Mon, 21 Jan 2013, Roger Quadros wrote: > > > >> On 01/18/2013 10:27 PM, Paul Walmsley wrote: > >>> On Fri, 18 Jan 2013, Roger Quadros wrote: > >>> > >>>> We don't need multiple aliases for the OMAP USB host clocks and neither > >>>> the dummy clocks so remove them. > >>>> > >>>> CC: Paul Walmsley <paul@pwsan.com> > >>>> CC: Rajendra Nayak <rnayak@ti.com> > >>>> CC: Benoit Cousson <b-cousson@ti.com> > >>>> CC: Mike Turquette <mturquette@linaro.com> > >>>> > >>>> Signed-off-by: Roger Quadros <rogerq@ti.com> > >>>> Reviewed-by: Felipe Balbi <balbi@ti.com> > >>>> Acked-by: Paul Walmsley <paul@pwsan.com> > >>> > >>> Per Tony's earlier request, you can drop this patch and patch 20 from your > >>> series now. I've got them queued for 3.10 or late 3.9 merge window. > >>> > >> > >> Should have mentioned it earlier, but just this patch without the rest > >> of the cleanup patches will break USB Host on OMAP3, as the old driver > >> bails out if optional clock nodes are missing. > >> > >> Including patch 20 doesn't seem to cause a problem with OMAP4 though. > > > > I've got these two patches queued for merging after your other patches go > > upstream -- e.g., probably 3.10. Do you foresee any problems with that? > > > > FYI, the usbhost patches are already in linux-next. Queued this patch for v3.11; looks like I missed it for v3.10. - Paul