* Re: [PATCH v3 4/7] drm/rcar-du: dsi: Support DSC in the pipeline
From: Laurent Pinchart @ 2026-06-12 15:53 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <11f27d38-0224-4fce-a975-7c3f7d8d1d38@ideasonboard.com>
On Fri, Jun 12, 2026 at 02:56:11PM +0300, Tomi Valkeinen wrote:
> On 11/06/2026 03:03, Laurent Pinchart wrote:
> > On Fri, May 15, 2026 at 12:09:29PM +0300, Tomi Valkeinen wrote:
> >> Enabling DSI clocks on rcar-du needs some tricks as the DU dot clock is
> >> provided by the DSI. Thus, we call rcar_mipi_dsi_pclk_enable() from the
> >> crtc, when enabling the crtc.
> >>
> >> With DSC (added in upcoming patch) in the pipeline, between the DU and
> >> the DSI, the above call path is broken as the crtc tries to call
> >> rcar_mipi_dsi_pclk_enable() on the DSC.
> >>
> >> Adjust the rcar_mipi_dsi_pclk_enable() so that it detects the DSC, and
> >> in that case gets the next bridge from the DSC, which is the DSI.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >> drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 36 +++++++++++++++++++++++--
> >> 1 file changed, 34 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> >> index 4ef2e3c129ed..085e229bcb0b 100644
> >> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> >> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> >> @@ -88,6 +88,8 @@ struct dsi_setup_info {
> >> const struct dsi_clk_config *clkset;
> >> };
> >>
> >> +static const struct drm_bridge_funcs rcar_mipi_dsi_bridge_ops;
> >> +
> >> static inline struct rcar_mipi_dsi *
> >> bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge)
> >> {
> >> @@ -844,15 +846,39 @@ static void rcar_mipi_dsi_atomic_disable(struct drm_bridge *bridge,
> >> rcar_mipi_dsi_stop_video(dsi);
> >> }
> >>
> >> +/*
> >> + * We need to skip the DSC bridge when we have DSC in between the DU and
> >> + * the DSI. We detect the DSI bridge via bridge->funcs, and assume the
> >> + * next_bridge is the DSI bridge. If this is not the case, the DT data
> >> + * is wrong (so it shouldn't really happen).
> >> + */
> >> +static struct drm_bridge *
> >> +rcar_mipi_dsi_resolve_bridge(struct drm_bridge *bridge)
> >> +{
> >> + if (bridge->funcs != &rcar_mipi_dsi_bridge_ops)
> >> + bridge = bridge->next_bridge;
> >> +
> >> + if (!bridge || bridge->funcs != &rcar_mipi_dsi_bridge_ops)
> >> + return NULL;
> >> +
> >> + return bridge;
> >> +}
> >
> > Hmmmm... It's quite a bit of a hack. It would be nicer to do this in
> > rcar_du_crtc.c instead, where we cache the dsi bridge pointer. The
>
> It's actually cached in rcar_du_encoder.c, but used in rcar_du_crtc.c.
>
> If I understand right, you'd like to do the DSC detection in
> rcar_du_crtc, and skip the DSC, if needed, before calling
> rcar_mipi_dsi_pclk_enable()?
That would be the idea, yes. Knowledge that there's a DSC in the
pipeline would be in the DU driver, not the DSI driver. I think it would
be better, as the DU driver is the one that should have an overall view
of the display pipeline.
> > question is how to then identify the right bridge, as we won't have
> > access to rcar_mipi_dsi_bridge_ops. Should this driver set the bridge
> > type field to DRM_MODE_CONNECTOR_DSI ?
>
> I'm not sure how that would help. Or, I can, as the dsi driver does not
> set the bridge type, so only DSC would set it. But isn't that even more
> hacky?
>
> Or did you rather mean that the DSI driver would set the bridge type,
> and DSC would not? We can then do:
>
> if (bridge->type != DRM_MODE_CONNECTOR_DSI)
> bridge = bridge->next_bridge;
Yes that's what I meant.
> in the crtc driver. This works. It's still a bit hacky, but I think the
> chances of the code getting it wrong are quite low. If the output port
> is RCAR_DU_OUTPUT_DSIx, then the next bridge must be rcar-dsi or
> rcar-dsc, so it's all under our control. Also, it's less code than this
> patch, so I'll go with that.
Thanks.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: spi: nuvoton,ma35d1-qspi: Add Nuvoton MA35D1 QSPI
From: Conor Dooley @ 2026-06-12 15:48 UTC (permalink / raw)
To: Chi-Wen Weng
Cc: broonie, robh, krzk+dt, conor+dt, linux-arm-kernel, linux-spi,
devicetree, linux-kernel, cwweng
In-Reply-To: <0031379c-0cc3-40c8-8145-5b1991b42f05@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3574 bytes --]
On Fri, Jun 12, 2026 at 08:33:01AM +0800, Chi-Wen Weng wrote:
> Hi Conor,
>
> Thanks for the review.
>
> I will add a default value for num-cs in v4:
>
> num-cs:
> maximum: 2
> default: 2
>
> The controller has two native chip selects and the driver currently uses
> that hardware default.
The driver should handle the property and fall back to the default.
It's not complex to support, so surely there's no reason not to?
Cheers,
Conor.
>
> Best regards,
> Chi-Wen
>
> Conor Dooley 於 2026/6/12 上午 01:34 寫道:
> > On Thu, Jun 11, 2026 at 05:12:45PM +0800, Chi-Wen Weng wrote:
> > > From: Chi-Wen Weng <cwweng@nuvoton.com>
> > >
> > > Add a devicetree binding for the Quad SPI controller found in
> > > Nuvoton MA35D1 SoCs.
> > >
> > > The controller supports SPI memory devices such as SPI NOR and SPI NAND
> > > flashes. It has one register range, one clock input and one reset line,
> > > and supports up to two chip selects.
> > >
> > > Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
> > > ---
> > > .../bindings/spi/nuvoton,ma35d1-qspi.yaml | 62 +++++++++++++++++++
> > > 1 file changed, 62 insertions(+)
> > > create mode 100644 Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
> > > new file mode 100644
> > > index 000000000000..d3b36e612eb0
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
> > > @@ -0,0 +1,62 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/spi/nuvoton,ma35d1-qspi.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Nuvoton MA35D1 Quad SPI Controller
> > > +
> > > +maintainers:
> > > + - Chi-Wen Weng <cwweng@nuvoton.com>
> > > +
> > > +allOf:
> > > + - $ref: /schemas/spi/spi-controller.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + const: nuvoton,ma35d1-qspi
> > > +
> > > + reg:
> > > + maxItems: 1
> > > +
> > > + interrupts:
> > > + maxItems: 1
> > > +
> > > + clocks:
> > > + maxItems: 1
> > > +
> > > + resets:
> > > + maxItems: 1
> > > +
> > > + num-cs:
> > > + maximum: 2
> > Missing a default of 2, unless you make the property required.
> > FWIW, your driver doesn't appear to read this value.
> >
> > pw-bot: changes-requested
> >
> > Cheers,
> > Conor.
> >
> > > +
> > > +required:
> > > + - compatible
> > > + - reg
> > > + - clocks
> > > + - resets
> > > +
> > > +unevaluatedProperties: false
> > > +
> > > +examples:
> > > + - |
> > > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
> > > + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
> > > +
> > > + soc {
> > > + #address-cells = <2>;
> > > + #size-cells = <2>;
> > > +
> > > + spi@40680000 {
> > > + compatible = "nuvoton,ma35d1-qspi";
> > > + reg = <0 0x40680000 0 0x100>;
> > > + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&clk QSPI0_GATE>;
> > > + resets = <&sys MA35D1_RESET_QSPI0>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + };
> > > + };
> > > +
> > > --
> > > 2.25.1
> > >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/7] dt-bindings: bluetooth: qcom,wcn6750-bt: Document WCN6755 Bluetooth
From: Luiz Augusto von Dentz @ 2026-06-12 15:46 UTC (permalink / raw)
To: Luca Weiss
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexander Koskovich, Liam Girdwood, Mark Brown,
Bartosz Golaszewski, Marcel Holtmann, Balakrishna Godavarthi,
Rocky Liao, Johannes Berg, Jeff Johnson,
~postmarketos/upstreaming, phone-devel, linux-arm-msm,
linux-kernel, devicetree, linux-bluetooth, linux-wireless, ath11k
In-Reply-To: <DJ757RE8OYHO.2XEXNTLVIJ497@fairphone.com>
Hi Luca,
On Fri, Jun 12, 2026 at 11:33 AM Luca Weiss <luca.weiss@fairphone.com> wrote:
>
> Hi Luiz,
>
> On Fri Apr 3, 2026 at 3:52 PM CEST, Luca Weiss wrote:
> > Document the WCN6755 Bluetooth using a fallback to WCN6750 since the two
> > chips seem to be completely pin and software compatible. In fact the
> > original downstream kernel just pretends the WCN6755 is a WCN6750.
>
> Could you please pick up this patch (or provide an Ack if you want Bjorn
> to pick this up with the rest of the series).
>
> Regards
> Luca
>
> >
> > Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> > ---
> > .../devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml | 10 ++++++++--
> > 1 file changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml b/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml
> > index 8606a45ac9b9..79522409d709 100644
> > --- a/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml
> > +++ b/Documentation/devicetree/bindings/net/bluetooth/qcom,wcn6750-bt.yaml
> > @@ -12,8 +12,14 @@ maintainers:
> >
> > properties:
> > compatible:
> > - enum:
> > - - qcom,wcn6750-bt
> > + oneOf:
> > + - items:
> > + - enum:
> > + - qcom,wcn6755-bt
> > + - const: qcom,wcn6750-bt
> > +
> > + - enum:
> > + - qcom,wcn6750-bt
> >
> > enable-gpios:
> > maxItems: 1
>
Acked-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] dt-bindings: cache: l2c2x0: Add missing power-domains
From: Conor Dooley @ 2026-06-12 15:45 UTC (permalink / raw)
To: Rob Herring (Arm)
Cc: Geert Uytterhoeven, Krzysztof Kozlowski, devicetree,
linux-renesas-soc, Jonathan Cameron
In-Reply-To: <178127350175.916476.16317522760209240659.robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
On Fri, Jun 12, 2026 at 09:11:42AM -0500, Rob Herring (Arm) wrote:
>
> On Wed, 10 Jun 2026 17:29:20 +0200, Geert Uytterhoeven wrote:
> > On Renesas SH-Mobile and R-Mobile SoCs, the ARM PL310 L2 Cache
> > Controller is located in a controllable power area.
> >
> > Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> > ---
> > This fixes "make dtbs_check":
> >
> > arch/arm/boot/dts/renesas/r8a7740-armadillo800eva.dtb: cache-controller@f0100000 (arm,pl310-cache): 'power-domains' does not match any of the regexes: '^pinctrl-[0-9]+$'
> > from schema $id: http://devicetree.org/schemas/cache/l2c2x0.yaml
> > arch/arm/boot/dts/renesas/sh73a0-kzm9g.dtb: cache-controller@f0100000 (arm,pl310-cache): 'power-domains' does not match any of the regexes: '^pinctrl-[0-9]+$'
> > from schema $id: http://devicetree.org/schemas/cache/l2c2x0.yaml
> > ---
> > Documentation/devicetree/bindings/cache/l2c2x0.yaml | 3 +++
> > 1 file changed, 3 insertions(+)
> >
>
> Applied, thanks!
Thanks Rob, was at an awkward time for me and would've probably sat til
rc1.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 phy-next 7/8] soc: fsl: guts: implement the RCW override procedure
From: Conor Dooley @ 2026-06-12 15:44 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, devicetree, linuxppc-dev, linux-arm-kernel,
Ioana Ciornei, Vinod Koul, Neil Armstrong, Tanjeff Moos,
Christophe Leroy (CS GROUP), Michael Walle, Shawn Guo, Frank Li,
linux-kernel, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260611193940.44416-8-vladimir.oltean@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 15588 bytes --]
On Thu, Jun 11, 2026 at 10:39:39PM +0300, Vladimir Oltean wrote:
> From: Ioana Ciornei <ioana.ciornei@nxp.com>
>
> Add support for the RCW override procedure which enables runtime
> reconfiguration of the protocol running on a SerDes lane. The procedure
> is done through the DCFG DCSR space which now can be defined as the
> second memory region of the guts DT node.
> Support is added on the following SoCs: LS1046A, LS1088A, LS2088A.
>
> The procedure is exported to the "client" driver - the Lynx10G SerDes
> PHY driver - through the following functions:
> - fsl_guts_lane_init() used to notify the initial / boot time lane mode
> running on a SerDes lane.
> - fsl_guts_lane_validate() used to validate that changing the protocol
> on a specific lane is supported.
> - fsl_guts_lane_set_mode() which can be used to request the RCW
> procedure be executed for a specific lane.
>
> Since the RCW override procedure is different depending on the SoC, the
> private fsl_soc_data structure is updated with two new per SoC callbacks
> (.serdes_get_rcw_override() and .serdes_init_rcwcr()) which get used
> from the generic fsl_guts_lane_set_mode() function. These two callbacks
> hide all the SoC specific register offsets, masks and values so that the
> _set_mode() procedure is straightforward.
>
> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> Cc: Conor Dooley <conor@kernel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
Wrong CC list for this specific patch?
ta,
Conor.
> ---
> drivers/soc/fsl/guts.c | 286 ++++++++++++++++++++++++++++++++++++++-
> include/linux/fsl/guts.h | 20 ++-
> 2 files changed, 299 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/soc/fsl/guts.c b/drivers/soc/fsl/guts.c
> index 9f2aff07a274..23ec5750080c 100644
> --- a/drivers/soc/fsl/guts.c
> +++ b/drivers/soc/fsl/guts.c
> @@ -15,6 +15,30 @@
> #include <linux/fsl/guts.h>
>
> #define DCFG_CCSR 0
> +#define DCFG_DCSR 1
> +
> +#define MAX_NUM_LANES 8
> +#define MAX_NUM_SERDES 2
> +
> +#define LS1088A_RCWSR29_SRDS_PRTCL_S1_LNn(lane) \
> + GENMASK(19 + 4 * (3 - lane), 16 + 4 * (3 - lane))
> +#define LS1088A_RCWSR30_SRDS_PRTCL_S2_LNn(lane) \
> + GENMASK(3 + 4 * (3 - lane), 4 * (3 - lane))
> +
> +#define LS1046A_RCWSR5_SRDS_PRTCL_S1(lane) \
> + GENMASK(19 + 4 * (lane), 16 + 4 * (lane))
> +#define SRDS_PRTCL_NONE 0
> +#define SRDS_PRTCL_XFI 1
> +#define SRDS_PRTCL_2500BASEX 2
> +#define SRDS_PRTCL_100BASEX_SGMII 3
> +#define SRDS_PRTCL_QSGMII 4
> +#define SRDS_PRTCL_PCIE 5
> +
> +#define LS2088A_RCWSR30_SRDS_CLK_EN_SEL_XGMII_S1 BIT(14)
> +#define LS2088A_RCWSR30_SRDS_CLK_SEL_XGMII_Ln_S1(lane) BIT(6 + (7 - (lane)))
> +#define LS2088A_RCWSR30_SRDS_CLK_SEL_MSK GENMASK(13, 6)
> +#define SRDS_CLK_SEL_XGMII 1
> +#define SRDS_CLK_SEL_GMII 0
>
> struct fsl_soc_die_attr {
> char *die;
> @@ -22,9 +46,19 @@ struct fsl_soc_die_attr {
> u32 mask;
> };
>
> +struct fsl_soc_serdes_rcw_override {
> + int offset;
> + int mask;
> + int val;
> +};
> +
> struct fsl_soc_data {
> const char *sfp_compat;
> u32 uid_offset;
> + int (*serdes_get_rcw_override)(int index, int lane,
> + enum lynx_lane_mode lane_mode,
> + struct fsl_soc_serdes_rcw_override *override);
> + void (*serdes_init_rcwcr)(int index);
> };
>
> enum qoriq_die {
> @@ -138,9 +172,13 @@ static const struct fsl_soc_die_attr fsl_soc_die[] = {
>
> static struct fsl_soc_guts {
> struct ccsr_guts __iomem *dcfg_ccsr;
> + struct ccsr_guts __iomem *dcfg_dcsr;
> const struct fsl_soc_data *data;
> bool little_endian;
> u32 svr;
> + enum lynx_lane_mode lane_mode[MAX_NUM_SERDES][MAX_NUM_LANES];
> + bool rcwcr_init_done;
> + spinlock_t rcwcr_lock; /* serializes concurrent writes to the RCWCR */
> } soc;
>
> static unsigned int fsl_guts_read(const void __iomem *reg)
> @@ -151,6 +189,28 @@ static unsigned int fsl_guts_read(const void __iomem *reg)
> return ioread32be(reg);
> }
>
> +static void fsl_guts_write(void __iomem *reg, u32 val)
> +{
> + if (soc.little_endian)
> + iowrite32(val, reg);
> + else
> + iowrite32be(val, reg);
> +}
> +
> +/* Some fields of the Reset Configuration Word (RCW) can be overridden at
> + * runtime by writing to the RCWCRn registers contained within the DCSR space
> + * of the Device Configuration (DCFG) block. The layout of the RCWCRn registers
> + * is identical with the read-only RCWSRn from the CCSR space.
> + */
> +static void fsl_guts_rmw(int offset, u32 val, u32 mask)
> +{
> + u32 tmp = fsl_guts_read(&soc.dcfg_ccsr->rcwsr[offset]);
> +
> + tmp &= ~mask;
> + tmp |= val;
> + fsl_guts_write(&soc.dcfg_dcsr->rcwcr[offset], tmp);
> +}
> +
> static bool fsl_soc_die_match_one(u32 svr, const struct fsl_soc_die_attr *match)
> {
> return match->svr == (svr & match->mask);
> @@ -167,6 +227,97 @@ static const struct fsl_soc_die_attr *fsl_soc_die_match(
> return NULL;
> }
>
> +static int
> +fsl_guts_serdes_get_rcw_override(int serdes_idx, int lane,
> + enum lynx_lane_mode lane_mode,
> + struct fsl_soc_serdes_rcw_override *override)
> +{
> + if ((!fsl_soc_die_match_one(soc.svr, &fsl_soc_die[DIE_LS1088A]) &&
> + !fsl_soc_die_match_one(soc.svr, &fsl_soc_die[DIE_LS2088A]) &&
> + !fsl_soc_die_match_one(soc.svr, &fsl_soc_die[DIE_LS1046A])) ||
> + !soc.data || !soc.data->serdes_get_rcw_override) {
> + pr_debug("RCW override not implemented for SoC\n");
> + return -EINVAL;
> + }
> +
> + if (!soc.dcfg_dcsr) {
> + pr_debug("Device tree does not define DCFG_DCSR region necessary for RCW override\n");
> + return -EINVAL;
> + }
> +
> + return soc.data->serdes_get_rcw_override(serdes_idx, lane, lane_mode,
> + override);
> +}
> +
> +/**
> + * fsl_guts_lane_init() - Notify guts module of SerDes lane configuration
> + * @serdes_idx: zero-based SerDes block index
> + * @lane: zero-based lane index within SerDes
> + * @lane_mode: initial / boot time SerDes protocol for lane
> + *
> + * On the LS208xA SoC, the RCW override procedure needs to be aware of all link
> + * modes which are configured on a SerDes block.
> + */
> +void fsl_guts_lane_init(int serdes_idx, int lane, enum lynx_lane_mode lane_mode)
> +{
> + soc.lane_mode[serdes_idx - 1][lane] = lane_mode;
> +}
> +EXPORT_SYMBOL_NS_GPL(fsl_guts_lane_init, "FSL_GUTS");
> +
> +/**
> + * fsl_guts_lane_validate() - Validate that SerDes protocol is implemented and
> + * supported on current SoC
> + * @serdes_idx: zero-based SerDes block index
> + * @lane: zero-based lane index within SerDes
> + * @lane_mode: requested SerDes protocol
> + *
> + * Should be called before actually requesting the RCW override procedure to be
> + * applied using %fsl_guts_lane_set_mode()
> + *
> + * Return: 0 if RCW override to protocol is possible, negative error otherwise
> + */
> +int fsl_guts_lane_validate(int serdes_idx, int lane, enum lynx_lane_mode lane_mode)
> +{
> + struct fsl_soc_serdes_rcw_override override;
> +
> + return fsl_guts_serdes_get_rcw_override(serdes_idx, lane, lane_mode,
> + &override);
> +}
> +EXPORT_SYMBOL_NS_GPL(fsl_guts_lane_validate, "FSL_GUTS");
> +
> +/**
> + * fsl_guts_lane_set_mode() - apply RCW override procedure for SerDes lane
> + * @serdes_idx: zero-based SerDes block index
> + * @lane: zero-based lane index within SerDes
> + * @lane_mode: requested SerDes protocol
> + *
> + * Return: 0 on success, negative error otherwise
> + */
> +int fsl_guts_lane_set_mode(int serdes_idx, int lane, enum lynx_lane_mode lane_mode)
> +{
> + struct fsl_soc_serdes_rcw_override override;
> + int err;
> +
> + err = fsl_guts_serdes_get_rcw_override(serdes_idx, lane, lane_mode,
> + &override);
> + if (err)
> + return err;
> +
> + spin_lock(&soc.rcwcr_lock);
> +
> + if (soc.data->serdes_init_rcwcr)
> + soc.data->serdes_init_rcwcr(serdes_idx);
> +
> + fsl_guts_rmw(override.offset, override.val << __bf_shf(override.mask),
> + override.mask);
> + soc.lane_mode[serdes_idx - 1][lane] = lane_mode;
> +
> + spin_unlock(&soc.rcwcr_lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL_NS_GPL(fsl_guts_lane_set_mode, "FSL_GUTS");
> +
> static u64 fsl_guts_get_soc_uid(const char *compat, unsigned int offset)
> {
> struct device_node *np;
> @@ -193,6 +344,128 @@ static u64 fsl_guts_get_soc_uid(const char *compat, unsigned int offset)
> return uid;
> }
>
> +static int ls1088a_serdes_get_rcw_override(int index, int lane,
> + enum lynx_lane_mode lane_mode,
> + struct fsl_soc_serdes_rcw_override *override)
> +{
> + /* The RCW override procedure has to write to different registers
> + * depending on the SerDes block index.
> + */
> + switch (index) {
> + case 1:
> + override->offset = 28;
> + override->mask = LS1088A_RCWSR29_SRDS_PRTCL_S1_LNn(lane);
> + break;
> + case 2:
> + override->offset = 29;
> + override->mask = LS1088A_RCWSR30_SRDS_PRTCL_S2_LNn(lane);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (lynx_lane_mode_uses_xgmii_mac(lane_mode))
> + override->val = SRDS_PRTCL_XFI;
> + else if (lynx_lane_mode_uses_gmii_mac(lane_mode))
> + override->val = SRDS_PRTCL_100BASEX_SGMII;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int ls1046a_serdes_get_rcw_override(int index, int lane,
> + enum lynx_lane_mode lane_mode,
> + struct fsl_soc_serdes_rcw_override *override)
> +{
> + /* The RCW override procedure has to write to different registers
> + * depending on the SerDes block index.
> + */
> + switch (index) {
> + case 1:
> + override->offset = 4;
> + override->mask = LS1046A_RCWSR5_SRDS_PRTCL_S1(lane);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (lynx_lane_mode_uses_xgmii_mac(lane_mode))
> + override->val = SRDS_PRTCL_XFI;
> + else if (lynx_lane_mode_uses_gmii_mac(lane_mode))
> + override->val = SRDS_PRTCL_100BASEX_SGMII;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int ls2088a_serdes_get_rcw_override(int index, int lane,
> + enum lynx_lane_mode lane_mode,
> + struct fsl_soc_serdes_rcw_override *override)
> +{
> + switch (index) {
> + case 1:
> + override->offset = 29;
> + override->mask = LS2088A_RCWSR30_SRDS_CLK_SEL_XGMII_Ln_S1(lane);
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + if (lynx_lane_mode_uses_xgmii_mac(lane_mode))
> + override->val = SRDS_CLK_SEL_XGMII;
> + else if (lynx_lane_mode_uses_gmii_mac(lane_mode))
> + override->val = SRDS_CLK_SEL_GMII;
> + else
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static void ls2088a_serdes_init_rcwcr(int serdes_idx)
> +{
> + u32 reg;
> + int i;
> +
> + if (serdes_idx != 1)
> + return;
> + if (soc.rcwcr_init_done)
> + return;
> +
> + /* SRDS_CLK_EN_SEL_XGMII_S1: SerDes Clock Enable Select XGMII Serdes 1:
> + * Enables to select GMII/XGMII clock according to
> + * SRDS_CLK_SEL_XGMII_Ln_S1
> + */
> + reg = LS2088A_RCWSR30_SRDS_CLK_EN_SEL_XGMII_S1;
> +
> + /* We need to configure the initial state of all lanes for
> + * the SerDes block #1
> + */
> + for (i = 0; i < MAX_NUM_LANES; i++)
> + if (lynx_lane_mode_uses_xgmii_mac(soc.lane_mode[serdes_idx - 1][i]))
> + reg |= LS2088A_RCWSR30_SRDS_CLK_SEL_XGMII_Ln_S1(i);
> +
> + fsl_guts_rmw(29, reg,
> + LS2088A_RCWSR30_SRDS_CLK_EN_SEL_XGMII_S1 |
> + LS2088A_RCWSR30_SRDS_CLK_SEL_MSK);
> +
> + soc.rcwcr_init_done = true;
> +}
> +
> +static const struct fsl_soc_data ls1088a_data = {
> + .serdes_get_rcw_override = ls1088a_serdes_get_rcw_override,
> +};
> +
> +static const struct fsl_soc_data ls1046a_data = {
> + .serdes_get_rcw_override = ls1046a_serdes_get_rcw_override,
> +};
> +
> +static const struct fsl_soc_data ls2088a_data = {
> + .serdes_get_rcw_override = ls2088a_serdes_get_rcw_override,
> + .serdes_init_rcwcr = ls2088a_serdes_init_rcwcr,
> +};
> +
> static const struct fsl_soc_data ls1028a_data = {
> .sfp_compat = "fsl,ls1028a-sfp",
> .uid_offset = 0x21c,
> @@ -221,10 +494,10 @@ static const struct of_device_id fsl_guts_of_match[] = {
> { .compatible = "fsl,mpc8572-guts", },
> { .compatible = "fsl,ls1021a-dcfg", },
> { .compatible = "fsl,ls1043a-dcfg", },
> - { .compatible = "fsl,ls2080a-dcfg", },
> - { .compatible = "fsl,ls1088a-dcfg", },
> + { .compatible = "fsl,ls2080a-dcfg", .data = &ls2088a_data},
> + { .compatible = "fsl,ls1088a-dcfg", .data = &ls1088a_data},
> { .compatible = "fsl,ls1012a-dcfg", },
> - { .compatible = "fsl,ls1046a-dcfg", },
> + { .compatible = "fsl,ls1046a-dcfg", .data = &ls1046a_data},
> { .compatible = "fsl,lx2160a-dcfg", },
> { .compatible = "fsl,ls1028a-dcfg", .data = &ls1028a_data},
> {}
> @@ -250,6 +523,8 @@ static int __init fsl_guts_init(void)
> of_node_put(np);
> return -ENOMEM;
> }
> + /* DCFG_DCSR is optional */
> + soc.dcfg_dcsr = of_iomap(np, DCFG_DCSR);
>
> soc.little_endian = of_property_read_bool(np, "little-endian");
> soc.svr = fsl_guts_read(&soc.dcfg_ccsr->svr);
> @@ -296,6 +571,8 @@ static int __init fsl_guts_init(void)
> goto err;
> }
>
> + spin_lock_init(&soc.rcwcr_lock);
> +
> pr_info("Machine: %s\n", soc_dev_attr->machine);
> pr_info("SoC family: %s\n", soc_dev_attr->family);
> pr_info("SoC ID: %s, Revision: %s\n",
> @@ -305,7 +582,8 @@ static int __init fsl_guts_init(void)
>
> err_nomem:
> ret = -ENOMEM;
> -
> + if (soc.dcfg_dcsr)
> + iounmap(soc.dcfg_dcsr);
> iounmap(soc.dcfg_ccsr);
> err:
> kfree(soc_dev_attr->family);
> diff --git a/include/linux/fsl/guts.h b/include/linux/fsl/guts.h
> index fdb55ca47a4f..176842531241 100644
> --- a/include/linux/fsl/guts.h
> +++ b/include/linux/fsl/guts.h
> @@ -13,6 +13,7 @@
>
> #include <linux/types.h>
> #include <linux/io.h>
> +#include <soc/fsl/phy-fsl-lynx.h>
>
> /*
> * Global Utility Registers.
> @@ -91,9 +92,15 @@ struct ccsr_guts {
> u32 iovselsr; /* 0x.00c0 - I/O voltage select status register
> Called 'elbcvselcr' on 86xx SOCs */
> u8 res0c4[0x100 - 0xc4];
> - u32 rcwsr[16]; /* 0x.0100 - Reset Control Word Status registers
> - There are 16 registers */
> - u8 res140[0x224 - 0x140];
> + /* 0x.0100 - read-only Reset Configuration Word Status registers in
> + * CCSR, or write-only Reset Configuration Word Control registers in
> + * DCSR. In both cases there are 32 registers.
> + */
> + union {
> + u32 rcwsr[32];
> + u32 rcwcr[32];
> + };
> + u8 res180[0x224 - 0x180];
> u32 iodelay1; /* 0x.0224 - IO delay control register 1 */
> u32 iodelay2; /* 0x.0228 - IO delay control register 2 */
> u8 res22c[0x604 - 0x22c];
> @@ -131,6 +138,13 @@ struct ccsr_guts {
> u32 srds2cr1; /* 0x.0f44 - SerDes2 Control Register 0 */
> } __attribute__ ((packed));
>
> +void fsl_guts_lane_init(int serdes_idx, int lane,
> + enum lynx_lane_mode lane_mode);
> +int fsl_guts_lane_validate(int serdes_idx, int lane,
> + enum lynx_lane_mode lane_mode);
> +int fsl_guts_lane_set_mode(int serdes_idx, int lane,
> + enum lynx_lane_mode lane_mode);
> +
> /* Alternate function signal multiplex control */
> #define MPC85xx_PMUXCR_QE(x) (0x8000 >> (x))
>
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v1 phy-next 6/8] dt-bindings: fsl: layerscape-dcfg: define DCFG_DCSR region
From: Conor Dooley @ 2026-06-12 15:44 UTC (permalink / raw)
To: Vladimir Oltean
Cc: linux-phy, devicetree, linuxppc-dev, linux-arm-kernel,
Ioana Ciornei, Vinod Koul, Neil Armstrong, Tanjeff Moos,
Christophe Leroy (CS GROUP), Michael Walle, Shawn Guo, Frank Li,
linux-kernel, Krzysztof Kozlowski, Rob Herring
In-Reply-To: <20260611193940.44416-7-vladimir.oltean@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 3952 bytes --]
On Thu, Jun 11, 2026 at 10:39:38PM +0300, Vladimir Oltean wrote:
> In Layerscape (Arm) and QorIQ (PowerPC) devices, hardware peripherals
> are accessed by the CPU through a portion of the SoC address space
> called CCSR ("Configuration, Control, and Status Registers"). All
> hardware IP blocks have their registers mapped here, and the Device
> Configuration block makes no exception.
>
> However, there exists a secondary range of the address space named DCSR
> ("Debug Control and Status Registers") which, like CCSR, also holds
> registers of hardware IP blocks, except the DCSR contents is hidden in
> all public reference manuals.
>
> The intention of the CCSR/DCSR split, to the best of my knowledge, was
> to place the functionality that is too low level for normal use, and
> which is necessary only for debug, in a completely separate address
> space which can be hidden.
>
> A use case has appeared where networking SerDes lanes need to be
> reconfigured at runtime for a different protocol (example: 10GBase-R to
> SGMII), and the architecture of the SoCs does not normally permit that.
> The Reset Configuration Word (RCW) is a data structure read by the SoC
> preboot loader (PBL) which contains stuff like pinmuxing and SerDes
> protocol mapping for each lane.
>
> The RCW that the PBL has loaded is visible in the DCFG block's normal
> status registers (from CCSR), as read only. Turns out, the RCW is also
> mapped in the DCFG's shadow register map (in DCSR), in a write-only
> form. Writing to the RCW registers from the DCFG's DCSR space to change
> what the PBL has loaded is called "RCW override".
>
> It has been validated that the RCW override procedure is necessary to
> reconfigure the networking data path when a SerDes lane performs a major
> protocol change. It changes some internal muxes which connect the PCS to
> either the 10G MAC or to the 1G MAC.
>
> Defining the DCSR area of the DCFG as a secondary 'reg' array element
> allows operating systems to perform RCW overrides. Since it is
> introduced late in the binding's lifetime, it is optional. It can be
> identified by name, but also by index (first 'reg' is CCSR).
>
> Note that while all SoCs should have a DCFG register block in DCSR, we
> only need to expose it for the SoCs where the RCW override procedure is
> known to be needed and has been validated.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> ---
> Cc: Conor Dooley <conor@kernel.org>
Where did this email come from btw? get_maintainer.pl result should have
+dt in it.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
Cheers,
Conor.
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> ---
> .../bindings/soc/fsl/fsl,layerscape-dcfg.yaml | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
> index 3fb0534ea597..fc14fd0bf84b 100644
> --- a/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
> +++ b/Documentation/devicetree/bindings/soc/fsl/fsl,layerscape-dcfg.yaml
> @@ -36,7 +36,20 @@ properties:
> - const: simple-mfd
>
> reg:
> - maxItems: 1
> + minItems: 1
> + items:
> + - description:
> + Customer-visible DCFG register map from CCSR address space
> + (Configuration, Control and Status Registers)
> + - description:
> + Customer-hidden DCFG register map from DCSR address space
> + (Debug Control and Status Registers)
> +
> + reg-names:
> + minItems: 1
> + items:
> + - const: dcfg_ccsr
> + - const: dcfg_dcsr
>
> little-endian: true
> big-endian: true
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] regulator: Add support for UGREEN NASync DH2300 MCU SATA power gate
From: sashiko-bot @ 2026-06-12 15:41 UTC (permalink / raw)
To: Alexey Charkov; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260612-dh2300-mcu-v1-4-ab8db1617bc0@flipper.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The platform driver lacks a MODULE_ALIAS() declaration, which prevents automatic module loading.
--
commit 64ccd270dc21c4fa03f9ebc2bb443018b396eeab
Author: Alexey Charkov <alchark@flipper.net>
regulator: Add support for UGREEN NASync DH2300 MCU SATA power gate
This commit adds a driver for the SATA drive-bay power gate function of the
UGREEN NASync DH2300 embedded controller. It acts as a simple on/off regulator
controlled by register 0x41.
> diff --git a/drivers/regulator/ugreen-dh2300-mcu-regulator.c b/drivers/regulator/ugreen-dh2300-mcu-regulator.c
> new file mode 100644
> index 0000000000000..69fda90f7ace6
> --- /dev/null
> +++ b/drivers/regulator/ugreen-dh2300-mcu-regulator.c
[ ... ]
> +static struct platform_driver ugreen_dh2300_mcu_regulator_driver = {
> + .driver = {
> + .name = "ugreen-dh2300-mcu-regulator",
> + },
> + .probe = ugreen_dh2300_mcu_regulator_probe,
> +};
> +module_platform_driver(ugreen_dh2300_mcu_regulator_driver);
> +
> +MODULE_DESCRIPTION("UGREEN NASync DH2300 MCU SATA power regulator");
> +MODULE_LICENSE("GPL");
[Severity: Medium]
Will ugreen_dh2300_mcu_regulator_driver load automatically when built as a
module?
This driver lacks an id_table, of_match_table, or a MODULE_ALIAS declaration.
When the MFD core registers the sub-device, the platform bus emits a uevent
with MODALIAS=platform:ugreen-dh2300-mcu-regulator.
Without the alias mapping, udev/modprobe might fail to automatically load
the driver on boot, leaving the SATA drives unpowered unless the module
is manually loaded.
Would it make sense to add MODULE_ALIAS("platform:ugreen-dh2300-mcu-regulator")?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612-dh2300-mcu-v1-0-ab8db1617bc0@flipper.net?part=4
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: media: Add nxp neoisp support
From: Frank Li @ 2026-06-12 15:39 UTC (permalink / raw)
To: Antoine Bouyer
Cc: julien.vuillaumier, alexi.birlinger, daniel.baluta, peng.fan,
frank.li, jacopo.mondi, laurent.pinchart, mchehab, robh, krzk+dt,
conor+dt, michael.riesch, anthony.mcgivern, linux-media,
linux-kernel, devicetree, imx, ai.luthra, paul.elder, geert,
sakari.ailus, hverkuil+cisco
In-Reply-To: <20260612132039.2089051-2-antoine.bouyer@nxp.com>
On Fri, Jun 12, 2026 at 03:20:32PM +0200, Antoine Bouyer wrote:
> Add the yaml binding for NXP's Neo Image Signal Processor (ISP).
>
> Signed-off-by: Antoine Bouyer <antoine.bouyer@nxp.com>
> Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../bindings/media/nxp,imx95-neoisp.yaml | 62 +++++++++++++++++++
> 1 file changed, 62 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
>
> diff --git a/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml b/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
> new file mode 100644
> index 000000000000..458c4e4d640d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/nxp,imx95-neoisp.yaml
> @@ -0,0 +1,62 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/nxp,imx95-neoisp.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: NXP NEOISP Image Signal Processing Pipeline
> +
> +maintainers:
> + - Antoine Bouyer <antoine.bouyer@nxp.com>
> +
> +description:
> + The NXP NEOISP performs a set of image processing tasks on the RAW camera
> + stream and provides RGB or YUV enhanced image.
> +
> +properties:
> + compatible:
> + enum:
> + - nxp,imx95-neoisp
> +
> + reg:
> + items:
> + - description: The configuration registers
> + - description: ISP local memories
> +
> + interrupts:
> + maxItems: 1
> +
> + clocks:
> + maxItems: 1
> +
> + clock-names:
> + items:
> + - const: camcm0
> +
> + power-domains:
> + maxItems: 1
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> + - clock-names
> + - power-domains
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> +
> + isp@4ae00000 {
> + compatible = "nxp,imx95-neoisp";
> + reg = <0x4ae00000 0x8000>,
> + <0x4afe0000 0x10000>;
> + interrupts = <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-parent = <&gic>;
> + clocks = <&scmi_clk 64>; /* IMX95_CLK_CAMCM0 */
> + clock-names = "camcm0";
> + power-domains = <&scmi_devpd 3>; /* IMX95_PD_CAMERA */
> + };
> --
> 2.53.0
>
>
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: rockchip: fix emmc reset polarity on px30-cobra
From: Quentin Schulz @ 2026-06-12 15:38 UTC (permalink / raw)
To: Jakob Unterwurzacher, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Jakob Unterwurzacher
Cc: stable, Heiko Stuebner, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260609081728.30616-2-jakobunt@gmail.com>
Hi Jakob,
On 6/9/26 10:17 AM, Jakob Unterwurzacher wrote:
> From: Jakob Unterwurzacher <jakob.unterwurzacher@cherry.de>
>
> Technically, the reset signal is active low - it's called RST_n after all.
>
> But it is ignored completely unless RST_n_FUNCTION=1 (byte 162 in extcsd)
> is set in the emmc. It is 0 per default.
>
> For emmcs that have RST_n_FUNCTION=1 we failed like this:
>
> [ 3.074480] mmc1: Failed to initialize a non-removable card
>
> With this change they work normally.
>
> Cc: stable@vger.kernel.org
> Fixes: bb510ddc9d3e ("arm64: dts: rockchip: add px30-cobra base dtsi and board variants")
Tested-by: Quentin Schulz <quentin.schulz@cherry.de>
Thanks!
Quentin
^ permalink raw reply
* Re: [PATCH v16 0/3] of: parsing of multi #{iommu,msi}-cells in maps
From: Rob Herring @ 2026-06-12 15:35 UTC (permalink / raw)
To: Vijayanand Jitta
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Lorenzo Pieralisi, Marc Zyngier, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
linux-arm-msm, linux-kernel, iommu, linux-arm-kernel, devicetree,
linux-pci, imx, xen-devel, Charan Teja Kalla, Dmitry Baryshkov
In-Reply-To: <20260603-parse_iommu_cells-v16-0-dc509dacb19a@oss.qualcomm.com>
On Wed, Jun 03, 2026 at 12:43:11PM +0530, Vijayanand Jitta wrote:
> So far our parsing of {iommu,msi}-map properties has always blindly
> assumed that the output specifiers will always have exactly 1 cell.
> This typically does happen to be the case, but is not actually enforced
> (and the PCI msi-map binding even explicitly states support for 0 or 1
> cells) - as a result we've now ended up with dodgy DTs out in the field
> which depend on this behaviour to map a 1-cell specifier for a 2-cell
> provider, despite that being bogus per the bindings themselves.
>
> Since there is some potential use[1] in being able to map at least
> single input IDs to multi-cell output specifiers (and properly support
> 0-cell outputs as well), add support for properly parsing and using the
> target nodes' #cells values, albeit with the unfortunate complication of
> still having to work around expectations of the old behaviour too.
> -- Robin.
>
> Unlike single #{}-cell, it is complex to establish a linear relation
> between input 'id' and output specifier for multi-cell properties, thus
> it is always expected that len never going to be > 1.
>
> These changes have been tested on QEMU for the arm64 architecture and
> on the glymur platform [3].
>
> Since, this would also need update in dt-schema, raised PR[2] for the
> same.
>
> [1] https://lore.kernel.org/all/20250627-video_cb-v3-0-51e18c0ffbce@quicinc.com/
> [2] PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184
> [3] https://lore.kernel.org/all/20260515-glymur-v6-5-f6a99cb43a24@oss.qualcomm.com/
>
> V16:
> - Patch 2: Fix potential NULL pointer dereference in of_msi_xlate()
> when msi_np is NULL. Guard the of_check_msi_parent() call with
> "if (msi_np && ...)" to handle the case where the caller passes
> NULL for msi_np, as documented. Reported by Sashiko [1].
> - Patch 2: Fix OF node refcount leak in of_msi_map_get_device_domain():
> np was never released after of_msi_xlate() transferred ownership.
> - Patch 3: Default to 1-cell output specifier when the target node
> lacks the #iommu-cells/#msi-cells property, for backward
> compatibility with controllers that predate the property
> (e.g. arm,gic-v2m-frame). Reported by Sashiko [1].
> - Patch 3: Add !cells_name to the initial parameter guard in
> of_map_id() to prevent a crash if cells_name is NULL.
> Reported by Sashiko [1].
I've applied the series, thanks.
Rob
^ permalink raw reply
* [PATCH 4/4] regulator: Add support for UGREEN NASync DH2300 MCU SATA power gate
From: Alexey Charkov @ 2026-06-12 15:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Heiko Stuebner, Liam Girdwood, Mark Brown
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Alexey Charkov
In-Reply-To: <20260612-dh2300-mcu-v1-0-ab8db1617bc0@flipper.net>
Add a driver for the SATA drive-bay power gate function of the UGREEN
NASync DH2300 embedded controller (HC32F005 MCU).
This is a simple on/off regulator, controlled by bit 0 of register 0x41,
with inverted polarity (0 = enabled, 1 = disabled). Boot-time default is
disabled, so this driver is required to use the NAS functionality.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
MAINTAINERS | 1 +
drivers/regulator/Kconfig | 12 ++++
drivers/regulator/Makefile | 1 +
drivers/regulator/ugreen-dh2300-mcu-regulator.c | 80 +++++++++++++++++++++++++
4 files changed, 94 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9578a06fe651..2fc84be86e46 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27638,6 +27638,7 @@ M: Alexey Charkov <alchark@flipper.net>
S: Maintained
F: Documentation/devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml
F: drivers/mfd/ugreen-dh2300-mcu.c
+F: drivers/regulator/ugreen-dh2300-mcu-regulator.c
UHID USERSPACE HID IO DRIVER
M: David Rheinsberg <david@readahead.eu>
diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index a54a549196fe..e692ff864806 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -1812,6 +1812,18 @@ config REGULATOR_TWL4030
This driver supports the voltage regulators provided by
this family of companion chips.
+config REGULATOR_UGREEN_DH2300_MCU
+ tristate "UGREEN NASync DH2300 MCU SATA power regulator"
+ depends on MFD_UGREEN_DH2300_MCU
+ help
+ Say yes here to enable support for the SATA drive-bay power gate of
+ the UGREEN NASync DH2300 embedded controller. The regulator is a
+ sub-device of the ugreen-dh2300-mcu MFD core and is normally consumed
+ by the SATA controllers via their target-supply.
+
+ This driver can also be built as a module. If so, the module will be
+ called ugreen-dh2300-mcu-regulator.
+
config REGULATOR_UNIPHIER
tristate "UniPhier regulator driver"
depends on ARCH_UNIPHIER || COMPILE_TEST
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 134eee274dbf..44956d795923 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -206,6 +206,7 @@ obj-$(CONFIG_REGULATOR_TPS6594) += tps6594-regulator.o
obj-$(CONFIG_REGULATOR_TPS65132) += tps65132-regulator.o
obj-$(CONFIG_REGULATOR_TPS68470) += tps68470-regulator.o
obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o twl6030-regulator.o
+obj-$(CONFIG_REGULATOR_UGREEN_DH2300_MCU) += ugreen-dh2300-mcu-regulator.o
obj-$(CONFIG_REGULATOR_UNIPHIER) += uniphier-regulator.o
obj-$(CONFIG_REGULATOR_RZG2L_VBCTRL) += renesas-usb-vbus-regulator.o
obj-$(CONFIG_REGULATOR_VCTRL) += vctrl-regulator.o
diff --git a/drivers/regulator/ugreen-dh2300-mcu-regulator.c b/drivers/regulator/ugreen-dh2300-mcu-regulator.c
new file mode 100644
index 000000000000..69fda90f7ace
--- /dev/null
+++ b/drivers/regulator/ugreen-dh2300-mcu-regulator.c
@@ -0,0 +1,80 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * SATA drive-bay power gate for the UGREEN NASync DH2300 embedded controller
+ * (HC32F005 MCU).
+ *
+ * The microcontroller gates the SATA bay power rail through register 0x41.
+ * The polarity is inverted: writing 0 enables the rail, writing 1 disables it
+ * (the controller latches "off" out of reset).
+ */
+
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/regulator/driver.h>
+#include <linux/regulator/of_regulator.h>
+
+#define UGREEN_DH2300_MCU_REG_SATA_POWER 0x41
+
+static const struct regulator_ops ugreen_dh2300_sata_ops = {
+ .enable = regulator_enable_regmap,
+ .disable = regulator_disable_regmap,
+ .is_enabled = regulator_is_enabled_regmap,
+};
+
+static const struct regulator_desc ugreen_dh2300_sata_desc = {
+ .name = "sata-power",
+ .enable_is_inverted = true,
+ .enable_mask = 0x01,
+ .enable_reg = UGREEN_DH2300_MCU_REG_SATA_POWER,
+ .supply_name = "vin",
+ .ops = &ugreen_dh2300_sata_ops,
+ .type = REGULATOR_VOLTAGE,
+ .owner = THIS_MODULE,
+};
+
+static int ugreen_dh2300_mcu_regulator_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct regulator_config config = { };
+ struct regulator_dev *rdev;
+ struct device_node *np;
+
+ np = of_get_child_by_name(dev->parent->of_node, "regulator");
+ if (!np)
+ return dev_err_probe(dev, -ENODEV,
+ "missing regulator child node\n");
+
+ config.dev = dev;
+ config.of_node = np;
+ config.regmap = dev_get_regmap(dev->parent, NULL);
+ if (!config.regmap) {
+ of_node_put(np);
+ return dev_err_probe(dev, -ENODEV,
+ "no regmap available from parent\n");
+ }
+
+ config.init_data = of_get_regulator_init_data(dev, np,
+ &ugreen_dh2300_sata_desc);
+
+ rdev = devm_regulator_register(dev, &ugreen_dh2300_sata_desc, &config);
+ of_node_put(np);
+ if (IS_ERR(rdev))
+ return dev_err_probe(dev, PTR_ERR(rdev),
+ "failed to register regulator\n");
+
+ return 0;
+}
+
+static struct platform_driver ugreen_dh2300_mcu_regulator_driver = {
+ .driver = {
+ .name = "ugreen-dh2300-mcu-regulator",
+ },
+ .probe = ugreen_dh2300_mcu_regulator_probe,
+};
+module_platform_driver(ugreen_dh2300_mcu_regulator_driver);
+
+MODULE_DESCRIPTION("UGREEN NASync DH2300 MCU SATA power regulator");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH 3/4] mfd: Add support for UGREEN NASync DH2300 MCU
From: Alexey Charkov @ 2026-06-12 15:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Heiko Stuebner, Liam Girdwood, Mark Brown
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Alexey Charkov
In-Reply-To: <20260612-dh2300-mcu-v1-0-ab8db1617bc0@flipper.net>
Add a driver for the HC32F005 MCU used as an embedded controller on the
UGREEN NASync DH2300 NAS.
This part provides the shared I2C regmap to be used by function-specific
sub-devices, and instantiates the SATA drive-bay power gate regulator.
Implemented as an MFD to allow for other functions of the MCU to be added
later: vendor binaries imply that it also provides a hardware watchdog
and somehow serves as a wake source, but so far only the SATA power gating
function has been confirmed in absence of documentation and sources for the
vendor firmware.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
MAINTAINERS | 1 +
drivers/mfd/Kconfig | 16 +++++++++++
drivers/mfd/Makefile | 1 +
drivers/mfd/ugreen-dh2300-mcu.c | 60 +++++++++++++++++++++++++++++++++++++++++
4 files changed, 78 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index ca27df7cd684..9578a06fe651 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27637,6 +27637,7 @@ UGREEN DH2300 MCU MFD DRIVER
M: Alexey Charkov <alchark@flipper.net>
S: Maintained
F: Documentation/devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml
+F: drivers/mfd/ugreen-dh2300-mcu.c
UHID USERSPACE HID IO DRIVER
M: David Rheinsberg <david@readahead.eu>
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 763ce6a34782..5a2ad75bd9c9 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1947,6 +1947,22 @@ config MFD_TPS6594_SPI
This driver can also be built as a module. If so, the module
will be called tps6594-spi.
+config MFD_UGREEN_DH2300_MCU
+ tristate "UGREEN NASync DH2300 embedded controller"
+ depends on I2C
+ depends on OF
+ select MFD_CORE
+ select REGMAP_I2C
+ help
+ Say yes here to enable support for the HC32F005 microcontroller found
+ on the UGREEN NASync DH2300 NAS, where it acts as a board embedded
+ controller. This core driver sets up the shared register map and
+ instantiates the function sub-devices (the SATA drive-bay power
+ regulator).
+
+ This driver can also be built as a module. If so, the module will be
+ called ugreen-dh2300-mcu.
+
config TWL4030_CORE
bool "TI TWL4030/TWL5030/TWL6030/TPS659x0 Support"
depends on I2C=y
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index dd4bb7e77c33..6247239bcfe1 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -109,6 +109,7 @@ obj-$(CONFIG_MFD_TPS65912_SPI) += tps65912-spi.o
obj-$(CONFIG_MFD_TPS6594) += tps6594-core.o
obj-$(CONFIG_MFD_TPS6594_I2C) += tps6594-i2c.o
obj-$(CONFIG_MFD_TPS6594_SPI) += tps6594-spi.o
+obj-$(CONFIG_MFD_UGREEN_DH2300_MCU) += ugreen-dh2300-mcu.o
obj-$(CONFIG_MENELAUS) += menelaus.o
obj-$(CONFIG_TWL4030_CORE) += twl-core.o twl4030-irq.o twl6030-irq.o
diff --git a/drivers/mfd/ugreen-dh2300-mcu.c b/drivers/mfd/ugreen-dh2300-mcu.c
new file mode 100644
index 000000000000..5184b0c98759
--- /dev/null
+++ b/drivers/mfd/ugreen-dh2300-mcu.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Core driver for the UGREEN NASync DH2300 embedded controller (HC32F005 MCU).
+ *
+ * The microcontroller sits on I2C and exposes an 8-bit register map. It is a
+ * multi-function device: SATA drive-bay power gate, hardware watchdog and
+ * possibly other functions
+ */
+
+#include <linux/i2c.h>
+#include <linux/mfd/core.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/regmap.h>
+
+#define UGREEN_DH2300_MCU_REG_MAX 0x94
+
+static const struct regmap_config ugreen_dh2300_mcu_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = UGREEN_DH2300_MCU_REG_MAX,
+};
+
+static const struct mfd_cell ugreen_dh2300_mcu_cells[] = {
+ { .name = "ugreen-dh2300-mcu-regulator" },
+};
+
+static int ugreen_dh2300_mcu_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct regmap *regmap;
+
+ regmap = devm_regmap_init_i2c(client, &ugreen_dh2300_mcu_regmap_config);
+ if (IS_ERR(regmap))
+ return dev_err_probe(dev, PTR_ERR(regmap),
+ "failed to initialise regmap\n");
+
+ return devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO,
+ ugreen_dh2300_mcu_cells,
+ ARRAY_SIZE(ugreen_dh2300_mcu_cells),
+ NULL, 0, NULL);
+}
+
+static const struct of_device_id ugreen_dh2300_mcu_of_match[] = {
+ { .compatible = "ugreen,dh2300-mcu" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ugreen_dh2300_mcu_of_match);
+
+static struct i2c_driver ugreen_dh2300_mcu_driver = {
+ .driver = {
+ .name = "ugreen-dh2300-mcu",
+ .of_match_table = ugreen_dh2300_mcu_of_match,
+ },
+ .probe = ugreen_dh2300_mcu_probe,
+};
+module_i2c_driver(ugreen_dh2300_mcu_driver);
+
+MODULE_DESCRIPTION("UGREEN NASync DH2300 embedded controller core driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH 2/4] dt-bindings: mfd: Add UGREEN NASync DH2300 MCU
From: Alexey Charkov @ 2026-06-12 15:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Heiko Stuebner, Liam Girdwood, Mark Brown
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Alexey Charkov
In-Reply-To: <20260612-dh2300-mcu-v1-0-ab8db1617bc0@flipper.net>
Document the UGREEN NASync DH2300 embedded controller (HC32F005 MCU),
which is responsible for gating the SATA drive-bay power rail and
providing a hardware watchdog.
This is based on disassebly of a GPL binary from vendor firmware for which
no source code could be found, so parts of it can be inaccurate. Only
the power gating function is confirmed.
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
.../devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml | 62 ++++++++++++++++++++++
MAINTAINERS | 5 ++
2 files changed, 67 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml b/Documentation/devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml
new file mode 100644
index 000000000000..847970c609cd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml
@@ -0,0 +1,62 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/ugreen,dh2300-mcu.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: UGREEN NASync DH2300 embedded controller
+
+maintainers:
+ - Alexey Charkov <alchark@flipper.net>
+
+description:
+ The UGREEN NASync DH2300 NAS carries a HC32F005 microcontroller on I2C that
+ acts as a board embedded controller. It gates power to the SATA drive bays
+ through an internal register and apparently also serves as a watchdog
+ (unconfirmed, as vendor kernel sources are unavailable, works without it)
+
+properties:
+ compatible:
+ const: ugreen,dh2300-mcu
+
+ reg:
+ maxItems: 1
+
+ regulator:
+ type: object
+ $ref: /schemas/regulator/regulator.yaml#
+ unevaluatedProperties: false
+ description:
+ The SATA drive-bay power gate controlled by the MCU.
+
+ watchdog-gpios:
+ description:
+ Optional GPIO line used to ping the hardware watchdog function of the MCU
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/pinctrl/rockchip.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ embedded-controller@4c {
+ compatible = "ugreen,dh2300-mcu";
+ reg = <0x4c>;
+ watchdog-gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>;
+
+ sata_power: regulator {
+ regulator-name = "sata-power";
+ vin-supply = <&vcc12v_dcin>;
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index f1caa6e5198b..ca27df7cd684 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27633,6 +27633,11 @@ L: linux-input@vger.kernel.org
S: Maintained
F: drivers/hid/hid-udraw-ps3.c
+UGREEN DH2300 MCU MFD DRIVER
+M: Alexey Charkov <alchark@flipper.net>
+S: Maintained
+F: Documentation/devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml
+
UHID USERSPACE HID IO DRIVER
M: David Rheinsberg <david@readahead.eu>
L: linux-input@vger.kernel.org
--
2.53.0
^ permalink raw reply related
* [PATCH 1/4] dt-bindings: vendor-prefixes: Add Ugreen Group Limited
From: Alexey Charkov @ 2026-06-12 15:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Heiko Stuebner, Liam Girdwood, Mark Brown
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Alexey Charkov
In-Reply-To: <20260612-dh2300-mcu-v1-0-ab8db1617bc0@flipper.net>
Add Ugreen Group Limited, a consumer technology company producing a range
of smart charging, office audio and visual, and smart storage products.
Link: https://www.ugreen.com/
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index dd94c50e97f9..274e52421a5b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1757,6 +1757,8 @@ patternProperties:
description: Ufi Space Co., Ltd.
"^ugoos,.*":
description: Ugoos Industrial Co., Ltd.
+ "^ugreen,.*":
+ description: Ugreen Group Limited
"^ultrapower,.*":
description: Beijing Ultrapower Software Co., Ltd.
"^uni-t,.*":
--
2.53.0
^ permalink raw reply related
* [PATCH 0/4] mfd: Add support for the MCU in the UGREEN DH2300 NAS
From: Alexey Charkov @ 2026-06-12 15:34 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lee Jones,
Heiko Stuebner, Liam Girdwood, Mark Brown
Cc: devicetree, linux-kernel, linux-arm-kernel, linux-rockchip,
Alexey Charkov
UGREEN DH2300 is a 2-bay SATA NAS based on the Rockchip RK3576 SoC. It
includes an embedded controller connected over I2C which won't let the
drives power up without its register being poked first, which precludes
the use of the device for its main purpose.
There is no public documentation or source code available, but apparently
the MCU is also responsible for a hardware watchdog function and some type
of wake functionality, so this series implements an MFD-regulator
separation right away to allow for adding these functions properly later
on.
For now though a single-bit write to the MCU seems to be sufficient to get
the drives to work with only a board DTS addition [1] - to be submitted
separately.
[1] https://github.com/flipperdevices/flipper-linux-kernel/blob/2c1c5ee609f6ed4c77e9e5428df91e98b3f50cce/arch/arm64/boot/dts/rockchip/rk3576-nasync-dh2300.dts
Signed-off-by: Alexey Charkov <alchark@flipper.net>
---
Alexey Charkov (4):
dt-bindings: vendor-prefixes: Add Ugreen Group Limited
dt-bindings: mfd: Add UGREEN NASync DH2300 MCU
mfd: Add support for UGREEN NASync DH2300 MCU
regulator: Add support for UGREEN NASync DH2300 MCU SATA power gate
.../devicetree/bindings/mfd/ugreen,dh2300-mcu.yaml | 62 +++++++++++++++++
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
MAINTAINERS | 7 ++
drivers/mfd/Kconfig | 16 +++++
drivers/mfd/Makefile | 1 +
drivers/mfd/ugreen-dh2300-mcu.c | 60 ++++++++++++++++
drivers/regulator/Kconfig | 12 ++++
drivers/regulator/Makefile | 1 +
drivers/regulator/ugreen-dh2300-mcu-regulator.c | 80 ++++++++++++++++++++++
9 files changed, 241 insertions(+)
---
base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
change-id: 20260612-dh2300-mcu-5354d1f5f11a
Best regards,
--
Alexey Charkov <alchark@flipper.net>
^ permalink raw reply
* Re: [PATCH v6 1/3] dt-bindings: imx6q-pcie: Add optional intr/aer/pme interrupts for i.MX95
From: Rob Herring @ 2026-06-12 15:13 UTC (permalink / raw)
To: hongxing.zhu
Cc: krzk+dt, conor+dt, bhelgaas, frank.li, l.stach, lpieralisi,
kwilczynski, mani, s.hauer, kernel, festevam, linux-pci,
linux-arm-kernel, devicetree, imx, linux-kernel, Richard Zhu
In-Reply-To: <20260603062510.3767610-2-hongxing.zhu@oss.nxp.com>
On Wed, Jun 03, 2026 at 02:25:08PM +0800, hongxing.zhu@oss.nxp.com wrote:
> From: Richard Zhu <hongxing.zhu@nxp.com>
>
> The i.MX95 PCIe controller introduces three additional dedicated hardware
> interrupt lines for specific events:
> - intr: general controller events
> - aer: Advanced Error Reporting events
> - pme: Power Management Events
>
> These interrupts are optional on i.MX95. PCIe basic functionality
> (enumeration, configuration, and data transfer) works correctly without
> them, as the controller can operate using only the existing msi interrupt.
>
> Earlier i.MX PCIe variants (imx6q, imx6sx, imx6qp, imx7d, imx8mm, imx8mp,
> imx8mq, imx8q) do not have these three dedicated interrupt lines.
>
> Update the binding to allow up to 5 interrupts for i.MX95, while
> restricting earlier variants to a maximum of 2 interrupts using
> conditional constraints (if/then schema). This ensures the schema
> accurately reflects the hardware capabilities of each SoC variant.
>
> Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> ---
> .../bindings/pci/fsl,imx6q-pcie.yaml | 29 +++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> index e8b8131f5f23..9b5d4e59dfff 100644
> --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml
> @@ -58,12 +58,18 @@ properties:
> items:
> - description: builtin MSI controller.
> - description: builtin DMA controller.
> + - description: PCIe event interrupt.
> + - description: builtin AER SPI standalone interrupt line.
> + - description: builtin PME SPI standalone interrupt line.
>
> interrupt-names:
> minItems: 1
> items:
> - const: msi
> - const: dma
> + - const: intr
> + - const: aer
> + - const: pme
>
> reset-gpio:
> deprecated: true
> @@ -248,6 +254,29 @@ allOf:
> - const: pcie_aux
> - const: ref
> - const: extref # Optional
> + interrupts:
> + maxItems: 5
> + interrupt-names:
> + maxItems: 5
5 is already the max.
> +
> + - if:
> + properties:
> + compatible:
> + enum:
> + - fsl,imx6q-pcie
> + - fsl,imx6sx-pcie
> + - fsl,imx6qp-pcie
> + - fsl,imx7d-pcie
> + - fsl,imx8mm-pcie
> + - fsl,imx8mp-pcie
> + - fsl,imx8mq-pcie
> + - fsl,imx8q-pcie
> + then:
> + properties:
> + interrupts:
> + maxItems: 2
> + interrupt-names:
> + maxItems: 2
>
> unevaluatedProperties: false
>
> --
> 2.34.1
>
^ permalink raw reply
* Re: [PATCH v2 1/5] ASoC: dt-bindings: rockchip-spdif: Correct SPDIF clock descriptions
From: Rob Herring (Arm) @ 2026-06-12 15:12 UTC (permalink / raw)
To: phucduc.bui
Cc: Mark Brown, linux-kernel, Heiko Stuebner, Krzysztof Kozlowski,
linux-sound, Liam Girdwood, Jaroslav Kysela, Conor Dooley,
devicetree, linux-rockchip, linux-arm-kernel, Takashi Iwai
In-Reply-To: <20260602101608.45137-2-phucduc.bui@gmail.com>
On Tue, 02 Jun 2026 17:16:04 +0700, phucduc.bui@gmail.com wrote:
> From: bui duc phuc <phucduc.bui@gmail.com>
>
> Update the binding descriptions to match the actual clock usage, where
> 'mclk' is the controller clock and 'hclk' is the bus clock.
>
> Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> ---
>
> Changes in v2:
> - Update commit message based on Krzysztof's review
>
> Documentation/devicetree/bindings/sound/rockchip-spdif.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: mux-gpio: name correct maintainer
From: Wolfram Sang @ 2026-06-12 15:01 UTC (permalink / raw)
To: linux-i2c
Cc: Peter Korsgaard, Peter Rosin, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260611122053.7306-2-wsa+renesas@sang-engineering.com>
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
On Thu, Jun 11, 2026 at 02:20:53PM +0200, Wolfram Sang wrote:
> The YAML conversion added me as maintainer but I can't recall being
> asked nor do I want to maintain it. Add Peter as maintainer for the
> binding as he is maintainer of the driver.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Applied to for-current, thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: sm8550: add SDHC4 controller node
From: Tendai Makumire @ 2026-06-12 14:56 UTC (permalink / raw)
To: Vladimir Zapolskiy
Cc: William Bright, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, devicetree,
linux-kernel, Ram Boukobza
In-Reply-To: <aca9bd93-9dff-4493-a1c4-daf9ba27aad6@linaro.org>
On Fri, Jun 12, 2026 at 10:11 AM, Vladimir Zapolskiy wrote:
> If Qualcomm supports their downstream Android kernel running on your
> board, it should be worth to contact them.
Hi Vladimir,
I had previously opened a case with Qualcomm when I started trying to get
SDHC4 working on our board and we didn't get very far with them. I did almost
all the work here without their support.
What's interesting to me is that we managed to get SDHC2 working at
UHS-I SDR104 speeds quite early on. And the traces for SDHC4 on our
board are actually shorter than what we have for SDHC2.
The only difference between the two controllers on our board
is that we don't have a level shifter on SDHC4 and the pins are
connected directly to the IW416 without any pullups or pulldowns.
The signals looked clean last time I measured them.
Tendai
On Fri, Jun 12, 2026 at 10:11 AM Vladimir Zapolskiy
<vladimir.zapolskiy@linaro.org> wrote:
>
> On 6/12/26 11:47, William Bright wrote:
> > On Thu, Jun 11, 2026 at 10:48:34AM +0300, Vladimir Zapolskiy wrote:
> >> Looks like the SDHC driver behaves expectedly then. For me it's hard to say
> >> what may be the rootcause, I believe the lower bus frequency should be fine,
> >> so it sounds like a hardware issue, but could it be PCB/board specific one?
> >>
> >> If you find a chance to copy the SDHC driver (and its small dependencies)
> >> from Android and test it on your board, and if it also fails, then it might
> >> be well concluded that something is wrong with hardware, still it won't be
> >> quite convincing that the SoC SDHC is to blame here.
> >>
> >> Hope it helps.
> >>
> > My colleague Tendai (<tendai.makumire@imd-tec.com>) had the same issue
> > with dll-tuning failing in SDR50 when working on the downstream 5.15 msm
> > kernel [1].
>
> If Qualcomm supports their downstream Android kernel running on your
> board, it should be worth to contact them.
>
> > It does sound like a potential SI issue so I will try the following:
> > - Sweeping the drive-strength values for the sdhc_4 lines to see if I
> > can find a set of values that work
> > - Scoping the lines to check SI when performing dll-tuning, our board
> > is very dense so this is challenging.
> > I am guessing this patch is only acceptable to be upstreamed once we get
> > to the bottom of why dll-tuning is failing?
>
> Apparently if Qualcomm confirms that SM8550 SDHC4 actually has this
> discovered and unveiled defect, then this change will be accepted for
> all SM8550 platform like you propose it to be done.
>
> According to my experince SM8550 SDHC2 operates properly in UHS-I
> SDR50/SDR104 speed modes, this can be verified on the reference boards
> like HDK or QRD, and for me it sounds oddly that there is such a problem
> with SDHC4.
>
> If the proposed change as is does not enter upstream for SM8550 SoC, you
> may keep it as a necessary change in your particular board .dts file.
>
> > [1] https://github.com/imd-tec/meta-imdt-qcom/tree/kirkstone/patches/msm-kernel/files
> >
>
> --
> Best wishes,
> Vladimir
^ permalink raw reply
* Re: [PATCH v17 00/17] Add Renesas RZ/G3L SD/eMMC support
From: wsa+renesas @ 2026-06-12 14:56 UTC (permalink / raw)
To: Biju Das
Cc: biju.das.au, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Geert Uytterhoeven, Philipp Zabel, magnus.damm,
linux-mmc@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <TY3PR01MB113460D9FC3AE79E9391DF4C286182@TY3PR01MB11346.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 226 bytes --]
Hi Biju,
> I will send v3 with these changes, if it is ok for you.
Sure, sure. I will review the then latest version once I have time for
it. The more issues already found, the better, of course!
Happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodes
From: Rob Herring @ 2026-06-12 14:50 UTC (permalink / raw)
To: sashiko-reviews; +Cc: Tapio Reijonen, conor+dt, devicetree
In-Reply-To: <20260601113815.8A9821F00893@smtp.kernel.org>
On Mon, Jun 01, 2026 at 11:38:15AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [High] Kernel panic in error path due to uninitialized port structures in `max310x_probe()`
Why does sashiko reply to binding patches with driver issues? Please
stop.
Rob
^ permalink raw reply
* Re: [PATCH v5 09/10] dt-bindings: firmware: add arm,ras-cper
From: Rob Herring @ 2026-06-12 14:49 UTC (permalink / raw)
To: Ahmed Tiba
Cc: Jonathan Cameron, will, xueshuai, saket.dumbre, mchehab, dave,
djbw, bp, tony.luck, guohanjun, lenb, skhan, vishal.l.verma,
rafael, corbet, ira.weiny, dave.jiang, krzk+dt, catalin.marinas,
alison.schofield, conor+dt, linux-arm-kernel, Michael.Zhao2,
linux-doc, linux-kernel, linux-cxl, Dmitry.Lamerov, devicetree,
linux-acpi, linux-edac, acpica-devel
In-Reply-To: <ceb19cb6-7083-44ad-a262-a8198f489257@arm.com>
On Thu, Jun 11, 2026 at 03:22:21PM +0100, Ahmed Tiba wrote:
> On 29/05/2026 17:44, Jonathan Cameron wrote:
> > On Fri, 29 May 2026 10:50:49 +0100
> > Ahmed Tiba<ahmed.tiba@arm.com> wrote:
> > > .../devicetree/bindings/firmware/arm,ras-cper.yaml | 54 ++++++++++++++++++++++
> > > MAINTAINERS | 5 ++
> > > 2 files changed, 59 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
> > > new file mode 100644
> > > index 000000000000..3d4de096093f
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/firmware/arm,ras-cper.yaml
> > > @@ -0,0 +1,54 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id:http://devicetree.org/schemas/firmware/arm,ras-cper.yaml#
> > > +$schema:http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Arm RAS CPER provider
> > > +
> > > +maintainers:
> > > + - Ahmed Tiba<ahmed.tiba@arm.com>
> > > +
> > > +description:
> > > + Arm Reliability, Availability and Serviceability (RAS) firmware can expose
> > > + a firmware-first CPER error source directly via DeviceTree. Firmware
> > > + provides the CPER Generic Error Status block and notifies the OS through
> > > + an interrupt.
> > I'd like some spec references in here if possible.
> I can add a reference to the UEFI CPER specification for the Generic
> Error Status record format.
>
> For the firmware-first DT description itself I do not have a more specific
> public reference to cite.
Is there a platform actually using this with DT (FVP doesn't really
count)?
Rob
^ permalink raw reply
* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: Rob Herring @ 2026-06-12 14:42 UTC (permalink / raw)
To: Wandun Chen
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, alex, saravanak, akpm, bhe,
rppt, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy, quic_obabatun
In-Reply-To: <20260527032917.3385849-1-chenwandun1@gmail.com>
On Wed, May 27, 2026 at 11:29:06AM +0800, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> On SoCs that carve out large firmware-owned reserved memory (GPU
> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
> those carveouts as part of system RAM even though their contents are
> firmware state that is not useful for kernel crash analysis.
>
> This series introduces an opt-in 'dumpable' flag [1] on struct
> reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on
> DT-based architectures (arm64, riscv, loongarch). By default reserved
> regions are treated as non-dumpable; CMA regions are explicitly opted
> in because their pages are returned to the buddy allocator and may
> carry key crash-analysis data.
>
> The series is organized as follows:
> Patches 1-3: Pre-existing fixes and a small prep change.
> Patches 4-5: Restructure to allow appending /memreserve/ entries.
> Patches 6-7: Add a dumpable flag and append /memreserve/ entries.
> Patch 8: Add generic kdump helpers.
> Patches 9-11: Wire the helpers into arm64, riscv and loongarch kdump
> elfcorehdr preparation.
>
> v2 --> v3:
> 1. Fix out-of-bounds issue if device tree lacks /reserved-memory node.[2]
> 2. Fix UAF issue when alloc_reserved_mem_array() fails.
> 3. Add some prepare patches.
>
> v1 --> v2:
> 1. v1 added an opt-out DT property ('linux,no-dump'). Per Rob's
> feedback [1], v2 drop that property and exclude reserve memory
> by default.
> 2. Split some prepared patches from the original patches.
> 3. Address coding-style comments on patch 5 from Rob.
>
> [1] https://lore.kernel.org/lkml/20260506144542.GA2072596-robh@kernel.org/
> [2] https://sashiko.dev/#/patchset/20260520091844.592753-1-chenwandun%40lixiang.com?part=4
>
> Wandun Chen (11):
> of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
> of: reserved_mem: zero total_reserved_mem_cnt if no valid
> /reserved-memory entry
I applied these 2 for 7.2.
Rob
^ permalink raw reply
* Re: [PATCH v3 05/11] of: reserved_mem: split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late()
From: Rob Herring @ 2026-06-12 14:41 UTC (permalink / raw)
To: Wandun Chen
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, alex, saravanak, akpm, bhe,
rppt, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy, quic_obabatun
In-Reply-To: <20260527032917.3385849-6-chenwandun1@gmail.com>
On Wed, May 27, 2026 at 11:29:11AM +0800, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> Prepare for storing /memreserve/ entries in the reserved_mem array.
> alloc_reserved_mem_array is skipped if the device tree lacks a
> /reserved-memory node, pointer 'reserved_mem' continues to reference
> the reserved_mem_array which lives in __initdata, storing
> /memreserve/ entries into reserved_mem_array would result in metadata
> loss, and an out-of-bounds memory access will occur if the device
> tree contains more than MAX_RESERVED_REGIONS /memreserve/ entries.
>
> So split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late(),
> and call alloc_reserved_mem_array() whether or not there is a
> /reserved-memory node.
>
> No functional change.
> The actual /memreserve/ population is added in a follow-up patch.
>
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
> ---
> drivers/of/fdt.c | 7 +++++--
> drivers/of/of_private.h | 1 +
> drivers/of/of_reserved_mem.c | 6 +-----
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 82f7327c59ea..83a2a474831e 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1284,8 +1284,11 @@ void __init unflatten_device_tree(void)
> {
> void *fdt = initial_boot_params;
>
> - /* Save the statically-placed regions in the reserved_mem array */
> - fdt_scan_reserved_mem_late();
> + /* Attempt dynamic allocation of a new reserved_mem array */
> + if (fdt && alloc_reserved_mem_array()) {
> + /* Save the statically-placed regions in the reserved_mem array */
> + fdt_scan_reserved_mem_late();
Can we make this just:
alloc_reserved_mem_array();
fdt_scan_reserved_mem_late();
We already check !fdt in fdt_scan_reserved_mem_late().
Rob
^ permalink raw reply
* Re: [PATCH v6 02/11] ARM: dts: renesas: r8a7740: Add clocks for FSI
From: Geert Uytterhoeven @ 2026-06-12 14:31 UTC (permalink / raw)
To: Bui Duc Phuc
Cc: Kuninori Morimoto, Mark Brown, Liam Girdwood, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Jaroslav Kysela,
Takashi Iwai, linux-sound, linux-renesas-soc, devicetree,
linux-kernel
In-Reply-To: <CAABR9nG2kHH3=gkd0H+vhGZJtvkHLA7YMpoWt+p+XtdNV+oe=A@mail.gmail.com>
Hi Phuc,
On Fri, 12 Jun 2026 at 14:54, Bui Duc Phuc <phucduc.bui@gmail.com> wrote:
> > According to my schematics (RevA), R120 is not populated, but R250 is.
> > So the 12.288 MHz clock is fed to both the FSIACK-pin of R-Mobile A1,
> > and the MCLK-pin of the WM8978 codec.
> > Which revision of the schematics and board do you have?
> >
>
> Oh, sorry, I misread it. You're right, mine is also Rev A, and R120 is
> not populated, but R250 is.
>
> > I haven't located R120 and R250 yet, so I don't know which
> > configuration my board has.
>
> Please flip the board over; these resistors are located on the bottom
> side of the board rather than the top.
Thanks, confirmed.
Have a nice weekend!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
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