summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-12-23usb: ohci-nxp: fix device leak on probe failureJohan Hovold
Make sure to drop the reference taken when looking up the PHY I2C device during probe on probe failure (e.g. probe deferral) and on driver unbind. Fixes: 73108aa90cbf ("USB: ohci-nxp: Use isp1301 driver") Cc: stable@vger.kernel.org # 3.5 Reported-by: Ma Ke <make24@iscas.ac.cn> Link: https://lore.kernel.org/lkml/20251117013428.21840-1-make24@iscas.ac.cn/ Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://patch.msgid.link/20251218153519.19453-4-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23usb: phy: isp1301: fix non-OF device reference imbalanceJohan Hovold
A recent change fixing a device reference leak in a UDC driver introduced a potential use-after-free in the non-OF case as the isp1301_get_client() helper only increases the reference count for the returned I2C device in the OF case. Increment the reference count also for non-OF so that the caller can decrement it unconditionally. Note that this is inherently racy just as using the returned I2C device is since nothing is preventing the PHY driver from being unbound while in use. Fixes: c84117912bdd ("USB: lpc32xx_udc: Fix error handling in probe") Cc: stable@vger.kernel.org Cc: Ma Ke <make24@iscas.ac.cn> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://patch.msgid.link/20251218153519.19453-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23usb: gadget: lpc32xx_udc: fix clock imbalance in error pathJohan Hovold
A recent change fixing a device reference leak introduced a clock imbalance by reusing an error path so that the clock may be disabled before having been enabled. Note that the clock framework allows for passing in NULL clocks so there is no risk for a NULL pointer dereference. Also drop the bogus I2C client NULL check added by the offending commit as the pointer has already been verified to be non-NULL. Fixes: c84117912bdd ("USB: lpc32xx_udc: Fix error handling in probe") Cc: stable@vger.kernel.org Cc: Ma Ke <make24@iscas.ac.cn> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Vladimir Zapolskiy <vz@mleia.com> Link: https://patch.msgid.link/20251218153519.19453-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23usb: typec: ucsi: Get connector status after enable notificationsHsin-Te Yuan
Originally, the notification for connector change will be enabled after the first read of the connector status. Therefore, if the event happens during this window, it will be missing and make the status unsynced. Get the connector status only after enabling the notification for connector change to ensure the status is synced. Fixes: c1b0bc2dabfa ("usb: typec: Add support for UCSI interface") Cc: stable <stable@kernel.org> Tested-by: Kenneth R. Crudup <kenny@panix.com> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Hsin-Te Yuan <yuanhsinte@chromium.org> Link: https://patch.msgid.link/20251218-ucsi-v7-1-aea83e83fb12@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23usb: usb-storage: Maintain minimal modifications to the bcdDevice range.Chen Changcheng
We cannot determine which models require the NO_ATA_1X and IGNORE_RESIDUE quirks aside from the EL-R12 optical drive device. Fixes: 955a48a5353f ("usb: usb-storage: No additional quirks need to be added to the EL-R12 optical drive.") Signed-off-by: Chen Changcheng <chenchangcheng@kylinos.cn> Link: https://patch.msgid.link/20251218012318.15978-1-chenchangcheng@kylinos.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23usb: dwc3: Add Google Tensor SoC DWC3 glue driverRoy Luo
Add support for the DWC3 USB controller found on Google Tensor G5 (codename: laguna). The controller features dual-role functionality and hibernation. The primary focus is implementing hibernation support in host mode, enabling the controller to enter a low-power state (D3). This is particularly relevant during system power state transition and runtime power management for power efficiency. Highlights: - Align suspend callback with dwc3_suspend_common() for deciding between a full teardown and hibernation in host mode. - Integration with `psw` (power switchable) and `top` power domains, managing their states and device links to support hibernation. - A notifier callback dwc3_google_usb_psw_pd_notifier() for `psw` power domain events to manage controller state transitions to/from D3. - Coordination of the `non_sticky` reset during power state transitions, asserting it on D3 entry and deasserting on D0 entry in hibernation scenario. - Handling of high-speed and super-speed PME interrupts that are generated by remote wakeup during hibernation. Co-developed-by: Joy Chakraborty <joychakr@google.com> Signed-off-by: Joy Chakraborty <joychakr@google.com> Co-developed-by: Naveen Kumar <mnkumar@google.com> Signed-off-by: Naveen Kumar <mnkumar@google.com> Reviewed-by: Peter Griffin <peter.griffin@linaro.org> Signed-off-by: Roy Luo <royluo@google.com> Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com> Link: https://patch.msgid.link/20251218-controller-v10-2-4047c9077274@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23dt-bindings: usb: dwc3: Add Google Tensor G5 DWC3Roy Luo
Document the device tree bindings for the DWC3 USB controller found in Google Tensor SoCs, starting with the G5 generation (codename: laguna). The Tensor G5 silicon represents a complete architectural departure from previous generations (like gs101), including entirely new clock/reset schemes, top-level wrapper and register interface. Consequently, existing Samsung/Exynos DWC3 USB bindings are incompatible, necessitating this new device tree binding. The USB controller on Tensor G5 is based on Synopsys DWC3 IP and features Dual-Role Device single port with hibernation support. Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Roy Luo <royluo@google.com> Link: https://patch.msgid.link/20251218-controller-v10-1-4047c9077274@google.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23usb: gadget: Constify struct configfs_item_operations and ↵Christophe JAILLET
configfs_group_operations 'struct configfs_item_operations' and 'configfs_group_operations' are not modified in these drivers. Constifying these structures moves some data to a read-only section, so increases overall security, especially when the structure holds some function pointers. On a x86_64, with allmodconfig, as an example: Before: ====== text data bss dec hex filename 65061 20968 256 86285 1510d drivers/usb/gadget/configfs.o After: ===== text data bss dec hex filename 66181 19848 256 86285 1510d drivers/usb/gadget/configfs.o Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://patch.msgid.link/49cec1cb84425f854de80b6d69b53a5a3cda8189.1766164523.git.christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23smc91x: fix broken irq-context in PREEMPT_RTYeoreum Yun
When smc91x.c is built with PREEMPT_RT, the following splat occurs in FVP_RevC: [ 13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000 [ 13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106] [ 13.062137] preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work [ 13.062266] C ** replaying previous printk message ** [ 13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)} [ 13.062353] Hardware name: , BIOS [ 13.062382] Workqueue: mld mld_ifc_work [ 13.062469] Call trace: [ 13.062494] show_stack+0x24/0x40 (C) [ 13.062602] __dump_stack+0x28/0x48 [ 13.062710] dump_stack_lvl+0x7c/0xb0 [ 13.062818] dump_stack+0x18/0x34 [ 13.062926] process_scheduled_works+0x294/0x450 [ 13.063043] worker_thread+0x260/0x3d8 [ 13.063124] kthread+0x1c4/0x228 [ 13.063235] ret_from_fork+0x10/0x20 This happens because smc_special_trylock() disables IRQs even on PREEMPT_RT, but smc_special_unlock() does not restore IRQs on PREEMPT_RT. The reason is that smc_special_unlock() calls spin_unlock_irqrestore(), and rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke rcu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero. To address this issue, replace smc_special_trylock() with spin_trylock_irqsave(). Fixes: 342a93247e08 ("locking/spinlock: Provide RT variant header: <linux/spinlock_rt.h>") Signed-off-by: Yeoreum Yun <yeoreum.yun@arm.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20251217085115.1730036-1-yeoreum.yun@arm.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-12-23RDMA/bnxt_re: Fix to use correct page size for PDE tableKalesh AP
In bnxt_qplib_alloc_init_hwq(), while allocating memory for PDE table driver incorrectly is using the "pg_size" value passed to the function. Fixed to use the right value 4K. Also, fixed the allocation size for PBL table. Fixes: 0c4dcd602817 ("RDMA/bnxt_re: Refactor hardware queue memory allocation") Signed-off-by: Damodharam Ammepalli <damodharam.ammepalli@broadcom.com> Signed-off-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Link: https://patch.msgid.link/20251223131855.145955-1-kalesh-anakkur.purayil@broadcom.com Reviewed-by: Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by: Leon Romanovsky <leon@kernel.org>
2025-12-23ASoC: Intel: avs: replace strcmp with sysfs_streqBrahmajit Das
allmodconfig failes to build with GCC 16 with the following build error sound/soc/intel/avs/path.c:137:38: error: ‘strcmp’ reading 1 or more bytes from a region of size 0 [-Werror=stringop-overread] 137 | return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ‘avs_condpaths_walk’: events 1-3 137 | return id->id == id2->id && !strcmp(id->tplg_name, id2->tplg_name); | ~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | | | (3) warning happens here | (1) when the condition is evaluated to true ...... 155 | if (id->id != path->template->owner->id || | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | (2) when the condition is evaluated to false 156 | strcmp(id->tplg_name, path->template->owner->owner->name)) | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from sound/soc/intel/avs/path.h:14, from sound/soc/intel/avs/path.c:15: sound/soc/intel/avs/topology.h: In function ‘avs_condpaths_walk’: sound/soc/intel/avs/topology.h:152:13: note: at offset 4 into source object ‘id’ of size 4 152 | u32 id; | ^~ Using the sysfs_streq as an alternative to strcmp helps getting around this build failure. Please also refer https://docs.kernel.org/core-api/kernel-api.html#c.__sysfs_match_string Signed-off-by: Brahmajit Das <listout@listout.xyz> Link: https://patch.msgid.link/20251221185531.6453-1-listout@listout.xyz Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-23ASoC: rockchip: Discard pm_runtime_put() return valueRafael J. Wysocki
It is better to check directly whether or not CONFIG_PM has been enabled instead of relying on an error value returned by pm_runtime_put() in that case because pm_runtime_put() may also return an error value in other cases, like after writing "on" to the devices' runtime PM "control" attribute in sysfs for one example. This will facilitate a planned change of the pm_runtime_put() return type to void in the future. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/5160923.0VBMTVartN@rafael.j.wysocki Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-23PCI: imx6: Add external reference clock input mode supportRichard Zhu
i.MX95 PCIes have two reference clock inputs: one from internal PLL, the other from off chip crystal oscillator. The "extref" clock refers to a reference clock from an external crystal oscillator. Add external reference clock input mode support for i.MX95 PCIes. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Link: https://patch.msgid.link/20251211064821.2707001-4-hongxing.zhu@nxp.com
2025-12-23dt-bindings: PCI: pci-imx6: Add external reference clock inputRichard Zhu
i.MX95 PCIes have two reference clock inputs: one from internal PLL. It's wired inside chip and present as "ref" clock. It's not an optional clock. The other from off chip crystal oscillator. The "extref" clock refers to a reference clock from an external crystal oscillator through the CLKIN_N/P pair PADs. It is an optional clock, relied on the board design. Add additional optional external reference clock input for i.MX95 PCIes. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Link: https://patch.msgid.link/20251211064821.2707001-3-hongxing.zhu@nxp.com
2025-12-23dt-bindings: PCI: dwc: Add external reference clock inputRichard Zhu
Add external reference clock input "extref" for a reference clock that comes from external crystal oscillator. Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Reviewed-by: Frank Li <Frank.Li@nxp.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20251211064821.2707001-2-hongxing.zhu@nxp.com
2025-12-23PCI: xilinx: Fix INTx IRQ domain leak in error pathsHaotian Zhang
In xilinx_pcie_init_irq_domain(), if xilinx_allocate_msi_domains() fails after pcie->leg_domain has been successfully created via irq_domain_create_linear(), the function returns directly without cleaning up the allocated IRQ domain, resulting in a resource leak. In xilinx_free_msi_domains(), pcie->leg_domain is also neglected. Add irq_domain_remove() call in the error path to properly release the IRQ domain before returning the error. Also rename xilinx_free_msi_domains() to xilinx_free_irq_domains() and add the release of pcie->leg_domain to it. Fixes: 313b64c3ae52 ("PCI: xilinx: Convert to MSI domains") Suggested-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251219021615.965-1-vulab@iscas.ac.cn
2025-12-23dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Update pcie phy bindings for ↵Ziyue Zhang
qcs8300 The gcc_aux_clk is not required by the PCIe PHY on qcs8300 and is not specified in the device tree node. Hence, move the qcs8300 phy compatibility entry into the list of PHYs that require six clocks. Removed the phy_aux clock from the PCIe PHY binding as it is no longer used by any instance. Fixes: e46e59b77a9e ("dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Document the QCS8300 QMP PCIe PHY Gen4 x2") Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Acked-by: Manivannan Sadhasivam <mani@kernel.org> Acked-by: Rob Herring (Arm) <robh@kernel.org> Reviewed-by: Johan Hovold <johan+linaro@kernel.org> Link: https://patch.msgid.link/20251128104928.4070050-2-ziyue.zhang@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23phy: fsl-imx8mq-usb: fix typec orientation switch when built as moduleFranz Schnyder
Currently, the PHY only registers the typec orientation switch when it is built in. If the typec driver is built as a module, the switch registration is skipped due to the preprocessor condition, causing orientation detection to fail. With commit 45fe729be9a6 ("usb: typec: Stub out typec_switch APIs when CONFIG_TYPEC=n") the preprocessor condition is not needed anymore and the orientation switch is correctly registered for both built-in and module builds. Fixes: b58f0f86fd61 ("phy: fsl-imx8mq-usb: add tca function driver for imx95") Cc: stable@vger.kernel.org Suggested-by: Xu Yang <xu.yang_2@nxp.com> Signed-off-by: Franz Schnyder <franz.schnyder@toradex.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Reviewed-by: Xu Yang <xu.yang_2@nxp.com> Link: https://patch.msgid.link/20251126140136.1202241-1-fra.schnyder@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23platform/x86/intel/pmt: Fix kobject memory leak on init failureKaushlendra Kumar
When kobject_init_and_add() fails in pmt_features_discovery(), the function returns without calling kobject_put(). This violates the kobject API contract where kobject_put() must be called even on initialization failure to properly release allocated resources. Fixes: d9a078809356 ("platform/x86/intel/pmt: Add PMT Discovery driver") Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar@intel.com> Link: https://patch.msgid.link/20251223084041.3832933-1-kaushlendra.kumar@intel.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
2025-12-23Merge tag 'for-net-2025-12-19' of ↵Paolo Abeni
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - MGMT: report BIS capability flags in supported settings - btusb: revert use of devm_kzalloc in btusb * tag 'for-net-2025-12-19' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: btusb: revert use of devm_kzalloc in btusb Bluetooth: MGMT: report BIS capability flags in supported settings ==================== Link: https://patch.msgid.link/20251219223118.90141-1-luiz.dentz@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-12-23net: wangxun: move PHYLINK dependencyArnd Bergmann
The LIBWX library code is what calls into phylink, so any user of it has to select CONFIG_PHYLINK at the moment, with NGBEVF missing this: x86_64-linux-ld: drivers/net/ethernet/wangxun/libwx/wx_ethtool.o: in function `wx_nway_reset': wx_ethtool.c:(.text+0x613): undefined reference to `phylink_ethtool_nway_reset' x86_64-linux-ld: drivers/net/ethernet/wangxun/libwx/wx_ethtool.o: in function `wx_get_link_ksettings': wx_ethtool.c:(.text+0x62b): undefined reference to `phylink_ethtool_ksettings_get' x86_64-linux-ld: drivers/net/ethernet/wangxun/libwx/wx_ethtool.o: in function `wx_set_link_ksettings': wx_ethtool.c:(.text+0x643): undefined reference to `phylink_ethtool_ksettings_set' x86_64-linux-ld: drivers/net/ethernet/wangxun/libwx/wx_ethtool.o: in function `wx_get_pauseparam': wx_ethtool.c:(.text+0x65b): undefined reference to `phylink_ethtool_get_pauseparam' x86_64-linux-ld: drivers/net/ethernet/wangxun/libwx/wx_ethtool.o: in function `wx_set_pauseparam': wx_ethtool.c:(.text+0x677): undefined reference to `phylink_ethtool_set_pauseparam' Add the 'select PHYLINK' line in the libwx option directly so this will always be enabled for all current and future wangxun drivers, and remove the now duplicate lines. Fixes: a0008a3658a3 ("net: wangxun: add ngbevf build") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Link: https://patch.msgid.link/20251216213547.115026-1-arnd@kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-12-23selftests: net: fix "buffer overflow detected" for tap.cAlice C. Munduruca
When the selftest 'tap.c' is compiled with '-D_FORTIFY_SOURCE=3', the strcpy() in rtattr_add_strsz() is replaced with a checked version which causes the test to consistently fail when compiled with toolchains for which this option is enabled by default. TAP version 13 1..3 # Starting 3 tests from 1 test cases. # RUN tap.test_packet_valid_udp_gso ... *** buffer overflow detected ***: terminated # test_packet_valid_udp_gso: Test terminated by assertion # FAIL tap.test_packet_valid_udp_gso not ok 1 tap.test_packet_valid_udp_gso # RUN tap.test_packet_valid_udp_csum ... *** buffer overflow detected ***: terminated # test_packet_valid_udp_csum: Test terminated by assertion # FAIL tap.test_packet_valid_udp_csum not ok 2 tap.test_packet_valid_udp_csum # RUN tap.test_packet_crash_tap_invalid_eth_proto ... *** buffer overflow detected ***: terminated # test_packet_crash_tap_invalid_eth_proto: Test terminated by assertion # FAIL tap.test_packet_crash_tap_invalid_eth_proto not ok 3 tap.test_packet_crash_tap_invalid_eth_proto # FAILED: 0 / 3 tests passed. # Totals: pass:0 fail:3 xfail:0 xpass:0 skip:0 error:0 A buffer overflow is detected by the fortified glibc __strcpy_chk() since the __builtin_object_size() of `RTA_DATA(rta)` is incorrectly reported as 1, even though there is ample space in its bounding buffer `req`. Additionally, given that IFLA_IFNAME also expects a null-terminated string, callers of rtaddr_add_str{,sz}() could simply use the rtaddr_add_strsz() variant. (which has been renamed to remove the trailing `sz`) memset() has been used for this function since it is unchecked and thus circumvents the issue discussed in the previous paragraph. Fixes: 2e64fe4624d1 ("selftests: add few test cases for tap driver") Signed-off-by: Alice C. Munduruca <alice.munduruca@canonical.com> Reviewed-by: Cengiz Can <cengiz.can@canonical.com> Reviewed-by: Willem de Bruijn <willemb@google.com> Link: https://patch.msgid.link/20251216170641.250494-1-alice.munduruca@canonical.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-12-23PCI: dwc: ep: Cache MSI outbound iATU mappingKoichiro Den
dw_pcie_ep_raise_msi_irq() currently programs an outbound iATU window for the MSI target address on every interrupt and tears it down again via dw_pcie_ep_unmap_addr(). On systems that heavily use the AXI bridge interface (for example when the integrated eDMA engine is active), this means the outbound iATU registers are updated while traffic is in flight. The DesignWare endpoint databook 5.40a - "3.10.6.1 iATU Outbound Programming Overview" warns that updating iATU registers in this situation is not supported, and the behavior is undefined. Under high MSI and eDMA load this pattern results in occasional bogus outbound transactions and IOMMU faults, on the RC side, such as: ipmmu-vmsa eed40000.iommu: Unhandled fault: status 0x00001502 iova 0xfe000000 followed by the system becoming unresponsive. This is the actual output observed on Renesas R-Car S4, with its ipmmu_hc used with PCIe ch0. There is no need to reprogram the iATU region used for MSI on every interrupt. The host-provided MSI address is stable while MSI is enabled, and the endpoint driver already dedicates a scratch buffer for MSI generation. Cache the aligned MSI address and map size, program the outbound iATU once, and keep the window enabled. Subsequent interrupts only perform a write to the MSI scratch buffer, avoiding dynamic iATU reprogramming in the hot path and fixing the lockups seen under load. dw_pcie_ep_raise_msix_irq() is not modified, as each vector can have a different msg_addr, and because the msg_addr is allowed to be changed while the vector is masked. Neither problem is easy to solve with the current design. Instead, the plan is for the DWC vendor drivers to transition to dw_pcie_ep_raise_msix_irq_doorbell(), which does not rely on the iATU. Signed-off-by: Koichiro Den <den@valinux.co.jp> [cassel: improve commit message] Signed-off-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Manivannan Sadhasivam <mani@kernel.org> Link: https://patch.msgid.link/20251222110144.3299523-2-cassel@kernel.org
2025-12-23dt-bindings: dma: Update ADMA bindings for tegra264sheetal
- Update ADMA device tree bindings for tegra264 to support up to 64 interrupt channels by setting 'interrupts' property maxItems to 64. - Also, update the 'allOf' conditional schema to ensure correct maxItems for 'interrupts' based on compatible string, including tegra210 (22) and tegra186 (32) ADMA controllers. Signed-off-by: sheetal <sheetal@nvidia.com> Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Acked-by: Thierry Reding <treding@nvidia.com> Link: https://patch.msgid.link/20250929105930.1767294-2-sheetal@nvidia.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dma: dma-axi-dmac: simplify axi_dmac_parse_dt()Nuno Sá
Simplify axi_dmac_parse_dt() by using the cleanup device_node class for automatically releasing the of_node reference when going out of scope. Signed-off-by: Nuno Sá <nuno.sa@analog.com> base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-4-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dma: dma-axi-dmac: support bigger than 32bits addressesNuno Sá
In some supported platforms as ARCH_ZYNQMP, part of the memory is mapped above 32bit addresses and since the DMA mask, by default, is set to 32bits, we would need to rely on swiotlb (which incurs a performance penalty) for the DMA mappings. Thus, we can write either the SRC or DEST high addresses with 1's and read them back. The last bit set on the return value will reflect the IP address bus width and so we can update the device DMA mask accordingly. While at it, support bigger that 32 bits transfers in IP without HW scatter gather support. Signed-off-by: Nuno Sá <nuno.sa@analog.com> base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-3-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dma: dma-axi-dmac: fix HW scatter-gather not looking at the queueNuno Sá
For HW scatter gather transfers we still need to look for the queue. The HW is capable of queueing 3 concurrent transfers and if we try more than that we'll get the submit queue full and should return. Otherwise, if we go ahead and program the new transfer, we end up discarding it. Fixes: e97dc7435972 ("dmaengine: axi-dmac: Add support for scatter-gather transfers") Signed-off-by: Nuno Sá <nuno.sa@analog.com> base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-2-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dma: dma-axi-dmac: fix SW cyclic transfersNuno Sá
If 'hw_cyclic' is false we should still be able to do cyclic transfers in "software". That was not working for the case where 'desc->num_sgs' is 1 because 'chan->next_desc' is never set with the current desc which means that the cyclic transfer only runs once and in the next SOT interrupt we do nothing since vchan_next_desc() will return NULL. Fix it by setting 'chan->next_desc' as soon as we get a new desc via vchan_next_desc(). Fixes: 0e3b67b348b8 ("dmaengine: Add support for the Analog Devices AXI-DMAC DMA controller") Signed-off-by: Nuno Sá <nuno.sa@analog.com> base-commit: 398035178503bf662281bbffb4bebce1460a4bc5 change-id: 20251104-axi-dmac-fixes-and-improvs-e3ad512a329c Acked-by: Michael Hennerich <michael.hennerich@analog.com> Link: https://patch.msgid.link/20251104-axi-dmac-fixes-and-improvs-v1-1-3e6fd9328f72@analog.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23net: usb: rtl8150: fix memory leak on usb_submit_urb() failureDeepakkumar Karn
In async_set_registers(), when usb_submit_urb() fails, the allocated async_req structure and URB are not freed, causing a memory leak. The completion callback async_set_reg_cb() is responsible for freeing these allocations, but it is only called after the URB is successfully submitted and completes (successfully or with error). If submission fails, the callback never runs and the memory is leaked. Fix this by freeing both the URB and the request structure in the error path when usb_submit_urb() fails. Reported-by: syzbot+8dd915c7cb0490fc8c52@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=8dd915c7cb0490fc8c52 Fixes: 4d12997a9bb3 ("drivers: net: usb: rtl8150: concurrent URB bugfix") Signed-off-by: Deepakkumar Karn <dkarn@redhat.com> Link: https://patch.msgid.link/20251216151304.59865-2-dkarn@redhat.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-12-23thermal: intel: intel_tcc_cooling: Add CPU models in the support listSrinivas Pandruvada
Add Panther Lake, Wildcat Lake and Nova Lake CPU models in the support list. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Link: https://patch.msgid.link/20251218195150.3872795-1-srinivas.pandruvada@linux.intel.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-12-23dmaengine: st_fdma: add COMPILE_TEST supportRosen Penev
Add COMPILE_TEST as an option to allow test building the driver. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20251106022015.84970-3-rosenp@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dmaengine: st_fdma: change dreg_line to longRosen Penev
The code is encoding a pointer into an int which works fine with a 32-bit build. Not with a 64-bit one. Signed-off-by: Rosen Penev <rosenp@gmail.com> Link: https://patch.msgid.link/20251106022015.84970-2-rosenp@gmail.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23Merge branch 'selftests-drv-net-psp-fix-templated-test-names-in-psp-py'Paolo Abeni
Daniel Zahka says: ==================== selftests: drv-net: psp: fix templated test names in psp.py The templated test names in psp.py had a bug that was not exposed until 80970e0fc07e ("selftests: net: py: extract the case generation logic") changed the order of test case evaluation and test case name extraction. The test cases created in psp_ip_ver_test_builder() and ipver_test_builder() were only assigning formatted names to the test cases they returned, when the test itself was run. This series moves the test case naming to the point where the test function is created. Using netdevsim psp: Before: ./tools/testing/selftests/drivers/net/psp.py TAP version 13 1..28 ok 1 psp.test_case ok 2 psp.test_case ok 3 psp.test_case ok 4 psp.test_case ok 5 psp.test_case ok 6 psp.test_case ok 7 psp.test_case ok 8 psp.test_case ok 9 psp.test_case ok 10 psp.test_case ok 11 psp.dev_list_devices ... ok 28 psp.removal_device_bi # Totals: pass:28 fail:0 xfail:0 xpass:0 skip:0 error:0 # # Responder logs (0): # STDERR: # Set PSP enable on device 3 to 0xf # Set PSP enable on device 3 to 0x0 After: ./tools/testing/selftests/drivers/net/psp.py TAP version 13 1..28 ok 1 psp.data_basic_send_v0_ip4 ok 2 psp.data_basic_send_v0_ip6 ok 3 psp.data_basic_send_v1_ip4 ok 4 psp.data_basic_send_v1_ip6 ok 5 psp.data_basic_send_v2_ip4 ok 6 psp.data_basic_send_v2_ip6 ok 7 psp.data_basic_send_v3_ip4 ok 8 psp.data_basic_send_v3_ip6 ok 9 psp.data_mss_adjust_ip4 ok 10 psp.data_mss_adjust_ip6 ok 11 psp.dev_list_devices ... ok 28 psp.removal_device_bi # Totals: pass:28 fail:0 xfail:0 xpass:0 skip:0 error:0 # # Responder logs (0): # STDERR: # Set PSP enable on device 3 to 0xf # Set PSP enable on device 3 to 0x0 Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> ==================== Link: https://patch.msgid.link/20251216-psp-test-fix-v1-0-3b5a6dde186f@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-12-23selftests: drv-net: psp: fix test names in ipver_test_builder()Daniel Zahka
test_case will only take on the formatted name after being called. This does not work with the way ksft_run() currently works. Assign the name after the test_case is created. Fixes: 81236c74dba6 ("selftests: drv-net: psp: add test for auto-adjusting TCP MSS") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251216-psp-test-fix-v1-2-3b5a6dde186f@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-12-23selftests: drv-net: psp: fix templated test names in psp_ip_ver_test_builder()Daniel Zahka
test_case will only take on its formatted name after it is called by the test runner. Move the assignment to test_case.__name__ to when the test_case is constructed, not called. Fixes: 8f90dc6e417a ("selftests: drv-net: psp: add basic data transfer and key rotation tests") Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com> Link: https://patch.msgid.link/20251216-psp-test-fix-v1-1-3b5a6dde186f@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
2025-12-23dt-bindings: dma: qcom,gpi: Document GPI DMA engine for Kaanapali and Glymur ↵Jyothi Kumar Seerapu
SoCs Document the GPI DMA engine on the Kaanapali and Glymur platforms. Signed-off-by: Jyothi Kumar Seerapu <jyothi.seerapu@oss.qualcomm.com> Signed-off-by: Pankaj Patil <pankaj.patil@oss.qualcomm.com> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://patch.msgid.link/20251105-knp-bus-v2-1-ed3095c7013a@oss.qualcomm.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dmaengine: mediatek: mtk-uart-apdma: Add support for Dimensity 9200AngeloGioacchino Del Regno
Add a compatible string and match data for the APDMA IP version found in the MediaTek Dimensity 9200 MT6985 SoC; this supports extended addressing with up to 35 bits. Other SoCs with this IP version also include the Dimensity 9400 MT6991 and Kompanio Ultra MT8196 (which don't need a specific compatible in this driver and can reuse the mt6985 one). Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20251113122229.23998-9-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dmaengine: mediatek: mtk-uart-apdma: Add support for Dimensity 6300AngeloGioacchino Del Regno
Add a compatible string and match data for the APDMA IP version found in the MediaTek Dimensity 6300 MT6835 SoC; this supports extended addressing with up to 34 bits. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20251113122229.23998-8-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dmaengine: mediatek: mtk-uart-apdma: Rename support_33bits to support_ext_addrAngeloGioacchino Del Regno
In preparation for adding support for SoCs with APDMA IP versions supporting more than 33 bits addressing, rename the support_33bits variable to support_ext_addr to signal support for extended, above 4GB, addressing. This change is cosmetic only, and brings no functional differences. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20251113122229.23998-7-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dmaengine: mediatek: uart-apdma: Fix above 4G addressing TX/RXAngeloGioacchino Del Regno
The VFF_4G_SUPPORT register is named differently in datasheets, and its name is "VFF_ADDR2"; was this named correctly from the beginning it would've been clearer that there was a mistake in the programming sequence. This register is supposed to hold the high bits to support the DMA addressing above 4G (so, more than 32 bits) and not a bit to "enable" the support for VFF 4G. Fix the name of this register, and also fix its usage by writing the upper 32 bits of the dma_addr_t on it when the SoC supports such feature. Fixes: 9135408c3ace ("dmaengine: mediatek: Add MediaTek UART APDMA support") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patch.msgid.link/20251113122229.23998-6-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dmaengine: mediatek: uart-apdma: Get addressing bits from match dataAngeloGioacchino Del Regno
The only SoC that declares mediatek,dma-33bits in its devicetree currently is MT6795, which obviously also declares a SoC-specific compatible string: in preparation for adding new SoCs with 34 bits addressing, replace the parsing of said vendor property with logic to get the number of addressing bits from platform data associated to compatible strings. While at it, also make the bit_mask variable unsigned and move the `int rc` declaration as last to beautify the code. Thanks to the correct declaration of the APDMA node is in all of the MediaTek device trees that are currently upstream, this commit brings no functional differences. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20251113122229.23998-5-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dt-bindings: dma: mediatek,uart-dma: Support all SoC generationsAngeloGioacchino Del Regno
Add support for the APDMA IP found in all of the SoC generations that are currently supported upstream; this includes: - MT8173, MT8183, fully compatible with MT6577 (32-bits) - MT7988, MT8186, MT8188, MT8192, MT8195 and MT6835 (34-bits) - MT6991, MT8196 and MT6985 (35-bits) ...where: - MT6835 is the first SoC where the AP_DMA IP supports 34-bits addressing; and - MT6985 is the first SoC where the AP_DMA IP supports 35-bits addressing. While at it, also add myself in the maintainers list. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20251113122229.23998-4-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dt-bindings: dma: mediatek,uart-dma: Deprecate mediatek,dma-33bitsAngeloGioacchino Del Regno
While this property wants to express a capability of the hardware, this is only used by the driver itself to vary the DMA bits during probe. Different hardware shall instead have different compatible strings. Following the driver cleanup and the introduction of a specific compatible string for the APDMA IP version found in MT6795, set the "mediatek,dma-33bits" vendor property as deprecated. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20251113122229.23998-3-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23dt-bindings: dma: mediatek,uart-dma: Allow MT6795 single compatibleAngeloGioacchino Del Regno
While it is true that this SoC is compatible with the MT6577 APDMA IP, that is valid only when the IP is used in 32-bits addressing mode, and, by the way there is no good reason to do so. Since the APDMA IP in MT6795 supports 33 bits addressing, this means that it is a newer revision compared to the one found in MT6577, hence only partially compatible with it. Allow nodes to specify "mediatek,mt6795-uart-dma" as their only compatible in the case of MT6795; this is done in lieu of the fact that there are other SoCs integrating the same version of this IP as MT6795, and those will eventually get their own compatible that expresses full compatibility with this SoC. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Acked-by: Conor Dooley <conor.dooley@microchip.com> Link: https://patch.msgid.link/20251113122229.23998-2-angelogioacchino.delregno@collabora.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23most: core: fix resource leak in most_register_interface error pathsNavaneeth K
The function most_register_interface() did not correctly release resources if it failed early (before registering the device). In these cases, it returned an error code immediately, leaking the memory allocated for the interface. Fix this by initializing the device early via device_initialize() and calling put_device() on all error paths. The most_register_interface() is expected to call put_device() on error which frees the resources allocated in the caller. The put_device() either calls release_mdev() or dim2_release(), depending on the caller. Switch to using device_add() instead of device_register() to handle the split initialization. Acked-by: Abdun Nihaal <abdun.nihaal@gmail.com> Signed-off-by: Navaneeth K <knavaneeth786@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Link: https://patch.msgid.link/20251127165337.19172-1-knavaneeth786@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23spi: cadence-quadspi: Improve CQSPI_SLOW_SRAM quirk if flash is slowMateusz Litwin
CQSPI_SLOW_SRAM quirk on the Stratix10 platform causes fewer interrupts, but also causes timeouts if a small block is used or if flash devices are slower than or equal in speed to SRAM's read operations. Adding the CQSPI_REG_IRQ_IND_COMP interrupt would resolve the problem for small reads, and removing the disabling of interrupts would resolve the issue with lost interrupts. This marginally increases IRQ count. Tests show that this will cause only a few percent more interrupts. Test: $ dd if=/dev/mtd0 of=/dev/null bs=1M count=64 Results from the Stratix10 platform with mt25qu02g flash. FIFO size in all tests: 128 Serviced interrupt call counts: Without CQSPI_SLOW_SRAM quirk: 16 668 850 With CQSPI_SLOW_SRAM quirk: 204 176 With CQSPI_SLOW_SRAM and this commit: 224 528 Signed-off-by: Mateusz Litwin <mateusz.litwin@nokia.com> Link: https://patch.msgid.link/20251218-cqspi_indirect_read_improve-v2-2-396079972f2a@nokia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-23spi: cadence-quadspi: Prevent lost complete() call during indirect readMateusz Litwin
A race condition exists between the read loop and IRQ `complete()` call. An interrupt could call the complete() between the inner loop and reinit_completion(), potentially losing the completion event and causing an unnecessary timeout. Moving reinit_completion() before the loop prevents this. A premature signal will only result in a spurious wakeup and another wait cycle, which is preferable to waiting for a timeout. Signed-off-by: Mateusz Litwin <mateusz.litwin@nokia.com> Link: https://patch.msgid.link/20251218-cqspi_indirect_read_improve-v2-1-396079972f2a@nokia.com Signed-off-by: Mark Brown <broonie@kernel.org>
2025-12-23dmaengine: stm32-mdma: initialize m2m_hw_period and ccr to fix warningsClément Le Goffic
m2m_hw_period is initialized only when chan_config->m2m_hw is true. This triggers a warning: ‘m2m_hw_period’ may be used uninitialized [-Wmaybe-uninitialized] Although m2m_hw_period is only used when chan_config->m2m_hw is true and ignored otherwise, initialize it unconditionally to 0. ccr is initialized by stm32_mdma_set_xfer_param() when the sg list is not empty. This triggers a warning: ‘ccr’ may be used uninitialized [-Wmaybe-uninitialized] Indeed, it could be used uninitialized if the sg list is empty. Initialize it to 0. Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com> Reviewed-by: Clément Le Goffic <legoffic.clement@gmail.com> Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://patch.msgid.link/20251217-mdma_warnings_fix-v2-1-340200e0bb55@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org>
2025-12-23serial: xilinx_uartps: fix rs485 delay_rts_after_sendj.turek
RTS line control with delay should be triggered when there is no more bytes in kfifo and hardware buffer is empty. Without this patch RTS control is scheduled right after feeding hardware buffer and this is too early. RTS line may change state before hardware buffer is empty. With this patch delayed RTS state change is triggered when function cdns_uart_handle_tx is called from cdns_uart_isr on CDNS_UART_IXR_TXEMPTY exactly when hardware completed transmission Fixes: fccc9d9233f9 ("tty: serial: uartps: Add rs485 support to uartps driver") Cc: stable <stable@kernel.org> Link: https://patch.msgid.link/20251221103221.1971125-1-jakub.turek@elsta.tech Signed-off-by: Jakub Turek <jakub.turek@elsta.tech> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-12-23serial: sh-sci: Check that the DMA cookie is validClaudiu Beznea
The driver updates struct sci_port::tx_cookie to zero right before the TX work is scheduled, or to -EINVAL when DMA is disabled. dma_async_is_complete(), called through dma_cookie_status() (and possibly through dmaengine_tx_status()), considers cookies valid only if they have values greater than or equal to 1. Passing zero or -EINVAL to dmaengine_tx_status() before any TX DMA transfer has started leads to an incorrect TX status being reported, as the cookie is invalid for the DMA subsystem. This may cause long wait times when the serial device is opened for configuration before any TX activity has occurred. Check that the TX cookie is valid before passing it to dmaengine_tx_status(). Fixes: 7cc0e0a43a91 ("serial: sh-sci: Check if TX data was written to device in .tx_empty()") Cc: stable <stable@kernel.org> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Link: https://patch.msgid.link/20251217135759.402015-1-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>