FW: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure)

FW: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure)

[Jennifer Li (TP)]

SGksDQoNCkFkZCBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnDQpEb2VzIGFueW9uZSBjYW4gaGVs
cCB1cz8NCg0KQmVzdCByZWdhcmRzLA0KSmVubmZlcg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCkZyb206IGJ1Z3ppbGxhLWRhZW1vbkBidWd6aWxsYS5rZXJuZWwub3JnIFttYWlsdG86YnVn
emlsbGEtZGFlbW9uQGJ1Z3ppbGxhLmtlcm5lbC5vcmddIA0KU2VudDogU2F0dXJkYXksIEp1bHkg
MTQsIDIwMTIgOTowOSBQTQ0KVG86IEplbm5pZmVyIExpIChUUCkNClN1YmplY3Q6IFtCdWcgNDMy
NDddIE8yIG1pY3JvIFNEL01NQysxMzk0IGNvbnRyb2xsZXI6IDEzOTQgZGV2aWNlIGNhbid0IHdv
cmsgKFJlZ2lzdGVyIGFjY2VzcyBmYWlsdXJlKQ0KDQpodHRwczovL2J1Z3ppbGxhLmtlcm5lbC5v
cmcvc2hvd19idWcuY2dpP2lkPTQzMjQ3DQoNCg0KDQoNCg0KLS0tIENvbW1lbnQgIzIwIGZyb20g
U3RlZmFuIFJpY2h0ZXIgPHN0ZWZhbnJAczVyNi5pbi1iZXJsaW4uZGU+ICAyMDEyLTA3LTE0IDEz
OjA5OjE2IC0tLSBPbiBKdWwgMTAgYnVnemlsbGEtZGFlbW9uQGJ1Z3ppbGxhLmtlcm5lbC5vcmcg
d3JvdGU6DQo+IGh0dHBzOi8vYnVnemlsbGEua2VybmVsLm9yZy9zaG93X2J1Zy5jZ2k/aWQ9NDMy
NDcNCj4gDQo+IC0tLSBDb21tZW50ICMxOSBmcm9tIGplbm5pZmVyIDxqZW5uaWZlci5saUBvMm1p
Y3JvLmNvbT4gIDIwMTItMDctMTAgDQo+IDExOjAyOjE2IC0tLQ0KWy4uLl0NCj4gPiBEbyB5b3Ug
bWVhbiBieSB0aGF0IHRoYXQNCj4gPiB0aGUgb3JpZ2luYWwgTGludXggZHJpdmVyIHdvcmtzIGZv
ciB5b3UgaWYgeW91IGJvb3QgTGludXggYnV0IGRvIG5vdCANCj4gPiBsZXQgdGhlIGRyaXZlciBi
ZSBhdXRvbWF0aWNhbGx5IGxvYWRlZCBkdXJpbmcgYm9vdCwgYnV0IGluc3RlYWQgbG9hZCANCj4g
PiB0aGUgZHJpdmVyIGxhdGVyIGJ5ICdtb2Rwcm9iZSBmaXJld2lyZS1vaGNpJyBhZnRlciB0aGUg
cmVzdCBvZiB0aGUgDQo+ID4gc3lzdGVtIGhhcyBmaW5pc2hlZCBib290aW5nIHVwPw0KPiANCj4g
WWVzLg0KPiANCj4gPiANCj4gPiBBbmQgaWYgeWVzLCBkaWQgeW91IGFsc28gbmVlZCB0byBsb2Fk
IHRoZSBzZGhjaS1wY2kgZHJpdmVyIG1hbnVhbGx5IA0KPiA+IHRoaXMgd2F5Pw0KPiANCj4gVGhl
cmUgYXJlIDQgd2F5cyB3aGljaCBjYW4gcGFzcyB0aGUgaXNzdWUuDQo+IDEuIExvYWQgMTM5NCBi
eSBPUyArIExvYWQgc2RoY2ktcGNpIGJ5IG1hbnVhbGx5Lg0KPiAyLiBMb2FkIHNkaGNpLXBjaSBi
eSBPUyArIExvYWQgMTM5NCBieSBtYW51YWxseS4NCj4gMy4gTG9hZCAxMzk0IGJ5IG1hbnVhbGx5
ICsgbG9hZCBzZGhjaS1wY2kgYnkgbWFudWFsbHkuDQo+IDQuIExvYWQgc2RoY2ktcGNpIGJ5IG1h
bnVhbGx5ICsgbG9hZCAxMzk0IGJ5IG1hbnVhbGx5Lg0KPiANCj4gPiBBbmQgZnVydGhlciwgZG9l
cyBpdCBtYXR0ZXIgd2hldGhlciBzZGhjaS1wY2kgaXMgbG9hZGVkIGJlZm9yZSANCj4gPiBmaXJl
d2lyZS1vaGNpIG9yIHRoZSBvdGhlciB3YXkgYXJvdW5kPw0KPiANCj4gQWNjb3JkaW5nIHRvIG91
ciB0ZXN0IHJlc3VsdCwgaWYgd2UgbG9hZCB0aGUgZHJpdmVyIGJ5IG1hbnVhbGx5IGFuZCANCj4g
dGhlIGlzc3VlIHdpbGwgZGlzYXBwZWFyLiBJdCBkaWRuJ3QgaGFzIHRoZSByZWxhdGlvbnNoaXAg
YWJvdXQgdGhlIGxvYWRlZCBwcmlvcml0eS4NCj4gQnV0LCBpZiB3ZSBsb2FkIHRob3NlIGRyaXZl
cnMgYnkgT1MgYW5kIHRoZSBpc3N1ZSB3aWxsIGhhcHBlbi4NCg0KDQpDb3VsZCBzb21lYm9keSBh
dCBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnIHBsZWFzZSBhZHZpc2U/DQoNCjEuKSAgSXMgdGhl
cmUgYSBrZXJuZWwgcGFyYW1ldGVyIHdoaWNoIEplbm5pZmVyIGNvdWxkIHRyeSBpbiBvcmRlciB0
byBmb3JjZSBzZXJpYWxpemVkIFBDSSBkcml2ZXIgcHJvYmluZz8NCg0KMi4pICBJZiB0aGVyZSBp
cyBvbmUgYW5kIGlmIHRoaXMgdHVybnMgb3V0IHRvIGN1cmUgdGhlIGlzc3VlIGluIHRlc3Rpbmc6
DQpIb3cgY2FuIEkgaW1wbGVtZW50IHNlcmlhbGl6YXRpb24gYmV0d2VlbiB0aGUgTzJNaWNybyBG
aXJlV2lyZSAucHJvYmUoKSBhbmQgLnJlc3VtZSgpIG9uIG9uZSBoYW5kIGFuZCB0aGUgTzJNaWNy
byBTREhDSSAucHJvYmUoKSBhbmQgLnJlc3VtZSgpIG9uIHRoZSBvdGhlciBoYW5kPw0KDQoNCltJ
ZiB5b3UgcmVwbHkgdG8gdGhpcyB2aWEgYnVnemlsbGEgbWFpbCwgcGxlYXNlIGFkZA0KICAgIENj
OiBsaW51eC1wY2lAdmdlci5rZXJuZWwub3JnDQppbiB5b3VyIHJlcGx5LiAgSSBhbSBub3QgYXdh
cmUgb2YgYSB3YXkgdG8gYWRkIGl0IHRvIGJ1Z3ppbGxhLmtlcm5lbC5vcmcncyBDYyBsaXN0IG9m
IGJ1ZyA0MzI0Ny5dDQoNCi0tDQpDb25maWd1cmUgYnVnbWFpbDogaHR0cHM6Ly9idWd6aWxsYS5r
ZXJuZWwub3JnL3VzZXJwcmVmcy5jZ2k/dGFiPWVtYWlsDQotLS0tLS0tIFlvdSBhcmUgcmVjZWl2
aW5nIHRoaXMgbWFpbCBiZWNhdXNlOiAtLS0tLS0tIFlvdSByZXBvcnRlZCB0aGUgYnVnLg0KDQoN
Cg0KVW5sZXNzIG90aGVyd2lzZSBzdGF0ZWQsIHRoaXMgZS1tYWlsIG1lc3NhZ2UgZG9lcyBub3Qg
Y29uc3RpdHV0ZSBhIHNvbGljaXRhdGlvbiB0byBidXkgb3Igc2VsbCBhbnkgcHJvZHVjdHMgb3Ig
c2VydmljZXMsIG9yIHRvIHBhcnRpY2lwYXRlIGluIGFueSBwYXJ0aWN1bGFyIHRyYWRpbmcgc3Ry
YXRlZ3kuIFRoaXMgZS1tYWlsIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgaW50ZW5k
ZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aGlj
aCBpdCBpcyBhZGRyZXNzZWQgYW5kIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgY29u
ZmlkZW50aWFsIG9yIGxlZ2FsbHkgcHJpdmlsZWdlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu
ZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzc2VtaW5h
dGlvbiwgZGlzdHJpYnV0aW9uLCBjb3B5aW5nIG9yIG90aGVyIHVzZSBvZiB0aGlzIG1lc3NhZ2Ug
b3IgaXRzIGF0dGFjaG1lbnRzIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl
Y2VpdmVkIHRoaXMgbWVzc2FnZSBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGlt
bWVkaWF0ZWx5IGFuZCBwZXJtYW5lbnRseSBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBhbnkgYXR0
YWNobWVudHMuIE8yTWljcm8gSW50ZXJuYXRpb25hbCBMdGQuLCBhbmQgaXRzIHN1YnNpZGlhcmll
cyBhbmQgYWZmaWxpYXRlcywgYXJlIG5laXRoZXIgbGlhYmxlIGZvciB0aGUgcHJvcGVyIGFuZCBj
b21wbGV0ZSB0cmFuc21pc3Npb24gb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz
IGNvbW11bmljYXRpb24sIHRoZSBhY2N1cmFjeSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVk
IHRoZXJlaW4sIG5vciBmb3IgYW55IGRlbGF5IGluIGl0cyByZWNlaXB0LiAgDQoNCg0K

