* 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 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 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 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 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
* [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
* [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 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
* 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
* 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 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
* [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] 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
* 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] 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 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
* [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
* [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
* 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
* 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 v5 06/12] coresight: etm4x: fix leaked trace id
From: Leo Yan @ 2026-04-17 7:52 UTC (permalink / raw)
To: Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <aeEXIfEA5NpqhGX1@e129823.arm.com>
Hi Levi,
On Thu, Apr 16, 2026 at 06:06:41PM +0100, Yeoreum Yun wrote:
[...]
> > We should use paired way for allocation and release. For example:
> >
> > coresight_enable_sysfs()
> > {
> > ...
> > coresight_path_assign_trace_id(path);
> >
> > failed:
> > coresight_path_unassign_trace_id(path);
> > }
> >
> > coresight_disable_sysfs()
> > {
> > coresight_path_unassign_trace_id(path);
> > }
> >
> > But this requires broader refactoring. E.g., the STM driver currently
> > allocates system trace IDs statically during probe, we might need to
> > consolidate for all modules to use dynamic allocation.
>
> So IIUC, Do we want to "map" per "session" and save this map information
> in the "sink" driver? or just use "global" map but locate it in sink
> driver?
I prefer to save map in the sink's driver data, this is more scalable
as the trace ID is allocated within a session rather than system wide.
> I totally agree for above suggestion -- unsigned trace id
> in the coresight_XXX function -- (but we need to add another callback
> for this) but I think we don't need to sustain map per session
> and it seems enough to use current storage for trace_id not move to
> sink driver.
>
> Anyway It would be better to refactorying wiht another patchset...
Yeah, we can come back to these ideas when work on it.
Thanks,
Leo
^ permalink raw reply
* RE: [PATCH rc v2 0/5] iommu/arm-smmu-v3: Fix device crash on kdump kernel
From: Tian, Kevin @ 2026-04-17 7:48 UTC (permalink / raw)
To: Jason Gunthorpe, Robin Murphy
Cc: Nicolin Chen, will@kernel.org, joro@8bytes.org, praan@google.com,
baolu.lu@linux.intel.com, miko.lenczewski@arm.com,
smostafa@google.com, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org, jamien@nvidia.com
In-Reply-To: <20260416172005.GB761338@nvidia.com>
> From: Jason Gunthorpe <jgg@nvidia.com>
> Sent: Friday, April 17, 2026 1:20 AM
>
> On Thu, Apr 16, 2026 at 05:49:24PM +0100, Robin Murphy wrote:
> > On 15/04/2026 10:17 pm, Nicolin Chen wrote:
> > > When transitioning to a kdump kernel, the primary kernel might have
> crashed
> > > while endpoint devices were actively bus-mastering DMA. Currently, the
> SMMU
> > > driver aggressively resets the hardware during probe by clearing
> CR0_SMMUEN
> > > and setting the Global Bypass Attribute (GBPA) to ABORT.
> > >
> > > In a kdump scenario, this aggressive reset is highly destructive:
> > > a) If GBPA is set to ABORT, in-flight DMA will be aborted, generating fatal
> > > PCIe AER or SErrors that may panic the kdump kernel
> > > b) If GBPA is set to BYPASS, in-flight DMA targeting some IOVAs will
> bypass
> > > the SMMU and corrupt the physical memory at those 1:1 mapped
> IOVAs.
> >
> > But wasn't that rather the point? Th kdump kernel doesn't know the scope
> of
> > how much could have gone wrong (including potentially the SMMU
> configuration
> > itself), so it just blocks everything, resets and reenables the devices it
> > cares about, and ignores whatever else might be on fire.
>
> The purpose of kdump is to have the maximum chance to capture a dump
> from the blown up kernel.
>
> Yes, on a perfect platform aborting the entire SMMU should improve the
> chance of getting that dump.
>
> But sadly there are so many busted up platforms where if you start
> messing with the IOMMU they will explode and blow up the kdump. x86
> and "firmware first" error handling systems are particularly notorious
> for nasty behavior like this.
>
> Seems like there are now ARM systems too. :(
is there any report on such systems? It might be informational to include
a link to the report so it's clear that this series fixes real issues instead of
a preparation for coming systems...
>
> So, the iommu drivers have been preserving the IOMMU and not
> disrupting the DMAs on x86 for a long time. This is established kdump
> practice.
>
> > If AER can panic a kdump kernel, that seems like a failing of the kdump
> > kernel itself more than anything else (especially given the likelihood that
> > additional AER events could follow from whatever initial crash/failure
> > triggered kdump to begin with).
>
> Probably the kdump wasn't triggered by AER. You want kdump to not
> trigger more RAS events that might blow up the kdump while it is
> trying to run.. That increases the chance of success
>
btw the DMA is allowed after the previous kernel is hung til the point
where smmu driver blocks it. In cases where in-fly DMAs are considered
dangerous to kdump, this series just make it worse instead of creating
a new issue. While for majority other failures not related to DMAs,
unblocking then increases the chance of success...
^ permalink raw reply
* Re: [PATCH v6 08/10] clk: realtek: Add RTD1625-CRT clock controller driver
From: Yu-Chun Lin @ 2026-04-17 7:45 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_bsflBlSGf9M-h@redhat.com>
Hi Brian,
> Hi Yu-Chun,
>
(snip)
> > +
> > +static const struct reg_sequence pll_acpu_seq_power_off[] = {
> > + {RTD1625_REG_PLL_ACPU2, 0x4},
> > +};
> > +
> > +static const struct reg_sequence pll_acpu_seq_pre_set_freq[] = {
> > + {RTD1625_REG_PLL_SSC_DIG_ACPU0, 0x4},
> > +};
> > +
> > +static const struct reg_sequence pll_acpu_seq_post_set_freq[] = {
> > + {RTD1625_REG_PLL_SSC_DIG_ACPU0, 0x5},
> > +};
> > +
> > +static struct clk_pll pll_acpu = {
>
> static const?
>
The clock object should not be declared as const.
> > + .clkr.hw.init = CLK_HW_INIT("pll_acpu", "osc27m", &rtk_clk_pll_ops, CLK_GET_RATE_NOCACHE),
> > + .seq_power_on = pll_acpu_seq_power_on,
> > + .num_seq_power_on = ARRAY_SIZE(pll_acpu_seq_power_on),
> > + .seq_power_off = pll_acpu_seq_power_off,
> > + .num_seq_power_off = ARRAY_SIZE(pll_acpu_seq_power_off),
> > + .seq_pre_set_freq = pll_acpu_seq_pre_set_freq,
> > + .num_seq_pre_set_freq = ARRAY_SIZE(pll_acpu_seq_pre_set_freq),
> > + .seq_post_set_freq = pll_acpu_seq_post_set_freq,
> > + .num_seq_post_set_freq = ARRAY_SIZE(pll_acpu_seq_post_set_freq),
> > + .freq_reg = RTD1625_REG_PLL_SSC_DIG_ACPU1,
> > + .freq_tbl = acpu_tbl,
> > + .freq_mask = FREQ_NF_MASK,
> > + .freq_ready_reg = RTD1625_REG_PLL_SSC_DIG_ACPU_DBG2,
> > + .freq_ready_mask = BIT(20),
> > + .freq_ready_val = BIT(20),
> > + .power_reg = RTD1625_REG_PLL_ACPU2,
> > + .power_mask = 0x7,
> > + .power_val_on = 0x3,
> > +};
(snip)
> > +
> > +static const struct reg_sequence pll_ve1_seq_post_set_freq[] = {
> > + {RTD1625_REG_PLL_SSC_DIG_VE1_0, 0x5},
> > +};
> > +
> > +static struct clk_pll pll_ve1 = {
>
> Same here about static const, plus some others below?
>
No. The clock object cannot be const.
(snip)
> > +static const struct of_device_id rtd1625_crt_match[] = {
> > + {.compatible = "realtek,rtd1625-crt-clk", .data = &rtd1625_crt_desc,},
> > + {/* sentinel */}
>
> Add a space around the comment like so:
>
> { /* sentinel */ }
>
Ack.
>
> > +};
> > +
> > +static struct platform_driver rtd1625_crt_driver = {
> > + .probe = rtd1625_crt_probe,
> > + .driver = {
> > + .name = "rtk-rtd1625-crt-clk",
> > + .of_match_table = rtd1625_crt_match,
> > + },
> > +};
> > +
> > +static int __init rtd1625_crt_init(void)
> > +{
> > + return platform_driver_register(&rtd1625_crt_driver);
> > +}
> > +subsys_initcall(rtd1625_crt_init);
> > +
> > +MODULE_DESCRIPTION("Reatek RTD1625 CRT Controller Driver");
>
>s/Reatek/Realtex/
>
Will fix it.
> > +MODULE_AUTHOR("Cheng-Yu Lee <cylee12@realtek.com>");
> > +MODULE_LICENSE("GPL");
> > +MODULE_IMPORT_NS("REALTEK_CLK");
> > diff --git a/drivers/reset/realtek/Kconfig b/drivers/reset/realtek/Kconfig
> > index 99a14d355803..a44c7834191c 100644
> > --- a/drivers/reset/realtek/Kconfig
> > +++ b/drivers/reset/realtek/Kconfig
> > @@ -1,3 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> > config RESET_RTK_COMMON
> > bool
> > + select AUXILIARY_BUS
> > + default COMMON_CLK_RTD1625
> > diff --git a/drivers/reset/realtek/Makefile b/drivers/reset/realtek/Makefile
> > index b59a3f7f2453..8ca1fa939f10 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
> > +obj-$(CONFIG_RESET_RTK_COMMON) += common.o reset-rtd1625-crt.o
>
>CONFIG_RESET_RTK_COMMON is supposed to be common, right? If so, the
> SoC-specific driver shouldn't be included here.
>
This Makefile will change to
obj-$(CONFIG_RESET_RTK_COMMON) += common.o
obj-$(CONFIG_RESET_RTD1625) += reset-rtd1625-crt.o
> > diff --git a/drivers/reset/realtek/reset-rtd1625-crt.c b/drivers/reset/realtek/reset-rtd1625-crt.c
> > new file mode 100644
> > index 000000000000..ebb15bb68885
> > --- /dev/null
> > +++ b/drivers/reset/realtek/reset-rtd1625-crt.c
> > @@ -0,0 +1,186 @@
> > +// 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/slab.h>
> > +#include "common.h"
> > +
> > +#define RTD1625_CRT_RSTN_MAX 123
> > +
> > +static struct rtk_reset_desc rtd1625_crt_reset_descs[] = {
> > + /* Bank 0: offset 0x0 */
> > + [RTD1625_CRT_RSTN_MISC] = { .ofs = 0x0, .bit = 0, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_DIP] = { .ofs = 0x0, .bit = 2, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_GSPI] = { .ofs = 0x0, .bit = 4, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_SDS] = { .ofs = 0x0, .bit = 6, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_SDS_REG] = { .ofs = 0x0, .bit = 8, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_SDS_PHY] = { .ofs = 0x0, .bit = 10, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_GPU2D] = { .ofs = 0x0, .bit = 12, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_DC_PHY] = { .ofs = 0x0, .bit = 22, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_DCPHY_CRT] = { .ofs = 0x0, .bit = 24, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_LSADC] = { .ofs = 0x0, .bit = 26, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_SE] = { .ofs = 0x0, .bit = 28, .write_en = 1 },
> > + [RTD1625_CRT_RSTN_DLA] = { .ofs = 0x0, .bit = 30, .write_en = 1 },
>
> Sashiko reports:
> https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> Can this cause undefined behavior during reset mask computation?
>
> Several reset array entries set .bit = 30 and .write_en = 1. In
> rtk_reset_assert() and rtk_reset_deassert(), if the bitmask is computed as
> 0x3 << desc->bit, 0x3 is a signed 32-bit integer literal. Left-shifting it by
> 30 results in 0xC0000000, which exceeds the maximum positive value for a
> signed 32-bit integer.
>
> Modifying the sign bit via left-shift on a signed type invokes undefined
> behavior in C. Would an unsigned literal (e.g., 0x3U << desc->bit) be needed
> to safely construct the mask?
Agreed, Will make it 0x3U.
(snip)
> > +
> > +static int rtd1625_crt_reset_probe(struct auxiliary_device *adev,
> > + const struct auxiliary_device_id *id)
> > +{
> > + struct device *dev = &adev->dev;
> > + struct rtk_reset_data *data;
> > +
> > + data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> > + if (!data)
> > + return -ENOMEM;
> > +
> > + data->descs = rtd1625_crt_reset_descs;
> > + data->rcdev.nr_resets = RTD1625_CRT_RSTN_MAX;
> > + return rtk_reset_controller_add(dev, data);
>
> Sashiko reports:
> https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> Will the reset controller driver unconditionally fail to probe with -ENODEV
> due to an incompatible regmap acquisition method?
>
> The rtk_reset_controller_add() helper attempts to retrieve the shared regmap
> from the parent clock device using dev_get_regmap(parent, NULL). However, the
> parent clock driver (rtk_clk_probe()) acquires its regmap via
> device_node_to_regmap().
>
> This syscon helper creates the regmap but does not associate it with the
> parent struct device via devres. Because the regmap is absent from the
> parent's devres list, dev_get_regmap() will always return NULL, causing the
> reset driver probe to fail unconditionally and leaving dependent peripherals
> without reset control.
>
> Brian
>
Thanks for identifying this issue. I've fixed the regmap passing mechanism:
Changes:
1. 'rtk_reset_controller_register()' in clk/realtek/common.c passes the
regmap as platform data via 'devm_auxiliary_device_create()'
2. 'rtk_reset_controller_add()' in reset/realtek/common.c retrieves it
using 'dev_get_platdata()' instead of 'dev_get_regmap()'
This ensures the reset controller can access the shared regmap regardless
of how the parent clock driver acquired it
Best Regards,
Yu-Chun
^ permalink raw reply
* Re: [PATCH v6 07/10] clk: realtek: Add support for MMC-tuned PLL clocks
From: Yu-Chun Lin @ 2026-04-17 7:43 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_YfHe0dscb3MPw@redhat.com>
Hi Brian,
> Hi Yu-Chun,
>
> I should have finished going through Sashiko while manually reviewing
> your patches.
>
> On Thu, Apr 02, 2026 at 03:39:54PM +0800, Yu-Chun Lin wrote:
>> From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Add clk_pll_mmc_ops for enable/disable, prepare, rate control, and status
> > operations on MMC PLL clocks.
> >
> > Also add clk_pll_mmc_phase_ops to support phase get/set operations.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Jyan Chou <jyanchou@realtek.com>
> > Signed-off-by: Jyan Chou <jyanchou@realtek.com>
> > Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> > ---
> > +static int clk_pll_mmc_set_rate(struct clk_hw *hw, unsigned long rate, unsigned long parent_rate)
> > +{
> > + struct clk_pll_mmc *clkm = to_clk_pll_mmc(hw);
> > + u32 val = PLL_MMC_SSC_DIV_N_VAL;
> > + int ret;
> > +
> > + ret = regmap_update_bits(clkm->clkr.regmap,
> > + clkm->ssc_dig_ofs + PLL_SSC_DIG_EMMC1_OFFSET,
> > + PLL_FLAG_INITAL_EMMC_MASK, 0x0 << PLL_FLAG_INITAL_EMMC_SHIFT);
> > + if (ret)
> > + return ret;
> > +
> > + ret = set_ssc_div_n(clkm, val);
> > + if (ret)
> > + return ret;
> > +
> > + ret = set_ssc_div_ext_f(clkm, 1517);
> > + if (ret)
> > + return ret;
> > +
> > + switch (val) {
> > + case 31 ... 46:
> > + ret |= set_pi_ibselh(clkm, 3);
> > + ret |= set_sscpll_rs(clkm, 3);
> > + ret |= set_sscpll_icp(clkm, 2);
>
> Sashiko reports:
> https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> Is it intended to use bitwise OR to accumulate these return values? Because
> these hardware operations return standard negative error codes on failure,
> performing a bitwise OR on multiple negative integers will merge their bit
> patterns and create a corrupted error code.
>
Will return immediately upon the first error.
> > + break;
> > +
> > + case 20 ... 30:
> > + ret |= set_pi_ibselh(clkm, 2);
> > + ret |= set_sscpll_rs(clkm, 3);
> > + ret |= set_sscpll_icp(clkm, 1);
> > + break;
> > +
> > + case 10 ... 19:
> > + ret |= set_pi_ibselh(clkm, 1);
> > + ret |= set_sscpll_rs(clkm, 2);
> > + ret |= set_sscpll_icp(clkm, 1);
> > + break;
> > +
> > + case 5 ... 9:
> > + ret |= set_pi_ibselh(clkm, 0);
> > + ret |= set_sscpll_rs(clkm, 2);
> > + ret |= set_sscpll_icp(clkm, 0);
> > + break;
> > + }
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_update_bits(clkm->clkr.regmap,
> > + clkm->ssc_dig_ofs + PLL_SSC_DIG_EMMC3_OFFSET,
> > + PLL_NCODE_SSC_EMMC_MASK,
> > + 27 << PLL_NCODE_SSC_EMMC_SHIFT);
>
> Sashiko reports:
> https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> Are the mask and shift values mismatched here? PLL_FLAG_INITAL_EMMC_MASK is
> defined as BIT(1) (0x02), but PLL_FLAG_INITAL_EMMC_SHIFT is 8.
>
> When regmap_update_bits() applies the 0x02 mask to a value shifted by 8,
> won't it evaluate to 0 and fail to set the intended initialization flag?
>
> Brian
You're right, will fix it.
Yu-Chun.
^ permalink raw reply
* Re: [PATCH v6 07/10] clk: realtek: Add support for MMC-tuned PLL clocks
From: Yu-Chun Lin @ 2026-04-17 7:40 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_XtHzDpIjHW8xT@redhat.com>
Hi Brian,
Sorry for the late reply.
> Hi Yu-Chun and Cheng-Yu,
>
> On Thu, Apr 02, 2026 at 03:39:54PM +0800, Yu-Chun Lin wrote:
> > From: Cheng-Yu Lee <cylee12@realtek.com>
> >
> > Add clk_pll_mmc_ops for enable/disable, prepare, rate control, and status
> > operations on MMC PLL clocks.
> >
> > Also add clk_pll_mmc_phase_ops to support phase get/set operations.
> >
> > Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> > Co-developed-by: Jyan Chou <jyanchou@realtek.com>
> > Signed-off-by: Jyan Chou <jyanchou@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 to_clk_pll_mmc() from clk-pll.h to clk-pll-mmc.c to limit its scope.
> > - Change offset type from int to unsigned int.
> > ---
> > MAINTAINERS | 8 +
> > drivers/clk/realtek/Kconfig | 3 +
> > drivers/clk/realtek/Makefile | 2 +
> > drivers/clk/realtek/clk-pll-mmc.c | 410 ++++++++++++++++++++++++++++++
> > drivers/clk/realtek/clk-pll.h | 13 +
> > 5 files changed, 436 insertions(+)
> > create mode 100644 drivers/clk/realtek/clk-pll-mmc.c
> >
(snip)
> > +
> > +static inline int get_phrt0(struct clk_pll_mmc *clkm, u32 *val)
> > +{
> > + u32 reg;
> > + int ret;
> > +
> > + ret = regmap_read(clkm->clkr.regmap, clkm->pll_ofs + PLL_EMMC1_OFFSET, ®);
> > + if (ret)
> > + return ret;
> > +
> > + *val = (reg >> PLL_PHRT0_SHIFT) & PLL_PHRT0_MASK;
>
> Sashiko reports the following:
> https://sashiko.dev/#/patchset/20260402073957.2742459-1-eleanor.lin%40realtek.com
>
> With PLL_PHRT0_SHIFT defined as 1 and PLL_PHRT0_MASK as BIT(1) (0x02), shifting
> right by 1 moves the target bit 1 to position 0, but masking with 0x02 checks
> position 1 of the shifted value.
>
> Will this cause clk_pll_mmc_is_enabled() to always evaluate to false since it
> expects val == 0x1?
>
Thank you for catching this critical bug! You're absolutely right.
The issue is that I incorrectly used BIT() for the mask values
I will correct them, like PLL_PHRT0_MASK from BIT(1) to 0x1.
> > + return 0;
> > +}
> > +
> > +static inline int set_phrt0(struct clk_pll_mmc *clkm, u32 val)
> > +{
> > + return regmap_update_bits(clkm->clkr.regmap, clkm->pll_ofs + PLL_EMMC1_OFFSET,
> > + PLL_PHRT0_MASK, val << PLL_PHRT0_SHIFT);
> > +}
> > +
> > +static inline int get_phsel(struct clk_pll_mmc *clkm, int id, u32 *val)
> > +{
> > + int ret;
> > + u32 raw_val;
> > + u32 sft = id ? 8 : 3;
>
> Put variables in reverse Christmas tree order.
>
Ack.
(snip)
> > +
> > +static int clk_pll_mmc_phase_set_phase(struct clk_hw *hw, int degrees)
> > +{
> > + struct clk_hw *hwp = clk_hw_get_parent(hw);
> > + struct clk_pll_mmc *clkm;
> > + int phase_id;
> > + int ret;
> > + u32 val;
> > +
> > + if (!hwp)
> > + return -ENOENT;
> > +
> > + clkm = to_clk_pll_mmc(hwp);
> > + phase_id = (hw - &clkm->phase0_hw) ? 1 : 0;
>
> Are you checking to see if these two pointers are the same? If so, what
> do you think about this instead?
>
> hw == &clkm->phase0_hw
>
>
> Does you mean phase_id = (hw == &clkm->phase0_hw) ? 0 : 1; ?
>
Yes, I will revise it according to your suggestion.
> > + val = DIV_ROUND_CLOSEST(degrees * 100, PHASE_SCALE_FACTOR);
> > + ret = set_phsel(clkm, phase_id, val);
> > + if (ret)
> > + return ret;
> > +
> > + usleep_range(10, 20);
> > + return 0;
> > +}
> > +
(snip)
> > +
> > +static unsigned long clk_pll_mmc_recalc_rate(struct clk_hw *hw, unsigned long parent_rate)
> > +{
> > + struct clk_pll_mmc *clkm = to_clk_pll_mmc(hw);
> > + u32 val, ext_f;
> > + int ret;
> > +
> > + ret = get_ssc_div_n(clkm, &val);
> > + if (ret)
> > + return ret;
> > +
> > + ret = get_ssc_div_ext_f(clkm, &ext_f);
> > + if (ret)
> > + return ret;
> > +
> > + return parent_rate / 4 * (val + 2) + (parent_rate / 4 * ext_f) / 8192;
> > +}
> > +
> > +static int clk_pll_mmc_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
> > +{
>
> Should there be a check for a parent rate of zero before the division is
> done?
>
Ack, I will do it.
> > + u32 val = DIV_ROUND_CLOSEST(req->rate * 4, req->best_parent_rate);
> > +
> > + req->rate = req->best_parent_rate * val / 4;
> > + return 0;
> > +}
> > +
> > +static int clk_pll_mmc_set_rate(struct clk_hw *hw, unsigned long rate, unsigned long parent_rate)
> > +{
> > + struct clk_pll_mmc *clkm = to_clk_pll_mmc(hw);
> > + u32 val = PLL_MMC_SSC_DIV_N_VAL;
> > + int ret;
> > +
> > + ret = regmap_update_bits(clkm->clkr.regmap,
> > + clkm->ssc_dig_ofs + PLL_SSC_DIG_EMMC1_OFFSET,
> > + PLL_FLAG_INITAL_EMMC_MASK, 0x0 << PLL_FLAG_INITAL_EMMC_SHIFT);
> > + if (ret)
> > + return ret;
> > +
> > + ret = set_ssc_div_n(clkm, val);
> > + if (ret)
> > + return ret;
> > +
> > + ret = set_ssc_div_ext_f(clkm, 1517);
> > + if (ret)
> > + return ret;
> > +
> > + switch (val) {
> > + case 31 ... 46:
> > + ret |= set_pi_ibselh(clkm, 3);
> > + ret |= set_sscpll_rs(clkm, 3);
> > + ret |= set_sscpll_icp(clkm, 2);
> > + break;
> > +
> > + case 20 ... 30:
> > + ret |= set_pi_ibselh(clkm, 2);
> > + ret |= set_sscpll_rs(clkm, 3);
> > + ret |= set_sscpll_icp(clkm, 1);
> > + break;
> > +
> > + case 10 ... 19:
> > + ret |= set_pi_ibselh(clkm, 1);
> > + ret |= set_sscpll_rs(clkm, 2);
> > + ret |= set_sscpll_icp(clkm, 1);
> > + break;
> > +
> > + case 5 ... 9:
> > + ret |= set_pi_ibselh(clkm, 0);
> > + ret |= set_sscpll_rs(clkm, 2);
> > + ret |= set_sscpll_icp(clkm, 0);
> > + break;
> > + }
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_update_bits(clkm->clkr.regmap,
> > + clkm->ssc_dig_ofs + PLL_SSC_DIG_EMMC3_OFFSET,
> > + PLL_NCODE_SSC_EMMC_MASK,
> > + 27 << PLL_NCODE_SSC_EMMC_SHIFT);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_update_bits(clkm->clkr.regmap,
> > + clkm->ssc_dig_ofs + PLL_SSC_DIG_EMMC3_OFFSET,
> > + PLL_FCODE_SSC_EMMC_MASK, 321);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_update_bits(clkm->clkr.regmap,
> > + clkm->ssc_dig_ofs + PLL_SSC_DIG_EMMC4_OFFSET,
> > + PLL_GRAN_EST_EM_MC_MASK, 5985);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_update_bits(clkm->clkr.regmap,
> > + clkm->ssc_dig_ofs + PLL_SSC_DIG_EMMC1_OFFSET,
> > + PLL_EN_SSC_EMMC_MASK, 0x1);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_update_bits(clkm->clkr.regmap,
> > + clkm->ssc_dig_ofs + PLL_SSC_DIG_EMMC1_OFFSET,
> > + PLL_EN_SSC_EMMC_MASK, 0x0);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_update_bits(clkm->clkr.regmap,
> > + clkm->ssc_dig_ofs + PLL_SSC_DIG_EMMC1_OFFSET,
> > + PLL_FLAG_INITAL_EMMC_MASK,
> > + 0x1 << PLL_FLAG_INITAL_EMMC_SHIFT);
>
> It looks like the rate and parent rate are not used in this function.
> Will this always end up with the same rate when everything is
> successful?
>
> Brian
Despite receiving various rate requests (26MHz, 52MHz, 200MHz), this function
consistently returns 0x1b (represents the 27MHz) because it reflects the input
reference clock frequency to the SSCPLL, not the PLL output frequency.
However, the emmc host controller handles frequency division internally to
achieve the requested eMMC frequency.
Best Regards,
Yu-Chun
^ 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