| Message ID | 201303151700.27231.arnd@arndb.de |
|---|---|
| State | New |
| Headers | show |
On Fri, 15 Mar 2013, Arnd Bergmann wrote: > On Friday 15 March 2013, Alan Stern wrote: > > Roger just submitted my patch to split out ehci-omap. > > Ok, if we can merge that for 3.9, the main issue will be resolved, because > an OMAP+Orion config is much more interesting in practice than adding > VT8500 to the mix. I don't know if the patch will get into 3.9. That's up to Greg; IIRC Roger did not ask for it. > An alternative for VT8500 would be to remove drivers/usb/host/ehci-vt8500.c > completely and use the generic ehci-platform.c bus glue with added DT > support, as the patch below that I just hacked up. Not sure if that > anyone would prefer that over the hot-fix for 3.9, but it's possibly > a better solution in the long run. Getting rid of driver files is always worthwhile. > @@ -89,12 +90,17 @@ static int ehci_platform_probe(struct platform_device *dev) > return -ENXIO; > } > > - if (pdata->power_on) { > + if (pdata && pdata->power_on) { > err = pdata->power_on(dev); > if (err < 0) > return err; > } Instead of adding these tests for non-NULL pdata all over the place, you could define a static structure with default settings and store a pointer to it if pdata wasn't set initially. Alan Stern
On Fri, 15 Mar 2013, Arnd Bergmann wrote: > On Friday 15 March 2013, Alan Stern wrote: > > Roger just submitted my patch to split out ehci-omap. > > Ok, if we can merge that for 3.9, the main issue will be resolved, because > an OMAP+Orion config is much more interesting in practice than adding > VT8500 to the mix. I just got an automated message from Greg: -------------------------------------------------------------------------- This is a note to let you know that I've just added the patch titled USB: EHCI: split ehci-omap out to a separate driver to my usb git tree which can be found at git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git in the usb-next branch. -------------------------------------------------------------------------- Unless something is changed, this patch won't get into 3.9-final. Do you want Greg to move it to his usb-linus branch? Alan Stern
On Fri, Mar 15, 2013 at 03:19:08PM -0400, Alan Stern wrote: > On Fri, 15 Mar 2013, Arnd Bergmann wrote: > > > On Friday 15 March 2013, Alan Stern wrote: > > > Roger just submitted my patch to split out ehci-omap. > > > > Ok, if we can merge that for 3.9, the main issue will be resolved, because > > an OMAP+Orion config is much more interesting in practice than adding > > VT8500 to the mix. > > I just got an automated message from Greg: > > -------------------------------------------------------------------------- > This is a note to let you know that I've just added the patch titled > > USB: EHCI: split ehci-omap out to a separate driver > > to my usb git tree which can be found at > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git > in the usb-next branch. > -------------------------------------------------------------------------- > > Unless something is changed, this patch won't get into 3.9-final. > Do you want Greg to move it to his usb-linus branch? It's a bit too "big" for 3.9-final, sorry. greg k-h
On Friday 15 March 2013, Alan Stern wrote: > I just got an automated message from Greg: > > -------------------------------------------------------------------------- > This is a note to let you know that I've just added the patch titled > > USB: EHCI: split ehci-omap out to a separate driver > > to my usb git tree which can be found at > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git > in the usb-next branch. > -------------------------------------------------------------------------- > > Unless something is changed, this patch won't get into 3.9-final. > Do you want Greg to move it to his usb-linus branch? I don't care much which way we do it, but I'd certainly like to see one of these two solutions for the bug: a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support for generic bus glue" patch on top after it has been tested b) Apply my "USB: EHCI: hot-fix OMAP and Orion multiplatform config" when I send a version based on the proper tree for 3.9, and leave the other ones to do it properly for 3.10. Arnd
On Friday 15 March 2013, Sergei Shtylyov wrote: > > > > a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support > > for generic bus glue" patch on top after it has been tested > > Arnd, sorry, where can I find this patch? Archive search doesn't > turn up anything... It's in this email thread, in one of my earlier replies to Alan. Since Greg already said that he won't take Roger's patch for 3.9, taking this one would be pointless as well. I can resubmit it for 3.10 once we know what to do about my hot-fix. Arnd
On Friday 15 March 2013, Greg Kroah-Hartman wrote: > > Unless something is changed, this patch won't get into 3.9-final. > > Do you want Greg to move it to his usb-linus branch? > > It's a bit too "big" for 3.9-final, sorry. Would you consider the hot fix at the start of this thread for 3.9 then? I can resubmit it as a patch for inclusion with the missing hunk added in if there are no objections. Arnd
Hello. On 03/15/2013 11:15 PM, Arnd Bergmann wrote: > On Friday 15 March 2013, Alan Stern wrote: >> I just got an automated message from Greg: >> >> -------------------------------------------------------------------------- >> This is a note to let you know that I've just added the patch titled >> >> USB: EHCI: split ehci-omap out to a separate driver >> >> to my usb git tree which can be found at >> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git >> in the usb-next branch. >> -------------------------------------------------------------------------- >> >> Unless something is changed, this patch won't get into 3.9-final. >> Do you want Greg to move it to his usb-linus branch? > I don't care much which way we do it, but I'd certainly like to > see one of these two solutions for the bug: > > a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support > for generic bus glue" patch on top after it has been tested Arnd, sorry, where can I find this patch? Archive search doesn't turn up anything... WBR, Sergei
Hello. On 03/16/2013 12:11 AM, Arnd Bergmann wrote: > On Friday 15 March 2013, Sergei Shtylyov wrote: >>> a) Apply Roger's patch for 3.9, and add my "USB: EHCI: DT support >>> for generic bus glue" patch on top after it has been tested >> Arnd, sorry, where can I find this patch? Archive search doesn't >> turn up anything... > It's in this email thread, in one of my earlier replies to Alan. Ah, found it now. I thought however that it already handles the DT properties for the EHCI platform data. Of course, that can be added later... WBR, Sergei
On Fri, Mar 15, 2013 at 09:13:52PM +0000, Arnd Bergmann wrote: > On Friday 15 March 2013, Greg Kroah-Hartman wrote: > > > Unless something is changed, this patch won't get into 3.9-final. > > > Do you want Greg to move it to his usb-linus branch? > > > > It's a bit too "big" for 3.9-final, sorry. > > Would you consider the hot fix at the start of this thread for 3.9 > then? I can resubmit it as a patch for inclusion with the missing > hunk added in if there are no objections. Feel free to resend, but remember, I am _very_ leery of pushing this type of patch in at the moment, given my past history with it... greg k-h
On Saturday 16 March 2013, Greg Kroah-Hartman wrote: > On Fri, Mar 15, 2013 at 09:13:52PM +0000, Arnd Bergmann wrote: > > On Friday 15 March 2013, Greg Kroah-Hartman wrote: > > > > Unless something is changed, this patch won't get into 3.9-final. > > > > Do you want Greg to move it to his usb-linus branch? > > > > > > It's a bit too "big" for 3.9-final, sorry. > > > > Would you consider the hot fix at the start of this thread for 3.9 > > then? I can resubmit it as a patch for inclusion with the missing > > hunk added in if there are no objections. > > Feel free to resend, but remember, I am very leery of pushing this > type of patch in at the moment, given my past history with it... Sure, it's your decision. I just don't want to be accused of abandoning the issue that I caused. It's not strictly a regression because no configuration that was working in 3.8 is broken in 3.9, and embedded systems won't normally run a multiplatform kernel anyway. Also, the patch is really an ugly hack, which is probably enough reason not to take it. ;-) The only situation I can think of that is broken without the hotfix is distribution kernels that were already running multiplatform on Armada XP (mvebu/orion) and now want to add OMAP support without breaking the platforms that are already working. Peter Robinson is doing this on for Fedora right now[1] and I assume the Debian/Ubuntu/OpenSUSE/Gentoo people will be in a similar situation, but they can all apply the patch manually if it doesn't make it into 3.9. It won't be the only patch they need to get there, it's just the only one for 3.9 we already know about. Arnd [1] https://plus.google.com/117898952501074015902/posts/VgnDhJBxbU4
Arnd Bergmann <arnd@arndb.de> writes: Hi, > On Saturday 16 March 2013, Greg Kroah-Hartman wrote: >> On Fri, Mar 15, 2013 at 09:13:52PM +0000, Arnd Bergmann wrote: >> > On Friday 15 March 2013, Greg Kroah-Hartman wrote: >> > > > Unless something is changed, this patch won't get into 3.9-final. >> > > > Do you want Greg to move it to his usb-linus branch? >> > > >> > > It's a bit too "big" for 3.9-final, sorry. >> > >> > Would you consider the hot fix at the start of this thread for 3.9 >> > then? I can resubmit it as a patch for inclusion with the missing >> > hunk added in if there are no objections. >> >> Feel free to resend, but remember, I am very leery of pushing this >> type of patch in at the moment, given my past history with it... > > Sure, it's your decision. I just don't want to be accused of abandoning the > issue that I caused. It's not strictly a regression because no configuration > that was working in 3.8 is broken in 3.9, and embedded systems won't normally > run a multiplatform kernel anyway. Also, the patch is really an ugly hack, > which is probably enough reason not to take it. ;-) Given that the omap patch has been accepted and that the patch is an "ugly hack", how hard it would be to provide a working patch for mvebu (well, orion usb driver) ? > > The only situation I can think of that is broken without the hotfix is > distribution kernels that were already running multiplatform on Armada XP > (mvebu/orion) and now want to add OMAP support without breaking the well, for omap, this patch may be needed too http://marc.info/?l=linux-usb&m=136248269928419&w=2 imho (I've not checked if it's merged now). > platforms that are already working. Peter Robinson is doing this on for > Fedora right now[1] and I assume the Debian/Ubuntu/OpenSUSE/Gentoo > people will be in a similar situation, but they can all apply the > patch fwiw, I've mentionned this usb issue few days ago when talking about multiplatform on the debian-arm ml. > manually if it doesn't make it into 3.9. It won't be the only patch they it can applied in the debian kernel, as long as the patch is merged upstream. Arnaud
On Monday 18 March 2013, Arnaud Patard wrote: > Arnd Bergmann <arnd@arndb.de> writes: > > Sure, it's your decision. I just don't want to be accused of abandoning the > > issue that I caused. It's not strictly a regression because no configuration > > that was working in 3.8 is broken in 3.9, and embedded systems won't normally > > run a multiplatform kernel anyway. Also, the patch is really an ugly hack, > > which is probably enough reason not to take it. ;-) > > Given that the omap patch has been accepted and that the patch is an > "ugly hack", how hard it would be to provide a working patch for mvebu > (well, orion usb driver) ? The OMAP patch was accepted for 3.10, and I'm sure we will have good patches for the other bus glues as well, but the bug is also present on 3.9, and the proper patches are too invasive now to get merged there. > > platforms that are already working. Peter Robinson is doing this on for > > Fedora right now[1] and I assume the Debian/Ubuntu/OpenSUSE/Gentoo > > people will be in a similar situation, but they can all apply the > > patch > > fwiw, I've mentionned this usb issue few days ago when talking about > multiplatform on the debian-arm ml. Yes, we've known about it for a long time, but failed to get the proper patches out in time :( > > manually if it doesn't make it into 3.9. It won't be the only patch they > > it can applied in the debian kernel, as long as the patch is merged > upstream. It won't be merged in 3.10, but in that case Debian can backport the proper patches from 3.10. Arnd
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c index ca75063..2e4ddd4 100644 --- a/drivers/usb/host/ehci-platform.c +++ b/drivers/usb/host/ehci-platform.c @@ -18,11 +18,13 @@ * * Licensed under the GNU/GPL. See COPYING for details. */ +#include <linux/dma-mapping.h> #include <linux/err.h> #include <linux/kernel.h> #include <linux/hrtimer.h> #include <linux/io.h> #include <linux/module.h> +#include <linux/of.h> #include <linux/platform_device.h> #include <linux/usb.h> #include <linux/usb/hcd.h> @@ -41,17 +43,21 @@ static int ehci_platform_reset(struct usb_hcd *hcd) struct ehci_hcd *ehci = hcd_to_ehci(hcd); int retval; - hcd->has_tt = pdata->has_tt; - ehci->has_synopsys_hc_bug = pdata->has_synopsys_hc_bug; - ehci->big_endian_desc = pdata->big_endian_desc; - ehci->big_endian_mmio = pdata->big_endian_mmio; + ehci->caps = hcd->regs; + + if (pdata) { + hcd->has_tt = pdata->has_tt; + ehci->has_synopsys_hc_bug = pdata->has_synopsys_hc_bug; + ehci->big_endian_desc = pdata->big_endian_desc; + ehci->big_endian_mmio = pdata->big_endian_mmio; + ehci->caps += pdata->caps_offset; + } - ehci->caps = hcd->regs + pdata->caps_offset; retval = ehci_setup(hcd); if (retval) return retval; - if (pdata->no_io_watchdog) + if (pdata && pdata->no_io_watchdog) ehci->need_io_watchdog = 0; return 0; } @@ -70,11 +76,6 @@ static int ehci_platform_probe(struct platform_device *dev) int irq; int err = -ENOMEM; - if (!pdata) { - WARN_ON(1); - return -ENODEV; - } - if (usb_disabled()) return -ENODEV; @@ -89,12 +90,17 @@ static int ehci_platform_probe(struct platform_device *dev) return -ENXIO; } - if (pdata->power_on) { + if (pdata && pdata->power_on) { err = pdata->power_on(dev); if (err < 0) return err; } + if (!dev->dev.dma_mask) { + dev->dev.dma_mask = &dev->dev.coherent_dma_mask; + dev->dev.coherent_dma_mask = DMA_BIT_MASK(32); + } + hcd = usb_create_hcd(&ehci_platform_hc_driver, &dev->dev, dev_name(&dev->dev)); if (!hcd) { @@ -121,7 +127,7 @@ static int ehci_platform_probe(struct platform_device *dev) err_put_hcd: usb_put_hcd(hcd); err_power: - if (pdata->power_off) + if (pdata && pdata->power_off) pdata->power_off(dev); return err; @@ -136,7 +142,7 @@ static int ehci_platform_remove(struct platform_device *dev) usb_put_hcd(hcd); platform_set_drvdata(dev, NULL); - if (pdata->power_off) + if (pdata && pdata->power_off) pdata->power_off(dev); return 0; @@ -155,7 +161,7 @@ static int ehci_platform_suspend(struct device *dev) ret = ehci_suspend(hcd, do_wakeup); - if (pdata->power_suspend) + if (pdata && pdata->power_suspend) pdata->power_suspend(pdev); return ret; @@ -168,7 +174,7 @@ static int ehci_platform_resume(struct device *dev) struct platform_device *pdev = container_of(dev, struct platform_device, dev); - if (pdata->power_on) { + if (pdata && pdata->power_on) { int err = pdata->power_on(pdev); if (err < 0) return err; @@ -183,6 +189,12 @@ static int ehci_platform_resume(struct device *dev) #define ehci_platform_resume NULL #endif /* CONFIG_PM */ +static const struct of_device_id vt8500_ehci_ids[] = { + { .compatible = "via,vt8500-ehci", }, + { .compatible = "wm,prizm-ehci", }, + {} +}; + static const struct platform_device_id ehci_platform_table[] = { { "ehci-platform", 0 }, { } @@ -203,6 +215,7 @@ static struct platform_driver ehci_platform_driver = { .owner = THIS_MODULE, .name = "ehci-platform", .pm = &ehci_platform_pm_ops, + .of_match_table = of_match_ptr(vt8500_ehci_ids), } };