The board exposes the GPIO4_C6 pin to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Additionally, drop the now unnecessary workaround of using vcc5v_hdmi_tx
as hdmi-pwr-supply solely to drive the GPIO into its default state.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-3-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The board exposes the GPIO4_C6 pin to control the voltage bias on the
HDMI data lines. It must be asserted when operating in HDMI 2.1 FRL
mode and deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Additionally, remove the now unnecessary workaround of using
vcc_5v0_hdmi as hdmi-pwr-supply solely to drive the GPIO into its
default state.
Also rename the hdmi_con_en pinctrl to hdmi_tx_on_h to match the
schematic naming.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-2-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The following RK3576 boards expose a GPIO pin to control the voltage
bias on the HDMI data lines:
- rk3576-100ask-dshanpi-a1
- rk3576-armsom-sige5
- rk3576-evb1-v10
- rk3576-evb2-v10
- rk3576-nanopi-m5
- rk3576-roc-pc
- rk3576-rock-4d
The pin must be asserted when operating in HDMI 2.1 FRL mode and
deasserted for HDMI 1.4/2.0 TMDS mode.
Wire up the hdmi node to its dedicated GPIO via frl-enable-gpios to
allow adjusting the bias when transitioning between TMDS and FRL modes.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Link: https://patch.msgid.link/20260428-dts-rk-frl-enable-gpios-v2-1-924df9db884a@collabora.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Khadas Edge 2L uses an Ampak AP6275P (BCM43752) PCIe
Wi-Fi 6 module.
Enable combphy0 and pcie0, add the Wi-Fi regulator and reset
pinctrl, and describe the PCIe Wi-Fi function so it can consume
the 32.768kHz LPO clock provided by the HYM8563 RTC.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260429063712.2150938-4-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The Khadas Edge 2L uses an on-board HYM8563 RTC connected to
I2C2. Enable it and expose its 32.768kHz clock output so later
board-level patches can reference it as the LPO clock source for
the AP6275P wireless module.
Mark the RTC as a wakeup source as well.
Signed-off-by: Gray Huang <gray.huang@wesion.com>
Link: https://patch.msgid.link/20260429063712.2150938-3-gray.huang@wesion.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The engine state size reported to GuC via ADS should only include the
engine state portion and should not include the indirect ring state page
that comes after it in the context image. The GuC uses this size to
overwrite the engine state in the LRC on watchdog resets and we don't
want it to overwrite the indirect ring state as well.
Fixes: d6219e1cd5 ("drm/xe: Add Indirect Ring State support")
Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Satyanarayana K V P <satyanarayana.k.v.p@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patch.msgid.link/20260504094924.3760713-4-satyanarayana.k.v.p@intel.com
xe_hw_error_map[] is not worth the memory needed to map two components.
Clean it up and use switch() instead, which also, in turn, simplifies
bounds checking logic.
add/remove: 0/1 grow/shrink: 0/1 up/down: 0/-425 (-425)
Function old new delta
xe_hw_error_map 136 - -136
xe_hw_error_irq_handler 3728 3439 -289
Total: Before=7700, After=7275, chg -5.52%
Signed-off-by: Raag Jadav <raag.jadav@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com>
Link: https://patch.msgid.link/20260502180143.1450266-1-raag.jadav@intel.com
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Chromium/Depthcharge bootloaders may dynamically add a few device nodes
to a system's DTB under a /firmware node. A typical DT looks something
like the following:
## From a RK3399 Gru/Kevin Chromebook:
# find /sys/firmware/devicetree/base/firmware
/sys/firmware/devicetree/base/firmware
/sys/firmware/devicetree/base/firmware/coreboot
/sys/firmware/devicetree/base/firmware/coreboot/ram-code
/sys/firmware/devicetree/base/firmware/coreboot/compatible
/sys/firmware/devicetree/base/firmware/coreboot/board-id
/sys/firmware/devicetree/base/firmware/coreboot/reg
/sys/firmware/devicetree/base/firmware/coreboot/name
/sys/firmware/devicetree/base/firmware/chromeos
/sys/firmware/devicetree/base/firmware/chromeos/readonly-firmware-version
/sys/firmware/devicetree/base/firmware/chromeos/active-ec-firmware
/sys/firmware/devicetree/base/firmware/chromeos/firmware-version
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-storage
/sys/firmware/devicetree/base/firmware/chromeos/vboot-shared-data
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-size
/sys/firmware/devicetree/base/firmware/chromeos/nonvolatile-context-offset
/sys/firmware/devicetree/base/firmware/chromeos/hardware-id
/sys/firmware/devicetree/base/firmware/chromeos/compatible
/sys/firmware/devicetree/base/firmware/chromeos/firmware-type
/sys/firmware/devicetree/base/firmware/chromeos/fmap-offset
/sys/firmware/devicetree/base/firmware/chromeos/name
/sys/firmware/devicetree/base/firmware/ranges
/sys/firmware/devicetree/base/firmware/name
The /firmware node has an empty 'ranges', but does not have
address/size-cells.
Commit 6e5773d52f ("of/address: Fix WARN when attempting translating
non-translatable addresses") started requiring #address-cells for a
device's parent if we want to use the reg resource in a device node.
This leads to errors like the following:
[ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
Add appropriate #{address,size}-cells to work around the problem.
Note that Google has also patched the Depthcharge bootloader source to
add {address,size}-cells [1], but bootloader updates are typically
delivered only via Google OS updates. Not all users install Google
software updates, and even if they do, Google may not produce updated
binaries for all/older devices.
[1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
#size-cells for firmware node")
Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
Fixes: 6e5773d52f ("of/address: Fix WARN when attempting translating non-translatable addresses")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
[On RK3399-based Chromebooks there is no real other way than to load the
DTB together with its kernel when running a mainline kernel and as the
whole line is EOL, there also won't be any updates to the bootloader that
could fix that issue there.]
Link: https://patch.msgid.link/20260428200712.2660635-2-briannorris@chromium.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Chromium/Depthcharge bootloaders may dynamically add a few device nodes
to a system's DTB under a /firmware node. A typical DT looks something
like the following:
/ {
firmware {
ranges;
coreboot {
compatible = "coreboot";
reg = <...>;
...;
};
};
};
Notably, the /firmware node has an empty 'ranges', but does not have
address/size-cells.
Commit 6e5773d52f ("of/address: Fix WARN when attempting translating
non-translatable addresses") started requiring #address-cells for a
device's parent if we want to use the reg resource in a device node.
This leads to errors like the following:
[ 7.763870] coreboot_table firmware:coreboot: probe with driver coreboot_table failed with error -22
Add appropriate #{address,size}-cells to work around the problem.
Note that Google has also patched the Depthcharge bootloader source to
add {address,size}-cells [1], but bootloader updates are typically
delivered only via Google OS updates. Not all users install Google
software updates, and even if they do, Google may not produce updated
binaries for all/older devices.
[1] https://lore.kernel.org/all/20241209092809.GA3246424@google.com/https://crrev.com/c/6051580 ("coreboot: Insert #address-cells and
#size-cells for firmware node")
Closes: https://lore.kernel.org/all/aeKlYzTiL0OB1y3g@google.com/
Fixes: 6e5773d52f ("of/address: Fix WARN when attempting translating non-translatable addresses")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
[On RK288-based Chromebooks there is no real other way than to load the
DTB together with its kernel when running a mainline kernel and as the
whole line is EOL, there also won't be any updates to the bootloader that
could fix that issue there.]
Link: https://patch.msgid.link/20260428200712.2660635-3-briannorris@chromium.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Add device IDs for the next generation of switchtec products.
No changes to the driver were required with the new version of the
hardware.
[logang: rewrote commit message]
Signed-off-by: Ben Reed <Ben.Reed@microchip.com>
Signed-off-by: Logan Gunthorpe <logang@deltatee.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Link: https://patch.msgid.link/20260505161633.67454-1-logang@deltatee.com
Add i.MX91 9x9 Quick Start Board support.
- Enable ADC1.
- Enable lpuart1.
- Enable network eqos.
- Enable I2C bus and children nodes under I2C bus.
- Enable USB and related nodes.
- Enable uSDHC1 and uSDHC2.
- Enable Watchdog3.
The board description can refer to the following link:
https://www.nxp.com/design/design-center/development-boards-and-designs/IMX91QSB
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The clock-frequency property is not implemented. Remove it to clean up the
device tree.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The clock-frequency property is not implemented. Remove it to clean up the
device tree.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
The clock-frequency property is not implemented. Remove it to clean up the
device tree.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Add compatible string for i.MX91 9x9 Quick Start Board.
Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
A collection of bugs, many found with inspection tools:
- Several error unwind misses on system calls in mlx5, mana,, ocrdma,
vmw_pvrdma, mlx4, and hns
- More rxe bugs processing network packets
- User triggerable races in mlx5 when destroying and creating the same
same object when the FW returns the same object ID
- Incorrect passing of an IPv6 address through netlink
RDMA_NL_LS_OP_IP_RESOLVE
- Add memory ordering for mlx5's lock avoidance pattenr
- Protect mana from kernel memory overflow
- Use safe patterns for xarray/radix_tree look up in mlx5 and hns
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCafoC6AAKCRCFwuHvBreF
YSHCAP9AU6NnDa+ltlY65HrKXNP3R7kgKAKM3x0e7keZrj4ahQEA9zCBNEJ/PY/Q
jM0jgMor2W1aWfuuqn47g82rPN5e4QY=
=lqDa
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
Pull rdma fixes from Jason Gunthorpe:
- Several error unwind misses on system calls in mlx5, mana, ocrdma,
vmw_pvrdma, mlx4, and hns
- More rxe bugs processing network packets
- User triggerable races in mlx5 when destroying and creating the same
same object when the FW returns the same object ID
- Incorrect passing of an IPv6 address through netlink
RDMA_NL_LS_OP_IP_RESOLVE
- Add memory ordering for mlx5's lock avoidance pattenr
- Protect mana from kernel memory overflow
- Use safe patterns for xarray/radix_tree look up in mlx5 and hns
* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: (24 commits)
RDMA/hns: Fix unlocked call to hns_roce_qp_remove()
RDMA/hns: Fix xarray race in hns_roce_create_qp_common()
RDMA/hns: Fix xarray race in hns_roce_create_srq()
RDMA/mlx4: Fix mis-use of RCU in mlx4_srq_event()
RDMA/mlx4: Fix resource leak on error in mlx4_ib_create_srq()
RDMA/vmw_pvrdma: Fix double free on pvrdma_alloc_ucontext() error path
RDMA/ocrdma: Don't NULL deref uctx on errors in ocrdma_copy_pd_uresp()
RDMA/ocrdma: Clarify the mm_head searching
RDMA/mana: Fix error unwind in mana_ib_create_qp_rss()
RDMA/mana: Fix mana_destroy_wq_obj() cleanup in mana_ib_create_qp_rss()
RDMA/mana: Remove user triggerable WARN_ON() in mana_ib_create_qp_rss()
RDMA/mana: Validate rx_hash_key_len
RDMA/mlx5: Add missing store/release for lock elision pattern
RDMA/mlx5: Restore zero-init to mlx5_ib_modify_qp() ucmd
RDMA/ionic: Fix typo in format string
RDMA/mlx5: Fix null-ptr-deref in Raw Packet QP creation
RDMA/core: Fix rereg_mr use-after-free race
IB/core: Fix IPv6 netlink message size in ib_nl_ip_send_msg()
RDMA/mlx5: Fix UAF in DCT destroy due to race with create
RDMA/mlx5: Fix UAF in SRQ destroy due to race with create
...
Agilex3 SoCFPGA have 2 i3c controllers, a main master and a secondary
master. Setting the alias for both i3c controllers to prevent bus id
contention when both controllers are enabled which results in driver
probe failures.
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Agilex5 SoCFPGA variants and derivatives have 2 i3c controllers, a main
master and a secondary master. Setting the alias for both i3c controllers
to prevent bus id contention when both controllers are enabled which
results in driver probe failures.
Signed-off-by: Adrian Ng Ho Yin <adrian.ho.yin.ng@altera.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
YAML literal block scalars cannot use tabs for indent.
Replace tab separators (mostly between values and trailing /* ... */
comments) with single spaces.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/2044ee0cac191c7be8b6e989fc3c99b24aa4cc5e.1777434096.git.daniel@makrotopia.org
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Fix an ath5k potential stack buffer overwrite.
Fix several issues in ath12k:
- WMI buffer leaks on error conditions
- use of uninitialized stack data when processing RSSI events
- incorrect logic for determining the peer ID in the RX path
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ/mtSHzPUi16IfDEksFbugiYzLewUCafn3owAKCRAsFbugiYzL
e5K2AP9lVpNgx8xE4YFK6QVGTfZb9OD6ikFcvj9Y4sYakOgc3AEAyx3x8i3unBkE
z2safm5blk5AmpfA0qwLNYeVJIWflgA=
=448V
-----END PGP SIGNATURE-----
Merge tag 'ath-current-20260505' of git://git.kernel.org/pub/scm/linux/kernel/git/ath/ath
Jeff Johnson says:
==================
ath.git update for v7.1-rc3
Fix an ath5k potential stack buffer overwrite.
Fix several issues in ath12k:
- WMI buffer leaks on error conditions
- use of uninitialized stack data when processing RSSI events
- incorrect logic for determining the peer ID in the RX path
==================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
ffa_sched_recv_cb_update() used list_for_each_entry_safe() to search for
a matching partition and then tested the iterator against NULL. That is
not a valid end-of-list check for circular lists and can fall through
with an invalid pointer. Use a normal iterator and detect the not-found
case correctly before touching the partition state.
Fixes: be61da9385 ("firmware: arm_ffa: Allow multiple UUIDs per partition to register SRI callback")
Link: https://patch.msgid.link/20260428-ffa_fixes-v2-11-8595ae450034@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
Both notification handlers currently look up a notifier callback under
notify_lock, drop the lock, and then dereference the returned
notifier entry. A concurrent unregister can delete and free that
entry in the gap, leaving the handler to dereference stale memory.
Copy the callback pointer and callback data while notify_lock is
still held and invoke the callback only after the lock is dropped.
This keeps the existing callback execution model while removing the
use-after-free window in both the framework and non-framework
notification paths.
Fixes: 285a5ea0f5 ("firmware: arm_ffa: Add support for handling framework notifications")
Link: https://patch.msgid.link/20260428-ffa_fixes-v2-10-8595ae450034@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
Commit 83210251fd ("firmware: arm_ffa: Use the correct buffer size during
RXTX_MAP") advertises PAGE_ALIGN(rxtx_bufsz) to firmware when mapping the
buffers but the driver continues to stores the minimum FF-A buffer size
in drv_info->rxtx_bufsz which is used elsewhere in the driver.
Align the size before storing it so that the allocation, validation and
FFA_RXTX_MAP all use the same buffer size.
Fixes: 83210251fd ("firmware: arm_ffa: Use the correct buffer size during RXTX_MAP")
Cc: Sebastian Ene <sebastianene@google.com>
Link: https://sashiko.dev/#/patchset/20260402113939.930221-1-sebastianene@google.com
Reviewed-by: Sebastian Ene <sebastianene@google.com>
Link: https://patch.msgid.link/20260428-ffa_fixes-v2-9-8595ae450034@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
Framework notifications carry an indirect message in the shared RX
buffer. Validate the reported offset and size before using them, reject
zero-length payloads, and ensure that any non-header payload starts at
the UUID field rather than in the middle of the message header.
Use the validated offset and size values for both kmemdup() and the UUID
parsing path so malformed firmware data cannot drive an out-of-bounds
read or an oversized allocation.
Fixes: 285a5ea0f5 ("firmware: arm_ffa: Add support for handling framework notifications")
Link: https://patch.msgid.link/20260428-ffa_fixes-v2-8-8595ae450034@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
The framework notification handler drops rx_lock before issuing
FFA_RX_RELEASE, leaving a window where another RX-buffer user can
start a new FF-A transaction before ownership has actually been
returned to firmware.
Move the FFA_RX_RELEASE calls so they execute while rx_lock is still
held on both the kmemdup() failure path and the normal success path.
While doing that, switch the handler to scoped_guard() to keep the
critical section explicit.
Fixes: 285a5ea0f5 ("firmware: arm_ffa: Add support for handling framework notifications")
Link: https://patch.msgid.link/20260428-ffa_fixes-v2-7-8595ae450034@kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
The register-based PARTITION_INFO_GET path trusted the firmware-provided
indices when copying partition descriptors into the caller buffer.
Reject inconsistent counts or index progressions so the copy loop cannot
write past the allocated array.
Fixes: ba85c644ac ("firmware: arm_ffa: Add support for FFA_PARTITION_INFO_GET_REGS")
Link: https://patch.msgid.link/20260428-ffa_fixes-v2-6-8595ae450034@kernel.org
(fixed cur_idx when exactly one descriptor in the first fragment)
Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
Extend the guidelines when to use fallback compatibles to cover to
common review responses. Devices are most likely compatible and should
use fallbacks when having:
1. Compatible programming interface, meaning one is a subset, and Linux
device drivers can use the subset to correctly match/bind and still
operate with the subset features.
2. Device variant discovery through some means, like registers.
Devices are incompatible and fallback is not suitable when that
fallback cannot be used by the drivers to match/bind. In the same time
commit message should clearly explain when the code suggests devices
are compatible, but the binding does not define them as such.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260427160739.175451-2-krzysztof.kozlowski@oss.qualcomm.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Now that memblock and slab allocators are the only allocators and both
return zero-initialized memory, zeroing the memory ourselves is
redundant. The allocators used are:
- kernel_tree_alloc uses kzalloc()
- early_init_dt_alloc_memory_arch() and dt_alloc_memory() both use
memblock_alloc()
Remove redundant memset after the allocation. No funtional change.
Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
Link: https://patch.msgid.link/20260418140420.2221736-1-ekffu200098@gmail.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
The 'wakeup-source' property already has its type defined in the core
schema. Remove the redundant 'type: boolean' from the binding file to
clean up the binding files.
Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
Link: https://patch.msgid.link/20260417021858.6582-1-phucduc.bui@gmail.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Add compatible for Eliza SoC IMEM.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Link: https://patch.msgid.link/20260418-eliza-imem-v3-2-bfbd499b6e77@pm.me
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
SSD2825 being RGB-DSI bridge should inherit dsi-controller properties same
way other DSI controllers and DSI bridges do.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://patch.msgid.link/20260417064657.20293-2-clamor95@gmail.com
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Add support for allocating buffers from reserved carveout memory when
IOMMU is not available. This is useful during debugging or bring-up.
In this configuration, the device uses physical addresses and does
not support scatter-gather lists, requiring physically contiguous
buffers.
Implement carveout-backed allocation and integrate it into buffer
management to support operation in physical address mode.
Signed-off-by: Max Zhen <max.zhen@amd.com>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Signed-off-by: Lizhi Hou <lizhi.hou@amd.com>
Link: https://patch.msgid.link/20260427170949.2666601-1-lizhi.hou@amd.com
dcmi_graph_init() registers the async notifier before dcmi_probe() toggles
the reset line. If reset_control_assert() or reset_control_deassert()
fails afterwards, probe returns through err_cleanup and the driver core
will not call dcmi_remove().
Unregister the notifier before cleaning it up on that error path,
matching the successful remove path and the V4L2 async notifier lifetime
rules.
Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Fixes: d079f94c90 ("media: platform: Switch to v4l2_async_notifier_add_subdev")
Cc: stable@vger.kernel.org
[hverkuil: added Fixes tag]
OF_GPIO is selected automatically on all OF systems. Any symbols it
controls also provide stubs so there's really no reason to select it
explicitly. For Kconfig entries that have no other dependencies: convert
it to requiring OF to avoid new symbols popping up for everyone in make
config, for others just drop it altogether.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Destroy allocated workqueue in remove() callback to free its resources,
thus fixing memory leak.
Fixes: 519a4bdcf8 ("V4L/DVB (11984): Add support for yet another SDMC DM1105 based DVB-S card.")
Cc: <stable@vger.kernel.org>
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
If the vpe_top resource is missing, vpe_probe() returns -ENODEV after
v4l2_device_register() has succeeded. Probe failures do not call the
driver's remove callback, so the v4l2 device remains registered on that
error path.
Route that failure through the existing v4l2_device_unregister() unwind
label, matching the other errors after v4l2_device_register().
Fixes: 4d59c7d455 ("media: ti-vpe: vpe: Add missing null pointer checks")
Cc: stable@vger.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: Yemike Abhilash Chandra <y-abhilashchandra@ti.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
During manual code audit, we found that cafe_pci_probe() enables the
PCI device with pci_enable_device(), and its probe error path properly
calls pci_disable_device() on failure.
However, cafe_pci_remove() tears down the controller and frees the
driver data without disabling the PCI device, leaving the remove path
inconsistent with probe cleanup.
Add the missing pci_disable_device() call to cafe_pci_remove().
Fixes: abfa3df36c ("[media] marvell-cam: Separate out the Marvell camera core")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
When platform_device_register() fails in vivid_init(), the embedded
struct device in vivid_pdev has already been initialized by
device_initialize(), but the failure path jumps to free_output_strings
without dropping the device reference for the current platform device:
vivid_init()
-> platform_device_register(&vivid_pdev)
-> device_initialize(&vivid_pdev.dev)
-> setup_pdev_dma_masks(&vivid_pdev)
-> platform_device_add(&vivid_pdev)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before jumping to the common
cleanup path.
Also, the unreg_driver label incorrectly calls
platform_driver_register() instead of platform_driver_unregister(),
which breaks cleanup when workqueue creation fails after successful
driver registration. Fix that as well.
The reference leak was identified by a static analysis tool I developed
and confirmed by manual review. The incorrect cleanup call was found
during code inspection.
Fixes: f46d740fb0 ("[media] vivid: turn this into a platform_device")
Fixes: d7c969f375 ("media: vivid: Add 'Is Connected To' menu controls")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
When platform_device_register() fails in vimc_init(), the embedded
struct device in vimc_pdev has already been initialized by
device_initialize(), but the failure path returns the error without
dropping the device reference for the current platform device:
vimc_init()
-> platform_device_register(&vimc_pdev)
-> device_initialize(&vimc_pdev.dev)
-> setup_pdev_dma_masks(&vimc_pdev)
-> platform_device_add(&vimc_pdev)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: 4babf057c1 ("media: vimc: allocate vimc_device dynamically")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
When platform_device_register() fails in vidtv_bridge_init(), the
embedded struct device in vidtv_bridge_dev has already been initialized
by device_initialize(), but the failure path returns the error without
dropping the device reference for the current platform device:
vidtv_bridge_init()
-> platform_device_register(&vidtv_bridge_dev)
-> device_initialize(&vidtv_bridge_dev.dev)
-> setup_pdev_dma_masks(&vidtv_bridge_dev)
-> platform_device_add(&vidtv_bridge_dev)
This leads to a reference leak when platform_device_register() fails.
Fix this by calling platform_device_put() before returning the error.
The issue was identified by a static analysis tool I developed and
confirmed by manual review.
Fixes: f90cf6079b ("media: vidtv: add a bridge driver")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The return value of dm1105_dma_map(), which handles DMA memory allocation,
is ignored in dm1105_hw_init(). If dma_alloc_coherent() fails, the driver
will proceed using a NULL pointer for DMA transfers, leading to a kernel
oops or invalid hardware access.
Fix this by checking the return value and propagating -ENOMEM on failure.
Signed-off-by: Zhaoyang Yu <2426767509@qq.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Remove functions av7110_reset_arm() and av7110_send_ci_cmd()
which have both been disabled behind #if 0 since the introduction
to staging. Code can be recovered from git history.
Signed-off-by: Josh Hesketh <josh.hesketh@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
The driver reuses the OF node of the parent device but fails to take
another reference to balance the one dropped by the platform bus code
when unbinding the parent and releasing the child devices.
Fix this by using the intended helper for reusing OF nodes.
Fixes: 4a5f8ae50b ("[media] davinci: vpif_capture: get subdevs from DT when available")
Cc: stable@vger.kernel.org # 4.13
Cc: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
Use the common USB helper for looking up bulk-in endpoints instead of
open coding.
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
