[PATCH AUTOSEL 6.17-6.12] usb: xhci-pci: add support for hosts with zero USB3 ports

[PATCH AUTOSEL 6.17-6.12] usb: xhci-pci: add support for hosts with zero USB3 ports

[Sasha Levin]

From: Niklas Neronin <niklas.neronin@linux.intel.com>

[ Upstream commit 719de070f764e079cdcb4ddeeb5b19b3ddddf9c1 ]

Add xhci support for PCI hosts that have zero USB3 ports.
Avoid creating a shared Host Controller Driver (HCD) when there is only
one root hub. Additionally, all references to 'xhci->shared_hcd' are now
checked before use.

Only xhci-pci.c requires modification to accommodate this change, as the
xhci core already supports configurations with zero USB3 ports. This
capability was introduced when xHCI Platform and MediaTek added support
for zero USB3 ports.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220181
Tested-by: Nick Nielsen <nick.kainielsen@free.fr>
Tested-by: grm1 <grm1@mailbox.org>
Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20250917210726.97100-4-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES — this change is a focused bugfix that lets PCI xHCI controllers
with only a single root hub enumerate correctly, matching support
already present in the core and other host adapters.

- `drivers/usb/host/xhci-pci.c:640` now sets `xhci->allow_single_roothub
  = 1`, allowing the existing `xhci_has_one_roothub()` helper to
  recognize hosts that genuinely provide only USB2 or only USB3 ports.
  For such hardware the new branch at `drivers/usb/host/xhci-
  pci.c:641-659` skips creating the secondary HCD and still runs
  `xhci_ext_cap_init()`, preventing the allocation/registration of a
  useless SuperSpeed root hub that currently causes probe failures on
  the systems reported in bug 220181.
- Stream capability handling switches to `xhci_get_usb3_hcd()` at
  `drivers/usb/host/xhci-pci.c:662-664`, so the code safely handles both
  the traditional dual-root-hub case and the new single-root-hub case
  without dereferencing a NULL `shared_hcd`.
- The xHCI core has supported “single-roothub” controllers since commit
  873f323618c2 (see the helper definitions in
  `drivers/usb/host/xhci.h:1659-1737`), and platform drivers already
  rely on the same pattern (`drivers/usb/host/xhci-plat.c:207` and
  `drivers/usb/host/xhci-mtk.c:629-655`). This patch simply brings the
  PCI glue in line with that infrastructure, so it has no architectural
  side effects.
- Scope is limited to the PCI front-end; it doesn’t alter shared data
  structures or other subsystems. Tested-by tags and the fact that the
  alternative drivers have run this logic for multiple release cycles
  further reduce regression risk. Backporters only need to ensure the
  target stable branch already contains the earlier
  “allow_single_roothub” support (present in 6.1+). If that prerequisite
  is met, the change is small, self-contained, and fixes real hardware
  breakage.

Natural next steps: 1) cherry-pick (plus prerequisite check) into the
relevant stable trees; 2) rerun basic USB enumeration on affected
hardware to confirm the controller now probes successfully.

 drivers/usb/host/xhci-pci.c | 42 +++++++++++++++++++++----------------
 1 file changed, 24 insertions(+), 18 deletions(-)

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 00fac8b233d2a..5c8ab519f497d 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -610,7 +610,7 @@ int xhci_pci_common_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
 	int retval;
 	struct xhci_hcd *xhci;
-	struct usb_hcd *hcd;
+	struct usb_hcd *hcd, *usb3_hcd;
 	struct reset_control *reset;
 
 	reset = devm_reset_control_get_optional_exclusive(&dev->dev, NULL);
@@ -636,26 +636,32 @@ int xhci_pci_common_probe(struct pci_dev *dev, const struct pci_device_id *id)
 	hcd = dev_get_drvdata(&dev->dev);
 	xhci = hcd_to_xhci(hcd);
 	xhci->reset = reset;
-	xhci->shared_hcd = usb_create_shared_hcd(&xhci_pci_hc_driver, &dev->dev,
-						 pci_name(dev), hcd);
-	if (!xhci->shared_hcd) {
-		retval = -ENOMEM;
-		goto dealloc_usb2_hcd;
-	}
 
-	retval = xhci_ext_cap_init(xhci);
-	if (retval)
-		goto put_usb3_hcd;
+	xhci->allow_single_roothub = 1;
+	if (!xhci_has_one_roothub(xhci)) {
+		xhci->shared_hcd = usb_create_shared_hcd(&xhci_pci_hc_driver, &dev->dev,
+							 pci_name(dev), hcd);
+		if (!xhci->shared_hcd) {
+			retval = -ENOMEM;
+			goto dealloc_usb2_hcd;
+		}
 
-	retval = usb_add_hcd(xhci->shared_hcd, dev->irq,
-			IRQF_SHARED);
-	if (retval)
-		goto put_usb3_hcd;
-	/* Roothub already marked as USB 3.0 speed */
+		retval = xhci_ext_cap_init(xhci);
+		if (retval)
+			goto put_usb3_hcd;
+
+		retval = usb_add_hcd(xhci->shared_hcd, dev->irq, IRQF_SHARED);
+		if (retval)
+			goto put_usb3_hcd;
+	} else {
+		retval = xhci_ext_cap_init(xhci);
+		if (retval)
+			goto dealloc_usb2_hcd;
+	}
 
-	if (!(xhci->quirks & XHCI_BROKEN_STREAMS) &&
-			HCC_MAX_PSA(xhci->hcc_params) >= 4)
-		xhci->shared_hcd->can_do_streams = 1;
+	usb3_hcd = xhci_get_usb3_hcd(xhci);
+	if (usb3_hcd && !(xhci->quirks & XHCI_BROKEN_STREAMS) && HCC_MAX_PSA(xhci->hcc_params) >= 4)
+		usb3_hcd->can_do_streams = 1;
 
 	/* USB-2 and USB-3 roothubs initialized, allow runtime pm suspend */
 	pm_runtime_put_noidle(&dev->dev);
-- 
2.51.0

Re: [PATCH AUTOSEL 6.17-6.12] usb: xhci-pci: add support for hosts with zero USB3 ports

[Michal Pecio]

On Sat, 25 Oct 2025 11:54:27 -0400, Sasha Levin wrote:
> From: Niklas Neronin <niklas.neronin@linux.intel.com>
> 
> [ Upstream commit 719de070f764e079cdcb4ddeeb5b19b3ddddf9c1 ]
> 
> Add xhci support for PCI hosts that have zero USB3 ports.
> Avoid creating a shared Host Controller Driver (HCD) when there is only
> one root hub. Additionally, all references to 'xhci->shared_hcd' are now
> checked before use.
> 
> Only xhci-pci.c requires modification to accommodate this change, as the
> xhci core already supports configurations with zero USB3 ports. This
> capability was introduced when xHCI Platform and MediaTek added support
> for zero USB3 ports.
> 
> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220181
> Tested-by: Nick Nielsen <nick.kainielsen@free.fr>
> Tested-by: grm1 <grm1@mailbox.org>
> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
> Link: https://lore.kernel.org/r/20250917210726.97100-4-mathias.nyman@linux.intel.com
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> ---

Hi Sasha,

This is completely broken, fix is pending in Greg's usb-linus branch.
(Which is something autosel could perhaps check itself...)

8607edcd1748 usb: xhci-pci: Fix USB2-only root hub registration

Michal

Re: [PATCH AUTOSEL 6.17-6.12] usb: xhci-pci: add support for hosts with zero USB3 ports

[Sasha Levin]

On Sat, Oct 25, 2025 at 06:47:40PM +0200, Michal Pecio wrote:
>On Sat, 25 Oct 2025 11:54:27 -0400, Sasha Levin wrote:
>> From: Niklas Neronin <niklas.neronin@linux.intel.com>
>>
>> [ Upstream commit 719de070f764e079cdcb4ddeeb5b19b3ddddf9c1 ]
>>
>> Add xhci support for PCI hosts that have zero USB3 ports.
>> Avoid creating a shared Host Controller Driver (HCD) when there is only
>> one root hub. Additionally, all references to 'xhci->shared_hcd' are now
>> checked before use.
>>
>> Only xhci-pci.c requires modification to accommodate this change, as the
>> xhci core already supports configurations with zero USB3 ports. This
>> capability was introduced when xHCI Platform and MediaTek added support
>> for zero USB3 ports.
>>
>> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220181
>> Tested-by: Nick Nielsen <nick.kainielsen@free.fr>
>> Tested-by: grm1 <grm1@mailbox.org>
>> Signed-off-by: Niklas Neronin <niklas.neronin@linux.intel.com>
>> Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
>> Link: https://lore.kernel.org/r/20250917210726.97100-4-mathias.nyman@linux.intel.com
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Signed-off-by: Sasha Levin <sashal@kernel.org>
>> ---
>
>Hi Sasha,
>
>This is completely broken, fix is pending in Greg's usb-linus branch.
>(Which is something autosel could perhaps check itself...)
>
>8607edcd1748 usb: xhci-pci: Fix USB2-only root hub registration

I'll add the fix on top, thanks!

-- 
Thanks,
Sasha

[PATCH AUTOSEL 6.17-6.12] HID: pidff: PERMISSIVE_CONTROL quirk autodetection

[Sasha Levin]

From: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>

[ Upstream commit c2dc9f0b368c08c34674311cf78407718d5715a7 ]

Fixes force feedback for devices built with MMOS firmware and many more
not yet detected devices.

Update quirks mask debug message to always contain all 32 bits of data.

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES

Why this is a good stable backport
- Fixes real user-visible breakage: enables force feedback on devices
  with MMOS firmware and other devices misreporting PID_DEVICE_CONTROL’s
  logical_minimum (previously failed to initialize FF).
