[PATCH 2/2] usb: core: Attempt power cycle when port is in eSS.Disabled state

be caused by invalid VBus, and after some expiremets, it does show that the SMSC hub can be brought back after a power cycle. So let's power cycle the port at the end of reset resume attempt, if it's in eSS.Disabled state. Signed-off-by: Kai-Heng Feng --- drivers/usb/core/hub.c | 21

Re: [PATCH v4 2/2] ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound to a driver

Hi Takashi, > On Sep 25, 2019, at 19:32, Kai-Heng Feng wrote: > > Nvidia proprietary driver doesn't support runtime power management, so > when a user only wants to use the integrated GPU, it's a common practice > to let dGPU not to bind any driver, and let its upstream port

Re: e1000e regression - 5.4rc1

Hi Tobias, > On Oct 5, 2019, at 03:52, Tobias Klausmann > wrote: > > Hello, > > On 04.10.19 19:36, Kai-Heng Feng wrote: >> Hi Tobias >> >>> On Oct 4, 2019, at 18:34, Tobias Klausmann >>> wrote: >>> >>> Hello all, >

[PATCH] HID: i2c-hid: Remove runtime power management

. Signed-off-by: Kai-Heng Feng --- drivers/hid/i2c-hid/i2c-hid-core.c | 111 ++--- 1 file changed, 4 insertions(+), 107 deletions(-) diff --git a/drivers/hid/i2c-hid/i2c-hid-core.c b/drivers/hid/i2c-hid/i2c-hid-core.c index 2a7c6e33bb1c..5ab4982b3a7b 100644 --- a/drivers/hid

Re: [PATCH] HID: i2c-hid: Remove runtime power management

Hi Benjamin, > On Oct 11, 2019, at 17:27, Benjamin Tissoires > wrote: > > Hi, > > [Adding Mika, who introduced runpm in i2c-hid] > > few questions, remarks: > > On Tue, Oct 8, 2019 at 10:26 PM Hans de Goede wrote: >> >> Hi, >> >>

[PATCH v2] HID: i2c-hid: Remove runtime power management

, my power meter reports little to none energy saving when i2c-hid is runtime suspended. So let's remove runtime power management since there is no actual benefit. Signed-off-by: Kai-Heng Feng --- v2: - Remove unused label and wording change. drivers/hid/i2c-hid/i2c-hid-core.c | 118

Re: [PATCH v3] usb: Add a new quirk to let buggy hub enable and disable LPM during suspend and resume

> On Oct 4, 2019, at 03:04, Alan Stern wrote: > > On Fri, 4 Oct 2019, Kai-Heng Feng wrote: > >> Dell WD15 dock has a topology like this: >> /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 1M >>|__ Port 1: Dev 2, If 0, C

Re: [PATCH v2 2/2] PCI: pciehp: Prevent deadlock on disconnect

; > Now that I looked more closely, I realized it actually is not supposed > to remove the hierarchy below so indeed it might be possible to do that > without taking pci_lock_rescan_remove(). This series fixes S3 resume hang when native PCIe TBT is connected to TBT dock. Is there going to be a v

[PATCH v6 2/2] ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound to a driver

the runtime suspend requirement for dGPU's HDA function, to disable the power source to save lots of power. BugLink: https://bugs.launchpad.net/bugs/1840835 Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers") Signed-off-by: Kai-Heng Feng --- v5, v6: - No change. v4: - Find upstream port

[PATCH v6 1/2] PCI: Add a helper to check Power Resource Requirements _PR3 existence

A driver may want to know the existence of _PR3, to choose different runtime suspend behavior. A user will be add in next patch. This is mostly the same as nouveau_pr3_present(). Reported-by: kbuild test robot Signed-off-by: Kai-Heng Feng --- v6: - Only define the function when CONFIG_ACPI

Re: [PATCH v6 1/2] PCI: Add a helper to check Power Resource Requirements _PR3 existence

> On Oct 18, 2019, at 16:18, Takashi Iwai wrote: > > On Fri, 18 Oct 2019 09:38:47 +0200, > Kai-Heng Feng wrote: >> >> A driver may want to know the existence of _PR3, to choose different >> runtime suspend behavior. A user will be add in next patch.

[PATCH 1/2] Revert "ALSA: hda/realtek: Fix pop noise on ALC225"

ink: https://bugs.launchpad.net/bugs/1875916 Signed-off-by: Kai-Heng Feng --- sound/pci/hda/patch_realtek.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index b26f0acfd86e..dedf0c17f198 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sou

[PATCH 2/2] ALSA: hda/realtek - Fix S3 pop noise on Dell Wyse

able power save node for the affected Dell Wyse platform. Fixes: 317d9313925c ("ALSA: hda/realtek - Set default power save node to 0") BugLink: https://bugs.launchpad.net/bugs/1866357 Signed-off-by: Kai-Heng Feng --- sound/pci/hda/patch_realtek.c | 16 1 file changed, 16

[PATCH] PCI: Enable ASPM L1 on TI PCIe-to-PCI bridge

Windows does, to save additional power. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571 Signed-off-by: Kai-Heng Feng --- drivers/pci/quirks.c | 21 + 1 file changed, 21 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index ca9ed5774eb1

