kernel/linux.git, branch v6.6.116

Linux 6.6.116

2025-11-02T13:14:42+00:00

Link: https://lore.kernel.org/r/20251031140042.387255981@linuxfoundation.org Tested-by: Peter Schneider Tested-by: Florian Fainelli Tested-by: Jon Hunter Tested-by: Shuah Khan Tested-by: Linux Kernel Functional Testing Tested-by: Ron Economos Tested-by: Brett A C Sheffield Tested-by: Miguel Ojeda Signed-off-by: Greg Kroah-Hartman

gpio: idio-16: Define fixed direction of the GPIO lines

2025-11-02T13:14:42+00:00

[ Upstream commit 2ba5772e530f73eb847fb96ce6c4017894869552 ] The direction of the IDIO-16 GPIO lines is fixed with the first 16 lines as output and the remaining 16 lines as input. Set the gpio_config fixed_direction_output member to represent the fixed direction of the GPIO lines. Fixes: db02247827ef ("gpio: idio-16: Migrate to the regmap API") Reported-by: Mark Cave-Ayland Closes: https://lore.kernel.org/r/9b0375fd-235f-4ee1-a7fa-daca296ef6bf@nutanix.com Suggested-by: Michael Walle Cc: stable@vger.kernel.org # ae495810cffe: gpio: regmap: add the .fixed_direction_output configuration parameter Cc: stable@vger.kernel.org Reviewed-by: Andy Shevchenko Signed-off-by: William Breathitt Gray Reviewed-by: Linus Walleij Link: https://lore.kernel.org/r/20251020-fix-gpio-idio-16-regmap-v2-3-ebeb50e93c33@kernel.org Signed-off-by: Bartosz Golaszewski Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

gpio: regmap: add the .fixed_direction_output configuration parameter

2025-11-02T13:14:42+00:00

[ Upstream commit 00aaae60faf554c27c95e93d47f200a93ff266ef ] There are GPIO controllers such as the one present in the LX2160ARDB QIXIS FPGA which have fixed-direction input and output GPIO lines mixed together in a single register. This cannot be modeled using the gpio-regmap as-is since there is no way to present the true direction of a GPIO line. In order to make this use case possible, add a new configuration parameter - fixed_direction_output - into the gpio_regmap_config structure. This will enable user drivers to provide a bitmap that represents the fixed direction of the GPIO lines. Signed-off-by: Ioana Ciornei Acked-by: Bartosz Golaszewski Reviewed-by: Michael Walle Signed-off-by: Bartosz Golaszewski Stable-dep-of: 2ba5772e530f ("gpio: idio-16: Define fixed direction of the GPIO lines") Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

gpio: regmap: Allow to allocate regmap-irq device

2025-11-02T13:14:42+00:00

[ Upstream commit 553b75d4bfe9264f631d459fe9996744e0672b0e ] GPIO controller often have support for IRQ: allow to easily allocate both gpio-regmap and regmap-irq in one operation. Reviewed-by: Andy Shevchenko Acked-by: Bartosz Golaszewski Signed-off-by: Mathieu Dubois-Briand Link: https://lore.kernel.org/r/20250824-mdb-max7360-support-v14-5-435cfda2b1ea@bootlin.com Signed-off-by: Lee Jones Stable-dep-of: 2ba5772e530f ("gpio: idio-16: Define fixed direction of the GPIO lines") Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

bits: introduce fixed-type GENMASK_U*()

2025-11-02T13:14:42+00:00

[ Upstream commit 19408200c094858d952a90bf4977733dc89a4df5 ] Add GENMASK_TYPE() which generalizes __GENMASK() to support different types, and implement fixed-types versions of GENMASK() based on it. The fixed-type version allows more strict checks to the min/max values accepted, which is useful for defining registers like implemented by i915 and xe drivers with their REG_GENMASK*() macros. The strict checks rely on shift-count-overflow compiler check to fail the build if a number outside of the range allowed is passed. Example: #define FOO_MASK GENMASK_U32(33, 4) will generate a warning like: include/linux/bits.h:51:27: error: right shift count >= width of type [-Werror=shift-count-overflow] 51 | type_max(t) >> (BITS_PER_TYPE(t) - 1 - (h))))) | ^~ The result is casted to the corresponding fixed width type. For example, GENMASK_U8() returns an u8. Note that because of the C promotion rules, GENMASK_U8() and GENMASK_U16() will immediately be promoted to int if used in an expression. Regardless, the main goal is not to get the correct type, but rather to enforce more checks at compile time. While GENMASK_TYPE() is crafted to cover all variants, including the already existing GENMASK(), GENMASK_ULL() and GENMASK_U128(), for the moment, only use it for the newly introduced GENMASK_U*(). The consolidation will be done in a separate change. Co-developed-by: Yury Norov Signed-off-by: Lucas De Marchi Acked-by: Jani Nikula Signed-off-by: Vincent Mailhol Reviewed-by: Andy Shevchenko Signed-off-by: Yury Norov Stable-dep-of: 2ba5772e530f ("gpio: idio-16: Define fixed direction of the GPIO lines") Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

