On Tue, Aug 21, 2018 at 07:47:04AM +0200, Lukas Wunner wrote: > On Mon, Aug 20, 2018 at 06:06:24PM -0500, Bjorn Helgaas wrote: > > mmyangfl@xxxxxxxxx reported a problem [1]: on v4.17, a QCA9005 AR9462 > > wifi device was present at boot, but disappeared after suspend/resume. > > > > He also tested a recent kernel (5c60a7389d79, from Thu Aug 16), > > where the suspend/resume problem doesn't seem to happen, but the wifi > > device isn't enumerated correctly at boot-time. > > > > [ 0.928714] pciehp 0000:04:00.0:pcie204: Slot #0 AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+ Interlock- NoCompl- LLActRep+ > > [ 0.928752] pciehp 0000:04:00.0:pcie204: Slot(0-1): Card not present > > [ 0.928811] pciehp 0000:04:00.0:pcie204: Slot(0-1): Link Up > > [ 0.928815] pciehp 0000:04:00.0:pcie204: Slot(0-1): No adapter > > > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=200839 > > [2] https://bugzilla.kernel.org/attachment.cgi?id=277923 > > The hardware appears to be broken in that the Presence Detect State bit > in the Slot Status register is 0 (Slot Empty) even though the slot is > occupied. [...] > Possible solutions: > > (a) Be lenient towards broken hardware and accept DLActive+ as a proxy > for PresDet+. > > (b) Add a blacklist to pciehp such that it doesn't bind to [1ae9:0200]. > The bug reporter writes that "it's a single Half Mini PCIe card, > with two chipsets (Wil6110? + AR9462) combined by a PCIe hub". > This sounds like it's not really hotpluggable. > (Is Mini PCIe hotplug capable at all?) > > Let me go through the driver and see if (a) is feasible and how intrusive > it would be. So (a) would seem to be feasible, we could add a quirk for devices like this to call pciehp_check_link_active() in pciehp_get_adapter_status(). Alternatively, we could generally add a call to pciehp_check_link_active() in get_adapter_status(), pciehp_check_presence() and pcie_init() and thus avoid a quirk for this specific device. The existing call in __pciehp_enable_slot() could actually be removed, this code path is only entered if either PDS or DLLLA is set. And the third option would be to add a quirk like quirk_hotplug_bridge() which sets is_hotplug_bridge = 0 on this broken device such that pciehp doesn't bind to it in the first place. Bjorn, please let me know which of these options you'd prefer. Thanks, Lukas
