The qmp_usb_iomap() helper function currently returns the raw result of
devm_ioremap() for non-exclusive mappings. Since devm_ioremap() may return
a NULL pointer and the caller only checks error pointers with IS_ERR(),
NULL could bypass the check and lead to an invalid dereference.
Fix the issue by checking if devm_ioremap() returns NULL. When it does,
qmp_usb_iomap() now returns an error pointer via IOMEM_ERR_PTR(-ENOMEM),
ensuring safe and consistent error handling.
Signed-off-by: Chenyuan Yang <chenyuan0y@gmail.com>
Fixes: a5d6b1ac56 ("phy: qcom-qmp-usb: fix memleak on probe deferral")
CC: Johan Hovold <johan@kernel.org>
CC: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250414125050.2118619-1-chenyuan0y@gmail.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The Cadence Torrent SERDES supports USXGMII protocol. Hence, update the
bindings to allow PHY_TYPE_USXGMII. Since PHY_TYPE_USXGMII has the value
of "12" while the existing maximum allowed PHY TYPE is "9", switch back to
using "enum" property in the bindings to account for this discontinuity.
Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250411055743.623135-1-s-vadapalli@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
This API allows providers to offer an specific LED to be looked-up by a
consumer. Consumers are then able to describe the aforementioned LED
and take a reference on it.
For convenience, we're testing both sides of the API in just one test
function here. In reality, both the provider and the consumer would be
logistically orthogonal.
CMD:
tools/testing/kunit/kunit.py run --kunitconfig drivers/leds
RESULTS:
[16:38:57] Configuring KUnit Kernel ...
[16:38:57] Building KUnit Kernel ...
Populating config with:
$ make ARCH=um O=.kunit olddefconfig
Building with:
$ make all compile_commands.json scripts_gdb ARCH=um O=.kunit --jobs=20
[16:39:02] Starting KUnit Kernel (1/1)...
[16:39:02] ============================================================
Running tests with:
$ .kunit/linux kunit.enable=1 mem=1G console=tty kunit_shutdown=halt
[16:39:03] ===================== led (2 subtests) =====================
[16:39:03] [PASSED] led_test_class_register
[16:39:03] [PASSED] led_test_class_add_lookup_and_get
[16:39:03] ======================= [PASSED] led =======================
[16:39:03] ============================================================
[16:39:03] Testing complete. Ran 2 tests: passed: 2
[16:39:03] Elapsed time: 6.255s total, 0.001s configuring, 5.131s building, 1.106s running
Link: https://lore.kernel.org/r/20250501081918.3621432-3-lee@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Upon successful LED class device registration, it is expected that
certain attributes are filled out in pre-defined ways. For instance, if
provided, the .brightness_get() call-back should be called to populate
the class device 'brightness' attribute, 'max_brightness' should be
initialised as LED_FULL (at least until we can rid these pesky enums)
and the sysfs group should be created with the class device name
supplied by the caller.
If subsequent registrations take place that would result in name
conflicts, various outcomes are expected depending on which flags are
set. If LED_REJECT_NAME_CONFLICT is disabled, registration should
succeed resulting in an iteration on the provided name. Conversely, if
it's enabled, then registration is expected to fail outright.
We test for all of these scenarios here.
Link: https://lore.kernel.org/r/20250501081918.3621432-2-lee@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
If a KUNIT_ASSERT_*() call ends up in an assertion, the test is marked
as a failure and the subsequent error checking is never executed, making
it superfluous. Remove it for simplicity and to avoid confusion.
Link: https://lore.kernel.org/r/20250501081918.3621432-1-lee@kernel.org
Signed-off-by: Lee Jones <lee@kernel.org>
Remove the stray space between the '.' and the 'data' field name in
the PCA995x device-tree match table.
Signed-off-by: Jesse Karjalainen <jesse@ponkila.com>
Link: https://lore.kernel.org/r/20250426020454.47059-1-jesse@ponkila.com
Signed-off-by: Lee Jones <lee@kernel.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-4-2f42d8fbb525@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-3-2f42d8fbb525@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-2-2f42d8fbb525@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
struct gpio_chip now has callbacks for setting line values that return
an integer, allowing to indicate failures. Convert the driver to using
them.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20250423-gpiochip-set-rv-leds-v1-1-2f42d8fbb525@linaro.org
Signed-off-by: Lee Jones <lee@kernel.org>
This helps prevent mistakes like disable out of order in cleanup functions
and forgetting to free on error paths (as was done here).
This was the last thing the .remove() function did, so remove that too.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-6-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
Locking is a single register write, so no need to have the unlock
function also lock. This removes the need to pass in the option
and reduces the nesting level in the function.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-5-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
This allows the regulator to be optional which is the same as
done here with all the checks for NULL. This also disables
on remove for us, so remove the manual disabling.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-4-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
If we are not using regmap caches, then the value will be read
in every time, having a default value does not change anything in
that case. Remove the unused defaults.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-3-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
Use scoped mutex guards to simplify return paths. While here use
devm_mutex_init() to register the muxex so it also is cleaned
up automatically.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20250407183555.409687-2-afd@ti.com
Signed-off-by: Lee Jones <lee@kernel.org>
GCC compiler (Debian 14.2.0-17) is not happy about printing
into a too short buffer (when build with `make W=1`):
drivers/leds/leds-pca955x.c:554:33: note: ‘snprintf’ output between 2 and 12 bytes into a destination of size 8
Indeed, the buffer size is chosen based on some assumptions,
while in general the assigned value might not fit (GCC can't
prove it does).
Fix this by changing the bits field in the struct pca955x_chipdef to u8,
with a positive side effect of the better memory footprint, and convert
loop iterator to be unsigned. With that done, update format specifiers
accordingly.
In one case join back string literal as it improves the grepping over the code
based on the message and remove duplicating information (the driver name is
printed as pert of the dev_*() output [1]) as we touch the same line anyway.
Link: https://lore.kernel.org/r/4ac527f2-c59e-70a2-efd4-da52370ea557@dave.eu/ [1]
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20250407151441.706378-1-andriy.shevchenko@linux.intel.com
Signed-off-by: Lee Jones <lee@kernel.org>
When writing to the multi_intensity file, don't unconditionally call
led_set_brightness. By only doing this if blinking is inactive we
prevent blinking from stopping if the blinking is in its off phase while
the file is written.
Instead, if blinking is active, the changed intensity values are applied
upon the next blink. This is consistent with changing the brightness on
monochrome LEDs with active blinking.
Suggested-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Reviewed-by: Tobias Deiminger <tobias.deiminger@linutronix.de>
Tested-by: Sven Schuchmann <schuchmann@schleissheimer.de>
Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
Link: https://lore.kernel.org/r/20250404184043.227116-1-sven@svenschwermer.de
Signed-off-by: Lee Jones <lee@kernel.org>
Patch from Sam Shih <sam.shih@mediatek.com> found in MediaTek SDK
released under GPL.
Get syscon and use it to set the PHY type.
Extend support to PCIe and SGMII mode in addition to USB2 and USB3.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://lore.kernel.org/r/20250422132438.15735-7-linux@fw-web.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add support for type switch by pericfg register between USB3/PCIe.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250422132438.15735-5-linux@fw-web.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add compatible for xs-phy on mt7988.
Signed-off-by: Frank Wunderlich <frank-w@public-files.de>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20250422132438.15735-4-linux@fw-web.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Because current PWM Kconfig is sorting by symbol name,
it looks strange ordering in menuconfig.
=> [ ] Renesas R-Car PWM support
=> [ ] Renesas TPU PWM support
[ ] Rockchip PWM support
=> [ ] Renesas RZ/G2L General PWM Timer support
=> [ ] Renesas RZ/G2L MTU3a PWM Timer support
Let's use common CONFIG_PWM_RENESAS_xxx symbol name for Renesas,
and sort it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/877c2mxrrr.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Uwe Kleine-König <ukleinek@kernel.org>
- Enable modular support for the Renesas RZ/G2L GPT and MSIOF sound in
the ARM64 defconfig,
- Enable more support for RZN1D-DB/EB in shmobile_defconfig.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCaB4BQgAKCRCKwlD9ZEnx
cIo1APkBYQV8WZJNdKWIn3f3k7bfZJrbRSjRjvCnGs76wFI6nAEA7O63MVuy1kto
Hl6ApTlnptcOVvG+Bu6b+33QMN1eOwU=
=OKti
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm-defconfig-for-v6.16-tag2' of https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into pwm/for-next
Renesas ARM defconfig updates for v6.16 (take two)
- Enable modular support for the Renesas RZ/G2L GPT and MSIOF sound in
the ARM64 defconfig,
- Enable more support for RZN1D-DB/EB in shmobile_defconfig.
It is merged into the pwm tree due to the next patch renaming
PWM_RZG2L_GPT which has a use added in the arm64 defconfig.
The global pseudo-constants 'page_offset_base', 'vmalloc_base' and
'vmemmap_base' are not used extremely early during the boot, and cannot be
used safely until after the KASLR memory randomization code in
kernel_randomize_memory() executes, which may update their values.
So there is no point in setting these variables extremely early, and it
can wait until after the kernel itself is mapped and running from its
permanent virtual mapping.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20250513111157.717727-9-ardb+git@google.com
Warnings generated with 'make W=1':
arch/x86/power/hibernate.c:47: warning: Function parameter or struct member 'pfn' not described in 'pfn_is_nosave'
arch/x86/power/hibernate.c:92: warning: Function parameter or struct member 'max_size' not described in 'arch_hibernation_header_save'
Add missing parameter documentation in hibernate functions to
fix kernel-doc warnings.
Signed-off-by: Shivank Garg <shivankg@amd.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://lore.kernel.org/r/20250514062637.3287779-2-shivankg@amd.com
Building the kernel with W=1 generates the following warning:
arch/x86/mm/pat/memtype.c:692: warning: Function parameter or struct member 'pfn' not described in 'pat_pfn_immune_to_uc_mtrr'
Add missing parameter documentation to fix the kernel-doc warning.
Signed-off-by: Shivank Garg <shivankg@amd.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20250514062637.3287779-3-shivankg@amd.com
In tegra_ahub_probe(), check the result of function
of_device_get_match_data(), return an error code in case it fails.
Signed-off-by: Yuanjun Gong <ruc_gongyuanjun@163.com>
Link: https://patch.msgid.link/20250513123744.3041724-1-ruc_gongyuanjun@163.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Convert the TI DM816 AHCI SATA Controller to DT schema format. It's a
straight-forward conversion.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Commit affccb16c1 ("ata: ahci: print the lpm policy on boot") added a
lpm-pol print during boot, which shows the LPM policy used by each port.
While the LPM policy is usually determined by the Kconfig
CONFIG_SATA_MOBILE_LPM_POLICY, the Kconfig value is overridden e.g. if
firmware has marked the port as hotplug capable / external.
Commit f97106b10d ("ata: ahci: Add debug print for external port") did
add a debug print to show if LPM was disabled because firmware has marked
the port as external, however, because devices having broken LPM (even
though they claim to support it) is more common than one would have hoped,
print "ext" during boot if firmware has marked the port is external.
This will make it easier to debug certain LPM issues, e.g. if firmware has
enabled/marked only some of the ports as hotplug capable / external.
Before (port marked as external by firmware):
ata1: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3100 irq 57 lpm-pol 0
After (port marked as external by firmware):
ata1: SATA max UDMA/133 abar m4096@0xfebd3000 port 0xfebd3100 irq 57 lpm-pol 0 ext
Signed-off-by: Niklas Cassel <cassel@kernel.org>
Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
i.MX8qxp Display Controller(DC) is comprised of three main components that
include a blit engine for 2D graphics accelerations, display controller for
display output processing, as well as a command sequencer. Add kernel
mode setting support for the display controller part with two CRTCs and
two primary planes(backed by FetchLayer and FetchWarp respectively). The
registers of the display controller are accessed without command sequencer
involved, instead just by using CPU. The command sequencer is supposed to
be used by the blit engine.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Link: https://lore.kernel.org/r/20250414035028.1561475-13-victor.liu@nxp.com
i.MX8qxp Display Controller has a built-in interrupt controller to support
Enable/Status/Preset/Clear interrupt bit. Add driver for it.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Link: https://lore.kernel.org/r/20250414035028.1561475-12-victor.liu@nxp.com
i.MX8qxp Display Controller pixel engine consists of all processing
units that operate in the AXI bus clock domain. Add drivers for
ConstFrame, ExtDst, FetchLayer, FetchWarp and LayerBlend units, as
well as a pixel engine driver, so that two displays with primary
planes can be supported. The pixel engine driver and those unit
drivers are components to be aggregated by a master registered in
the upcoming DRM driver.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-11-victor.liu@nxp.com
i.MX8qxp Display Controller display engine consists of all processing
units that operate in a display clock domain. Add minimal feature
support with FrameGen and TCon so that the engine can output display
timings. The FrameGen driver, TCon driver and display engine driver
are components to be aggregated by a master registered in the upcoming
DRM driver.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-10-victor.liu@nxp.com
i.MX8qxp Display Controller(DC) is comprised of three main components that
include a blit engine for 2D graphics accelerations, display controller for
display output processing, as well as a command sequencer.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-9-victor.liu@nxp.com
i.MX8qxp Display Controller has a built-in interrupt controller to support
Enable/Status/Preset/Clear interrupt bit.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-8-victor.liu@nxp.com
i.MX8qxp Display Controller contains a command sequencer is designed to
autonomously process command lists.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-7-victor.liu@nxp.com
i.MX8qxp Display Controller contains a AXI performance counter which allows
measurement of average bandwidth and latency during operation.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-6-victor.liu@nxp.com
i.MX8qxp Display Controller pixel engine consists of all processing units
that operate in the AXI bus clock domain. Command sequencer and interrupt
controller of the Display Controller work with AXI bus clock, but they are
not in pixel engine.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-5-victor.liu@nxp.com
i.MX8qxp Display Controller display engine consists of all processing units
that operate in a display clock domain.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-4-victor.liu@nxp.com
i.MX8qxp Display Controller contains a blit engine for raster graphics.
It may read up to 3 source images from memory and computes one destination
image from it, which is written back to memory.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-3-victor.liu@nxp.com
Freescale i.MX8qxp Display Controller is implemented as construction set of
building blocks with unified concept and standardized interfaces. Document
all existing processing units.
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20250414035028.1561475-2-victor.liu@nxp.com
Recent patch fixed an old commit
'fc2a5a6161 ("powerpc/64s: ppc_save_regs is now needed for all 64s builds")'
which is to include building of ppc_save_reg.c only when XMON
and KEXEC_CORE and PPC_BOOK3S are enabled. This was valid, since
ppc_save_regs was called only in replay_system_reset() of old
irq.c which was under BOOK3S.
But there has been multiple refactoring of irq.c and have
added call to ppc_save_regs() from __replay_soft_interrupts
-> replay_soft_interrupts which is part of irq_64.c included
under CONFIG_PPC64. And since ppc_save_regs is called in
CRASH_DUMP path as part of crash_setup_regs in kexec.h,
CONFIG_PPC32 also needs it.
So with this recent patch which enabled the building of
ppc_save_regs.c caused a build break when none of these
(XMON, KEXEC_CORE, BOOK3S) where enabled as part of config.
Patch to enable building of ppc_save_regs.c by defaults.
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20250511041111.841158-1-maddy@linux.ibm.com
This patch is based on the commit 73eb5476df ("drm: rcar-du: Support
panels connected directly to the DPAD outputs").
The RZ DU driver assumes that a bridge is always connected to the DU
output. This is valid for the HDMI output, but the DPAD output can be
connected directly to a panel, in which case no bridge is available.
To support this use case, detect whether the entities connected to the DU
DPAD output is encoders or panels based on the number of ports of their DT
node, and retrieve the corresponding type of DRM objects. For panels,
additionally create panel bridge instances.
Signed-off-by: hienhuynh <hien.huynh.px@renesas.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Tested-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
Link: https://lore.kernel.org/r/20250508095042.25164-1-biju.das.jz@bp.renesas.com