Re: FW: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure)

[Bjorn Helgaas]

> 1.)  Is there a kernel parameter which Jennifer could try in order to force serialized PCI driver probing?

I don't understand the question here.  As far as I know, drivers
compiled statically into the kernel are already initialized serially,
via the do_initcalls() -> do_initcall_level(6) path.  The PCI core
enumerates all the devices, then when we call each driver's
module_init() function (serially), the module_init() function will
register the driver, and the driver core will call the driver's
.probe() function for every matching PCI device.

> 2.)  If there is one and if this turns out to cure the issue in testing:
> How can I implement serialization between the O2Micro FireWire .probe() and .resume() on one hand and the O2Micro SDHCI .probe() and .resume() on the other hand?

If serialization is required between two drivers, that sounds like a
driver bug.  What are the two drivers involved?

Re: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure)

[Stefan Richter]

On Jul 17 Bjorn Helgaas wrote:
> > 1.)  Is there a kernel parameter which Jennifer could try in order
> >      to force serialized PCI driver probing?
> 
> I don't understand the question here.  As far as I know, drivers
> compiled statically into the kernel are already initialized serially,
> via the do_initcalls() -> do_initcall_level(6) path.  The PCI core
> enumerates all the devices, then when we call each driver's
> module_init() function (serially), the module_init() function will
> register the driver, and the driver core will call the driver's
> .probe() function for every matching PCI device.

Jennifer and the other reporters of the issue most certainly all used
modular kernels, i.e. got the drivers loaded by udev.

module_init() doesn't matter, but
  - .probe(),
  - .resume()
do.  So as you say, if the drivers were statically linked, then at least
.probe() would be performed serially, one PCI device after another,
right?  But AFAIK .resume() would still be performed in parallel by a
pool of kernel threads in current kernels.

> > 2.)  If there is one and if this turns out to cure the issue in
> >      testing:
> >      How can I implement serialization between the O2Micro FireWire
> >      .probe() and .resume() on one hand and the O2Micro SDHCI
> >      .probe() and .resume() on the other hand?
> 
> If serialization is required between two drivers, that sounds like a
> driver bug.  What are the two drivers involved?

>From what I can tell, there is no driver bug but an unfortunate interaction
between parts of a combo controller which in theory should functionally be
totally unrelated.

First we had lots and lots of slightly different and inconclusive reports
from various people about the O2Micro FireWire part (or/and the SDHCI
part) failing to work after boot or after PM resume.  Jennifer's recent
reports show that this happens if the two devices are being .probed() at
the same time (or perhaps not exactly at the same time but close together;
at least the firewire-ohci .probe() takes long enough to make some overlap
probable of the .probe()s were called asynchronously baut close together).

The involved drivers are:

    drivers/firewire/firewire-ohci.ko (drivers/firewire/ohci.c)
    drivers/mmc/host/sdhci-pci.ko     (drivers/mmc/host/sdhci-pci.c)


The involved device is either this triple combo device:

0b:00.0 FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:11f7] (rev 05) (prog-if 10 [OHCI])
	Subsystem: Dell Device [1028:04a4]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx+
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 42
	Region 0: Memory at e0130000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci

0b:00.1 SD Host controller [0805]: O2 Micro, Inc. Device [1217:8320] (rev 05) (prog-if 01)
	Subsystem: Dell Device [1028:04a4]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 16
	Region 0: Memory at e0120000 (32-bit, non-prefetchable) [size=512]
	Capabilities: <access denied>
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci-pci

0b:00.2 Mass storage controller [0180]: O2 Micro, Inc. Device [1217:8330] (rev 05)
	Subsystem: Dell Device [1028:04a4]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin C routed to IRQ 10
	Region 0: Memory at e0110000 (32-bit, non-prefetchable) [size=1K]
	Region 2: Memory at e0100000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>


Or this dual combo device:

09:00.0 FireWire (IEEE 1394) [0c00]: O2 Micro, Inc. Device [1217:13f7] (rev 05) (prog-if 10 [OHCI])
	Subsystem: Dell Device [1028:04b4]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 17
	Region 0: Memory at e1a30000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: firewire_ohci
	Kernel modules: firewire-ohci

09:00.1 SD Host controller [0805]: O2 Micro, Inc. Device [1217:8321] (rev 05) (prog-if 01)
	Subsystem: Dell Device [1028:04b4]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 18
	Region 0: Memory at e1a20000 (32-bit, non-prefetchable) [size=512]
	Capabilities: <access denied>
	Kernel driver in use: sdhci-pci
	Kernel modules: sdhci-pci

-- 
Stefan Richter
-=====-===-- -=== =---=
http://arcgraph.de/sr/

Re: [Bug 43247] O2 micro SD/MMC+1394 controller: 1394 device can't work (Register access failure)

[Bjorn Helgaas]

> Jennifer and the other reporters of the issue most certainly all used
> modular kernels, i.e. got the drivers loaded by udev.
>
> module_init() doesn't matter, but
>   - .probe(),
>   - .resume()
> do.  So as you say, if the drivers were statically linked, then at least
> .probe() would be performed serially, one PCI device after another,
> right?  But AFAIK .resume() would still be performed in parallel by a
> pool of kernel threads in current kernels.

OK, I see.  When both drivers are loaded near the same time via udev,
the firewire driver doesn't work correctly.  I don't know of anything
that serializes driver registration from dynamically loaded modules.

I wouldn't bother with the resume issue until after the load-time
issue is resolved because suspend/resume makes things harder to debug.
 You might be able to try loading/unloading the modules in a loop to
reproduce the issue in a single boot.

> From what I can tell, there is no driver bug but an unfortunate interaction
> between parts of a combo controller which in theory should functionally be
> totally unrelated.

That's plausible.  But I can't think of anything useful the PCI core
can do here.  If you can identify a hardware issue in the device, it's
possible you could write a quirk to work around it.  But after the
driver has called pci_enable_device() (the last point at which quirks
are applied), the PCI core is pretty much out of the picture.

Maybe something could be added to one or both drivers to look for
these devices and try deal with them?  I'm afraid I don't have any
good ideas here.