mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-08 19:06:38 +07:00
4b87361d49
ELAN's U132 is a USB to CardBus OHCI controller adapter, designed specifically for CardBus 3G data cards to function in machines without a CardBus slot. The "ftdi-elan" module is a USB client driver, that detects a supported CardBus OHCI controller plugged into the U132 adapter and thereafter provides the conduit for for access by the "u132-hcd" module. The "u132-hcd" module is a (cut-down OHCI) host controller that supports a single OHCI function of the CardBus card inserted into the U132 adapter. The problem with the initial implementation is that when the CardBus card inserted into the U132 adapter has multiple functions (and a CardBus card can support up to 4 functions), it was the first function that was arbitrarily choosen. The first batch of 3G cards tested, like the Merlin Qualcomm V620, have two functions each supporting a seperate USB OHCI host controller, of which it was that first function that is wired up to the 3G modem. Then along comes the Vodafone Mobile Connect 3G/GPRS data card, aka "Option GT 3G Quad" as printed on it's rear or "Option N.V. GlobeTrotter Fusion Quad Lite" as read with "lspci -v". And it has the meaningful functionality in the second CardBus function. That presents a problem because it was the "ftdi-elan" module alone that knows how to communicate to the embedded CardBus slot and the "u132-hcd" module alone that knows how to access the pcmcia configuration and CardBus accessible memory space. And of course, the information about attached (internally hardwired) devices is contained within USB configuration embedded somewhere within the CardBus card. If only the "u132-hcd" module probe() interface could return a result code that propagated back to the instigating function platform_device_register() then the "ftdi-elan" module could try an alternative CardBus function. However in spite of the recent changes to the drivers/base/ routines that moved device_attach() from bus_add_device() to bus_attach_device() both of those routines lose the "failed to attach" 0 result code and thus the calling routine, namely device_add() is incapable of propaging the "failed to attach" condition back to platform_device_add() and consequently back to the caller of platform_device_register() Experiments show that patching bus_attach_device() to return ENODEV fails with the kernel locking up very early during boot. But, however, if the patch is restricted to calls from platform_device_add() then it does seem to work. Unfortunately, until the kernel's drivers/base is properly modified to propagate -ENODEV back to the caller of platform_device_register(), it is necessary to "fix" the "ftdi-elan" module by importing knowledge from the "u132-hcd" module. This is the reason for the duplicated functionality introduced in this patch. Signed-off-by: Tony Olech <tony.olech@elandigitalsystems.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> |
||
---|---|---|
.. | ||
ehci-au1xxx.c | ||
ehci-dbg.c | ||
ehci-fsl.c | ||
ehci-fsl.h | ||
ehci-hcd.c | ||
ehci-hub.c | ||
ehci-mem.c | ||
ehci-pci.c | ||
ehci-q.c | ||
ehci-sched.c | ||
ehci.h | ||
hc_crisv10.c | ||
hc_crisv10.h | ||
isp116x-hcd.c | ||
isp116x.h | ||
Kconfig | ||
Makefile | ||
ohci-at91.c | ||
ohci-au1xxx.c | ||
ohci-dbg.c | ||
ohci-ep93xx.c | ||
ohci-hcd.c | ||
ohci-hub.c | ||
ohci-lh7a404.c | ||
ohci-mem.c | ||
ohci-omap.c | ||
ohci-pci.c | ||
ohci-pnx4008.c | ||
ohci-pnx8550.c | ||
ohci-ppc-soc.c | ||
ohci-pxa27x.c | ||
ohci-q.c | ||
ohci-s3c2410.c | ||
ohci-sa1111.c | ||
ohci.h | ||
pci-quirks.c | ||
pci-quirks.h | ||
sl811_cs.c | ||
sl811-hcd.c | ||
sl811.h | ||
u132-hcd.c | ||
uhci-debug.c | ||
uhci-hcd.c | ||
uhci-hcd.h | ||
uhci-hub.c | ||
uhci-q.c |