[PATCH] xhci: Prevent runtime suspend all the time with XHCI_RESET_ON_RESUME quirk

with XHCI_RESET_ON_RESUME quirk. Signed-off-by: Kai-Heng Feng --- drivers/usb/host/xhci-pci.c | 3 ++- drivers/usb/host/xhci.c | 19 --- 2 files changed, 2 insertions(+), 20 deletions(-) diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c index 766b74723e64

Re: [PATCH] xhci: Prevent runtime suspend all the time with XHCI_RESET_ON_RESUME quirk

> On May 4, 2020, at 17:47, Oliver Neukum wrote: > > Am Montag, den 04.05.2020, 17:19 +0800 schrieb Kai-Heng Feng: >> Etron EJ168 USB 3.0 Host Controller stops working after S3, if it was >> runtime suspended previously: >> [ 370.080359] pci :02:00.0: can't cha

Re: [PATCH] xhci: Prevent runtime suspend all the time with XHCI_RESET_ON_RESUME quirk

> On May 4, 2020, at 18:13, Mathias Nyman wrote: > > On 4.5.2020 13.02, Kai-Heng Feng wrote: >> >> >>> On May 4, 2020, at 17:47, Oliver Neukum wrote: >>> >>> Am Montag, den 04.05.2020, 17:19 +0800 schrieb Kai-Heng Feng: >>>>

[PATCH v2] xhci: Prevent runtime suspend on Etron EJ168

, reset failed. [ 370.080575] xhci_hcd :04:00.0: PCI post-resume error -19! [ 370.080586] xhci_hcd :04:00.0: HC died; cleaning up This can be fixed by not runtime suspend the controller at all. So disable runtime suspend for EJ168 xHCI device. Signed-off-by: Kai-Heng Feng --- v2: - Use

[PATCH 2/3] ALSA: hda/realtek - Enable micmute LED on and HP system

Though the system uses DMIC, headset mic still uses the HDA, let's use GPIO 0x1 to control the micmute LED. The micmute LED GPIO has a different polarity to the mute LED GPIO, we can use the newly added micmute_led_polarity to indicate that. Signed-off-by: Kai-Heng Feng --- sound/pci/hda

[PATCH 3/3] ALSA: hda/realtek - Add LED class support for micmute LED

e DMIC can facilitate the codec-controlled LED. Signed-off-by: Kai-Heng Feng --- sound/pci/hda/patch_realtek.c | 25 + 1 file changed, 25 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index 6f164ccddde3..82eb7624bbba 100644 --- a/sou

[PATCH 1/3] ALSA: hda/realtek - Introduce polarity for micmute LED GPIO

Currently mute LED and micmute LED share the same GPIO polarity. So split the polarity for mute and micmute, in case they have different polarities. Signed-off-by: Kai-Heng Feng --- sound/pci/hda/patch_realtek.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git

[PATCH] ASoC: SOF: Update correct LED status at the first time usage of update_mute_led()

: SOF: acpi led support for switch controls") Signed-off-by: Kai-Heng Feng --- sound/soc/sof/control.c | 4 ++-- sound/soc/sof/sof-audio.h | 2 +- sound/soc/sof/topology.c | 2 ++ 3 files changed, 5 insertions(+), 3 deletions(-) diff --git a/sound/soc/sof/control.c b/sound/soc/sof/contr

[PATCH v2 3/3] ALSA: hda/realtek - Add LED class support for micmute LED

e DMIC can facilitate the codec-controlled LED. Signed-off-by: Kai-Heng Feng --- v2: - Only compile the code when CONFIG_LEDS_TRIGGER_AUDIO is reachable. sound/pci/hda/patch_realtek.c | 29 + 1 file changed, 29 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sou

[PATCH] x86/intel: Disable HPET on Intel Coffe Lake platforms

://lore.kernel.org/lkml/20190516090651.1396-1-harry@intel.com/ Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203183 Cc: Suggested-by: Feng Tang Signed-off-by: Kai-Heng Feng --- arch/x86/kernel/early-quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/x86/kernel/early

Re: Alps touchpad generates IRQ storm after S3

Hi Xiaojian, > On Aug 28, 2019, at 22:43, Kai-Heng Feng wrote: > > Hi Mario, > > at 21:25, wrote: > >> KH, >> >> Just make sure I understand details. >> >>> Commit "HID: i2c-hid: Don't reset device upon system resume >> &

[PATCH v4 1/2] PCI: Add a helper to check Power Resource Requirements _PR3 existence

A driver may want to know the existence of _PR3, to choose different runtime suspend behavior. A user will be add in next patch. This is mostly the same as nouveau_pr3_present(). Signed-off-by: Kai-Heng Feng --- v4: - Let caller to find its upstream port device. drivers/pci/pci.c | 16

[PATCH v4 2/2] ALSA: hda: Allow HDA to be runtime suspended when dGPU is not bound to a driver

