lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 21 Aug 2018 09:25:41 +0200
From:   Lukas Wunner <>
To:     Bjorn Helgaas <>
Subject: Re: Enumeration issue with QCA9005 AR9462

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:
> > 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]
> > [2]
> 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.



Powered by blists - more mailing lists