[PCMCIA] Solved: No USB 2.0 (ehci) in PCMCIA slot on E7110

[Thomas Richter]

Dear Alan, Josep, David, dear PCMCIA maintainers,

this is on followup of a hang I reported earlier when using a delock 
(NEC-based) PCMCIA card in a O2Micro slot of an oldish E7110 Fujitsu 
laptop. The phenomenon is that read accesses through the ehci interface 
of the USB host adapter are unreliable, and write accesses are outright 
impossible and create hangs and bad data being transmitted. The 
miscommunication on the USB port is so bad that it erased the super 
block of an external hard drive I have, thus causing loss of files on 
this drive. BUMMER!

While I searched for a long time in the usb subsystem, I found that this 
is actually innocent of the hang, and the trouble is rather in the 
pcmcia system.

The error was introduced in kernel 2.6.32, 2.6.31 worked fine. After a 
lot of bisection work, I finally found the source of the error.
The trouble is in drivers/pcmcia/o2micro.h, line 137 as of the linux 
3.10.5 kernel. It's likely in the close vicinity for the current 
development kernel:

		case PCI_DEVICE_ID_O2_6729:
		case PCI_DEVICE_ID_O2_6730:
		case PCI_DEVICE_ID_O2_6812:
		case PCI_DEVICE_ID_O2_6832:
		case PCI_DEVICE_ID_O2_6836:
		case PCI_DEVICE_ID_O2_6933: /* <--- this one! */
			use_speedup = false;
			break;

This line disables read prefetch and write bursting of the O2 pcmcia 
bridge chip found in this laptop, thus pcmcia communication is then 
entirely CPU-based, and simply too slow to generate signals to be 
conforming to the ehci protocol. ohci (USB 1.0) works. Note that this is 
only a 1.7Ghz Pentium-4-M dinosaur.

I understand the care necessary to disable this for some broken 
machines, but on the other hand on my machine write bursting does work, 
apparently, and *not* enabling it broke the communications so badly that 
it harmed data integrity on an external disk.

Thus, unconditionally disabling write bursts on the mentioned O2 bridge 
is not the right action. Probably the bridge should allow users of this 
bridge to query which speeds are available, and either disable the 
higher speed protocols like ehci, or include some kind of yet to be 
determined test that would allow to check whether the chip *is* actually 
broken. As said, it isn't here.

As a shorter time resolution, I would recommend to expose this as a 
configuration item in the kernel configuration dialog so I could build 
my kernel in the correct way, without running into the risk of ruining
data on external devices. (-;

For your information, this is the lspci output of the (un-)affected O2 card:
02:0a.0 CardBus bridge: O2 Micro, Inc. OZ6933/711E1 CardBus/SmartCardBus 
Controller (rev 02)
02:0a.1 CardBus bridge: O2 Micro, Inc. OZ6933/711E1 CardBus/SmartCardBus 
Controller (rev 02)

or numeric:

02:0a.0 0607: 1217:6933 (rev 02)
02:0a.1 0607: 1217:6933 (rev 02)

What is also probably helpful is the output of dmidecode to identify the 
product:

Handle 0x0001, DMI type 1, 25 bytes
System Information
         Manufacturer: FUJITSU SIEMENS
         Product Name: LIFEBOOK E Series
         Version:
         Serial Number: YBSN003702
         UUID: D1552D78-AB36-11D6-8B14-00E000AE4E45
         Wake-up Type: Power Switch

Handle 0x0002, DMI type 2, 8 bytes
Base Board Information
         Manufacturer: FUJITSU
         Product Name: FJNB15C
         Version:
         Serial Number:

Handle 0x0021, DMI type 9, 13 bytes
System Slot Information
         Designation: CardBus-1
         Type: 32-bit PC Card (PCMCIA)
         Current Usage: Unknown
         Length: Other
         ID: Adapter 0, Socket 0
         Characteristics:
                 5.0 V is provided
                 3.3 V is provided
                 PC Card-16 is supported
                 Cardbus is supported
                 Modem ring resume is supported
                 PME signal is supported

Handle 0x0022, DMI type 9, 13 bytes
System Slot Information
         Designation: CardBus-2
         Type: 32-bit PC Card (PCMCIA)
         Current Usage: Unknown
         Length: Other
         ID: Adapter 1, Socket 0
         Characteristics:
                 5.0 V is provided
                 3.3 V is provided
                 PC Card-16 is supported
                 Cardbus is supported
                 Modem ring resume is supported
                 PME signal is supported

(yes, there are two pcmcia slots here)

Maybe that helps as an identification, too, before turning 
write-bursting off.

Thanks, and please let me know if I can be of any further help to 
resolve the problem. It's currently successfully patched away for my 
kernel, but that's not a good solution.

Greetings,
	Thomas