the runtime suspend requirement for dGPU's HDA function, to disable the power source to save lots of power. BugLink: https://bugs.launchpad.net/bugs/1840835 Fixes: b516ea586d71 ("PCI: Enable NVIDIA HDA controllers") Signed-off-by: Kai-Heng Feng --- v4: - Find upstream port, it's callee's

[PATCH v5 1/2] PCI: Add pci_pr3_present() helper to check Power Resource for D3hot

as nouveau_pr3_present(). Signed-off-by: Kai-Heng Feng --- v5: - Add wording suggestion from Bjorn. v4: - Let caller to find its upstream port device. drivers/pci/pci.c | 16 include/linux/pci.h | 2 ++ 2 files changed, 18 insertions(+) diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c index

Re: [PATCH] Revert "Bluetooth: btusb: Disable runtime suspend on Realtek devices"

Hi Abhishek, > On Jul 30, 2020, at 07:17, Abhishek Pandit-Subedi > wrote: > > This reverts commit 7ecacafc240638148567742cca41aa7144b4fe1e. > > Testing this change on a board with RTL8822CE, I found that enabling > autosuspend has no effect on the stability of the system. The board >

Re: [PATCH] Revert "Bluetooth: btusb: Disable runtime suspend on Realtek devices"

t; * change your kconfig so BT_HCIBTUSB_AUTOSUSPEND=n >>> * use a udev rule to disable autosuspend for specific vid:pid >>> >>> Keeping this change in the kernel makes it impossible to enable >>> autosuspend so it should be reverted. >> >> It's apparently a driver/firmware/hardware issue, so the fix should keep >> inside the kernel. >> However, the fix can be more precise and target only 8723DE. > > lets do that and lets do it quickly since the merge window is close. > Otherwise I really have to revert that patch. Ok, I no longer observe the original issue with the patch reverted. Acked-by: Kai-Heng Feng > > Regards > > Marcel >

[PATCH] USB: quirks: Add no-lpm quirk for another Raydium touchscreen

[1.339152] usb 1-9: Manufacturer: Raydium Corporation ... [6.450497] usb 1-9: can't set config #1, error -110 BugLink: https://bugs.launchpad.net/bugs/1889446 Signed-off-by: Kai-Heng Feng --- drivers/usb/core/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/core/quirks.c

[PATCH] PCI: Mark AMD Navi10 GPU rev 0x00 ATS as broken

ex Deucher Signed-off-by: Kai-Heng Feng --- drivers/pci/quirks.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index 812bfc32ecb8..052efeb9f053 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -5192

[Regression] "SUNRPC: Add "@len" parameter to gss_unwrap()" breaks NFS Kerberos on upstream stable 5.4.y

Hi, Multiple users reported NFS causes NULL pointer dereference [1] on Ubuntu, due to commit "SUNRPC: Add "@len" parameter to gss_unwrap()" and commit "SUNRPC: Fix GSS privacy computation of auth->au_ralign". The same issue happens on upstream stable 5.4.y branch. The mainline kernel doesn't

Re: [Regression] "SUNRPC: Add "@len" parameter to gss_unwrap()" breaks NFS Kerberos on upstream stable 5.4.y

> On Jul 15, 2020, at 23:02, Chuck Lever wrote: > > > >> On Jul 15, 2020, at 10:48 AM, Kai-Heng Feng >> wrote: >> >> Hi, >> >> Multiple users reported NFS causes NULL pointer dereference [1] on Ubuntu, >> due to commit &qu

Re: [Regression] "SUNRPC: Add "@len" parameter to gss_unwrap()" breaks NFS Kerberos on upstream stable 5.4.y

> On Jul 18, 2020, at 01:34, Chuck Lever wrote: > > > >> On Jul 17, 2020, at 1:29 PM, Pierre Sauter wrote: >> >> Hi Chuck, >> >> Am Donnerstag, 16. Juli 2020, 21:25:40 CEST schrieb Chuck Lever: >>> So this makes me think there's a possibility you are not using upstream >>> stable

[PATCH v2] nvme/pci: Add new quirk for SK hynix PC400 NLB off-by-one bug

mented yet, so add a new quirk to workaround the former two commands. BugLink: https://bugs.launchpad.net/bugs/1872383 Cc: kyounghwan sohn Signed-off-by: Kai-Heng Feng --- v2: - SK hynix found the root cause so change the approach accordingly. - lspci is wrong, the device is PC400 instea

Re: [PATCH v2] nvme/pci: Add new quirk for SK hynix PC400 NLB off-by-one bug

> On Jul 24, 2020, at 00:03, Christoph Hellwig wrote: > > On Thu, Jul 23, 2020 at 11:57:31PM +0800, Kai-Heng Feng wrote: >> After commit 6e02318eaea5 ("nvme: add support for the Write Zeroes >> command"), SK hynix PC400 becomes very slow with the following err

[PATCH v3] nvme/pci: Prevent SK hynix PC400 from using Write Zeroes command

mplemented, so disable it completely on SK hynix PC400. BugLink: https://bugs.launchpad.net/bugs/1872383 Cc: kyounghwan sohn Signed-off-by: Kai-Heng Feng --- v3: - Simply disable Write Zeroes command. v2: - SK hynix found the root cause so change the approach accordingly. - lspci is wrong,

Re: 5.7 regression: Lots of PCIe AER errors and suspend failure without pcie=noaer

eems to silence the AER > errors and allow suspend/resume to work again: > > setpci -s 00:1c.0 0x50.B=0x00 > setpci -s 02:00.0 0x90.B=0x00 > > It appears the behavior changed as a result of this patch (which went > into the stable tree for 5.7.6 and so affects 5.7 kernels as well):

[PATCH v3] PCI / PM: Don't runtime suspend when device only supports wakeup from D0

-Heng Feng --- v3: - Add Bugzilla link v2: - Changes wording - Keep old behaviour for devices can't wakeup. drivers/pci/pci-driver.c | 6 ++ drivers/pci/pci.c| 2 +- include/linux/pci.h | 3 +++ 3 files changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/pci/pci

Re: [PATCH 1/2] PCI: pciehp: Do not disable interrupt twice on suspend

when system suspend hook is called. Fixes: 9c62f0bfb832 ("PCI: pciehp: Implement runtime PM callbacks") Reported-by: Kai Heng Feng Signed-off-by: Mika Westerberg Tested-by: Kai-Heng Feng --- drivers/pci/hotplug/pciehp_core.c | 25 +++-- 1 file changed, 23

Re: Opportunistic S0ix blocked by e1000e when ethernet is in use

Hi Jeffrey, at 19:08, Kai-Heng Feng wrote: Hi Jeffrey, There are several platforms that uses e1000e can’t enter Opportunistic S0ix (PC10) when the ethernet has a link partner. This behavior also exits in out-of-tree e1000e driver 3.4.2.1, but seems like 3.4.2.3 fixes the issue

RX CRC errors on I219-V (6) 8086:15be

Hi Jeffrey, We’ve encountered another issue, which causes multiple CRC errors and renders ethernet completely useless, here’s the network stats: /sys/class/net/eno1/statistics$ grep . * collisions:0 multicast:95 rx_bytes:1499851 rx_compressed:0 rx_crc_errors:1165 rx_dropped:0 rx_errors:2330

ca0132 audio in Ubuntu 19.04 only after Windows 10 started, missing ctefx-r3di.bin

Hi Connor, The bug was filed at Launchpad [1], I think the most notable error is [3.768667] snd_hda_intel :00:1f.3: Direct firmware load for ctefx-r3di.bin failed with error -2 The firmware is indeed listed in patch_ca0132.c, but looks like there’s no corresponding file in

Re: [alsa-devel] ca0132 audio in Ubuntu 19.04 only after Windows 10 started, missing ctefx-r3di.bin

at 17:13, Takashi Iwai wrote: On Fri, 28 Jun 2019 08:35:51 +0200, Kai-Heng Feng wrote: Hi Connor, The bug was filed at Launchpad [1], I think the most notable error is [3.768667] snd_hda_intel :00:1f.3: Direct firmware load for ctefx-r3di.bin failed with error -2 The firmware

Re: RX CRC errors on I219-V (6) 8086:15be

at 14:26, Neftin, Sasha wrote: On 6/26/2019 09:14, Kai Heng Feng wrote: Hi Sasha at 5:09 PM, Kai-Heng Feng wrote: Hi Jeffrey, We’ve encountered another issue, which causes multiple CRC errors and renders ethernet completely useless, here’s the network stats: I also tried ignore_ltr

Re: RX CRC errors on I219-V (6) 8086:15be

+linux-pci Hi Sasha, at 6:49 PM, Kai-Heng Feng wrote: at 14:26, Neftin, Sasha wrote: On 6/26/2019 09:14, Kai Heng Feng wrote: Hi Sasha at 5:09 PM, Kai-Heng Feng wrote: Hi Jeffrey, We’ve encountered another issue, which causes multiple CRC errors and renders ethernet completely

Re: RX CRC errors on I219-V (6) 8086:15be

at 02:01, Bjorn Helgaas wrote: On Tue, Jul 02, 2019 at 04:25:59PM +0800, Kai Heng Feng wrote: +linux-pci Hi Sasha, at 6:49 PM, Kai-Heng Feng wrote: at 14:26, Neftin, Sasha wrote: On 6/26/2019 09:14, Kai Heng Feng wrote: Hi Sasha at 5:09 PM, Kai-Heng Feng wrote: Hi Jeffrey, We’ve

Re: [PATCH v2] USB: Disable USB2 LPM at shutdown

at 15:55, Kai-Heng Feng wrote: at 18:22, Kai-Heng Feng wrote: at 00:01, Kai-Heng Feng wrote: On Jan 30, 2019, at 16:21, Greg KH wrote: On Thu, Jan 24, 2019 at 02:16:43PM +0800, Kai-Heng Feng wrote: The QCA Rome USB Bluetooth controller has several issues once LPM gets enabled: - Fails

[PATCH] USB: usb-storage: Add new ID to ums-realtek

There is one more Realtek card reader requires ums-realtek to work correctly. Add the device ID to support it. Signed-off-by: Kai-Heng Feng --- drivers/usb/storage/unusual_realtek.h | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/usb/storage/unusual_realtek.h b/drivers/usb

[PATCH] mfd: intel-lpss: Remove D3cold delay

regression. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202683 Signed-off-by: Kai-Heng Feng --- drivers/mfd/intel-lpss-pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mfd/intel-lpss-pci.c b/drivers/mfd/intel-lpss-pci.c index aed2c0447966..3c271b14e7c6 100644

Re: [PATCH v2 1/2] Bluetooth: Disable LE Advertising in hci_suspend_dev()

at 11:00, Kai Heng Feng wrote: Hi Marcel, at 5:25 PM, Kai-Heng Feng wrote: LE Advertising may wake up system during system-wide sleep, disable it to prevent this issue from happening. Do the reverse in hci_resume_dev(). Do you have any suggestion for this patch? Please let me know

Re: [PATCH] PCI / PM: Don't runtime suspend when device only supports wakeup from D0

at 19:57, Bjorn Helgaas wrote: On Mon, May 27, 2019 at 11:57:47AM -0500, Bjorn Helgaas wrote: On Thu, May 23, 2019 at 12:39:23PM +0800, Kai-Heng Feng wrote: at 04:52, Bjorn Helgaas wrote: On Wed, May 22, 2019 at 02:39:56PM -0400, Alan Stern wrote: On Wed, 22 May 2019, Bjorn Helgaas wrote

Re: [PATCH] PCI / PM: Don't runtime suspend when device only supports wakeup from D0

at 17:39, Rafael J. Wysocki wrote: On Friday, July 5, 2019 9:02:01 AM CEST Kai-Heng Feng wrote: at 19:57, Bjorn Helgaas wrote: On Mon, May 27, 2019 at 11:57:47AM -0500, Bjorn Helgaas wrote: On Thu, May 23, 2019 at 12:39:23PM +0800, Kai-Heng Feng wrote: at 04:52, Bjorn Helgaas wrote

[PATCH 2/2] e1000e: disable force K1-off feature

Forwardport from http://mails.dpdk.org/archives/dev/2016-November/050658.html MAC-PHY desync may occur causing misdetection of link up event. Disabling K1-off feature can work around the problem. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204057 Signed-off-by: Kai-Heng Feng

[PATCH 1/2] e1000e: add workaround for possible stalled packet

/show_bug.cgi?id=204057 Signed-off-by: Kai-Heng Feng --- drivers/net/ethernet/intel/e1000e/ich8lan.c | 10 ++ drivers/net/ethernet/intel/e1000e/ich8lan.h | 2 +- 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/drivers/net/ethernet/intel/e1000e/ich8lan.c b/drivers/net/ethernet

[PATCH v3] xhci: Prevent runtime suspend on Etron EJ168

, reset failed. [ 370.080575] xhci_hcd :04:00.0: PCI post-resume error -19! [ 370.080586] xhci_hcd :04:00.0: HC died; cleaning up This can be fixed by not runtime suspend the controller at all. So disable runtime suspend for EJ168 xHCI device. Signed-off-by: Kai-Heng Feng --- v3

[PATCH] igb: Report speed and duplex as unknown when device is runtime suspended

() while the lock is already hold by upper ethtool layer. So let's take this approach until the igb_runtime_resume() no longer needs to hold rtnl_lock. Suggested-by: Alexander Duyck Signed-off-by: Kai-Heng Feng --- drivers/net/ethernet/intel/igb/igb_ethtool.c | 6 ++ 1 file changed, 6 insertions

[PATCH 2/2] ALSA: hda: Use hdac_to_hda_codec macro

Use hdac_to_hda_codec() instead of container_of(). No functional change intended. Signed-off-by: Kai-Heng Feng --- include/sound/hda_codec.h | 4 sound/pci/hda/patch_hdmi.c | 12 ++-- sound/soc/codecs/hdac_hda.h | 4 3 files changed, 10 insertions(+), 10 deletions

[PATCH 1/2] ALSA: hda: Use dev_to_hdac_dev macro

Use dev_to_hdac_dev() instead of container_of(). No functional change intended. Signed-off-by: Kai-Heng Feng --- sound/hda/ext/hdac_ext_bus.c | 2 +- sound/hda/hdac_device.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/hda/ext/hdac_ext_bus.c b/sound/hda/ext

[PATCH v2] igb: Report speed and duplex as unknown when device is runtime suspended

igb_runtime_resume() , which tries to rtnl_lock() while the lock is already hold by upper ethtool layer. So let's take this approach until the igb_runtime_resume() no longer needs to hold rtnl_lock. Cc: Jeff Kirsher Cc: Aaron Brown Suggested-by: Alexander Duyck Signed-off-by: Kai-Heng Feng --- v2

[PATCH v2] PCI/ASPM: Enable ASPM for root complex <-> bridge <-> bridge case

ts to root complex enables ASPM, instead of removing it completely, to avoid regression. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571 Signed-off-by: Kai-Heng Feng --- drivers/pci/pcie/aspm.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/driver

[PATCH] HID: intel-ish-hid: Replace PCI_DEV_FLAGS_NO_D3 with pci_save_state

PCI_DEV_FLAGS_NO_D3 should not be used outside of PCI core. Instead, we can use pci_save_state() to hint PCI core that the device should stay at D0 during suspend. Signed-off-by: Kai-Heng Feng --- drivers/hid/intel-ish-hid/ipc/pci-ish.c | 15 ++- 1 file changed, 10 insertions(+), 5

Re: [PATCH v2] PCI/ASPM: Enable ASPM for root complex <-> bridge <-> bridge case

> On May 5, 2020, at 21:38, Bjorn Helgaas wrote: > > On Tue, May 05, 2020 at 08:27:59PM +0800, Kai-Heng Feng wrote: >> The TI PCIe-to-PCI bridge prevents the Intel SoC from entering power >> state deeper than PC3 due to disabled ASPM, consumes lots of unnecessary >>

[PATCH v3] PCI/ASPM: Enable ASPM for bridge-to-bridge link

ecial case, as PCIe spec already envisioned ASPM on bridge-to-bridge link. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571 Signed-off-by: Kai-Heng Feng --- v3: - Remove the special case completely. v2: - Enable ASPM on root complex <-> bridge <-> bridge, instead of us

Re: [PATCH] usb: core: hub: limit HUB_QUIRK_DISABLE_AUTOSUSPEND to USB5534B

> On May 15, 2020, at 06:02, Eugeniu Rosca wrote: > > On Tue, May 12, 2020 at 09:36:07PM +0800, Kai-Heng Feng wrote [1]: >> This patch prevents my Raven Ridge xHCI from getting runtime suspend. > > The problem described in v5.6 commit 1208f9e1d758c9 ("USB: hub:

[PATCH] libata: Use per port sync for detach

pad.net/bugs/1867983 Signed-off-by: Kai-Heng Feng --- drivers/ata/libata-core.c | 6 +++--- include/linux/libata.h| 3 +++ 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index beca5f91bb4c..4a698f6388cd 100644 --- a/drivers/ata

Re: [PATCH] libata: Use per port sync for detach

> On May 15, 2020, at 20:38, John Garry wrote: > > On 15/05/2020 12:09, Kai-Heng Feng wrote: >> Commit 130f4caf145c ("libata: Ensure ata_port probe has completed before >> detach") may cause system freeze during suspend. >> Using async_synchronize_full()

Re: [PATCH v3] usb: Add a new quirk to let buggy hub enable and disable LPM during suspend and resume

> On Oct 21, 2019, at 21:59, Mathias Nyman > wrote: > > On 18.10.2019 21.59, Greg Kroah-Hartman wrote: >> On Thu, Oct 17, 2019 at 02:33:00PM +0800, Kai-Heng Feng wrote: >>> >>> >>>> On Oct 4, 2019, at 03:04, Alan Stern wrote: &g

[PATCH v5] drm/i915: Init lspcon chip dynamically

the lspcon chip on the system only gets powered after the cable is plugged. Consolidate lspcon_init() into lspcon_resume() to dynamically init lspcon chip, and make HDMI port work. Closes: https://gitlab.freedesktop.org/drm/intel/issues/203 Signed-off-by: Kai-Heng Feng --- v5: - Consolidate

Re: [PATCH v2] xhci: Set port link to RxDetect if port is not enabled after resume

> On Apr 28, 2020, at 00:49, Mathias Nyman > wrote: > > On 27.4.2020 12.05, Kai-Heng Feng wrote: >> >> >>> On Apr 23, 2020, at 19:25, Mathias Nyman >>> wrote: >>> >>> Was this roothub port forcefully suspended xhci_bus_s

[PATCH] xhci: Make debug message consistent with bus and port number

make debug message consistent. Signed-off-by: Kai-Heng Feng --- drivers/usb/host/xhci-hub.c | 41 + 1 file changed, 23 insertions(+), 18 deletions(-) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb/host/xhci-hub.c index f37316d2c8fa..83088c262cc4 100644 ---

[PATCH] e1000e: Warn if disabling ULP failed

The hardware may stop working if driver failed to disable ULP mode. Take the return value of e1000_disable_ulp_lpt_lp() into account, and pass up the error if it fails. Signed-off-by: Kai-Heng Feng --- drivers/net/ethernet/intel/e1000e/ich8lan.c | 6 +- 1 file changed, 5 insertions(+), 1

Re: [PATCH] xhci: Make debug message consistent with bus and port number

> On May 7, 2020, at 14:45, Greg Kroah-Hartman > wrote: > > On Thu, May 07, 2020 at 02:17:55PM +0800, Kai-Heng Feng wrote: >> Current xhci debug message doesn't always output bus number, so it's >> hard to figure out it's from USB2 or USB3 root hub. >> >

Re: [PATCH] xhci: Make debug message consistent with bus and port number

> On May 7, 2020, at 15:31, Greg Kroah-Hartman > wrote: > > On Thu, May 07, 2020 at 03:15:01PM +0800, Kai-Heng Feng wrote: >> >> >>> On May 7, 2020, at 14:45, Greg Kroah-Hartman >>> wrote: >>> >>> On Thu, May 07, 2020 at 02

[PATCH] e1000e: Disable TSO for buffer overrun workaround

so let's disable TSO by default to regain the loss. Fixes: b10effb92e27 ("e1000e: fix buffer overrun while the I219 is processing DMA transactions") BugLink: https://bugs.launchpad.net/bugs/1802691 Signed-off-by: Kai-Heng Feng --- drivers/net/ethernet/intel/e1000e/netdev.c | 4

Re: [PATCH] HID: multitouch: Remove MT_CLS_WIN_8_DUAL

> On Apr 14, 2020, at 17:18, Kai-Heng Feng wrote: > > After commit c23e2043d5f7 ("HID: multitouch: do not filter mice nodes"), > MT_CLS_WIN_8 also supports mouse nodes, hence make MT_CLS_WIN_8_DUAL > redundant. > > Remove MT_CLS_WIN_8_DUAL accordingly. A

[PATCH 1/2] serial: 8250_pci: Move Pericom IDs to pci_ids.h

Move the IDs to pci_ids.h so it can be used by next patch. Signed-off-by: Kai-Heng Feng --- drivers/tty/serial/8250/8250_pci.c | 6 -- include/linux/pci_ids.h| 6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/tty/serial/8250/8250_pci.c b/drivers

[PATCH 2/2] PCI: Prevent Pericom USB controller OHCI/EHCI PME# defect

tps://bugzilla.kernel.org/show_bug.cgi?id=205981 Signed-off-by: Kai-Heng Feng --- drivers/pci/quirks.c | 12 1 file changed, 12 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index ca9ed5774eb1..db2590243f0d 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirk

[Regression] "iommu/amd: Relax locking in dma_ops path" makes tg3 ethernet transmit queue timeout

Hi, Broadcom ethernet tg3 unusable after commit 92d420ec028d ("iommu/amd: Relax locking in dma_ops path"). After a short period it stops: [ 122.717144] WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:303 dev_watchdog+0x237/0x240() [ 122.717152] NETDEV WATCHDOG: enp3s0 (tg3): transmit queue

[PATCH] HID: i2c-hid: Enable touchpad wakeup from Suspend-to-Idle

Many laptops have the ability to be woken up from Suspend-to-Idle by touchpad. This is also the default behavior on other OSes. So let's enable the wakeup support if the system defaults to use Suspend-to-Idle. Signed-off-by: Kai-Heng Feng --- drivers/hid/i2c-hid/i2c-hid-core.c | 5 + 1

[PATCH v2] HID: i2c-hid: Enable touchpad wakeup from Suspend-to-Idle

Many laptops have the ability to be woken up from Suspend-to-Idle by touchpad. This is also the default behavior on other OSes. So let's enable the wakeup support if the system defaults to use Suspend-to-Idle. Signed-off-by: Kai-Heng Feng --- v2: - Fix compile error when ACPI is not enabled

Re: [Regression] "iommu/amd: Relax locking in dma_ops path" makes tg3 ethernet transmit queue timeout

> On May 18, 2020, at 21:32, Joerg Roedel wrote: > > On Mon, May 18, 2020 at 05:06:45PM +0800, Kai-Heng Feng wrote: >> Particularly, as soon as the spinlock is removed, the issue can be >> reproduced. >> Function domain_flush_complete() doesn't seem to affect

Re: [Regression] "iommu/amd: Relax locking in dma_ops path" makes tg3 ethernet transmit queue timeout

> On May 18, 2020, at 22:05, Kai-Heng Feng wrote: > > > >> On May 18, 2020, at 21:32, Joerg Roedel wrote: >> >> On Mon, May 18, 2020 at 05:06:45PM +0800, Kai-Heng Feng wrote: >>> Particularly, as soon as the spinlock is removed, the iss

Re: [Regression] "iommu/amd: Relax locking in dma_ops path" makes tg3 ethernet transmit queue timeout

> On May 18, 2020, at 23:32, Kai-Heng Feng wrote: > > > >> On May 18, 2020, at 22:05, Kai-Heng Feng wrote: >> >> >> >>> On May 18, 2020, at 21:32, Joerg Roedel wrote: >>> >>> On Mon, May 18, 2020 at 05:06:45PM +0800,

[PATCH v3] HID: intel-ish-hid: Replace PCI_DEV_FLAGS_NO_D3 with pci_save_state

spec mandates. Signed-off-by: Kai-Heng Feng --- v3: - Use multi-line comments. v2: - Wording change. drivers/hid/intel-ish-hid/ipc/pci-ish.c | 16 +++- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/drivers/hid/intel-ish-hid/ipc/pci-ish.c b/drivers/hid/intel-ish-hid

Re: [PATCH v6] drm/i915: Init lspcon after HPD in intel_dp_detect()

> On Jun 10, 2020, at 15:55, Kai-Heng Feng wrote: > > On HP 800 G4 DM, if HDMI cable isn't plugged before boot, the HDMI port > becomes useless and never responds to cable hotplugging: > [3.031904] [drm:lspcon_init [i915]] *ERROR* Failed to probe lspcon > [3.031945] [

Re: [PATCH] xhci: Make debug message consistent with bus and port number

> On Jun 8, 2020, at 17:29, Mathias Nyman wrote: > > On 8.6.2020 6.57, Kai-Heng Feng wrote: >> >> >>> On May 7, 2020, at 18:35, Mathias Nyman >>> wrote: >>> >>> On 7.5.2020 11.21, Greg Kroah-Hartman wrote: >>&

Re: [PATCH 2/2] xhci: Poll for U0 after disabling USB2 LPM

> On Jun 8, 2020, at 19:21, Mathias Nyman wrote: > > On 20.5.2020 13.18, Kai-Heng Feng wrote: >> USB2 devices with LPM enabled may interrupt the system suspend: >> [ 932.510475] usb 1-7: usb suspend, wakeup 0 >> [ 932.510549] hub 1-0:1.0: hub_suspend >> [

[PATCH 1/2] xhci: Suspend ports to U3 directly from U1 or U2

l for USB2 devices, which may take a very long time to switch USB2 LPM on and off. Suggested-by: Mathias Nyman Signed-off-by: Kai-Heng Feng --- drivers/usb/host/xhci-hub.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/usb/host/xhci-hub.c b/drivers/usb

[PATCH 2/2] USB: hub: Suspend and resume port with LPM enabled

ed-off-by: Kai-Heng Feng --- drivers/usb/core/hub.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c index b1e14beaac5f..882b54df6ef5 100644 --- a/drivers/usb/core/hub.c +++ b/drivers/usb/core/hub.c @@ -3285,9 +3285,6 @@ int usb_port_suspend(

[PATCH v6] drm/i915: Init lspcon after HPD in intel_dp_detect()

the lspcon chip on the system only gets powered after the cable is plugged. Consilidate lspcon_init() into lspcon_resume() to dynamically init lspcon chip, and make HDMI port work. Signed-off-by: Kai-Heng Feng --- v6: - Rebase on latest for-linux-next. v5: - Consolidate lspcon_resume

[PATCH] platform/x86: intel-hid: Use hp-wireless for rfkill on HP platforms

hotkey if HPQ6001 is present. Signed-off-by: Kai-Heng Feng --- drivers/platform/x86/intel-hid.c | 31 ++- 1 file changed, 30 insertions(+), 1 deletion(-) diff --git a/drivers/platform/x86/intel-hid.c b/drivers/platform/x86/intel-hid.c index 9ee79b74311c..31091c8faf70

Re: [PATCH 1/2] xhci: Suspend ports to U3 directly from U1 or U2

> On Jun 10, 2020, at 22:32, Alan Stern wrote: > > On Wed, Jun 10, 2020 at 02:42:30PM +0800, Kai-Heng Feng wrote: >> xHCI spec "4.15.1 Port Suspend" states that port can be put to U3 as long >> as Enabled bit is set and from U0, U1 or U2 state. >> >&

Re: [PATCH] leds: core: Use blocking op for system suspend

> On Jul 2, 2020, at 05:28, Jacek Anaszewski wrote: > > Hi Kai-Heng, > > Thank you for the patch. > > On 7/1/20 11:35 AM, Kai-Heng Feng wrote: >> Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon >> system suspend. > > Just

[PATCH v2] leds: core: Flush scheduled work for system suspend

sure LED gets turned off. Signed-off-by: Kai-Heng Feng --- v2: - Use flush_work() instead. drivers/leds/led-class.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c index 3363a6551a70..cc3929f858b6 100644 --- a/drivers/leds/led-class.c +++ b

[BUG] "Pre-boot DMA Protection" makes AMDGPU stop working

Hi, A more detailed bug report can be found at [1]. I have a AMD Renoir system that can't enter graphical session because there are many IOMMU splat. Alex suggested to disable "Pre-boot DMA Protection", I can confirm once it's disabled, AMDGPU starts working with IOMMU enabled. So raise the

Re: [PATCH] net: atlantic: Add support for firmware v4

> On Jul 7, 2020, at 16:46, Alexander Lobakin wrote: > > From: Kai-Heng Feng > Date: Tue, 7 Jul 2020 14:38:28 +0800 > >> We have a new ethernet card that is supported by the atlantic driver: >> 01:00.0 Ethernet controller [0200]: Aquantia Corp. AQC107 NBase-

[PATCH] ALSA: hda/realtek: Serialize setting GPIO LED

to serialize setting the LED, to prevent the issue from happening. Signed-off-by: Kai-Heng Feng --- include/sound/hda_codec.h | 1 + sound/pci/hda/hda_codec.c | 1 + sound/pci/hda/patch_realtek.c | 3 +++ 3 files changed, 5 insertions(+) diff --git a/include/sound/hda_codec.h b/include

Re: [PATCH v3] HID: i2c-hid: Enable touchpad wakeup from Suspend-to-Idle

> On Jun 19, 2020, at 17:56, Hans de Goede wrote: > > Hi, > > On 6/19/20 6:16 AM, Kai-Heng Feng wrote: >> Hi, >>> On Jun 18, 2020, at 23:28, Hans de Goede wrote: >>> >>> Hi, >>> >>> On 6/18/20 4:55 PM, Kai-Heng Feng wrote:

<    3   4   5   6   7   8   9   10   11   >