- Small, contained change in HID PID FF driver; no architectural changes
  or cross‑subsystem impacts.
- Risk is low: the new behavior only relaxes a check if the strict path
  fails, and only for the specific Device Control field; otherwise
  behavior remains identical.
- Improves diagnostics (full 32‑bit quirks mask) without functional side
  effects.
- Aligns with stable rules: important bugfix, minimal risk, confined to
  HID/PIDFF.

What changes, concretely
- Autodetect and set PERMISSIVE_CONTROL only when needed:
  - Before: Device Control lookup was strict unless the quirk was pre-
    specified (e.g., via device ID). If logical_minimum != 1, driver
    failed with “device control field not found”.
  - After: Try strict lookup first; if not found, set
    `HID_PIDFF_QUIRK_PERMISSIVE_CONTROL` and retry without enforcing
    min==1. This allows devices with non‑conforming descriptors to work
    without hardcoding IDs.
- Debug formatting improvement: print all 32 bits of the quirks mask.

Relevant code references (current tree)
- Device Control lookup currently enforces min==1 unless the quirk is
  already set:
  - drivers/hid/usbhid/hid-pidff.c:1135
    - `pidff->device_control = pidff_find_special_field(...,
      PID_DEVICE_CONTROL_ARRAY, !(pidff->quirks &
      HID_PIDFF_QUIRK_PERMISSIVE_CONTROL));`
  - The change will:
    - First call with `enforce_min=1`, then if null:
      - `pr_debug("Setting PERMISSIVE_CONTROL quirk");`
      - `pidff->quirks |= HID_PIDFF_QUIRK_PERMISSIVE_CONTROL;`
      - Retry with `enforce_min=0`.
  - Safety: If the usage isn’t present at all, the second lookup still
    returns NULL and the function returns error exactly as before.
- Quirk definition already exists:
  - drivers/hid/usbhid/hid-pidff.h:16
    - `#define HID_PIDFF_QUIRK_PERMISSIVE_CONTROL BIT(2)`
- Quirks debug formatting to widen to 8 hex digits:
  - drivers/hid/usbhid/hid-pidff.c:1477
    - Currently: `hid_dbg(dev, "Active quirks mask: 0x%x\n",
      pidff->quirks);`
    - Change to: `0x%08x` (formatting only, no logic impact).

Compatibility and dependencies
- Depends on the existing quirk bit and infrastructure (already present
  since “HID: pidff: Add PERMISSIVE_CONTROL quirk”; this is in-tree with
  Signed-off-by: Sasha Levin, so it has been flowing into stable).
- Interacts safely with the more recent fix to Device Control handling:
  - “HID: pidff: Fix set_device_control()” ensures correct 1‑based
    indexing and guards against missing fields; the autodetection does
    not invalidate those fixes.

Regression risk assessment
- Previously working devices (strict path succeeds) are unchanged.
- Previously non-working devices (strict path fails) now work via a
  guarded fallback; without the usage present, behavior remains
  identical (fail).
- The quirk only changes acceptance of the Device Control field; no
  other code paths are altered.

Conclusion
- This is a targeted, low-risk fix that unlocks FF functionality for a
  notable set of devices without broad side effects. It’s well-suited
  for backporting to stable trees that already carry the
  PERMISSIVE_CONTROL quirk.

 drivers/hid/usbhid/hid-pidff.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