bits: add comments and newlines to #if, #else and #endif directives

2025-11-02T13:14:41+00:00

[ Upstream commit 31299a5e0211241171b2222c5633aad4763bf700 ] This is a preparation for the upcoming GENMASK_U*() and BIT_U*() changes. After introducing those new macros, there will be a lot of scrolling between the #if, #else and #endif. Add a comment to the #else and #endif preprocessor macros to help keep track of which context we are in. Also, add new lines to better visually separate the non-asm and asm sections. Signed-off-by: Vincent Mailhol Reviewed-by: Andy Shevchenko Signed-off-by: Yury Norov Stable-dep-of: 2ba5772e530f ("gpio: idio-16: Define fixed direction of the GPIO lines") Signed-off-by: William Breathitt Gray Signed-off-by: Greg Kroah-Hartman

xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event

2025-11-02T13:14:41+00:00

[ Upstream commit f3d12ec847b945d5d65846c85f062d07d5e73164 ] DbC may add 1024 bogus bytes to the beginneing of the receiving endpoint if DbC hw triggers a STALL event before any Transfer Blocks (TRBs) for incoming data are queued, but driver handles the event after it queued the TRBs. This is possible as xHCI DbC hardware may trigger spurious STALL transfer events even if endpoint is empty. The STALL event contains a pointer to the stalled TRB, and "remaining" untransferred data length. As there are no TRBs queued yet the STALL event will just point to first TRB position of the empty ring, with '0' bytes remaining untransferred. DbC driver is polling for events, and may not handle the STALL event before /dev/ttyDBC0 is opened and incoming data TRBs are queued. The DbC event handler will now assume the first queued TRB (length 1024) has stalled with '0' bytes remaining untransferred, and copies the data This race situation can be practically mitigated by making sure the event handler handles all pending transfer events when DbC reaches configured state, and only then create dev/ttyDbC0, and start queueing transfers. The event handler can this way detect the STALL events on empty rings and discard them before any transfers are queued. This does in practice solve the issue, but still leaves a small possible gap for the race to trigger. We still need a way to distinguish spurious STALLs on empty rings with '0' bytes remaing, from actual STALL events with all bytes transmitted. Cc: stable Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver") Tested-by: Łukasz Bartosik Signed-off-by: Mathias Nyman Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

xhci: dbc: Avoid event polling busyloop if pending rx transfers are inactive.

2025-11-02T13:14:41+00:00

[ Upstream commit cab63934c33b12c0d1e9f4da7450928057f2c142 ] Event polling delay is set to 0 if there are any pending requests in either rx or tx requests lists. Checking for pending requests does not work well for "IN" transfers as the tty driver always queues requests to the list and TRBs to the ring, preparing to receive data from the host. This causes unnecessary busylooping and cpu hogging. Only set the event polling delay to 0 if there are pending tx "write" transfers, or if it was less than 10ms since last active data transfer in any direction. Cc: Łukasz Bartosik Fixes: fb18e5bb9660 ("xhci: dbc: poll at different rate depending on data transfer activity") Cc: stable@vger.kernel.org Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20250505125630.561699-3-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

xhci: dbc: Improve performance by removing delay in transfer event polling.

2025-11-02T13:14:41+00:00

[ Upstream commit 03e3d9c2bd85cda941b3cf78e895c1498ac05c5f ] Queue event polling work with 0 delay in case there are pending transfers queued up. This is part 2 of a 3 part series that roughly triples dbc performace when using adb push and pull over dbc. Max/min push rate after patches is 210/118 MB/s, pull rate 171/133 MB/s, tested with large files (300MB-9GB) by Łukasz Bartosik First performance improvement patch was commit 31128e7492dc ("xhci: dbc: add dbgtty request to end of list once it completes") Cc: Łukasz Bartosik Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20241227120142.1035206-2-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

xhci: dbc: Allow users to modify DbC poll interval via sysfs

2025-11-02T13:14:41+00:00

[ Upstream commit de3edd47a18fe05a560847cc3165871474e08196 ] xhci DbC driver polls the host controller for DbC events at a reduced rate when DbC is enabled but there are no active data transfers. Allow users to modify this reduced poll interval via dbc_poll_interval_ms sysfs entry. Unit is milliseconds and accepted range is 0 to 5000. Max interval of 5000 ms is selected as it matches the common 5 second timeout used in usb stack. Default value is 64 milliseconds. A long interval is useful when users know there won't be any activity on systems connected via DbC for long periods, and want to avoid battery drainage due to unnecessary CPU usage. Example being Android Debugger (ADB) usage over DbC on ChromeOS systems running Android Runtime. [minor changes and rewording -Mathias] Co-developed-by: Samuel Jacob Signed-off-by: Samuel Jacob Signed-off-by: Uday M Bhat Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20240626124835.1023046-5-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman Stable-dep-of: f3d12ec847b9 ("xhci: dbc: fix bogus 1024 byte prefix if ttyDBC read races with stall event") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman