* Re: [PATCH v2 2/2] drm: lcdif: Wait for vblank before disabling DMA
From: Liu Ying @ 2026-04-07 6:34 UTC (permalink / raw)
To: Paul Kocialkowski, dri-devel, imx, linux-arm-kernel, linux-kernel
Cc: Marek Vasut, Stefan Agner, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Lucas Stach,
Krzysztof Hałasa, Marco Felsch
In-Reply-To: <20260402183351.3281123-3-paulk@sys-base.io>
Hi Paul,
On Thu, Apr 02, 2026 at 08:33:51PM +0200, Paul Kocialkowski wrote:
> It is necessary to wait for the full frame to finish streaming
> through the DMA engine before we can safely disable it by removing
> the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> hardware confused and unable to resume streaming for the next frame.
>
> This causes the FIFO underrun and empty status bits to be set and
> a single solid color to be shown on the display, coming from one of
> the pixels of the previous frame. The issue occurs sporadically when
> a new mode is set, which triggers the crtc disable and enable paths.
>
> Setting the shadow load bit and waiting for it to be cleared by the
> DMA engine allows waiting for completion.
>
> The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
>
> Fixes: 9db35bb349a0 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> Co-developed-by: Lucas Stach <l.stach@pengutronix.de>
There is a warning reported by checkpatch.pl:
WARNING: Co-developed-by: must be immediately followed by Signed-off-by:
#23:
Co-developed-by: Lucas Stach <l.stach@pengutronix.de>
With this fixed:
Acked-by: Liu Ying <victor.liu@nxp.com>
Thanks!
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v3] ACPI: AGDI: fix missing newline in error message
From: Hanjun Guo @ 2026-04-07 6:36 UTC (permalink / raw)
To: Haoyu Lu, Rafael J . Wysocki, Lorenzo Pieralisi, Sudeep Holla,
Catalin Marinas, Will Deacon
Cc: Len Brown, Ilkka Koskinen, Russell King, linux-acpi,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260407033117.100-1-hechushiguitu666@gmail.com>
On 2026/4/7 11:31, Haoyu Lu wrote:
> Add the missing trailing newline to the dev_err() message
> printed when SDEI event registration fails.
>
> This keeps the error output as a properly terminated log line.
>
> Fixes: a2a591fb76e6f5461dfd04715b69c317e50c43a5 ("ACPI: AGDI: Add driver for Arm Generic Diagnostic Dump and Reset device")
> Reviewed-by: Ilkka Koskinen <ilkka@os.amperecomputing.com>
> Signed-off-by: Haoyu Lu <hechushiguitu666@gmail.com>
> ---
> Changes in v2:
> - Change subject prefix from "acpi: arm64: agdi:" to "ACPI: AGDI:"
>
> Changes in v3:
> - Move version history below the "---" separator as per review feedback
>
> drivers/acpi/arm64/agdi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/agdi.c b/drivers/acpi/arm64/agdi.c
> index feb4b2cb4618..0c2d9d6c160b 100644
> --- a/drivers/acpi/arm64/agdi.c
> +++ b/drivers/acpi/arm64/agdi.c
> @@ -36,7 +36,7 @@ static int agdi_sdei_probe(struct platform_device *pdev,
>
> err = sdei_event_register(adata->sdei_event, agdi_sdei_handler, pdev);
> if (err) {
> - dev_err(&pdev->dev, "Failed to register for SDEI event %d",
> + dev_err(&pdev->dev, "Failed to register for SDEI event %d\n",
> adata->sdei_event);
> return err;
> }
Reviewed-by: Hanjun Guo <guohanjun@huawei.com>
Thanks
Hanjun
^ permalink raw reply
* RE: [PATCH V10 04/13] PCI: imx6: Assert PERST# before enabling regulators
From: Sherry Sun @ 2026-04-07 6:38 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <jwazawvhuoafkhfwpjfgccc3hz6kej7i6iwkh5be2qena2b4di@yzv6e75zezfu>
> On Thu, Apr 02, 2026 at 05:50:58PM +0800, Sherry Sun wrote:
> > According to the PCIe initialization requirements, PERST# signal
> > should be asserted before applying power to the PCIe device, and
> > deasserted after power and reference clock are stable.
> >
>
> Spec wording is not quite like this. Spec mandates asserting PERST# *before*
> stopping refclk and powering down the device and deasserting it *after*
> applying power and refclk stable.
>
> I believe you want to assert PERST# before enabling regulator to prevent the
> endpoint from functioning? If so, is it due to refclk not available yet or some
> other reason?
You are right. My commit message wording was not that precise.
The PCIe endpoint may start responding or driving signals as
soon as its supply is enabled, even before the reference clock is stable.
Asserting PERST# before enabling the regulator ensures that the endpoint
remains in reset throughout the entire power-up sequence, until both
power and refclk are known to be stable and link initialization can safely
begin. This is mainly to avoid undefined behavior during early power-up.
I will update the commit message to better reflect this.
>
> > Currently, the driver enables the vpcie3v3aux regulator in
> > imx_pcie_probe() before PERST# is asserted in imx_pcie_host_init(),
> > which violates the PCIe power sequencing requirements. However, there
> > is no issue so far because PERST# is requested as GPIOD_OUT_HIGH in
> > imx_pcie_probe(), which guarantees that PERST# is asserted before
> > enabling the vpcie3v3aux regulator.
> >
> > This is prepare for the upcoming changes that will parse the reset
> > property using the new Root Port binding, which will use GPIOD_ASIS
> > when requesting the reset GPIO. With GPIOD_ASIS, the GPIO state is not
> > guaranteed, so explicit sequencing is required.
> >
> > Fix the power sequencing by:
> > 1. Moving vpcie3v3aux regulator enable from probe to
> > imx_pcie_host_init(), where it can be properly sequenced with PERST#.
> > 2. Moving imx_pcie_assert_perst() before regulator and clock enable to
> > ensure correct ordering.
> >
> > The vpcie3v3aux regulator is kept enabled for the entire PCIe
> > controller lifecycle and automatically disabled on device removal via devm
> cleanup.
> >
>
> vpcie3v3aux handling should be in a separate patch.
Actually the handling of vpcie3v3aux itself remains unchanged, I just adjust the
sequence of regulator/clock enable and perst#.
Previously, the imx driver enabled the vpcie3v3aux regulator in imx_pcie_probe()
before PERST# is asserted in imx_pcie_host_init(), which violates the PCIe power
sequencing requirements.
This patch moves vpcie3v3aux regulator enable from probe to imx_pcie_host_init(),
where it can be properly sequenced with PERST#.
Perhaps I should just remove this description to avoid confusion.
Best Regards
Sherry
>
> - Mani
>
> > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > ---
> > drivers/pci/controller/dwc/pci-imx6.c | 49
> > +++++++++++++++++++++------
> > 1 file changed, 39 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/pci/controller/dwc/pci-imx6.c
> > b/drivers/pci/controller/dwc/pci-imx6.c
> > index 45d70ae7e04f..948ffb75d122 100644
> > --- a/drivers/pci/controller/dwc/pci-imx6.c
> > +++ b/drivers/pci/controller/dwc/pci-imx6.c
> > @@ -166,6 +166,8 @@ struct imx_pcie {
> > u32 tx_swing_full;
> > u32 tx_swing_low;
> > struct regulator *vpcie;
> > + struct regulator *vpcie_aux;
> > + bool vpcie_aux_enabled;
> > struct regulator *vph;
> > void __iomem *phy_base;
> >
> > @@ -1220,6 +1222,13 @@ static void imx_pcie_disable_device(struct
> pci_host_bridge *bridge,
> > imx_pcie_remove_lut(imx_pcie, pci_dev_id(pdev)); }
> >
> > +static void imx_pcie_vpcie_aux_disable(void *data) {
> > + struct regulator *vpcie_aux = data;
> > +
> > + regulator_disable(vpcie_aux);
> > +}
> > +
> > static void imx_pcie_assert_perst(struct imx_pcie *imx_pcie, bool
> > assert) {
> > if (assert) {
> > @@ -1240,6 +1249,24 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > struct imx_pcie *imx_pcie = to_imx_pcie(pci);
> > int ret;
> >
> > + imx_pcie_assert_perst(imx_pcie, true);
> > +
> > + /* Keep 3.3Vaux supply enabled for the entire PCIe controller lifecycle
> */
> > + if (imx_pcie->vpcie_aux && !imx_pcie->vpcie_aux_enabled) {
> > + ret = regulator_enable(imx_pcie->vpcie_aux);
> > + if (ret) {
> > + dev_err(dev, "failed to enable vpcie_aux
> regulator: %d\n",
> > + ret);
> > + return ret;
> > + }
> > + imx_pcie->vpcie_aux_enabled = true;
> > +
> > + ret = devm_add_action_or_reset(dev,
> imx_pcie_vpcie_aux_disable,
> > + imx_pcie->vpcie_aux);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > if (imx_pcie->vpcie) {
> > ret = regulator_enable(imx_pcie->vpcie);
> > if (ret) {
> > @@ -1249,25 +1276,24 @@ static int imx_pcie_host_init(struct dw_pcie_rp
> *pp)
> > }
> > }
> >
> > + ret = imx_pcie_clk_enable(imx_pcie);
> > + if (ret) {
> > + dev_err(dev, "unable to enable pcie clocks: %d\n", ret);
> > + goto err_reg_disable;
> > + }
> > +
> > if (pp->bridge && imx_check_flag(imx_pcie,
> IMX_PCIE_FLAG_HAS_LUT)) {
> > pp->bridge->enable_device = imx_pcie_enable_device;
> > pp->bridge->disable_device = imx_pcie_disable_device;
> > }
> >
> > imx_pcie_assert_core_reset(imx_pcie);
> > - imx_pcie_assert_perst(imx_pcie, true);
> >
> > if (imx_pcie->drvdata->init_phy)
> > imx_pcie->drvdata->init_phy(imx_pcie);
> >
> > imx_pcie_configure_type(imx_pcie);
> >
> > - ret = imx_pcie_clk_enable(imx_pcie);
> > - if (ret) {
> > - dev_err(dev, "unable to enable pcie clocks: %d\n", ret);
> > - goto err_reg_disable;
> > - }
> > -
> > if (imx_pcie->phy) {
> > ret = phy_init(imx_pcie->phy);
> > if (ret) {
> > @@ -1780,9 +1806,12 @@ static int imx_pcie_probe(struct platform_device
> *pdev)
> > of_property_read_u32(node, "fsl,max-link-speed", &pci-
> >max_link_speed);
> > imx_pcie->supports_clkreq = of_property_read_bool(node,
> > "supports-clkreq");
> >
> > - ret = devm_regulator_get_enable_optional(&pdev->dev,
> "vpcie3v3aux");
> > - if (ret < 0 && ret != -ENODEV)
> > - return dev_err_probe(dev, ret, "failed to enable Vaux
> supply\n");
> > + imx_pcie->vpcie_aux = devm_regulator_get_optional(&pdev->dev,
> "vpcie3v3aux");
> > + if (IS_ERR(imx_pcie->vpcie_aux)) {
> > + if (PTR_ERR(imx_pcie->vpcie_aux) != -ENODEV)
> > + return PTR_ERR(imx_pcie->vpcie_aux);
> > + imx_pcie->vpcie_aux = NULL;
> > + }
> >
> > imx_pcie->vpcie = devm_regulator_get_optional(&pdev->dev,
> "vpcie");
> > if (IS_ERR(imx_pcie->vpcie)) {
> > --
> > 2.37.1
> >
>
> --
> மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v5 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Linus Walleij @ 2026-04-07 6:42 UTC (permalink / raw)
To: Frank Li, Peter Rosin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <20260327-pinctrl-mux-v5-0-d4aec9d62c62@nxp.com>
Hi Frank,
OK let's apply it!
On Fri, Mar 27, 2026 at 10:34 PM Frank Li <Frank.Li@nxp.com> wrote:
> mux: add devm_mux_control_get_from_np() to get mux from child node
Didn't get an ACK from the mux maintainer for this but this has been going
on for long now so I applied it.
Peter: protest if you don't like this and I will back it out.
> dt-bindings: pinctrl: Add generic pinctrl for board-level mux chips
> pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
> pinctrl: add optional .release_mux() callback
> pinctrl: add generic board-level pinctrl driver using mux framework
Those applied.
> arm64: dts: imx8mp-evk: add board-level mux for CAN2 and MICFIL
> arm64: dts: imx8mp-evk: add flexcan2 overlay file
Please funnel these through the SoC tree!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 0/3] i2c: ma35d1: Add support for MA35D1 I2C controller
From: zychen @ 2026-04-07 6:45 UTC (permalink / raw)
To: andi.shyti, ychuang3
Cc: robh, krzk+dt, conor+dt, linux-i2c, devicetree, linux-arm-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260316063726.41048-1-zychennvt@gmail.com>
Hi Andi and Krzysztof,
I'm following up on this series. As detailed in the change log, v2 addresses the feedback from v1 regarding the modernization of legacy code.
I am preparing v3 to address minor formatting issues in Patch 3 (DTS). Before sending it out, I would highly appreciate any technical feedback on the driver logic in Patch 2 to ensure it aligns with your expectations.
Best regards,
Zi-Yu
Zi-Yu Chen 於 2026/3/16 下午 02:37 寫道:
> This series adds support for the I2C controller found in the Nuvoton
> MA35D1 SoC. The driver supports controller and optional target mode
> and runtime power management.
>
> The implementation has been tested on the Nuvoton MA35D1 SOM board.
>
> Changes in v2:
> - Overall:
> - Rebase on linux-i2c/i2c-next
> - Switched terminology from "master/slave" to "controller/target".
>
> - Patch 1 (dt-bindings):
> - Simplified description and fixed 'reg' size in example.
>
> - Patch 2 (driver):
> - Modernized using devm_*, generic device properties, and FIELD_PREP/GENMASK.
> - Optimized power management by moving clock control to runtime PM.
> - Simplified code by removing redundant .remove(), .owner, and inlines.
> - Added dev_err_probe() and default bus frequency handling.
>
> - Patch 3 (dts):
> - Moved i2c aliases to board dts and reordered nodes alphabetically.
>
> -Link to v1: https://lore.kernel.org/r/20260302020822.13936-1-zychennvt@gmail.com
>
> Zi-Yu Chen (3):
> dt-bindings: i2c: nuvoton,ma35d1-i2c: Add MA35D1 I2C controller
> i2c: ma35d1: Add Nuvoton MA35D1 I2C driver support
> arm64: dts: nuvoton: Add I2C nodes for MA35D1 SoC
>
> .../bindings/i2c/nuvoton,ma35d1-i2c.yaml | 63 ++
> .../boot/dts/nuvoton/ma35d1-som-256m.dts | 18 +-
> arch/arm64/boot/dts/nuvoton/ma35d1.dtsi | 60 ++
> drivers/i2c/busses/Kconfig | 13 +
> drivers/i2c/busses/Makefile | 1 +
> drivers/i2c/busses/i2c-ma35d1.c | 792 ++++++++++++++++++
> 6 files changed, 946 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/i2c/nuvoton,ma35d1-i2c.yaml
> create mode 100644 drivers/i2c/busses/i2c-ma35d1.c
>
^ permalink raw reply
* Re: [PATCH V10 04/13] PCI: imx6: Assert PERST# before enabling regulators
From: Manivannan Sadhasivam @ 2026-04-07 6:46 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB12114917D17B5B8FB67E68DB9925AA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Tue, Apr 07, 2026 at 06:38:50AM +0000, Sherry Sun wrote:
>
> > On Thu, Apr 02, 2026 at 05:50:58PM +0800, Sherry Sun wrote:
> > > According to the PCIe initialization requirements, PERST# signal
> > > should be asserted before applying power to the PCIe device, and
> > > deasserted after power and reference clock are stable.
> > >
> >
> > Spec wording is not quite like this. Spec mandates asserting PERST# *before*
> > stopping refclk and powering down the device and deasserting it *after*
> > applying power and refclk stable.
> >
> > I believe you want to assert PERST# before enabling regulator to prevent the
> > endpoint from functioning? If so, is it due to refclk not available yet or some
> > other reason?
>
> You are right. My commit message wording was not that precise.
> The PCIe endpoint may start responding or driving signals as
> soon as its supply is enabled, even before the reference clock is stable.
> Asserting PERST# before enabling the regulator ensures that the endpoint
> remains in reset throughout the entire power-up sequence, until both
> power and refclk are known to be stable and link initialization can safely
> begin. This is mainly to avoid undefined behavior during early power-up.
>
> I will update the commit message to better reflect this.
>
> >
> > > Currently, the driver enables the vpcie3v3aux regulator in
> > > imx_pcie_probe() before PERST# is asserted in imx_pcie_host_init(),
> > > which violates the PCIe power sequencing requirements. However, there
> > > is no issue so far because PERST# is requested as GPIOD_OUT_HIGH in
> > > imx_pcie_probe(), which guarantees that PERST# is asserted before
> > > enabling the vpcie3v3aux regulator.
> > >
> > > This is prepare for the upcoming changes that will parse the reset
> > > property using the new Root Port binding, which will use GPIOD_ASIS
> > > when requesting the reset GPIO. With GPIOD_ASIS, the GPIO state is not
> > > guaranteed, so explicit sequencing is required.
> > >
> > > Fix the power sequencing by:
> > > 1. Moving vpcie3v3aux regulator enable from probe to
> > > imx_pcie_host_init(), where it can be properly sequenced with PERST#.
> > > 2. Moving imx_pcie_assert_perst() before regulator and clock enable to
> > > ensure correct ordering.
> > >
> > > The vpcie3v3aux regulator is kept enabled for the entire PCIe
> > > controller lifecycle and automatically disabled on device removal via devm
> > cleanup.
> > >
> >
> > vpcie3v3aux handling should be in a separate patch.
>
> Actually the handling of vpcie3v3aux itself remains unchanged, I just adjust the
> sequence of regulator/clock enable and perst#.
> Previously, the imx driver enabled the vpcie3v3aux regulator in imx_pcie_probe()
> before PERST# is asserted in imx_pcie_host_init(), which violates the PCIe power
> sequencing requirements.
> This patch moves vpcie3v3aux regulator enable from probe to imx_pcie_host_init(),
> where it can be properly sequenced with PERST#.
> Perhaps I should just remove this description to avoid confusion.
>
Yeah.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH net v3] net: airoha: Add dma_rmb() and READ_ONCE() in airoha_qdma_rx_process()
From: Lorenzo Bianconi @ 2026-04-07 6:48 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: Xuegang Lu, Simon Horman, linux-arm-kernel, linux-mediatek,
netdev
Add missing dma_rmb() in airoha_qdma_rx_process routine to make sure the
DMA read operations are completed when the NIC reports the processing on
the current descriptor is done. Moreover, add missing READ_ONCE() in
airoha_qdma_rx_process() for DMA descriptor control fields in order to
avoid any compiler reordering.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
Changes in v3:
- Move page pointer initialization before checking error condition on
payload length in order avoid using page pointer uninitialized in the
airoha_qdma_rx_process() error path.
- Link to v2: https://lore.kernel.org/r/20260403-airoha_qdma_rx_process-fix-reordering-v2-1-181e6e23d27b@kernel.org
Changes in v2:
- Use msg1 in airoha_qdma_get_gdm_port() signature to avoid missing
READ_ONCE().
- Link to v1: https://lore.kernel.org/r/20260402-airoha_qdma_rx_process-fix-reordering-v1-1-53278474f062@kernel.org
---
drivers/net/ethernet/airoha/airoha_eth.c | 16 ++++++++++------
1 file changed, 10 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 91cb63a32d99..9285a68f435f 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -584,7 +584,7 @@ static int airoha_qdma_fill_rx_queue(struct airoha_queue *q)
static int airoha_qdma_get_gdm_port(struct airoha_eth *eth,
struct airoha_qdma_desc *desc)
{
- u32 port, sport, msg1 = le32_to_cpu(desc->msg1);
+ u32 port, sport, msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
sport = FIELD_GET(QDMA_ETH_RXMSG_SPORT_MASK, msg1);
switch (sport) {
@@ -612,21 +612,24 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
while (done < budget) {
struct airoha_queue_entry *e = &q->entry[q->tail];
struct airoha_qdma_desc *desc = &q->desc[q->tail];
- u32 hash, reason, msg1 = le32_to_cpu(desc->msg1);
- struct page *page = virt_to_head_page(e->buf);
- u32 desc_ctrl = le32_to_cpu(desc->ctrl);
+ u32 hash, reason, msg1, desc_ctrl;
struct airoha_gdm_port *port;
int data_len, len, p;
+ struct page *page;
+ desc_ctrl = le32_to_cpu(READ_ONCE(desc->ctrl));
if (!(desc_ctrl & QDMA_DESC_DONE_MASK))
break;
+ dma_rmb();
+
q->tail = (q->tail + 1) % q->ndesc;
q->queued--;
dma_sync_single_for_cpu(eth->dev, e->dma_addr,
SKB_WITH_OVERHEAD(q->buf_size), dir);
+ page = virt_to_head_page(e->buf);
len = FIELD_GET(QDMA_DESC_LEN_MASK, desc_ctrl);
data_len = q->skb ? q->buf_size
: SKB_WITH_OVERHEAD(q->buf_size);
@@ -670,8 +673,8 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
* DMA descriptor. Report DSA tag to the DSA stack
* via skb dst info.
*/
- u32 sptag = FIELD_GET(QDMA_ETH_RXMSG_SPTAG,
- le32_to_cpu(desc->msg0));
+ u32 msg0 = le32_to_cpu(READ_ONCE(desc->msg0));
+ u32 sptag = FIELD_GET(QDMA_ETH_RXMSG_SPTAG, msg0);
if (sptag < ARRAY_SIZE(port->dsa_meta) &&
port->dsa_meta[sptag])
@@ -679,6 +682,7 @@ static int airoha_qdma_rx_process(struct airoha_queue *q, int budget)
&port->dsa_meta[sptag]->dst);
}
+ msg1 = le32_to_cpu(READ_ONCE(desc->msg1));
hash = FIELD_GET(AIROHA_RXD4_FOE_ENTRY, msg1);
if (hash != AIROHA_RXD4_FOE_ENTRY)
skb_set_hash(q->skb, jhash_1word(hash, 0),
---
base-commit: a9d4f4f6e65e0bf9bbddedecc84d67249991979c
change-id: 20260402-airoha_qdma_rx_process-fix-reordering-722308255b65
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH v5 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Linus Walleij @ 2026-04-07 6:48 UTC (permalink / raw)
To: Frank Li, Peter Rosin
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <CAD++jLmoHiJWV3J8f3TtpmQWLpUFD24icQEv2cbO3+x7775zxw@mail.gmail.com>
On Tue, Apr 7, 2026 at 8:42 AM Linus Walleij <linusw@kernel.org> wrote:
> > mux: add devm_mux_control_get_from_np() to get mux from child node
>
> Didn't get an ACK from the mux maintainer for this but this has been going
> on for long now so I applied it.
>
> Peter: protest if you don't like this and I will back it out.
I created an immutable branch for Peter to pull in if he want it:
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git/log/?h=ib-mux-pinctrl
(You can also pull in just the bottom commit which is just the mux change)
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH V10 03/13] PCI: dwc: Parse Root Port nodes in dw_pcie_host_init()
From: Manivannan Sadhasivam @ 2026-04-07 6:52 UTC (permalink / raw)
To: Sherry Sun
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, kernel@pengutronix.de,
festevam@gmail.com, lpieralisi@kernel.org, kwilczynski@kernel.org,
bhelgaas@google.com, Hongxing Zhu, l.stach@pengutronix.de,
imx@lists.linux.dev, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <VI0PR04MB121147E4D3F9FDC95391C1153925AA@VI0PR04MB12114.eurprd04.prod.outlook.com>
On Tue, Apr 07, 2026 at 03:21:30AM +0000, Sherry Sun wrote:
> > On Thu, Apr 02, 2026 at 05:50:57PM +0800, Sherry Sun wrote:
> > > Add support for parsing Root Port child nodes in dw_pcie_host_init()
> > > using pci_host_common_parse_ports(). This allows DWC-based drivers to
> > > specify Root Port properties (like reset GPIOs) in individual Root
> > > Port nodes rather than in the host bridge node.
> > >
> > > Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> > > ---
> > > drivers/pci/controller/dwc/pcie-designware-host.c | 8 ++++++++
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > index da152c31bb2e..f6fca984fb34 100644
> > > --- a/drivers/pci/controller/dwc/pcie-designware-host.c
> > > +++ b/drivers/pci/controller/dwc/pcie-designware-host.c
> > > @@ -20,6 +20,7 @@
> > > #include <linux/platform_device.h>
> > >
> > > #include "../../pci.h"
> > > +#include "../pci-host-common.h"
> > > #include "pcie-designware.h"
> > >
> > > static struct pci_ops dw_pcie_ops;
> > > @@ -581,6 +582,13 @@ int dw_pcie_host_init(struct dw_pcie_rp *pp)
> > >
> > > pp->bridge = bridge;
> > >
> > > + /* Parse Root Port nodes if present */
> > > + ret = pci_host_common_parse_ports(dev, bridge);
> > > + if (ret && ret != -ENOENT) {
> > > + dev_err(dev, "Failed to parse Root Port nodes: %d\n", ret);
> > > + return ret;
> >
> > Won't this change break drivers that parse Root Ports on their own? Either
> > you need to modify them also in this change or call this API from imx6 driver
> > and let other drivers switch to it in a phased manner.
> >
> > I perfer the latter.
>
> Hi Mani, sorry I didn't fully get your point here, there are no changes to this part
> V10, for drivers that parse Root Ports on their own, here pci_host_common_parse_ports()
> will return -ENOENT, so nothing break as we discussed this in V8
> https://lore.kernel.org/all/dcl3bdljrdzgeaybrg3dc5uaxkebkjns7pajix6mxxftao5g4m@vm3ywyyp4ujh/.
>
So if this API gets called first, it will acquire PERST# from the Root Port node
and if the controller drivers try to do the same in their own parsing code,
PERST# request will return -EBUSY and the probe will fail.
On the other hand, if the controller drivers parse PERST# first, this API will
return -EBUSY and will result in probe failure.
Only way to fix this issue would be to call this API from imx6 driver for now
and start migrating other drivers later.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH 0/3] ARM: pxa: attach software nodes to the GPIO controllers
From: Linus Walleij @ 2026-04-07 7:14 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, brgl, linux-arm-kernel,
linux-gpio, linux-kernel
In-Reply-To: <20260331-pxa-gpio-swnodes-v1-0-f66d86d10d8d@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 11:11 AM Bartosz Golaszewski
<bartosz.golaszewski@oss.qualcomm.com> wrote:
> I was looking for a use-case where automatic secondary fwnode assignment
> would make sense for a DT platform. With the paz00 issue having been
> addressed by Dmitry, PXA looked like the last one that could match the
> idea but it turned out that we can just easily attach the software nodes
> to their controllers enabling fwnode lookup of GPIOs.
>
> After that the only GPIO consumers that still use label lookup with
> dangling software nodes are ACPI platform devices and a single PCI
> use-case. In that case, I won't be doing anything OF-related and will
> limit the x86 tablets series to an ACPI-centric solution.
>
> With that being said: here's a series attaching software nodes to GPIO
> controllers on the PXA platform. Since everything happens in a
> bord-file, it's quite straightforward.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
This makes things better, thanks!
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/2] KVM: arm64: Factor out TG0/1 decoding of VTCR and TCR
From: Marc Zyngier @ 2026-04-07 7:17 UTC (permalink / raw)
To: Wei-Lin Chang
Cc: linux-arm-kernel, kvmarm, linux-kernel, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon
In-Reply-To: <20260406164618.3312473-2-weilin.chang@arm.com>
On Mon, 06 Apr 2026 17:46:17 +0100,
Wei-Lin Chang <weilin.chang@arm.com> wrote:
>
> The current code decodes TCR.TG0/TG1 and VTCR.TG0 inline at several
> places. Extract this logic into helpers so the granule size is derived
> in one place. This enables us to alter the effective granule size in
> the same place, which we will need in a later patch.
>
> Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
> ---
> arch/arm64/kvm/at.c | 73 +++++++++++++++++++++++++----------------
> arch/arm64/kvm/nested.c | 70 ++++++++++++++++++++++++---------------
> 2 files changed, 89 insertions(+), 54 deletions(-)
>
> diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
> index c5c5644b1878..ff8ba30e917b 100644
> --- a/arch/arm64/kvm/at.c
> +++ b/arch/arm64/kvm/at.c
> @@ -135,14 +135,54 @@ static void compute_s1poe(struct kvm_vcpu *vcpu, struct s1_walk_info *wi)
> wi->e0poe = (wi->regime != TR_EL2) && (val & TCR2_EL1_E0POE);
> }
>
> +static unsigned int tg0_to_shift(u64 tg0)
> +{
It'd be better to abstract these helpers a bit more by making them
take the full TCR_ELx value, and to give them a slightly better name.
I'd suggest something like:
static unsigned int tcr_to_tg0_pgshift(u64 tcr)
{
u64 tg0 = tcr & TCR_TG0_MASK, tcr;
which makes it clear that the result is a page shift, as required by
wi->pgshift.
> + switch (tg0) {
> + case TCR_EL1_TG0_4K:
> + return 12;
> + case TCR_EL1_TG0_16K:
> + return 14;
> + case TCR_EL1_TG0_64K:
Please don't mix the _EL1 definition and those without _EL1 in the
same file. For a start, that's not always EL1. Also, this makes very
hard to reason about what is shifted and what is not.
> + default: /* IMPDEF: treat any other value as 64k */
> + return 16;
> + }
> +}
> +
> +static unsigned int tg1_to_shift(u64 tg1)
> +{
> + switch (tg1) {
> + case TCR_EL1_TG1_4K:
> + return 12;
> + case TCR_EL1_TG1_16K:
> + return 14;
> + case TCR_EL1_TG1_64K:
> + default: /* IMPDEF: treat any other value as 64k */
> + return 16;
> + }
> +}
> +
> +static u64 tcr_tg_shift(struct kvm *kvm, u64 tcr, bool upper_range)
> +{
> + unsigned int shift;
> +
> + /* Someone was silly enough to encode TG0/TG1 differently */
> + if (upper_range)
> + shift = tg1_to_shift(FIELD_GET(TCR_EL1_TG1_MASK, tcr));
> + else
> + shift = tg0_to_shift(FIELD_GET(TCR_EL1_TG0_MASK, tcr));
> +
> + return shift;
> +}
> +
> static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
> struct s1_walk_result *wr, u64 va)
> {
> - u64 hcr, sctlr, tcr, tg, ps, ia_bits, ttbr;
> + u64 hcr, sctlr, tcr, ps, ia_bits, ttbr;
> unsigned int stride, x;
> - bool va55, tbi, lva;
> + bool va55, tbi, lva, upper_range;
>
> va55 = va & BIT(55);
> + upper_range = va55 && wi->regime != TR_EL2;
>
> if (vcpu_has_nv(vcpu)) {
> hcr = __vcpu_sys_reg(vcpu, HCR_EL2);
> @@ -173,35 +213,12 @@ static int setup_s1_walk(struct kvm_vcpu *vcpu, struct s1_walk_info *wi,
> BUG();
> }
>
> - /* Someone was silly enough to encode TG0/TG1 differently */
> - if (va55 && wi->regime != TR_EL2) {
> + if (upper_range)
> wi->txsz = FIELD_GET(TCR_T1SZ_MASK, tcr);
> - tg = FIELD_GET(TCR_TG1_MASK, tcr);
> -
> - switch (tg << TCR_TG1_SHIFT) {
> - case TCR_TG1_4K:
> - wi->pgshift = 12; break;
> - case TCR_TG1_16K:
> - wi->pgshift = 14; break;
> - case TCR_TG1_64K:
> - default: /* IMPDEF: treat any other value as 64k */
> - wi->pgshift = 16; break;
> - }
> - } else {
> + else
> wi->txsz = FIELD_GET(TCR_T0SZ_MASK, tcr);
> - tg = FIELD_GET(TCR_TG0_MASK, tcr);
> -
> - switch (tg << TCR_TG0_SHIFT) {
> - case TCR_TG0_4K:
> - wi->pgshift = 12; break;
> - case TCR_TG0_16K:
> - wi->pgshift = 14; break;
> - case TCR_TG0_64K:
> - default: /* IMPDEF: treat any other value as 64k */
> - wi->pgshift = 16; break;
> - }
> - }
>
> + wi->pgshift = tcr_tg_shift(vcpu->kvm, tcr, upper_range);
> wi->pa52bit = has_52bit_pa(vcpu, wi, tcr);
>
> ia_bits = get_ia_size(wi);
> diff --git a/arch/arm64/kvm/nested.c b/arch/arm64/kvm/nested.c
> index 883b6c1008fb..2bfab3007cb3 100644
> --- a/arch/arm64/kvm/nested.c
> +++ b/arch/arm64/kvm/nested.c
> @@ -378,20 +378,36 @@ static int walk_nested_s2_pgd(struct kvm_vcpu *vcpu, phys_addr_t ipa,
> return 0;
> }
>
> -static void vtcr_to_walk_info(u64 vtcr, struct s2_walk_info *wi)
> +static unsigned int tg0_to_shift(u64 tg0)
Same comments as above.
> +{
> + switch (tg0) {
> + case VTCR_EL2_TG0_4K:
> + return 12;
> + case VTCR_EL2_TG0_16K:
> + return 14;
> + case VTCR_EL2_TG0_64K:
> + default: /* IMPDEF: treat any other value as 64k */
> + return 16;
> + }
> +}
> +
> +static u64 vtcr_tg0_shift(struct kvm *kvm, u64 vtcr)
> +{
> + u64 tg0 = FIELD_GET(VTCR_EL2_TG0_MASK, vtcr);
> + unsigned int shift = tg0_to_shift(tg0);
> +
> + return shift;
shift is an unsigned int. Why is the return value a u64? Try and make
sure that types are consistent, even if they cast nicely in C.
> +}
> +
> +static size_t vtcr_tg0_size(struct kvm *kvm, u64 vtcr)
> +{
> + return BIT(vtcr_tg0_shift(kvm, vtcr));
> +}
> +
> +static void vtcr_to_walk_info(struct kvm *kvm, u64 vtcr, struct s2_walk_info *wi)
This prototype reads bizarrely. vtcr is per CPU, the walk info is
evidently per CPU, and yet you pass a kvm struct.
Instead, rename this to:
static void setup_s2_walk(struct kvm_vcpu *vcpu,
struct s2_walk_info *wi)
{
u64 vtcr = vcpu_read_sys_reg(vcpu, VTCR_EL2);
and call that directly. You can then extract vcpu->kvm as needed. It
also aligns the naming on the s1 part, which isn't a bad thing to do.
> {
> wi->t0sz = vtcr & TCR_EL2_T0SZ_MASK;
> -
> - switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
> - case VTCR_EL2_TG0_4K:
> - wi->pgshift = 12; break;
> - case VTCR_EL2_TG0_16K:
> - wi->pgshift = 14; break;
> - case VTCR_EL2_TG0_64K:
> - default: /* IMPDEF: treat any other value as 64k */
> - wi->pgshift = 16; break;
> - }
> -
> + wi->pgshift = vtcr_tg0_shift(kvm, vtcr);
> wi->sl = FIELD_GET(VTCR_EL2_SL0_MASK, vtcr);
> /* Global limit for now, should eventually be per-VM */
> wi->max_oa_bits = min(get_kvm_ipa_limit(),
> @@ -414,7 +430,7 @@ int kvm_walk_nested_s2(struct kvm_vcpu *vcpu, phys_addr_t gipa,
>
> wi.baddr = vcpu_read_sys_reg(vcpu, VTTBR_EL2);
>
> - vtcr_to_walk_info(vtcr, &wi);
> + vtcr_to_walk_info(vcpu->kvm, vtcr, &wi);
>
> wi.be = vcpu_read_sys_reg(vcpu, SCTLR_EL2) & SCTLR_ELx_EE;
>
> @@ -515,17 +531,19 @@ static u8 get_guest_mapping_ttl(struct kvm_s2_mmu *mmu, u64 addr)
> u64 tmp, sz = 0, vtcr = mmu->tlb_vtcr;
> kvm_pte_t pte;
> u8 ttl, level;
> + struct kvm *kvm = kvm_s2_mmu_to_kvm(mmu);
> + size_t tg0_size = vtcr_tg0_size(kvm, vtcr);
>
> - lockdep_assert_held_write(&kvm_s2_mmu_to_kvm(mmu)->mmu_lock);
> + lockdep_assert_held_write(&kvm->mmu_lock);
>
> - switch (FIELD_GET(VTCR_EL2_TG0_MASK, vtcr)) {
> - case VTCR_EL2_TG0_4K:
> + switch (tg0_size) {
> + case SZ_4K:
> ttl = (TLBI_TTL_TG_4K << 2);
> break;
> - case VTCR_EL2_TG0_16K:
> + case SZ_16K:
> ttl = (TLBI_TTL_TG_16K << 2);
> break;
> - case VTCR_EL2_TG0_64K:
> + case SZ_64K:
All these unit changes make the patch harder to read than it should
be. Consider having a separate patch to do that.
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH v1] PCI: imx6: Add force_suspend flag to override L1SS suspend skip
From: mani @ 2026-04-07 7:24 UTC (permalink / raw)
To: Hongxing Zhu
Cc: Bjorn Helgaas, Frank Li, jingoohan1@gmail.com,
l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, robh@kernel.org, bhelgaas@google.com,
s.hauer@pengutronix.de, kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <AS8PR04MB8833C20B6FF92F96EE7641E38C5AA@AS8PR04MB8833.eurprd04.prod.outlook.com>
On Tue, Apr 07, 2026 at 03:31:57AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: mani@kernel.org <mani@kernel.org>
> > Sent: 2026年4月4日 1:03
> > To: Hongxing Zhu <hongxing.zhu@nxp.com>
> > Cc: Bjorn Helgaas <helgaas@kernel.org>; Frank Li <frank.li@nxp.com>;
> > jingoohan1@gmail.com; l.stach@pengutronix.de; lpieralisi@kernel.org;
> > kwilczynski@kernel.org; robh@kernel.org; bhelgaas@google.com;
> > s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com;
> > linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > imx@lists.linux.dev; linux-kernel@vger.kernel.org; stable@vger.kernel.org
> > Subject: Re: [PATCH v1] PCI: imx6: Add force_suspend flag to override L1SS
> > suspend skip
> >
> > On Tue, Mar 24, 2026 at 02:01:58AM +0000, Hongxing Zhu wrote:
> > > > -----Original Message-----
> > > > From: Bjorn Helgaas <helgaas@kernel.org>
> > > > Sent: 2026年3月24日 6:09
> > > > To: Hongxing Zhu <hongxing.zhu@nxp.com>
> > > > Cc: Frank Li <frank.li@nxp.com>; jingoohan1@gmail.com;
> > > > l.stach@pengutronix.de; lpieralisi@kernel.org;
> > > > kwilczynski@kernel.org; mani@kernel.org; robh@kernel.org;
> > > > bhelgaas@google.com; s.hauer@pengutronix.de; kernel@pengutronix.de;
> > > > festevam@gmail.com; linux-pci@vger.kernel.org;
> > > > linux-arm-kernel@lists.infradead.org;
> > > > imx@lists.linux.dev; linux-kernel@vger.kernel.org;
> > > > stable@vger.kernel.org
> > > > Subject: Re: [PATCH v1] PCI: imx6: Add force_suspend flag to
> > > > override L1SS suspend skip
> > > >
> > > > On Wed, Mar 18, 2026 at 02:55:45AM +0000, Hongxing Zhu wrote:
> > > > > > -----Original Message-----
> > > > > > From: Bjorn Helgaas <helgaas@kernel.org>
> > > > > ... [messed up quoting]
> > > >
> > > > > > On Tue, Mar 17, 2026 at 02:12:56PM +0800, Richard Zhu wrote:
> > > > > > > Add a force_suspend flag to allow platform drivers to force
> > > > > > > the PCIe link into L2 state during suspend, even when L1SS
> > > > > > > (ASPM L1
> > > > > > > Sub-States) is enabled.
> > > > > > >
> > > > > > > By default, the DesignWare PCIe host controller skips L2
> > > > > > > suspend when L1SS is supported to meet low resume latency
> > > > > > > requirements for devices like NVMe. However, some platforms
> > > > > > > like i.MX PCIe need to enter L2 state for proper power
> > > > > > > management regardless of L1SS
> > > > support.
> > > > > > >
> > > > > > > Enable force_suspend for i.MX PCIe to ensure the link enters
> > > > > > > L2 during system suspend.
> > > > > >
> > > > > > I'm a little bit skeptical about this.
> > > > > >
> > > > > > What exactly does a "low resume latency requirement" mean? Is
> > > > > > this an actual functional requirement that's special to NVMe, or
> > > > > > is it just the desire for low resume latency that everybody has
> > > > > > for all devices?
> > > > >
> > > > > From my understanding, L1SS mode is characterized by lower latency
> > > > > when compared to L2 or L3 modes.
> > > > >
> > > > > It can be used on all devices, avoiding frequent power on/off cycles.
> > > > > NVMe can also extend the service life of the equipment.
> > > >
> > > > All the above applies to all platforms, so it's not an argument for
> > > > i.MX-specific code here.
> > > >
> > > Hi Bjorn:
> > > Thanks for your kindly review.
> > > Yes, it is.
> > > > > > Is there something special about i.MX here? Why do we want i.MX
> > > > > > to be different from other host controllers?
> > > > >
> > > > > i.MX PCIe loses power supply during Deep Sleep Mode (DSM),
> > > > > requiring full reinitialization after system wake-up.
> > > >
> > > > I don't know what DSM means in PCIe or how it would help justify
> > > > this change.
> > > >
> > > i.MX PCIe power is gated off during suspend, requiring full
> > > reinitialization on resume
> > >
> >
> > Is this an unconditional behavior? What if the PCIe device is configured as a
> > wakeup source like WOL, WOW? And if you connect NVMe, this behavior will
> > result in resume failure as NVMe driver expects the power to be retained if
> > ASPM is supported.
>
> Yes, this is unconditional behavior. The i.MX PCIe controller exclusively
> supports sideband wakeup mechanisms, which operate independently of the
> PCIe link state and device power configuration.
>
I believe you are referring to WAKE# as the sideband wakeup mechanism. If so,
both host and device has to support WAKE#.
> For devices configured as wakeup sources (WOL, WOW, etc.): The sideband
> wakeup path bypasses the standard PCIe power management, so these
> configurations do not impact the i.MX PCIe RC controller's suspend/resume
> behavior.
>
Once user enables wakeup for a device, PCI core will configure PME_EN only if
the device supports toggling WAKE# from D3Cold. So the wakeup functionality
depends on device too, not just the RC.
> For NVMe devices with ASPM: While NVMe drivers typically expect power
> retention when ASPM is enabled, the i.MX implementation's sideband wakeup
> mechanism operates through a separate signaling path. The wakeup functionality
> does not depend on maintaining PCIe link power, thus avoiding conflicts with
> NVMe power state expectations.
>
There is no relation between WAKE# and NVMe. NVMe is a passive device, so it
doesn't support WAKE#. With this patch alone, the NVMe driver won't resume (is
ASPM is enabled). You need to tell the NVMe driver to perpare for power loss
too. Maybe this patch can help you:
https://lore.kernel.org/all/20251231162126.7728-1-manivannan.sadhasivam@oss.qualcomm.com/
But that patch will only help if your platform supports S2RAM through PSCI.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH net-next v9 0/4] net: stmmac: Add PCI driver support for BCM8958x
From: Russell King (Oracle) @ 2026-04-07 7:24 UTC (permalink / raw)
To: Jitendra Vegiraju
Cc: netdev, alexandre.torgue, davem, edumazet, kuba, pabeni,
mcoquelin.stm32, bcm-kernel-feedback-list, richardcochran, ast,
daniel, hawk, john.fastabend, rohan.g.thomas, linux-kernel,
linux-stm32, linux-arm-kernel, bpf, andrew+netdev, horms, sdf, me,
siyanteng, prabhakar.mahadev-lad.rj, weishangjuan, wens,
vladimir.oltean, lizhi2, boon.khai.ng, maxime.chevallier,
chenchuangyu, yangtiezhu, ovidiu.panait.rb, chenhuacai,
florian.fainelli, quic_abchauha
In-Reply-To: <20260402213629.1996133-1-jitendra.vegiraju@broadcom.com>
On Thu, Apr 02, 2026 at 02:36:25PM -0700, Jitendra Vegiraju wrote:
> From: Jitendra Vegiraju <jitendra.vegiraju@broadcom.com>
>
> This patchset adds basic PCI ethernet device driver support for Broadcom
> BCM8958x Automotive Ethernet switch SoC devices.
>
> This SoC device has PCIe ethernet MAC attached to an integrated ethernet
> switch using XGMII interface. The PCIe ethernet controller is presented to
> the Linux host as PCI network device.
> Management of integrated ethernet switch on this SoC is not handled via
> the PCIe interface.
>
> The following block diagram gives an overview of the application.
> +=================================+
> | Host CPU/Linux |
> +=================================+
> || PCIe
> ||
> +==========================================+
> | +--------------+ |
> | | PCIE Endpoint| |
> | | Ethernet | |
> | | Controller | |
> | | DMA | |
> | +--------------+ |
> | | MAC | BCM8958X |
> | +--------------+ SoC |
> | || XGMII |
> | || |
> | +--------------+ |
> | | Ethernet | |
> | | switch | |
> | +--------------+ |
> | || || || || |
> +==========================================+
> || || || || More external interfaces
>
> The MAC block on BCM8958x is based on Synopsis XGMAC 4.00a core. This
> MAC IP introduces new DMA architecture called Hyper-DMA for virtualization
> scalability.
>
> Driver functionality specific to new MAC (DW25GMAC) is implemented in
> new file dw25gmac.c.
Sorry for suggesting this rather late, but I recently came across
another stmmac driver in the kernel - drivers/net/ethernet/synopsys.
This is for XLGMAC, but I wonder whether it may be a better bet for
this core. Have you looked at it?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* [PATCH V2] spi: mtk-snfi: unregister ECC engine on probe failure and remove() callback
From: Pei Xiao @ 2026-04-07 7:26 UTC (permalink / raw)
To: broonie, matthias.bgg, angelogioacchino.delregno, linux-spi,
linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Pei Xiao
mtk_snand_probe() registers the on-host NAND ECC engine, but teardown was
missing from both probe unwind and remove-time cleanup. Add a devm cleanup
action after successful registration so
nand_ecc_unregister_on_host_hw_engine() runs automatically on probe
failures and during device removal.
Fixes: 764f1b748164 ("spi: add driver for MTK SPI NAND Flash Interface")
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
changlog in v2: dev_err changes to dev_err_probe
---
drivers/spi/spi-mtk-snfi.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/spi/spi-mtk-snfi.c b/drivers/spi/spi-mtk-snfi.c
index 437edbd658aa..73fa84475f0e 100644
--- a/drivers/spi/spi-mtk-snfi.c
+++ b/drivers/spi/spi-mtk-snfi.c
@@ -1303,6 +1303,13 @@ static const struct spi_controller_mem_caps mtk_snand_mem_caps = {
.ecc = true,
};
+static void mtk_unregister_ecc_engine(void *data)
+{
+ struct nand_ecc_engine *eng = data;
+
+ nand_ecc_unregister_on_host_hw_engine(eng);
+}
+
static irqreturn_t mtk_snand_irq(int irq, void *id)
{
struct mtk_snand *snf = id;
@@ -1443,6 +1450,13 @@ static int mtk_snand_probe(struct platform_device *pdev)
goto release_ecc;
}
+ ret = devm_add_action_or_reset(&pdev->dev, mtk_unregister_ecc_engine,
+ &ms->ecc_eng);
+ if (ret) {
+ dev_err_probe(&pdev->dev, ret, "failed to add ECC unregister action\n");
+ goto release_ecc;
+ }
+
ctlr->num_chipselect = 1;
ctlr->mem_ops = &mtk_snand_mem_ops;
ctlr->mem_caps = &mtk_snand_mem_caps;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 3/3] gpio: realtek: Add driver for Realtek DHC RTD1625 SoC
From: Linus Walleij @ 2026-04-07 7:27 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: brgl, robh, krzk+dt, conor+dt, afaerber, tychang, linux-gpio,
devicetree, linux-kernel, linux-arm-kernel, linux-realtek-soc,
cy.huang, stanley_chang, james.tai
In-Reply-To: <20260331113835.3510341-4-eleanor.lin@realtek.com>
On Tue, Mar 31, 2026 at 1:38 PM Yu-Chun Lin <eleanor.lin@realtek.com> wrote:
> From: Tzuyi Chang <tychang@realtek.com>
>
> Add support for the GPIO controller found on Realtek DHC RTD1625 SoCs.
>
> Unlike the existing Realtek GPIO driver (drivers/gpio/gpio-rtd.c),
> which manages pins via shared bank registers, the RTD1625 introduces
> a per-pin register architecture. Each GPIO line now has its own
> dedicated 32-bit control register to manage configuration independently,
> including direction, output value, input value, interrupt enable, and
> debounce. Therefore, this distinct hardware design requires a separate
> driver.
>
> Signed-off-by: Tzuyi Chang <tychang@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
With Bartosz comment addressed:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v5 8/9] driver core: Replace dev->of_node_reused with dev_of_node_reused()
From: Manivannan Sadhasivam @ 2026-04-07 7:27 UTC (permalink / raw)
To: Douglas Anderson
Cc: Greg Kroah-Hartman, Rafael J . Wysocki, Danilo Krummrich,
Alan Stern, Alexey Kardashevskiy, Johan Hovold, Eric Dumazet,
Leon Romanovsky, Christoph Hellwig, Robin Murphy, maz,
Alexander Lobakin, Saravana Kannan, Mark Brown, alexander.stein,
andrew, andrew, andriy.shevchenko, astewart, bhelgaas, brgl,
davem, devicetree, driver-core, hkallweit1, jirislaby, joel, kees,
kuba, lgirdwood, linux-arm-kernel, linux-aspeed, linux-kernel,
linux-pci, linux-serial, linux-usb, linux, netdev, pabeni, robh
In-Reply-To: <20260406162231.v5.8.I806b8636cd3724f6cd1f5e199318ab8694472d90@changeid>
On Mon, Apr 06, 2026 at 04:23:01PM -0700, Douglas Anderson wrote:
> In C, bitfields are not necessarily safe to modify from multiple
> threads without locking. Switch "of_node_reused" over to the "flags"
> field so modifications are safe.
>
> Cc: Johan Hovold <johan@kernel.org>
> Acked-by: Mark Brown <broonie@kernel.org>
> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org>
> Reviewed-by: Danilo Krummrich <dakr@kernel.org>
> Signed-off-by: Douglas Anderson <dianders@chromium.org>
Acked-by: Manivannan Sadhasivam <mani@kernel.org> # PCI_PWRCTRL
- Mani
> ---
> Not fixing any known bugs; problem is theoretical and found by code
> inspection. Change is done somewhat manually and only lightly tested
> (mostly compile-time tested).
>
> (no changes since v4)
>
> Changes in v4:
> - Use accessor functions for flags
>
> Changes in v3:
> - New
>
> drivers/base/core.c | 2 +-
> drivers/base/pinctrl.c | 2 +-
> drivers/base/platform.c | 2 +-
> drivers/net/pcs/pcs-xpcs-plat.c | 2 +-
> drivers/of/device.c | 6 +++---
> drivers/pci/of.c | 2 +-
> drivers/pci/pwrctrl/core.c | 2 +-
> drivers/regulator/bq257xx-regulator.c | 2 +-
> drivers/regulator/rk808-regulator.c | 2 +-
> drivers/tty/serial/serial_base_bus.c | 2 +-
> drivers/usb/gadget/udc/aspeed-vhub/dev.c | 2 +-
> include/linux/device.h | 7 ++++---
> 12 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index 8a83d7c93361..30825bf83234 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -5283,7 +5283,7 @@ void device_set_of_node_from_dev(struct device *dev, const struct device *dev2)
> {
> of_node_put(dev->of_node);
> dev->of_node = of_node_get(dev2->of_node);
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
> }
> EXPORT_SYMBOL_GPL(device_set_of_node_from_dev);
>
> diff --git a/drivers/base/pinctrl.c b/drivers/base/pinctrl.c
> index 6e250272c843..0bbc83231234 100644
> --- a/drivers/base/pinctrl.c
> +++ b/drivers/base/pinctrl.c
> @@ -24,7 +24,7 @@ int pinctrl_bind_pins(struct device *dev)
> {
> int ret;
>
> - if (dev->of_node_reused)
> + if (dev_of_node_reused(dev))
> return 0;
>
> dev->pins = devm_kzalloc(dev, sizeof(*(dev->pins)), GFP_KERNEL);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index d44591d52e36..199e6fb25770 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -856,7 +856,7 @@ struct platform_device *platform_device_register_full(
> pdev->dev.parent = pdevinfo->parent;
> pdev->dev.fwnode = pdevinfo->fwnode;
> pdev->dev.of_node = of_node_get(to_of_node(pdev->dev.fwnode));
> - pdev->dev.of_node_reused = pdevinfo->of_node_reused;
> + dev_assign_of_node_reused(&pdev->dev, pdevinfo->of_node_reused);
>
> if (pdevinfo->dma_mask) {
> pdev->platform_dma_mask = pdevinfo->dma_mask;
> diff --git a/drivers/net/pcs/pcs-xpcs-plat.c b/drivers/net/pcs/pcs-xpcs-plat.c
> index b8c48f9effbf..f4b1b8246ce9 100644
> --- a/drivers/net/pcs/pcs-xpcs-plat.c
> +++ b/drivers/net/pcs/pcs-xpcs-plat.c
> @@ -349,7 +349,7 @@ static int xpcs_plat_init_dev(struct dw_xpcs_plat *pxpcs)
> * up later. Make sure DD-core is aware of the OF-node being re-used.
> */
> device_set_node(&mdiodev->dev, fwnode_handle_get(dev_fwnode(dev)));
> - mdiodev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&mdiodev->dev);
>
> /* Pass the data further so the DW XPCS driver core could use it */
> mdiodev->dev.platform_data = (void *)device_get_match_data(dev);
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index f7e75e527667..be4e1584e0af 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -26,7 +26,7 @@
> const struct of_device_id *of_match_device(const struct of_device_id *matches,
> const struct device *dev)
> {
> - if (!matches || !dev->of_node || dev->of_node_reused)
> + if (!matches || !dev->of_node || dev_of_node_reused(dev))
> return NULL;
> return of_match_node(matches, dev->of_node);
> }
> @@ -192,7 +192,7 @@ ssize_t of_device_modalias(struct device *dev, char *str, ssize_t len)
> {
> ssize_t sl;
>
> - if (!dev || !dev->of_node || dev->of_node_reused)
> + if (!dev || !dev->of_node || dev_of_node_reused(dev))
> return -ENODEV;
>
> sl = of_modalias(dev->of_node, str, len - 2);
> @@ -254,7 +254,7 @@ int of_device_uevent_modalias(const struct device *dev, struct kobj_uevent_env *
> {
> int sl;
>
> - if ((!dev) || (!dev->of_node) || dev->of_node_reused)
> + if ((!dev) || (!dev->of_node) || dev_of_node_reused(dev))
> return -ENODEV;
>
> /* Devicetree modalias is tricky, we add it in 2 steps */
> diff --git a/drivers/pci/of.c b/drivers/pci/of.c
> index 9f8eb5df279e..1f9b669abdb0 100644
> --- a/drivers/pci/of.c
> +++ b/drivers/pci/of.c
> @@ -38,7 +38,7 @@ int pci_set_of_node(struct pci_dev *dev)
> struct device *pdev __free(put_device) =
> bus_find_device_by_of_node(&platform_bus_type, node);
> if (pdev)
> - dev->bus->dev.of_node_reused = true;
> + dev_set_of_node_reused(&dev->bus->dev);
>
> device_set_node(&dev->dev, of_fwnode_handle(no_free_ptr(node)));
> return 0;
> diff --git a/drivers/pci/pwrctrl/core.c b/drivers/pci/pwrctrl/core.c
> index 7754baed67f2..72963a92362a 100644
> --- a/drivers/pci/pwrctrl/core.c
> +++ b/drivers/pci/pwrctrl/core.c
> @@ -39,7 +39,7 @@ static int pci_pwrctrl_notify(struct notifier_block *nb, unsigned long action,
> * If we got here then the PCI device is the second after the
> * power control platform device. Mark its OF node as reused.
> */
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
> break;
> }
>
> diff --git a/drivers/regulator/bq257xx-regulator.c b/drivers/regulator/bq257xx-regulator.c
> index dab8f1ab4450..40e0f1a7ae81 100644
> --- a/drivers/regulator/bq257xx-regulator.c
> +++ b/drivers/regulator/bq257xx-regulator.c
> @@ -143,7 +143,7 @@ static int bq257xx_regulator_probe(struct platform_device *pdev)
> struct regulator_config cfg = {};
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> pdata = devm_kzalloc(&pdev->dev, sizeof(struct bq257xx_reg_data), GFP_KERNEL);
> if (!pdata)
> diff --git a/drivers/regulator/rk808-regulator.c b/drivers/regulator/rk808-regulator.c
> index e66408f23bb6..8297d31cde9f 100644
> --- a/drivers/regulator/rk808-regulator.c
> +++ b/drivers/regulator/rk808-regulator.c
> @@ -2115,7 +2115,7 @@ static int rk808_regulator_probe(struct platform_device *pdev)
> int ret, i, nregulators;
>
> pdev->dev.of_node = pdev->dev.parent->of_node;
> - pdev->dev.of_node_reused = true;
> + dev_set_of_node_reused(&pdev->dev);
>
> regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!regmap)
> diff --git a/drivers/tty/serial/serial_base_bus.c b/drivers/tty/serial/serial_base_bus.c
> index a12935f6b992..5f23284a8778 100644
> --- a/drivers/tty/serial/serial_base_bus.c
> +++ b/drivers/tty/serial/serial_base_bus.c
> @@ -74,7 +74,7 @@ static int serial_base_device_init(struct uart_port *port,
> dev->parent = parent_dev;
> dev->bus = &serial_base_bus_type;
> dev->release = release;
> - dev->of_node_reused = true;
> + dev_set_of_node_reused(dev);
>
> device_set_node(dev, fwnode_handle_get(dev_fwnode(parent_dev)));
>
> diff --git a/drivers/usb/gadget/udc/aspeed-vhub/dev.c b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> index 2ecd049dacc2..8b9449d16324 100644
> --- a/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> +++ b/drivers/usb/gadget/udc/aspeed-vhub/dev.c
> @@ -593,7 +593,7 @@ int ast_vhub_init_dev(struct ast_vhub *vhub, unsigned int idx)
> d->gadget.max_speed = USB_SPEED_HIGH;
> d->gadget.speed = USB_SPEED_UNKNOWN;
> d->gadget.dev.of_node = vhub->pdev->dev.of_node;
> - d->gadget.dev.of_node_reused = true;
> + dev_set_of_node_reused(&d->gadget.dev);
>
> rc = usb_add_gadget_udc(d->port_dev, &d->gadget);
> if (rc != 0)
> diff --git a/include/linux/device.h b/include/linux/device.h
> index 5b0fb6ad4c72..a79865a212e9 100644
> --- a/include/linux/device.h
> +++ b/include/linux/device.h
> @@ -483,6 +483,8 @@ struct device_physical_location {
> * driver/bus sync_state() callback.
> * @DEV_FLAG_DMA_COHERENT: This particular device is dma coherent, even if the
> * architecture supports non-coherent devices.
> + * @DEV_FLAG_OF_NODE_REUSED: Set if the device-tree node is shared with an
> + * ancestor device.
> */
> enum struct_device_flags {
> DEV_FLAG_READY_TO_PROBE = 0,
> @@ -492,6 +494,7 @@ enum struct_device_flags {
> DEV_FLAG_DMA_OPS_BYPASS = 4,
> DEV_FLAG_STATE_SYNCED = 5,
> DEV_FLAG_DMA_COHERENT = 6,
> + DEV_FLAG_OF_NODE_REUSED = 7,
>
> DEV_FLAG_COUNT
> };
> @@ -573,8 +576,6 @@ enum struct_device_flags {
> *
> * @offline_disabled: If set, the device is permanently online.
> * @offline: Set after successful invocation of bus type's .offline().
> - * @of_node_reused: Set if the device-tree node is shared with an ancestor
> - * device.
> * @flags: DEV_FLAG_XXX flags. Use atomic bitfield operations to modify.
> *
> * At the lowest level, every device in a Linux system is represented by an
> @@ -681,7 +682,6 @@ struct device {
>
> bool offline_disabled:1;
> bool offline:1;
> - bool of_node_reused:1;
>
> DECLARE_BITMAP(flags, DEV_FLAG_COUNT);
> };
> @@ -715,6 +715,7 @@ __create_dev_flag_accessors(dma_skip_sync, DEV_FLAG_DMA_SKIP_SYNC);
> __create_dev_flag_accessors(dma_ops_bypass, DEV_FLAG_DMA_OPS_BYPASS);
> __create_dev_flag_accessors(state_synced, DEV_FLAG_STATE_SYNCED);
> __create_dev_flag_accessors(dma_coherent, DEV_FLAG_DMA_COHERENT);
> +__create_dev_flag_accessors(of_node_reused, DEV_FLAG_OF_NODE_REUSED);
>
> #undef __create_dev_flag_accessors
>
> --
> 2.53.0.1213.gd9a14994de-goog
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH] spi: uniphier: Simplify clock handling with devm_clk_get_enabled()
From: Pei Xiao @ 2026-04-07 7:30 UTC (permalink / raw)
To: hayashi.kunihiko, mhiramat, linux-spi, linux-arm-kernel,
linux-kernel
Cc: broonie, Pei Xiao
Replace devm_clk_get() followed by clk_prepare_enable() with
devm_clk_get_enabled() for the clock. This removes the need for
explicit clock enable and disable calls, as the managed API automatically
handles clock disabling on device removal or probe failure.
Remove the now-unnecessary clk_disable_unprepare() calls from the probe
error path and the remove callback. Adjust error labels accordingly.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
drivers/spi/spi-uniphier.c | 18 ++++--------------
1 file changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/spi/spi-uniphier.c b/drivers/spi/spi-uniphier.c
index 9e1d364a6198..1b815ee2ed1b 100644
--- a/drivers/spi/spi-uniphier.c
+++ b/drivers/spi/spi-uniphier.c
@@ -666,28 +666,24 @@ static int uniphier_spi_probe(struct platform_device *pdev)
}
priv->base_dma_addr = res->start;
- priv->clk = devm_clk_get(&pdev->dev, NULL);
+ priv->clk = devm_clk_get_enabled(&pdev->dev, NULL);
if (IS_ERR(priv->clk)) {
dev_err(&pdev->dev, "failed to get clock\n");
ret = PTR_ERR(priv->clk);
goto out_host_put;
}
- ret = clk_prepare_enable(priv->clk);
- if (ret)
- goto out_host_put;
-
irq = platform_get_irq(pdev, 0);
if (irq < 0) {
ret = irq;
- goto out_disable_clk;
+ goto out_host_put;
}
ret = devm_request_irq(&pdev->dev, irq, uniphier_spi_handler,
0, "uniphier-spi", priv);
if (ret) {
dev_err(&pdev->dev, "failed to request IRQ\n");
- goto out_disable_clk;
+ goto out_host_put;
}
init_completion(&priv->xfer_done);
@@ -716,7 +712,7 @@ static int uniphier_spi_probe(struct platform_device *pdev)
if (IS_ERR_OR_NULL(host->dma_tx)) {
if (PTR_ERR(host->dma_tx) == -EPROBE_DEFER) {
ret = -EPROBE_DEFER;
- goto out_disable_clk;
+ goto out_host_put;
}
host->dma_tx = NULL;
dma_tx_burst = INT_MAX;
@@ -766,9 +762,6 @@ static int uniphier_spi_probe(struct platform_device *pdev)
host->dma_tx = NULL;
}
-out_disable_clk:
- clk_disable_unprepare(priv->clk);
-
out_host_put:
spi_controller_put(host);
return ret;
@@ -777,14 +770,11 @@ static int uniphier_spi_probe(struct platform_device *pdev)
static void uniphier_spi_remove(struct platform_device *pdev)
{
struct spi_controller *host = platform_get_drvdata(pdev);
- struct uniphier_spi_priv *priv = spi_controller_get_devdata(host);
if (host->dma_tx)
dma_release_channel(host->dma_tx);
if (host->dma_rx)
dma_release_channel(host->dma_rx);
-
- clk_disable_unprepare(priv->clk);
}
static const struct of_device_id uniphier_spi_match[] = {
--
2.25.1
^ permalink raw reply related
* [PATCH] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Pei Xiao @ 2026-04-07 7:32 UTC (permalink / raw)
To: michal.simek, linux-spi, linux-arm-kernel, linux-kernel, broonie; +Cc: Pei Xiao
Replace devm_clk_get() followed by clk_prepare_enable() with
devm_clk_get_enabled() for both "pclk" and "ref_clk". This removes
the need for explicit clock enable and disable calls, as the managed
API automatically disables the clocks on device removal or probe
failure.
Remove the now-unnecessary clk_disable_unprepare() calls from the
probe error paths and the remove callback. Simplify error handling
by jumping directly to the remove_ctlr label.
Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
---
drivers/spi/spi-zynq-qspi.c | 31 ++++++-------------------------
1 file changed, 6 insertions(+), 25 deletions(-)
diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
index 5232483c4a3a..8c3975030d0a 100644
--- a/drivers/spi/spi-zynq-qspi.c
+++ b/drivers/spi/spi-zynq-qspi.c
@@ -661,7 +661,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
goto remove_ctlr;
}
- xqspi->pclk = devm_clk_get(&pdev->dev, "pclk");
+ xqspi->pclk = devm_clk_get_enabled(&pdev->dev, "pclk");
if (IS_ERR(xqspi->pclk)) {
dev_err(&pdev->dev, "pclk clock not found.\n");
ret = PTR_ERR(xqspi->pclk);
@@ -670,36 +670,24 @@ static int zynq_qspi_probe(struct platform_device *pdev)
init_completion(&xqspi->data_completion);
- xqspi->refclk = devm_clk_get(&pdev->dev, "ref_clk");
+ xqspi->refclk = devm_clk_get_enabled(&pdev->dev, "ref_clk");
if (IS_ERR(xqspi->refclk)) {
dev_err(&pdev->dev, "ref_clk clock not found.\n");
ret = PTR_ERR(xqspi->refclk);
goto remove_ctlr;
}
- ret = clk_prepare_enable(xqspi->pclk);
- if (ret) {
- dev_err(&pdev->dev, "Unable to enable APB clock.\n");
- goto remove_ctlr;
- }
-
- ret = clk_prepare_enable(xqspi->refclk);
- if (ret) {
- dev_err(&pdev->dev, "Unable to enable device clock.\n");
- goto clk_dis_pclk;
- }
-
xqspi->irq = platform_get_irq(pdev, 0);
if (xqspi->irq < 0) {
ret = xqspi->irq;
- goto clk_dis_all;
+ goto remove_ctlr;
}
ret = devm_request_irq(&pdev->dev, xqspi->irq, zynq_qspi_irq,
0, pdev->name, xqspi);
if (ret != 0) {
ret = -ENXIO;
dev_err(&pdev->dev, "request_irq failed\n");
- goto clk_dis_all;
+ goto remove_ctlr;
}
ret = of_property_read_u32(np, "num-cs",
@@ -709,7 +697,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
} else if (num_cs > ZYNQ_QSPI_MAX_NUM_CS) {
ret = -EINVAL;
dev_err(&pdev->dev, "only 2 chip selects are available\n");
- goto clk_dis_all;
+ goto remove_ctlr;
} else {
ctlr->num_chipselect = num_cs;
}
@@ -728,15 +716,11 @@ static int zynq_qspi_probe(struct platform_device *pdev)
ret = devm_spi_register_controller(&pdev->dev, ctlr);
if (ret) {
dev_err(&pdev->dev, "devm_spi_register_controller failed\n");
- goto clk_dis_all;
+ goto remove_ctlr;
}
return ret;
-clk_dis_all:
- clk_disable_unprepare(xqspi->refclk);
-clk_dis_pclk:
- clk_disable_unprepare(xqspi->pclk);
remove_ctlr:
spi_controller_put(ctlr);
@@ -758,9 +742,6 @@ static void zynq_qspi_remove(struct platform_device *pdev)
struct zynq_qspi *xqspi = platform_get_drvdata(pdev);
zynq_qspi_write(xqspi, ZYNQ_QSPI_ENABLE_OFFSET, 0);
-
- clk_disable_unprepare(xqspi->refclk);
- clk_disable_unprepare(xqspi->pclk);
}
static const struct of_device_id zynq_qspi_of_match[] = {
--
2.25.1
^ permalink raw reply related
* Re: [RFC v1 01/11] media: uapi: v4l2-isp: Add v4l2 ISP extensible statistics definitions
From: Antoine Bouyer @ 2026-04-07 7:37 UTC (permalink / raw)
To: Jacopo Mondi
Cc: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, laurent.pinchart, mchehab, robh, krzk+dt, conor+dt,
shawnguo, s.hauer, kernel, festevam, linux-kernel, linux-media,
devicetree, linux-arm-kernel, Jai Luthra, paul elder
In-Reply-To: <ac93m33MhldSpYDj@zed>
Hi Jacopo
On 4/3/26 10:19 AM, Jacopo Mondi wrote:
>
>
> Hello Antoine
>
> in cc Jai and Paul
>
> Jai and Paul are working on upstreaming new ISP formats which would
> benefit from usage of extensible stats.
>
> No pressure of course, just wanted to check how things are progressing
> on your side. Do you have an updated version of this patch which can
> be taken in ? Should we sync and work on an updated version ?
I'm still on it. Things are progressing well, but little bit delayed
because of neoisp rework. I hope to submit patchset (v4l2-isp + neo) by
end of this week.
BR
Antoine
>
> Thanks!
> j
>
> On Fri, Jan 23, 2026 at 09:09:28AM +0100, Antoine Bouyer wrote:
>> Extend the v4l2-isp extensible format introduced for isp parameters buffer
>> to the statistics buffer as well.
>>
>> Like for ISP configuration purpose, that will help supporting various ISP
>> hardware versions reporting different statistics data with less impact on
>> userspace.
>>
>> The `v4l2_isp_stats_buffer` reuses the `v4l2_isp_params_buffer` container
>> definitions, with similar header, versions and flags. V0 and V1 versions
>> are provided to match with params versions. On the other side, ENABLE and
>> DISABLE flags are not really meaningfull for statistics purpose. So VALID
>> and INVALID flags are introduced. Purpose is to force ISP driver to
>> validate a statistics buffer, before it is consumed by userspace.
>>
>> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
>> ---
>> include/uapi/linux/media/v4l2-isp.h | 85 +++++++++++++++++++++++++++++
>> 1 file changed, 85 insertions(+)
>>
>> diff --git a/include/uapi/linux/media/v4l2-isp.h b/include/uapi/linux/media/v4l2-isp.h
>> index 779168f9058e..ed1279b86694 100644
>> --- a/include/uapi/linux/media/v4l2-isp.h
>> +++ b/include/uapi/linux/media/v4l2-isp.h
>> @@ -99,4 +99,89 @@ struct v4l2_isp_params_buffer {
>> __u8 data[] __counted_by(data_size);
>> };
>>
>> +/**
>> + * enum v4l2_isp_stats_version - V4L2 ISP statistics versioning
>> + *
>> + * @V4L2_ISP_STATS_VERSION_V0: First version of the V4L2 ISP statistics format
>> + * (for compatibility)
>> + * @V4L2_ISP_STATS_VERSION_V1: First version of the V4L2 ISP statistics format
>> + *
>> + * V0 and V1 are identical, and comply with V4l2 ISP parameters versions. So
>> + * both V0 and V1 refers to the first version of the V4L2 ISP statistics
>> + * format.
>> + *
>> + * Future revisions of the V4L2 ISP statistics format should start from the
>> + * value of 2.
>> + */
>> +enum v4l2_isp_stats_version {
>> + V4L2_ISP_STATS_VERSION_V0 = 0,
>> + V4L2_ISP_STATS_VERSION_V1,
>> +};
>> +
>> +#define V4L2_ISP_PARAMS_FL_BLOCK_VALID (1U << 0)
>> +#define V4L2_ISP_PARAMS_FL_BLOCK_INVALID (1U << 1)
>> +
>> +/*
>> + * Reserve the first 8 bits for V4L2_ISP_STATS_FL_* flag.
>> + *
>> + * Driver-specific flags should be defined as:
>> + * #define DRIVER_SPECIFIC_FLAG0 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(0))
>> + * #define DRIVER_SPECIFIC_FLAG1 ((1U << V4L2_ISP_STATS_FL_DRIVER_FLAGS(1))
>> + */
>> +#define V4L2_ISP_STATS_FL_DRIVER_FLAGS(n) ((n) + 8)
>> +
>> +/**
>> + * struct v4l2_isp_stats_block_header - V4L2 extensible statistics block header
>> + * @type: The statistics block type (driver-specific)
>> + * @flags: A bitmask of block flags (driver-specific)
>> + * @size: Size (in bytes) of the statistics block, including this header
>> + *
>> + * This structure represents the common part of all the ISP statistics blocks.
>> + * Each statistics block shall embed an instance of this structure type as its
>> + * first member, followed by the block-specific statistics data.
>> + *
>> + * The @type field is an ISP driver-specific value that identifies the block
>> + * type. The @size field specifies the size of the parameters block.
>> + *
>> + * The @flags field is a bitmask of per-block flags V4L2_STATS_ISP_FL_* and
>> + * driver-specific flags specified by the driver header.
>> + */
>> +struct v4l2_isp_stats_block_header {
>> + __u16 type;
>> + __u16 flags;
>> + __u32 size;
>> +} __attribute__((aligned(8)));
>> +
>> +/**
>> + * struct v4l2_isp_stats_buffer - V4L2 extensible statistics data
>> + * @version: The statistics buffer version (driver-specific)
>> + * @data_size: The statistics data effective size, excluding this header
>> + * @data: The statistics data
>> + *
>> + * This structure contains the statistics information of the ISP hardware,
>> + * serialized for userspace into a data buffer. Each statistics block is
>> + * represented by a block-specific structure which contains a
>> + * :c:type:`v4l2_isp_stats_block_header` entry as first member. Driver
>> + * populates the @data buffer with statistics information of the ISP blocks it
>> + * intends to share to userspace. As a consequence, the data buffer effective
>> + * size changes according to the number of ISP blocks that driver intends to
>> + * provide and is set by the driver in the @data_size field.
>> + *
>> + * The statistics buffer is versioned by the @version field to allow modifying
>> + * and extending its definition. Driver shall populate the @version field to
>> + * inform the userpsace about the version it intends to use. The userspace will
>> + * parse and handle the @data buffer according to the data layout specific to
>> + * the indicated version.
>> + *
>> + * For each ISP block that driver wants to report, a block-specific structure
>> + * is appended to the @data buffer, one after the other without gaps in
>> + * between. Driver shall populate the @data_size field with the effective
>> + * size, in bytes, of the @data buffer.
>> + */
>> +struct v4l2_isp_stats_buffer {
>> + __u32 version;
>> + __u32 data_size;
>> + __u8 data[] __counted_by(data_size);
>> +};
>> +
>> #endif /* _UAPI_V4L2_ISP_H_ */
>> --
>> 2.52.0
>>
^ permalink raw reply
* Re: [PATCH 3/8] firmware: sysfb: Make CONFIG_SYSFB a user-selectable option
From: Thomas Zimmermann @ 2026-04-07 7:39 UTC (permalink / raw)
To: Arnd Bergmann, Javier Martinez Canillas, Ard Biesheuvel,
Ilias Apalodimas, Huacai Chen, WANG Xuerui, Maarten Lankhorst,
Maxime Ripard, Dave Airlie, Simona Vetter, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, longli, Helge Deller
Cc: linux-arm-kernel, loongarch, linux-efi, linux-riscv, dri-devel,
linux-hyperv, linux-fbdev
In-Reply-To: <295a43ce-92fb-435d-a82f-d1cfa8f4f28d@app.fastmail.com>
Hi
Am 02.04.26 um 18:47 schrieb Arnd Bergmann:
> On Thu, Apr 2, 2026, at 17:27, Thomas Zimmermann wrote:
>> Am 02.04.26 um 16:59 schrieb Arnd Bergmann:
>>> On Thu, Apr 2, 2026, at 16:10, Thomas Zimmermann wrote:
>>>> Am 02.04.26 um 15:08 schrieb Arnd Bergmann:
>>>>> On Thu, Apr 2, 2026, at 11:09, Thomas Zimmermann wrote:
>>>>> I don't really like this part of the series and would prefer
>>>>> to keep CONFIG_SYSFB hidden as much as possible as an x86
>>>>> (and EFI) specific implementation detail, with the hope
>>>>> of eventually seperating out the x86 bits from the EFI ones.
>>>> You mean, you want to use the EFI-provided framebuffers without the
>>>> intermediate step of going through sysfb_primary_display?
>>>>
>>>> In that case, CONFIG_SYSFB would become an x86-internal thing, right?
>>> The part that is still needed from sysfb is the arbitration
>>> between DRM_EFI and the PCI device driver for the same hardware,
>>> so I think some part of sysfb is clearly needed, in particular
>>> the sysfb_disable() function that removes the EFI framebuffer
>>> when there is a conflicting simpledrm or hardware specific
>>> driver.
>> We do most of that in the aperture-helper module. (see
>> <linux/aperture.h>). Calling sysfb_disable() from there is a workaround
>> for some corner cases. We can have an EFI-specific function that does
>> the same.
> That sounds good, yes. The same change would need to go into
> of_platform_default_populate_init() then.
The call to sysfb_disable() is a workaround for certain cases that
aperture helpers don't handle well. In the longer term, I'd want
aperture helpers to be more clever about aperture ownership. But as an
intermediate step, adding other _disable() function would be an option.
But there's no hurry.
>
>> BTW, simpledrm-on-EFI/VESA is considered obsolete and should preferably
>> be removed from that driver. Simpledrm should become a driver for
>> Devicetree nodes of type simple-framebuffer (as it originally has been
>> intended).
> Sure, I was only thinking of the case where there are both
> sysfb (from Arm/riscv UEFI) and simpledrm (from devicetree)
> objects referring to the same one, not the simpledrm
> device created by sysfb_simplefb.
>
>>> The parts that I want to keep out of that is anything
>>> related to the x86 boot protocol, non-EFI framebuffers,
>>> text console, and kexec handoff, which we don't need on
>>> non-x86 UEFI systems.
>>>
>>> I don't mind the idea of having a sysfb_primary_display
>>> in the EFI code if that helps keep EFI sane on x86,
>>> but it would be good to make that local to
>>> drivers/firmware/efi and (eventually) detached from
>>> include/uapi/linux/screen_info.h.
>> Efidrm retrieves the framebuffer settings from the contained struct
>> screen_info. Disconnecting from screen_info would require separate
>> graphics drivers for x86 and non-x86. If we split off EFI from sysfb,
>> we'd likely need a sysfbdrm driver of some sort. Just saying.
> Yes, I saw that as well and don't have an immediate idea for how
> to best do it. I saw that you already abstracted the access to
> the screen_info members in drm_sysfb_screen_info.c, which I think
> is a step in that direction.
>
> I also noticed that efidrm is mostly a subset of vesadrm, so
> in theory they could be merged back into an x86 drm driver
> along with the drm_sysfb_screen_info helpers, and have a non-x86
> driver that constructs a drm_sysfb_device directly from the
> EFI structures.
I would not want to have a unifed driver for all-things-screen_info. The
code that can easily be shared is already in the sysfb helpers. But I
don't mind adding a separate driver for EFI's Graphics Output Protocol.
Then there would be current efidrm for EFI-from-screen_info and
efigopdrm for EFI via the GOP interfaces. If EFI ever specifies another
graphics interface, we could add another driver. The maintenance
overhead is small on the DRM side.
What is the future of x86's boot_param and the related screen_info on
x86-64? Is it obsolete? Will boot loaders run the EFI stub instead?
>
>> I think we'd also have to duplicate the framebuffer-relocation code that
>> currently works on anything using struct screen_info (see patch 5).
> You mean the code from include/linux/screen_info.h? I think
> it would make sense to have an x86 specific version of that
> to operate on the x86 screen_info, and a simpler version
> that just updates the resource for the efirdrm driver, but
> that could also be done one level higher or lower.
Makes me wonder if the relocation code could be integrated into the
aperture helpers. It would have to track the relocation of all PCI
graphics devices and probing DRM drivers would query the relocation
offset for their given framebuffer.
>
>>>>> In general, I am always in favor of properly using Kconfig
>>>>> dependencies over 'select' statements, for the same reasons
>>>>> you describe, but I don't want the the x86 logic for
>>>>> the legacy VESA and VGA console handling to leak into more
>>>>> architectures than necessary.
>>>>>
>>>>> Do you think we could instead move the sysfb_init()
>>>>> function into the same two places that contain the
>>>>> sysfb_primary_display definition (arch/x86/kernel/setup.c,
>>>>> drivers/firmware/efi/efi-init.c) and simplify the efi version
>>>>> to take out the x86 bits? That would reduce the rest
>>>>> of sysfb-primary.c to the logic to unregister the device,
>>>>> and that could then be selected by both x86 and EFI.
>>>> No, I'm more than happy that sysfb finally consolidates all the
>>>> init-framebuffer setup and detection that floated around in the kernel.
>>>> I would not want it to be duplicated again.
>>>>
>>>> For now, we could certainly keep CONFIG_SYSFB hidden and autoselected.
>>>> Although I think this will require soem sort of solution at a later point.
>>> Can you clarify which problem you are trying to solve
>>> with that?
>> One thing is that some users simply what control over their kernel build.
>>
>> I also think that there might be systems that want to use
>> sysfb_primary_display (plus the relocation feature), but not create the
>> framebuffer device. Say for efi-earlycon. It needs user-control over the
>> SYSFB option to do that.
> I'm still not following, sorry. efi-earlycon doesn't require
> CONFIG_SYSFB today, and I don't see why that would need to change,
> or why it couldn't just 'select SYSFB' if it it does change.
>
>> As a side-effect, user-configurable SYSFB gives us a nice place to put
>> SYSFB_SIMPLEFB and FIRMWARE_EDID; two options that currently float
>> around in the config somewhat arbitrarily.
> You said that SYSFB_SIMPLEFB should get phased out in the future,
> right?
Yes. Better sooner than later.
>
> I'm also missing your plan for CONFIG_FIRMWARE_EDID. I only
> see three legacy drivers using the old fb_firmware_edid()
> interface, so I assume this is not what you are interested in.
>
> For the global copy that is filled by x86 and efi, and
> consumed by vesadrm and efidrm, does that even need to
> be a configuration option rather than get always enabled?
There is code in x86's old 16-bit boot/init code that reads the EDID via
VESA. The help text on CONFIG_FIRMWARE_EDID sounds like it needs to be
configurable because some systems can't do the VESA calls. Hence, the
logical step seems to be to make this consistent for all systems by
adopting the option for all EDID retrieval.
If we can remove CONFIG_FIRMWARE_EDID and make EDID support
unconditional, I'm all for it.
Best regards
Thomas
>
> Arnd
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [Upstream] Re: [PATCH] arm64: dts: imx{91,93}-phyboard-segin: Add peb-av-18 overlay
From: Primoz Fiser @ 2026-04-07 6:14 UTC (permalink / raw)
To: Frank Li, Florijan Plohl
Cc: Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, imx, linux-arm-kernel,
devicetree, linux-kernel, upstream
In-Reply-To: <adMg762HH4gcuWyq@lizhi-Precision-Tower-5810>
Hi Frank, Florijan,
On 4/6/26 04:56, Frank Li wrote:
> On Fri, Apr 03, 2026 at 10:29:00AM +0200, Florijan Plohl wrote:
>> Hello,
>>
>> On 4/2/26 15:50, Frank Li wrote:
>>> On Thu, Apr 02, 2026 at 09:08:26AM +0200, Florijan Plohl wrote:
>>>> Add overlay for the PEB-AV-18 adapter on phyBOARD-Segin-i.MX91/93.
>>> what's means PEB-AV-18? Is it random board name?
>> The PEB-AV-18 is PHYTEC designation for Audio/Video adapter modules that can
>> be used to connect displays on their boards.
>>
>> I will improve commit message to add more such information in v2.
>>
>>>
>>>
>>>> The supported LCD is Powertip PH800480T032-ZHC19 panel (AC220).
>>>>
>>>> Signed-off-by: Florijan Plohl <florijan.plohl@norik.com>
>>>> ---
>>>> arch/arm64/boot/dts/freescale/Makefile | 4 +
>>>> .../imx91-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
>>>> .../imx93-phyboard-segin-peb-av-18.dtso | 142 ++++++++++++++++++
>>> Any difference between 91 and 93, can use one overlay file?
>>>
>>> Frank
>>
>> Can you suggest how to do so?
>>
>> There are imx93-pinfunc.h and imx91-pinfunc.h which are not unified
>> between imx91 and imx93.
>
> I suggest move pinmux setting to mainboard's dts files, which provide
> plug adaptor header, signal should be descripted in mainboard's dts file,
> which provide an unified label to overlay file.
Yeah, that would be one way of doing it.
However, the phycore dtsi and phyboard dts are kept simple by design
choice. This way, all optional pinctrls and peripherals are kept
separate from the board device-tree to maintain clutter low.
For v2 I would prefer to keep as is (current downstream implementation)
or at least use this approach:
imx91-93-phyboard-segin-peb-av-18.dtsi
|
-> imx91-phyboard-segin-peb-av-18.dtso
|
-> imx93-phyboard-segin-peb-av-18.dtso
BR,
Primoz
>
> Frank
>
>>
>> So we can only create common dtsi like so:
>>
>> imx91-93-phyboard-segin-peb-av-18.dtsi
>>
>> and still use separate dtsos:
>>
>> imx91-phyboard-segin-peb-av-18.dtso
>> imx93-phyboard-segin-peb-av-18.dtso
>>
>> Is that your idea?
>>
>> BR,
>>
>> Florijan Plohl
>>
>>>> --
>>>> 2.43.0
>>>>
> _______________________________________________
> upstream mailing list -- upstream@lists.phytec.de
> To unsubscribe send an email to upstream-leave@lists.phytec.de
--
Primoz Fiser
phone: +386-41-390-545
email: primoz.fiser@norik.com
--
Norik systems d.o.o.
Your embedded software partner
Slovenia, EU
phone: +386-41-540-545
email: info@norik.com
^ permalink raw reply
* Re: [PATCH] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Michal Simek @ 2026-04-07 8:01 UTC (permalink / raw)
To: Pei Xiao, linux-spi, linux-arm-kernel, linux-kernel, broonie
In-Reply-To: <0c851587c90ae51d1498d18955aefc83fa41f17d.1775547057.git.xiaopei01@kylinos.cn>
On 4/7/26 09:32, Pei Xiao wrote:
> [You don't often get email from xiaopei01@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Replace devm_clk_get() followed by clk_prepare_enable() with
> devm_clk_get_enabled() for both "pclk" and "ref_clk". This removes
> the need for explicit clock enable and disable calls, as the managed
> API automatically disables the clocks on device removal or probe
> failure.
>
> Remove the now-unnecessary clk_disable_unprepare() calls from the
> probe error paths and the remove callback. Simplify error handling
> by jumping directly to the remove_ctlr label.
>
> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
> ---
> drivers/spi/spi-zynq-qspi.c | 31 ++++++-------------------------
> 1 file changed, 6 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
> index 5232483c4a3a..8c3975030d0a 100644
> --- a/drivers/spi/spi-zynq-qspi.c
> +++ b/drivers/spi/spi-zynq-qspi.c
> @@ -661,7 +661,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
> goto remove_ctlr;
> }
>
> - xqspi->pclk = devm_clk_get(&pdev->dev, "pclk");
> + xqspi->pclk = devm_clk_get_enabled(&pdev->dev, "pclk");
> if (IS_ERR(xqspi->pclk)) {
> dev_err(&pdev->dev, "pclk clock not found.\n");
> ret = PTR_ERR(xqspi->pclk);
> @@ -670,36 +670,24 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>
> init_completion(&xqspi->data_completion);
>
> - xqspi->refclk = devm_clk_get(&pdev->dev, "ref_clk");
> + xqspi->refclk = devm_clk_get_enabled(&pdev->dev, "ref_clk");
> if (IS_ERR(xqspi->refclk)) {
> dev_err(&pdev->dev, "ref_clk clock not found.\n");
> ret = PTR_ERR(xqspi->refclk);
> goto remove_ctlr;
> }
>
> - ret = clk_prepare_enable(xqspi->pclk);
> - if (ret) {
> - dev_err(&pdev->dev, "Unable to enable APB clock.\n");
> - goto remove_ctlr;
> - }
> -
> - ret = clk_prepare_enable(xqspi->refclk);
> - if (ret) {
> - dev_err(&pdev->dev, "Unable to enable device clock.\n");
> - goto clk_dis_pclk;
> - }
> -
> xqspi->irq = platform_get_irq(pdev, 0);
> if (xqspi->irq < 0) {
> ret = xqspi->irq;
> - goto clk_dis_all;
> + goto remove_ctlr;
> }
> ret = devm_request_irq(&pdev->dev, xqspi->irq, zynq_qspi_irq,
> 0, pdev->name, xqspi);
> if (ret != 0) {
> ret = -ENXIO;
> dev_err(&pdev->dev, "request_irq failed\n");
> - goto clk_dis_all;
> + goto remove_ctlr;
> }
>
> ret = of_property_read_u32(np, "num-cs",
> @@ -709,7 +697,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
> } else if (num_cs > ZYNQ_QSPI_MAX_NUM_CS) {
> ret = -EINVAL;
> dev_err(&pdev->dev, "only 2 chip selects are available\n");
> - goto clk_dis_all;
> + goto remove_ctlr;
> } else {
> ctlr->num_chipselect = num_cs;
> }
> @@ -728,15 +716,11 @@ static int zynq_qspi_probe(struct platform_device *pdev)
> ret = devm_spi_register_controller(&pdev->dev, ctlr);
> if (ret) {
> dev_err(&pdev->dev, "devm_spi_register_controller failed\n");
> - goto clk_dis_all;
> + goto remove_ctlr;
> }
>
> return ret;
>
> -clk_dis_all:
> - clk_disable_unprepare(xqspi->refclk);
> -clk_dis_pclk:
> - clk_disable_unprepare(xqspi->pclk);
> remove_ctlr:
> spi_controller_put(ctlr);
>
> @@ -758,9 +742,6 @@ static void zynq_qspi_remove(struct platform_device *pdev)
> struct zynq_qspi *xqspi = platform_get_drvdata(pdev);
>
> zynq_qspi_write(xqspi, ZYNQ_QSPI_ENABLE_OFFSET, 0);
> -
> - clk_disable_unprepare(xqspi->refclk);
> - clk_disable_unprepare(xqspi->pclk);
> }
>
> static const struct of_device_id zynq_qspi_of_match[] = {
> --
> 2.25.1
>
There is also clock manipulation in zynq_qspi_setup_op() which needs to be handled.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v3 3/4] soc: rockchip: rk3588: add SYS_GRF SOC_CON6 register offset
From: Nicolas Frattaroli @ 2026-04-07 8:10 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Daniele Briguglio
Cc: linux-clk, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Daniele Briguglio
In-Reply-To: <20260320-rk3588-mclk-gate-grf-v3-3-980338eacd2c@superkali.me>
On Friday, 20 March 2026 11:34:15 Central European Summer Time Daniele Briguglio wrote:
> Add the RK3588_SYSGRF_SOC_CON6 register offset to the RK3588 GRF
> header. This register contains the I2S MCLK output to IO gate bits,
> needed by the clock driver.
>
> Signed-off-by: Daniele Briguglio <hello@superkali.me>
> ---
> include/soc/rockchip/rk3588_grf.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/soc/rockchip/rk3588_grf.h b/include/soc/rockchip/rk3588_grf.h
> index 02a7b2432d99..db0092fc66ad 100644
> --- a/include/soc/rockchip/rk3588_grf.h
> +++ b/include/soc/rockchip/rk3588_grf.h
> @@ -19,4 +19,6 @@
> /* Whether the LPDDR5 is in 2:1 (= 0) or 4:1 (= 1) CKR a.k.a. DQS mode */
> #define RK3588_PMUGRF_OS_REG6_LP5_CKR BIT(0)
>
> +#define RK3588_SYSGRF_SOC_CON6 0x0318
> +
> #endif /* __SOC_RK3588_GRF_H */
>
>
Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Verified the definition by comparing it to hardware documentation,
it checks out.
^ permalink raw reply
* Re: [PATCH] coresight: tpdm: fix invalid MMIO access issue
From: Leo Yan @ 2026-04-07 8:10 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Tingwei Zhang, coresight, linux-arm-kernel, linux-kernel
In-Reply-To: <20260407-fix-potential-issue-in-tpdm-v1-1-42090d27c0a8@oss.qualcomm.com>
On Tue, Apr 07, 2026 at 12:47:11PM +0800, Jie Gan wrote:
> Create the csdev_access struct only when a valid MMIO resource is
> available. In tpdm_probe(), base is uninitialized for static TPDM
> instances that lack an MMIO resource, causing csdev_access to be
> created with a garbage address and potentially leading to
> unexpected issues.
This patch itself is fine for me. However, I am wandering if this
is sufficient.
As mentioned "potentially leading to unexpected issues", can I
understand some code pieces access register with uninitialized base?
If so, you would also explictly add coresight_is_static_tpdm() to
prevent register access.
Thanks,
Leo
> Fixes: 14ae052f7947 ("coresight: tpdm: add static tpdm support")
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> drivers/hwtracing/coresight/coresight-tpdm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index 9b16f368a58b..eaf7210af648 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -1430,6 +1430,7 @@ static int tpdm_probe(struct device *dev, struct resource *res)
> if (ret)
> return ret;
>
> + desc.access = CSDEV_ACCESS_IOMEM(base);
> if (tpdm_has_dsb_dataset(drvdata))
> of_property_read_u32(drvdata->dev->of_node,
> "qcom,dsb-msrs-num", &drvdata->dsb_msr_num);
> @@ -1452,7 +1453,6 @@ static int tpdm_probe(struct device *dev, struct resource *res)
> desc.ops = &tpdm_cs_ops;
> desc.pdata = dev->platform_data;
> desc.dev = dev;
> - desc.access = CSDEV_ACCESS_IOMEM(base);
> if (res)
> desc.groups = tpdm_attr_grps;
> else
>
> ---
> base-commit: 816f193dd0d95246f208590924dd962b192def78
> change-id: 20260407-fix-potential-issue-in-tpdm-b07b44416051
>
> Best regards,
> --
> Jie Gan <jie.gan@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH] spi: zynq-qspi: Simplify clock handling with devm_clk_get_enabled()
From: Pei Xiao @ 2026-04-07 8:14 UTC (permalink / raw)
To: Michal Simek, linux-spi, linux-arm-kernel, linux-kernel, broonie
In-Reply-To: <827a6fdf-b119-4aea-9442-7f27f1383c78@amd.com>
在 2026/4/7 16:01, Michal Simek 写道:
>
>
> On 4/7/26 09:32, Pei Xiao wrote:
>> [You don't often get email from xiaopei01@kylinos.cn. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>>
>> Replace devm_clk_get() followed by clk_prepare_enable() with
>> devm_clk_get_enabled() for both "pclk" and "ref_clk". This removes
>> the need for explicit clock enable and disable calls, as the managed
>> API automatically disables the clocks on device removal or probe
>> failure.
>>
>> Remove the now-unnecessary clk_disable_unprepare() calls from the
>> probe error paths and the remove callback. Simplify error handling
>> by jumping directly to the remove_ctlr label.
>>
>> Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn>
>> ---
>> drivers/spi/spi-zynq-qspi.c | 31 ++++++-------------------------
>> 1 file changed, 6 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/spi/spi-zynq-qspi.c b/drivers/spi/spi-zynq-qspi.c
>> index 5232483c4a3a..8c3975030d0a 100644
>> --- a/drivers/spi/spi-zynq-qspi.c
>> +++ b/drivers/spi/spi-zynq-qspi.c
>> @@ -661,7 +661,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>> goto remove_ctlr;
>> }
>>
>> - xqspi->pclk = devm_clk_get(&pdev->dev, "pclk");
>> + xqspi->pclk = devm_clk_get_enabled(&pdev->dev, "pclk");
>> if (IS_ERR(xqspi->pclk)) {
>> dev_err(&pdev->dev, "pclk clock not found.\n");
>> ret = PTR_ERR(xqspi->pclk);
>> @@ -670,36 +670,24 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>>
>> init_completion(&xqspi->data_completion);
>>
>> - xqspi->refclk = devm_clk_get(&pdev->dev, "ref_clk");
>> + xqspi->refclk = devm_clk_get_enabled(&pdev->dev, "ref_clk");
>> if (IS_ERR(xqspi->refclk)) {
>> dev_err(&pdev->dev, "ref_clk clock not found.\n");
>> ret = PTR_ERR(xqspi->refclk);
>> goto remove_ctlr;
>> }
>>
>> - ret = clk_prepare_enable(xqspi->pclk);
>> - if (ret) {
>> - dev_err(&pdev->dev, "Unable to enable APB clock.\n");
>> - goto remove_ctlr;
>> - }
>> -
>> - ret = clk_prepare_enable(xqspi->refclk);
>> - if (ret) {
>> - dev_err(&pdev->dev, "Unable to enable device clock.\n");
>> - goto clk_dis_pclk;
>> - }
>> -
>> xqspi->irq = platform_get_irq(pdev, 0);
>> if (xqspi->irq < 0) {
>> ret = xqspi->irq;
>> - goto clk_dis_all;
>> + goto remove_ctlr;
>> }
>> ret = devm_request_irq(&pdev->dev, xqspi->irq, zynq_qspi_irq,
>> 0, pdev->name, xqspi);
>> if (ret != 0) {
>> ret = -ENXIO;
>> dev_err(&pdev->dev, "request_irq failed\n");
>> - goto clk_dis_all;
>> + goto remove_ctlr;
>> }
>>
>> ret = of_property_read_u32(np, "num-cs",
>> @@ -709,7 +697,7 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>> } else if (num_cs > ZYNQ_QSPI_MAX_NUM_CS) {
>> ret = -EINVAL;
>> dev_err(&pdev->dev, "only 2 chip selects are available\n");
>> - goto clk_dis_all;
>> + goto remove_ctlr;
>> } else {
>> ctlr->num_chipselect = num_cs;
>> }
>> @@ -728,15 +716,11 @@ static int zynq_qspi_probe(struct platform_device *pdev)
>> ret = devm_spi_register_controller(&pdev->dev, ctlr);
>> if (ret) {
>> dev_err(&pdev->dev, "devm_spi_register_controller failed\n");
>> - goto clk_dis_all;
>> + goto remove_ctlr;
>> }
>>
>> return ret;
>>
>> -clk_dis_all:
>> - clk_disable_unprepare(xqspi->refclk);
>> -clk_dis_pclk:
>> - clk_disable_unprepare(xqspi->pclk);
>> remove_ctlr:
>> spi_controller_put(ctlr);
>>
>> @@ -758,9 +742,6 @@ static void zynq_qspi_remove(struct platform_device *pdev)
>> struct zynq_qspi *xqspi = platform_get_drvdata(pdev);
>>
>> zynq_qspi_write(xqspi, ZYNQ_QSPI_ENABLE_OFFSET, 0);
>> -
>> - clk_disable_unprepare(xqspi->refclk);
>> - clk_disable_unprepare(xqspi->pclk);
>> }
>>
>> static const struct of_device_id zynq_qspi_of_match[] = {
>> --
>> 2.25.1
>>
>
> There is also clock manipulation in zynq_qspi_setup_op() which needs to be handled.
>
Can I remove this code? If not, please ignore this patch, and I apologize for the noise.
In zynq_qspi_setup_op:
~~~~remove this clk enable code
ret = clk_enable(qspi->refclk);
if (ret)
return ret;
ret = clk_enable(qspi->pclk);
if (ret) {
clk_disable(qspi->refclk);
return ret;
}
~~~
Thanks!
Pei.
> Thanks,
> Michal
^ 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