-ENOROGER :-p On Thu, Jan 10, 2013 at 08:23:56PM +0200, Felipe Balbi wrote: > Hi > > On Thu, Jan 10, 2013 at 12:01:09PM -0500, Alan Stern wrote: > > On Thu, 10 Jan 2013, Felipe Balbi wrote: > > > > > Hi, > > > > > > On Thu, Jan 10, 2013 at 10:36:27AM -0500, Alan Stern wrote: > > > > On Thu, 10 Jan 2013, Felipe Balbi wrote: > > > > > > > > > Hi Alan, > > > > > > > > > > with v3.8-rc3, ehci-hcd fails to compile for ARM if I use allmodconfig: > > > > > > > > > > drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER" redefined [enabled by default] > > > > > drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition > > > > > drivers/usb/host/ehci-mxc.c:280:31: warning: 'ehci_mxc_driver' defined but not used [-Wunused-variable] > > > > > drivers/usb/host/ehci-hcd.c:1285:0: warning: "PLATFORM_DRIVER" redefined [enabled by default] > > > > > drivers/usb/host/ehci-hcd.c:1255:0: note: this is the location of the previous definition > > > > > > > > > > Looks like the recent ARM multi-arch patches didn't take into account > > > > > EHCI-hcd. > > > > > > > > Do you know why this problem didn't occur in 3.6-rc2? I don't see any > > > > changes in -rc3 that would account for it (although I didn't look > > > > terribly thoroughly). > > > > > > It's probably there, I just didn't look at it either :-) > > > > It seems clear that CONFIG_EHCI_HCD_PLATFORM needs to be mutually > > exclusive with all the old-style drivers, in order to prevent this sort > > of conflict. I just don't see why it never came up before... > > you can't do that as you will break ARM single zImage builds. > > > > > > Now it becomes easy to see why giving ehci its own > > > > > platform_device/driver would've been a lot easier ;-) > > > > > > > > Not at all. We merely need to finish the conversion that I started. > > > > It should be pretty easy to convert ehci-mxc over to the new scheme. > > > > I don't have time to do it right now, but soon... > > > > > > ehci-mxc isn't the only one redefining PLATFORM_DRIVER. All of below are > > > potential offenders: > > > > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_fsl_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_mxc_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sh_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_omap_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_orion_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_w90x900_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_atmel_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_octeon_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER vt8500_ehci_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER spear_ehci_hcd_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_msm_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_tilegx_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_msp_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER tegra_ehci_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER s5p_ehci_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_grlib_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_mv_driver > > > drivers/usb/host/ehci-hcd.c:#define PLATFORM_DRIVER ehci_hcd_sead3_driver > > > > Yes; those all are old-style drivers. Most of them can be converted to > > the new scheme with relatively little effort; a few will require more > > work. > > > > In fact, the only drivers that _have_ been converted so far are > > ehci-pci, chipidea, and ehci-platform. > > Fair enough... Roger Quadros (now in Cc) can probably help converting > ehci-omap to the new scheme if you're willing to provide your review :-) > > > > By adding a platform_device to struct ehci-hcd.c we wouldn't need all of > > > those defines. > > > > And indeed, each time a driver is converted to the new scheme, its > > #define gets removed. > > good, then I withdraw my previous comment :-) > > > > Also note that not all of them will be able to simply use > > > ehci-platform.c. OMAP, for instance, needs to reimplement parts of > > > ehci_hub_control() due to silicon erratas (we need to reparent a clock > > > at a specific spot during bus suspend), this means we will always have, > > > at a minimum, ehci-omap.c. Tegra has other silicon erratas on and > > > reimplements other ehci functions and so forth. > > > > That's right. But a driver can follow the new scheme without using > > ehci-platform.c. For example, neither ehci-pci.c nor chipidea/host.c > > does. > > that's good :-) > > > > But fair enough, I just want to see this fixed but, like yourself, no > > > time to look at that :-s > > > > I can fix up ehci-mxc easily enough. Don't all those other drivers > > cause similar build problems, though? > > they either already do, or will eventually. > > > It wouldn't hurt to add some restrictions to the Kconfig entry for > > CONFIG_USB_EHCI_HCD_PLATFORM too. > > Ok, maybe add a #warn "fix your freaking driver dude!!" to the > non-converted ones would make people help ? > > -- > balbi -- balbi
Attachment:
signature.asc
Description: Digital signature
