summaryrefslogtreecommitdiff
path: root/drivers
AgeCommit message (Collapse)Author
2026-05-05pinctrl: add generic board-level pinctrl driver using mux frameworkFrank Li
Many boards use on-board mux chips (often controlled by GPIOs from an I2C expander) to switch shared signals between peripherals. Add a generic pinctrl driver built on top of the mux framework to centralize mux handling and avoid probe ordering issues. Keep board-level routing out of individual drivers and supports boot-time only mux selection. Ensure correct probe ordering, especially when the GPIO expander is probed later. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-05pinctrl: add optional .release_mux() callbackFrank Li
Add an optional .release_mux() callback to struct pinmux_ops. Some drivers acquire additional resources in .set_mux(), such as software locks. These resources may need to be released when the mux function is no longer active. Introducing a dedicated .release_mux() callback allows drivers to clean up such resources. The callback is optional and does not affect existing drivers. Commit 2243a87d90b42 ("pinctrl: avoid duplicated calling enable_pinmux_setting for a pin") removed the .disable() callback to resolve two issues: 1. desc->mux_usecount increasing monotonically 2. Hardware glitches caused by repeated .disable()/.enable() calls Adding .release_mux() does not reintroduce those problems. The callback is intended only for releasing driver-side resources (e.g. locks) and must not modify hardware registers. Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-05pinctrl: extract pinctrl_generic_to_map() from ↵Frank Li
pinctrl_generic_pins_function_dt_node_to_map() Refactor pinctrl_generic_pins_function_dt_subnode_to_map() by separating DT parsing logic from map creation. Introduce a new helper pinctrl_generic_to_map() to handle mapping to kernel data structures, while keeping DT property parsing in the subnode function. Improve code structure and enables easier reuse for platforms using different DT properties (e.g. pinmux) without modifying the dt_node_to_map-style callback API. Avoid unnecessary coupling to pinctrl_generic_pins_function_dt_node_to_map(), which provides functionality not needed when the phandle target is unambiguous. Maximize code reuse and provide a cleaner extension point for future pinctrl drivers. Suggested-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-05mux: add devm_mux_state_get_from_np() to get mux from child nodeFrank Li
Add new API devm_mux_state_get_from_np() to retrieve a mux control from a specified child device node. Make devm_mux_state_get() call devm_mux_state_get_from_np() with a NULL node parameter, which defaults to using the device's own of_node. Support the following DT schema: pinctrl@0 { uart-func { mux-state = <&mux_chip 0>; }; spi-func { mux-state = <&mux_chip 1>; }; }; Signed-off-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-05drm/panel: himax-hx83102: restore MODE_LPM after sending disable cmdsIcenowy Zheng
When preparing the panel, it seems that it always expects commands to be transferred in LP mode. However, the disable function removes the MIPI_DSI_MODE_LPM flag, and no other function re-adds it. As the unprepare function contains no DSI commands, re-adding the flag just after disabling the panel should be safe. Add the code re-adding the flag after the two commands for disabling the panel are sent. This fixes screen unblanking (after blanking once) on mt8188-geralt-ciri-sku1 device. Cc: stable@vger.kernel.org # 6.11+ Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out as separate driver") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260425165751.1716569-1-zhengxingda@iscas.ac.cn
2026-05-05drm/panel: boe-tv101wum-nl6: restore MODE_LPM after sending disable cmdsIcenowy Zheng
When preparing the panel, it seems that it always expects commands to be transferred in LP mode. However, the disable function removes the MIPI_DSI_MODE_LPM flag, and no other function re-adds it. As the unprepare function contains no DSI commands, re-adding the flag just after disabling the panel should be safe. Add the code re-adding the flag after the two commands for disabling the panel are sent. This fixes error messages shown in kernel log when unblanking on mt8183-kukui-kodama-sku32 device. Cc: stable@vger.kernel.org Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel") Signed-off-by: Icenowy Zheng <zhengxingda@iscas.ac.cn> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260503091708.1079962-1-zhengxingda@iscas.ac.cn
2026-05-05drm/panel: feiyang-fy07024di26a30d: return display-on errorChristian Van
mipi_dsi_dcs_set_display_on() returns an error code, but feiyang_enable() currently ignores it and always reports success. Return the DCS command result so callers can observe enable failures. Signed-off-by: Christian Van <cvan20191@gmail.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260425053948.117714-1-cvan20191@gmail.com
2026-05-05drm/panel: hx83121a: select DRM_DISPLAY_DSC_HELPERArnd Bergmann
Like a number of other panel drivers, this newly merged driver needs DRM_DISPLAY_DSC_HELPER to be enabled: arm-linux-gnueabi-ld: drivers/gpu/drm/panel/panel-himax-hx83121a.o: in function `himax_prepare': panel-himax-hx83121a.c:(.text+0x1024): undefined reference to `drm_dsc_pps_payload_pack' Fixes: a7c61963b727 ("drm/panel: Add Himax HX83121A panel driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by: David Heidelberg <david@ixit.cz> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260413071043.3829868-1-arnd@kernel.org
2026-05-05drm/panel: himax-hx83121a: Fix incorrect error check for devm_drm_panel_alloc()Chen Ni
Check devm_drm_panel_alloc() return value for ERR_PTR instead of NULL. devm_drm_panel_alloc() returns an ERR_PTR on failure, never NULL. Using a NULL check skips the error path and may cause a NULL pointer dereference. Fixes: a7c61963b727 ("drm/panel: Add Himax HX83121A panel driver") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patch.msgid.link/20260327021728.647182-1-nichen@iscas.ac.cn
2026-05-05net: eth: fbnic: Add pma read and write accessMike Marciniszyn (Meta)
Document the MDIO interface topology with an ASCII diagram showing the MAC, PCS (MMD 3), FEC, Separated PMA (MMD 8), and PMD (MMD 1) blocks and their interconnects. The diagram illustrates how 4 lanes connect the MAC through PCS, FEC, and PMA, then narrow to 2 lanes at the PMD. The c45 read and write routines are enhanced to support read and write of the separated PMA for the fbnic. Co-developed-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Alexander Duyck <alexanderduyck@fb.com> Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com> Link: https://patch.msgid.link/20260430150802.3521-4-mike.marciniszyn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-05net: eth: fbnic: Consolidate register reads for ids and devsMike Marciniszyn (Meta)
Consolidate the register reads for boiler plate registers to reduce LOC and cleanup pcs reads for DEVS1 to fetch overrides for reserved bits that the hardware does not return. Signed-off-by: Mike Marciniszyn (Meta) <mike.marciniszyn@gmail.com> Link: https://patch.msgid.link/20260430150802.3521-3-mike.marciniszyn@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2026-05-05Merge tag 'renesas-pinctrl-fixes-for-v7.1-tag1' of ↵Linus Walleij
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers into fixes pinctrl: renesas: Fixes for v7.1 - Fix pin bias suspend/resume handling on the RZ/G2L family, - Fix Schmitt-trigger suspend/resume handling on RZ/V2H(P), RZ/V2N, and RZ/G3E. Signed-off-by: Linus Walleij <linusw@kernel.org>
2026-05-05media: intel/ipu6: Improve DWC PHY HSFREQRANGE band selection for ↵Marco Nenciarini
overlapping ranges The get_hsfreq_by_mbps() function searches the freqranges[] table backward (from highest to lowest index). Because adjacent frequency bands overlap, a data rate that falls in the overlap region always lands on the higher-indexed band. For data rates up to 1500 Mbps (index 42) every band uses osc_freq_target 335. Starting at index 43 (1461-1640 Mbps) the osc_freq_target drops to 208. A sensor running at 1498 Mbps sits in the overlap between index 42 (1414-1588, osc 335) and index 43 (1461-1640, osc 208). The backward search picks index 43, programming the lower osc_freq_target of 208 instead of the optimal 335. This causes DDL lock instability and CSI-2 CRC errors on affected configurations, such as the OmniVision OV08X40 sensor on Intel Arrow Lake platforms (Dell Pro Max 16). Rewrite get_hsfreq_by_mbps() to select the optimal band: 1. Among bands whose min/max range covers the data rate, prefer the one with the higher osc_freq_target. 2. If osc_freq_target is equal, prefer the band whose default_mbps is closest to the requested rate. Since the frequency ranges are monotonically increasing, the loop exits early once min exceeds the requested rate. For 1498 Mbps this now correctly selects index 42 (osc_freq_target 335, range 1414-1588) instead of index 43 (osc_freq_target 208, range 1461-1640). Fixes: 1e7eeb301696 ("media: intel/ipu6: add the CSI2 DPHY implementation") Cc: stable@vger.kernel.org Signed-off-by: Marco Nenciarini <mnencia@kcore.it> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-05-05staging: media: ipu7: remove 'U' suffix from hexadecimal literalsLian Xiangyu
The ipu7 driver's TODO specifies that the 'U' suffix should be removed from hexadecimal values in register definitions. This patch cleans up the definitions in the header files within the ipu7 directory to comply with the requirements and improve consistency. The modification was verified by comparing the disassembly of the built-in.a archive before and after the change. The MD5 hashes of the disassembly output remained identical, confirming that this is a purely cosmetic cleanup with no functional impact on the binary. Signed-off-by: Lian Xiangyu <lin25001x@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-05-05staging: media: ipu7: fix double-free and use-after-free in error pathsAlexandru Hossu
In both ipu7_isys_init() and ipu7_psys_init(), pdata is allocated and then passed to ipu7_bus_initialize_device(), which stores it in adev->pdata. The ipu7_bus_release() function frees adev->pdata when the device's reference count drops to zero. Two error paths incorrectly call kfree(pdata) after the device teardown has already freed it: 1. When ipu7_mmu_init() fails: put_device() is called, which drops the reference count to zero and triggers ipu7_bus_release() -> kfree(pdata). The subsequent kfree(pdata) is a double-free. 2. When ipu7_bus_add_device() fails: it calls auxiliary_device_uninit() internally, which calls put_device() -> ipu7_bus_release() -> kfree(pdata). The subsequent kfree(pdata) is again a double-free. Note that the kfree(pdata) when ipu7_bus_initialize_device() itself fails is correct, because in that case auxiliary_device_init() failed and the release function was never set up, so pdata must be freed manually. Additionally, the error code was not saved before calling put_device(), causing ERR_CAST() to dereference the already-freed adev pointer when constructing the return value. Fix this by saving the error from dev_err_probe() before put_device() and returning ERR_PTR() instead. Remove the redundant kfree(pdata) calls and fix the use-after-free in the return values of the two affected error paths. Fixes: b7fe4c0019b1 ("media: staging/ipu7: add Intel IPU7 PCI device driver") Cc: stable@vger.kernel.org Reviewed-by: Dan Carpenter <error27@gmail.com> Signed-off-by: Alexandru Hossu <hossu.alexandru@gmail.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-05-05media: dw9719: Add back the I²C device id tableSakari Ailus
The I²C device id table is necessary as the device may be, besides through system firmware, also instantiated in the IPU bridge so matching takes place using the I²C device id table. Add back the table, with ids for all supported devices. Reported-by: Michael Anthony <manthony.nw@outlook.com> Closes: https://lore.kernel.org/linux-media/AMBP190MB2678E7DC048409068260DCE8ED4AA@AMBP190MB2678.EURP190.PROD.OUTLOOK.COM/ Fixes: 15faf0fa1472 ("media: i2c: dw9719: Remove unused i2c device id table") Cc: stable@vger.kernel.org # for v6.19 and later Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2026-05-05drm/i915: remove HAS_PCH_NOP() dependency from clock gatingLuca Coelho
intel_pch_init_clock_gating() already handles unsupported PCH types, including PCH_NOP, by doing nothing. Drop the explicit HAS_PCH_NOP() check from the IVB clock gating path and always call the display helper directly. This removes one more direct dependency on display-side PCH macros from intel_clock_gating.c. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260428095104.818360-9-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-05-05drm/i915/display: move pre-HSW clock gating init to displayLuca Coelho
Move the remaining pre-HSW display clock gating programming into display. This also drops display register includes from intel_clock_gating.c. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260428095104.818360-8-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-05-05drm/i915/display: move HSW and BDW clock gating init to displayLuca Coelho
Move the HSW and BDW display clock gating programming into the display code. In this case we need two different helpers, because the common code between these two is split in the middle. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260428095104.818360-7-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-05-05drm/i915/display: move GLK clock gating init to displayLuca Coelho
Move the GLK-specific display clock gating programming into display intel_display_clock_gating.c, to remove more dependencies from i915 to display registers. Now that all remaining Gen9-family callers moved into display, we can move the shared Gen9 display clock gating helper into display and remove the old local helper from intel_clock_gating.c. Additionally, the SKL_DE_COMPRESSED_HASH_MODE programming was protected by HAS_LLC(), but that's incidental, because in Gen9 platforms, only SKL and KBL, for which this workaround applies, have LLC(). In order not to use HAS_LLC() in display code, we can simply remove this check from the generic Gen9 function and move the SKL_DE_COMPRESSED_HASH_MODE programming to the KBL and SKL specific functions. And, intentionally or not, CFL and CML were also using this workaround, because they also have LLC, even though the comments were only mentioning SKL and KBL. In order not to change anything functionally with this patch, the workaround was also added to intel_display_cfl_init_clock_gating(). Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260428095104.818360-6-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-05-05drm/i915/display: move BXT clock gating init to displayLuca Coelho
Move the BXT-specific display clock gating programming into display intel_display_clock_gating.c, to remove more dependencies from i915. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260428095104.818360-5-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-05-05drm/i915/display: move CFL clock gating init to displayLuca Coelho
Move the CFL/CML-specific display clock gating programming into display intel_display_clock_gating.c, to remove more dependencies from i915 to display registers. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260428095104.818360-4-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-05-05drm/i915: move KBL clock gating init to displayLuca Coelho
Move the KBL-specific display clock gating programming into a display intel_display_clock_gating.c, to remove more dependencies from i915 to display registers. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260428095104.818360-3-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-05-05drm/i915: move SKL clock gating init to displayLuca Coelho
Move the SKL-specific display clock gating programming into a new file inside display. This removes dependency from intel_clock_gating.c to the display's intel_pch.h file, so we can remove the include statement. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patch.msgid.link/20260428095104.818360-2-luciano.coelho@intel.com Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
2026-05-05regulator: palmas: Move MODULE_DEVICE_TABLE next to the table itselfKrzysztof Kozlowski
By convention MODULE_DEVICE_TABLE() immediately follows the ID table it exports, because this is easier to read and verify. It also makes more sense since #ifdef for ACPI or OF could hide both of them. Most of the privers already have this correctly placed, so adjust the missing ones. No functional impact. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Link: https://patch.msgid.link/20260505102734.180464-2-krzysztof.kozlowski@oss.qualcomm.com Signed-off-by: Mark Brown <broonie@kernel.org>
2026-05-05thunderbolt: Don't create multiple DMA tunnels on firmware connection managerAlan Borzeszkowski
Firmware connection manager supports only one DMA tunnel per XDomain connection. Firmware prior Intel Titan Ridge failed the operation directly but the same does not happen anymore on Titan Ridge and forward. For this reason add an explicit check, and fail the operation accordingly in the driver. Signed-off-by: Alan Borzeszkowski <alan.borzeszkowski@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Remove XDomain from the bus without holding tb->lockMika Westerberg
Currently we call device_unregister() for services and the XDomain itself with tb->lock held. This prevents the service drivers from calling any functions that may take it. For this reason separate removing the XDomain from the topology data structures (where we need the lock) from unregistering the device from the bus (where remove callbacks of the drivers are being called). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Remove service debugfs entries during unregisterMika Westerberg
We add them as part of the register path so to keep it symmetric remove them as part of the unregister path. This also removes them even if the service itself is not yet released (but is unregistered), thus allowing new register with the same service name to happen. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: dma_test: No need to store debugfs directory pointerMika Westerberg
We don't actually need to store the debugfs directory pointer inside struct dma_test. Instead we can use the debugfs_lookup_and_remove() which also handles the case if the debugfs directory is already removed by the core driver (for example when cable is disconnected). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Keep XDomain reference during the lifetime of a serviceMika Westerberg
This is needed because we release the service ID in tb_service_release() and the ID array is owned by the parent XDomain. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Wait for tb_domain_release() to complete when driver is removedMika Westerberg
We should not call nhi_shutdown() before the domain structure and the control channel rings are completely released. Otherwise we might release resources like the nhi->msix_ida that are still referenced in tb_domain_release(). For this reason wait for the tb_domain_release() to be completed before continuing to nhi_shutdown() and eventually releasing of the rest of the data structures. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Set tb->root_switch to NULL when domain is stoppedMika Westerberg
Similarly what we do with the firmware connection manager. This makes tb_xdp_handle_request() return error to the remote host. However, we need to make sure we keep the uuid alive so that we can reply until the whole domain is released. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Release request if tb_cfg_request() fails in ↵Mika Westerberg
__tb_xdomain_response() If tb_cfg_request() fails setting up the request (for example the control channel is shut down already) it returns an error without calling the callback. To avoid leaking that memory, call tb_cfg_request_put() if tb_cfg_request() fails. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Keep the domain reference while processing hotplugMika Westerberg
We process hotplug events in a workqueue that may run after the domain has been removed by tb_domain_remove(). For example if user unloads the driver while at the same time plugging a device router we may have scheduled tb_handle_hotplug() to run. Avoid possible UAF in this case by taking the domain reference before scheduling the hotplug handler in tb_queue_hotplug(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Make XDomain lane bonding comply with the USB4 v2 specMika Westerberg
The USB4 v2 Inter-Domain spec "unified" the lane bonding flow so that when the other end (with higher UUID) is not yet set the target link width accordingly it is expected to reply with ERROR_NOT_READY. Implement this for Linux. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Don't disable lane adapter if XDomain lane bonding isn't possibleMika Westerberg
This happens when firmware connection manager is being used. It will deal with disabling the lane 1 adapter after the tunnel has been established and re-enabling it afterwards. For this reason only do this when we know that lane bonding is possible (e.g running software connection manager). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05thunderbolt: Avoid reserved fields in path config space for USB4 routersGil Fine
According to USB4 spec, USB4 Connection Manager shall not change value of any fields that are defined as "RsvdZ" or "VD". Specifically fields: Path Credits Allocated, IFC, ISE fields in path config space shall not be written by CM. To handle this, CM shall first read current path config space from the hardware, change only the fields that can be changed, and then write back the path config space. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2026-05-05wifi: cfg80211: Add MAC address filter to remain_on_channelPeddolla Harshavardhan Reddy
Currently the remain_on_channel operation does not support filtering incoming frames by destination MAC address. This prevents use cases such as PASN authentication in the responder side that need to receive frames addressed to a specific MAC during the off-channel period. Add an rx_addr parameter to the remain_on_channel operation callback and propagate it through the call chain from nl80211 to driver implementations. Introduce the extended feature NL80211_EXT_FEATURE_ROC_ADDR_FILTER as a capability gate so that cfg80211 rejects the request if the driver does not advertise support for address filtering. Extract the address from the NL80211_ATTR_MAC attribute when provided in the netlink message and update the tracing infrastructure to include the address in remain_on_channel trace events. The rx_addr parameter is optional and can be NULL, maintaining backward compatibility with existing drivers. Signed-off-by: Peddolla Harshavardhan Reddy <peddolla.reddy@oss.qualcomm.com> Link: https://patch.msgid.link/20260420090856.2152905-3-peddolla.reddy@oss.qualcomm.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
2026-05-05soc: ti: k3-socinfo: Add support for AM62P variants via NVMEMJudith Mendez
Add support for detecting AM62P silicon revisions. On AM62P, silicon revision is discovered with GP_SW1 register instead of JTAGID register. Use the NVMEM framework to read GP_SW1 from the gpsw-efuse nvmem provider to determine SoC revision. Signed-off-by: Judith Mendez <jm@ti.com> Reviewed-by: Andrew Davis <afd@ti.com> Link: https://patch.msgid.link/20260209172330.53623-3-jm@ti.com Signed-off-by: Nishanth Menon <nm@ti.com>
2026-05-05drm: xlnx: zynqmp: Add support for XVUY2101010Tomi Valkeinen
Add support for XVUY2101010 format. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-11-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm: xlnx: zynqmp: Add support for T430Tomi Valkeinen
Add support for T430 format. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-10-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm: xlnx: zynqmp: Add support for Y8 and XYYY2101010Tomi Valkeinen
Add support for Y8 and XYYY2101010 formats. We also need to add new csc matrices for these y-only formats. Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-9-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm: xlnx: zynqmp: Add support for P030 & P230Tomi Valkeinen
Add support for P030 & P230 formats. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-8-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm: xlnx: zynqmp: Use drm helpers when calculating buffer sizesTomi Valkeinen
Use drm helpers, drm_format_info_plane_width(), drm_format_info_plane_height() and drm_format_info_min_pitch() to calculate sizes for the DMA. This cleans up the code, but also makes it possible to support more complex formats (like P030, P230). Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-7-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm/fourcc: Add DRM_FORMAT_XVUY2101010Tomi Valkeinen
Add XVUY2101010, a 10 bits per component YCbCr format in a 32 bit container. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-6-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm/fourcc: Add DRM_FORMAT_T430Tomi Valkeinen
Add T430, a 3 plane 10 bits per component non-subsampled YCbCr format. A new initial letter was chosen for this one, as the format doesn't match the existing P, Q or S formats. T is the next one in the alphabet. It was definitely not chosen because of the initial letter in the author's name. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-5-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm/fourcc: Add DRM_FORMAT_XYYY2101010Tomi Valkeinen
Add XYYY2101010 ("YPA4"), a 10 bit greyscale format, with 3 pixels packed into 32-bit container, and two bits of padding. The fourcc for the format is 'YPA4', which comes from Y - Y only, P - packed, A - 10 (as in 0xA), 4 - 4 bytes. Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-4-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm/fourcc: Add DRM_FORMAT_Y8Tomi Valkeinen
Add greyscale Y8 format. The 8-bit greyscale format has been discussed before, and the earlier guidance was to use DRM_FORMAT_R8, as a single-channel 8-bit pixel. However, adding DRM_FORMAT_Y8 makes sense, we can mark it as 'is_yuv' in the drm_format_info, and this can help the drivers handle e.g. full/limited range. This will distinguish two single-channel formats: R8, which is a RGB format with the same value for all components, and Y8, which is a Y-only YCbCr format, with Cb and Cr being neutral. Acked-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Acked-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-3-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm/fourcc: Add DRM_FORMAT_P230Tomi Valkeinen
Add a new pixel format, DRM_FORMAT_P230 ("P230") P230 is 2 plane 10 bit per component YCbCr 2x1 subsampled format. P230 is similar to the already existing P030 format, which is 2x2 subsampled. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Vishal Sagar <vishal.sagar@amd.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-2-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
2026-05-05drm/fourcc: Add warning for bad bppTomi Valkeinen
drm_format_info_bpp() cannot be used for formats which do not have an integer bits-per-pixel in a pixel block. E.g. DRM_FORMAT_P030's plane 0 has three 10-bit pixels (Y components), and two padding bits, in a 4 byte block. That is 10.666... bits per pixel when considering the whole 4 byte block, which is what drm_format_info_bpp() does. Thus a driver that supports such formats cannot use drm_format_info_bpp(), It is a driver bug if this happens, but so handle wrong calls by printing a warning and returning 0. Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-by: Simon Ser <contact@emersion.fr> Link: https://patch.msgid.link/20260423-xilinx-formats-v10-1-c690c2b8ea89@ideasonboard.com Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>