From: Lane Odenbach <laodenbach(a)gmail.com>
[ Upstream commit 7bab1bd9fdf15b9fa7e6a4b0151deab93df3c80d ]
This fixes the internal microphone in the stated device
Signed-off-by: Lane Odenbach <laodenbach(a)gmail.com>
Link: https://patch.msgid.link/20250715182038.10048-1-laodenbach@gmail.com
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
**YES**
This commit should be backported to stable kernel trees for the
following reasons:
1. **Bug Fix for Hardware Functionality**: The commit fixes a non-
functional internal microphone on the HP Laptop 17 cp-2033dx. This is
a hardware enablement bug fix that prevents users from using a core
functionality of their laptop.
2. **Minimal and Contained Change**: The change is extremely minimal -
it only adds 7 lines to the DMI quirk table:
```c
+ {
+ .driver_data = &acp6x_card,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
+ DMI_MATCH(DMI_BOARD_NAME, "8A81"),
+ }
+ },
```
This is a simple DMI match addition with no algorithmic changes or
side effects.
3. **Low Risk of Regression**: DMI quirk additions are inherently safe
as they only affect the specific hardware model being added. The
change cannot impact any other system that doesn't match the exact
DMI strings.
4. **Follows Established Pattern**: All five similar commits provided as
reference (for HP models with board names 8BD6, 8A3E, 8A22, 8A27, and
other manufacturers) were marked as "Backport Status: YES". This type
of commit has a well-established history of being backported.
5. **User-Impacting Issue**: Without this quirk, users of the HP Laptop
17 cp-2033dx cannot use their internal microphone, which is essential
functionality for video calls, recording, and voice commands. This
significantly degrades the user experience.
6. **Consistent with Stable Tree Rules**: The commit meets the stable
kernel criteria:
- It fixes a real bug that bothers users (non-functional microphone)
- It's obviously correct and tested (standard DMI quirk pattern)
- It's small (7 lines)
- It doesn't add new features, only fixes existing functionality
The AMD Yellow Carp (YC) audio driver uses DMI quirks to enable the
internal microphone on specific laptop models. Without these quirks, the
DMIC (Digital Microphone) won't be properly initialized on affected
systems. This is a common pattern in the Linux kernel for handling
hardware-specific configurations.
sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index 66ef8f4fd02cd..74f8e12aa7107 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -577,6 +577,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "8A7F"),
}
},
+ {
+ .driver_data = &acp6x_card,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
+ DMI_MATCH(DMI_BOARD_NAME, "8A81"),
+ }
+ },
{
.driver_data = &acp6x_card,
.matches = {
--
2.39.5
From: Lane Odenbach <laodenbach(a)gmail.com>
[ Upstream commit 7bab1bd9fdf15b9fa7e6a4b0151deab93df3c80d ]
This fixes the internal microphone in the stated device
Signed-off-by: Lane Odenbach <laodenbach(a)gmail.com>
Link: https://patch.msgid.link/20250715182038.10048-1-laodenbach@gmail.com
Signed-off-by: Mark Brown <broonie(a)kernel.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
**YES**
This commit should be backported to stable kernel trees for the
following reasons:
1. **Bug Fix for Hardware Functionality**: The commit fixes a non-
functional internal microphone on the HP Laptop 17 cp-2033dx. This is
a hardware enablement bug fix that prevents users from using a core
functionality of their laptop.
2. **Minimal and Contained Change**: The change is extremely minimal -
it only adds 7 lines to the DMI quirk table:
```c
+ {
+ .driver_data = &acp6x_card,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
+ DMI_MATCH(DMI_BOARD_NAME, "8A81"),
+ }
+ },
```
This is a simple DMI match addition with no algorithmic changes or
side effects.
3. **Low Risk of Regression**: DMI quirk additions are inherently safe
as they only affect the specific hardware model being added. The
change cannot impact any other system that doesn't match the exact
DMI strings.
4. **Follows Established Pattern**: All five similar commits provided as
reference (for HP models with board names 8BD6, 8A3E, 8A22, 8A27, and
other manufacturers) were marked as "Backport Status: YES". This type
of commit has a well-established history of being backported.
5. **User-Impacting Issue**: Without this quirk, users of the HP Laptop
17 cp-2033dx cannot use their internal microphone, which is essential
functionality for video calls, recording, and voice commands. This
significantly degrades the user experience.
6. **Consistent with Stable Tree Rules**: The commit meets the stable
kernel criteria:
- It fixes a real bug that bothers users (non-functional microphone)
- It's obviously correct and tested (standard DMI quirk pattern)
- It's small (7 lines)
- It doesn't add new features, only fixes existing functionality
The AMD Yellow Carp (YC) audio driver uses DMI quirks to enable the
internal microphone on specific laptop models. Without these quirks, the
DMIC (Digital Microphone) won't be properly initialized on affected
systems. This is a common pattern in the Linux kernel for handling
hardware-specific configurations.
sound/soc/amd/yc/acp6x-mach.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/sound/soc/amd/yc/acp6x-mach.c b/sound/soc/amd/yc/acp6x-mach.c
index 1689b6b22598e..42d123cb8b4c6 100644
--- a/sound/soc/amd/yc/acp6x-mach.c
+++ b/sound/soc/amd/yc/acp6x-mach.c
@@ -577,6 +577,13 @@ static const struct dmi_system_id yc_acp_quirk_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "8A7F"),
}
},
+ {
+ .driver_data = &acp6x_card,
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "HP"),
+ DMI_MATCH(DMI_BOARD_NAME, "8A81"),
+ }
+ },
{
.driver_data = &acp6x_card,
.matches = {
--
2.39.5
From: Thomas Zimmermann <tzimmermann(a)suse.de>
[ Upstream commit 5dd0b96118e09a3725e3f83543e133b1fd02c18c ]
The radeon driver holds the console lock while suspending in-kernel
DRM clients. This creates a circular dependency with the client-list
mutex, which is supposed to be acquired first. Reported when combining
radeon with another DRM driver.
Therefore, do not take the console lock in radeon, but let the fbdev
DRM client acquire the lock when needed. This is what all other DRM
drivers so.
Signed-off-by: Thomas Zimmermann <tzimmermann(a)suse.de>
Reported-by: Jeff Johnson <jeff.johnson(a)oss.qualcomm.com>
Closes: https://lore.kernel.org/dri-devel/0a087cfd-bd4c-48f1-aa2f-4a3b12593935@oss.…
Suggested-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com>
(cherry picked from commit 612ec7c69d04cb58beb1332c2806da9f2f47a3ae)
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
LLM Generated explanations, may be completely bogus:
Based on my analysis of the commit and the code changes, here is my
assessment:
**Answer: YES**
This commit should be backported to stable kernel trees. Here's my
extensive explanation:
## 1. **The commit fixes a real circular locking dependency bug**
The commit message clearly states this fixes a "circular dependency with
the client-list mutex" that was "Reported when combining radeon with
another DRM driver." This is a real bug that can lead to deadlocks in
production systems.
## 2. **The fix is minimal and focused**
The code changes are very small and targeted:
- In `radeon_suspend_kms()`: Changed from calling
`drm_client_dev_suspend(dev, true)` with console_lock held to
`drm_client_dev_suspend(dev, false)` without holding the lock
- In `radeon_resume_kms()`: Removed the console_lock/unlock calls around
`drm_client_dev_resume()`
The second parameter to `drm_client_dev_suspend()` indicates whether the
caller holds the console lock. By changing it from `true` to `false`,
radeon now follows the same pattern as other DRM drivers.
## 3. **This aligns radeon with other DRM drivers**
The commit message explicitly states: "This is what all other DRM
drivers so." Looking at the similar commits provided:
- Similar Commit #1 shows radeon being updated to use the new client
suspend/resume infrastructure
- Similar Commit #4 shows amdgpu (the successor to radeon) already using
`drm_client_dev_suspend(dev, false)` without holding the console lock
## 4. **The bug has real-world impact**
The issue was reported by a real user (Jeff Johnson) and occurs "when
combining radeon with another DRM driver." Multi-GPU systems are
increasingly common, especially with integrated + discrete GPU
configurations.
## 5. **Low regression risk**
The change removes lock acquisition rather than adding it, which
generally has lower risk. The fbdev DRM client will acquire the console
lock when needed (as mentioned in the commit message), so the necessary
locking still occurs - just at the correct layer to avoid the circular
dependency.
## 6. **Similar to historical fixes**
Looking at Similar Commit #5 (amdgpu console lock restructuring), we can
see there's a history of console lock ordering issues in AMD GPU drivers
that have been fixed in the past. This suggests these types of fixes are
considered important enough for the maintainers.
## 7. **The fix is already cherry-picked**
The commit message shows "(cherry picked from commit
612ec7c69d04cb58beb1332c2806da9f2f47a3ae)" indicating this was already
selected for backporting by maintainers.
The only potential concern would be ensuring that the DRM client
infrastructure this depends on is present in the stable kernels being
targeted, but given that this is fixing a bug in existing code paths,
the infrastructure must already be there.
drivers/gpu/drm/radeon/radeon_device.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c
index bbd39348a7aba..6f50cfdfe5a2e 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1635,11 +1635,9 @@ int radeon_suspend_kms(struct drm_device *dev, bool suspend,
pci_set_power_state(pdev, PCI_D3hot);
}
- if (notify_clients) {
- console_lock();
- drm_client_dev_suspend(dev, true);
- console_unlock();
- }
+ if (notify_clients)
+ drm_client_dev_suspend(dev, false);
+
return 0;
}
--
2.39.5
Hi,
I wanted to check with you if you had time to go through my previous email.
Let me know your thoughts about acquiring this email list.
Regards,
*Clint*
*____________________________________________________________________________*
Hi,
We have successfully built a verified file of *Healthcare Industry *contacts
with accurate emails. Would you be interested in acquiring* Healthcare
Industry Professionals List* across North America, UK, Europe and Global?
*Few Lists**:* Physicians and Surgeons Lists, Nurses Lists, Hospitals
Lists, Ambulatory Surgery Centers List, Hospitals Executives Decision
Makers list, Home Healthcare Lists, Pharmacy Lists, Clinical
Director/Managers Email List, Facility Manager Lists, Hospital
Administrator Lists, Nurse Manager Lists, Clinical Director Email List,
Laboratory Managers & Directors Email List, General Medical & Surgical
Hospitals Executives Email List, Pharmacy Decision Makers List, NP’s & PA’s
Email list many more.
*Few Physician Specialties**:* Anesthesiologist, Cardiologist,
Dermatologist, Dentist, Emergency Medicine, Family Practitioners,
Gastroenterologist, General Practitioners, Gynecologist, Hospitalist,
Hematologist, Internal Medicine, Nephrologists, Neurologist, Oncologist,
Ophthalmologist, Optometrist, Pathologist, Pediatrician, Psychiatrist,
Psychologist, Plastic Surgeon, Podiatrist, Pulmonologist, Radiologist,
Rheumatologist, Urologist, Physician Assistants, Nurse Practitioners,
Registered Nurses, etc.
*Our list comes with*: Company/Organization, Website, Contacts, Title,
Address, Direct Number and Email Address, Revenue Size, Employee Size,
Industry segment.
Please send me your *target audience and geographical area*, so that I can
give you more information, *Counts and Pricing *for your review.
Looking forward to hearing from you.
Regards,
*Clint Carnell| Customer Success Manager*
*B2B Marketing & Tradeshow Specialist*Clint(a)b2bleadsonline.us
P *We have a responsibility to the environment*
*Before printing this e-mail or any other document, let's ask ourselves
whether we need a hard copy*
From: Haiyang Zhang <haiyangz(a)microsoft.com>
Add init_llist_node for lock-less list nodes in struct net in
setup_net(), so we can test if a node is on a list or not.
Cc: stable(a)vger.kernel.org
Fixes: d6b3358a2813 ("llist: add interface to check if a node is on a list.")
Signed-off-by: Haiyang Zhang <haiyangz(a)microsoft.com>
---
net/core/net_namespace.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index ae54f26709ca..2a821849558f 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -434,6 +434,9 @@ static __net_init int setup_net(struct net *net)
LIST_HEAD(net_exit_list);
int error = 0;
+ init_llist_node(&net->defer_free_list);
+ init_llist_node(&net->cleanup_list);
+
preempt_disable();
net->net_cookie = gen_cookie_next(&net_cookie);
preempt_enable();
--
2.34.1
Delete the external-module style Makefile commands. They are not needed
for in-tree modules.
This is the only Makefile in the kernel tree (aside from tools/ and
samples/) that uses this Makefile style.
The same files are built with or without this patch.
Fixes: 056f2821b631 ("media: cec: extron-da-hd-4k-plus: add the Extron DA HD 4K Plus CEC driver")
Signed-off-by: Randy Dunlap <rdunlap(a)infradead.org>
Cc: stable(a)vger.kernel.org
---
v2 changes, per the Media CI bot:
- add Cc: stable(a)vger.kernel.org
- move other Cc:s to mail headers only, not in the signoff area
Cc: Hans Verkuil <hverkuil(a)kernel.org>
Cc: Masahiro Yamada <masahiroy(a)kernel.org>
drivers/media/cec/usb/extron-da-hd-4k-plus/Makefile | 6 ------
1 file changed, 6 deletions(-)
--- linux-next-20250718.orig/drivers/media/cec/usb/extron-da-hd-4k-plus/Makefile
+++ linux-next-20250718/drivers/media/cec/usb/extron-da-hd-4k-plus/Makefile
@@ -1,8 +1,2 @@
extron-da-hd-4k-plus-cec-objs := extron-da-hd-4k-plus.o cec-splitter.o
obj-$(CONFIG_USB_EXTRON_DA_HD_4K_PLUS_CEC) := extron-da-hd-4k-plus-cec.o
-
-all:
- $(MAKE) -C $(KDIR) M=$(shell pwd) modules
-
-install:
- $(MAKE) -C $(KDIR) M=$(shell pwd) modules_install
The patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x 2521106fc732b0b75fd3555c689b1ed1d29d273c
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072256-verbally-zippy-bbd6@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 2521106fc732b0b75fd3555c689b1ed1d29d273c Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Mon, 23 Jun 2025 16:39:47 +0300
Subject: [PATCH] usb: hub: Don't try to recover devices lost during warm
reset.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hub driver warm-resets ports in SS.Inactive or Compliance mode to
recover a possible connected device. The port reset code correctly
detects if a connection is lost during reset, but hub driver
port_event() fails to take this into account in some cases.
port_event() ends up using stale values and assumes there is a
connected device, and will try all means to recover it, including
power-cycling the port.
Details:
This case was triggered when xHC host was suspended with DbC (Debug
Capability) enabled and connected. DbC turns one xHC port into a simple
usb debug device, allowing debugging a system with an A-to-A USB debug
cable.
xhci DbC code disables DbC when xHC is system suspended to D3, and
enables it back during resume.
We essentially end up with two hosts connected to each other during
suspend, and, for a short while during resume, until DbC is enabled back.
The suspended xHC host notices some activity on the roothub port, but
can't train the link due to being suspended, so xHC hardware sets a CAS
(Cold Attach Status) flag for this port to inform xhci host driver that
the port needs to be warm reset once xHC resumes.
CAS is xHCI specific, and not part of USB specification, so xhci driver
tells usb core that the port has a connection and link is in compliance
mode. Recovery from complinace mode is similar to CAS recovery.
xhci CAS driver support that fakes a compliance mode connection was added
in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS")
Once xHCI resumes and DbC is enabled back, all activity on the xHC
roothub host side port disappears. The hub driver will anyway think
port has a connection and link is in compliance mode, and hub driver
will try to recover it.
The port power-cycle during recovery seems to cause issues to the active
DbC connection.
Fix this by clearing connect_change flag if hub_port_reset() returns
-ENOTCONN, thus avoiding the whole unnecessary port recovery and
initialization attempt.
Cc: stable(a)vger.kernel.org
Fixes: 8bea2bd37df0 ("usb: Add support for root hub port status CAS")
Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250623133947.3144608-1-mathias.nyman@linux.inte…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3e1215f7a9a0..256fe8c86828 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5751,6 +5751,7 @@ static void port_event(struct usb_hub *hub, int port1)
struct usb_device *hdev = hub->hdev;
u16 portstatus, portchange;
int i = 0;
+ int err;
connect_change = test_bit(port1, hub->change_bits);
clear_bit(port1, hub->event_bits);
@@ -5847,8 +5848,11 @@ static void port_event(struct usb_hub *hub, int port1)
} else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
|| udev->state == USB_STATE_NOTATTACHED) {
dev_dbg(&port_dev->dev, "do warm reset, port only\n");
- if (hub_port_reset(hub, port1, NULL,
- HUB_BH_RESET_TIME, true) < 0)
+ err = hub_port_reset(hub, port1, NULL,
+ HUB_BH_RESET_TIME, true);
+ if (!udev && err == -ENOTCONN)
+ connect_change = 0;
+ else if (err < 0)
hub_port_disable(hub, port1, 1);
} else {
dev_dbg(&port_dev->dev, "do warm reset, full device\n");
The patch below does not apply to the 5.4-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.4.y
git checkout FETCH_HEAD
git cherry-pick -x 2521106fc732b0b75fd3555c689b1ed1d29d273c
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072258-fervor-reabsorb-1b7a@gregkh' --subject-prefix 'PATCH 5.4.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 2521106fc732b0b75fd3555c689b1ed1d29d273c Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Mon, 23 Jun 2025 16:39:47 +0300
Subject: [PATCH] usb: hub: Don't try to recover devices lost during warm
reset.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hub driver warm-resets ports in SS.Inactive or Compliance mode to
recover a possible connected device. The port reset code correctly
detects if a connection is lost during reset, but hub driver
port_event() fails to take this into account in some cases.
port_event() ends up using stale values and assumes there is a
connected device, and will try all means to recover it, including
power-cycling the port.
Details:
This case was triggered when xHC host was suspended with DbC (Debug
Capability) enabled and connected. DbC turns one xHC port into a simple
usb debug device, allowing debugging a system with an A-to-A USB debug
cable.
xhci DbC code disables DbC when xHC is system suspended to D3, and
enables it back during resume.
We essentially end up with two hosts connected to each other during
suspend, and, for a short while during resume, until DbC is enabled back.
The suspended xHC host notices some activity on the roothub port, but
can't train the link due to being suspended, so xHC hardware sets a CAS
(Cold Attach Status) flag for this port to inform xhci host driver that
the port needs to be warm reset once xHC resumes.
CAS is xHCI specific, and not part of USB specification, so xhci driver
tells usb core that the port has a connection and link is in compliance
mode. Recovery from complinace mode is similar to CAS recovery.
xhci CAS driver support that fakes a compliance mode connection was added
in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS")
Once xHCI resumes and DbC is enabled back, all activity on the xHC
roothub host side port disappears. The hub driver will anyway think
port has a connection and link is in compliance mode, and hub driver
will try to recover it.
The port power-cycle during recovery seems to cause issues to the active
DbC connection.
Fix this by clearing connect_change flag if hub_port_reset() returns
-ENOTCONN, thus avoiding the whole unnecessary port recovery and
initialization attempt.
Cc: stable(a)vger.kernel.org
Fixes: 8bea2bd37df0 ("usb: Add support for root hub port status CAS")
Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250623133947.3144608-1-mathias.nyman@linux.inte…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3e1215f7a9a0..256fe8c86828 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5751,6 +5751,7 @@ static void port_event(struct usb_hub *hub, int port1)
struct usb_device *hdev = hub->hdev;
u16 portstatus, portchange;
int i = 0;
+ int err;
connect_change = test_bit(port1, hub->change_bits);
clear_bit(port1, hub->event_bits);
@@ -5847,8 +5848,11 @@ static void port_event(struct usb_hub *hub, int port1)
} else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
|| udev->state == USB_STATE_NOTATTACHED) {
dev_dbg(&port_dev->dev, "do warm reset, port only\n");
- if (hub_port_reset(hub, port1, NULL,
- HUB_BH_RESET_TIME, true) < 0)
+ err = hub_port_reset(hub, port1, NULL,
+ HUB_BH_RESET_TIME, true);
+ if (!udev && err == -ENOTCONN)
+ connect_change = 0;
+ else if (err < 0)
hub_port_disable(hub, port1, 1);
} else {
dev_dbg(&port_dev->dev, "do warm reset, full device\n");
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.10.y
git checkout FETCH_HEAD
git cherry-pick -x 2521106fc732b0b75fd3555c689b1ed1d29d273c
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2025072257-ranging-salvaging-2f13@gregkh' --subject-prefix 'PATCH 5.10.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 2521106fc732b0b75fd3555c689b1ed1d29d273c Mon Sep 17 00:00:00 2001
From: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Date: Mon, 23 Jun 2025 16:39:47 +0300
Subject: [PATCH] usb: hub: Don't try to recover devices lost during warm
reset.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Hub driver warm-resets ports in SS.Inactive or Compliance mode to
recover a possible connected device. The port reset code correctly
detects if a connection is lost during reset, but hub driver
port_event() fails to take this into account in some cases.
port_event() ends up using stale values and assumes there is a
connected device, and will try all means to recover it, including
power-cycling the port.
Details:
This case was triggered when xHC host was suspended with DbC (Debug
Capability) enabled and connected. DbC turns one xHC port into a simple
usb debug device, allowing debugging a system with an A-to-A USB debug
cable.
xhci DbC code disables DbC when xHC is system suspended to D3, and
enables it back during resume.
We essentially end up with two hosts connected to each other during
suspend, and, for a short while during resume, until DbC is enabled back.
The suspended xHC host notices some activity on the roothub port, but
can't train the link due to being suspended, so xHC hardware sets a CAS
(Cold Attach Status) flag for this port to inform xhci host driver that
the port needs to be warm reset once xHC resumes.
CAS is xHCI specific, and not part of USB specification, so xhci driver
tells usb core that the port has a connection and link is in compliance
mode. Recovery from complinace mode is similar to CAS recovery.
xhci CAS driver support that fakes a compliance mode connection was added
in commit 8bea2bd37df0 ("usb: Add support for root hub port status CAS")
Once xHCI resumes and DbC is enabled back, all activity on the xHC
roothub host side port disappears. The hub driver will anyway think
port has a connection and link is in compliance mode, and hub driver
will try to recover it.
The port power-cycle during recovery seems to cause issues to the active
DbC connection.
Fix this by clearing connect_change flag if hub_port_reset() returns
-ENOTCONN, thus avoiding the whole unnecessary port recovery and
initialization attempt.
Cc: stable(a)vger.kernel.org
Fixes: 8bea2bd37df0 ("usb: Add support for root hub port status CAS")
Tested-by: Łukasz Bartosik <ukaszb(a)chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman(a)linux.intel.com>
Acked-by: Alan Stern <stern(a)rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250623133947.3144608-1-mathias.nyman@linux.inte…
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 3e1215f7a9a0..256fe8c86828 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -5751,6 +5751,7 @@ static void port_event(struct usb_hub *hub, int port1)
struct usb_device *hdev = hub->hdev;
u16 portstatus, portchange;
int i = 0;
+ int err;
connect_change = test_bit(port1, hub->change_bits);
clear_bit(port1, hub->event_bits);
@@ -5847,8 +5848,11 @@ static void port_event(struct usb_hub *hub, int port1)
} else if (!udev || !(portstatus & USB_PORT_STAT_CONNECTION)
|| udev->state == USB_STATE_NOTATTACHED) {
dev_dbg(&port_dev->dev, "do warm reset, port only\n");
- if (hub_port_reset(hub, port1, NULL,
- HUB_BH_RESET_TIME, true) < 0)
+ err = hub_port_reset(hub, port1, NULL,
+ HUB_BH_RESET_TIME, true);
+ if (!udev && err == -ENOTCONN)
+ connect_change = 0;
+ else if (err < 0)
hub_port_disable(hub, port1, 1);
} else {
dev_dbg(&port_dev->dev, "do warm reset, full device\n");