* [PATCH] ASoC: dt-bindings: rockchip: Convert rk3399-gru-sound to YAML
From: Anushka Badhe @ 2026-04-02 5:56 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner
Cc: linux-sound, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Anushka Badhe
Convert the rockchip,rk3399-gru-sound.txt DT binding to YAML Schema.
During conversion, property rockchip,cpu was changed from phandle to
phandle-array to properly validate existing DTS usage.
Signed-off-by: Anushka Badhe <anushkabadhe@gmail.com>
---
This was the error reported by dtbs_check when rockchip,cpu was defined as phandle:
sound (rockchip,rk3399-gru-sound): rockchip,cpu:0: [211, 212] is too
long from schema $id:
http://devicetree.org/schemas/sound/rockchip,rk3399-gru-sound.yaml
This error was found when verifying against
rockchip/rk3399-gru-kevin.dtb
.../sound/rockchip,rk3399-gru-sound.txt | 22 ---------
.../sound/rockchip,rk3399-gru-sound.yaml | 47 +++++++++++++++++++
2 files changed, 47 insertions(+), 22 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
create mode 100644 Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
deleted file mode 100644
index 72d3cf4c2606..000000000000
--- a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
-
-Required properties:
-- compatible: "rockchip,rk3399-gru-sound"
-- rockchip,cpu: The phandle of the Rockchip I2S controller that's
- connected to the codecs
-- rockchip,codec: The phandle of the audio codecs
-
-Optional properties:
-- dmic-wakeup-delay-ms : specify delay time (ms) for DMIC ready.
- If this option is specified, which means it's required dmic need
- delay for DMIC to ready so that rt5514 can avoid recording before
- DMIC send valid data
-
-Example:
-
-sound {
- compatible = "rockchip,rk3399-gru-sound";
- rockchip,cpu = <&i2s0>;
- rockchip,codec = <&max98357a &rt5514 &da7219>;
- dmic-wakeup-delay-ms = <20>;
-};
diff --git a/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
new file mode 100644
index 000000000000..10001fd2f886
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rockchip,rk3399-gru-sound.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/rockchip,rk3399-gru-sound.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ROCKCHIP with MAX98357A/RT5514/DA7219 codecs on GRU boards
+
+maintainers:
+ - Heiko Stuebner <heiko@sntech.de>
+
+properties:
+ compatible:
+ const: rockchip,rk3399-gru-sound
+
+ rockchip,cpu:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description:
+ The phandle of the Rockchip I2S controller that's connected to the codecs
+
+ rockchip,codec:
+ $ref: /schemas/types.yaml#/definitions/phandle-array
+ description: The phandle of the audio codecs
+
+ dmic-wakeup-delay-ms:
+ description:
+ specify delay time (ms) for DMIC ready.
+ If this option is specified, which means it's required dmic need
+ delay for DMIC to ready so that rt5514 can avoid recording before
+ DMIC sends valid data
+
+required:
+ - compatible
+ - rockchip,cpu
+ - rockchip,codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound {
+ compatible = "rockchip,rk3399-gru-sound";
+ rockchip,cpu = <&i2s0>;
+ rockchip,codec = <&max98357a &rt5514 &da7219>;
+ dmic-wakeup-delay-ms = <20>;
+ };
+
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 net-next 5/5] net: pcs: pcs-mtk-lynxi: deprecate "mediatek,pnswap"
From: Frank Wunderlich @ 2026-04-02 5:50 UTC (permalink / raw)
To: Vladimir Oltean
Cc: netdev, devicetree, linux-kernel, linux-mediatek, Daniel Golle,
Horatiu Vultur, Bj√∏rn Mork, Andrew Lunn,
Heiner Kallweit, Russell King, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Eric Woudstra, Alexander Couzens, Chester A. Unal, DENG Qingfang,
Sean Wang, Felix Fietkau
In-Reply-To: <20260330190443.bol5vjfqqitz7kuo@skbuf>
Hi,
i tried using these properties in sgmiisys0 node (which should be mapped to mac0 and the mt7530 switch) without success [1].
it looks like these properties are not read somewhere.
the flow is
mtk_probe (eth driver)
if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII)) {
err = mtk_sgmii_init(eth);
and there calling mtk_pcs_lynxi_create with the sgmiisys-node (for each mac, so imho mac0=sgmiisys0)
but handling the sgmiisys only as syscon, not a "real" pcs node [2].
but your new code calls phy_get_tx_polarity and should read out this properties, but from subnode "pcs", so next try was
&sgmiisys0 {
pcs {
rx-polarity = <PHY_POL_NORMAL>;
tx-polarity = <PHY_POL_INVERT>;
};
};
which results in completely strange behaviour (looks like sgmiisys1 is mapped to mac0, but based on code in mtk_sgmii_init 0=0 should be right):
[ 2.765218] SGMSYS_QPHY_WRAP_CTRL = 0x501, will write 0x500
[ 9.143849] SGMSYS_QPHY_WRAP_CTRL = 0x500, will write 0x501
but nevertheless i tried changing sgmiisys0 to sgmiisys1 and got the dame result as before
[ 2.713644] SGMSYS_QPHY_WRAP_CTRL = 0x501, will write 0x500
[ 9.061509] SGMSYS_QPHY_WRAP_CTRL = 0x500, will write 0x500
i can only change the second serdes with sgmiisys0, but not the first.
mapping between mac and sgmiisys in dts in mt7986a.dtsi [3] are like this:
eth: ethernet@15100000 {
compatible = "mediatek,mt7986-eth";
mediatek,sgmiisys = <&sgmiisys0>, <&sgmiisys1>;
...
};
ð {
status = "okay";
gmac0: mac@0 {
compatible = "mediatek,eth-mac";
...
};
gmac1: mac@1 {
compatible = "mediatek,eth-mac";
...
};
};
maybe it is time to revive the PCS framework discussion ([4]-[6])?
[1] https://github.com/frank-w/BPI-Router-Linux/commit/4846a7bb352fe5911136cba33813f099bac035fd
[2] https://elixir.bootlin.com/linux/v7.0-rc4/source/drivers/net/ethernet/mediatek/mtk_eth_soc.c#L5001
[3] https://elixir.bootlin.com/linux/v7.0-rc4/source/arch/arm64/boot/dts/mediatek/mt7986a.dtsi#L528
[4] * https://patchwork.kernel.org/project/netdevbpf/patch/20250610233134.3588011-4-sean.anderson@linux.dev/ (v6)
> pcs-framework itself had not yet got a response from netdev maintainer (only other parts)
[5] * https://patchwork.kernel.org/project/netdevbpf/patch/20250511201250.3789083-4-ansuelsmth@gmail.com/ (v4)
> discussion: https://lore.kernel.org/netdev/20250511201250.3789083-1-ansuelsmth@gmail.com/
[6] * https://patchwork.kernel.org/project/netdevbpf/patch/ba4e359584a6b3bc4b3470822c42186d5b0856f9.1721910728.git.daniel@makrotopia.org/
> discussion: https://patchwork.kernel.org/project/netdevbpf/patch/8aa905080bdb6760875d62cb3b2b41258837f80e.1702352117.git.daniel@makrotopia.org/
Am 30. März 2026 um 21:04 schrieb "Vladimir Oltean" <vladimir.oltean@nxp.com mailto:vladimir.oltean@nxp.com?to=%22Vladimir%20Oltean%22%20%3Cvladimir.oltean%40nxp.com%3E >:
>
> Hi Frank,
>
> On Mon, Mar 30, 2026 at 05:52:17PM +0000, Frank Wunderlich wrote:
>
> >
> > Hi Vladimir
> >
> > Thanks for the patch and sorry for my delay...i was away this weekend so i was not able to test.
> >
> > traffic works again (but there is only read now) and this is the result of your debug prints:
> >
> > root@bpi-r3:~# mailto:root@bpi-r3:~# dmesg | grep SGMSYS_QPHY_WRAP_CTRL
> > [ 2.706963] SGMSYS_QPHY_WRAP_CTRL = 0x501, intending to write 0x500
> > [ 9.134081] SGMSYS_QPHY_WRAP_CTRL = 0x500, intending to write 0x500
> >
> > R3/mt7986 has 2 MAC, and switch is on the first, so value will change, not sure why this is different.
> >
> > i have not found SGMSYS_QPHY_WRAP_CTRL or something related with polarity in ethernet/mac-
> > (drivers/net/ethernet/mediatek/mtk_eth_soc.c) or switch-driver (drivers/net/dsa/mt7530{,-mdio}.c)
> > in case they manipulate this register too (of course they should not). Also looked into the pcs-handling
> > in both drivers, but see nothing related to polarity. And looked for possible duplicate register const
> > definition (other name for 0xec).
> >
> This result means that your default QPHY_WRAP_CTRL register value has
> the SGMII_PN_SWAP_TX bit set. Whether that comes from U-Boot or hardware
> default or otherwise, it doesn't really matter. Curious that the
> SGMII_SW_RESET doesn't clear TX inversion, though. I guess you wouldn't
> have documentation that would suggest this setting is sticky?
>
> In Documentation/devicetree/bindings/net/pcs/mediatek,sgmiisys.yaml,
> it is not specified what happens when the "mediatek,pnswap" property is
> missing. I thought the most logical thing would be for the lane
> polarities to not be swapped - because how would you describe normal
> lane polarities otherwise? My bad for thinking the original vendor
> bindings were more sane than they were.
>
> The only way to describe the polarities that this SGMSYS block needs on
> a particular board is to use the newly introduced 'rx-polarity =
> <PHY_POL_NORMAL>' and 'tx-polarity = <PHY_POL_INVERT>'. Which I strongly
> recommend you to do, even if the attached patch should restore
> functionality with your current device tree.
>
regards Frank
^ permalink raw reply
* Re: [PATCH v8 08/18] arm64: dts: qcom: x1e80100: Add CAMCC block definition
From: Taniya Das @ 2026-04-02 5:33 UTC (permalink / raw)
To: Konrad Dybcio, Bryan O'Donoghue, Bjorn Andersson,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Robert Foss, Todor Tomov, Mauro Carvalho Chehab,
Konrad Dybcio, Vladimir Zapolskiy, Bryan O'Donoghue
Cc: linux-arm-msm, linux-clk, devicetree, linux-kernel, linux-media,
Krzysztof Kozlowski
In-Reply-To: <382725b5-1e72-44b2-b9ae-38aea1f7a976@oss.qualcomm.com>
On 3/3/2026 3:35 PM, Konrad Dybcio wrote:
>> Konrad, MxA is always ON, and with the current clock configuration, a
>> performance vote isn’t required because the clock controller currently
>> votes only for the minimum level.
> Yes, it's on, however I'm asking whether it needs to be at any specific
> higher OPP as the clocks are scaled to higher rates.
>
> In particular, PLL2 and the MCLK RCGs/branches have *some* references
> to MXA, yet their FMAX is possible @ LOWSVS_D1, so it may be that we
> *effectively* don't need any.
Sorry for the late response, Konrad. The PLL2 operates at a fixed
frequency. The maximum frequency derived from the MCLK RCGs/branches is
68.57 MHz, which can be achieved at LOWSVS_D1.
Therefore, MxA at LOWSVS_D1 should be sufficient for the MCLKs to
operate, and no explicit voting is required.
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH v3 3/3] input: touchscreen: st1232: add system wakeup support
From: Dmitry Torokhov @ 2026-04-02 5:17 UTC (permalink / raw)
To: phucduc.bui
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, Jeff LaBundy,
Bastian Hecht, Javier Carrasco, linux-input, devicetree,
linux-renesas-soc, linux-kernel
In-Reply-To: <20260306111912.58388-4-phucduc.bui@gmail.com>
On Fri, Mar 06, 2026 at 06:19:12PM +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> The ST1232 touchscreen controller can generate an interrupt when the
> panel is touched, which may be used as a wakeup source for the system.
>
> Add support for system wakeup by initializing the device wakeup
> capability in probe() based on the "wakeup-source" device property.
> When wakeup is enabled, the driver enables IRQ wake during suspend
> so that touch events can wake the system.
>
> If wakeup is not enabled, the driver retains the existing behavior of
> disabling the IRQ and powering down the controller during suspend.
I do not believe this patch is needed: i2c core already handles
"wakeup-source" property and manages wakeup IRQ.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v6 1/3] dt-bindings: mmc: sdhci-msm: Add ICE phandle
From: Kuldeep Singh @ 2026-04-02 5:14 UTC (permalink / raw)
To: Neeraj Soni, ulf.hansson, robh, krzk+dt, conor+dt, andersson,
konradybcio
Cc: linux-mmc, devicetree, linux-kernel, Abel Vesa, Abhinaba Rakshit,
linux-arm-msm
In-Reply-To: <20260310113557.348502-2-neeraj.soni@oss.qualcomm.com>
On 3/10/2026 5:05 PM, Neeraj Soni wrote:
> Starting with sc7280(kodiak), the ICE will have its own device-tree node.
> So add the qcom,ice property to reference it.
>
> To avoid double-modeling, when qcom,ice is present, disallow an embedded
> ICE register region in the SDHCI node. Older SoCs without ICE remain
> valid as no additional requirement is imposed.
>
> Co-developed-by: Abel Vesa <abel.vesa@linaro.org>
> Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
> Co-developed-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> Signed-off-by: Abhinaba Rakshit <abhinaba.rakshit@oss.qualcomm.com>
> Signed-off-by: Neeraj Soni <neeraj.soni@oss.qualcomm.com>
Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v2 10/10] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Liu Ying @ 2026-04-02 5:07 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <1a8b1a34-89bd-436e-8b5c-64ea71e8f333@nxp.com>
On Thu, Apr 02, 2026 at 12:55:32PM +0800, Liu Ying wrote:
> "pitfalls" in commit mesg, which makes me a bit more worried.
^^^^^^^^^^^ Typo, should be cover letter. Sorry.
^ permalink raw reply
* Re: [PATCH v2 10/10] drm/mxsfb/lcdif: use DRM_BRIDGE_ATTACH_NO_CONNECTOR and the bridge-connector
From: Liu Ying @ 2026-04-02 4:55 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-10-c7f2af536a24@bootlin.com>
Hi Luca,
On Mon, Mar 30, 2026 at 09:25:51PM +0200, Luca Ceresoli wrote:
> Convert this driver to DRM_BRIDGE_ATTACH_NO_CONNECTOR and to the
> drm_bridge_connector framework which is the current DRM bridge best
> practice.
>
> Tested-by: Martyn Welch <martyn.welch@collabora.com>
> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> Changes in v2:
> - Added missing select DRM_DISPLAY_HELPER in Kconfig
> - Rebased on previous patch changes
> ---
> drivers/gpu/drm/mxsfb/Kconfig | 2 ++
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 16 +++++++++++++++-
> 2 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
> index 264e74f45554..31db7a824a93 100644
> --- a/drivers/gpu/drm/mxsfb/Kconfig
> +++ b/drivers/gpu/drm/mxsfb/Kconfig
> @@ -33,6 +33,8 @@ config DRM_IMX_LCDIF
> select DRM_GEM_DMA_HELPER
> select DRM_PANEL
> select DRM_PANEL_BRIDGE
> + select DRM_DISPLAY_HELPER
> + select DRM_BRIDGE_CONNECTOR
> help
> Choose this option if you have an LCDIFv3 LCD controller.
> Those devices are found in various i.MX SoC (i.MX8MP,
> diff --git a/drivers/gpu/drm/mxsfb/lcdif_drv.c b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> index c8ba8f9b1da8..7f07ae24e0dc 100644
> --- a/drivers/gpu/drm/mxsfb/lcdif_drv.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_drv.c
> @@ -18,6 +18,7 @@
> #include <drm/clients/drm_client_setup.h>
> #include <drm/drm_atomic_helper.h>
> #include <drm/drm_bridge.h>
> +#include <drm/drm_bridge_connector.h>
> #include <drm/drm_drv.h>
> #include <drm/drm_encoder.h>
> #include <drm/drm_fbdev_dma.h>
> @@ -57,6 +58,7 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
> struct of_endpoint of_ep;
> struct drm_bridge *bridge;
> struct drm_encoder *encoder;
> + struct drm_connector *connector;
> int ret;
>
> if (!of_device_is_available(remote))
> @@ -86,11 +88,23 @@ static int lcdif_attach_bridge(struct lcdif_drm_private *lcdif)
> "Failed to initialize encoder for endpoint%u\n",
> of_ep.id);
>
> - ret = drm_bridge_attach(encoder, bridge, NULL, 0);
> + ret = drm_bridge_attach(encoder, bridge, NULL, DRM_BRIDGE_ATTACH_NO_CONNECTOR);
It seems that only analogix-anx6345.c, analogix-anx78xx.c and analogix_dp_core.c
don't allow DRM_BRIDGE_ATTACH_NO_CONNECTOR, since they error out when attaching
the bridge with the flag:
if (flags & DRM_BRIDGE_ATTACH_NO_CONNECTOR) {
DRM_ERROR("Fix bridge driver to make connector optional!");
return -EINVAL;
}
Looks like i.MX8MP platforms don't use these drivers.
But, are we completely safe here by adding the flag? You also mentioned
"pitfalls" in commit mesg, which makes me a bit more worried.
Sorry for not bringing this up in v1.
> if (ret)
> return dev_err_probe(dev, ret,
> "Failed to attach bridge for endpoint%u\n",
> of_ep.id);
> +
> + connector = drm_bridge_connector_init(lcdif->drm, encoder);
Also, kernel doc of drm_bridge_connector.c says:
* To make use of this helper, all bridges in the chain shall report bridge
* operation flags (&drm_bridge->ops) and bridge output type
* (&drm_bridge->type), as well as the DRM_BRIDGE_ATTACH_NO_CONNECTOR attach
* flag (none of the bridges shall create a DRM connector directly).
Are you sure that we are safe to use this helper?
> + if (IS_ERR(connector))
> + return dev_err_probe(dev, PTR_ERR(connector),
> + "Failed to init bridge_connector for endpoint%u\n",
> + of_ep.id);
> +
> + ret = drm_connector_attach_encoder(connector, encoder);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to attach connector for endpoint%u\n",
> + of_ep.id);
> }
>
> return 0;
>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH RFC 3/4] clk: qcom: tcsrcc-glymur: Migrate tcsr_pcie_N_clkref_en to clk_ref common helper
From: Qiang Yu @ 2026-04-02 4:47 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, johan,
linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <ebce5979-0ab5-47ff-963e-68e27216821d@oss.qualcomm.com>
On Wed, Apr 01, 2026 at 10:05:12PM +0530, Taniya Das wrote:
>
>
> On 4/1/2026 12:05 PM, Qiang Yu wrote:
> > Replace local clk_branch-based clkref definitions with descriptor-based
> > registration via qcom_clk_ref_probe().
> >
> > This keeps the glymur driver focused on clock metadata and reuses common
> > runtime logic for regulator handling, enable/disable sequencing, and OF
> > provider wiring.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > drivers/clk/qcom/tcsrcc-glymur.c | 340 +++++++++++----------------------------
> > 1 file changed, 93 insertions(+), 247 deletions(-)
> >
> > diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
> > index 9c0edebcdbb12816d1be5249e4f04bcaf02048aa..585f87b23af2d92daef1787b2f38911681c0d8ee 100644
> > --- a/drivers/clk/qcom/tcsrcc-glymur.c
> > +++ b/drivers/clk/qcom/tcsrcc-glymur.c
> > @@ -4,265 +4,115 @@
> > */
> >
> > #include <linux/clk-provider.h>
> > +#include <linux/clk/qcom.h>
> > #include <linux/mod_devicetable.h>
> > #include <linux/module.h>
> > +#include <linux/of.h>
> > #include <linux/platform_device.h>
> > #include <linux/regmap.h>
> >
> > #include <dt-bindings/clock/qcom,glymur-tcsr.h>
> >
> > -#include "clk-alpha-pll.h"
> > -#include "clk-branch.h"
> > -#include "clk-pll.h"
> > -#include "clk-rcg.h"
> > -#include "clk-regmap.h"
> > -#include "clk-regmap-divider.h"
> > -#include "clk-regmap-mux.h"
> > -#include "common.h"
> > -#include "gdsc.h"
> > -#include "reset.h"
> > -
> > -enum {
> > - DT_BI_TCXO_PAD,
> > -};
> > -
> > -static struct clk_branch tcsr_edp_clkref_en = {
> > - .halt_reg = 0x60,
> > - .halt_check = BRANCH_HALT_DELAY,
> > - .clkr = {
> > - .enable_reg = 0x60,
> > - .enable_mask = BIT(0),
> > - .hw.init = &(const struct clk_init_data) {
> > - .name = "tcsr_edp_clkref_en",
> > - .parent_data = &(const struct clk_parent_data){
> > - .index = DT_BI_TCXO_PAD,
> > - },
> > - .num_parents = 1,
> > - .ops = &clk_branch2_ops,
> > - },
> > +static const char * const tcsr_pcie_1_regulators[] = {
> > + "vdda-refgen-0p9",
> > + "vdda-refgen-1p2",
> > + "vdda-qrefrx5-0p9",
> > + "vdda-qreftx0-0p9",
> > + "vdda-qreftx0-1p2",
> > +};
> > +
> > +static const char * const tcsr_pcie_2_regulators[] = {
> > + "vdda-refgen-0p9",
> > + "vdda-refgen-1p2",
> > + "vdda-qreftx1-0p9",
> > + "vdda-qrefrpt0-0p9",
> > + "vdda-qrefrpt1-0p9",
> > + "vdda-qrefrpt2-0p9",
> > + "vdda-qrefrx2-0p9",
> > +};
> > +
> > +static const char * const tcsr_pcie_3_regulators[] = {
> > + "vdda-refgen-0p9",
> > + "vdda-refgen-1p2",
> > + "vdda-qreftx1-0p9",
> > + "vdda-qrefrpt0-0p9",
> > + "vdda-qrefrpt1-0p9",
> > + "vdda-qrefrx1-0p9",
> > +};
> > +
> > +static const char * const tcsr_pcie_4_regulators[] = {
> > + "vdda-refgen-0p9",
> > + "vdda-refgen-1p2",
> > + "vdda-qreftx1-0p9",
> > + "vdda-qrefrpt0-0p9",
> > + "vdda-qrefrpt1-0p9",
> > + "vdda-qrefrpt2-0p9",
> > + "vdda-qrefrx2-0p9",
> > +};
> > +
>
> TCSR clock refs are just not for PCIe alone, they would have supplies
> for all the ref clocks. These supplies can also be shared across other
> clock refs. I think it is not the correct way to handle the supplies, as
> TCSR does not have the complete supplies map.
>
We have complete supplies map. You can get it on ipcatlog. Here is example
for other instances eg USB and EDP:
- Glymur (eDP): CXO PAD -> TX0 -> RPT0 -> RX0 -> eDP
- Glymur (USB4_2): CXO PAD -> TX0 -> RPT0 -> RPT1 -> RX1 -> USB4_2
- Glymur (USB3): CXO PAD -> TX0 -> RPT3 -> RPT4 -> RX4 -> USB3_SS3
I only add supplies for PCIe in this series because USB and EDP vote these
LDO in their PHY driver. They can remove them in PHY dts node and add same
regulator list here.
- Qiang Yu
>
> > +static const struct qcom_clk_ref_desc tcsr_cc_glymur_clk_descs[] = {
> > + [TCSR_EDP_CLKREF_EN] = {
> > + .name = "tcsr_edp_clkref_en",
> > + .offset = 0x60,
> > },
> > -};
> >
>
>
> --
> Thanks,
> Taniya Das
>
^ permalink raw reply
* Re: [PATCH 3/3] pmdomain: qcom: rpmhpd: Add power domains for Hawi SoC
From: Fenglin Wu @ 2026-04-02 4:45 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Ulf Hansson, Konrad Dybcio, Subbaraman Narayanamurthy,
linux-arm-msm, devicetree, linux-kernel, linux-pm, kernel
In-Reply-To: <ht2vvduvxvz3s36cn5m54hv3zon7qelrgat3tnykfvqi7f56fd@t24kmaliap5l>
On 4/1/2026 7:31 PM, Dmitry Baryshkov wrote:
> On Wed, Apr 01, 2026 at 02:15:31AM -0700, Fenglin Wu wrote:
>> Add the RPMh power domains required for the Hawi SoC. This includes
>> new definitions for domains supplying specific hardware components:
>> - DCX: supplies VDD_DISP
>> - GBX: supplies VDD_GFX_BX
>>
>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>> ---
>> drivers/pmdomain/qcom/rpmhpd.c | 38 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 38 insertions(+)
>>
>> + [RPMHPD_LCX] = &lcx,
>> + [RPMHPD_LMX] = &lmx,
>> + [RPMHPD_MMCX] = &mmcx,
>> + [RPMHPD_MMCX_AO] = &mmcx_ao,
> So, should it be just mmcx or mmcx_w_cx_parent ?
It is mmcx.
There is no such requirement to vote cx before voting mmcx on Hawi SoC.
>> + [RPMHPD_MX] = &mx,
>> + [RPMHPD_MX_AO] = &mx_ao,
^ permalink raw reply
* Re: [PATCH 2/2] spmi: spmi-pmic-arb: add support for PMIC arbiter v8.5
From: Fenglin Wu @ 2026-04-02 4:18 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Subbaraman Narayanamurthy, David Collins,
linux-arm-msm, linux-kernel, devicetree, kernel
In-Reply-To: <mxawruvb2p6svks3y4rab7feyn4dhkwe6dosjyc6yt2ozdaual@bvvof6rzm3jo>
On 4/1/2026 7:22 PM, Dmitry Baryshkov wrote:
> On Wed, Apr 01, 2026 at 02:41:24AM -0700, Fenglin Wu wrote:
>> PMIC arbiter v8.5 is an extension of PMIC arbiter v8 that updated
>> the definition of the channel status register bit fields. Add support
>> to handle this difference.
>>
>> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
>> ---
>> drivers/spmi/spmi-pmic-arb.c | 69 ++++++++++++++++++++++++++++++++++++++------
>> 1 file changed, 60 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
>> index 69f8d456324a..deeaa39bb647 100644
>> --- a/drivers/spmi/spmi-pmic-arb.c
>> +++ b/drivers/spmi/spmi-pmic-arb.c
>> @@ -28,6 +28,7 @@
>> #define PMIC_ARB_VERSION_V5_MIN 0x50000000
>> #define PMIC_ARB_VERSION_V7_MIN 0x70000000
>> #define PMIC_ARB_VERSION_V8_MIN 0x80000000
>> +#define PMIC_ARB_VERSION_V8P5_MIN 0x80050000
>> #define PMIC_ARB_INT_EN 0x0004
>>
>> #define PMIC_ARB_FEATURES 0x0004
>> @@ -63,11 +64,34 @@
>> #define SPMI_OWNERSHIP_PERIPH2OWNER(X) ((X) & 0x7)
>>
>> /* Channel Status fields */
>> -enum pmic_arb_chnl_status {
>> - PMIC_ARB_STATUS_DONE = BIT(0),
>> - PMIC_ARB_STATUS_FAILURE = BIT(1),
>> - PMIC_ARB_STATUS_DENIED = BIT(2),
>> - PMIC_ARB_STATUS_DROPPED = BIT(3),
>> +struct pmic_arb_chnl_status_mask {
>> + u8 done;
>> + u8 failure;
>> + u8 crc;
>> + u8 parity;
>> + u8 nack;
>> + u8 denied;
>> + u8 dropped;
>> +};
>> +
>> +static const struct pmic_arb_chnl_status_mask chnl_status_mask = {
>> + .done = BIT(0),
>> + .failure = BIT(1),
>> + .crc = 0,
>> + .parity = 0,
>> + .nack = 0,
>> + .denied = BIT(2),
>> + .dropped = BIT(3),
>> +};
>> +
>> +static const struct pmic_arb_chnl_status_mask chnl_status_mask_v8p5 = {
>> + .done = BIT(0),
>> + .failure = BIT(1),
>> + .crc = BIT(2),
>> + .parity = BIT(3),
>> + .nack = BIT(4),
>> + .denied = BIT(5),
>> + .dropped = BIT(6),
> Would it be better to extract generation-specific callback to decode the
> error rather than defining the list of masks?
Are you proposing to add a callback in pmic_arb_ver_ops, like
'*check_chnl_status', and create separate implementations for PMIC
arbiter versions before and after v8.5?
This approach would add more extensive code changes with some code
duplication, especially for handling common error bits shared across all
versions—even if they only print error messages and return an error
code. Is that a concern?
Fenglin
^ permalink raw reply
* Re: [PATCH RFC 1/4] dt-bindings: clock: qcom,sm8550-tcsr: Add QREF regulator supplies for glymur
From: Qiang Yu @ 2026-04-02 4:08 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Taniya Das, Konrad Dybcio,
johan, linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <6d0c1154-b249-4c44-acb4-52d43d626fa6@kernel.org>
On Wed, Apr 01, 2026 at 09:18:12AM +0200, Krzysztof Kozlowski wrote:
> On 01/04/2026 08:35, Qiang Yu wrote:
> > The glymur TCSR PCIe clkref clocks require regulator supplies for the
> > QREF block and its refgen reference voltage generator. Add the optional
> > supply properties restricted to qcom,glymur-tcsr via an allOf/if/then
> > conditional schema.
> >
> > Switch from additionalProperties to unevaluatedProperties so that
> > properties defined inside the if/then block are correctly recognised as
> > evaluated and not rejected by the schema validator.
>
> Sorry, but no. There is a reason for that why additionalProperties fail
> and writing-bindings explain that.
>
Okay, will change this part.
> >
> > Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> > ---
> > .../bindings/clock/qcom,sm8550-tcsr.yaml | 26 +++++++++++++++++++++-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> > index ae9aef0e54e8b8b85bc70e6096d524447091f39e..88db650e69ef2388a5bfb6783a57c1d48c0e780f 100644
> > --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> > +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
> > @@ -49,11 +49,35 @@ properties:
> > '#reset-cells':
> > const: 1
> >
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: qcom,glymur-tcsr
> > + then:
> > + properties:
> > + vdda-refgen-0p9-supply: true
> > + vdda-refgen-1p2-supply: true
> > + vdda-qrefrx0-0p9-supply: true
> > + vdda-qrefrx1-0p9-supply: true
> > + vdda-qrefrx2-0p9-supply: true
> > + vdda-qrefrx4-0p9-supply: true
> > + vdda-qrefrx5-0p9-supply: true
> > + vdda-qreftx0-0p9-supply: true
> > + vdda-qreftx0-1p2-supply: true
> > + vdda-qreftx1-0p9-supply: true
> > + vdda-qrefrpt0-0p9-supply: true
> > + vdda-qrefrpt1-0p9-supply: true
> > + vdda-qrefrpt2-0p9-supply: true
> > + vdda-qrefrpt3-0p9-supply: true
> > + vdda-qrefrpt4-0p9-supply: true
>
> I really doubt that TCSR, which is a small, tiny tiny block the in SoC
> have this ~15 pin supplies.
>
> Anyway, if it has, then device is quite different and should live in its
> own schema.
TX/RPT/RX are common QREF components across platforms; what changes by SoC
is the number of instances and the routing topology.
For example, a single PCIe path on Glymur and Kaanapali:
- Glymur: CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
- Kaanapali: CXO -> TX0 -> RPT0 -> RPT1 -> RX0 -> PCIe0_PHY
The DT supplies added in this series (vdda-qreftx*, vdda-qrefrpt*
vdda-qrefrx*) supply to these TX/RPT/RX components and can be resused by
other plarforms.
- Qiang Yu
^ permalink raw reply
* Re: [PATCH v2 09/10] drm/bridge: imx8mp-hdmi-tx: switch to DRM_BRIDGE_ATTACH_NO_CONNECTOR
From: Liu Ying @ 2026-04-02 4:08 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-9-c7f2af536a24@bootlin.com>
On Mon, Mar 30, 2026 at 09:25:50PM +0200, Luca Ceresoli wrote:
> The imx8mp-hdmi-tx one of many drivers based on dw-hdmi. dw-hdmi in turn
> can operate in two different modes, depending on the platform data as set
> by the driver:
>
> A. hdmi->plat_data->output_port = 0:
> the HDMI output (port@1) in device tree is not used [0]
>
> B. hdmi->plat_data->output_port = 1:
> the HDMI output (port@1) is parsed to find the next bridge
>
> The imx8mp-hdmi-tx driver falls in case A. Switching to case B, which is
> the current best practice, requires that the HDMI connector is always
> described in the live device tree, and a previous commit ensured this is
> always the case by adding an overlay in case the device tree does not
> comply.
>
> So now we can simply switch to the new mode and support
> DRM_BRIDGE_ATTACH_NO_CONNECTOR.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> Changes in v2:
> - new patch, split out of the previous patch
> ---
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 1 +
> 1 file changed, 1 insertion(+)
Reviewed-by: Liu Ying <victor.liu@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 08/10] drm/bridge: imx8mp-hdmi-tx: add an hdmi-connector when missing using a DT overlay at boot time
From: Liu Ying @ 2026-04-02 4:05 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-8-c7f2af536a24@bootlin.com>
Hi Luca,
On Mon, Mar 30, 2026 at 09:25:49PM +0200, Luca Ceresoli wrote:
[...]
> Changes in v2:
> - don't apply the overlay if the SoC is not i.MX8MP
> - build unconditionally, but depend on DRM_IMX_LCDIF
> - remove useless error check
> - add missing cleanup.h and init.h includes, remove unneeded includes
> - avoid dtc warnings on overlay
> - fix typo in Kconfig help text
> - not added the Tested-bys because the code has changed
> - split the 'plat_data->output_port = 1' line to a separate patch
v2 also changes commit mesg.
[...]
> +static int __init imx8mp_hdmi_tx_connector_fixup_init(void)
[...]
> + return of_overlay_fdt_apply(dtbo_start, dtbo_size, &ovcs_id, NULL);
Kernel doc of of_overlay_fdt_apply() says:
* On error return, the changeset may be partially applied. This is especially
* likely if an OF_OVERLAY_POST_APPLY notifier returns an error. In this case
* the caller should call of_overlay_remove() with the value in *@ret_ovcs_id.
Need a bailout?
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 07/10] drm/bridge: dw-hdmi: move next_bridge lookup to attach time
From: Liu Ying @ 2026-04-02 3:59 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-7-c7f2af536a24@bootlin.com>
On Mon, Mar 30, 2026 at 09:25:48PM +0200, Luca Ceresoli wrote:
> This driver looks up the next_bridge at probe time and stores it in
> hdmi->bridge.next_bridge, but only uses the stored value when attaching,
> and only in the DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
>
> This will be problematic with an upcoming change, adding an hdmi-connector
> using a device tree overlay when not present. That change is in turn
> necessary to migrate the i.MX LCDIF driver to the bridge-connector.
>
> The problem is that, adding the hdmi-connector via an overlay, devlink
> considers hdmi-connector a consumer of the dw-hdmi device, generating a
> chicken-egg problem:
>
> * hdmi-connector probe won't be tried until dw-hdmi is probed (devlink)
> * dw-hdmi probe will defer until it finds the next_bridge (the
> hdmi-connector wrapper bridge)
>
> In preparation for those changes, move the next_bridge lookup from probe to
> attach, when it is actually used. This allows dw-hdmi to probe, so that the
> hdmi-connector can probe as well.
>
> Also avoid storing the pointer in hdmi->bridge.next_bridge: the value is
> computed when needed, thus a local variable is enough.
>
> Finally, this also allows to slightly improve the code by not doing any DT
> lookup in the !DRM_BRIDGE_ATTACH_NO_CONNECTOR case.
>
> Tested-by: Martyn Welch <martyn.welch@collabora.com>
> Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com> # TQMa8MPxL/MBa8MPxL
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> Changes in v2:
> - Fix returned error codes
> - Added missing cleanup.h include
> ---
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 45 +++++++++++--------------------
> 1 file changed, 16 insertions(+), 29 deletions(-)
Acked-by: Liu Ying <victor.liu@nxp.com>
^ permalink raw reply
* Re: [PATCH v2 04/10] drm/mxsfb/lcdif: lcdif_attach_bridge: move iteration-specific variables declaration inside loop
From: Liu Ying @ 2026-04-02 3:57 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-4-c7f2af536a24@bootlin.com>
On Mon, Mar 30, 2026 at 09:25:45PM +0200, Luca Ceresoli wrote:
> The bridge and ret variables are per-iteration variables, whose values
> don't have to be carried to the next iteration or be used after the loop
> end. Move their declaration inside the loop scope as a cleanup and to make
> code clearer.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> This patch is new in v2
> ---
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Nit: change subject to:
drm/mxsfb/lcdif: move iteration-specific variables declaration inside loop in lcdif_attach_bridge
Reviewed-by: Liu Ying <victor.liu@nxp.com>
--
Regards,
Liu Ying
^ permalink raw reply
* [PATCH ath-next v4 6/6] wifi: ath12k: Enable IPQ5424 WiFi device support
From: Raj Kumar Bhagat @ 2026-04-02 3:54 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Raj Kumar Bhagat, Sowmiya Sree Elavalagan,
Saravanakumar Duraisamy
In-Reply-To: <20260402-ath12k-ipq5424-v4-0-cd1e0f0a6c88@oss.qualcomm.com>
From: Sowmiya Sree Elavalagan <sowmiya.elavalagan@oss.qualcomm.com>
Currently, ath12k AHB (in IPQ5332) uses SCM calls to authenticate the
firmware image to bring up userpd. From IPQ5424 onwards, Q6 firmware can
directly communicate with the Trusted Management Engine - Lite (TME-L),
eliminating the need for SCM calls for userpd bring-up.
Hence, to enable IPQ5424 device support, use qcom_mdt_load_no_init() and
skip the SCM call as Q6 will directly authenticate the userpd firmware.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Signed-off-by: Sowmiya Sree Elavalagan <sowmiya.elavalagan@oss.qualcomm.com>
Co-developed-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
Co-developed-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/ahb.c | 36 ++++++++++++++++++-----------
drivers/net/wireless/ath/ath12k/ahb.h | 1 +
drivers/net/wireless/ath/ath12k/wifi7/ahb.c | 8 +++++++
3 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/ahb.c b/drivers/net/wireless/ath/ath12k/ahb.c
index 9a4d34e49104..2dcf0a52e4c1 100644
--- a/drivers/net/wireless/ath/ath12k/ahb.c
+++ b/drivers/net/wireless/ath/ath12k/ahb.c
@@ -382,8 +382,12 @@ static int ath12k_ahb_power_up(struct ath12k_base *ab)
ATH12K_AHB_UPD_SWID;
/* Load FW image to a reserved memory location */
- ret = qcom_mdt_load(dev, fw, fw_name, pasid, mem_region, mem_phys, mem_size,
- &mem_phys);
+ if (ab_ahb->scm_auth_enabled)
+ ret = qcom_mdt_load(dev, fw, fw_name, pasid, mem_region,
+ mem_phys, mem_size, &mem_phys);
+ else
+ ret = qcom_mdt_load_no_init(dev, fw, fw_name, mem_region,
+ mem_phys, mem_size, &mem_phys);
if (ret) {
ath12k_err(ab, "Failed to load MDT segments: %d\n", ret);
goto err_fw;
@@ -414,11 +418,13 @@ static int ath12k_ahb_power_up(struct ath12k_base *ab)
goto err_fw2;
}
- /* Authenticate FW image using peripheral ID */
- ret = qcom_scm_pas_auth_and_reset(pasid);
- if (ret) {
- ath12k_err(ab, "failed to boot the remote processor %d\n", ret);
- goto err_fw2;
+ if (ab_ahb->scm_auth_enabled) {
+ /* Authenticate FW image using peripheral ID */
+ ret = qcom_scm_pas_auth_and_reset(pasid);
+ if (ret) {
+ ath12k_err(ab, "failed to boot the remote processor %d\n", ret);
+ goto err_fw2;
+ }
}
/* Instruct Q6 to spawn userPD thread */
@@ -475,13 +481,15 @@ static void ath12k_ahb_power_down(struct ath12k_base *ab, bool is_suspend)
qcom_smem_state_update_bits(ab_ahb->stop_state, BIT(ab_ahb->stop_bit), 0);
- pasid = (u32_encode_bits(ab_ahb->userpd_id, ATH12K_USERPD_ID_MASK)) |
- ATH12K_AHB_UPD_SWID;
- /* Release the firmware */
- ret = qcom_scm_pas_shutdown(pasid);
- if (ret)
- ath12k_err(ab, "scm pas shutdown failed for userPD%d: %d\n",
- ab_ahb->userpd_id, ret);
+ if (ab_ahb->scm_auth_enabled) {
+ pasid = (u32_encode_bits(ab_ahb->userpd_id, ATH12K_USERPD_ID_MASK)) |
+ ATH12K_AHB_UPD_SWID;
+ /* Release the firmware */
+ ret = qcom_scm_pas_shutdown(pasid);
+ if (ret)
+ ath12k_err(ab, "scm pas shutdown failed for userPD%d\n",
+ ab_ahb->userpd_id);
+ }
}
static void ath12k_ahb_init_qmi_ce_config(struct ath12k_base *ab)
diff --git a/drivers/net/wireless/ath/ath12k/ahb.h b/drivers/net/wireless/ath/ath12k/ahb.h
index be9e31b3682d..0fa15daaa3e6 100644
--- a/drivers/net/wireless/ath/ath12k/ahb.h
+++ b/drivers/net/wireless/ath/ath12k/ahb.h
@@ -68,6 +68,7 @@ struct ath12k_ahb {
int userpd_irq_num[ATH12K_USERPD_MAX_IRQ];
const struct ath12k_ahb_ops *ahb_ops;
const struct ath12k_ahb_device_family_ops *device_family_ops;
+ bool scm_auth_enabled;
};
struct ath12k_ahb_driver {
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/ahb.c b/drivers/net/wireless/ath/ath12k/wifi7/ahb.c
index a6c5f7689edd..6a8b8b2a56f9 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/ahb.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/ahb.c
@@ -19,6 +19,9 @@ static const struct of_device_id ath12k_wifi7_ahb_of_match[] = {
{ .compatible = "qcom,ipq5332-wifi",
.data = (void *)ATH12K_HW_IPQ5332_HW10,
},
+ { .compatible = "qcom,ipq5424-wifi",
+ .data = (void *)ATH12K_HW_IPQ5424_HW10,
+ },
{ }
};
@@ -38,6 +41,11 @@ static int ath12k_wifi7_ahb_probe(struct platform_device *pdev)
switch (hw_rev) {
case ATH12K_HW_IPQ5332_HW10:
ab_ahb->userpd_id = ATH12K_IPQ5332_USERPD_ID;
+ ab_ahb->scm_auth_enabled = true;
+ break;
+ case ATH12K_HW_IPQ5424_HW10:
+ ab_ahb->userpd_id = ATH12K_IPQ5332_USERPD_ID;
+ ab_ahb->scm_auth_enabled = false;
break;
default:
return -EOPNOTSUPP;
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next v4 5/6] wifi: ath12k: Add CE remap hardware parameters for IPQ5424
From: Raj Kumar Bhagat @ 2026-04-02 3:54 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Raj Kumar Bhagat, Saravanakumar Duraisamy
In-Reply-To: <20260402-ath12k-ipq5424-v4-0-cd1e0f0a6c88@oss.qualcomm.com>
From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
Add CE remap hardware parameters for Ath12k AHB device IPQ5424.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/ce.h | 13 +++++++++----
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 22 +++++++++++++++++-----
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/ce.h b/drivers/net/wireless/ath/ath12k/ce.h
index df4f2a4f8480..009cddf2d68d 100644
--- a/drivers/net/wireless/ath/ath12k/ce.h
+++ b/drivers/net/wireless/ath/ath12k/ce.h
@@ -38,10 +38,15 @@
#define PIPEDIR_INOUT 3 /* bidirectional */
#define PIPEDIR_INOUT_H2H 4 /* bidirectional, host to host */
-/* CE address/mask */
-#define CE_HOST_IE_ADDRESS 0x75804C
-#define CE_HOST_IE_2_ADDRESS 0x758050
-#define CE_HOST_IE_3_ADDRESS CE_HOST_IE_ADDRESS
+/* IPQ5332 CE address/mask */
+#define CE_HOST_IPQ5332_IE_ADDRESS 0x75804C
+#define CE_HOST_IPQ5332_IE_2_ADDRESS 0x758050
+#define CE_HOST_IPQ5332_IE_3_ADDRESS CE_HOST_IPQ5332_IE_ADDRESS
+
+/* IPQ5424 CE address/mask */
+#define CE_HOST_IPQ5424_IE_ADDRESS 0x21804C
+#define CE_HOST_IPQ5424_IE_2_ADDRESS 0x218050
+#define CE_HOST_IPQ5424_IE_3_ADDRESS CE_HOST_IPQ5424_IE_ADDRESS
#define CE_HOST_IE_3_SHIFT 0xC
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
index 9b9ca06a9f45..a2c98cc1e348 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
@@ -329,9 +329,15 @@ static const struct ath12k_hw_ring_mask ath12k_wifi7_hw_ring_mask_wcn7850 = {
};
static const struct ce_ie_addr ath12k_wifi7_ce_ie_addr_ipq5332 = {
- .ie1_reg_addr = CE_HOST_IE_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
- .ie2_reg_addr = CE_HOST_IE_2_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
- .ie3_reg_addr = CE_HOST_IE_3_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
+ .ie1_reg_addr = CE_HOST_IPQ5332_IE_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
+ .ie2_reg_addr = CE_HOST_IPQ5332_IE_2_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
+ .ie3_reg_addr = CE_HOST_IPQ5332_IE_3_ADDRESS - HAL_IPQ5332_CE_WFSS_REG_BASE,
+};
+
+static const struct ce_ie_addr ath12k_wifi7_ce_ie_addr_ipq5424 = {
+ .ie1_reg_addr = CE_HOST_IPQ5424_IE_ADDRESS - HAL_IPQ5424_CE_WFSS_REG_BASE,
+ .ie2_reg_addr = CE_HOST_IPQ5424_IE_2_ADDRESS - HAL_IPQ5424_CE_WFSS_REG_BASE,
+ .ie3_reg_addr = CE_HOST_IPQ5424_IE_3_ADDRESS - HAL_IPQ5424_CE_WFSS_REG_BASE,
};
static const struct ce_remap ath12k_wifi7_ce_remap_ipq5332 = {
@@ -340,6 +346,12 @@ static const struct ce_remap ath12k_wifi7_ce_remap_ipq5332 = {
.cmem_offset = HAL_SEQ_WCSS_CMEM_OFFSET,
};
+static const struct ce_remap ath12k_wifi7_ce_remap_ipq5424 = {
+ .base = HAL_IPQ5424_CE_WFSS_REG_BASE,
+ .size = HAL_IPQ5424_CE_SIZE,
+ .cmem_offset = HAL_SEQ_WCSS_CMEM_OFFSET,
+};
+
static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
{
.name = "qcn9274 hw1.0",
@@ -822,8 +834,8 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
.iova_mask = 0,
.supports_aspm = false,
- .ce_ie_addr = NULL,
- .ce_remap = NULL,
+ .ce_ie_addr = &ath12k_wifi7_ce_ie_addr_ipq5424,
+ .ce_remap = &ath12k_wifi7_ce_remap_ipq5424,
.bdf_addr_offset = 0x940000,
.dp_primary_link_only = true,
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next v4 4/6] wifi: ath12k: add ath12k_hw_regs for IPQ5424
From: Raj Kumar Bhagat @ 2026-04-02 3:54 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Raj Kumar Bhagat, Saravanakumar Duraisamy
In-Reply-To: <20260402-ath12k-ipq5424-v4-0-cd1e0f0a6c88@oss.qualcomm.com>
From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
Add register addresses (ath12k_hw_regs) for ath12k AHB based
WiFi 7 device IPQ5424.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/wifi7/hal.c | 2 +-
drivers/net/wireless/ath/ath12k/wifi7/hal.h | 3 +
.../net/wireless/ath/ath12k/wifi7/hal_qcn9274.c | 88 ++++++++++++++++++++++
.../net/wireless/ath/ath12k/wifi7/hal_qcn9274.h | 1 +
4 files changed, 93 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.c b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
index c2cc99a83f09..a0a1902fb491 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hal.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
@@ -55,7 +55,7 @@ static const struct ath12k_hw_version_map ath12k_wifi7_hw_ver_map[] = {
.hal_desc_sz = sizeof(struct hal_rx_desc_qcn9274_compact),
.tcl_to_wbm_rbm_map = ath12k_hal_tcl_to_wbm_rbm_map_qcn9274,
.hal_params = &ath12k_hw_hal_params_ipq5332,
- .hw_regs = NULL,
+ .hw_regs = &ipq5424_regs,
},
};
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.h b/drivers/net/wireless/ath/ath12k/wifi7/hal.h
index 9337225a5253..3d9386198893 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hal.h
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.h
@@ -364,6 +364,9 @@
#define HAL_IPQ5332_CE_WFSS_REG_BASE 0x740000
#define HAL_IPQ5332_CE_SIZE 0x100000
+#define HAL_IPQ5424_CE_WFSS_REG_BASE 0x200000
+#define HAL_IPQ5424_CE_SIZE 0x100000
+
#define HAL_RX_MAX_BA_WINDOW 256
#define HAL_DEFAULT_BE_BK_VI_REO_TIMEOUT_USEC (100 * 1000)
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c
index 41c918eb1767..ba9ce1e718e8 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.c
@@ -484,6 +484,94 @@ const struct ath12k_hw_regs ipq5332_regs = {
HAL_IPQ5332_CE_WFSS_REG_BASE,
};
+const struct ath12k_hw_regs ipq5424_regs = {
+ /* SW2TCL(x) R0 ring configuration address */
+ .tcl1_ring_id = 0x00000918,
+ .tcl1_ring_misc = 0x00000920,
+ .tcl1_ring_tp_addr_lsb = 0x0000092c,
+ .tcl1_ring_tp_addr_msb = 0x00000930,
+ .tcl1_ring_consumer_int_setup_ix0 = 0x00000940,
+ .tcl1_ring_consumer_int_setup_ix1 = 0x00000944,
+ .tcl1_ring_msi1_base_lsb = 0x00000958,
+ .tcl1_ring_msi1_base_msb = 0x0000095c,
+ .tcl1_ring_base_lsb = 0x00000910,
+ .tcl1_ring_base_msb = 0x00000914,
+ .tcl1_ring_msi1_data = 0x00000960,
+ .tcl2_ring_base_lsb = 0x00000988,
+ .tcl_ring_base_lsb = 0x00000b68,
+
+ /* TCL STATUS ring address */
+ .tcl_status_ring_base_lsb = 0x00000d48,
+
+ /* REO DEST ring address */
+ .reo2_ring_base = 0x00000578,
+ .reo1_misc_ctrl_addr = 0x00000b9c,
+ .reo1_sw_cookie_cfg0 = 0x0000006c,
+ .reo1_sw_cookie_cfg1 = 0x00000070,
+ .reo1_qdesc_lut_base0 = 0x00000074,
+ .reo1_qdesc_lut_base1 = 0x00000078,
+ .reo1_ring_base_lsb = 0x00000500,
+ .reo1_ring_base_msb = 0x00000504,
+ .reo1_ring_id = 0x00000508,
+ .reo1_ring_misc = 0x00000510,
+ .reo1_ring_hp_addr_lsb = 0x00000514,
+ .reo1_ring_hp_addr_msb = 0x00000518,
+ .reo1_ring_producer_int_setup = 0x00000524,
+ .reo1_ring_msi1_base_lsb = 0x00000548,
+ .reo1_ring_msi1_base_msb = 0x0000054C,
+ .reo1_ring_msi1_data = 0x00000550,
+ .reo1_aging_thres_ix0 = 0x00000B28,
+ .reo1_aging_thres_ix1 = 0x00000B2C,
+ .reo1_aging_thres_ix2 = 0x00000B30,
+ .reo1_aging_thres_ix3 = 0x00000B34,
+
+ /* REO Exception ring address */
+ .reo2_sw0_ring_base = 0x000008c0,
+
+ /* REO Reinject ring address */
+ .sw2reo_ring_base = 0x00000320,
+ .sw2reo1_ring_base = 0x00000398,
+
+ /* REO cmd ring address */
+ .reo_cmd_ring_base = 0x000002A8,
+
+ /* REO status ring address */
+ .reo_status_ring_base = 0x00000aa0,
+
+ /* WBM idle link ring address */
+ .wbm_idle_ring_base_lsb = 0x00000d3c,
+ .wbm_idle_ring_misc_addr = 0x00000d4c,
+ .wbm_r0_idle_list_cntl_addr = 0x00000240,
+ .wbm_r0_idle_list_size_addr = 0x00000244,
+ .wbm_scattered_ring_base_lsb = 0x00000250,
+ .wbm_scattered_ring_base_msb = 0x00000254,
+ .wbm_scattered_desc_head_info_ix0 = 0x00000260,
+ .wbm_scattered_desc_head_info_ix1 = 0x00000264,
+ .wbm_scattered_desc_tail_info_ix0 = 0x00000270,
+ .wbm_scattered_desc_tail_info_ix1 = 0x00000274,
+ .wbm_scattered_desc_ptr_hp_addr = 0x0000027c,
+
+ /* SW2WBM release ring address */
+ .wbm_sw_release_ring_base_lsb = 0x0000037c,
+
+ /* WBM2SW release ring address */
+ .wbm0_release_ring_base_lsb = 0x00000e08,
+ .wbm1_release_ring_base_lsb = 0x00000e80,
+
+ /* PPE release ring address */
+ .ppe_rel_ring_base = 0x0000046c,
+
+ /* CE address */
+ .umac_ce0_src_reg_base = 0x00200000 -
+ HAL_IPQ5424_CE_WFSS_REG_BASE,
+ .umac_ce0_dest_reg_base = 0x00201000 -
+ HAL_IPQ5424_CE_WFSS_REG_BASE,
+ .umac_ce1_src_reg_base = 0x00202000 -
+ HAL_IPQ5424_CE_WFSS_REG_BASE,
+ .umac_ce1_dest_reg_base = 0x00203000 -
+ HAL_IPQ5424_CE_WFSS_REG_BASE,
+};
+
static inline
bool ath12k_hal_rx_desc_get_first_msdu_qcn9274(struct hal_rx_desc *desc)
{
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h
index 08c0a0469474..03cf3792d523 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hal_qcn9274.h
@@ -17,6 +17,7 @@ extern const struct hal_ops hal_qcn9274_ops;
extern const struct ath12k_hw_regs qcn9274_v1_regs;
extern const struct ath12k_hw_regs qcn9274_v2_regs;
extern const struct ath12k_hw_regs ipq5332_regs;
+extern const struct ath12k_hw_regs ipq5424_regs;
extern const struct ath12k_hal_tcl_to_wbm_rbm_map
ath12k_hal_tcl_to_wbm_rbm_map_qcn9274[DP_TCL_NUM_RING_MAX];
extern const struct ath12k_hw_hal_params ath12k_hw_hal_params_qcn9274;
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next v4 3/6] wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424
From: Raj Kumar Bhagat @ 2026-04-02 3:54 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Raj Kumar Bhagat
In-Reply-To: <20260402-ath12k-ipq5424-v4-0-cd1e0f0a6c88@oss.qualcomm.com>
Add a new ath12k_hw_version_map entry for the AHB based WiFi 7 device
IPQ5424.
Reuse most of the ath12k_hw_version_map fields such as hal_ops,
hal_desc_sz, tcl_to_wbm_rbm_map, and hal_params from IPQ5332. The
register addresses differ on IPQ5424, hence set hw_regs temporarily
to NULL and populated it in a subsequent patch.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/wifi7/hal.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hal.c b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
index bd1753ca0db6..c2cc99a83f09 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hal.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hal.c
@@ -50,6 +50,13 @@ static const struct ath12k_hw_version_map ath12k_wifi7_hw_ver_map[] = {
.hal_params = &ath12k_hw_hal_params_wcn7850,
.hw_regs = &qcc2072_regs,
},
+ [ATH12K_HW_IPQ5424_HW10] = {
+ .hal_ops = &hal_qcn9274_ops,
+ .hal_desc_sz = sizeof(struct hal_rx_desc_qcn9274_compact),
+ .tcl_to_wbm_rbm_map = ath12k_hal_tcl_to_wbm_rbm_map_qcn9274,
+ .hal_params = &ath12k_hw_hal_params_ipq5332,
+ .hw_regs = NULL,
+ },
};
int ath12k_wifi7_hal_init(struct ath12k_base *ab)
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next v4 2/6] wifi: ath12k: Add ath12k_hw_params for IPQ5424
From: Raj Kumar Bhagat @ 2026-04-02 3:54 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Raj Kumar Bhagat, Saravanakumar Duraisamy
In-Reply-To: <20260402-ath12k-ipq5424-v4-0-cd1e0f0a6c88@oss.qualcomm.com>
From: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
Add ath12k_hw_params for the ath12k AHB-based WiFi 7 device IPQ5424.
The WiFi device IPQ5424 is similar to IPQ5332. Most of the hardware
parameters like hw_ops, wmi_init, ring_mask, etc., are the same between
IPQ5424 and IPQ5332, hence use these same parameters for IPQ5424.
Some parameters are specific to IPQ5424; initially set these to
0 or NULL, and populate them in subsequent patches.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01243-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5332 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Tested-on: IPQ5424 hw1.0 AHB WLAN.WBE.1.6-01275-QCAHKSWPL_SILICONZ-1
Signed-off-by: Saravanakumar Duraisamy <quic_saradura@quicinc.com>
Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
---
drivers/net/wireless/ath/ath12k/core.h | 1 +
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 75 ++++++++++++++++++++++++++++++
2 files changed, 76 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
index 59c193b24764..68453594eba8 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -157,6 +157,7 @@ enum ath12k_hw_rev {
ATH12K_HW_WCN7850_HW20,
ATH12K_HW_IPQ5332_HW10,
ATH12K_HW_QCC2072_HW10,
+ ATH12K_HW_IPQ5424_HW10,
};
enum ath12k_firmware_mode {
diff --git a/drivers/net/wireless/ath/ath12k/wifi7/hw.c b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
index ec6dba96640b..9b9ca06a9f45 100644
--- a/drivers/net/wireless/ath/ath12k/wifi7/hw.c
+++ b/drivers/net/wireless/ath/ath12k/wifi7/hw.c
@@ -753,6 +753,81 @@ static const struct ath12k_hw_params ath12k_wifi7_hw_params[] = {
.dp_primary_link_only = false,
},
+ {
+ .name = "ipq5424 hw1.0",
+ .hw_rev = ATH12K_HW_IPQ5424_HW10,
+ .fw = {
+ .dir = "IPQ5424/hw1.0",
+ .board_size = 256 * 1024,
+ .cal_offset = 128 * 1024,
+ .m3_loader = ath12k_m3_fw_loader_remoteproc,
+ .download_aux_ucode = false,
+ },
+ .max_radios = 1,
+ .single_pdev_only = false,
+ .qmi_service_ins_id = ATH12K_QMI_WLFW_SERVICE_INS_ID_V01_IPQ5332,
+ .internal_sleep_clock = false,
+
+ .hw_ops = &qcn9274_ops,
+ .ring_mask = &ath12k_wifi7_hw_ring_mask_ipq5332,
+
+ .host_ce_config = ath12k_wifi7_host_ce_config_ipq5332,
+ .ce_count = 12,
+ .target_ce_config = ath12k_wifi7_target_ce_config_wlan_ipq5332,
+ .target_ce_count = 12,
+ .svc_to_ce_map =
+ ath12k_wifi7_target_service_to_ce_map_wlan_ipq5332,
+ .svc_to_ce_map_len = 18,
+
+ .rxdma1_enable = true,
+ .num_rxdma_per_pdev = 1,
+ .num_rxdma_dst_ring = 0,
+ .rx_mac_buf_ring = false,
+ .vdev_start_delay = false,
+
+ .interface_modes = BIT(NL80211_IFTYPE_STATION) |
+ BIT(NL80211_IFTYPE_AP) |
+ BIT(NL80211_IFTYPE_MESH_POINT),
+ .supports_monitor = true,
+
+ .idle_ps = false,
+ .download_calib = true,
+ .supports_suspend = false,
+ .tcl_ring_retry = true,
+ .reoq_lut_support = false,
+ .supports_shadow_regs = false,
+
+ .num_tcl_banks = 48,
+ .max_tx_ring = 4,
+
+ .wmi_init = &ath12k_wifi7_wmi_init_qcn9274,
+
+ .qmi_cnss_feature_bitmap = BIT(CNSS_QDSS_CFG_MISS_V01),
+
+ .rfkill_pin = 0,
+ .rfkill_cfg = 0,
+ .rfkill_on_level = 0,
+
+ .rddm_size = 0,
+
+ .def_num_link = 0,
+ .max_mlo_peer = 256,
+
+ .otp_board_id_register = 0,
+
+ .supports_sta_ps = false,
+
+ .acpi_guid = NULL,
+ .supports_dynamic_smps_6ghz = false,
+ .iova_mask = 0,
+ .supports_aspm = false,
+
+ .ce_ie_addr = NULL,
+ .ce_remap = NULL,
+ .bdf_addr_offset = 0x940000,
+
+ .dp_primary_link_only = true,
+ },
};
/* Note: called under rcu_read_lock() */
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next v4 1/6] dt-bindings: net: wireless: add ath12k wifi device IPQ5424
From: Raj Kumar Bhagat @ 2026-04-02 3:53 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Raj Kumar Bhagat, Krzysztof Kozlowski
In-Reply-To: <20260402-ath12k-ipq5424-v4-0-cd1e0f0a6c88@oss.qualcomm.com>
Add the device-tree bindings for the ATH12K AHB wifi device IPQ5424.
Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
index 363a0ecb6ad9..37d8a0da7780 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ipq5332-wifi.yaml
@@ -17,6 +17,7 @@ properties:
compatible:
enum:
- qcom,ipq5332-wifi
+ - qcom,ipq5424-wifi
reg:
maxItems: 1
--
2.34.1
^ permalink raw reply related
* [PATCH ath-next v4 0/6] wifi: ath12k: Enable IPQ5424 AHB WiFi device
From: Raj Kumar Bhagat @ 2026-04-02 3:53 UTC (permalink / raw)
To: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson
Cc: linux-wireless, devicetree, linux-kernel, ath12k,
Raj Kumar Bhagat, Saravanakumar Duraisamy,
Sowmiya Sree Elavalagan, Krzysztof Kozlowski
Add support for the new ath12k AHB device IPQ5424, as currently, Ath12k
AHB only supports IPQ5332 WiFi devices.
The IPQ5424 is an IEEE 802.11be 2 GHz WiFi device, supporting 4x4
configurations. To enable the IPQ5424 device:
- Add the necessary hardware parameters for IPQ5424.
- Modify the boot-up sequence for ath12k AHB to accommodate the
requirements of the IPQ5424 device.
---
Changes in v4:
- DT binding: dropped copyright update as per discussion in v3.
- DT binding: Used DT binding from v2 and retained Acked-by tag.
- Link to v3: https://patch.msgid.link/20260331-ath12k-ipq5424-v3-0-1455b9cae29c@oss.qualcomm.com
Changes in v3:
- DT binding: updated copyright.
- DT binding: Dropped Acked-by tag as copyright is updated.
- Rebased on latest ToT.
- Dropped ath12k_ahb_ops because qcom_mdt_load() and
qcom_mdt_load_no_init() now have different number of arguments.
- Link to v2: https://lore.kernel.org/all/20250518-ath12k-ipq5424-v2-0-ef81b833dc97@quicinc.com/
Changes in v2:
- DT binding: Removed the redundant example for IPQ5424, as it is similar
to IPQ5332.
- Added driver probe data structure to eliminate the redundant switch-case
logic in the ath12k_ahb_probe() function.
- Validation completed, hence changed from RFC to PATCH.
- Link to v1: https://lore.kernel.org/all/20250130051838.1924079-1-quic_rajkbhag@quicinc.com/
Signed-off-by: Raj Kumar Bhagat <raj.bhagat@oss.qualcomm.com>
---
Raj Kumar Bhagat (2):
dt-bindings: net: wireless: add ath12k wifi device IPQ5424
wifi: ath12k: add ath12k_hw_version_map entry for IPQ5424
Saravanakumar Duraisamy (3):
wifi: ath12k: Add ath12k_hw_params for IPQ5424
wifi: ath12k: add ath12k_hw_regs for IPQ5424
wifi: ath12k: Add CE remap hardware parameters for IPQ5424
Sowmiya Sree Elavalagan (1):
wifi: ath12k: Enable IPQ5424 WiFi device support
.../bindings/net/wireless/qcom,ipq5332-wifi.yaml | 1 +
drivers/net/wireless/ath/ath12k/ahb.c | 36 +++++----
drivers/net/wireless/ath/ath12k/ahb.h | 1 +
drivers/net/wireless/ath/ath12k/ce.h | 13 ++-
drivers/net/wireless/ath/ath12k/core.h | 1 +
drivers/net/wireless/ath/ath12k/wifi7/ahb.c | 8 ++
drivers/net/wireless/ath/ath12k/wifi7/hal.c | 7 ++
drivers/net/wireless/ath/ath12k/wifi7/hal.h | 3 +
.../net/wireless/ath/ath12k/wifi7/hal_qcn9274.c | 88 ++++++++++++++++++++
.../net/wireless/ath/ath12k/wifi7/hal_qcn9274.h | 1 +
drivers/net/wireless/ath/ath12k/wifi7/hw.c | 93 +++++++++++++++++++++-
11 files changed, 231 insertions(+), 21 deletions(-)
---
base-commit: 15551ababf6d4e857f2101366a0c3eaa86dd822c
change-id: 20260331-ath12k-ipq5424-cddb63a46a97
^ permalink raw reply
* Re: [PATCH v2 03/10] drm/mxsfb/lcdif: use dev_err_probe() consistently in lcdif_attach_bridge
From: Liu Ying @ 2026-04-02 3:52 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-3-c7f2af536a24@bootlin.com>
On Mon, Mar 30, 2026 at 09:25:44PM +0200, Luca Ceresoli wrote:
> lcdif_attach_bridge() uses dev_err_probe() in some error paths, dev_err() +
> return in others. Use dev_err_probe() for all of them to make code
> consistent, simpler and with bettere error reporting.
s/bettere/better/
Reviewed-by: Liu Ying <victor.liu@nxp.com>
--
Regards,
Liu Ying
^ permalink raw reply
* Re: [PATCH v2 02/10] drm/mxsfb/lcdif: simplify ep pointer management using __free
From: Liu Ying @ 2026-04-02 3:50 UTC (permalink / raw)
To: Luca Ceresoli, Marek Vasut, Stefan Agner, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Rob Herring, Saravana Kannan
Cc: Damon Ding, Kory Maincent (TI.com), Hervé Codina, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, imx, linux-arm-kernel,
linux-kernel, devicetree, Adam Ford, Alexander Stein,
Christopher Obbard, Daniel Scally, Emanuele Ghidoli,
Fabio Estevam, Francesco Dolcini, Frieder Schrempf, Gilles Talis,
Goran Rađenović, Heiko Schocher, Josua Mayer,
Kieran Bingham, Marco Felsch, Martyn Welch, Oleksij Rempel,
Peng Fan, Richard Hu, Shengjiu Wang, Stefan Eichenberger,
Vitor Soares
In-Reply-To: <20260330-drm-lcdif-dbanc-v2-2-c7f2af536a24@bootlin.com>
On Mon, Mar 30, 2026 at 09:25:43PM +0200, Luca Ceresoli wrote:
> Putting the ep device_node reference requires a of_node_put(ep) in many
> return points. Use a cleanup action to simplify the code.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
>
> ---
>
> This patch is new in v2
> ---
> drivers/gpu/drm/mxsfb/lcdif_drv.c | 13 +++----------
> 1 file changed, 3 insertions(+), 10 deletions(-)
Reviewed-by: Liu Ying <victor.liu@nxp.com>
^ permalink raw reply
* Re: [PATCH net-next v2 4/4] net: dsa: initial support for MT7628 embedded switch
From: Jakub Kicinski @ 2026-04-02 3:31 UTC (permalink / raw)
To: joey
Cc: Jakub Kicinski, netdev, horms, pabeni, edumazet, davem, olteanv,
andrew, devicetree, robh, krzk+dt, conor+dt
In-Reply-To: <20260330184017.766200-5-joey@tinyisr.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: dsa: initial support for MT7628 embedded switch
Add support for the MT7628 embedded switch.
The switch has 5 built-in 100Mbps user ports (ports 0-4) and one 1Gbps
port that is internally attached to the SoCs CPU MAC and serves as the
CPU port.
> diff --git a/drivers/net/dsa/Kconfig b/drivers/net/dsa/Kconfig
> --- a/drivers/net/dsa/Kconfig
> +++ b/drivers/net/dsa/Kconfig
> @@ -28,6 +28,14 @@ source "drivers/net/dsa/hirschmann/Kconfig"
>
> source "drivers/net/dsa/lantiq/Kconfig"
>
> +config NET_DSA_MT7628
> + tristate "MediaTek MT7628 Embedded Ethernet switch support"
> + select NET_DSA_TAG_MT7628
> + select MEDIATEK_FE_SOC_PHY
Does this configuration need to select NET_DSA_TAG_8021Q?
The driver relies on the tag_8021q mechanism for switch port isolation. If
the kernel is configured without NET_DSA_TAG_8021Q, dsa_tag_8021q_register()
will return -EOPNOTSUPP, causing the switch to boot with broken port
isolation.
> + help
> + This enables support for the built-in Ethernet switch found
> + in the MT7628 SoC.
> +
[ ... ]
> diff --git a/drivers/net/dsa/mt7628.c b/drivers/net/dsa/mt7628.c
> --- /dev/null
> +++ b/drivers/net/dsa/mt7628.c
[ ... ]
> +static int mt7628_mii_read(struct mii_bus *bus, int port, int regnum)
> +{
> + struct mt7628_esw *esw = bus->priv;
> + int ret;
> + u32 val;
> +
> + ret = regmap_read_poll_timeout(esw->regmap, MT7628_ESW_REG_PCR1, val,
> + !(val & MT7628_ESW_PCR1_RD_DONE), 10,
> + 5000);
Will this polling logic cause an MDIO timeout?
If RD_DONE is a completion status bit that remains 1 after a successful
operation, this first poll will wait indefinitely for the bit to become 0.
If RD_DONE is an active-low busy bit, the second poll below waits for the
controller to become busy instead of waiting for it to be idle.
> + if (ret)
> + goto out;
> +
> + ret = regmap_write(esw->regmap, MT7628_ESW_REG_PCR0,
> + FIELD_PREP(MT7628_ESW_PCR0_CPU_PHY_REG,
> + regnum) |
> + FIELD_PREP(MT7628_ESW_PCR0_CPU_PHY_ADDR,
> + port) | MT7628_ESW_PCR0_RD_PHY_CMD);
> + if (ret)
> + goto out;
> +
> + ret = regmap_read_poll_timeout(esw->regmap, MT7628_ESW_REG_PCR1, val,
> + (val & MT7628_ESW_PCR1_RD_DONE), 10,
> + 5000);
> +out:
> + if (ret) {
> + dev_err(&bus->dev, "read failed. MDIO timeout?\n");
> + return ret;
> + }
> + return FIELD_GET(MT7628_ESW_PCR1_RD_DATA, val);
> +}
> +
> +static int mt7628_mii_write(struct mii_bus *bus, int port, int regnum, u16 dat)
> +{
> + struct mt7628_esw *esw = bus->priv;
> + u32 val;
> + int ret;
> +
> + ret = regmap_read_poll_timeout(esw->regmap, MT7628_ESW_REG_PCR1, val,
> + !(val & MT7628_ESW_PCR1_WT_DONE), 10,
> + 5000);
> + if (ret)
> + goto out;
> +
> + ret = regmap_write(esw->regmap, MT7628_ESW_REG_PCR0,
> + FIELD_PREP(MT7628_ESW_PCR0_WT_NWAY_DATA, dat) |
> + FIELD_PREP(MT7628_ESW_PCR0_CPU_PHY_REG,
> + regnum) |
> + FIELD_PREP(MT7628_ESW_PCR0_CPU_PHY_ADDR,
> + port) | MT7628_ESW_PCR0_WT_PHY_CMD);
> + if (ret)
> + goto out;
> +
> + ret = regmap_read_poll_timeout(esw->regmap, MT7628_ESW_REG_PCR1, val,
> + (val & MT7628_ESW_PCR1_WT_DONE), 10,
> + 5000);
Is this second poll waiting for the controller to become busy instead of
idle, similar to the read function?
> +out:
> + if (ret) {
> + dev_err(&bus->dev, "write failed. MDIO timeout?\n");
> + return ret;
> + }
> + return 0;
> +}
> +
> +static int mt7628_setup_internal_mdio(struct dsa_switch *ds)
> +{
> + struct mt7628_esw *esw = ds->priv;
> + struct device_node *mdio;
> + struct mii_bus *bus;
> + int ret = 0;
> +
> + mdio = of_get_available_child_by_name(ds->dev->of_node, "mdio");
> +
> + bus = devm_mdiobus_alloc(esw->dev);
Can allocating devm_ resources in the DSA .setup callback cause a sysfs name
collision?
The .setup callback is executed whenever the DSA tree binds. Since devm_
resources are tied to the platform device (esw->dev) rather than the DSA
tree lifecycle, they are not released when the DSA tree unbinds. On a
subsequent re-bind, allocating a new MDIO bus with the same ID will fail
because the original bus was never unregistered.
> + if (!bus) {
> + ret = -ENOMEM;
> + goto out_put_node;
> + }
> +
> + bus->name = "MT7628 internal MDIO bus";
> + snprintf(bus->id, MII_BUS_ID_SIZE, "%s-mii", dev_name(ds->dev));
> + bus->priv = esw;
> + bus->read = mt7628_mii_read;
> + bus->write = mt7628_mii_write;
> + bus->parent = esw->dev;
> + if (!mdio) {
> + ds->user_mii_bus = bus;
> + bus->phy_mask = ~ds->phys_mii_mask;
> + }
> +
> + ret = devm_of_mdiobus_register(esw->dev, bus, mdio);
> +
> +out_put_node:
> + of_node_put(mdio);
> + return ret;
> +}
[ ... ]
> +static int mt7628_setup(struct dsa_switch *ds)
> +{
> + struct mt7628_esw *esw = ds->priv;
> + int ret;
> +
> + reset_control_reset(esw->rst_esw);
> + usleep_range(1000, 2000);
> + reset_control_reset(esw->rst_ephy);
> + usleep_range(1000, 2000);
> + /*
> + * all MMIO reads hang if esw is not out of reset
> + * ephy needs extra time to get out of reset or it ends up misconfigured
> + */
> + mt7628_switch_init(ds);
> + rtnl_lock();
> + dsa_tag_8021q_register(ds, htons(ETH_P_8021Q));
Is it safe to ignore the return value of dsa_tag_8021q_register()?
If the registration fails, the core function frees the allocated context but
does not clear ds->tag_8021q_ctx. The setup will continue, and the DSA core
will later dereference the non-NULL ds->tag_8021q_ctx, leading to a
use-after-free crash.
Also, if mt7628_setup_internal_mdio() below fails, the setup returns an
error without unregistering the tagger, which leaks the tag_8021q context.
> + rtnl_unlock();
> +
> + ret = mt7628_setup_internal_mdio(ds);
> + return ret;
> +}
[ ... ]
> +static struct dsa_switch_ops mt7628_switch_ops = {
> + .get_tag_protocol = mt7628_get_tag_proto,
> + .setup = mt7628_setup,
Does this switch ops structure need a .teardown callback?
Without calling dsa_tag_8021q_unregister() in a .teardown callback, the
tag_8021q context memory allocated during .setup will be permanently leaked
whenever the DSA switch is unbound or the module is removed.
> + .port_enable = mt7628_port_enable,
> + .port_disable = mt7628_port_disable,
> + .phylink_get_caps = mt7628_phylink_get_caps,
> + .tag_8021q_vlan_add = mt7628_dsa_8021q_vlan_add,
> + .tag_8021q_vlan_del = mt7628_dsa_8021q_vlan_del,
> +};
--
pw-bot: cr
^ 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