index c6b4f61e535d5..711eefff853bb 100644
--- a/drivers/hid/usbhid/hid-pidff.c
+++ b/drivers/hid/usbhid/hid-pidff.c
@@ -1151,8 +1151,16 @@ static int pidff_find_special_fields(struct pidff_device *pidff)
 					 PID_DIRECTION, 0);
 	pidff->device_control =
 		pidff_find_special_field(pidff->reports[PID_DEVICE_CONTROL],
-			PID_DEVICE_CONTROL_ARRAY,
-			!(pidff->quirks & HID_PIDFF_QUIRK_PERMISSIVE_CONTROL));
+			PID_DEVICE_CONTROL_ARRAY, 1);
+
+	/* Detect and set permissive control quirk */
+	if (!pidff->device_control) {
+		pr_debug("Setting PERMISSIVE_CONTROL quirk\n");
+		pidff->quirks |= HID_PIDFF_QUIRK_PERMISSIVE_CONTROL;
+		pidff->device_control = pidff_find_special_field(
+			pidff->reports[PID_DEVICE_CONTROL],
+			PID_DEVICE_CONTROL_ARRAY, 0);
+	}
 
 	pidff->block_load_status =
 		pidff_find_special_field(pidff->reports[PID_BLOCK_LOAD],
@@ -1492,7 +1500,7 @@ int hid_pidff_init_with_quirks(struct hid_device *hid, u32 initial_quirks)
 	ff->playback = pidff_playback;
 
 	hid_info(dev, "Force feedback for USB HID PID devices by Anssi Hannula <anssi.hannula@gmail.com>\n");
-	hid_dbg(dev, "Active quirks mask: 0x%x\n", pidff->quirks);
+	hid_dbg(dev, "Active quirks mask: 0x%08x\n", pidff->quirks);
 
 	hid_device_io_stop(hid);
 
-- 
2.51.0

[PATCH AUTOSEL 6.17-5.15] usb: cdns3: gadget: Use-after-free during failed initialization and exit of cdnsp gadget

[Sasha Levin]

From: Chen Yufeng <chenyufeng@iie.ac.cn>

[ Upstream commit 87c5ff5615dc0a37167e8faf3adeeddc6f1344a3 ]

In the __cdnsp_gadget_init() and cdnsp_gadget_exit() functions, the gadget
structure (pdev->gadget) was freed before its endpoints.
The endpoints are linked via the ep_list in the gadget structure.
Freeing the gadget first leaves dangling pointers in the endpoint list.
When the endpoints are subsequently freed, this results in a use-after-free.

Fix:
By separating the usb_del_gadget_udc() operation into distinct "del" and
"put" steps, cdnsp_gadget_free_endpoints() can be executed prior to the
final release of the gadget structure with usb_put_gadget().

A patch similar to bb9c74a5bd14("usb: dwc3: gadget: Free gadget structure
 only after freeing endpoints").

Signed-off-by: Chen Yufeng <chenyufeng@iie.ac.cn>
Link: https://lore.kernel.org/r/20250905094842.1232-1-chenyufeng@iie.ac.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES

- Fixes a real bug (use-after-free) that can crash or corrupt memory
  during error paths and driver removal, affecting users of the Cadence
  cdnsp gadget driver.
- Root cause: endpoints are linked via `gadget.ep_list`, so freeing the
  gadget before removing endpoints leaves dangling list pointers.
  `cdnsp_gadget_free_endpoints()` manipulates `pdev->gadget.ep_list`; if
  the gadget is already freed, this is a UAF.
  - Endpoint teardown iterates and removes from the gadget’s endpoint
    list: `drivers/usb/cdns3/cdnsp-gadget.c:1725`.
- Precise failure points addressed:
  - In `__cdnsp_gadget_init()`, if `devm_request_threaded_irq()` fails,
    the old path did `usb_del_gadget_udc()` and then
    `cdnsp_gadget_free_endpoints()`, risking UAF. The patch splits the
    del/put so endpoints are freed while the gadget is still alive:
    - Function start: `drivers/usb/cdns3/cdnsp-gadget.c:1900`
    - UDC registration: `drivers/usb/cdns3/cdnsp-gadget.c:1963`
    - New error path ordering: `del_gadget:` →
      `usb_del_gadget(&pdev->gadget);` →
      `cdnsp_gadget_free_endpoints(pdev);` →
      `usb_put_gadget(&pdev->gadget);` → `goto halt_pdev;` at
      `drivers/usb/cdns3/cdnsp-gadget.c:1978`
  - In `cdnsp_gadget_exit()`, the old sequence similarly freed the
    gadget before endpoints. The patch changes it to:
    - Function start: `drivers/usb/cdns3/cdnsp-gadget.c:1997`
    - New order: `usb_del_gadget(&pdev->gadget);` →
      `cdnsp_gadget_free_endpoints(pdev);` →
      `usb_put_gadget(&pdev->gadget);` at `drivers/usb/cdns3/cdnsp-
      gadget.c:2001` and `:2005`.
- The change is minimal, localized, and follows established core UDC API
  semantics:
  - `usb_del_gadget_udc()` is literally `usb_del_gadget()` +
    `usb_put_gadget()` (so splitting is functionally correct and
    intended): `drivers/usb/gadget/udc/core.c:1560`.
  - `usb_del_gadget()` unregisters the gadget without final put:
    `drivers/usb/gadget/udc/core.c:1531`.
  - `usb_put_gadget()` is the final put (inline):
    `include/linux/usb/gadget.h:500`.
- The fix mirrors the proven pattern already used by other gadget
  drivers (e.g., DWC3): `usb_del_gadget();` → free endpoints →
  `usb_put_gadget();` in `drivers/usb/dwc3/gadget.c:4816`.
- No architectural changes, no new features, and no ABI impacts. It only
  touches cdnsp gadget teardown and error paths.
- Regression risk is low:
  - Releases UDC before endpoint list manipulation (prevents new
    activity), but keeps the gadget object alive until endpoints are
    freed.
  - Adds `goto halt_pdev` from the `del_gadget` path to avoid double-
    freeing endpoints; other error paths remain balanced and consistent.
- Security/stability relevance: UAFs are both reliability and potential
  security issues; fixing them is strongly aligned with stable policy.

Given the clear bugfix nature, small and contained changes, and
alignment with core and peer driver patterns, this is a strong candidate
for backporting to all stable trees that contain the cdnsp gadget
driver.

 drivers/usb/cdns3/cdnsp-gadget.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/cdns3/cdnsp-gadget.c b/drivers/usb/cdns3/cdnsp-gadget.c
index 55f95f41b3b4d..0252560cbc80b 100644
--- a/drivers/usb/cdns3/cdnsp-gadget.c
+++ b/drivers/usb/cdns3/cdnsp-gadget.c
@@ -1976,7 +1976,10 @@ static int __cdnsp_gadget_init(struct cdns *cdns)
 	return 0;
 
 del_gadget:
-	usb_del_gadget_udc(&pdev->gadget);
+	usb_del_gadget(&pdev->gadget);
+	cdnsp_gadget_free_endpoints(pdev);
+	usb_put_gadget(&pdev->gadget);
+	goto halt_pdev;
 free_endpoints:
 	cdnsp_gadget_free_endpoints(pdev);
 halt_pdev:
@@ -1998,8 +2001,9 @@ static void cdnsp_gadget_exit(struct cdns *cdns)
 	devm_free_irq(pdev->dev, cdns->dev_irq, pdev);
 	pm_runtime_mark_last_busy(cdns->dev);
 	pm_runtime_put_autosuspend(cdns->dev);
-	usb_del_gadget_udc(&pdev->gadget);
+	usb_del_gadget(&pdev->gadget);
 	cdnsp_gadget_free_endpoints(pdev);
+	usb_put_gadget(&pdev->gadget);
 	cdnsp_mem_cleanup(pdev);
 	kfree(pdev);
 	cdns->gadget_dev = NULL;
-- 
2.51.0

[PATCH AUTOSEL 6.17-6.12] HID: pidff: Use direction fix only for conditional effects

[Sasha Levin]

From: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>

[ Upstream commit f345a4798dab800159b09d088e7bdae0f16076c3 ]

The already fixed bug in SDL only affected conditional effects. This
should fix FFB in Forza Horizion 4/5 on Moza Devices as Forza Horizon
flips the constant force direction instead of using negative magnitude
values.

Changing the direction in the effect directly in pidff_upload_effect()
would affect it's value in further operations like comparing to the old
effect and/or just reading the effect values in the user application.

This, in turn, would lead to constant PID_SET_EFFECT spam as the effect
direction would constantly not match the value that's set by the
application.

This way, it's still transparent to any software/API.

Only affects conditional effects now so it's better for it to explicitly
state that in the name. If any HW ever needs fixed direction for other
effects, we'll add more quirks.

Signed-off-by: Tomasz Pakuła <tomasz.pakula.oficjalny@gmail.com>
Reviewed-by: Oleg Makarenko <oleg@makarenk.ooo>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES

- What it fixes
  - The earlier quirk forced a fixed direction (0x4000) for all effect
    types on specific wheelbases to work around mis-set PID directions
    in some user stacks (dinput → wine → SDL). That broad forcing breaks
    games that legitimately use the direction field for non-conditional
    effects (e.g., Forza Horizon 4/5 uses direction flips for constant
    force instead of negative magnitudes). This patch narrows the quirk
    to conditional effects only (spring, damper, inertia, friction),
    matching where the SDL-side bug actually applied.

- How it changes behavior
  - Adds a helper to detect conditional effects and a wrapper to set the
    direction only when appropriate:
    - New logic: pidff_is_effect_conditional() and
      pidff_set_effect_direction() in drivers/hid/usbhid/hid-pidff.c
      (replaces unconditional forcing in Set Effect).
    - Set Effect now calls the helper instead of unconditionally forcing
      direction for all effects.
  - Renames the quirk to reflect scope:
    HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION →
    HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION, still using the same bit
    (BIT(3)).
  - Updates device ID table entries to use the new quirk name for Moza
    devices in drivers/hid/hid-universal-pidff.c.

- Why it’s appropriate for stable
  - User-visible bug/regression: Fixes incorrect or missing FFB in Forza
    Horizon 4/5 on Moza devices when the kernel overrode constant-force
    directions. The message explicitly states this resolves that case.
  - Small and contained: Limited to HID PID force-feedback code and
    quirk tables; no architectural changes.
  - Minimal risk: Only affects devices already marked with the quirk
    bit. Behavior is narrowed (less intrusive) by applying the fixed
    direction only to conditional effects; other effect types now honor
    the application-provided direction as intended.
  - No side effects on unrelated subsystems: Touches only HID FFB code
    paths.
  - Clear lineage: It logically corrects the earlier
    “FIX_WHEEL_DIRECTION” quirk (drivers/hid/usbhid/hid-pidff.c:397)
    that forced direction for all effect types.

- Specific code references
  - Current unconditional forcing (to be replaced by helper call):
    drivers/hid/usbhid/hid-pidff.c:397
  - Quirk bit definition that’s renamed but remains BIT(3):
    drivers/hid/usbhid/hid-pidff.h:20
  - Fixed direction constant (still used, but now applied
    conditionally): drivers/hid/usbhid/hid-pidff.c:151
  - Device entries using the quirk (updated to new name):
    drivers/hid/hid-universal-pidff.c:6

- Additional considerations
  - The commit avoids mutating effect->direction in
    pidff_upload_effect(), preventing mismatches with the application’s
    state and avoiding needless PID_SET_EFFECT churn. It keeps behavior
    transparent to user space.
  - If any future hardware requires fixed direction for non-conditional
    effects, the commit message notes that more targeted quirks will be
    added, which further limits regression risk.

Given it’s a targeted regression fix for a real-world breakage, small in
scope, and reduces the quirk’s blast radius, it’s a strong candidate for
stable backport (especially on branches that already carry the earlier
FIX_WHEEL_DIRECTION quirk).

 drivers/hid/hid-universal-pidff.c | 20 ++++++++++----------
 drivers/hid/usbhid/hid-pidff.c    | 28 +++++++++++++++++++++++-----
 drivers/hid/usbhid/hid-pidff.h    |  2 +-
 3 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/drivers/hid/hid-universal-pidff.c b/drivers/hid/hid-universal-pidff.c
index 554a6559aeb73..70fce0f88e825 100644
--- a/drivers/hid/hid-universal-pidff.c
+++ b/drivers/hid/hid-universal-pidff.c
@@ -144,25 +144,25 @@ static int universal_pidff_input_configured(struct hid_device *hdev,
 
 static const struct hid_device_id universal_pidff_devices[] = {
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R3),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R3_2),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R5),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R5_2),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R9),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R9_2),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R12),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R12_2),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R16_R21),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_MOZA, USB_DEVICE_ID_MOZA_R16_R21_2),
-		.driver_data = HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION },
+		.driver_data = HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CAMMUS, USB_DEVICE_ID_CAMMUS_C5) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_CAMMUS, USB_DEVICE_ID_CAMMUS_C12) },
 	{ HID_USB_DEVICE(USB_VENDOR_ID_VRS, USB_DEVICE_ID_VRS_DFP),
diff --git a/drivers/hid/usbhid/hid-pidff.c b/drivers/hid/usbhid/hid-pidff.c
index 614a20b620231..c6b4f61e535d5 100644
--- a/drivers/hid/usbhid/hid-pidff.c
+++ b/drivers/hid/usbhid/hid-pidff.c
@@ -205,6 +205,14 @@ struct pidff_device {
 	u8 effect_count;
 };
 
+static int pidff_is_effect_conditional(struct ff_effect *effect)
+{
+	return effect->type == FF_SPRING  ||
+	       effect->type == FF_DAMPER  ||
+	       effect->type == FF_INERTIA ||
+	       effect->type == FF_FRICTION;
+}
+
 /*
  * Clamp value for a given field
  */
@@ -294,6 +302,20 @@ static void pidff_set_duration(struct pidff_usage *usage, u16 duration)
 	pidff_set_time(usage, duration);
 }
 
