Well, after comparing the kernel log from both systems, it seems that the device controller simply isn't being enumerated by the kernel for some reason. Here's the relevant section from the Android kernel: <6>[ 0.612857] PCI host bridge to bus 0000:00 <6>[ 0.612869] pci_bus 0000:00: root bus resource [bus 00-ff] <6>[ 0.612877] pci_bus 0000:00: root bus resource [io 0x0000-0x006f] <6>[ 0.612885] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7] <6>[ 0.612893] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff] <6>[ 0.612900] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff] <6>[ 0.612908] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff] <6>[ 0.612915] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff] <6>[ 0.612923] pci_bus 0000:00: root bus resource [mem 0x7d000001-0x7f000000] <6>[ 0.612931] pci_bus 0000:00: root bus resource [mem 0x80000000-0x90effffe] <6>[ 0.612938] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed40fff] <7>[ 0.612960] pci 0000:00:00.0: [8086:0f00] type 00 class 0x060000 <7>[ 0.613276] pci 0000:00:02.0: [8086:0f31] type 00 class 0x030000 <7>[ 0.613304] pci 0000:00:02.0: reg 10: [mem 0x90400000-0x907fffff] <7>[ 0.613326] pci 0000:00:02.0: reg 18: [mem 0x80000000-0x8fffffff pref] <7>[ 0.613346] pci 0000:00:02.0: reg 20: [io 0x1000-0x1007] <7>[ 0.613672] pci 0000:00:03.0: [8086:0f38] type 00 class 0x048000 <7>[ 0.613696] pci 0000:00:03.0: reg 10: [mem 0x90000000-0x903fffff] <7>[ 0.614052] pci 0000:00:14.0: [8086:0f35] type 00 class 0x0c0330 <7>[ 0.614087] pci 0000:00:14.0: reg 10: [mem 0x90e00000-0x90e0ffff 64bit] <7>[ 0.614179] pci 0000:00:14.0: PME# supported from D3hot D3cold <7>[ 0.614473] pci 0000:00:16.0: [8086:0f37] type 00 class 0x0c0380 <6>[ 0.614488] EM:OEM1 table found, size=64 <6>[ 0.614493] OEM1 charging bit = 1 <7>[ 0.614514] pci 0000:00:16.0: reg 10: [mem 0x90800000-0x909fffff] <7>[ 0.614530] pci 0000:00:16.0: reg 14: [mem 0x90e2e000-0x90e2efff] <7>[ 0.614611] pci 0000:00:16.0: PME# supported from D0 D3hot <7>[ 0.614916] pci 0000:00:1a.0: [8086:0f18] type 00 class 0x108000 <7>[ 0.614957] pci 0000:00:1a.0: reg 10: [mem 0x90d00000-0x90dfffff] <7>[ 0.614979] pci 0000:00:1a.0: reg 14: [mem 0x90c00000-0x90cfffff] <7>[ 0.615118] pci 0000:00:1a.0: PME# supported from D0 D3hot <7>[ 0.615416] pci 0000:00:1f.0: [8086:0f1c] type 00 class 0x060100 <7>[ 0.615775] pci_bus 0000:00: on NUMA node 0 As you can see, our device controller is recognized and enumerated in Android. I suppose this explains why it works there. :) Here's the relevant section from the mainline kernel: [ 0.636189] PCI host bridge to bus 0000:00 [ 0.636196] pci_bus 0000:00: root bus resource [io 0x0070-0x0077] [ 0.636201] pci_bus 0000:00: root bus resource [io 0x0000-0x006f window] [ 0.636205] pci_bus 0000:00: root bus resource [io 0x0078-0x0cf7 window] [ 0.636209] pci_bus 0000:00: root bus resource [io 0x0d00-0xffff window] [ 0.636213] pci_bus 0000:00: root bus resource [mem 0x000a0000-0x000bffff window] [ 0.636217] pci_bus 0000:00: root bus resource [mem 0x000c0000-0x000dffff window] [ 0.636221] pci_bus 0000:00: root bus resource [mem 0x000e0000-0x000fffff window] [ 0.636225] pci_bus 0000:00: root bus resource [mem 0x90c00000-0x90ffffff window] [ 0.636228] pci_bus 0000:00: root bus resource [mem 0x7cf00001-0x7ef00000 window] [ 0.636232] pci_bus 0000:00: root bus resource [mem 0x80000000-0x908ffffe window] [ 0.636236] pci_bus 0000:00: root bus resource [mem 0xfed40000-0xfed40fff window] [ 0.636241] pci_bus 0000:00: root bus resource [bus 00-ff] [ 0.636258] pci 0000:00:00.0: [8086:0f00] type 00 class 0x060000 [ 0.636608] pci 0000:00:02.0: [8086:0f31] type 00 class 0x030000 [ 0.636627] pci 0000:00:02.0: reg 0x10: [mem 0x90000000-0x903fffff] [ 0.636644] pci 0000:00:02.0: reg 0x18: [mem 0x80000000-0x8fffffff pref] [ 0.636659] pci 0000:00:02.0: reg 0x20: [io 0x1000-0x1007] [ 0.637019] pci 0000:00:14.0: [8086:0f35] type 00 class 0x0c0330 [ 0.637045] pci 0000:00:14.0: reg 0x10: [mem 0x90800000-0x9080ffff 64bit] [ 0.637128] pci 0000:00:14.0: PME# supported from D3hot D3cold [ 0.637451] pci 0000:00:1a.0: [8086:0f18] type 00 class 0x108000 [ 0.637477] pci 0000:00:1a.0: reg 0x10: [mem 0x90700000-0x907fffff] [ 0.637491] pci 0000:00:1a.0: reg 0x14: [mem 0x90600000-0x906fffff] [ 0.637596] pci 0000:00:1a.0: PME# supported from D0 D3hot [ 0.637915] pci 0000:00:1f.0: [8086:0f1c] type 00 class 0x060100 [ 0.638290] pci_bus 0000:00: on NUMA node 0 Here are the complete logs for both systems: Mainline: https://gist.githubusercontent.com/jakogut/f726178f480b5daa1a917e3e41b46d9f/raw/80b0c273ec6a0b434c1ab0f9493283bbd0ab1635/dmesg.log Android: https://gist.githubusercontent.com/jakogut/a0f77161ea3ae886bf31e2ca6c1c33a5/raw/2a2c4b6f9a5f11be15938f58161b77d730874c6d/dmesg.log I modified the _STA method from the OTG1 device to always return 0xF, and the device controller still didn't show up on the PCI bus. I compared the disassembled DSDTs from both systems as well, and the Android DSDT is longer, but the only differences seem to be additional inconsequential devices, like cameras and ambient light sensors. I tried booting the mainline kernel with the Android DSDT, but it didn't bring up the MMC device, hence no root. I suppose I could try booting the Android kernel in my Linux OS, where I have better debugging tools and control over the kernel command line. At the very least, it would tell me if the DSDT is the culprit. -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
