linux-kernel - Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

lists.openwall.net		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 linux-cve-announce 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]

Message-ID: <Pine.LNX.4.44L0.1706091036070.2100-100000@iolanthe.rowland.org>
Date:   Fri, 9 Jun 2017 10:43:43 -0400 (EDT)
From:   Alan Stern <stern@...land.harvard.edu>
To:     Kai-Heng Feng <kai.heng.feng@...onical.com>
cc:     gregkh@...uxfoundation.org, <linux-usb@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: host: ehci: workaround PME bug on AMD EHCI controller

On Fri, 9 Jun 2017, Kai-Heng Feng wrote:

> As Alan Stern points out [1], the PME signal is not enabled when
> controller is in D3, therefore it's not being woken up when new deivces
> get plugged in.
> 
> Workaround this bug by preventing the controller enters D3 power state.
> 
> [1] https://www.spinics.net/lists/linux-usb/msg157462.html
> 
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@...onical.com>
> ---
>  drivers/usb/host/ehci-pci.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
> index 93326974ff4b..616685f83954 100644
> --- a/drivers/usb/host/ehci-pci.c
> +++ b/drivers/usb/host/ehci-pci.c
> @@ -181,6 +181,8 @@ static int ehci_pci_setup(struct usb_hcd *hcd)
>  		if (pdev->device == 0x7808) {
>  			ehci->use_dummy_qh = 1;
>  			ehci_info(ehci, "applying AMD SB700/SB800/Hudson-2/3 EHCI dummy qh workaround\n");
> +
> +			pdev->dev_flags |= PCI_DEV_FLAGS_NO_D3;
>  		}
>  		break;
>  	case PCI_VENDOR_ID_VIA:

Is this really the right solution?  Maybe it would be better to allow 
the controller to go into D3 provided no wakeup signal is needed.  You 
could do:

		device_set_wakeup_capable(&pdev->dev, 0);

Another alternative is to put the controller into D2 instead of D3, but 
(1) I don't know how to do that, and (2) we don't know if wakeup 
signalling works any better in D2 than it does in D3.

Alan Stern