| Age | Commit message (Collapse) | Author |
|---|
|
On resume, the UCSI driver will re-enable notifications by sending
SET_NOTIFICATION_ENABLE. The LPM/PPM may be busy during system
resume causing SET_NOTIFICATION_ENABLE to fail and preventing the UCSI
driver from receiving connection status changes.
Change resume work to a delayed workqueue to allow retries on failed
SET_NOTIFICATION_ENABLED commands. Additionally, cancel resume work
on suspend to prevent pending resume commands from impacting suspend.
Signed-off-by: Jameson Thies <jthies@google.com>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Acked-by: Marco Crivellari <marco.crivellari@suse.com>
Link: https://patch.msgid.link/20260904234124.2336922-1-jthies@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
struct ubsmon_packet does not exist; the name is struct usbmon_packet.
Use struct usbmon_packet.
Fixes: 6f23ee1fefdc ("USB: add binary API to usbmon")
Assisted-by: LLM
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260905075609.32879-1-kmehltretter@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
MEDIA_INFO(us).lba_to_pba and .pba_to_lba are arrays of num_zones
pointers, allocated by kcalloc() in alauda_init_media().
alauda_ensure_map_for_zone() reads lba_to_pba[zone] and
pba_to_lba[zone], and when either is NULL alauda_read_map() writes a
pointer back to both. Two separate errors let zone reach num_zones, one
element past the end.
max_lba is capacity >> (blockshift + pageshift), which counts physical
blocks, but zone is lba / uzonesize and uzonesize is 125/128 of
zonesize. On a 16 MB card (alauda_card_ids id 0x73) num_zones is 1 and
uzonesize is 1000, so lba 1000 to 1023 pass the bounds check and index
element 1 of a one-element array.
alauda_read_data() also calls alauda_ensure_map_for_zone() before it
compares lba against max_lba, so any larger lba is used as an index
before the check rejects it. alauda_write_data() already checks first.
Bound lba by num_zones * uzonesize on both paths and move the read
side's call below the check. alauda_transport() reports
num_zones * uzonesize * blocksize for READ_CAPACITY, so the new bound is
exactly the range the device advertises and no block becomes
unreachable.
sd never issues an lba past the reported capacity; an SG_IO READ_10 can.
Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support")
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Arka Mondal <arka@arkamondal.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260901065831.43567-4-arka@arkamondal.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
alauda_ensure_map_for_zone() ignores the value alauda_read_map()
returns. On failure lba_to_pba[zone] and pba_to_lba[zone] are left NULL,
and both callers dereference them immediately:
pba = MEDIA_INFO(us).lba_to_pba[zone][lba_offset];
alauda_read_map() returns USB_STOR_TRANSPORT_ERROR when either kcalloc()
fails or an alauda_get_redu_data() transfer fails, so one failed bulk
transfer is enough to reach the NULL dereference.
Return that value from alauda_ensure_map_for_zone() and check it in
alauda_read_data() and alauda_write_lba().
Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217862
Signed-off-by: Arka Mondal <arka@arkamondal.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260901065831.43567-3-arka@arkamondal.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
alauda_check_status2(), alauda_get_redu_data(), alauda_erase_block(),
alauda_read_block_raw() and alauda_write_block() build their commands in
stack arrays and pass them to usb_stor_bulk_transfer_buf().
alauda_check_status2() and alauda_erase_block() also read the reply back
into a stack array.
usb_stor_msg_common() sets URB_NO_TRANSFER_DMA_MAP only when the buffer
is us->iobuf. Every other buffer reaches usb_hcd_map_urb_for_dma(),
which has warned and returned -EAGAIN for a buffer on the stack since
commit 4568136620c6 ("usb: core: Check URB setup_packet and
transfer_buffer sanity"). On a host controller that uses DMA, all of
these commands fail.
Use us->iobuf, as alauda_reset_media() in this driver and the other
usb-storage subdrivers already do. The command is sent before the reply
is read, so both can use it; sddr09_read_status() does the same.
Fixes: e80b0fade09e ("[PATCH] USB Storage: add alauda support")
Link: https://bugzilla.kernel.org/show_bug.cgi?id=217862
Signed-off-by: Arka Mondal <arka@arkamondal.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260901065831.43567-2-arka@arkamondal.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert the TI DA8xx/OMAP-L1x MUSB text bindings to DT schema. Since
DA8xx MUSB node acts as a parent bus for the CPPI41 DMA controller add
required #address-cells, #size-cells, and ranges properties.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Link: https://patch.msgid.link/20260901-ti-am33-usb-v3-6-5e15c617d2e9@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert the TI AM33xx USB Wrapper text binding to DT schema.
Changes during conversion:
- Drop the USB control module from child nodes, as it physically resides
within the System Control Module address space, not the USB wrapper.
- Allow standard phy@[0-9a-f]+$ child node names alongside the legacy
usb-phy@[0-9a-f]+$.
- Mark the legacy ti,hwmods property as deprecated.
- Document required #address-cells, #size-cells, and ranges property
missing from text binding.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Link: https://patch.msgid.link/20260901-ti-am33-usb-v3-5-5e15c617d2e9@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert the TI AM335x USB Control Module text bindings to DT schema. No
functional changes.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Link: https://patch.msgid.link/20260901-ti-am33-usb-v3-4-5e15c617d2e9@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert the TI AM33xx MUSB text bindings to DT schema.
Changes during conversion:
- Allow an optional vbus interrupt used in am335x-bone-common.
- Add the interface-type and phy-names properties natively used by the
dm816x hardware.
- Allow 0 or 1 for mentor,multipoint. While the text binding mandated 1,
the Mentor USB IP natively supports both single and multipoint
configurations as used in existing DTS.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Link: https://patch.msgid.link/20260901-ti-am33-usb-v3-3-5e15c617d2e9@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert the TI AM335x USB PHY text bindings to DT schema.
Add undocumented vcc-supply property to match existing DTS usage.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Link: https://patch.msgid.link/20260901-ti-am33-usb-v3-2-5e15c617d2e9@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert TI CPPI 4.1 DMA controller text bindings to DT schema. Add
ti,am3359-cppi41 and ti,da830-cppi41 into single schema since they share
the same hardware IP block and driver. Add undocumented #dma-requests
and power-domains properties to match existing DTS usage.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Link: https://patch.msgid.link/20260901-ti-am33-usb-v3-1-5e15c617d2e9@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
On some platforms the PPM is not ready to answer commands correctly
for a short window during boot. On the Lenovo ThinkPad X1 Carbon
Gen 14 (21V7, tested on BIOS 1.12 and 1.14) roughly half of all boots
fail ucsi_init() with either -ENODEV (GET_CAPABILITY completes but
reports zero connectors) or -EINVAL (a standard command is rejected,
logged as "possible UCSI driver bug"). The failure is not a timeout:
increasing the sync command completion wait does not change the rate.
Since ucsi_init_work() only requeues on -EPROBE_DEFER, a single bad
answer during that window leaves UCSI dead for the whole session, so
Type-C events are never handled again; most visibly, the machine
silently never resumes charging after the charger is replugged.
Manually reloading ucsi_acpi a few seconds later has succeeded on
every attempt observed, which suggests simply retrying is enough.
Retry -ENODEV and -EINVAL the same way as the role switch wait, log
the retries at debug level, keep the loud report for the case where
the retries are exhausted, and note when init only succeeded after
retrying.
Tested on the affected machine: across 8 consecutive boots with this
patch, 5 hit the failure (matching the historical ~50-60% rate) and
all 5 recovered on the first retry ("PPM init succeeded after 2
attempts"). 0 of 8 boots ended with UCSI unusable, where ~5 of 8
would have without the patch.
Signed-off-by: Jacob Riff <jacob@riff.dk>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260824173536.2395830-1-jacob@riff.dk
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
sddr09_read_map() builds the LBA <-> PBA translation tables while
servicing READ_CAPACITY. The logical block address assigned to each
physical block is decoded from device-controlled redundancy data:
lba = short_pack(ptr[7], ptr[6]); /* 16-bit device value */
lba = (lba & 0x07FF) >> 1; /* 0..1023 */
if (lba >= 1000)
goto possibly_erase;
lba += 1000*(i/0x400);
if (info->lba_to_pba[lba] != UNDEF) /* heap OOB read */
...
info->pba_to_lba[i] = lba;
info->lba_to_pba[lba] = i; /* heap OOB write */
The tables are allocated with numblocks entries each, where numblocks
is derived from the device-reported NAND chip geometry. For the
smallest chip in nand_flash_ids[] (1 MB: chipshift=20, pageshift=8,
blockshift=4):
numblocks = (1 << 20) >> (8 + 4) = 256
so info->lba_to_pba[] only has indexes 0..255, while a hostile device
may report any LBA up to 999 - the "lba >= 1000" check is the only
limit on the value, and there is no check that lba < numblocks. On a
1 MB card indexes 256..999 (744 of them) index the table out of
bounds, up to ~3 KB (744 * 4 bytes) past the end of the allocation.
Attack chain (malicious USB storage device):
1. An attacker presents a USB Mass Storage device spoofing a unit
matched in sddr09_usb_ids, e.g. 0x04e6:0x0003 (SanDisk
ImageMate SDDR09) or 0x0781:0x0200, on the victim USB bus; the
device is enumerated as a normal storage device.
2. ums-sddr09 binds (sddr09_probe -> us->transport =
sddr09_transport) and the SCSI layer issues READ_CAPACITY, which
is handled via sddr09_get_cardinfo() (chip geometry from the
device ID, choosing numblocks) and sddr09_read_map().
3. The device reports a 1 MB chip (numblocks = 256) and fills the
per-block redundancy data with LBA values in the 256..999 range,
driving info->lba_to_pba[lba] and info->pba_to_lba[i] accesses
out of bounds: a heap OOB read used in the map-building
conditionals plus a heap OOB write of the loop index i (the
physical block number, 0..255) at an offset the attacker controls
via the reported LBA, corrupting adjacent heap memory.
The device-controlled inputs, the missing bound check and the OOB
indexing are confirmed by end-to-end reproduction with a FunctionFS
based malicious device emulator; the driver logged out-of-bounds
indexes such as:
sddr09: LBA 256 seen for PBA -858993460 and 201
sddr09: LBA 258 seen for PBA 4513 and 203
Add the missing bounds check: since lba is unsigned it can only be
too large, so bail out with "lba >= numblocks" and mark the physical
block UNUSABLE instead of indexing the tables. This mirrors the
max_lba bounds checks already applied to the SCSI-address-derived LBA
in sddr09_read_data()/sddr09_write_data() and in the related sddr55
and alauda drivers.
Signed-off-by: Haofeng Li <lihaofeng@kylinos.cn>
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Assisted-by: opencode:deepseek-v4-flash-free
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260821180116.3490884-1-lihaofeng@kylinos.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Storing that negative value into an unsigned variable makes the check
`if (lchan->irq < 0)` always false, so probe errors are not correctly
detected and propagated.
Fix this by changing the type of `irq` to `int`, which allows proper
signed comparison and error handling.
Fixes: 1c0028e725f1 ("dmaengine: loongson: New driver for the Loongson Multi-Channel DMA controller")
Reported-by: Julia Lawall <julia.lawall@inria.fr>
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/r/202608152230.p20WPlS0-lkp@intel.com/
Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Link: https://patch.msgid.link/20260818093448.3597016-1-zhoubinbin@loongson.cn
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
Using the DMA in cyclic mode modifies the hardware buffer descriptor
chain in xilinx_dma_prep_dma_cyclic so that the last descriptor used by
the cyclic transfer points back to the first descriptor, but it never
restores the original descriptor ring. This breaks using non-cyclic mode
after cyclic mode with an error like:
xilinx-vdma 86000000.dma: Channel 00000000354d5c8d has errors 100, cdr 6de40000 tdr 6de40400
The only way to get out of this error state is to rebuild the hardware
buffer descriptor ring by releasing and re-acquiring the channel.
Fix using non-cyclic mode after cyclic mode by always restoring the
original buffer descriptor ring in the same manner as it is set up by
xilinx_dma_alloc_chan_resources().
Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario")
Signed-off-by: Alex Bereza <alex@bereza.email>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-after-cyclic-mode-v1-1-1fe47e701d6c@bereza.email
Link: https://patch.msgid.link/20260818-fix-hw-buf-desc-after-cyclic-mode-v2-1-530ff44c6a81@bereza.email
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The MT7530 internal GE PHY advertises EEE by hardware default, but its
EEE support is defective: with EEE advertised, some link partners fail
to establish a stable link. On a 2-pair (4-wire) cable where both ends
advertise gigabit, 1000BASE-T training cannot succeed, and instead of
falling back to 100 Mbps the port loops, so no link or DHCP lease is
ever obtained. MediaTek confirms the hardware is the root cause (Landen
Chao, 2021): "EEE of the 10-year-old MT7530 internal gephy has many IOT
problems, so it is recommended to disable its EEE."
mtk_gephy_config_init() used to clear the EEE advertisement early, but
commit af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE
advertisement") removed that on the rationale that the DSA subdriver
already performs an early disable. That holds for MT7531, whose
mt7531_setup() clears MDIO_AN_EEE_ADV on each switch PHY, but not for
the MT7530 PHY: neither the MT7621 integrated switch nor the dedicated
MT7530 IC ever had such a loop, so removing it left those boards
without any working early EEE disable and the link flapping came back.
Since the broken hardware is the PHY, fix it in the PHY driver so it
covers all users of this PHY, integrated in a switch or standalone:
- clear MDIO_AN_EEE_ADV in probe(), as early as possible, before
anything can negotiate EEE with the link partner;
- clear it again in config_init() and call phy_disable_eee() there.
config_init() is what phy_init_hw() replays after a PHY reset, when
the register is back at its EEE-advertising hardware default, and
it runs after of_set_phy_eee_broken() in phy_probe(), so the
eee_disabled_modes mask survives and neither phylib nor userspace
can re-enable EEE. dp83867 disables broken EEE from config_init()
the same way.
Auto-negotiation then falls back to a stable 100 Mbps link instead of
looping at gigabit. Tested on ASUS RT-AX53U (MT7621): with a 2-pair
cable on the WAN port, a single clean 100 Mbps link comes up and a
DHCP lease is obtained, where the unpatched driver loops.
Fixes: af3b4b0e59de ("net: phy: mediatek-ge: do not disable EEE advertisement")
Suggested-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Vladislav Karmanov <vladislav.karmanov.dev@gmail.com>
Link: https://patch.msgid.link/20260908145213.3976508-1-vladislav.karmanov.dev@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
Devmem tcp tx doesn't work without zero-copy, however it's not currently
enforced if NETIF_F_SG isn't present. In this case, tcp_sendmsg_locked()
will try the copy path and try to copy data from an iovec which consists
of offsets into the dma-buf and would normally fail. Moreover,
d9c56501c72fd ("net: tcp: block mixing readable and unreadable frags")
relies on that and assumes that the devmem binding is present IFF we're
using the zero-copy path, which can be used to mix net-iov and pages in
a single skb, and break invariants. Let's reject devmem tx without
zero-copy.
Note, the parameter check the patch is modifying is too loose, we can
create an io_uring request with dmabuf_id and all ZC flags, but which
won't have the binding. We replace it with stricter validation.
Fixes: bd61848900bff ("net: devmem: Implement TX path")
Fixes: d9c56501c72fd ("net: tcp: block mixing readable and unreadable frags")
Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Reviewed-by: Mina Almasry <almasrymina@google.com>
Link: https://patch.msgid.link/fdc2478d8f21268d7078556409887d8e6ba0ad32.1788529053.git.asml.silence@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
|
|
for_each_pci_dev() holds a reference to the current device. The Intel
EHCI lookup breaks as soon as it finds a match, so the iterator does not
get a chance to drop that reference on its next iteration.
Release the reference before leaving the loop.
Fixes: 26b76798e050 ("Intel xhci: refactor EHCI/xHCI port switching")
Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260807024304.928708-1-dbgh9129@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When a function-like macro expands to an expression, that expression
doesn't need a semicolon after it. All uses have been verified to
have their own semicolons.
This was found using the following Coccinelle semantic patch:
@r@
identifier i : script:ocaml() { String.lowercase_ascii i = i };
expression e;
@@
*#define i(...) e;
Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
Reviewed-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20260801191002.1383835-1-Julia.Lawall@inria.fr
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When mon_bus_init() fails to allocate the mon_bus struct, it returns
without setting ubus->mon_bus, so mbus->mon_bus remains NULL.
mon_bus_add() intentionally ignores this failure because the USB core
does not require monitoring to be established for normal operation.
However, when the HCD is later removed, usb_remove_hcd() fires the
USB_BUS_REMOVE notifier which calls mon_bus_remove(), it dereferences
ubus->mon_bus without checking for NULL, causing a null-ptr deference.
Fix this by adding a NULL check for mbus at the top of mon_bus_remove().
If mon_bus_init() failed, ubus->mon_bus is NULL, meaning the bus was
never tracked by the monitor, so there is nothing to clean up and
returning early is correct.
Reported-by: syzbot+5f4b29d9fe710a964482@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=5f4b29d9fe710a964482
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Jiangong.Han <jiangong.han@windriver.com>
Link: https://patch.msgid.link/20260801095128.46322-1-jiangong.han@windriver.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
When an SG URB completes with an error, mts_do_sg() calls
mts_transfer_cleanup(), which completes the SCSI command through
scsi_done(). However, the callback continues advancing the scatterlist
and may submit another URB for a command that has already been
completed.
Return immediately after the cleanup so that no further processing is
performed on the completed command.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Diego Fernando Mancera Gomez <diegomancera.dev@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
Link: https://patch.msgid.link/20260723195654.152104-1-diegomancera.dev@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Convert Texas Instruments da830-ohci bindings from legacy text to DT
schema. Name of binding is changed to match primary compatible property.
Add required property clocks and optional property oc-gpios which were
missing from legacy binding.
Signed-off-by: Bhargav Joshi <j.bhargav.u@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260729-ti-da830-ohci-v3-1-e30da330780f@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The driver core only creates the sysfs "module" symlink for a built-in
driver when its struct device_driver has mod_name set (see
module_add_driver()). This driver left mod_name unset, so its built-in
form had no such symlink.
Set mod_name to KBUILD_MODNAME during driver registration. Built-in
drivers now gain the symlink, while loadable modules are unaffected.
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://patch.msgid.link/20260722-mod_name_usb-v1-4-96d781530f3f@sony.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The driver core only creates the sysfs "module" symlink for a built-in
driver when its struct device_driver has mod_name set (see
module_add_driver()). This driver left mod_name unset, so its built-in
form had no such symlink.
Set mod_name to KBUILD_MODNAME during driver registration. Built-in
drivers now gain the symlink, while loadable modules are unaffected.
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://patch.msgid.link/20260722-mod_name_usb-v1-3-96d781530f3f@sony.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The driver core only creates the sysfs "module" symlink for a built-in
driver when its struct device_driver has mod_name set (see
module_add_driver()). This registration path left mod_name unset, so built-in
drivers using it had no such symlink.
Set mod_name to KBUILD_MODNAME during driver registration. Built-in
drivers now gain the symlink, while loadable modules are unaffected.
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://patch.msgid.link/20260722-mod_name_usb-v1-2-96d781530f3f@sony.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Rename usb_register_device_driver() to __usb_register_device_driver() and replace
it with a macro wrapper that passes THIS_MODULE implicitly. This is in line with
what other buses do.
Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
Reviewed-by: Bastien Nocera <hadess@hadess.net>
Link: https://patch.msgid.link/20260722-mod_name_usb-v1-1-96d781530f3f@sony.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
The DSPS glue layer (used on TI AM335x SoCs) was missing implementations
for the vbus_status and set_vbus platform ops defined in struct
musb_platform_ops.
Add dsps_musb_vbus_status() to report VBUS presence by reading the VBUS
field of MUSB_DEVCTL, and dsps_musb_set_vbus() to drive the SESSION bit
on MUSB_DEVCTL, enabling or disabling the USB session.
Register both callbacks in dsps_ops to allow the MUSB core to control
VBUS on AM335x-based platforms. This enables the USB core to perform a
VBUS power cycle as a recovery mechanism when a USB error condition is
detected, and also allows userspace to control VBUS state via the
standard USB sysfs interface.
Signed-off-by: Lucas Martins Alves <lucas.alves@lumal21.com.br>
Link: https://patch.msgid.link/20260717194449.317520-1-lucas.alves@lumal21.com.br
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Replace the open-coded of_address_to_resource() plus devm_ioremap_resource()
sequence with devm_platform_get_and_ioremap_resource(), which looks up the
resource and maps it in one call. The helper returns a pointer to the
resource, so update rsrc_start / rsrc_len to dereference it and assign the
mapped address to hcd->regs. Use a separate on-stack resource (ehci_res)
for the unrelated ibm,usb-ehci-440epx erratum lookup rather than aliasing
the returned resource pointer.
Switch IRQ acquisition from irq_of_parse_and_map() to platform_get_irq(),
which only retrieves the interrupt the OF/platform core has already set up
rather than transferring mapping ownership to the driver. Drop the now
unneeded irq_dispose_mapping() calls (probe error path and
ohci_hcd_ppc_of_remove()) and the now-unused of_irq.h include, keeping
linux/of_address.h for the erratum block's of_address_to_resource().
Behaviorally equivalent with respect to region reservation: the prior code
used devm_ioremap_resource(), which already reserved the region.
Built for PowerPC (ppc44x_defconfig + CONFIG_USB_OHCI_HCD_PPC_OF) with
LLVM=1; drivers/usb/host/ohci-hcd.o (which includes ohci-ppc-of.c)
compiles cleanly.
Assisted-by: opencode:hy3-free
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260713231604.1090044-1-rosenp@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Replace the open-coded of_address_to_resource() plus devm_ioremap_resource()
sequence with devm_platform_get_and_ioremap_resource(), which looks up the
resource and maps it in one call. The helper returns a pointer to the
resource, so update rsrc_start / rsrc_len to dereference it, assign the
mapped address to hcd->regs, and use a separate on-stack resource
(ohci_res) for the unrelated ibm,usb-ohci-440epx erratum lookup rather
than aliasing the returned resource pointer.
Switch IRQ acquisition from irq_of_parse_and_map() to platform_get_irq(),
which only retrieves the interrupt the OF/platform core has already set up
rather than transferring mapping ownership to the driver. Drop the now
unneeded irq_dispose_mapping() calls (probe error path and
ehci_hcd_ppc_of_remove()) and the now-unused of_irq.h and of_platform.h
includes, keeping linux/of_address.h for the erratum block's
of_address_to_resource().
Behaviorally equivalent with respect to region reservation: the prior code
used devm_ioremap_resource(), which already reserved the region.
Built for PowerPC (ppc44x_defconfig + CONFIG_USB_EHCI_HCD_PPC_OF) with
LLVM=1; drivers/usb/host/ehci-hcd.o (which includes ehci-ppc-of.c)
compiles cleanly.
Assisted-by: opencode:hy3-free
Signed-off-by: Rosen Penev <rosenp@gmail.com>
Link: https://patch.msgid.link/20260713231302.1076740-1-rosenp@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
For legacy 32-bit Tegra devices, the warning in the
tegra_pmc_enter_suspend_mode() function is being triggered because the
early_pmc->rate variable is never configured and hence, always 0. This
issue started occurring after updating the PMC driver to create the PMC
context dynamically which causes the 'rate' to be set in the new dynamic
context, but missed updating the rate in the early PMC context.
Fix this by initialising the early_pmc->rate variable for 32-bit Tegra
devices when the rate for the PMC context is initialised.
Fixes: 4d61f0342689 ("soc/tegra: pmc: Create PMC context dynamically")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
[treding@nvidia.com: move assignment to existing #ifdef block]
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
The pmic_glink client is released by the devres cleanup, which runs
after pmic_glink_ucsi_remove() has returned, so its notification
callbacks can queue work until then. Work that runs after
ucsi_unregister() has been called touches freed state: it dereferences
the connector array that ucsi_unregister() freed, or registers and
unregisters the instance a second time.
Disable both work items with disable_work_sync() before unregistering,
and unregister only if the instance is still registered.
This issue was found by an in-house static analysis tool.
Fixes: 62b5412b1f4a ("usb: typec: ucsi: add PMIC Glink UCSI driver")
Cc: stable <stable@kernel.org>
Assisted-by: Codex:gpt-5.6
Link: https://lore.kernel.org/r/20260227190430.889-1-nathan.c.rebello@gmail.com
Co-developed-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Link: https://patch.msgid.link/20260908060216.616045-1-fanwu01@zju.edu.cn
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
pxad_alloc_desc() was converted from
kzalloc(struct_size(sw_desc, hw_desc, nb_hw_desc), GFP_NOWAIT)
to kzalloc_flex(), which sets the __counted_by() counter sw_desc->nb_desc
itself - but only where the compiler has __builtin_counted_by_ref(), so
from gcc 15.1 or clang 22.1 on. The loop below it still increments
nb_desc, which makes it come out doubled there and correct elsewhere.
nb_desc is what pxad_free_desc() iterates over and what
set_updater_desc() indexes from, so set it explicitly and drop the
increment. The error path has to lower it to the number of descriptors
allocated so far, otherwise pxad_free_desc() would free entries that were
never allocated.
Fixes: 69050f8d6d075 ("treewide: Replace kmalloc with kmalloc_obj for non-scalar types")
Assisted-by: Claude:claude-opus-5
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://lore.kernel.org/r/20260817-dmaengine-pxa-v1-1-850c215c1196@pengutronix.de
Link: https://patch.msgid.link/20260817-dmaengine-pxa-v2-1-f42ab0569a48@pengutronix.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The jack in/out descriptor arrays in struct f_midi2_usb_config have
the size of MAX_CABLES, which look reasonable -- but it turned out to
be incorrect. Namely, the entries for those arrays are added from
both inputs and outputs, hence for each loop cycle, it adds two, ended
up with as twice as the expected size. This inconsistency may result
in potential OOB when a large number of jacks are set up via configfs,
although the max number of cables (the loop count) is limited to
MAX_CABLES.
For addressing it, correct the jack_ins & jack_outs array sizes to
twice, MAX_CABLES * 2.
Fixes: 856fa444b098 ("usb: gadget: midi2: Dynamically create MIDI 1.0 altset descriptors")
Cc: stable <stable@kernel.org>
Reported-by: syzbot+c35f34092a4bc9855be6@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=c35f34092a4bc9855be6
Link: https://lore.kernel.org/20260826134606.127250-1-eadavis@sina.com
Cc: Edward Adam Davis <eadavis@sina.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Link: https://patch.msgid.link/20260901145512.785142-1-tiwai@suse.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
sun6i_dma_tx_status() calls vchan_find_desc() to look up the virtual
descriptor for a given cookie, before checking whether the pointer
vd is NULL:
vd = vchan_find_desc(&vchan->vc, cookie);
txd = to_sun6i_desc(&vd->tx); /* vd may be NULL here */
if (vd) {
for (lli = txd->v_lli; ...)
vchan_find_desc() returns NULL when the descriptor has already been
completed or is in-flight on a physical channel and no longer present
in the virtual channel's descriptor list. When vd is NULL,
to_sun6i_desc() is called unconditionally on &vd->tx before the NULL
check, which is undefined behaviour. Move the call inside the if (vd)
guard to ensure it is only reached with a valid pointer.
vd = vchan_find_desc(&vchan->vc, cookie);
if (vd) {
struct sun6i_desc *txd = to_sun6i_desc(&vd->tx);
for (lli = txd->v_lli; ...)
Fixes: 555859308723 ("dmaengine: sun6i: Add driver for the Allwinner A31 DMA controller")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Christian Lugnberg <christian.lugnberg@soundtrack.io>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260817135723.12807-3-christian.lugnberg@soundtrack.io
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
sun6i_get_chan_size() reads DMA_CHAN_LLI_ADDR and DMA_CHAN_CUR_CNT in two
separate readl() calls with no synchronisation between them:
pos = readl(pchan->base + DMA_CHAN_LLI_ADDR);
bytes = readl(pchan->base + DMA_CHAN_CUR_CNT);
DMA_CHAN_LLI_ADDR holds the physical address of the *next* descriptor the
engine will load once the current one completes. DMA_CHAN_CUR_CNT holds the
remaining byte count for the *current* descriptor. If the DMA engine
advances to the next LLI entry between the two reads, pos becomes stale: it
still points to what was the next descriptor at the time of the first read,
but that descriptor is now the current one and CUR_CNT reflects its initial
(full) byte count. The subsequent virtual-chain walk starts one entry too
early and accumulates an extra full period's worth of bytes into the
residue estimate.
Fix this by re-reading DMA_CHAN_LLI_ADDR after DMA_CHAN_CUR_CNT and
retrying if the value changed. This double-read pattern guarantees that
both registers were sampled during the same descriptor interval. The cost
is at most one extra readl() pair per call in the racy case, which occurs
only at descriptor boundaries (~every 2 ms) and is negligible.
Fixes: a90e173f3faf ("dmaengine: sun6i: Add cyclic capability")
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-sonnet-4-6
Signed-off-by: Christian Lugnberg <christian.lugnberg@soundtrack.io>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260817135723.12807-2-christian.lugnberg@soundtrack.io
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
xilinx_dma_alloc_chan_resources() builds a static ring of hardware
buffer descriptors once and the driver uses this ring throughout the
lifetime of a channel. This requires the allocation order of hardware
buffer descriptors from chan->free_seg_list to stay in sync with the
hardware buffer descriptor ring built at channel allocation time by
returning oldest descriptors to chan->free_seg_list first.
When chan->pending_list is not empty e.g. during
xilinx_dma_terminate_all() the chan->free_seg_list and the order of the
static hardware buffer descriptor ring get out of sync. Descriptors age
in this order: pending -> active -> done. So freeing pending_list first
returns the newest buffer descriptors to the chan->free_seg_list first
and thus breaks the order required by the static hardware buffer
descriptor ring. Then when the channel is reused, after a wrap around of
the free_seg_list the DMA will find a hardware buffer descriptor with a
length field that is still zeroed and stop with something like this:
xilinx-vdma 86000000.dma: Channel 000000003a21d7b8 has errors 10, cdr 6de4c000 tdr 6de4c000
After this no more descriptors are completed and a consumer potentially
blocks and waits forever. The only way to get out of this error state is
to rebuild the static hardware buffer descriptor ring and the
free_seg_list by releasing and re-acquiring the channel.
Fix the order in which hardware buffer descriptors are returned to
free_seg_list to ensure the mentioned requirement holds.
Fixes: 23059408b6a3 ("dmaengine: xilinx_dma: Fix race condition in the driver for multiple descriptor scenario")
Signed-off-by: Alex Bereza <alex@bereza.email>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com>
Link: https://patch.msgid.link/20260817-fix-hw-buf-desc-reuse-v1-1-d79827a844c7@bereza.email
Signed-off-by: Vinod Koul <vkoul@kernel.org>
|
|
The stateful decoder leaks uninitialized kernel heap memory to userspace.
A process that can open the decoder video node gets it back in the CAPTURE
buffers it dequeues.
The reference frame and the compressed frame buffer are allocated with
kvmalloc() in vicodec_start_streaming(), and the decoder can read them
before they have been written. The first frame is allowed to be a P-frame,
in which case it is decoded against a reference frame that was never
produced, and the padding rows below the visible area are never written
for any frame.
Use kvzalloc() for both allocations.
Fixes: 256bf813ba39 ("media: vicodec: add the virtual codec driver")
Reported-by: Yuhao Jiang <danisjiang@gmail.com>
Assisted-by: Claude:claude-opus-5
Cc: stable@vger.kernel.org
Signed-off-by: Junrui Luo <moonafterrain@outlook.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
vivid_dev_release() cancels update_hdmi_ctrl_work but not its sibling
update_svid_ctrl_work, which vivid_vid_cap_s_ctrl() queues on
update_svid_ctrls_workqueue when a VIVID_CID_SVID_IS_CONNECTED_TO_OUTPUT
control is changed. The two work items were added together, but only
one of them is cancelled on release.
If the svid work is still pending or running when the last v4l2_device
reference is dropped, update_svid_ctrls_work_handler() runs after
kfree(dev): the handler iterates the global vivid_devs[] array and
calls v4l2_ctrl_modify_range() on every vivid_dev instance, including
this one after it has been freed.
Add the missing cancel_work_sync() next to the hdmi sibling, before
vivid_free_controls() releases the control handlers the work uses.
This issue was found by an in-house static analysis tool.
Fixes: d7c969f37515 ("media: vivid: Add 'Is Connected To' menu controls")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
Co-developed-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Song Li <songl@zju.edu.cn>
Signed-off-by: Fan Wu <fanwu01@zju.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The vim2m driver has two driver-specific controls, but the
control IDs were never reserved in v4l2-control.h.
While these control IDs clash with the range reserved for
the old meye driver, since that meye driver has been removed
from the kernel quite a long time ago we just officially claim
that range for the vim2m driver.
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Reported-by: Nicolas Dufresne <nicolas@ndufresne.ca>
Closes: https://lore.kernel.org/linux-media/71a3fa9710cf1afbb80ebe850878557c3e95a1b2.camel@ndufresne.ca/
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
|
|
The I2C core stores message lengths in u16, but cx231xx truncates them to
u8 when populating cx231xx_i2c_xfer_data. A 0x700-byte read therefore
becomes a zero-length request. USB treats zero-length control transfers as
OUT regardless of bRequestType, so the IN control pipe trips the
usb_submit_urb() direction warning.
Use u16 for buf_size, matching both i2c_msg.len and
VENDOR_REQUEST_IN.wLength. Oversized transfers then reach the existing
URB_MAX_CTRL_SIZE check and return -EINVAL.
Fixes: e0d3bafd0258 ("V4L/DVB (10954): Add cx231xx USB driver")
Cc: stable@kernel.org
Reported-by: syzbot+ddccc0c0dbc0a38ffccb@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=ddccc0c0dbc0a38ffccb
Tested-by: syzbot+ddccc0c0dbc0a38ffccb@syzkaller.appspotmail.com
Signed-off-by: Juan Perdomo <jcperdomo100@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
The devm_request_threaded_irq() function now automatically logs detailed
error messages on failure. This eliminates the need for driver-specific
dev_err_probe() calls that print generic messages.
Signed-off-by: Amin Gattout <amin.gattout@gmail.com>
Reviewed-by: Igor Paunovic <royalnet026@gmail.com>
Acked-by: Dmitry Osipenko <dmitry.osipenko@collabora.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
syzbot reports a vmalloc out-of-bounds write in the test pattern
generator:
BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2617 [inline]
BUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x2063/0x4160 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705
Write of size 720 at addr ffffc900038f9d50 by task vivid-000-vid-c/6017
The reproducer requests a 720x49 NV12 capture format, i.e. an odd
height for a format whose chroma plane is vertically subsampled.
The buffer size is derived from the height by a truncating division:
sizes[p] = (tpg_g_line_width(&dev->tpg, p) * h) /
dev->fmt_cap->vdownsampling[p] +
dev->fmt_cap->data_offset[p];
For a single buffer holding both planes tpg_g_line_width() returns
720 + 720 / 2 = 1080, so 1080 * 49 = 52920 bytes get allocated.
tpg_fill_plane_buffer() however emits one chroma line for every two
luma lines, i.e. DIV_ROUND_UP(49, 2) = 25 lines, and thus needs
49 * 720 + 25 * 720 = 53280 bytes. The memcpy() of the last chroma
line runs 360 bytes past the end of the buffer.
An odd height is not meaningful for a 4:2:0 format in the first place,
since the chroma plane would have to hold half a line. Rather than
fixing up each of the ~10 sites that divide the height by
vdownsampling[], round the height down to a multiple of the vertical
subsampling factor where it enters the driver. Adjusting the format is
what TRY_FMT/S_FMT are for, and it keeps every later division exact.
Formats without vertical subsampling are unaffected and keep accepting
odd heights.
Tested with the syzbot reproducer, which no longer triggers the splat,
and by streaming NV12, NV21, YUV420, YVU420 and YUYV at heights 47,
48, 49, 51, 480, 481 and 1081. v4l2-compliance gives identical results
before and after (48 of 50 succeeded on the vivid device in both
cases; the two failures are pre-existing and unrelated).
Fixes: ddcaee9dd4c0 ("[media] vivid: add support for single buffer planar formats")
Cc: stable@kernel.org
Reported-by: syzbot+cb43e758a4dc84dd467f@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=cb43e758a4dc84dd467f
Signed-off-by: Maxim Skokov <skokovmaksimevg@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Correct "initilize" to "initialize", reported by scripts/checkpatch.pl
using the misspelling list in scripts/spelling.txt. Only touches comments,
no code changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Drop the word written twice, reported by checkpatch.pl as a possible
repeated word.
Only the message text changes, no code changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Drop words accidentally written twice, reported by checkpatch.pl as a
possible repeated word. Only touches comments, no code changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Fix typos in comments, reported by scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Assisted-by: Cursor:claude-opus-5
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
cx25840_init() implements generic mode video output configuration only
for cx2584x chips. For other chips, it triggers a WARN_ON(1) and returns
0, falsely indicating successful initialization while leaving the chip
unconfigured and marking generic_mode as true.
Using WARN_ON() for unsupported hardware variants is discouraged as it
triggers kernel warnings and syzbot alerts on faulty or unsupported
devices.
Return -EOPNOTSUPP early if the chip is not a cx2584x variant so callers
(such as cxusb_medion_register_analog_subdevs()) can handle the error
cleanly.
Reported-by: syzbot+9123948aef13fe92d706@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=9123948aef13fe92d706
Tested-by: syzbot+9123948aef13fe92d706@syzkaller.appspotmail.com
Signed-off-by: Muhammad Haris Awan <m.harisawan@icloud.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
[hverkuil: fixed the mangled patch]
|
|
The tegra20 and tegra210 CSI bindings are not listed in any MAINTAINERS
entry, so get_maintainer.pl does not match TEGRA VIDEO DRIVER for changes
to them and reports neither linux-media nor two of the four maintainers
of that entry.
The entry already covers the VI and VIP bindings, and csi.c binds to the
compatibles documented by both files. Add them as well.
Signed-off-by: Aleksandr Chubuchnyi <chubuchnyi@gmail.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Switch to devm_of_reserved_mem_device_init() so the reserved memory
region is released automatically on probe failure or device removal.
Remove the four explicit of_reserved_mem_device_release() calls and
collapse the now-empty err_release_mem label into err_free.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
|
Switch to devm_of_reserved_mem_device_init() so the reserved memory
region is released automatically on probe failure or device removal.
Remove the three explicit of_reserved_mem_device_release() calls and
rename the error label from err_release_reserved_mem to
err_unprepare_vclk to reflect that it now only unwinds clock state.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
|
