Gui-Dong Han [Mon, 23 Mar 2026 08:58:46 +0000 (16:58 +0800)]
soundwire: debugfs: initialize firmware_file to empty string
Passing NULL to debugfs_create_str() causes a NULL pointer dereference,
and creating debugfs nodes with NULL string pointers is no longer
permitted.
Additionally, firmware_file is a global pointer. Previously, adding every
new slave blindly overwrote it with NULL.
Fix these issues by initializing firmware_file to an allocated empty
string once in the subsystem init path (sdw_debugfs_init), and freeing
it in the exit path. Existing driver code handles empty strings
correctly.
Gui-Dong Han [Mon, 23 Mar 2026 08:58:45 +0000 (16:58 +0800)]
debugfs: fix placement of EXPORT_SYMBOL_GPL for debugfs_create_str()
The EXPORT_SYMBOL_GPL() for debugfs_create_str was placed incorrectly
away from the function definition. Move it immediately below the
debugfs_create_str() function where it belongs.
Gui-Dong Han [Mon, 23 Mar 2026 08:58:44 +0000 (16:58 +0800)]
debugfs: check for NULL pointer in debugfs_create_str()
Passing a NULL pointer to debugfs_create_str() leads to a NULL pointer
dereference when the debugfs file is read. Following upstream
discussions, forbid the creation of debugfs string files with NULL
pointers. Add a WARN_ON() to expose offending callers and return early.
Michal Pecio [Thu, 2 Apr 2026 13:13:42 +0000 (16:13 +0300)]
usb: xhci: Make usb_host_endpoint.hcpriv survive endpoint_disable()
xHCI hardware maintains its endpoint state between add_endpoint()
and drop_endpoint() calls followed by successful check_bandwidth().
So does the driver.
Core may call endpoint_disable() during xHCI endpoint life, so don't
clear host_ep->hcpriv then, because this breaks endpoint_reset().
If a driver calls usb_set_interface(), submits URBs which make host
sequence state non-zero and calls usb_clear_halt(), the device clears
its sequence state but xhci_endpoint_reset() bails out. The next URB
malfunctions: USB2 loses one packet, USB3 gets Transaction Error or
may not complete at all on some (buggy?) HCs from ASMedia and AMD.
This is triggered by uvcvideo on bulk video devices.
The code was copied from ehci_endpoint_disable() but it isn't needed
here - hcpriv should only be NULL on emulated root hub endpoints.
It might prevent resetting and inadvertently enabling a disabled and
dropped endpoint, but core shouldn't try to reset dropped endpoints.
Document xhci requirements regarding hcpriv. They are currently met.
Resume roothubs without checking 'retval' value, as it is always '0'.
Due to changes made in commit 79989bd4ab86 ("xhci: always resume roothubs
if xHC was reset during resume") the check is redundant.
Improve readability of xhci_hub_report_usb3_link_state().
Comments are shortened and clarified, and the code now makes it explicit
when the Port Link State (PLS) value is modified versus when other status
bits are updated.
usb: xhci: rename parameter to match argument 'portsc'
A previous patch renamed the temporary variable holding the value read
from the PORTSC register from 'temp' to 'portsc'. This patch follows up
by updating the parameter names of all helper functions called from
xhci_hub_control() that receive a PORTSC value, as well as the functions
they call.
Function changed:
xhci_get_port_status()
L xhci_get_usb3_port_status()
L xhci_hub_report_usb3_link_state()
L xhci_del_comp_mod_timer()
xhci_get_ext_port_status()
xhci_port_state_to_neutral()
xhci_clear_port_change_bit()
xhci_port_speed()
The reason for the rename is to differentiate between port
status/change bit to be written to PORTSC and replying to hub-class
USB requests. Each of them use their specific macros.
Use "portsc" name for PORTSC values and "status" for values intended
for replying to hub-class USB request.
A dedicated structure for USB hub port status responses
('struct usb_port_status' from ch11.h) exists and will be integrated in
a later patch.
usb: xhci: add PORTSC variable to xhci_hub_control()
The variable 'temp' is used multiple times throughout xhci_hub_control()
for holding only PORTSC register values.
As a follow-up to introducing a dedicated variable for PORTPMSC, rename
all remaining 'temp' to 'portsc'. This improves readability and clarifies
what is being modified.
usb: xhci: add PORTPMSC variable to xhci_hub_control()
The code handling U1/U2 timeout updates reads and modifies the PORTPMSC
register using the generic 'temp' variable, which is also used for
PORTSC. This makes the code hard to read and increases the risk of mixing
up register contents.
Introduce a dedicated 'portpmsc' variable for PORTPMSC accesses and use
it in both U1 and U2 timeout handlers. This makes the intent clearer and
keeps register operations logically separated.
usb: xhci: separate use of USB Chapter 11 PLS macros from xHCI-specific PLS macros
The xhci driver uses two different sources for Port Link State (PLS):
1. The PLS field in the PORTSC register (bits 8:5).
2. The PLS value encoded in bits 15:8 of the USB request wIndex,
received by xhci_hub_control().
While both represent similar link states, they differ in a few details,
for example, xHCI's Resume State. Because of these differences, the xhci
driver defines its own set of PLS macros in xhci-port.h, which are intended
to be used when reading and writing PORTSC. The generic USB Chapter 11
macros in ch11.h should only be used when parsing or replying to hub-class
USB requests.
To avoid mixing these two representations and prevent incorrect state
reporting, replace all uses of Chapter 11 PLS macros with the xHCI
versions when interacting with the PORTSC register.
usb: xhci: clean up 'wValue' handling in xhci_hub_control()
Several hub control requests encode a descriptor type in the upper byte
of 'wValue'. Clean this up by extracting the descriptor type into a local
variable and using it for all relevant requests.
Replace magic value (0x02) with the appropriate macro (HUB_EXT_PORT_STATUS)
This improves readability and makes the handling of 'wValue' consistent.
usb: xhci: clean up handling of upper bits in SetPortFeature wIndex
In Set Port Feature requests, the upper byte of 'wIndex' encodes
feature-specific parameters. The current code reads these upper bits in
an early pre-processing block, and then the same feature is handled again
later in the main switch statement. This results in duplicated condition
checks and makes the control flow harder to follow.
Move all feature-specific extraction of 'wIndex' upper bits into the
main SetPortFeature logic so that each feature is handled in exactly one
place. This reduces duplication, makes the handling clearer, and keeps
'wIndex' parsing local to the code that actually uses the values.
usb: xhci: rename 'wIndex' parameters to 'portnum'
Several helper functions take a parameter named 'wIndex', but the
value they receive is not the raw USB request wIndex field. The only
function that actually processes the USB hub request parameter is
xhci_hub_control(), which extracts the relevant port number (and other
upper-byte fields) before passing them down.
To avoid confusion between the USB request parameter and the derived
0-based port index, rename all such function parameters from 'wIndex'
to 'portnum'. This improves readability and makes the call intentions
clearer.
When a function accept struct 'xhci_port' pointer, use its port number
instead.
usb: xhci: stop treating 'wIndex' as a mutable port number
The USB request parameter 'wIndex' is a 16-bit field whose meaning depends
on the request type. For hub port operations, only bits 7:0 encode the port
number (1..MaxPorts). Despite this, the current code extracts the port
number into 'portnum1' while also modifying and using 'wIndex' directly as
a 0-based port index. This dual use is both confusing and error-prone,
since 'wIndex' is not always a pure port number.
Clean this up by deriving a single 0-based 'portnum' from 'wIndex' and
using it throughout the function. The original 'wIndex' value is no longer
modified or treated as a port number. This also matches existing xhci code.
usb: xhci: optimize resuming from S4 (suspend-to-disk)
On resume from S4 (power loss after suspend/hibernation), the xHCI
driver previously freed, reallocated, and fully reinitialized all
data structures. Most of this is unnecessary because the data is
restored from a saved image; only the xHCI registers lose their values.
This patch optimizes S4 resume by performing only a host controller
reset, which includes:
* Freeing or clearing runtime-created data.
* Rewriting xHCI registers.
Improve debug output for suspend failures, particularly when the controller
handshake does not complete. This will become important as upcoming patches
significantly rework the resume path, making more detailed suspend-side
messages valuable for debugging.
Add an explicit check of the Save/Restore Error (SRE) flag after a
successful Save State (CSS) operation. The xHCI specification
(note in section 4.23.2) states:
"After a Save or Restore State operation completes, the
Save/Restore Error (SRE) flag in USBSTS should be checked to
ensure the operation completed successfully."
Currently, the SRE error is only observed and warning is printed.
This patch does not introduce deeper error handling, as the correct
response is unclear and changes to suspend behavior may risk regressions
once the resume path is updated.
Additionally, simplify and clean up the suspend USBSTS CSS/SSS
handling code, improving readability and quirk handling for AMD
SNPS xHC controllers that occasionally do not clear the SSS bit.
usb: xhci: split core allocation and initialization
Separate allocation and initialization in the xHCI core:
* xhci_mem_init() now only handles memory allocation.
* xhci_init() now only handles initialization.
This split allows xhci_init() to be reused when resuming from S4
suspend-to-disk.
usb: xhci: move initialization for lifetime objects
Initialize objects that exist for the lifetime of the driver only once,
rather than repeatedly. These objects do not require re-initialization
after events such as S4 (suspend-to-disk).
Move ring initialization from xhci_ring_alloc() to xhci_ring_init().
Call xhci_ring_init() after xhci_ring_alloc(); in the future,
it can also be used to re-initialize the ring during resume.
Additionally, remove xhci_dbg_trace() from xhci_mem_init(). The command
ring's first segment DMA address is now printed during the trace call in
xhci_ring_init().
This refactoring lays also the groundwork for eventually replacing:
* xhci_dbc_ring_init()
* xhci_clear_command_ring()
Introduce xhci_rh_bw_cleanup() to release all bandwidth tracking
structures associated with xHCI roothub ports.
The new helper clears:
* TT bandwidth entries
* Per-interval endpoint lists
This refactors and consolidates the existing per-port cleanup logic
previously embedded in xhci_mem_cleanup(), reducing duplication and
making the teardown sequence easier to follow.
The helper will also be reused for upcoming S4 resume handling.
A Restore Error or Host Controller Error indicates that the host controller
failed to resume after suspend. In such cases, the xhci driver is fully
re-initialized, similar to a post-hibernation scenario.
The existing error check is only relevant when 'power_lost' is false.
If 'power_lost' is true, a Restore or Controller error has no effect:
no warning is printed and the 'power_lost' state remains unchanged.
Move the entire error check into the if '!power_lost' condition
to make this dependency explicit and simplify the resume logic.
The function compliance_mode_recovery_timer_init() is called from
xhci_init() because the Compliance Mode Recovery Timer (CMRT) must be set
up before xhci_run() when the xhci driver is re-initialized.
To handle this case, the boolean flag 'comp_timer_running' was introduced
to track whether xhci_run() had already been called, ensuring that
xhci_resume() would not invoke compliance_mode_recovery_timer_init()
a second time.
This can be simplified by moving the 'done' label in xhci_resume() to
after the compliance_mode_recovery_timer_init() call. With this change,
the timer initialization runs only when the xhci driver has not been
re-initialized, making the 'comp_timer_running' flag unnecessary and
allowing it to be removed.
Michal Pecio [Thu, 2 Apr 2026 13:13:20 +0000 (16:13 +0300)]
usb: xhci: Fix debugfs bandwidth reporting
Replace kernel USB speed numbers with xHCI protocol IDs expected by HW.
They are numerically equal up to high speed, but instead of SuperSpeed
we were querying SuperSpeed+.
Gen1 hardware rejects such commands with TRB Error, which resulted in
zero available bandwidth being shown.
While at that, report failures properly. No attempt made at "tunneling"
all possible comp codes through errno, debugfs users may inspect the
result through event-ring/trbs.
Michal Pecio [Thu, 2 Apr 2026 13:13:19 +0000 (16:13 +0300)]
usb: xhci: Simplify clearing the Event Interrupt bit
USBSTS is mostly RW1C, so to clear EINT we should write just this
one bit. Remove pointless code which ORs the bit with current value
of the register, even though the bit is already known to be set,
and writes the result back, which clears all active RW1C flags.
We used to inadvertently clear PCD and SRE in this way. PCD isn't
used by the driver and SRE is only used at resume, so clearing them
should make no difference. Don't clear them anymore.
Tested by connecting and mounting a storage device on a few HCs.
cc1352_bootloader_rx() appends each serdev chunk into the fixed
rx_buffer before parsing bootloader packets. The helper can keep
leftover bytes between callbacks and may receive multiple packets in one
callback, so a single count value is not constrained by one packet
length.
Check that the incoming chunk fits in the remaining receive buffer space
before memcpy(). If it does not, drop the staged data and consume the
bytes instead of overflowing rx_buffer.
Weigang He [Mon, 30 Mar 2026 12:08:01 +0000 (12:08 +0000)]
greybus: gb-beagleplay: propagate hdlc_tx_frames() errors to callers
Now that hdlc_tx_frames() can drop frames when the circular buffer is
full, make the failure visible to callers:
- Change hdlc_tx_frames() return type from void to int (-EAGAIN on
buffer full).
- Change gb_beagleplay_start_svc() / gb_beagleplay_stop_svc() to
return int so probe and firmware-upload paths can detect failures.
- gb_message_send(): propagate the error so the greybus core can
handle the transport failure.
- hdlc_tx_s_frame_ack(): log with dev_warn_ratelimited on failure
(ACK loss is recoverable by HDLC retransmission).
- Probe path: propagate start_svc failure via new free_greybus label.
- Firmware upload paths: return FW_UPLOAD_ERR_RW_ERROR when SVC
restart fails instead of silently continuing.
- Remove path: best-effort stop_svc, ignore failure.
Cc: Ayush Singh <ayushdevel1325@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Weigang He <geoffreyhe2@gmail.com> Link: https://patch.msgid.link/20260330120801.981506-2-geoffreyhe2@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Weigang He [Mon, 30 Mar 2026 12:08:00 +0000 (12:08 +0000)]
greybus: gb-beagleplay: fix sleep in atomic context in hdlc_tx_frames()
hdlc_append() calls usleep_range() to wait for circular buffer space,
but it is called with tx_producer_lock (a spinlock) held via
hdlc_tx_frames() -> hdlc_append_tx_frame()/hdlc_append_tx_u8()/etc.
Sleeping while holding a spinlock is illegal and can trigger
"BUG: scheduling while atomic".
Fix this by moving the buffer-space wait out of hdlc_append() and into
hdlc_tx_frames(), before the spinlock is acquired. The new flow:
1. Pre-calculate the worst-case encoded frame length.
2. Wait (with sleep) outside the lock until enough space is available,
kicking the TX consumer work to drain the buffer.
3. Acquire the spinlock, re-verify space, and write the entire frame
atomically.
This ensures that sleeping only happens without any lock held, and
that frames are either fully enqueued or not written at all.
This bug is found by CodeQL static analysis tool (interprocedural
sleep-in-atomic query) and my code review.
Fixes: ec558bbfea67 ("greybus: Add BeaglePlay Linux Driver") Cc: stable <stable@kernel.org> Cc: Ayush Singh <ayushdevel1325@gmail.com> Cc: Johan Hovold <johan@kernel.org> Cc: Alex Elder <elder@kernel.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Weigang He <geoffreyhe2@gmail.com> Link: https://patch.msgid.link/20260330120801.981506-1-geoffreyhe2@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 11 Mar 2026 08:22:26 +0000 (09:22 +0100)]
greybus: es2: drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
When `flashing_mode` is set, `gb_tty_receive()` routes incoming bytes to
`cc1352_bootloader_rx()`. That helper appends the new bytes to the shared
`rx_buffer` with `memcpy()` but does not check that the chunk fits in the
remaining space first. The normal HDLC receive path already enforces
`MAX_RX_HDLC`, so do the same here before appending bootloader data.
If a packet would overflow the receive buffer, drop it and reset the
bootloader receive state instead of copying past the end of `rx_buffer`.
Many Comedi drivers have unnecessary empty module_init and module_exit
functions. Remove them. Note that if a module_init function exists, a
module_exit function must also exist; otherwise, the module cannot be
unloaded.
Ian Abbott [Thu, 29 Jan 2026 11:44:02 +0000 (11:44 +0000)]
comedi: Correct name of ACCES I/O Products
Commit 6cd5a9a35c3d ("staging/trivial: fix typos concerning "access"")
accidentally changed "Acces I/O Products" to "Access I/O Products",
although "Acces" should actually be a capitalized acronym "ACCES"
(standing for "Acquisition, Control, and Communication: Engineering &
Systems"). Change it in the "aio_aio12_8" and "aio_iiro_16" drivers and
change the Kconfig file to match.
Ian Abbott [Fri, 30 Jan 2026 16:48:11 +0000 (16:48 +0000)]
comedi: s526: Add sanity checks for I/O base address
The "s526" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a Sensoray
526 board. It currently allows any base address to be configured but
the hardware only supports base addresses (configured by on-board DIP
switches) in the range 0 to 0xFFC0 on 64-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:48:10 +0000 (16:48 +0000)]
comedi: rti802: Add sanity checks for I/O base address
The "rti800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a RTI-802
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board DIP
switches) in the range 0 to 0x3FC on 4-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:48:09 +0000 (16:48 +0000)]
comedi: rti800: Add sanity checks for I/O base address
The "rti800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a RTI-800
or RTI-815 board. It currently allows any base address to be configured
but the hardware only supports base addresses (configured by on-board
DIP switches) in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:48:08 +0000 (16:48 +0000)]
comedi: pcmuio: Add sanity checks for I/O base address
The "pcmmio" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
PCM-UIO48A or PCM-UIO96A board. It will probably work with the later
PCM-UIO48C and PCM-UIO96C boards. It currently allows any base address
to be configured but the hardware only supports base addresses
(configured by on-board jumpers) in the range 0 to 0xFFF0 on 16-byte
boundaries (for PCM-UIO48C) or 0 to 0xFFE0 on 32-byte boundaries (for
PCM-UIO96C). (The PCM-UIO48A supports base addresses up to 0xFF0 and
the PCI-UIO96A supports base addresses up to 0x7E0.)
Add a sanity check to ensure the device is not configured at an
unsupported base address (allowing for the extended range of the "C"
models).
Ian Abbott [Fri, 30 Jan 2026 16:48:07 +0000 (16:48 +0000)]
comedi: pcmmio: Add sanity checks for I/O base address
The "pcmmio" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a PCM-MIO
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0 to 0xFFE0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:48:06 +0000 (16:48 +0000)]
comedi: pcmda12: Add sanity checks for I/O base address
The "pcmda12" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
PCM-D/A-12 or PCM-A/D-16 board. It currently allows any base address to
be configured. I cannot find a full manual, but the short datasheet
says it uses 15 consecutive I/O addresses on "any even sixteen port
boundary", so assume it supports base addresses (configured by on-board
jumpers) in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:48:05 +0000 (16:48 +0000)]
comedi: pcmad: Add sanity checks for I/O base address
The "pcmad" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
PCM-A/D-12 or PCM-A/D-16 board. It currently allows any base address to
be configured but the hardware only supports base addresses (configured
by on-board jumpers) in the range 0 to 0x3FC on 4-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:48:04 +0000 (16:48 +0000)]
comedi: pcm3724: Add sanity checks for I/O base address
The "pcm3724" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a PCM-3724
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board DIP
switches) in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:48:03 +0000 (16:48 +0000)]
comedi: pcl818: Add sanity checks for I/O base address
The "pcl818" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a board in
the PCL-818 series. It currently allows any base address to be
configured but the hardware devices only support base addresses
(configured by on-board DIP switches) from 0 to 0x3F0 on 16-byte
boundaries. If the board has a FIFO and jumper JP6 is in the "Enabled"
(default) position, then the base address needs to be on a 32-byte
boundary and the length of the I/O port region will be 32 (to allow
access to the FIFO registers) instead of 16. The state of jumper JP6 is
unknown, so if the board has a FIFO device and is being configured on an
odd 16-byte boundary, assume that jumper JP6 is in the "Disabled"
position (to disallow access to the FIFO registers).
Add a sanity check to ensure the device is not configured at an
unsupported base address.
If the board has a FIFO and is configured on an odd 16-byte boundary,
log a reminder that JP6 needs to be in the "Disabled" position for
correct operation. If the board has a FIFO and is configured on an even
16-byte boundary and the configuration option has been set to use the
FIFO (`it->options[2] == -1`), log a reminder that JP6 needs to be in
the "Enabled" position.
Ian Abbott [Fri, 30 Jan 2026 16:48:02 +0000 (16:48 +0000)]
comedi: pcl816: Add sanity checks for I/O base address
The "pcl816" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a PCL-816
or PCL-814B ISA board. It currently allows any base address to be
configured but the hardware devices only support base addresses
(configured by on-board DIP switches) from 0 to 0x3F0 on 16-byte
boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:48:01 +0000 (16:48 +0000)]
comedi: pcl812: Add sanity checks for I/O base address
The "pcl812" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of various
analog/digital I/O ISA boards from Advantech, ADLINK, and ICP DAS. It
currently allows any base address to be configured but the hardware
devices only support base addresses (configured by on-board DIP
switches) from 0 or 0x200 (depending on the model) to 0x3F0 on 16-byte
boundaries.
Store the minimum supported I/O base addresses in the static board
information array elements and add a sanity check to ensure the device
is not configured at an unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:48:00 +0000 (16:48 +0000)]
comedi: pcl730: Add sanity checks for I/O base address
The "pcl730" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of various
relay output and digital input ISA board from Advantech, ADLINK, ICP
DAS, and Diamond Systems. It currently allows any base address to be
configured but the hardware devices have restrictions on the base
addresses (configured by on-board DIP switches or jumpers), including
the alignment, which can be larger than the board's I/O register address
span. The Diamond Systems IR104-PBF board is particularly restricted to
4 different base addresses with different sized gaps between the
possible addresses.
Store the minimum supported I/O base addresses and alignment in the
static board information array elements and add a sanity check to ensure
the device is not configured at an unsupported base address. For the
IR104-PBF board, add a special check that the base address is one of the
4 supported base addresses for that board.
Ian Abbott [Fri, 30 Jan 2026 16:47:59 +0000 (16:47 +0000)]
comedi: pcl726: Add sanity checks for I/O base address
The "pcl726" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of various
analog output ISA boards from Advantech (PCL-726/727/728) and ADLINK
(ACL-6126/6128). (Most of them also have digital I/O.) It currently
allows any base address to be configured but the hardware only supports
base addresses (configured by on-board DIP switches) from 0 or 0x200 up
to nearly 0x3FF, depending on the model.
Store the minimum and maximum supported I/O address ranges in the static
board information array elements (the required alignment is already
stored in the `io_len` member), and add a sanity check to ensure the
device is not configured at an unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:58 +0000 (16:47 +0000)]
comedi: pcl724: Add sanity checks for I/O base address
The "pcl724" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of various
8255 chip-based digital I/O ISA boards from Advantech, ADLINK,
WinSystems, and Diamond Systems. It currently allows any base address
to be configured but the hardware only supports base addresses
(configured by on-board DIP switches or jumpers) in various ranges, and
on various alignment boundaries, depending on the model.
Store the minimum and maximum supported I/O address ranges in the static
board information array elements (the required alignment is already
stored in the `io_range` member), and add a sanity check to ensure the
device is not configured at an unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:57 +0000 (16:47 +0000)]
comedi: pcl711: Add sanity checks for I/O base address
The "pcl711" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an
Advantech PCL-711 series board or an Adlink ACL-8112 series board. It
currently allows any base address to be configured but the hardware only
supports base addresses (configured by on-board DIP switches) in the
range 0 to 0x3F0 (for PCL-711) or 0x200 to 0x3F0 (for ACL-8112) on
16-byte boundaries.
Store the minimum supported I/O base address in the static board
information array elements, and add a sanity check to ensure the device
is not configured at an unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:56 +0000 (16:47 +0000)]
comedi: ni_labpc: Add sanity checks for I/O base address
The "ni_labpc" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
Lab-PC-1200 series or Lab-PC+ board. It currently allows any base
address to be configured but the hardware only supports base addresses
(configured by a configuration utility and stored in nonvolatile memory)
in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:55 +0000 (16:47 +0000)]
comedi: ni_atmio16d: Add sanity checks for I/O base address
The "ni_atmio16d" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an
AT-MIO-16 o AT-MIO-16D board. It currently allows any base address to
be configured but the hardware only supports base addresses (configured
by on-board DIP switches) in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:54 +0000 (16:47 +0000)]
comedi: ni_atmio: Add sanity checks for I/O base address
The "ni_atmio" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an AT E
Series board. Or, if the option value is zero, it can search ISA PNP
devices to look for a compatible board. If the base address is
configured manually, it currently allows any base address to be
configured but the hardware only supports base addresses (configured by
a configuration utility and stored in nonvolatile memory) in the range
0x20 to 0xFFE0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:53 +0000 (16:47 +0000)]
comedi: ni_at_ao: Add sanity checks for I/O base address
The "ni_at_ao" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an AT-AO-6
or AT-AO-10 board. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
on-board jumpers) in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:52 +0000 (16:47 +0000)]
comedi: ni_at_a2150: Add sanity checks for I/O base address
The "ni_at_a2150" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an AT-A2150
series board. It currently allows any base address to be configured but
the hardware only supports base addresses (configured by on-board
jumpers) in the range 0 to 0x3E0 on 32-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:51 +0000 (16:47 +0000)]
comedi: multiq3: Add sanity checks for I/O base address
The "multiq3" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a Multiq-3
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:50 +0000 (16:47 +0000)]
comedi: mpc624: Add sanity checks for I/O base address
The "mpc624" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a MPC624
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0 to 0x3F0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:49 +0000 (16:47 +0000)]
comedi: fl512: Add sanity checks for I/O base address
The "fl512" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of an FL512
board. It currently allows any base address to be configured and uses a
16-byte register region.
I cannot find any information about this board, but assume it needs to
be aligned to a 16-byte boundary. I have no idea about the allowed
range, so allow anything in a 32-bit range and add a "FIXME" comment
(although most ancient ISA cards only support 10-bit address decoding).
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:48 +0000 (16:47 +0000)]
comedi: dt2817: Add sanity checks for I/O base address
The "dt2817" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DT2817
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by on-board jumpers)
in the range 0x200 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:47 +0000 (16:47 +0000)]
comedi: dt2815: Add sanity checks for I/O base address
The "dt2815" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DT2815
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0x200 to 0x3fe on 2-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:46 +0000 (16:47 +0000)]
comedi: dt2814: Add sanity checks for I/O base address
The "dt2814" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DT2814
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0x200 to 0x3fe on 2-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:45 +0000 (16:47 +0000)]
comedi: dt2811: Add sanity checks for I/O base address
The "dt2811" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DT2811 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
on-board jumpers) in the range 0x200 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:44 +0000 (16:47 +0000)]
comedi: dt2801: Add sanity checks for I/O base address
The "dt2801" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DT2801 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0x200 to 0x3fe on 2-byte
boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:43 +0000 (16:47 +0000)]
comedi: dmm32at: Add sanity check for I/O base address
The "dmm32at" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a
Diamond-MM-32-AT board. It currently allows any base address to be
configured but the hardware only supports 8 possible base addresses
(selected by 3 on-board jumpers). These are 0x100, 0x140, 0x180, 0x200,
0x280, 0x300, 0x340, and 0x380.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:42 +0000 (16:47 +0000)]
comedi: das800: Add sanity checks for I/O base address
The "das800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DAS800 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:41 +0000 (16:47 +0000)]
comedi: das6402: Add sanity checks for I/O base address
The "das6402" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DAS6402 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f0 on 16-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:40 +0000 (16:47 +0000)]
comedi: das1800: Add sanity checks for I/O base address
The "das1800" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a board
compatible with the DAS1800 series. It currently allows any base
address to be configured but the hardware only supports base addresses
(configured by an on-board DIP switch) in the range 0 to 0x3f0 on
16-byte boundaries. Some boards have an additional span of up to 0x10
registers at offset 0x400 from the main 0x10 byte region.
Add a sanity check to ensure the device is not configured at an
unsupported base address. If the main base address is correctly aligned
and within range, then the additional region at offset 0x400 from the
configured base address will naturally be within range and correctly
aligned.
Ian Abbott [Fri, 30 Jan 2026 16:47:39 +0000 (16:47 +0000)]
comedi: das16m1: Add sanity checks for I/O base address
The "das16m1" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a DAS16/M1
board. It currently allows any base address to be configured but the
hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0 to 0x3f0 on 16-byte boundaries. It has an
additional span of 0x8 registers at offset 0x400 from the main 0x10 byte
region.
Add a sanity check to ensure the device is not configured at an
unsupported base address. If the main base address is correctly aligned
and within range, then the additional region at offset 0x400 from the
configured base address will naturally be within range and correctly
aligned.
Ian Abbott [Fri, 30 Jan 2026 16:47:38 +0000 (16:47 +0000)]
comedi: das16: Add sanity checks for I/O base address
The "das16" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a various
DAS16 compatible boards. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f0 on 16- or 32-byte
boundaries. Some of the boards have an 8255 chip at offset 0x10 and
require the board to be configured on a 32-byte boundary unless some
on-board jumpers are set to limit the board to decoding only the first
0x10 registers, disabling access to the 8255. Some other boards place
the 8255 chip (and some other registers) at offset 0x400 from the base
address, decoding 0x10 registers at the base address and 0x8 registers
at the base address plus 0x400.
Add a sanity check to ensure the device is not configured at an
unsupported base address. If the device has the 8255 chip at offset
0x10, and is being configured with the base address at an odd 16-byte
boundary, limit the size of the region to 0x10 and disable the 8255
subdevice.
Ian Abbott [Fri, 30 Jan 2026 16:47:37 +0000 (16:47 +0000)]
comedi: das08_isa: Add sanity checks for I/O base address
The "das08_isa" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board in the DAS08 family. It currently allows any base address to be
configured but the hardware only supports base addresses (configured by
an on-board DIP switch) in the range 0 to 0x3f0 on 16-byte boundaries.
(Technically, the DIP switches allow 8-byte boundaries, but I do not
think that is advisable given that the boards decode an 16-byte address
range.)
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:36 +0000 (16:47 +0000)]
comedi: dac02: Add sanity checks for I/O base address
The "dac02" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
DAC-02 board. It currently allows any base address to be configured but
the hardware only supports base addresses (configured by an on-board DIP
switch) in the range 0x200 to 0x3f8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:35 +0000 (16:47 +0000)]
comedi: comedi_parport: Add sanity checks for I/O base address
The "comedi_parport" driver treats a standard printer parallel port as a
COMEDI digital I/O device, driving the port's I/O registers directly.
It uses an admin-supplied configuration option (`it->options[0]`) to
configure the I/O port base address of the device. Currently, the
driver allows any I/O base address to be specified as long as the I/O
region can be reserved, and it converts the specified `int` option value
holding the base address to `unsigned long`.
It doesn't make sense to allow base addresses that are not aligned to
4-byte boundaries (for SPP printer ports, although printer ports with
EPP/ECP support actually need to be aligned on 8-byte boundaries), so
add a check for 4-byte alignment.
Convert the option value that specifies the base address from `int` to
`unsigned int` instead of `unsigned long` so it ends up the same on
32-bit and 64-bit systems.
Ian Abbott [Fri, 30 Jan 2026 16:47:34 +0000 (16:47 +0000)]
comedi: c6xdigio: Add sanity checks for I/O base address
The "c6xdigio" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
C6x_DIGIO DSP device connected to a PC printer parallel port (driving
the port's I/O registers directly). Currently, the driver allows any
I/O base address to be specified as long as the I/O region can be
reserved, and it converts the specified `int` option value holding the
base address to `unsigned long`.
It doesn't make sense to allow base addresses that are not aligned to
4-byte boundaries (for SPP printer ports, although printer ports with
EPP/ECP support actually need to be aligned on 8-byte boundaries), so
add a check for 4-byte alignment.
Convert the option value that specifies the base address from `int` to
`unsigned int` instead of `unsigned long` so it ends up the same on
32-bit and 64-bit systems.
Ian Abbott [Fri, 30 Jan 2026 16:47:33 +0000 (16:47 +0000)]
comedi: amplc_pc263: Add sanity checks for I/O base address
The "amplc_pc263" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
PC263 board. It currently allows any base address to be configured but
the hardware only supports base addresses (set by on-board DIP switches)
in the range 0 to 0x7FE on 2-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:32 +0000 (16:47 +0000)]
comedi: amplc_pc236: Add sanity checks for I/O base address
The "amplc_pc236" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
PC36AT board. It currently allows any base address to be configured but
the hardware only supports base addresses (set by on-board DIP switches)
in the range 0 to 0xFFC on 4-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:31 +0000 (16:47 +0000)]
comedi: amplc_dio200: Add sanity checks for I/O base address
The "amplc_dio200" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board (PC212E, PC214E, PC215E, PC218E, or PC272E). It currently allows
any base address to be configured but the hardware only supports base
addresses (set by on-board DIP switches) in the range 0 to 0xFE0 on
32-byte boundaries. (Technically, the DIP switches allow 16-byte
boundaries, but I do not think that is advisable given that the boards
decode a 32-byte address range.)
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:30 +0000 (16:47 +0000)]
comedi: aio_iiro_16: Add sanity checks for I/O base address
The "aio_iiro_16" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board (IIRO-16). It currently allows any base address to be configured
but the hardware only supports base addresses (set by on-board jumpers)
in the range 0x100 to 0x3F8 on 8-byte boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:29 +0000 (16:47 +0000)]
comedi: aio_aio12_8: Add sanity checks for I/O base address
The "aio_aio12_8" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of a supported
board (AIO12-8, AI12-8, or AO12-4). It currently allows any base
address to be configured but the hardware only supports base addresses
(set by on-board jumpers) in the range 0x100 to 0x3C0 on 32-byte
boundaries.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:28 +0000 (16:47 +0000)]
comedi: adq12b: Add sanity checks for I/O base address
The "adq12b" driver uses an admin-supplied configuration option
(`it->options[0]`) to configure the I/O port base address of the ADQ12-B
board. It currently allows any base address to be configured but the
hardware only supports the following base addresses (set by an on-board
jumper): 0x300, 0x320, 0x340, 0x360, 0x380, 0x3A0.
Add a sanity check to ensure the device is not configured at an
unsupported base address.
Ian Abbott [Fri, 30 Jan 2026 16:47:27 +0000 (16:47 +0000)]
comedi: 8255: Add some I/O base address sanity checks
The "8255" driver allows a COMEDI device to be constructed from one or
more 8255 chips, each at an I/O port base address specified by the
admin-supplied configuration options (`it->options[]`). Currently, the
driver allows any I/O base addresses to be specified as long as the I/O
regions can be reserved, and it converts the specified `int` option
values holding the base address to `unsigned long`.
It doesn't make sense to allow base addresses that are not aligned to
4-byte boundaries because the hardware register addresses would not be
decoded properly, so add a check for valid alignment.
Convert the option values that specify the base addresses from `int` to
`unsigned int` instead of `unsigned long` so they end up the same on
32-bit and 64-bit systems.
Ian Abbott [Fri, 30 Jan 2026 16:47:26 +0000 (16:47 +0000)]
comedi: add comedi_check_request_region()
There is an existing comedi_request_region(dev, start, len) function
used by COMEDI drivers for legacy devices to request an I/O port region
starting at a specified base address (which must be non-zero) and with a
specified length. It uses request_region(). On success, it sets
dev->iobase and dev->iolen and returns 0. There is a alternative
function __comedi_request_region(dev, start, len) which does the same
thing without setting dev->iobase and dev->iolen.
Most hardware devices have restrictions on the allowed I/O port base
address and alignment, so add new functions
comedi_check_request_region(dev, start, len, minstart, maxend, minalign)
and __comedi_check_request_region(dev, start, len, minstart, maxend,
minalign) to perform these additional checks. Turn the original
functions into static inline wrapper functions that call the new
functions.
Now that all the bits are properly addressed, provide a mechanism
for testing ESA mode guests in nested configurations.
Signed-off-by: Hendrik Brueckner <brueckner@linux.ibm.com>
[farman@us.ibm.com: Updated commit message] Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Eric Farman <farman@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Eric Farman [Wed, 1 Apr 2026 15:12:20 +0000 (17:12 +0200)]
KVM: s390: vsie: Accommodate ESA prefix pages
The prefix page address occupies a different number
of bits for z/Architecture versus ESA mode. Adjust the
definition to cover both, and permit an ESA mode
address within the nested codepath.
Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Eric Farman [Wed, 1 Apr 2026 15:12:19 +0000 (17:12 +0200)]
KVM: s390: vsie: Disable some bits when in ESA mode
In the event that a nested guest is put in ESA mode,
ensure that some bits are scrubbed from the shadow SCB.
Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
Eric Farman [Wed, 1 Apr 2026 15:12:18 +0000 (17:12 +0200)]
KVM: s390: vsie: Allow non-zarch guests
Linux/KVM runs in z/Architecture-only mode. Although z/Architecture
is built upon a long history of hardware refinements, any other
CPU mode is not permitted.
Allow a userspace to explicitly enable the use of ESA mode for
nested guests, otherwise usage will be rejected.
Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Eric Farman <farman@linux.ibm.com> Reviewed-by: Hendrik Brueckner <brueckner@linux.ibm.com> Reviewed-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
tracing: Non-consuming read for trace remotes with an offline CPU
When a trace_buffer is created while a CPU is offline, this CPU is
cleared from the trace_buffer CPU mask, preventing the creation of a
non-consuming iterator (ring_buffer_iter). For trace remotes, it means
the iterator fails to be allocated (-ENOMEM) even though there are
available ring buffers in the trace_buffer.
For non-consuming reads of trace remotes, skip missing ring_buffer_iter
to allow reading the available ring buffers.
Lorenzo Bianconi [Tue, 31 Mar 2026 10:33:24 +0000 (12:33 +0200)]
net: airoha: Set REG_RX_CPU_IDX() once in airoha_qdma_fill_rx_queue()
It is not necessary to update REG_RX_CPU_IDX register for each iteration
of the descriptor loop in airoha_qdma_fill_rx_queue routine.
Move REG_RX_CPU_IDX configuration out of the descriptor loop and rely on
the last queue head value updated in the descriptor loop.
Xiang Mei [Tue, 31 Mar 2026 05:02:17 +0000 (22:02 -0700)]
selftests/tc-testing: add tests for cls_fw and cls_flow on shared blocks
Regression tests for the shared-block NULL derefs fixed in the previous
two patches:
- fw: attempt to attach an empty fw filter to a shared block and
verify the configuration is rejected with EINVAL.
- flow: create a flow filter on a shared block without a baseclass
and verify the configuration is rejected with EINVAL.
Signed-off-by: Xiang Mei <xmei5@asu.edu> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260331050217.504278-3-xmei5@asu.edu Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Xiang Mei [Tue, 31 Mar 2026 05:02:16 +0000 (22:02 -0700)]
net/sched: cls_flow: fix NULL pointer dereference on shared blocks
flow_change() calls tcf_block_q() and dereferences q->handle to derive
a default baseclass. Shared blocks leave block->q NULL, causing a NULL
deref when a flow filter without a fully qualified baseclass is created
on a shared block.
Check tcf_block_shared() before accessing block->q and return -EINVAL
for shared blocks. This avoids the null-deref shown below:
=======================================================================
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:flow_change (net/sched/cls_flow.c:508)
Call Trace:
tc_new_tfilter (net/sched/cls_api.c:2432)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6980)
[...]
=======================================================================
Fixes: 1abf272022cf ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc") Reported-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Xiang Mei <xmei5@asu.edu> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260331050217.504278-2-xmei5@asu.edu Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Xiang Mei [Tue, 31 Mar 2026 05:02:15 +0000 (22:02 -0700)]
net/sched: cls_fw: fix NULL pointer dereference on shared blocks
The old-method path in fw_classify() calls tcf_block_q() and
dereferences q->handle. Shared blocks leave block->q NULL, causing a
NULL deref when an empty cls_fw filter is attached to a shared block
and a packet with a nonzero major skb mark is classified.
Reject the configuration in fw_change() when the old method (no
TCA_OPTIONS) is used on a shared block, since fw_classify()'s
old-method path needs block->q which is NULL for shared blocks.
The fixed null-ptr-deref calling stack:
KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]
RIP: 0010:fw_classify (net/sched/cls_fw.c:81)
Call Trace:
tcf_classify (./include/net/tc_wrapper.h:197 net/sched/cls_api.c:1764 net/sched/cls_api.c:1860)
tc_run (net/core/dev.c:4401)
__dev_queue_xmit (net/core/dev.c:4535 net/core/dev.c:4790)
Fixes: 1abf272022cf ("net: sched: tcindex, fw, flow: use tcf_block_q helper to get struct Qdisc") Reported-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Xiang Mei <xmei5@asu.edu> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Link: https://patch.msgid.link/20260331050217.504278-1-xmei5@asu.edu Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Ming Lei [Thu, 26 Mar 2026 14:40:58 +0000 (22:40 +0800)]
bio: fix kmemleak false positives from percpu bio alloc cache
When a bio is allocated from the mempool with REQ_ALLOC_CACHE set and
later completed, bio_put() places it into the per-cpu bio_alloc_cache
via bio_put_percpu_cache() instead of freeing it back to the
mempool/slab. The slab allocation remains tracked by kmemleak, but the
only reference to the bio is through the percpu cache's free_list,
which kmemleak fails to trace through percpu memory. This causes
kmemleak to report the cached bios as unreferenced objects.
Use symmetric kmemleak_free()/kmemleak_alloc() calls to properly track
bios across percpu cache transitions:
- bio_put_percpu_cache: call kmemleak_free() when a bio enters the
cache, unregistering it from kmemleak tracking.
- bio_alloc_percpu_cache: call kmemleak_alloc() when a bio is taken
from the cache for reuse, re-registering it so that genuine leaks
of reused bios remain detectable.
- __bio_alloc_cache_prune: call kmemleak_alloc() before bio_free() so
that kmem_cache_free()'s internal kmemleak_free() has a matching
allocation to pair with.
projects / thirdparty / linux.git / log