+static void pidff_set_effect_direction(struct pidff_device *pidff,
+				       struct ff_effect *effect)
+{
+	u16 direction = effect->direction;
+
+	/* Use fixed direction if needed */
+	if (pidff->quirks & HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION &&
+	    pidff_is_effect_conditional(effect))
+		direction = PIDFF_FIXED_WHEEL_DIRECTION;
+
+	pidff->effect_direction->value[0] =
+		pidff_rescale(direction, U16_MAX, pidff->effect_direction);
+}
+
 /*
  * Send envelope report to the device
  */
@@ -395,11 +417,7 @@ static void pidff_set_effect_report(struct pidff_device *pidff,
 		pidff->set_effect[PID_GAIN].field->logical_maximum;
 	pidff->set_effect[PID_DIRECTION_ENABLE].value[0] = 1;
 
-	/* Use fixed direction if needed */
-	pidff->effect_direction->value[0] = pidff_rescale(
-		pidff->quirks & HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION ?
-		PIDFF_FIXED_WHEEL_DIRECTION : effect->direction,
-		U16_MAX, pidff->effect_direction);
+	pidff_set_effect_direction(pidff, effect);
 
 	/* Omit setting delay field if it's missing */
 	if (!(pidff->quirks & HID_PIDFF_QUIRK_MISSING_DELAY))
diff --git a/drivers/hid/usbhid/hid-pidff.h b/drivers/hid/usbhid/hid-pidff.h
index a53a8b436baa6..f321f675e1318 100644
--- a/drivers/hid/usbhid/hid-pidff.h
+++ b/drivers/hid/usbhid/hid-pidff.h
@@ -16,7 +16,7 @@
 #define HID_PIDFF_QUIRK_PERMISSIVE_CONTROL	BIT(2)
 
 /* Use fixed 0x4000 direction during SET_EFFECT report upload */
-#define HID_PIDFF_QUIRK_FIX_WHEEL_DIRECTION	BIT(3)
+#define HID_PIDFF_QUIRK_FIX_CONDITIONAL_DIRECTION	BIT(3)
 
 /* Force all periodic effects to be uploaded as SINE */
 #define HID_PIDFF_QUIRK_PERIODIC_SINE_ONLY	BIT(4)
-- 
2.51.0

[PATCH AUTOSEL 6.17-5.4] usb: xhci: plat: Facilitate using autosuspend for xhci plat devices

[Sasha Levin]

From: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>

[ Upstream commit 41cf11946b9076383a2222bbf1ef57d64d033f66 ]

Allow autosuspend to be used by xhci plat device. For Qualcomm SoCs,
when in host mode, it is intended that the controller goes to suspend
state to save power and wait for interrupts from connected peripheral
to wake it up. This is particularly used in cases where a HID or Audio
device is connected. In such scenarios, the usb controller can enter
auto suspend and resume action after getting interrupts from the
connected device.

Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250916120436.3617598-1-krishna.kurapati@oss.qualcomm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES. Adding `pm_runtime_use_autosuspend(&pdev->dev);` in
`xhci_plat_probe()` (`drivers/usb/host/xhci-plat.c:185`) finally lets
platform xHCI hosts honour runtime PM autosuspend, so boards that set
`power/control=auto` (such as the Qualcomm configurations called out in
the commit message) can actually drop the controller into low-power idle
instead of burning power indefinitely. The rest of the driver already
implements full runtime suspend/resume support (`drivers/usb/host/xhci-
plat.c:500-573`) and wraps probe/remove paths with the usual runtime-PM
bookkeeping (`drivers/usb/host/xhci-plat.c:355-390`,
`drivers/usb/host/xhci-plat.c:463-548`), so this line simply flips on an
otherwise wired-up capability. Risk is very low: runtime PM remains opt-
in because `pm_runtime_forbid()` keeps the default “on” policy
(`drivers/usb/host/xhci-plat.c:358-362`), and other SoC-specific xHCI
drivers have long invoked the same helper (for example
`drivers/usb/host/xhci-mtk.c:573` and `drivers/usb/host/xhci-
tegra.c:1943`). No dependent changes are required and there are no
follow-up fixes, so this targeted fix for a real power-management
regression is a good candidate for stable backporting.

 drivers/usb/host/xhci-plat.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
index 5eb51797de326..dd57ffedcaa2f 100644
--- a/drivers/usb/host/xhci-plat.c
+++ b/drivers/usb/host/xhci-plat.c
@@ -171,6 +171,7 @@ int xhci_plat_probe(struct platform_device *pdev, struct device *sysdev, const s
 		return ret;
 
 	pm_runtime_set_active(&pdev->dev);
+	pm_runtime_use_autosuspend(&pdev->dev);
 	pm_runtime_enable(&pdev->dev);
 	pm_runtime_get_noresume(&pdev->dev);
 
-- 
2.51.0

[PATCH AUTOSEL 6.17-5.15] thunderbolt: Use is_pciehp instead of is_hotplug_bridge

[Sasha Levin]

From: Lukas Wunner <lukas@wunner.de>

[ Upstream commit 5d03847175e81e86d4865456c15638faaf7c0634 ]

The thunderbolt driver sets up device link dependencies from hotplug ports
to the Host Router (aka Native Host Interface, NHI).  When resuming from
system sleep, this allows the Host Router to re-establish tunnels to
attached Thunderbolt devices before the hotplug ports resume.

To identify the hotplug ports, the driver utilizes the is_hotplug_bridge
flag which also encompasses ACPI slots handled by the ACPI hotplug driver.

Thunderbolt hotplug ports are always Hot-Plug Capable PCIe ports, so it is
more apt to identify them with the is_pciehp flag.

Similarly, hotplug ports on older Thunderbolt controllers have broken MSI
support and are quirked to use legacy INTx interrupts instead.  The quirk
identifies them with is_hotplug_bridge, even though all affected ports are
also matched by is_pciehp.  So use is_pciehp here as well.

Signed-off-by: Lukas Wunner <lukas@wunner.de>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES

- What it changes
  - Switches hotplug-port detection from the broad
    `pdev->is_hotplug_bridge` flag to the precise `pdev->is_pciehp`
    (PCIe Hot-Plug Capable) in two places:
    - Quirk for TB controllers’ hotplug MSI: drivers/pci/quirks.c:3834
    - Device-link creation for resume ordering:
      drivers/thunderbolt/tb.c:3256

- Why this is correct
  - Semantics: `is_hotplug_bridge` is a superset flag that also covers
    ACPI-driven slots and conventional PCI hotplug, not just PCIe HPC.
    Documentation explicitly distinguishes them (include/linux/pci.h:330
    and include/linux/pci.h:334).
  - TB downstream hotplug ports are always PCIe Hot-Plug Capable, so
    `is_pciehp` matches the intended set without inadvertently pulling
    in ACPI-only slots.
  - ACPI code can set `is_hotplug_bridge` on bridges that are not PCIe
    HPC (drivers/pci/hotplug/acpiphp_glue.c:411 and
    drivers/pci/hotplug/acpiphp_glue.c:424), which is precisely what
    this change avoids.

- Code specifics and impact
  - Quirk: drivers/pci/quirks.c:3834
    - Old: `if (pdev->is_hotplug_bridge && …) pdev->no_msi = 1;`
    - New: `if (pdev->is_pciehp && …) pdev->no_msi = 1;`
    - Effect: Still covers all affected TB hotplug ports (Light
      Ridge/Eagle Ridge/Light Peak/early Cactus Ridge/Port Ridge),
      because those ports have PCIe HPC. Behavior is unchanged for
      intended devices, but avoids misfiring if some non-PCIe-HP bridge
      was flagged via the generic hotplug flag.
  - Resume ordering via device links: drivers/thunderbolt/tb.c:3256
    - Old: Filter downstream ports with `… || !pdev->is_hotplug_bridge)
      continue;`
    - New: `… || !pdev->is_pciehp) continue;`
    - Effect: Device links are created only for PCIe HPC downstream
      ports beneath the TB controller’s upstream port, which are the
      ports that participate in TB PCIe tunneling. This avoids creating
      links for ACPI-only hotplug bridges that do not belong in the TB
      tunnel re-establishment ordering.

- Correctness and consistency with PCI core
  - The PCI core caches the HPC bit early and sets both flags together
    for PCIe HPC ports (drivers/pci/probe.c:1628 and
    drivers/pci/probe.c:1630), so `is_pciehp` is reliable and avoids
    late config reads.
  - Other subsystems have already moved to `is_pciehp` for the same
    reason (e.g., PCIe portdrv created services only when `is_pciehp`),
    demonstrating the broader effort to disambiguate these flags.

- Risk assessment
  - Small, localized change; no architectural shifts.
  - Maintainers’ acks: Thunderbolt and PCI maintainers are on board
    (Acked-by Bjorn Helgaas, Signed-off-by Mika Westerberg), indicating
    consensus on intent and safety.
  - For TB quirk, the condition remains true for all intended TB ports;
    for TB device-links, the selection is narrowed to the correct
    subset, reducing potential for incorrect PM dependency ordering. No
    functional expansion; only reduced false positives.

- User-facing effect
  - More reliable resume sequencing for tunneled TB devices (device
    links now scoped to true PCIe HP ports).
  - Avoids unnecessary links for ACPI-only slots that are unrelated to
    TB tunnels.
  - No change in MSI disabling behavior for affected TB generations;
    still prevents broken MSI usage there.

- Backport considerations
  - Dependency: Target stable trees must already have `struct
    pci_dev::is_pciehp` and the core logic that sets it
    (drivers/pci/probe.c:1628 and drivers/pci/probe.c:1630). If a stable
    branch lacks this field, it would require backporting that PCI core
    addition first.
  - Scope: Touches only `drivers/pci/quirks.c` and
    `drivers/thunderbolt/tb.c`; isolated and low-risk with no API
    changes.

Given the minimal change, precise semantics, alignment with ongoing PCI
core cleanups, and low regression risk confined to TB/PCI hotplug paths,
this is a good candidate for stable backport (where `is_pciehp` is
present).

 drivers/pci/quirks.c     | 2 +-
 drivers/thunderbolt/tb.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
index 6eb3d20386e95..214ed060ca1b3 100644
--- a/drivers/pci/quirks.c
+++ b/drivers/pci/quirks.c
@@ -3830,7 +3830,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MELLANOX, 0xcf80, quirk_no_pm_reset);
  */
 static void quirk_thunderbolt_hotplug_msi(struct pci_dev *pdev)
 {
-	if (pdev->is_hotplug_bridge &&
+	if (pdev->is_pciehp &&
 	    (pdev->device != PCI_DEVICE_ID_INTEL_CACTUS_RIDGE_4C ||
 	     pdev->revision <= 1))
 		pdev->no_msi = 1;
diff --git a/drivers/thunderbolt/tb.c b/drivers/thunderbolt/tb.c
index c14ab1fbeeafd..83a33fc1486ab 100644
--- a/drivers/thunderbolt/tb.c
+++ b/drivers/thunderbolt/tb.c
@@ -3336,7 +3336,7 @@ static bool tb_apple_add_links(struct tb_nhi *nhi)
 		if (!pci_is_pcie(pdev))
 			continue;
 		if (pci_pcie_type(pdev) != PCI_EXP_TYPE_DOWNSTREAM ||
-		    !pdev->is_hotplug_bridge)
+		    !pdev->is_pciehp)
 			continue;
 
 		link = device_link_add(&pdev->dev, &nhi->pdev->dev,
-- 
2.51.0