| Age | Commit message (Collapse) | Author |
|---|
|
anx7411_i2c_probe() enables runtime PM before returning successfully, but
anx7411_i2c_remove() tears down the Type-C partner state, workqueue, dummy
I2C device, mux, switch and port without disabling runtime PM.
Use devm_pm_runtime_enable() so runtime PM is disabled automatically on
driver detach. Since devres action registration can fail, route that
failure through the existing probe unwind path.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: fe6d8a9c8e64 ("usb: typec: anx7411: Add Analogix PD ANX7411 support")
Cc: stable <stable@kernel.org>
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260701114006.75738-1-mhun512@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The dwc3_ulpi_setup() calls the register read and write calls with
dwc3->regs when both these calls take the dwc3 structure directly.
Chnage these two calls to fix the following sparse warning, and
possibly a nasty bug in the dwc3_ulpi_setup() code:
drivers/usb/dwc3/core.c:796:45: warning: incorrect type in argument 1 (different address spaces)
drivers/usb/dwc3/core.c:796:45: expected struct dwc3 *dwc
drivers/usb/dwc3/core.c:796:45: got void [noderef] __iomem *regs
drivers/usb/dwc3/core.c:798:40: warning: incorrect type in argument 1 (different address spaces)
drivers/usb/dwc3/core.c:798:40: expected struct dwc3 *dwc
drivers/usb/dwc3/core.c:798:40: got void [noderef] __iomem *regs
Cc: stable <stable@kernel.org>
Fixes: 9accc68b1cf0 ("usb: dwc3: Add dwc pointer to dwc3_readl/writel")
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Link: https://patch.msgid.link/20260703162033.2847599-1-ben.dooks@codethink.co.uk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
uss720_probe() registers a parport before reading the 1284 register used
to detect unsupported Belkin F5U002 adapters. If get_1284_register()
fails, the error path drops the driver private data and the USB device
reference, but leaves the parport device registered.
Leaving the port registered is more than a private allocation leak:
parport_register_port() has already reserved a parport number and
registered the parport bus device, while pp->private_data still points at
the private data that the common error path is about to release.
Undo the pre-announce registration in the get_1284_register() failure
branch before jumping to the common private-data cleanup path. Clear
priv->pp first, matching the disconnect path and avoiding a stale pointer
in the private data.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: 3295f1b866bf ("usb: misc: uss720: check for incompatible versions of the Belkin F5U002")
Cc: stable <stable@kernel.org>
Co-developed-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Ijae Kim <ae878000@gmail.com>
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Alex Henrie <alexhenrie24@gmail.com>
Link: https://patch.msgid.link/20260706151049.63470-1-mhun512@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add a length check for the rndis header in rndis_rm_hdr, to ensure that
MessageType, MessageLength, DataOffset, and DataLength fields are
present before they are accessed.
Assisted-by: gkh_clanker_2000
Cc: stable <stable@kernel.org>
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
Link: https://patch.msgid.link/20260708-usb-gadget-rndis-v1-2-e77e026dcc6a@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Add variable representations for BufLength and BufOffset in
rndis_query_response(), and perform a length check on them.
This is identical to how rndis_set_response() handles these parameters.
Assisted-by: gkh_clanker_2000
Cc: stable <stable@kernel.org>
Signed-off-by: Griffin Kroah-Hartman <griffin@kroah.com>
Link: https://patch.msgid.link/20260708-usb-gadget-rndis-v1-1-e77e026dcc6a@kroah.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
EHCI and FOTG210 isochronous submits build an ehci_iso_sched before
linking the URB to the endpoint queue, and keep the staged schedule in
urb->hcpriv until iso_stream_schedule() and the link helpers consume it.
If the controller is no longer accessible, or usb_hcd_link_urb_to_ep()
fails, submit jumps to done_not_linked before that handoff happens and
leaks the staged schedule still attached to urb->hcpriv.
Free the staged schedule from done_not_linked when submit fails before
the URB is linked and clear urb->hcpriv after the free.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still
present in v7.1.1.
An x86_64 allyesconfig build showed no new warnings. As we do not have an
EHCI host controller with a USB isochronous device to test with, no
runtime testing was able to be performed.
Fixes: 8de98402652c ("[PATCH] USB: Fix USB suspend/resume crasher (#2)")
Fixes: e9df41c5c589 ("USB: make HCDs responsible for managing endpoint queues")
Fixes: 7d50195f6c50 ("usb: host: Faraday fotg210-hcd driver")
Cc: stable <stable@kernel.org>
Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260630071419.349161-1-dawei.feng@seu.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Commit 1892bf90677a ("USB: usb-storage: Fix use of bitfields for
hardware data in ene_ub6250.c") converted the media status fields from
bitfields to bit masks.
The original ene_transport() test called ene_init() only when neither
media type was ready:
!(sd_ready || ms_ready)
The converted test became:
!sd_ready || ms_ready
This is not equivalent. Restore the original semantics by testing that
both ready bits are clear before calling ene_init().
Fixes: 1892bf90677a ("USB: usb-storage: Fix use of bitfields for hardware data in ene_ub6250.c")
Cc: stable <stable@kernel.org>
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/F42641386E32404F+20260626070607.4119527-1-raoxu@uniontech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
printer_open() returns -EBUSY when the character device is already
open, but it increments dev->kref regardless of the return value. VFS
does not call ->release() for a failed open, so every rejected second
open permanently leaks one reference.
Move kref_get() into the successful-open branch.
Fixes: e8d5f92b8d30 ("usb: gadget: function: printer: fix use-after-free in __lock_acquire")
Cc: stable <stable@kernel.org>
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Link: https://patch.msgid.link/80295742B820DA9B+20260626064617.4090626-1-raoxu@uniontech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
vep_alloc_request() wasn't initializing vrequest->udc, so cancellations
on the FunctionFS AIO path were arriving in vep_dequeue without a valid
UDC reference.
Since vrequest->udc is never actually properly used anywhere, we opt to
remove it, and update vep_dequeue to obtain a reference to the udc with
ep_to_vudc(), consistent with the other vep_ ops.
AFAICT this bug has existed for ~10 years. Seems that nobody has really
stressed the FunctionFS AIO path on usbip's vudc.
I tested this fix in a QEMU aarch64 guest driving FunctionFS endpoints
via AIO. Before the fix, running `usbip attach` from the host would
cause the guest to oops with the following backtrace:
Call trace:
vep_dequeue+0x1c/0xe4 (P)
usb_ep_dequeue+0x14/0x20
ffs_aio_cancel+0x24/0x34
__arm64_sys_io_cancel+0xb0/0x124
do_el0_svc+0x68/0x100
el0_svc+0x18/0x5c
el0t_64_sync_handler+0x98/0xdc
el0t_64_sync+0x154/0x158
Assisted-by: opencode:openai/gpt-5.5
Cc: stable <stable@kernel.org>
Fixes: b6a0ca111867 ("usbip: vudc: Add UDC specific ops")
Reviewed-by: Igor Kotrasinski <i.kotrasinsk@samsung.com>
Signed-off-by: Sam Day <me@samcday.com>
Link: https://patch.msgid.link/20260626-usbip-vudc-deque-fix-v3-1-98c2dc4d6a48@samcday.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
USB devices running at SuperSpeedPlus report "10000" or "20000" in
their sysfs speed attribute. usbip currently maps only "5000" to
USB_SPEED_SUPER, so a SuperSpeedPlus device is imported as
USB_SPEED_UNKNOWN.
The attach request is then rejected by vhci_hcd:
vhci_hcd: Failed attach request for unsupported USB speed: UNKNOWN
Map the SuperSpeedPlus sysfs speed values to USB_SPEED_SUPER_PLUS, use
the SuperSpeed VHCI hub for SuperSpeedPlus devices, and recognize the
gadget current_speed string used by the kernel.
Fixes: b2316645ca5e ("usb: show speed "10000" in sysfs for USB 3.1 SuperSpeedPlus devices")
Cc: stable <stable@kernel.org>
Signed-off-by: Yichong Chen <chenyichong@uniontech.com>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://patch.msgid.link/00C828F338E43447+20260617020613.199086-1-chenyichong@uniontech.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
In the UCSI Specification Revision 3.1 RC1, bits 32-63 of the SET_NEW_CAM
command hold the 32-bit Alternate Mode Specific (AMSpecific) field.
For DisplayPort Alternate Mode, this field must contain the full
32-bit DisplayPort configuration VDO payload that the OPM wants the
connector to operate in, rather than just the pin assignment value.
This AMSpecific value follows the DisplayPort Configurations defined
in the DisplayPort Alt Mode on USB Type-C Specification v2.1a,
Table 5-13: SOP DisplayPort Configurations.
Fixes: af8622f6a585 ("usb: typec: ucsi: Support for DisplayPort alt mode")
Cc: stable <stable@kernel.org>
Signed-off-by: Madhu M <madhu.m@intel.com>
Reviewed-by: Jameson Thies <jthies@google.com>
Reviewed-by: Andrei Kuchynski <akuchynski@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260619153311.3526083-1-madhu.m@intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Ravi Hothi <ravi.hothi@oss.qualcomm.com> says:
This series adds audio support for the Qualcomm Eliza SoC. Eliza uses
the same LPASS macro codec hardware as SM8550, so the existing SM8550
fallback compatible is reused for all four macro codecs (RX, TX, VA,
WSA). The sound card is compatible with the SM8450 generation machine
driver.
Patch 1 documents the Eliza LPASS macro codec compatibles in the
dt-bindings for RX, TX, VA and WSA macros.
Patch 2 documents the Eliza sound card compatible.
Patch 3 adds the Eliza sound card entry to the machine driver.
Link: https://patch.msgid.link/20260703073434.2589657-1-ravi.hothi@oss.qualcomm.com
|
|
Add compatible for sound card on Qualcomm Eliza boards.
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Link: https://patch.msgid.link/20260703073434.2589657-4-ravi.hothi@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add bindings for Eliza sound card, which is compatible with
the existing SM8450.
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260703073434.2589657-3-ravi.hothi@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add bindings for Qualcomm Eliza LPASS RX, TX, VA and WSA macro codecs,
which are compatible with the existing SM8550 generation.
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Link: https://patch.msgid.link/20260703073434.2589657-2-ravi.hothi@oss.qualcomm.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The bytes_sent and bytes_rcvd members of structs asyncppp and syncppp
are not used. Drop them.
Signed-off-by: Jiri Slaby (SUSE) <jirislaby@kernel.org>
Cc: Andrew Lunn <andrew+netdev@lunn.ch>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Jakub Kicinski <kuba@kernel.org>
Cc: Paolo Abeni <pabeni@redhat.com>
Link: https://patch.msgid.link/20260702060420.95023-1-jirislaby@kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The per-error decode in tegra30_mc_handle_irq() dereferences
mc->soc->regs unconditionally. This 'regs' structure is optional and is
only used for decoding and logging MC error interrupts. The rest of the
MC functionality does not depend on it.
When adding support for the Tegra238 SoC, the 'regs' structure was
initially omitted because it is only used for error logging. We found
that this resulted in a NULL pointer dereference in IRQ context, causing
a crash when an MC error interrupt fired. Although existing upstream
devices will not hit this condition because 'regs' is present, guard
against it to improve the robustness of the driver.
Skip the decode and just clear the interrupt when mc_regs is NULL. This
bypasses the error interrupt logging while keeping the remaining MC
functionality intact.
Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Link: https://patch.msgid.link/20260703045653.395498-1-amhetre@nvidia.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Add support for representing each memory-controller instance (one
per NUMA node / socket) as its own interconnect (ICC) provider,
with its own MC client nodes, to match the hardware topology on
multi-socket Tegra SoCs.
Use the NUMA node ID to make client IDs globally unique across
per-socket providers, since the ICC framework allocates node IDs
from a single global IDR. Per-socket MC and EMC node names are
also derived from dev_name() so they match the corresponding
debugfs subdirectory. On single-socket platforms (NUMA_NO_NODE)
the existing client IDs and node-name strings are preserved.
Each socket's MC and EMC therefore get their own debugfs
subdirectory under /sys/kernel/debug/{mc,emc}/. The parent
directories are created on first probe.
Bandwidth requests from MC clients in a socket are routed to
that socket's local BPMP.
Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/20260626131423.3986998-1-sumitg@nvidia.com
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
|
|
Backmerging to get updates from v7.2-rc2 into drm-misc-next.
Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
|
|
ipu7_resume() calls pm_runtime_get_sync() before resuming the device.
If the runtime PM resume fails, the usage count remains incremented, but
the error path returns without dropping the reference.
Use pm_runtime_resume_and_get() instead, which balances the usage count
on failure and avoids the leak. Keep returning 0 on error, as resume
callbacks should not propagate failures to the PM core, matching the
behaviour of the ipu6 driver.
Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver")
Signed-off-by: Vidhu Sarwal <vidhu.linux@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
ipu7_init_fw_code_region_by_sys()
ipu7_init_fw_code_region_by_sys() calls pm_runtime_get_sync() before
accessing the firmware code region. If resuming the device fails,
pm_runtime_get_sync() leaves the runtime PM usage count incremented,
but the error path returns without dropping the reference.
Use pm_runtime_resume_and_get() instead, which balances the usage count
automatically on failure and avoids the leak.
The ipu6 driver uses pm_runtime_resume_and_get() in the equivalent
location.
Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver")
Signed-off-by: Vidhu Sarwal <vidhu.linux@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
alvium_set_ctrl_auto_exposure
Write value for auto-exposure into correct register REG_BCRM_EXPOSURE_AUTO_RW
instead of wrong register REG_BCRM_WHITE_BALANCE_AUTO_RW.
Fixes: 0a7af872915e ("media: i2c: Add support for alvium camera")
Cc: stable@vger.kernel.org
Signed-off-by: Martin Hecht <mhecht73@gmail.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
The IBP project is an DFI platform with a fixed audio
configuration consisting of headset(headphone and mic-in).
The audio routing and pin assignments are defined according to
the board-level hardware design and are not intended to be
dynamically changed.
Signed-off-by: Leo Tsai <antivirus621@gmail.com>
Link: https://patch.msgid.link/20260708035552.44429-1-antivirus621@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
snd_ctl_open() unconditionally overwrites the return value of
snd_card_file_add() with -ENODEV on failure, discarding the actual
error code.
Fix this by directly returning the original error code returned by
snd_card_file_add() (e.g. -ENOMEM or -ENODEV). This behavior is
consistent with the error handling used in other functions such as
snd_mixer_oss_open(), snd_hwdep_open(), snd_pcm_oss_open(), and others.
There is no functional change other than the returned error code in this
failure path.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260708023540.6962-1-phucduc.bui@gmail.com
|
|
The HP Laptop 15-fd0xxx uses GPIO bit 0 to control the mic mute LED,
but currently the quirk only enables the speaker mute LED (via coef
bit). Switch to the existing ALC236_FIXUP_HP_MUTE_LED_MICMUTE_GPIO
fixup which additionally registers a GPIO-based mic mute LED, mapping
to the same verbs (SET_GPIO_DATA/SET_GPIO_DIRECTION bit 0) that the
platform firmware uses.
Signed-off-by: Kshamendra Kumar Mishra <kshamendrakumarmishra@gmail.com>
Link: https://patch.msgid.link/DJSOWKFBTJH8.2Z7EPWX514QXM@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add INTC10FA to the CVS ACPI match table so the driver can bind to
CVS devices exposed on NVL platforms.
Signed-off-by: Arun T <arun.t@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Add the NVL IPU8 PCI device ID to the CVS driver match table so the
CVS driver can bind to IPU8 camera hardware.
Signed-off-by: Arun T <arun.t@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Add INTC10FA to the IPU bridge ACPI match table so the bridge can
recognize NVL CVS devices.
This enables the camera bridge path to bind on NVL platforms where the
CVS device is exposed through the INTC10FA ACPI ID.
Signed-off-by: Arun T <arun.t@intel.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Add INTC10FA to the ACPI dependency honor list so the CVS driver is
loaded before dependent camera devices are probed on NVL platforms.
This matches the camera dependency handling already used for IVSC-based
platforms and ensures the camera streaming path is initialized before
sensor access or pipeline setup depends on it.
Signed-off-by: Arun T <arun.t@intel.com>
Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
When try_module_get() fails in snd_pcm_open(), the owning module is going
away and the device is no longer usable, so -EFAULT ("bad address") is the
wrong error. Return -ENODEV, matching the other unavailable-device paths
in this function(the NULL pcm check and the card->shutdown check).
This changes the errno reported to userspace on this rare race.
No other behaviour changes.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260707084506.718583-7-phucduc.bui@gmail.com
|
|
When try_module_get() fails in snd_pcm_oss_open(), the owning module is
going away and the device is no longer usable, so -EFAULT ("bad address")
is the wrong error. Return -ENODEV, matching the other unavailable-device
paths in this function(the NULL pcm check and the card->shutdown check).
This changes the errno reported to userspace on this rare race.
No other behaviour changes.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260707084506.718583-6-phucduc.bui@gmail.com
|
|
When try_module_get() fails in snd_mixer_oss_open(), the owning module is
going away and the device is no longer usable, so -EFAULT ("bad address")
is the wrong error. Return -ENODEV, matching the other unavailable-device
paths in this function(the NULL card check and the NULL mixer_oss check).
This changes the errno reported to userspace on this rare race.
No other behaviour changes.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260707084506.718583-5-phucduc.bui@gmail.com
|
|
When try_module_get() fails in alloc_info_private(), the owning module is
going away and the device is no longer usable, so -EFAULT ("bad address")
is the wrong error. Return -ENODEV, matching the other -ENODEV path in the
same function.
This changes the errno reported to userspace on this rare race.
No other behaviour changes.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260707084506.718583-4-phucduc.bui@gmail.com
|
|
When try_module_get() fails in snd_hwdep_open(), the owning module is
going away and the device is no longer usable, so -EFAULT ("bad address")
is the wrong error. Return -ENODEV, matching the other unavailable-device
paths in this function(the NULL hw check and the card->shutdown check).
This changes the errno reported to userspace on this rare race.
No other behaviour changes.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260707084506.718583-3-phucduc.bui@gmail.com
|
|
When try_module_get() fails in snd_ctl_open(), the owning module is going
away and the device is no longer usable, so -EFAULT ("bad address") is the
wrong error. Return -ENODEV, matching the other unavailable-device paths
in this function(the NULL card check and the snd_card_file_add() failure).
This changes the errno reported to userspace on this rare race.
No other behaviour changes.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260707084506.718583-2-phucduc.bui@gmail.com
|
|
On Nova Lake A/B steppings the GOP breaks DP-Alt / native DP output
when TRANS_VTOTAL.Vtotal is programmed with a non-zero value, and the
initial hardware readout of that field on such systems ends up in
adjusted_mode.crtc_vtotal = 1 -- tripping the DSB scanline WARN in
assert_dsl_ok() during intel_initial_commit.
Keep TRANS_VTOTAL.Vtotal at 0 on Nova Lake pre-C0 (A0..B3) in both
transcoder timing paths, and restore adjusted_mode.crtc_vtotal from
TRANS_VRR_VMIN in intel_vrr_get_config() so downstream state stays
consistent.
Fixes: f26a8df8dff9 ("drm/i915/display: Program TRANS_VTOTAL from mode vtotal")
Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com>
Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com>
Link: https://patch.msgid.link/20260703032653.2122784-1-suraj.kandpal@intel.com
|
|
The mute LED on HP Victus 15-fa0xxx (board ID 8A50) uses ALC245 but
requires a quirk to work. This patch enables the existing
ALC245_FIXUP_HP_MUTE_LED_COEFBIT quirk for the device.
Tested on my HP Victus 15-fa0xxx. The LED behaviour works as intended.
Signed-off-by: Rohit Sinha <rohitsinha12043@gmail.com>
Link: https://patch.msgid.link/20260706211834.384022-1-rohitsinha12043@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The device with USB ID 040b:0897 (Weltrend Semiconductor chipset,
sold rebranded as the Redragon H510-PRO Wireless headset, reporting
"XiiSound Technology Corporation" in its USB string descriptors)
reports a constant value on GET_CUR for its PCM Playback Volume
control while still supporting an actually tunable volume. This
trips the sticky-value detection in check_sticky_volume_control(),
which disables the mixer control entirely:
usb 1-4: 5:0: sticky mixer values (0/100/1 => 80), disabling
As a result, the device boots with playback volume effectively muted
and provides no way to raise it through the normal ALSA/PipeWire
mixer path.
Apply QUIRK_FLAG_MIXER_GET_CUR_BROKEN so the sticky check marks the
control as get_cur_broken and relies on the cached value instead of
disabling the mixer control outright.
Tested by backporting this quirk flag and the supporting
get_cur_broken logic onto a Linux 7.1.2-zen kernel build that does
not yet carry it, and confirming that after applying the flag the
kernel log changes from
usb 1-4: 5:0: sticky mixer values (0/100/1 => 80), disabling
to
usb 1-4: 5:0: broken mixer GET_CUR (0/100/1 => 80)
with the control usable via the driver's cached value afterward.
Signed-off-by: Agustin Luzardo <agustinluzardo09@gmail.com>
Link: https://patch.msgid.link/20260705184227.113588-1-agustinluzardo09@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Branch Sampling (BRS) and Last Branch Record (LBR) are mutually
exclusive hardware features, and users of both are tracked via
cpuc->lbr_users.
When SVM is toggled on a CPU, the host perf events are reprogrammed to
update the HostOnly filter bit (set when virtualization is enabled,
cleared when it is disabled). On PerfMonV2-capable processors, this
reprogramming is performed by calling amd_pmu_enable_all() to rewrite
the event selectors. However, amd_pmu_enable_all() also calls
amd_brs_enable_all(), which enables BRS whenever cpuc->lbr_users > 0.
Having active LBR events satisfies this gating on processors that have
LBR but not BRS. The kernel then tries to set the BRS enable bit in
DebugExtnCfg (MSR 0xc000010f). Since that bit is deprecated on such
hardware, the write results in a #GP:
Call Trace:
<IRQ>
amd_pmu_enable_all+0x1d/0x90
amd_pmu_disable_virt+0x62/0xb0
kvm_arch_disable_virtualization_cpu+0xa/0x40 [kvm]
hardware_disable_nolock+0x1a/0x30 [kvm]
__flush_smp_call_function_queue+0x9b/0x410
__sysvec_call_function+0x18/0xc0
sysvec_call_function+0x69/0x90
</IRQ>
<TASK>
asm_sysvec_call_function+0x16/0x20
RIP: 0010:cpuidle_enter_state+0xc4/0x450
? cpuidle_enter_state+0xb7/0x450
cpuidle_enter+0x29/0x40
cpuidle_idle_call+0xf5/0x160
do_idle+0x7b/0xe0
cpu_startup_entry+0x26/0x30
start_secondary+0x115/0x140
secondary_startup_64_no_verify+0x194/0x19b
</TASK>
Fix this by ensuring that BRS is not enabled from the event selector
reprogramming path even when cpuc->lbr_users > 0.
Fixes: bae19fdd7e9e ("perf/x86/amd/core: Fix reloading events for SVM")
Signed-off-by: Sandipan Das <sandipan.das@amd.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: https://patch.msgid.link/702fa204d574b03d14e3664c7d4b201db048bbfd.1783506528.git.sandipan.das@amd.com
|
|
Nimrod Oren says:
====================
selftests: drv-net: run XDP tests with both IP versions
The driver selftest environment picks a single address family for tests
which use the generic address fields. When both IPv4 and IPv6 are
available it prefers IPv6, which can leave IPv4 paths untested and hide
IPv4-only bugs.
This happened recently in the XDP selftest, where an IPv4 checksum bug
was missed when IPv6 was also configured. XDP traffic handling has
IP-version-specific code paths, and the follow-up discussion concluded
that the XDP tests should run against both IP versions [1].
This series changes NetDrvEpEnv from exposing only the initially selected
address family to allowing tests to switch the generic address fields
between IP versions. xdp.py uses this to run the XDP traffic cases over
both IPv4 and IPv6. Test variants whose required IP version is not
configured are skipped.
[1] https://lore.kernel.org/20260518143138.74839bf9@kernel.org/
====================
Link: https://patch.msgid.link/20260702062348.2123960-1-noren@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Parameterize test cases by IP version using @ksft_variants. Set the
environment's IP version at the start of each case using a new local
helper, which also handles restoring the original value via defer().
The last case is left unparameterized because it does not send traffic
or exercise IP-version-specific code.
While here, fix an int vs str comparison bug `if cfg.addr_ipver == 4`.
Suggested-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Nimrod Oren <noren@nvidia.com>
Link: https://patch.msgid.link/20260702062348.2123960-3-noren@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
NetDrvEpEnv picks a single IP version at init time, preferring IPv6 when
both are configured.
Add NetDrvEpEnv.set_ipver() to reselect the IP version and recompute the
derived address fields.
Reviewed-by: Carolina Jubran <cjubran@nvidia.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Nimrod Oren <noren@nvidia.com>
Link: https://patch.msgid.link/20260702062348.2123960-2-noren@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The snd-aloop driver currently defaults to using the system jiffies
timer (struct timer_list). On systems configured with a low timer
interrupt frequency (e.g., CONFIG_HZ=250), the jiffies resolution
(4ms per tick) is insufficient for precise audio timing. For
example, a 10ms audio period requires 2.5 jiffies ticks, causing
timing jitter that leads to capture underruns.
Introduce "hrtimer" as a supported timer_source option. When
timer_source="hrtimer" is set, aloop uses high-resolution timers
(hrtimer) to drive period updates. This provides nanosecond-level
accuracy regardless of CONFIG_HZ and operates independently of other
hardware audio cards.
Signed-off-by: Yu-Hsuan Hsu <yuhsuan@chromium.org>
Link: https://patch.msgid.link/20260705125941.1203871-1-yuhsuan@chromium.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Currently, configuring a VF MAC address via the PF (e.g., 'ip link
set <pf> vf 0 mac <mac>') blindly attempts to install a DMAC-based
hardware filter. However, the hardware parser profile might not
support DMAC extraction.
Check if the hardware parsing profile supports DMAC extraction
before adding the filter. Additionally, emit a warning message
to inform the operator if the MAC filter installation fails due
to missing DMAC extraction support. Update config->mac only
after hardware programming succeeds in otx2_set_vf_mac().
Fixes: f0c2982aaf98 ("octeontx2-pf: Add support for SR-IOV management functions")
Signed-off-by: Suman Ghosh <sumang@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>
Link: https://patch.msgid.link/20260702033451.2969880-1-nshettyj@marvell.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
CAKE accepts signed overhead values and stores them in an s16, but the
adjusted packet length calculation uses unsigned arithmetic. A negative
effective length can therefore wrap to a large value.
Such configurations make rate accounting depend on integer wraparound
rather than on the packet size userspace intended to model. A static
netlink lower bound is not enough because packets reaching CAKE can be
smaller than any reasonable manual-overhead allowance.
Fold the signed overhead adjustment into the existing datapath MPU clamp
so negative adjusted lengths are clamped before link-layer framing
adjustments.
Fixes: a729b7f0bd5b ("sch_cake: Add overhead compensation support to the rate shaper")
Assisted-by: Codex:gpt-5.5-cyber-preview
Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
Acked-by: Toke Høiland-Jørgensen <toke@toke.dk>
Link: https://patch.msgid.link/20260702000758.297407.e5c888d9d99d.cake-overhead-underflow@trailofbits.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
'devlink-extend-phys_port_name-controller-prefix-to-non-external-ports'
Tariq Toukan says:
====================
devlink: extend phys_port_name controller prefix to non-external ports
This series by Moshe includes the controller number in phys_port_name
for non-external ports with a non-zero controller, and updates the mlx5
driver to mark satellite PFs as non-external.
The controller prefix (c) in phys_port_name was previously only included
for ports marked as external. However, newer devices can have multiple
controllers within the DPU itself, even within a single host
environment. For example, a SmartNIC may have additional local PCI
physical functions that are managed by the eswitch but are not on an
external host. These ports use a non-zero controller number to
distinguish them from the eswitch manager's own functions, while the
external flag remains unset.
Patch 1 updates the devlink core to include the controller prefix in
phys_port_name for any non-zero controller, regardless of the external
flag. Documentation and kdoc are updated accordingly.
Patch 2 updates the mlx5 driver to set satellite PF devlink ports as
non-external, since they are local to the DPU. It also distinguishes
satellite PF SFs from host PF SFs when setting the external attribute.
====================
Link: https://patch.msgid.link/20260702111726.816985-1-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Satellite PFs are local to the DPU and are not on an external host.
Set their devlink port external attribute to false to reflect this.
For satellite PF SFs, distinguish them from host PF SFs by comparing
the SF controller number against the host PF controller
(hpf_host_number + 1). Only SFs whose controller matches the host PF
are marked external, since their PF resides on an external host.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Reviewed-by: Shay Drori <shayd@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260702111726.816985-3-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
The controller prefix (c<N>) in phys_port_name is currently restricted
to external host controllers. This layout sufficed when DPUs only had a
single local controller and one or more external host controllers.
However, newer devices can have multiple controllers within the DPU
itself, even within a single host environment. To support these
topologies, allow drivers to report the controller number regardless of
the "external" flag status. Any non-zero controller number will now be
explicitly reported, even for single-host or local DPU controllers.
Existing ports with controller=0 are unaffected.
Update documentation and kdoc to clarify that a non-zero controller
number does not require the external flag to be set.
Signed-off-by: Moshe Shemesh <moshe@nvidia.com>
Reviewed-by: Parav Pandit <parav@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20260702111726.816985-2-tariqt@nvidia.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Add a new driver for Sony imx471 camera sensor. It is based on
Jimmy Su <jimmy.su@intel.com> implementation and the driver can be found
in the following URL.
https://github.com/intel/ipu6-drivers/commits/master/drivers/media/i2c/imx471.c
This sensor can be found on Lenovo X1 Carbon G14, X9-14 and X9-15 laptops
and it is a part of IPU7 solution. The driver was tested on Lenovo X1
Carbon G14, X9-14 and X9-15 laptops.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Tested-by: computman <anis@talbi.fr>
Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
|
Update the con_id for the Sony IMX471 sensor to "vana" to serve as the
power enable. Additionally, the HID values SONY471A and TBE20A0, both
associated with the IMX471 image sensor, have been identified on Lenovo
laptops.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
Reviewed-by: Tarang Raval <tarang.raval@siliconsignals.io>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
|
