| 5e957175 | 24-Jun-2025 |
Pei Xiao <xiaopei01@kylinos.cn> |
ALSA: usb: qcom: fix NULL pointer dereference in qmi_stop_session
The find_substream() call may return NULL, but the error path
dereferenced 'subs' unconditionally via dev_err(&subs->dev->dev, ...),
ALSA: usb: qcom: fix NULL pointer dereference in qmi_stop_session
The find_substream() call may return NULL, but the error path
dereferenced 'subs' unconditionally via dev_err(&subs->dev->dev, ...),
causing a NULL pointer dereference when subs is NULL.
Fix by switching to &uadev[idx].udev->dev which is always valid
in this context.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
Link: https://patch.msgid.link/86ac2939273ac853535049e60391c09d7688714e.1750755508.git.xiaopei01@kylinos.cn
Signed-off-by: Takashi Iwai <tiwai@suse.de>
show more ...
|
| 3335a1bb | 13-May-2025 |
Arnd Bergmann <arnd@arndb.de> |
ALSA: qc_audio_offload: try to reduce address space confusion
uaudio_transfer_buffer_setup() allocates a buffer for the subs->dev
device, and the returned address for the buffer is a CPU local virtu
ALSA: qc_audio_offload: try to reduce address space confusion
uaudio_transfer_buffer_setup() allocates a buffer for the subs->dev
device, and the returned address for the buffer is a CPU local virtual
address that may or may not be in the linear mapping, as well as a DMA
address token that is accessible by the USB device, and this in turn
may or may not correspond to the physical address.
The use in the driver however assumes that these addresses are the
linear map and the CPU physical address, respectively. Both are
nonportable here, but in the end only the virtual address gets
used by converting it to a physical address that gets mapped into
a second iommu.
Make this more explicit by pulling the conversion out first
and warning if it is not part of the linear map, and using the
actual physical address to map into the iommu in place of the
dma address that may already be iommu-mapped into the usb host.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250513123442.159936-4-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 5c7ef500 | 13-May-2025 |
Arnd Bergmann <arnd@arndb.de> |
ALSA: qc_audio_offload: avoid leaking xfer_buf allocation
The info->xfer_buf_cpu member is set to a NULL value because the
allocation happens in a different function and is only assigned
to the func
ALSA: qc_audio_offload: avoid leaking xfer_buf allocation
The info->xfer_buf_cpu member is set to a NULL value because the
allocation happens in a different function and is only assigned
to the function argument but never passed back.
Pass it by reference instead to have a handle that can actually be
freed by the final usb_free_coherent() call.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250513123442.159936-3-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
| 485ae085 | 13-May-2025 |
Arnd Bergmann <arnd@arndb.de> |
ALSA: qc_audio_offload: rename dma/iova/va/cpu/phys variables
While trying to understand a bug in the audio offload code, I had
to spend extra time due to unfortunate nameing of local variables
and
ALSA: qc_audio_offload: rename dma/iova/va/cpu/phys variables
While trying to understand a bug in the audio offload code, I had
to spend extra time due to unfortunate nameing of local variables
and struct members.
Change these to more conventional names that reflect the actual
usage:
- pointers to the CPU virtual addresses of a dma buffer get a
_cpu suffix to disambiguate them for MMIO virtual addresses
- MMIO virtual addresses that are mapped explicitly through
the IOMMU get a _iova suffix consistently, rather than a
mix of iova and va.
- DMA addresses (dma_addr_t) that are in a device address
space (linear or IOMMU) get a _dma suffix in place of the
_pa suffix.
- CPU physical (phys_addr_t) addresses get a _pa suffix.
There is still a mixup with dma addresses here that I address
in another patch.
No functional changes are intended here.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20250513123442.159936-2-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|