On Tue, Jul 9, 2013 at 3:35 AM, Chris Clayton <chris2553@xxxxxxxxx> wrote: > Hello again, Bjorn. > > On 04/01/13 18:28, Bjorn Helgaas wrote: > > <snip> > > >>>> Hi Chris, >>>> >>>> The current Linux acpiphp driver doesn't do anything unless it finds >>>> devices with _EJ0 or _RMV methods, and your DSDT has neither. But I >>>> think that implementation is incorrect because I'm not convinced that >>>> those methods are required in order to do hotplug via ACPI. For >>>> example, your DSDT *does* have an _L01 method that does notifications >>>> to the root ports. I suspect that hotplug events on your box generate >>>> an SCI that invokes that method. Linux basically ignores the >>>> resulting notify events, and I suspect that hotplug works on Windows >>>> because it is paying attention to them. >>>> >>>> Can you build a kernel with CONFIG_ACPI_DEBUG=y, do the following, and >>>> attach all the output to the bugzilla? >>>> >>>> 1) Boot with empty ExpressCard slot (without using "pcie_ports=native") >>>> 2) # echo 0x00010004 > /sys/module/acpi/parameters/debug_layer >>>> 3) # echo 0x08000004 > /sys/module/acpi/parameters/debug_level >>>> 4) # lspci -vv >>>> 5) # setpci -s 1c.3 0x42.w >>>> 6) # setpci -s 1c.3 0x5a.w >>>> 7) # setpci -s 1c.3 0xd8.l >>>> 8) Insert ExpressCard >>>> 9) # setpci -s 1c.3 0x5a.w >>>> 10) # dmesg >>>> >>>> Here's what I think we'll see: >>>> >>>> - Slot Implemented (bit 8 of XCAP at 0x42) set, indicating a slot is >>>> implemented below this root port >>>> - Hot Plug SCI Enable (bit 30 of MPC at 0xd8) set, indicating that the >>>> root port should generate an SCI whenever a hotplug event is detected >>>> - Presence Detect State (bit 6 of SLTSTS at 0x5a) change from 0 with >>>> the slot empty to 1 with the slot occupied >>>> - pciehp doing nothing (since _OSC didn't grant the OS permission to >>>> use PCIe native hotplug) >>>> - dmesg indication of the SCI, leading to a Bus Check notification to >>>> \_SB.PCI0.RP04, which is the 1c.3 root port leading to the ExpressCard >>>> slot >>>> >>> >>> As far as I can see, your predicted outcomes where correct. I've added >>> the >>> logs to the bugzilla report. >> >> >> Yes, it behaved exactly as I expected. I attached a few more details >> of the analysis to the bug report >> (https://bugzilla.kernel.org/show_bug.cgi?id=54981). I think we need >> to rework acpiphp to fix this. We will fix it, but I don't know who >> will do it, or when it will happen. My list is growing faster than I >> can deal with :( >> > > I see that there has been quite a bit of work in the acpiphp area recently. > Is any of it intended to fix (or ease the subsequent fixing of) this bug > report, please? The problem on your system is that acpiphp doesn't work correctly because it expects a certain combination of _ADR/_EJ0/_RMV methods, and your system doesn't quite match. Rafael's acpiphp work is definitely addressing that issue, but I don't know whether he's made it far enough yet. I doubt that work will appear in a v3.11-rc release, though. More likely it will appear in -next fairly soon and will first appear in Linus' tree in v3.12-rc1. So if you want to test it, either try out -next or wait for v3.12-rc1. > It's not a big deal if it isn't - I do have a system that, via kernel > command line arguments, recognises expresscard devices when I plug them into > the slot. But when the release comes along that includes the reworking of > acpiphp that you mentioned, I will give extra attention to hotplugging when > I try out the -rc kernels on my laptop. Thanks! We'll certainly appreciate any testing reports. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
