* Re: [PATCH v2 1/8] dt-bindings: mfd: khadas: Add new compatible for Khadas VIM4 MCU
From: Neil Armstrong @ 2026-04-17 7:53 UTC (permalink / raw)
To: Ronald Claveau, Rob Herring
Cc: Lee Jones, Krzysztof Kozlowski, Conor Dooley, Andi Shyti,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <6fc8ddeb-d54d-473d-94d2-49dc78a07154@aliel.fr>
On 4/16/26 10:25, Ronald Claveau wrote:
> On 4/15/26 11:48 PM, Rob Herring wrote:
>> On Fri, Apr 03, 2026 at 06:08:34PM +0200, Ronald Claveau wrote:
>>> The Khadas VIM4 MCU register is slightly different
>>> from previous boards' MCU.
>>> This board also features a switchable power source for its fan.
>>>
>>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>>> ---
>>> Documentation/devicetree/bindings/mfd/khadas,mcu.yaml | 5 +++++
>>> 1 file changed, 5 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>> index 084960fd5a1fd..67769ef5d58b1 100644
>>> --- a/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>> +++ b/Documentation/devicetree/bindings/mfd/khadas,mcu.yaml
>>> @@ -18,6 +18,7 @@ properties:
>>> compatible:
>>> enum:
>>> - khadas,mcu # MCU revision is discoverable
>>
>> The revision is no longer discoverable as was claimed?
>>
>
> The firmware revision is still discoverable, and via the same register,
> but the VIM4 MCU has a different register layout (eg: no DEVICE_NO
> register). The new compatible is needed to describe a different MCU
> variant, not a different revision of the same MCU.
> I will remove the comment as it is confusing with new boards.
Yes basically it was discoverable for earlier MCU version, but is not
for this particular board version.
Keep the comment, but add a comment on the vim4 entry saying this variant
is not discoverable.
Neil
>
>>> + - khadas,vim4-mcu
>>>
>>> "#cooling-cells": # Only needed for boards having FAN control feature
>>> const: 2
>>> @@ -25,6 +26,10 @@ properties:
>>> reg:
>>> maxItems: 1
>>>
>>> + fan-supply:
>>> + description: Phandle to the regulator that powers the fan.
>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>> +
>>> required:
>>> - compatible
>>> - reg
>>>
>>> --
>>> 2.49.0
>>>
>
>
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Move Peter De Schrijver to CREDITS
From: Geert Uytterhoeven @ 2026-04-17 7:55 UTC (permalink / raw)
To: Aaro Koskinen
Cc: Thierry Reding, linux-tegra, linux-arm-kernel, linux-pm,
linux-omap, linux-kernel, Paul Walmsley
In-Reply-To: <aeEm5DavehkPmSgl@darkstar.musicnaut.iki.fi>
On Thu, 16 Apr 2026 at 20:14, Aaro Koskinen <aaro.koskinen@iki.fi> wrote:
> On Thu, Apr 16, 2026 at 03:18:10PM +0200, Thierry Reding wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Peter sadly passed away a while back. Paul did a much better job at
> > finding the right words to mourn this loss than I ever could, so I will
> > leave this link here:
> >
> > https://lore.kernel.org/lkml/alpine.DEB.2.21.999.2407240345480.11116@utopia.booyaka.com/T/#u
> >
> > Co-developed-by: Paul Walmsley <pjw@kernel.org>
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
>
> Thanks for doing this. I think also the m68k work should be mentioned?
Indeed: Apollo Domain workstations, and Ariadne and Hydra Amiga
Ethernet.
Also: IBM PS/2, Microchannel, and Token Ring support.
Peter is also still listed as the contact info in
Documentation/ABI/testing/sysfs-driver-tegra-fuse
and as DT bindings maintainer in
Documentation/devicetree/bindings/reserved-memory/nvidia,tegra264-bpmp-shmem.yaml
Thanks!
> > --- a/CREDITS
> > +++ b/CREDITS
> > @@ -3645,7 +3645,13 @@ D: Macintosh IDE Driver
> >
> > N: Peter De Schrijver
> > E: stud11@cc4.kuleuven.ac.be
> > +E: p2@mind.be
> > +E: peter.de-schrijver@nokia.com
> > +E: pdeschrijver@nvidia.com
> > +E: p2@psychaos.be
> > D: Mitsumi CD-ROM driver patches March version
> > +D: OMAP power management
> > +D: NVIDIA Tegra clock and BPMP drivers, among many other things
> > S: Molenbaan 29
> > S: B2240 Zandhoven
> > S: Belgium
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index ef978bfca514..ffe20d770249 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -26145,7 +26145,6 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux.git
> > N: [^a-z]tegra
> >
> > TEGRA CLOCK DRIVER
> > -M: Peter De Schrijver <pdeschrijver@nvidia.com>
> > M: Prashant Gaikwad <pgaikwad@nvidia.com>
> > S: Supported
> > F: drivers/clk/tegra/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 1/1] reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ
From: Robby Cai @ 2026-04-17 8:08 UTC (permalink / raw)
To: p.zabel, Frank.Li, s.hauer, festevam
Cc: krzk+dt, andrew.smirnov, kernel, imx, linux-arm-kernel,
linux-kernel, aisheng.dong, guoniu.zhou
On i.MX8MQ, the MIPI CSI reset lines are active-low and not self-clearing.
Writing '0' asserts reset and it remains asserted until explicitly
deasserted by software.
This driver previously treated the MIPI CSI reset signals as active-high,
which led to incorrect reset assert/deassert sequencing. This issue was
exposed by commit 6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly
release reset").
Fix this by reflecting the correct reset polarity and ensuring proper
reset handling.
Fixes: c979dbf59987 ("reset: imx7: Add support for i.MX8MQ IP block variant")
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
Changes in v2:
- Drop the naming change in response to feedback from Krzysztof Kozlowski
- Refine the patch subject and commit message
Link to v1: https://lore.kernel.org/imx/20260331101331.1405588-1-robby.cai@nxp.com/
---
drivers/reset/reset-imx7.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
index dd01fe11c5cb..a3cb8244d76a 100644
--- a/drivers/reset/reset-imx7.c
+++ b/drivers/reset/reset-imx7.c
@@ -236,6 +236,12 @@ static int imx8mq_reset_set(struct reset_controller_dev *rcdev,
case IMX8MQ_RESET_PCIE_CTRL_APPS_EN:
case IMX8MQ_RESET_PCIE2_CTRL_APPS_EN:
+ case IMX8MQ_RESET_MIPI_CSI1_CORE_RESET:
+ case IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET:
+ case IMX8MQ_RESET_MIPI_CSI1_ESC_RESET:
+ case IMX8MQ_RESET_MIPI_CSI2_CORE_RESET:
+ case IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET:
+ case IMX8MQ_RESET_MIPI_CSI2_ESC_RESET:
case IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N:
--
2.37.1
^ permalink raw reply related
* [PATCH] dt-bindings: cpufreq: add mt8189 cpufreq hw dt-bindings
From: Binbin Shi @ 2026-04-17 8:06 UTC (permalink / raw)
To: Rafael J . Wysocki, Viresh Kumar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Hector Yuan
Cc: linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, Project_Global_Chrome_Upstream_Group,
vince-wl.liu, Binbin Shi
Add mt8189 cpufreq hw compatible in dt-bindings.
Signed-off-by: Binbin Shi <binbin.shi@mediatek.com>
---
.../devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
index d0aecde2b89b..cff52fffc6b8 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-mediatek-hw.yaml
@@ -16,7 +16,9 @@ description:
properties:
compatible:
- const: mediatek,cpufreq-hw
+ enum:
+ - mediatek,cpufreq-hw
+ - mediatek,mt8189-cpufreq-hw
reg:
minItems: 1
--
2.45.2
^ permalink raw reply related
* Re: [PATCH v6 09/10] clk: realtek: Add RTD1625-ISO clock controller driver
From: Yu-Chun Lin @ 2026-04-17 8:09 UTC (permalink / raw)
To: bmasney
Cc: afaerber, conor+dt, cy.huang, cylee12, devicetree, eleanor.lin,
james.tai, jyanchou, krzk+dt, linux-arm-kernel, linux-clk,
linux-kernel, linux-realtek-soc, mturquette, p.zabel, robh, sboyd,
stanley_chang
In-Reply-To: <ac_c6BkBQyvvOpeq@redhat.com>
Hi Brian,
> Hi Yu-Chun,
>
> On Thu, Apr 02, 2026 at 03:39:56PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Add support for the ISO (Isolation) domain clock controller on the
> > Realtek
> > RTD1625 SoC. This controller manages clocks in the always-on power
> > domain, ensuring essential services remain functional even when the
> > main system power is gated.
> >
> > Since the reset controller shares the same register space with the ISO
> > clock controller, it is instantiated as an auxiliary device by the
> > core clock driver. This patch also includes the corresponding
> > auxiliary reset driver to handle the ISO domain resets.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > Changes in v6:
> > - Add the headers used in c file to follow the "Include What You Use"
> principle.
> > - Move struct rtk_reset_desc arrays from the clock driver to the dedicated
> reset driver.
> > - Implement and register a dedicated reset auxiliary driver.
> > ---
> > drivers/clk/realtek/Makefile | 1 +
> > drivers/clk/realtek/clk-rtd1625-iso.c | 144 ++++++++++++++++++++++
> > drivers/reset/realtek/Makefile | 2 +-
> > drivers/reset/realtek/reset-rtd1625-iso.c | 96 +++++++++++++++
> > 4 files changed, 242 insertions(+), 1 deletion(-) create mode 100644
> > drivers/clk/realtek/clk-rtd1625-iso.c
> > create mode 100644 drivers/reset/realtek/reset-rtd1625-iso.c
> >
> > diff --git a/drivers/clk/realtek/Makefile
> > b/drivers/clk/realtek/Makefile index c992f97dfbc7..1680435e1e0f 100644
> > --- a/drivers/clk/realtek/Makefile
> > +++ b/drivers/clk/realtek/Makefile
> > @@ -10,3 +10,4 @@ clk-rtk-y += freq_table.o
> >
> > clk-rtk-$(CONFIG_RTK_CLK_PLL_MMC) += clk-pll-mmc.o
> > obj-$(CONFIG_COMMON_CLK_RTD1625) += clk-rtd1625-crt.o
> > +obj-$(CONFIG_COMMON_CLK_RTD1625) += clk-rtd1625-iso.o
> > diff --git a/drivers/clk/realtek/clk-rtd1625-iso.c
> > b/drivers/clk/realtek/clk-rtd1625-iso.c
> > new file mode 100644
> > index 000000000000..027a131363f9
> > --- /dev/null
> > +++ b/drivers/clk/realtek/clk-rtd1625-iso.c
> > @@ -0,0 +1,144 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2024 Realtek Semiconductor Corporation
> > + * Author: Cheng-Yu Lee <cylee12@realtek.com> */
> > +
> > +#include <dt-bindings/clock/realtek,rtd1625-clk.h>
> > +#include <linux/array_size.h>
> > +#include <linux/init.h>
> > +#include <linux/module.h>
> > +#include <linux/of_device.h>
> > +#include <linux/platform_device.h>
> > +#include "clk-regmap-gate.h"
> > +
> > +#define RTD1625_ISO_CLK_MAX 19
> > +#define RTD1625_ISO_RSTN_MAX 29
> > +#define RTD1625_ISO_S_CLK_MAX 5
> > +#define RTD1625_ISO_S_RSTN_MAX 5
> > +
> > +static CLK_REGMAP_GATE_NO_PARENT(clk_en_usb_p4, 0, 0x4, 0, 0); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_usb_p3, 0, 0x4, 1, 0); static
> > +CLK_REGMAP_GATE(clk_en_misc_cec0, "clk_en_misc", 0, 0x4, 2, 0);
> > +static CLK_REGMAP_GATE_NO_PARENT(clk_en_cbusrx_sys, 0, 0x4, 3, 0);
> > +static CLK_REGMAP_GATE_NO_PARENT(clk_en_cbustx_sys, 0, 0x4, 4, 0);
> > +static CLK_REGMAP_GATE_NO_PARENT(clk_en_cbus_sys, 0, 0x4, 5, 0);
> > +static CLK_REGMAP_GATE_NO_PARENT(clk_en_cbus_osc, 0, 0x4, 6, 0);
> > +static CLK_REGMAP_GATE_NO_PARENT(clk_en_i2c0, 0, 0x4, 9, 0); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_i2c1, 0, 0x4, 10, 0); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_etn_250m, 0, 0x4, 11, 0); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_etn_sys, 0, 0x4, 12, 0); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_usb_drd, 0, 0x4, 13, 0); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_usb_host, 0, 0x4, 14, 0); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_usb_u3_host, 0, 0x4, 15, 0); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_usb, 0, 0x4, 16, 0); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_vtc, 0, 0x4, 17, 0); static
> > +CLK_REGMAP_GATE(clk_en_misc_vfd, "clk_en_misc", 0, 0x4, 18, 0);
> > +
> > +static struct clk_regmap *rtd1625_clk_regmap_list[] = {
>
> static const? Same for some others below as well.
>
I initially tried to add const, but it triggered a "read-only object"
compilation error during the probe phase ('desc->clks[i]->regmap = regmap;')
To properly address, the code will be modified as follows:
static struct clk_regmap * const rtd1625_clk_regmap_list[] = { ... };
// in drivers/clk/realtek/common.h
struct rtk_clk_desc {
struct clk_hw_onecell_data *clk_data;
struct clk_regmap * const *clks;
size_t num_clks;
};
> > + &clk_en_usb_p4.clkr,
> > + &clk_en_usb_p3.clkr,
> > + &clk_en_misc_cec0.clkr,
> > + &clk_en_cbusrx_sys.clkr,
> > + &clk_en_cbustx_sys.clkr,
> > + &clk_en_cbus_sys.clkr,
> > + &clk_en_cbus_osc.clkr,
> > + &clk_en_i2c0.clkr,
> > + &clk_en_i2c1.clkr,
> > + &clk_en_etn_250m.clkr,
> > + &clk_en_etn_sys.clkr,
> > + &clk_en_usb_drd.clkr,
> > + &clk_en_usb_host.clkr,
> > + &clk_en_usb_u3_host.clkr,
> > + &clk_en_usb.clkr,
> > + &clk_en_vtc.clkr,
> > + &clk_en_misc_vfd.clkr,
> > +};
> > +
> > +static struct clk_hw_onecell_data rtd1625_iso_clk_data = {
> > + .num = RTD1625_ISO_CLK_MAX,
> > + .hws = {
> > + [RTD1625_ISO_CLK_EN_USB_P4] =
> &__clk_regmap_gate_hw(&clk_en_usb_p4),
> > + [RTD1625_ISO_CLK_EN_USB_P3] =
> &__clk_regmap_gate_hw(&clk_en_usb_p3),
> > + [RTD1625_ISO_CLK_EN_MISC_CEC0] =
> &__clk_regmap_gate_hw(&clk_en_misc_cec0),
> > + [RTD1625_ISO_CLK_EN_CBUSRX_SYS] =
> &__clk_regmap_gate_hw(&clk_en_cbusrx_sys),
> > + [RTD1625_ISO_CLK_EN_CBUSTX_SYS] =
> &__clk_regmap_gate_hw(&clk_en_cbustx_sys),
> > + [RTD1625_ISO_CLK_EN_CBUS_SYS] =
> &__clk_regmap_gate_hw(&clk_en_cbus_sys),
> > + [RTD1625_ISO_CLK_EN_CBUS_OSC] =
> &__clk_regmap_gate_hw(&clk_en_cbus_osc),
> > + [RTD1625_ISO_CLK_EN_I2C0] =
> &__clk_regmap_gate_hw(&clk_en_i2c0),
> > + [RTD1625_ISO_CLK_EN_I2C1] =
> &__clk_regmap_gate_hw(&clk_en_i2c1),
> > + [RTD1625_ISO_CLK_EN_ETN_250M] =
> &__clk_regmap_gate_hw(&clk_en_etn_250m),
> > + [RTD1625_ISO_CLK_EN_ETN_SYS] =
> &__clk_regmap_gate_hw(&clk_en_etn_sys),
> > + [RTD1625_ISO_CLK_EN_USB_DRD] =
> &__clk_regmap_gate_hw(&clk_en_usb_drd),
> > + [RTD1625_ISO_CLK_EN_USB_HOST] =
> &__clk_regmap_gate_hw(&clk_en_usb_host),
> > + [RTD1625_ISO_CLK_EN_USB_U3_HOST] =
> &__clk_regmap_gate_hw(&clk_en_usb_u3_host),
> > + [RTD1625_ISO_CLK_EN_USB] =
> &__clk_regmap_gate_hw(&clk_en_usb),
> > + [RTD1625_ISO_CLK_EN_VTC] =
> &__clk_regmap_gate_hw(&clk_en_vtc),
> > + [RTD1625_ISO_CLK_EN_MISC_VFD] =
> &__clk_regmap_gate_hw(&clk_en_misc_vfd),
> > + [RTD1625_ISO_CLK_MAX] = NULL,
> > + },
> > +};
> > +
> > +static const struct rtk_clk_desc rtd1625_iso_desc = {
> > + .clk_data = &rtd1625_iso_clk_data,
> > + .clks = rtd1625_clk_regmap_list,
> > + .num_clks = ARRAY_SIZE(rtd1625_clk_regmap_list),
> > +};
> > +
> > +static CLK_REGMAP_GATE_NO_PARENT(clk_en_irda, 0, 0x4, 6, 1); static
> > +CLK_REGMAP_GATE_NO_PARENT(clk_en_ur10, 0, 0x4, 8, 1);
> > +
> > +static struct clk_regmap *rtd1625_iso_s_clk_regmap_list[] = {
> > + &clk_en_irda.clkr,
> > + &clk_en_ur10.clkr,
> > +};
> > +
> > +static struct clk_hw_onecell_data rtd1625_iso_s_clk_data = {
> > + .num = RTD1625_ISO_S_CLK_MAX,
> > + .hws = {
> > + [RTD1625_ISO_S_CLK_EN_IRDA] =
> &__clk_regmap_gate_hw(&clk_en_irda),
> > + [RTD1625_ISO_S_CLK_EN_UR10] =
> &__clk_regmap_gate_hw(&clk_en_ur10),
> > + [RTD1625_ISO_S_CLK_MAX] = NULL,
> > + },
> > +};
> > +
> > +static const struct rtk_clk_desc rtd1625_iso_s_desc = {
> > + .clk_data = &rtd1625_iso_s_clk_data,
> > + .clks = rtd1625_iso_s_clk_regmap_list,
> > + .num_clks = ARRAY_SIZE(rtd1625_iso_s_clk_regmap_list),
> > +};
> > +
> > +static int rtd1625_iso_probe(struct platform_device *pdev) {
> > + const struct rtk_clk_desc *desc;
> > +
> > + desc = of_device_get_match_data(&pdev->dev);
> > + if (!desc)
> > + return -EINVAL;
> > + return rtk_clk_probe(pdev, desc, "iso_rst");
>
> Add newline before return.
>
Ack.
> > +}
> > +
> > +static const struct of_device_id rtd1625_iso_match[] = {
> > + {.compatible = "realtek,rtd1625-iso-clk", .data = &rtd1625_iso_desc},
> > + {.compatible = "realtek,rtd1625-iso-s-clk", .data =
> &rtd1625_iso_s_desc},
> > + { /* sentinel */ }
> > +};
> > +
> > +static struct platform_driver rtd1625_iso_driver = {
> > + .probe = rtd1625_iso_probe,
> > + .driver = {
> > + .name = "rtk-rtd1625-iso-clk",
> > + .of_match_table = rtd1625_iso_match,
> > + },
> > +};
> > +
> > +static int __init rtd1625_iso_init(void) {
> > + return platform_driver_register(&rtd1625_iso_driver);
> > +}
> > +subsys_initcall(rtd1625_iso_init);
> > +
> > +MODULE_DESCRIPTION("Realtek RTD1625 ISO Controller Driver");
> > +MODULE_AUTHOR("Cheng-Yu Lee <cylee12@realtek.com>");
> > +MODULE_LICENSE("GPL"); MODULE_IMPORT_NS("REALTEK_CLK");
> > diff --git a/drivers/reset/realtek/Makefile
> > b/drivers/reset/realtek/Makefile index 8ca1fa939f10..26b3ddc75ada
> > 100644
> > --- a/drivers/reset/realtek/Makefile
> > +++ b/drivers/reset/realtek/Makefile
> > @@ -1,2 +1,2 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > -obj-$(CONFIG_RESET_RTK_COMMON) += common.o reset-rtd1625-crt.o
> > +obj-$(CONFIG_RESET_RTK_COMMON) += common.o reset-rtd1625-crt.o
> > +reset-rtd1625-iso.o
>
> Some comment as the previous patch. CONFIG_RESET_RTK_COMMON is
> expected to be common, right? If so, a SoC-specific driver shouldn't be listed
> here.
This Makefile will change to
obj-$(CONFIG_RESET_RTK_COMMON) += common.o
obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o reset-rtd1625-iso.o
>
> > diff --git a/drivers/reset/realtek/reset-rtd1625-iso.c
> > b/drivers/reset/realtek/reset-rtd1625-iso.c
> > new file mode 100644
> > index 000000000000..f2a0478382ae
> > --- /dev/null
> > +++ b/drivers/reset/realtek/reset-rtd1625-iso.c
> > @@ -0,0 +1,96 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +/*
> > + * Copyright (C) 2026 Realtek Semiconductor Corporation */
> > +
> > +#include <dt-bindings/reset/realtek,rtd1625.h>
> > +#include <linux/auxiliary_bus.h>
> > +#include <linux/device.h>
> > +#include <linux/errno.h>
> > +#include <linux/of.h>
> > +#include <linux/slab.h>
> > +#include "common.h"
> > +
> > +#define RTD1625_ISO_RSTN_MAX 29
> > +#define RTD1625_ISO_S_RSTN_MAX 5
> > +
> > +static struct rtk_reset_desc rtd1625_iso_reset_descs[] = {
>
> static const?
>
Ack.
> > + [RTD1625_ISO_RSTN_VFD] = { .ofs = 0x88, .bit =
> 0 },
> > + [RTD1625_ISO_RSTN_CEC0] = { .ofs = 0x88, .bit =
> 2 },
> > + [RTD1625_ISO_RSTN_CEC1] = { .ofs = 0x88, .bit =
> 3 },
> > + [RTD1625_ISO_RSTN_CBUSTX] = { .ofs = 0x88, .bit =
> 5 },
> > + [RTD1625_ISO_RSTN_CBUSRX] = { .ofs = 0x88, .bit =
> 6 },
> > + [RTD1625_ISO_RSTN_USB3_PHY2_XTAL_POW] = { .ofs = 0x88, .bit =
> 7 },
> > + [RTD1625_ISO_RSTN_UR0] = { .ofs = 0x88, .bit =
> 8 },
> > + [RTD1625_ISO_RSTN_GMAC] = { .ofs = 0x88, .bit =
> 9 },
> > + [RTD1625_ISO_RSTN_GPHY] = { .ofs = 0x88, .bit =
> 10 },
> > + [RTD1625_ISO_RSTN_I2C_0] = { .ofs = 0x88, .bit =
> 11 },
> > + [RTD1625_ISO_RSTN_I2C_1] = { .ofs = 0x88, .bit =
> 12 },
> > + [RTD1625_ISO_RSTN_CBUS] = { .ofs = 0x88, .bit =
> 13 },
> > + [RTD1625_ISO_RSTN_USB_DRD] = { .ofs = 0x88, .bit =
> 14 },
> > + [RTD1625_ISO_RSTN_USB_HOST] = { .ofs = 0x88, .bit =
> 15 },
> > + [RTD1625_ISO_RSTN_USB_PHY_0] = { .ofs = 0x88, .bit =
> 16 },
> > + [RTD1625_ISO_RSTN_USB_PHY_1] = { .ofs = 0x88, .bit =
> 17 },
> > + [RTD1625_ISO_RSTN_USB_PHY_2] = { .ofs = 0x88, .bit =
> 18 },
> > + [RTD1625_ISO_RSTN_USB] = { .ofs = 0x88, .bit =
> 19 },
> > + [RTD1625_ISO_RSTN_TYPE_C] = { .ofs = 0x88, .bit =
> 20 },
> > + [RTD1625_ISO_RSTN_USB_U3_HOST] = { .ofs = 0x88, .bit =
> 21 },
> > + [RTD1625_ISO_RSTN_USB3_PHY0_POW] = { .ofs = 0x88, .bit =
> 22 },
> > + [RTD1625_ISO_RSTN_USB3_P0_MDIO] = { .ofs = 0x88, .bit =
> 23 },
> > + [RTD1625_ISO_RSTN_USB3_PHY1_POW] = { .ofs = 0x88, .bit =
> 24 },
> > + [RTD1625_ISO_RSTN_USB3_P1_MDIO] = { .ofs = 0x88, .bit =
> 25 },
> > + [RTD1625_ISO_RSTN_VTC] = { .ofs = 0x88, .bit =
> 26 },
> > + [RTD1625_ISO_RSTN_USB3_PHY2_POW] = { .ofs = 0x88, .bit =
> 27 },
> > + [RTD1625_ISO_RSTN_USB3_P2_MDIO] = { .ofs = 0x88, .bit =
> 28 },
> > + [RTD1625_ISO_RSTN_USB_PHY_3] = { .ofs = 0x88, .bit =
> 29 },
> > + [RTD1625_ISO_RSTN_USB_PHY_4] = { .ofs = 0x88, .bit =
> 30 },
> > +};
> > +
> > +static struct rtk_reset_desc rtd1625_iso_s_reset_descs[] = {
> > + [RTD1625_ISO_S_RSTN_ISOM_MIS] = { .ofs = 0x310, .bit =
> 0, .write_en = 1 },
> > + [RTD1625_ISO_S_RSTN_GPIOM] = { .ofs = 0x310, .bit =
> 2, .write_en = 1 },
> > + [RTD1625_ISO_S_RSTN_TIMER7] = { .ofs = 0x310, .bit =
> 4, .write_en = 1 },
> > + [RTD1625_ISO_S_RSTN_IRDA] = { .ofs = 0x310, .bit =
> 6, .write_en = 1 },
> > + [RTD1625_ISO_S_RSTN_UR10] = { .ofs = 0x310, .bit =
> 8, .write_en = 1 },
> > +};
> > +
> > +static int rtd1625_iso_reset_probe(struct auxiliary_device *adev,
> > + const struct auxiliary_device_id *id)
> > +{
> > + struct device *dev = &adev->dev;
> > + struct device *parent = dev->parent;
> > + struct rtk_reset_data *data;
> > +
> > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + if (of_device_is_compatible(parent->of_node,
> "realtek,rtd1625-iso-s-clk")) {
> > + data->descs = rtd1625_iso_s_reset_descs;
> > + data->rcdev.nr_resets = RTD1625_ISO_S_RSTN_MAX;
> > + } else {
> > + data->descs = rtd1625_iso_reset_descs;
> > + data->rcdev.nr_resets = RTD1625_ISO_RSTN_MAX;
> > + }
> > + return rtk_reset_controller_add(dev, data);
>
> Newline before return.
>
Ack.
> > +}
> > +
> > +static const struct auxiliary_device_id rtd1625_iso_reset_ids[] = {
> > + {
> > + .name = "clk_rtk.iso_rst",
> > + },
>
> I would combine the { .name } all on one line.
>
Ack.
Best Regards,
Yu-Chun
> Brian
>
^ permalink raw reply
* Re: [PATCH] gpio: drop bitmap_complement() where feasible
From: Michal Simek @ 2026-04-17 8:14 UTC (permalink / raw)
To: Yury Norov, Linus Walleij, Andy Shevchenko, Bartosz Golaszewski,
Shubhrajyoti Datta, Srinivas Neeli, linux-gpio, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260417033439.318930-1-ynorov@nvidia.com>
On 4/17/26 05:34, Yury Norov wrote:
> [Some people who received this message don't often get email from ynorov@nvidia.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> The gpio drivers reproduce the following pattern:
>
> bitmap_complement(tmp, data1, nbits);
> bitmap_and(dst, data2, tmp, nbits);
>
> This can be done in a single pass:
>
> bitmap_andnot(dst, data2, data1t, nbits);
>
s/data1t/data1/
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v2 1/2] thermal/drivers/imx: Fix thermal zone leak on probe error path
From: Frank Li @ 2026-04-17 8:16 UTC (permalink / raw)
To: Felix Gu
Cc: Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Oleksij Rempel, linux-pm, imx, linux-arm-kernel, linux-kernel
In-Reply-To: <CAN4SLj3rH1q-jd6ccdo2qVNuNUoqfpsiS0KXJ3b=b7m_bh2QBw@mail.gmail.com>
On Thu, Apr 16, 2026 at 09:04:38PM +0800, Felix Gu wrote:
> On Wed, Apr 15, 2026 at 9:10 PM Felix Gu <ustc.gu@gmail.com> wrote:
...
> > 2.43.0
> >
>
> Hi all,
> This patch has a problem, I will fix it and send v3.
Next time trim context to let reviewer see important information before
scoll down email.
Frank
>
> Best regards,
> Felix
^ permalink raw reply
* Re: [PATCH] serial: mxs-auart: Compare the return value of gpiod_get_direction against GPIO_LINE_DIRECTION_IN
From: Frank Li @ 2026-04-17 8:22 UTC (permalink / raw)
To: Nikola Z. Ivanov
Cc: gregkh, jirislaby, s.hauer, kernel, festevam, linux-kernel,
linux-serial, imx, linux-arm-kernel
In-Reply-To: <20260416083254.1798-1-zlatistiv@gmail.com>
On Thu, Apr 16, 2026 at 11:32:54AM +0300, Nikola Z. Ivanov wrote:
subjust suggest change to
Replace hardcode 1 with predefined macro GPIO_LINE_DIRECTION_IN
Frank
> The GPIO_LINE_DIRECTION_* definitions have just recently been exposed to
> gpio consumers.h by breaking them out in a separate defs.h file.
>
> Use this to validate the gpio direction instead of the hard-coded literal.
>
> Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
> ---
> drivers/tty/serial/mxs-auart.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/tty/serial/mxs-auart.c b/drivers/tty/serial/mxs-auart.c
> index cc65c9fb6446..6c6df4d5c21f 100644
> --- a/drivers/tty/serial/mxs-auart.c
> +++ b/drivers/tty/serial/mxs-auart.c
> @@ -1519,7 +1519,7 @@ static int mxs_auart_init_gpios(struct mxs_auart_port *s, struct device *dev)
>
> for (i = 0; i < UART_GPIO_MAX; i++) {
> gpiod = mctrl_gpio_to_gpiod(s->gpios, i);
> - if (gpiod && (gpiod_get_direction(gpiod) == 1))
> + if (gpiod && (gpiod_get_direction(gpiod) == GPIO_LINE_DIRECTION_IN))
> s->gpio_irq[i] = gpiod_to_irq(gpiod);
> else
> s->gpio_irq[i] = -EINVAL;
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH v1] clk: imx95-blk-ctl: Fix REFCLK rise-fall mismatch on i.MX95
From: Richard Zhu @ 2026-04-17 8:29 UTC (permalink / raw)
To: abelvesa, peng.fan, mturquette, sboyd, Frank.Li, s.hauer,
festevam
Cc: linux-clk, imx, linux-arm-kernel, linux-kernel, kernel,
Richard Zhu
When the internal PLL is used as the PCIe reference clock source on i.MX95,
a REFCLK rise-fall time mismatch is observed during PCIe Gen1 compliance
testing with the Lfast IO analyzer.
Fix this issue by configuring the IREF_TX field to 0xF (15), which adjusts
the transmitter current reference to meet the PCIe specification timing
requirements.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
drivers/clk/imx/clk-imx95-blk-ctl.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/clk/imx/clk-imx95-blk-ctl.c b/drivers/clk/imx/clk-imx95-blk-ctl.c
index 1f9259f45607..bc6957299cec 100644
--- a/drivers/clk/imx/clk-imx95-blk-ctl.c
+++ b/drivers/clk/imx/clk-imx95-blk-ctl.c
@@ -44,6 +44,8 @@ struct imx95_blk_ctl_clk_dev_data {
const char * const *parent_names;
u32 num_parents;
u32 reg;
+ u32 reg_init_msk;
+ u32 reg_init_val;
u32 bit_idx;
u32 bit_width;
u32 clk_type;
@@ -289,6 +291,8 @@ static const struct imx95_blk_ctl_clk_dev_data hsio_blk_ctl_clk_dev_data[] = {
.parent_names = (const char *[]){ "func_out_en", },
.num_parents = 1,
.reg = 0,
+ .reg_init_msk = GENMASK(10, 7),
+ .reg_init_val = GENMASK(10, 7),
.bit_idx = 6,
.bit_width = 1,
.type = CLK_GATE,
@@ -410,6 +414,9 @@ static int imx95_bc_probe(struct platform_device *pdev)
const struct imx95_blk_ctl_clk_dev_data *data = &bc->pdata->clk_dev_data[i];
void __iomem *reg = base + data->reg;
+ if (data->reg_init_msk)
+ writel((readl(reg) & ~data->reg_init_msk) | data->reg_init_val, reg);
+
if (data->type == CLK_MUX) {
hws[i] = clk_hw_register_mux(dev, data->name, data->parent_names,
data->num_parents, data->flags, reg,
--
2.37.1
^ permalink raw reply related
* Re: [PATCH 1/5] media: synopsys: Add support for RAW16 Bayer formats
From: Frank Li @ 2026-04-17 8:31 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260415-csi2_imx95-v1-1-7d63f3508719@oss.nxp.com>
On Wed, Apr 15, 2026 at 11:46:52AM +0800, Guoniu Zhou wrote:
> This enables the driver to handle higher bit-depth raw image data
> from image sensors that support 16-bit output.
wrap at 75 char,
Add higher bit-depth raw image data support for the sensors, which supports
16-bit output.
Frank
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> index ce17f986279e..46e2a4315ac2 100644
> --- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> +++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> @@ -252,6 +252,26 @@ static const struct dw_mipi_csi2rx_format formats[] = {
> .depth = 12,
> .csi_dt = MIPI_CSI2_DT_RAW12,
> },
> + {
> + .code = MEDIA_BUS_FMT_SBGGR16_1X16,
> + .depth = 16,
> + .csi_dt = MIPI_CSI2_DT_RAW16,
> + },
> + {
> + .code = MEDIA_BUS_FMT_SGBRG16_1X16,
> + .depth = 16,
> + .csi_dt = MIPI_CSI2_DT_RAW16,
> + },
> + {
> + .code = MEDIA_BUS_FMT_SGRBG16_1X16,
> + .depth = 16,
> + .csi_dt = MIPI_CSI2_DT_RAW16,
> + },
> + {
> + .code = MEDIA_BUS_FMT_SRGGB16_1X16,
> + .depth = 16,
> + .csi_dt = MIPI_CSI2_DT_RAW16,
> + },
> };
>
> static inline struct dw_mipi_csi2rx_device *to_csi2(struct v4l2_subdev *sd)
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH 2/5] media: synopsys: Add support for multiple streams
From: Frank Li @ 2026-04-17 8:38 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260415-csi2_imx95-v1-2-7d63f3508719@oss.nxp.com>
On Wed, Apr 15, 2026 at 11:46:53AM +0800, Guoniu Zhou wrote:
> The current driver only supports single stream operation. Add support
> for multiple concurrent streams by tracking enabled streams with a
> bitmask and only initializing the hardware once for the first stream.
>
> This enables use cases such as surround view systems where multiple
> camera streams need to be processed simultaneously through the same
> CSI-2 receiver interface.
Look like this driver only one sink and one source pad, how to implement
multiple stream.
Frank
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v7 2/2] arm64: defconfig: enable BST SDHCI controller
From: gordon.ge @ 2026-04-17 8:38 UTC (permalink / raw)
To: yangzh0906
Cc: krzk, arnd, krzk+dt, robh, conor+dt, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260310091211.4171307-3-yangzh0906@thundersoft.com>
Acked-by: Gordon Ge <gordon.ge@bst.ai>
^ permalink raw reply
* [PATCH net 0/2] net: airoha: Fix NULL pointer derefrences in airoha_qdma_cleanup()
From: Lorenzo Bianconi @ 2026-04-17 8:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
Fix two possible NULL pointer derefrences in airoha_qdma_cleanup routine
if airoha_qdma_init() fails.
---
Lorenzo Bianconi (2):
net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()
net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup()
drivers/net/ethernet/airoha/airoha_eth.c | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
---
base-commit: 82c21069028c5db3463f851ae8ac9cc2e38a3827
change-id: 20260417-airoha_qdma_init_rx_queue-fix-b9bfada51671
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply
* [PATCH net 1/2] net: airoha: Move ndesc initialization at end of airoha_qdma_init_rx_queue()
From: Lorenzo Bianconi @ 2026-04-17 8:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha_qdma_init_rx_queue-fix-v1-0-db9fa5e468e5@kernel.org>
If queue entry or DMA descriptor list allocation fails in
airoha_qdma_init_rx_queue routine, airoha_qdma_cleanup() will trigger a
NULL pointer dereference running netif_napi_del() for RX queue NAPIs
since netif_napi_add() has never been executed to this particular RX NAPI.
The issue is due to the early ndesc initialization in
airoha_qdma_init_rx_queue() since airoha_qdma_cleanup() relies on ndesc
value to check if the queue is properly initialized. Fix the issue moving
ndesc initialization at end of airoha_qdma_init_tx routine.
Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index e1ab15f1ee7d..a6f8b231583d 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -745,10 +745,9 @@ static int airoha_qdma_init_rx_queue(struct airoha_queue *q,
dma_addr_t dma_addr;
q->buf_size = PAGE_SIZE / 2;
- q->ndesc = ndesc;
q->qdma = qdma;
- q->entry = devm_kzalloc(eth->dev, q->ndesc * sizeof(*q->entry),
+ q->entry = devm_kzalloc(eth->dev, ndesc * sizeof(*q->entry),
GFP_KERNEL);
if (!q->entry)
return -ENOMEM;
@@ -761,11 +760,12 @@ static int airoha_qdma_init_rx_queue(struct airoha_queue *q,
return err;
}
- q->desc = dmam_alloc_coherent(eth->dev, q->ndesc * sizeof(*q->desc),
+ q->desc = dmam_alloc_coherent(eth->dev, ndesc * sizeof(*q->desc),
&dma_addr, GFP_KERNEL);
if (!q->desc)
return -ENOMEM;
+ q->ndesc = ndesc;
netif_napi_add(eth->napi_dev, &q->napi, airoha_qdma_rx_napi_poll);
airoha_qdma_wr(qdma, REG_RX_RING_BASE(qid), dma_addr);
--
2.53.0
^ permalink raw reply related
* [PATCH net 2/2] net: airoha: Add size check for TX NAPIs in airoha_qdma_cleanup()
From: Lorenzo Bianconi @ 2026-04-17 8:40 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Simon Horman, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260417-airoha_qdma_init_rx_queue-fix-v1-0-db9fa5e468e5@kernel.org>
If airoha_qdma_init routine fails before airoha_qdma_tx_irq_init() runs
successfully for all TX NAPIs, airoha_qdma_cleanup() will
unconditionally runs netif_napi_del() on TX NAPIs, triggering a NULL
pointer dereference. Fix the issue relying on q_tx_irq size value to
check if the TX NAPIs is properly initialized in airoha_qdma_cleanup().
Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index a6f8b231583d..1ca4087e675d 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1398,8 +1398,12 @@ static void airoha_qdma_cleanup(struct airoha_qdma *qdma)
}
}
- for (i = 0; i < ARRAY_SIZE(qdma->q_tx_irq); i++)
+ for (i = 0; i < ARRAY_SIZE(qdma->q_tx_irq); i++) {
+ if (!qdma->q_tx_irq[i].size)
+ continue;
+
netif_napi_del(&qdma->q_tx_irq[i].napi);
+ }
for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++) {
if (!qdma->q_tx[i].ndesc)
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 06/12] coresight: etm4x: fix leaked trace id
From: Leo Yan @ 2026-04-17 8:41 UTC (permalink / raw)
To: Jie Gan
Cc: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel,
suzuki.poulose, mike.leach, james.clark, alexander.shishkin
In-Reply-To: <e994bf83-a66c-453e-aee6-c15b6888499c@oss.qualcomm.com>
Hi Jie,
On Fri, Apr 17, 2026 at 09:01:17AM +0800, Jie Gan wrote:
[...]
> ... we still need support static trace ID allocation in parallel for
> the dummy sources and we should not break this logic in future refactor.
Just confirm what is the reason you need to use static trace ID for the
dummy sources?
I am wandering if we could use dev->devt as trace ID for dummy
devices. Since the device's MAJOR number is non-zero and occupies the
upper bits (see MINORBITS), it is naturally separated from the hardware
trace ID range. If so, we even don't need to bother ID alloc/release.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH v3 1/2] mailbox: Use per-thread completion to fix wrong completion order
From: Joonwon Kang @ 2026-04-17 8:41 UTC (permalink / raw)
To: jassisinghbrar
Cc: angelogioacchino.delregno, jonathanh, joonwonkang,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding
In-Reply-To: <CABb+yY0uDQh-3cadPQONV=NJKjMtc4mJekgjmHYVaHnfHXvGZQ@mail.gmail.com>
> On Fri, Apr 3, 2026 at 9:51 AM Joonwon Kang <joonwonkang@google.com> wrote:
> >
> > > On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> > > >
> > > > Previously, a sender thread in mbox_send_message() could be woken up at
> > > > a wrong time in blocking mode. It is because there was only a single
> > > > completion for a channel whereas messages from multiple threads could be
> > > > sent in any order; since the shared completion could be signalled in any
> > > > order, it could wake up a wrong sender thread.
> > > >
> > > > This commit resolves the false wake-up issue with the following changes:
> > > > - Completions are created just as many as the number of concurrent sender
> > > > threads
> > > > - A completion is created on a sender thread's stack
> > > > - Each slot of the message queue, i.e. `msg_data`, contains a pointer to
> > > > its target completion
> > > > - tx_tick() signals the completion of the currently active slot of the
> > > > message queue
> > > >
> > > I think I reviewed it already or is this happening on
> > > one-channel-one-client usage? Because mailbox api does not support
> > > channels shared among multiple clients.
> >
> > Yes, this patch is handling the one-channel-one-client usage but when that
> > single channel is shared between multiple threads.
>
> hmm.... how is this not single-channel-multiple-clients ?
> A channel is returned as an opaque token to the clients, if that
> client shares that with other threads - they will race.
> It is the job of the original client to serialize its threads' access
> to the channel.
>
> > From my understanding, the
> > discussion back then ended with how to circumvent the issue rather than whether
> > we will eventually solve this in the mailbox framework or not, and if yes, how
> > we will, and if not, why.
>
> It will be interesting to see how many current clients actually need
> to share channels. If there are enough, it makes sense to implement
> some helper api
> on top of existing code, instead of changing its nature totally.
>
> Thanks
> Jassi
Hi Jassi, can we continue discussing this matter? We can start from the recent
comments from me.
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH v3 2/2] mailbox: Make mbox_send_message() return error code when tx fails
From: Joonwon Kang @ 2026-04-17 8:43 UTC (permalink / raw)
To: jassisinghbrar
Cc: akpm, angelogioacchino.delregno, jonathanh, joonwonkang,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding
In-Reply-To: <CABb+yY23aTXeXu6G-8sHjw32DCqmhsJLu2Mt-txenOgTBiyv+A@mail.gmail.com>
> On Fri, Apr 3, 2026 at 10:19 AM Joonwon Kang <joonwonkang@google.com> wrote:
> >
> > > On Thu, Apr 2, 2026 at 12:07 PM Joonwon Kang <joonwonkang@google.com> wrote:
> > > >
> > > > When the mailbox controller failed transmitting message, the error code
> > > > was only passed to the client's tx done handler and not to
> > > > mbox_send_message(). For this reason, the function could return a false
> > > > success. This commit resolves the issue by introducing the tx status and
> > > > checking it before mbox_send_message() returns.
> > > >
> > > Can you please share the scenario when this becomes necessary? This
> > > can potentially change the ground underneath some clients, so we have
> > > to be sure this is really useful.
> >
> > I would say the problem here is generic enough to apply to all the cases where
> > the send result needs to be checked. Since the return value of the send API is
> > not the real send result, any users who believe that this blocking send API
> > will return the real send result could fall for that. For example, users may
> > think the send was successful even though it was not actually. I believe it is
> > uncommon that users have to register a callback solely to get the send result
> > even though they are using the blocking send API already. Also, I guess there
> > is no special reason why only the mailbox send API should work this way among
> > other typical blocking send APIs. For these reasons, this patch makes the send
> > API return the real send result. This way, users will not need to register the
> > redundant callback and I think the return value will align with their common
> > expectation.
> >
> Clients submit a message into the Mailbox subsystem to be sent out to
> the remote side which can happen immediately or later.
> If submission fails, clients get immediately notified. If transmission
> fails (which is now internal to the subsystem) it is reported to the
> client by a callback.
> If the API was called mbox_submit_message (which it actually is)
> instead of mbox_send_message, there would be no confusion.
> We can argue how good/bad the current implementation is, but the fact
> is that it is here. And I am reluctant to cause churn without good
> reason.
> Again, as I said, any, _legal_, setup scenario will help me come over
> my reluctance.
>
> Thanks
> Jassi
Hi Jassi, can we continue discussing this issue from where we left off last
time?
Thanks,
Joonwon Kang
^ permalink raw reply
* Re: [PATCH net-next 5/6] net: stmmac: move PHY handling out of __stmmac_open()/release()
From: Alexander Stein @ 2026-04-17 8:47 UTC (permalink / raw)
To: Russell King (Oracle), Maxime Chevallier
Cc: Andrew Lunn, Heiner Kallweit, Alexandre Torgue, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, linux-arm-kernel,
linux-stm32, Maxime Coquelin, netdev, Paolo Abeni
In-Reply-To: <680c384c-135f-44cd-a2cd-7e4fd0ec4bf7@bootlin.com>
Am Freitag, 17. April 2026, 09:11:59 CEST schrieb Maxime Chevallier:
> Hi,
>
> On 16/04/2026 14:13, Russell King (Oracle) wrote:
> > On Thu, Apr 16, 2026 at 02:02:53PM +0200, Alexander Stein wrote:
> >> Hi Russel,
> >>
> >> Am Donnerstag, 16. April 2026, 12:49:25 CEST schrieb Russell King (Oracle):
> >>> On Thu, Apr 16, 2026 at 08:20:13AM +0200, Alexander Stein wrote:
> >>>> Am Mittwoch, 15. April 2026, 14:59:32 CEST schrieb Russell King (Oracle):
> >>>>> On Wed, Apr 15, 2026 at 08:08:40AM +0200, Alexander Stein wrote:
> >>>>>> Hi,
> >>>>>>
> >>>>>> Am Dienstag, 23. September 2025, 13:26:19 CEST schrieb Russell King (Oracle):
> >>>>>>> Move the PHY attachment/detachment from the network driver out of
> >>>>>>> __stmmac_open() and __stmmac_release() into stmmac_open() and
> >>>>>>> stmmac_release() where these actions will only happen when the
> >>>>>>> interface is administratively brought up or down. It does not make
> >>>>>>> sense to detach and re-attach the PHY during a change of MTU.
> >>>>>>
> >>>>>> Sorry for coming up now. But I recently noticed this commit breaks changing
> >>>>>> the MTU on i.MX8MP. Once I simply change the MTU I run into some DMA error:
> >>>>>> $ ip link set dev end1 mtu 1400
> >>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-0
> >>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-1
> >>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-2
> >>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-3
> >>>>>> imx-dwmac 30bf0000.ethernet end1: Register MEM_TYPE_PAGE_POOL RxQ-4
> >>>>>> imx-dwmac 30bf0000.ethernet end1: Link is Down
> >>>>>> imx-dwmac 30bf0000.ethernet end1: Failed to reset the dma
> >>>>>> imx-dwmac 30bf0000.ethernet end1: stmmac_hw_setup: DMA engine initialization failed
> >>>>>
> >>>>> This basically means that a clock is missing. Please provide more
> >>>>> information:
> >>>>>
> >>>>> - what kernel version are you using?
> >>>>
> >>>> Currently I am using v6.18.22.
> >>>> $ ethtool -i end1
> >>>> driver: st_gmac
> >>>> version: 6.18.22
> >>>> firmware-version:
> >>>> expansion-rom-version:
> >>>> bus-info: 30bf0000.ethernet
> >>>> supports-statistics: yes
> >>>> supports-test: no
> >>>> supports-eeprom-access: no
> >>>> supports-register-dump: yes
> >>>> supports-priv-flags: no
> >>>>
> >>>>> - has EEE been negotiated?
> >>>>
> >>>> No. It is marked as not supported
> >>>>
> >>>> $ ethtool --show-eee end1
> >>>> EEE settings for end1:
> >>>> EEE status: not supported
> >>>>
> >>>>> - does the problem persist when EEE is disabled?
> >>>>
> >>>> As EEE is not supported the problem occurs even with EEE disabled.
> >>>>
> >>>>> - which PHY is attached to stmmac?
> >>>>
> >>>> It is a TI DP83867.
> >>>>
> >>>> imx-dwmac 30bf0000.ethernet eth1: PHY [stmmac-1:03] driver [TI DP83867] (irq=136)
> >>>>
> >>>>> - which PHY interface mode is being used to connect the PHY to stmmac?
> >>>>
> >>>> For this interface
> >>>>> phy-mode = "rgmii-id";
> >>>> is set.
> >>>>
> >>>> In case it is helpful. My platform is arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mpxl.dts
> >>>> Thanks for assisting. If there a further questions, don't hesitate to ask.
> >>>
> >>> Thanks.
> >>>
> >>> So, as best I can determine at the moment, we end up with the following
> >>> sequence:
> >>>
> >>> stmmac_change_mtu()
> >>> __stmmac_release()
> >>> phylink_stop()
> >>> phy_stop()
> >>> phy->state = PHY_HALTED
> >>> _phy_state_machine() returns PHY_STATE_WORK_SUSPEND
> >>> _phy_state_machine_post_work()
> >>> phy_suspend()
> >>> genphy_suspend()
> >>> phy_set_bits(phydev, MII_BMCR, BMCR_PDOWN)
> >>>
> >>> With the DP83867, this causes most of the PHY to be powered down, thus
> >>> stopping the clocks, and this causes the stmmac reset to time out.
> >>>
> >>> Prior to this commit, we would have called phylink_disconnect_phy()
> >>> immediately after phylink_stop(), but I can see nothing that would
> >>> be affected by this change there (since that also calls
> >>> phy_suspend(), but as the PHY is already suspended, this becomes a
> >>> no-op.)
> >>>
> >>> However, __stmmac_open() would have called stmmac_init_phy(), which
> >>> would reattach the PHY. This would have called phy_init_hw(),
> >>> resetting the PHY, and phy_resume() which would ensure that the
> >>> PDOWN bit is clear - thus clocks would be running.
> >>>
> >>> As a hack, please can you try calling phylink_prepare_resume()
> >>> between the __stmmac_release() and __stmmac_open() in
> >>> stmmac_change_mtu(). This should resume the PHY, thus restoring the
> >>> clocks necessary for stmmac to reset.
> >>
> >> I tried the following patch. This works as you suspected.
> >
> > Brilliant, thanks for proving the theory why it broke.
> >
> > I'll have a think about the best way to solve this, because
> > phylink_prepare_resume() is supposed to be paired with phylink_resume()
> > and that isn't the case here.
> >
> > Please bear with me as my availability for looking at the kernel is
> > very unpredictable at present (family health issues.)
>
> FWIW I am able to reproduce this with imx8mp + ksz9131
>
> I can give this a try as Russell isn't available.
Thanks for conforming this for another PHY. What I'm wondering right now:
Why is the PHY stopped in the first place? We are just changing the MTU, no?
This has no effect on the PHY itself. "all" we need to do is reconfiguring
the DMA. I have a proof of concept running, but it needs more cleanup due
to code duplication.
Best regards
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v7 1/2] arm64: dts: bst: enable eMMC controller in C1200 CDCU1.0 board
From: gordon.ge @ 2026-04-17 8:47 UTC (permalink / raw)
To: yangzh0906
Cc: krzk, arnd, krzk+dt, robh, conor+dt, bst-upstream,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260310091211.4171307-2-yangzh0906@thundersoft.com>
Acked-by: Gordon Ge <gordon.ge@bst.ai>
^ permalink raw reply
* Re: [PATCH v2 1/1] reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ
From: Philipp Zabel @ 2026-04-17 8:47 UTC (permalink / raw)
To: Robby Cai, Frank.Li, s.hauer, festevam
Cc: krzk+dt, andrew.smirnov, kernel, imx, linux-arm-kernel,
linux-kernel, aisheng.dong, guoniu.zhou
In-Reply-To: <20260417080851.489303-1-robby.cai@nxp.com>
On Fr, 2026-04-17 at 16:08 +0800, Robby Cai wrote:
> On i.MX8MQ, the MIPI CSI reset lines are active-low and not self-clearing.
> Writing '0' asserts reset and it remains asserted until explicitly
> deasserted by software.
>
> This driver previously treated the MIPI CSI reset signals as active-high,
> which led to incorrect reset assert/deassert sequencing. This issue was
> exposed by commit 6d79bb8fd2aa ("media: imx8mq-mipi-csi2: Explicitly
> release reset").
If this patch is backported without 6d79bb8fd2aa, or the other way
around, will that break MIPI CSI-2 on older kernels? That would warrant
a Cc: stable tag.
Otherwise,
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* Re: [PATCH 3/5] media: synopsys: Add PHY stopstate wait for i.MX93
From: Frank Li @ 2026-04-17 8:51 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, linux-media, linux-kernel, devicetree, imx,
linux-arm-kernel, linux-rockchip
In-Reply-To: <20260415-csi2_imx95-v1-3-7d63f3508719@oss.nxp.com>
On Wed, Apr 15, 2026 at 11:46:54AM +0800, Guoniu Zhou wrote:
> Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
> ensures proper PHY initialization by verifying that the clock lane and
> all active data lanes have entered the stop state before proceeding with
> further operations.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
...
>
> +static int imx93_csi2rx_wait_for_phy_stopstate(struct dw_mipi_csi2rx_device *csi2)
> +{
> + struct device *dev = csi2->dev;
> + void __iomem *addr;
> + u32 stopstate_mask;
> + u32 val;
> + int ret;
> +
> + if (!dw_mipi_csi2rx_has_reg(csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE)) {
> + dev_err(dev, "phy_stopstate register not available\n");
> + return -ENXIO;
> + }
Needn't this check, you just implment this specfic callback for imx93, so
DW_MIPI_CSI2RX_PHY_STOPSTATE must be there.
> +
> + stopstate_mask = DPHY_STOPSTATE_CLK_LANE | GENMASK(csi2->lanes_num - 1, 0);
> + addr = dw_mipi_csi2rx_get_regaddr(csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE);
> +
> + ret = readl_poll_timeout(addr, val, (val & stopstate_mask) != stopstate_mask,
> + 1000, 2000000);
There are dw_mipi_csi2rx_read() helper function. So you already use
read_poll_timeout(dw_mipi_csi2rx_read, ...)
Frank
^ permalink raw reply
* Re: [PATCH v5 06/12] coresight: etm4x: fix leaked trace id
From: Jie Gan @ 2026-04-17 8:51 UTC (permalink / raw)
To: Leo Yan
Cc: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel,
suzuki.poulose, mike.leach, james.clark, alexander.shishkin
In-Reply-To: <20260417084118.GP356832@e132581.arm.com>
On 4/17/2026 4:41 PM, Leo Yan wrote:
> Hi Jie,
>
Hi Leo,
> On Fri, Apr 17, 2026 at 09:01:17AM +0800, Jie Gan wrote:
>
> [...]
>
>> ... we still need support static trace ID allocation in parallel for
>> the dummy sources and we should not break this logic in future refactor.
>
> Just confirm what is the reason you need to use static trace ID for the
> dummy sources?
>
> I am wandering if we could use dev->devt as trace ID for dummy
> devices. Since the device's MAJOR number is non-zero and occupies the
> upper bits (see MINORBITS), it is naturally separated from the hardware
> trace ID range. If so, we even don't need to bother ID alloc/release.
>
The data frame is generated by the dummy source(static TPDM, or some
other static devices, connected to a funnel or replicator, or TPDA
device) automatically(contained pre-assigned trace ID) and the data
trace is enabled by default. What we should do for the dummy source is
enabling its connected port in driver for outputting the trace data to
the connected device(funnel/TPDA/replicator etc...).
For this scenario, we cannot dynamic allocate trace ID for the dummy
source device. Because it's pre-assigned during the hardware design.
Thanks,
Jie
> Thanks,
> Leo
^ permalink raw reply
* Re: [PATCH v5 06/12] coresight: etm4x: fix leaked trace id
From: Jie Gan @ 2026-04-17 8:58 UTC (permalink / raw)
To: Leo Yan
Cc: Yeoreum Yun, coresight, linux-arm-kernel, linux-kernel,
suzuki.poulose, mike.leach, james.clark, alexander.shishkin
In-Reply-To: <61c957b5-6072-4936-a37f-84e9aad8f5e3@oss.qualcomm.com>
On 4/17/2026 4:51 PM, Jie Gan wrote:
>
>
> On 4/17/2026 4:41 PM, Leo Yan wrote:
>> Hi Jie,
>>
>
> Hi Leo,
>
>> On Fri, Apr 17, 2026 at 09:01:17AM +0800, Jie Gan wrote:
>>
>> [...]
>>
>>> ... we still need support static trace ID allocation in parallel for
>>> the dummy sources and we should not break this logic in future refactor.
>>
>> Just confirm what is the reason you need to use static trace ID for the
>> dummy sources?
>>
>> I am wandering if we could use dev->devt as trace ID for dummy
>> devices. Since the device's MAJOR number is non-zero and occupies the
>> upper bits (see MINORBITS), it is naturally separated from the hardware
>> trace ID range. If so, we even don't need to bother ID alloc/release.
>>
>
> The data frame is generated by the dummy source(static TPDM, or some
I shouldnt take TPDM as example here, TPDM is a special source device
and it's trace data will be re-constructed in it's connected TPDA device
with TPDA's trace ID.
We have some other dummy sources designed for the CDSP/ADSP/MODEM
subsystems... which cannot be directly accessed by the kernel.
Thanks,
Jie
> other static devices, connected to a funnel or replicator, or TPDA
> device) automatically(contained pre-assigned trace ID) and the data
> trace is enabled by default. What we should do for the dummy source is
> enabling its connected port in driver for outputting the trace data to
> the connected device(funnel/TPDA/replicator etc...).
>
> For this scenario, we cannot dynamic allocate trace ID for the dummy
> source device. Because it's pre-assigned during the hardware design.
>
> Thanks,
> Jie
>
>> Thanks,
>> Leo
>
^ permalink raw reply
* Re: [PATCH v4 7/8] ARM: dts: Declare UART1 on zx297520v3 boards
From: Arnd Bergmann @ 2026-04-17 8:59 UTC (permalink / raw)
To: Stefan Dösinger, Jonathan Corbet, Shuah Khan, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alexandre Belloni, Linus Walleij,
Drew Fustini, Greg Kroah-Hartman, Jiri Slaby
Cc: linux-doc, linux-kernel, linux-arm-kernel, devicetree, soc,
linux-serial
In-Reply-To: <20260416-send-v4-7-e19d02b944ec@gmail.com>
On Thu, Apr 16, 2026, at 22:19, Stefan Dösinger wrote:
>
> The reason why I add the serial1=uart1 alias is to keep console=ttyAMA1
> stable regardless of the other enabled UARTs. UART0, as the name
> implies, has a lower MMIO address, but uart1 is the one that usually has
> the boot output and console.
I'm not sure I'm following here. You generally want to either make
sure the alias matches whatever number is printed on the product
if there are multiple numbered ports, or you just use 'serial0'
as the only alias if there is only one port.
> + aliases {
> + serial1 = &uart1;
> + };
Either way, the alias should go into the board specific file, not
the general SoC file, as a board might be using a different
set of UARTs.
> +
> + /* The UART clock defaults to 26 mhz. It will be replaced when the zx29 clock
> + * framework is added.
> + */
> + uartclk: uartclk: clock-26000000 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <26000000>;
> + };
> +
> + uart1: serial@1408000 {
> + compatible = "arm,pl011", "arm,primecell";
> + arm,primecell-periphid = <0x001feffe>;
> + reg = <0x01408000 0x1000>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&uartclk>;
> + clock-names = "apb_pclk";
> + };
Since you know the addresses of the other uart instances, I would
suggest you add all of them at the same time.
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox