[PATCH v2] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW

hias Nyman for pointing us in the right direction. Signed-off-by: Daniel Drake <dr...@endlessm.com> Link: http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=bv1xhxv_gy3bzioo_n...@mail.gmail.com https://phabricator.endlessm.com/T21410 --- Notes: This should be considered for Li

[PATCH] ACPI / PM: allow deeper wakeup power states with no _SxD nor _SxW

hias Nyman for pointing us in the right direction. Signed-off-by: Daniel Drake <dr...@endlessm.com> Link: http://lkml.kernel.org/r/CAB4CAwf_k-WsF3zL4epm9TKAOu0h=bv1xhxv_gy3bzioo_n...@mail.gmail.com --- drivers/acpi/device_pm.c | 11 --- 1 file changed, 8 insertions(+), 3 deletion

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

On Mon, Mar 19, 2018 at 6:36 AM, Rafael J. Wysocki wrote: > On Fri, Mar 16, 2018 at 10:06 AM, Mathias Nyman > wrote: >> Adding Rafael directly to CC >> >> In short, if _S3D and _S3W are missing in DSDT then a PCI device >> stays in D0 during

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

> I've studied the ACPI spec trying to understand better, but I'm > struggling with the question: > What is the maximum number (lowest power) permitted device power state > for a device that is configured as able to wake the system from S3, > **that does not implement the _S3W method**? Actually

Re: Intel GemniLake xHCI connected devices can never wake up the system from suspend

Hi, I'm working alongside Chris on this issue. On Fri, Mar 16, 2018 at 12:11 AM, Mathias Nyman wrote: > Scope (_SB.PCI0.XHC) has _PS0 method, so Linux will look for a _S3W to get > the > lowest possible D state in S3, but_S3W is missing, so Linux pci-acpi code >

Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

On Wed, Dec 20, 2017 at 6:53 PM, Brian Norris wrote: > > On Wed, Dec 20, 2017 at 07:00:07PM +0800, Kai-Heng Feng wrote: > > This commit causes a regression on some QCA ROME chips. The USB device > > reset happens in btusb_open(), hence firmware loading gets interrupted.

Re: [PATCH v3] USB: Force disconnect Huawei 4G modem during suspend

Hi Oliver, On Wed, Oct 18, 2017 at 5:31 PM, Oliver Neukum <oneu...@suse.com> wrote: > Am Mittwoch, den 18.10.2017, 15:15 +0800 schrieb Daniel Drake: >> Notes: >> v2: >> - Handle quirk later in suspend, to avoid interfering with other parts >> of th

[PATCH v3] USB: Force disconnect Huawei 4G modem during suspend

ata ) Sub=00 Prot=02 Driver= I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Based on an earlier patch by Chris Chiu. Signed-off-by: Daniel Drake <dr...@endlessm.com> --- Notes: v2:

[PATCH v2] USB: Force disconnect Huawei 4G modem during suspend

ata ) Sub=00 Prot=02 Driver= I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Based on an earlier patch by Chris Chiu. Signed-off-by: Daniel Drake <dr...@endlessm.com> --- Notes: v2:

Re: [PATCH] USB: Force disconnect Huawei 4G modem during suspend

On Wed, Oct 11, 2017 at 11:04 PM, Alan Stern wrote: > Also, you should check whether this is for a runtime suspend or a > system suspend. You don't want to go around disconnecting a device > whenever it gets runtime suspended! Good point, I had not considered runtime

[PATCH] USB: Force disconnect Huawei 4G modem during suspend

6 Ivl=2ms I: If#= 1 Alt= 0 #EPs= 0 Cls=0a(data ) Sub=00 Prot=02 Driver= I: If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver= E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms Signed-off-by: Chris Chiu <c...@endlessm.com> Signed-off-by: D

Re: Huawei integrated modem causes instant resume from suspend on Acer P648-G3

On Wed, Sep 27, 2017 at 3:12 PM, Oliver Neukum wrote: > 1) kernel version? Currently testing 4.14.0-rc2 but reproduced on multiple older versions too going back to 4.8. (Have not found a working kernel version) > 2) driver used? The problem is reproducible just with the base

Huawei integrated modem causes instant resume from suspend on Acer P648-G3

Hi, The Acer TravelMate P648-G3 laptop includes this integrated Huawei 4G modem on the USB bus: T: Bus=01 Lev=01 Prnt=01 Port=08 Cnt=04 Dev#= 5 Spd=480 MxCh= 0 D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=ff MxPS=64 #Cfgs= 3 P: Vendor=12d1 ProdID=15c3 Rev= 1.02 S: Manufacturer=Huawei

[PATCH] Bluetooth: btusb: match generic class code in interface descriptor

: Ad=87(I) Atr=03(Int.) MxPS= 64 Ivl=500us Signed-off-by: Daniel Drake dr...@endlessm.com --- drivers/bluetooth/btusb.c | 1 + 1 file changed, 1 insertion(+) This replaces/obsoletes: [PATCH] Bluetooth: btusb: Recognize Realtek shared wifi/bluetooth devices [PATCH] Bluetooth: btusb: Add

Re: 3.17-rc6 on ODROID: ERROR: Bad of_node_put() on /ehci@12580000/port@1

On Wed, Oct 1, 2014 at 12:36 AM, Vivek Gautam gautam.vi...@samsung.com wrote: One reason i doubt why it could be coming is because we are specifically putting the child after doing everything with it. When we are getting the child node using for_each_available_child_of_node(), which calls

Re: [PATCH v2] phy: phy-samsung-usb2: Change phy power on/power off sequence

are powered on and off. Signed-off-by: Kamil Debski k.deb...@samsung.com Tested on ODROID-U2 with the internal LAN (which is a USB device), and an external USB mouse connected via the internal USB hub. Tested-by: Daniel Drake dr...@endlessm.com -- To unsubscribe from this list: send the line

Re: [PATCH] phy: phy-samsung-usb2: Change phy power on/power off sequence

without power cycling (it's nRESET pin is connected to P3V3). I found that removing regulator-always-on from buck8_reg: BUCK8 in the dts file fixes this problem. Yes, that fixes the problem. Thanks! Tested-by: Daniel Drake dr...@endlessm.com -- To unsubscribe from this list: send the line

Re: [PATCH] phy: phy-samsung-usb2: Change phy power on/power off sequence

On Tue, Jun 24, 2014 at 1:54 PM, Kamil Debski k.deb...@samsung.com wrote: The Exynos4412 USB 2.0 PHY hardware differs from the description provided in the documentation. Some register bits have different function. This patch fixes the defines of register bits and changes the way how phys are