Re: [PATCH 2/2] USB: EHCI: make ehci-orion a separate driver
Andrew Lunn writes:
Hi,
[...]
>> > +
>> > +static const char hcd_name[] = "ehci-orion";
[...]
>> > }
>> >
>> > -MODULE_ALIAS("platform:orion-ehci");
>> > -
>> > static const struct of_device_id ehci_orion_dt_ids[] = {
>> >{ .compatible = "marvell,orion-ehci", },
orion-ehci here ...
>> >{},
>> > @@ -336,8 +307,31 @@ static struct platform_driver ehci_orion_driver = {
>> >.remove = __exit_p(ehci_orion_drv_remove),
>> >.shutdown = usb_hcd_platform_shutdown,
>> >.driver = {
>> > - .name = "orion-ehci",
>> > + .name = hcd_name,
... and ehci-orion here. This would explain why only DT case seems to
work. I'm wondering why it has not been changed given that it has been
changed everywhere else, breaking stuff.
>>
>> Is this really what you want -- changing the driver name from
>> "orion-ehci" to "ehci-orion"? Is that liable to cause trouble?
>>
>> > +MODULE_DESCRIPTION(DRIVER_DESC);
>> > +MODULE_ALIAS("platform:ehci-orion");
>>
>> And is this really what you want -- changing the alias from
>> "platform:orion-ehci" to "platform:ehci-orion"?
>
> Hi Manjunath
>
> I can confirm that this breaks non DT based kirkwood systems. The
> driver does not get loaded.
>
> Sorry for not testing and finding this case earlier, i just tested a
> DT based system.
Maybe doing a mass renaming from orion-ehci to ehci-orion in
arch/arm/* files would be enough ? [ well, not necessary everywhere, I'm
not sure if changing the clock name in mach-kirkwood/board-dt.c would be
a good idea given the of node didn't change its name ]
Arnaud
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] USB: EHCI: hot-fix OMAP and Orion multiplatform config
Arnd Bergmann writes: Hi, > On Saturday 16 March 2013, Greg Kroah-Hartman wrote: >> On Fri, Mar 15, 2013 at 09:13:52PM +, 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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[patch 1/1] usbmisc_imx: allow autoloading on according to dt ids
Allow udev to autoload the module when booting with device-tree
Signed-off-by: Arnaud Patard
Index: linux/drivers/usb/chipidea/usbmisc_imx.c
===
--- linux.orig/drivers/usb/chipidea/usbmisc_imx.c 2013-05-16
00:46:35.0 +0200
+++ linux/drivers/usb/chipidea/usbmisc_imx.c2013-05-16 09:00:12.0
+0200
@@ -175,6 +175,7 @@ static const struct of_device_id usbmisc
},
{ /* sentinel */ }
};
+MODULE_DEVICE_TABLE(of, usbmisc_imx_dt_ids);
static int usbmisc_imx_probe(struct platform_device *pdev)
{
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] chipidea: core: Move hw_phymode_configure() into probe
Fabio Estevam writes: > Currently hw_phymode_configure() is located inside hw_device_reset(), which is > only called by chipidea udc driver. > > When operating in host mode, we also need to call hw_phymode_configure() in > order to properly configure the PHY mode, so move this function into probe. > > After this change, USB Host1 port on mx53qsb board is functional. nice catch. With this patch and the vbus supply patch, the 2 ports of my imx53qsb are working here too. Thanks. > > Signed-off-by: Fabio Estevam Tested-by: Arnaud Patard Arnaud -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
