* Re: [PATCH v1] media: rkisp1: Add support for CAC
From: Laurent Pinchart @ 2026-03-31 13:39 UTC (permalink / raw)
To: Jacopo Mondi
Cc: Barnabás Pőcze, Dafna Hirschfeld, Mauro Carvalho Chehab,
Heiko Stuebner, linux-media, linux-rockchip, linux-arm-kernel,
linux-kernel
In-Reply-To: <acu-j4hm0g8pTeAF@zed>
On Tue, Mar 31, 2026 at 02:42:33PM +0200, Jacopo Mondi wrote:
> On Mon, Mar 30, 2026 at 04:40:18PM +0200, Barnabás Pőcze wrote:
> > 2026. 03. 25. 16:21 keltezéssel, Jacopo Mondi írta:
> > > On Mon, Mar 23, 2026 at 03:02:16PM +0100, Barnabás Pőcze wrote:
> > > > The CAC block implements chromatic aberration correction. Expose it to
> > > > userspace using the extensible parameters format. This was tested on the
> > > > i.MX8MP platform, but based on available documentation it is also present
> > > > in the RK3399 variant (V10). Thus presumably also in later versions,
> > > > so no feature flag is introduced.
> > > >
> > > > Signed-off-by: Barnabás Pőcze <barnabas.pocze@ideasonboard.com>
> > >
> > > Only minors..
> > >
> > > > ---
> > > > .../platform/rockchip/rkisp1/rkisp1-params.c | 69 ++++++++++++
> > > > .../platform/rockchip/rkisp1/rkisp1-regs.h | 21 +++-
> > > > include/uapi/linux/rkisp1-config.h | 106 +++++++++++++++++-
> > > > 3 files changed, 193 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
> > > > index 6442436a5e428..b889af9dcee45 100644
> > > > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
> > > > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-params.c
> > > > @@ -64,6 +64,7 @@ union rkisp1_ext_params_config {
> > > > struct rkisp1_ext_params_compand_bls_config compand_bls;
> > > > struct rkisp1_ext_params_compand_curve_config compand_curve;
> > > > struct rkisp1_ext_params_wdr_config wdr;
> > > > + struct rkisp1_ext_params_cac_config cac;
> > > > };
> > > >
> > > > enum rkisp1_params_formats {
> > > > @@ -1413,6 +1414,48 @@ static void rkisp1_wdr_config(struct rkisp1_params *params,
> > > > RKISP1_CIF_ISP_WDR_TONE_CURVE_YM_MASK);
> > > > }
> > > >
> > > > +static void
> > > > +rkisp1_cac_config(struct rkisp1_params *params,
> > > > + const struct rkisp1_cif_isp_cac_config *arg)
> > >
> > > Fits in one line without going over 80 cols
> >
> > This is what the other functions looks like, so went this this.
>
> It seems to me not all of them are broken, but only the ones that go
> over 80 cols
>
> in example:
>
> static void rkisp1_dpf_config(struct rkisp1_params *params,
> const struct rkisp1_cif_isp_dpf_config *arg)
>
> A detail anyway, up to you
>
> > > > +{
> > > > + u32 regval;
All other functions in this file name similar variables "val", "value"
or "reg_val". Let's not introduce a fourth one. I have a small
preference for "val", but that's not mandatory.
> > > > +
> > > > + /*
> > > > + * The enable bit is in the same register (RKISP1_CIF_ISP_CAC_CTRL),
> > > > + * so only set the clipping mode, and do not modify the other bits.
> > > > + */
> > > > + regval = rkisp1_read(params->rkisp1, RKISP1_CIF_ISP_CAC_CTRL);
> > > > + regval &= ~(RKISP1_CIF_ISP_CAC_CTRL_H_CLIP_MODE |
> > > > + RKISP1_CIF_ISP_CAC_CTRL_V_CLIP_MODE);
> > > > + regval |= FIELD_PREP(RKISP1_CIF_ISP_CAC_CTRL_H_CLIP_MODE, arg->h_clip_mode) |
> > > > + FIELD_PREP(RKISP1_CIF_ISP_CAC_CTRL_V_CLIP_MODE, arg->v_clip_mode);
> > > > + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_CTRL, regval);
> > > > +
> > > > + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_COUNT_START_H_MASK, arg->h_count_start) |
> > > > + FIELD_PREP(RKISP1_CIF_ISP_CAC_COUNT_START_V_MASK, arg->v_count_start);
> > > > + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_COUNT_START, regval);
> > > > +
> > > > + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_A_RED_MASK, arg->red[0]) |
> > > > + FIELD_PREP(RKISP1_CIF_ISP_CAC_A_BLUE_MASK, arg->blue[0]);
> > > > + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_A, regval);
> > > > +
> > > > + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_B_RED_MASK, arg->red[1]) |
> > > > + FIELD_PREP(RKISP1_CIF_ISP_CAC_B_BLUE_MASK, arg->blue[1]);
> > > > + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_B, regval);
> > > > +
> > > > + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_C_RED_MASK, arg->red[2]) |
> > > > + FIELD_PREP(RKISP1_CIF_ISP_CAC_C_BLUE_MASK, arg->blue[2]);
> > > > + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_C, regval);
> > > > +
> > > > + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_X_NORM_NF_MASK, arg->x_nf) |
> > > > + FIELD_PREP(RKISP1_CIF_ISP_CAC_X_NORM_NS_MASK, arg->x_ns);
> > > > + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_X_NORM, regval);
> > > > +
> > > > + regval = FIELD_PREP(RKISP1_CIF_ISP_CAC_Y_NORM_NF_MASK, arg->y_nf) |
> > > > + FIELD_PREP(RKISP1_CIF_ISP_CAC_Y_NORM_NS_MASK, arg->y_ns);
> > > > + rkisp1_write(params->rkisp1, RKISP1_CIF_ISP_CAC_Y_NORM, regval);
> > > > +}
> > > > +
> > > > static void
> > > > rkisp1_isp_isr_other_config(struct rkisp1_params *params,
> > > > const struct rkisp1_params_cfg *new_params)
> > > > @@ -2089,6 +2132,25 @@ static void rkisp1_ext_params_wdr(struct rkisp1_params *params,
> > > > RKISP1_CIF_ISP_WDR_CTRL_ENABLE);
> > > > }
> > > >
> > > > +static void rkisp1_ext_params_cac(struct rkisp1_params *params,
> > > > + const union rkisp1_ext_params_config *block)
> > > > +{
> > > > + const struct rkisp1_ext_params_cac_config *cac = &block->cac;
> > > > +
> > > > + if (cac->header.flags & RKISP1_EXT_PARAMS_FL_BLOCK_DISABLE) {
> > > > + rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_CAC_CTRL,
> > > > + RKISP1_CIF_ISP_CAC_CTRL_ENABLE);
> > > > + return;
> > > > + }
> > > > +
> > > > + rkisp1_cac_config(params, &cac->config);
> > > > +
> > > > + if ((cac->header.flags & RKISP1_EXT_PARAMS_FL_BLOCK_ENABLE) &&
> > > > + !(params->enabled_blocks & BIT(cac->header.type)))
> > > > + rkisp1_param_set_bits(params, RKISP1_CIF_ISP_CAC_CTRL,
> > > > + RKISP1_CIF_ISP_CAC_CTRL_ENABLE);
> > > > +}
> > > > +
> > > > typedef void (*rkisp1_block_handler)(struct rkisp1_params *params,
> > > > const union rkisp1_ext_params_config *config);
> > > >
> > > > @@ -2185,6 +2247,10 @@ static const struct rkisp1_ext_params_handler {
> > > > .handler = rkisp1_ext_params_wdr,
> > > > .group = RKISP1_EXT_PARAMS_BLOCK_GROUP_OTHERS,
> > > > },
> > > > + [RKISP1_EXT_PARAMS_BLOCK_TYPE_CAC] = {
> > > > + .handler = rkisp1_ext_params_cac,
> > > > + .group = RKISP1_EXT_PARAMS_BLOCK_GROUP_OTHERS,
> > > > + },
> > > > };
> > > >
> > > > #define RKISP1_PARAMS_BLOCK_INFO(block, data) \
> > > > @@ -2215,6 +2281,7 @@ rkisp1_ext_params_block_types_info[] = {
> > > > RKISP1_PARAMS_BLOCK_INFO(COMPAND_EXPAND, compand_curve),
> > > > RKISP1_PARAMS_BLOCK_INFO(COMPAND_COMPRESS, compand_curve),
> > > > RKISP1_PARAMS_BLOCK_INFO(WDR, wdr),
> > > > + RKISP1_PARAMS_BLOCK_INFO(CAC, cac),
> > > > };
> > > >
> > > > static_assert(ARRAY_SIZE(rkisp1_ext_params_handlers) ==
> > > > @@ -2474,6 +2541,8 @@ void rkisp1_params_disable(struct rkisp1_params *params)
> > > > rkisp1_ie_enable(params, false);
> > > > rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_DPF_MODE,
> > > > RKISP1_CIF_ISP_DPF_MODE_EN);
> > > > + rkisp1_param_clear_bits(params, RKISP1_CIF_ISP_CAC_CTRL,
> > > > + RKISP1_CIF_ISP_CAC_CTRL_ENABLE);
> > > > }
> > > >
> > > > static const struct rkisp1_params_ops rkisp1_v10_params_ops = {
> > > > diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> > > > index fbeb186cde0d5..8e25537459bbd 100644
> > > > --- a/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> > > > +++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-regs.h
> > > > @@ -724,6 +724,23 @@
> > > > #define RKISP1_CIF_ISP_WDR_DMIN_STRENGTH_MASK GENMASK(20, 16)
> > > > #define RKISP1_CIF_ISP_WDR_DMIN_STRENGTH_MAX 16U
> > > >
> > > > +/* CAC */
> > > > +#define RKISP1_CIF_ISP_CAC_CTRL_ENABLE BIT(0)
> > > > +#define RKISP1_CIF_ISP_CAC_CTRL_V_CLIP_MODE GENMASK(2, 1)
> > > > +#define RKISP1_CIF_ISP_CAC_CTRL_H_CLIP_MODE GENMASK(3, 3)
I'd go for BIT(3) as you use BIT(0) for the enable bit.
> > > > +#define RKISP1_CIF_ISP_CAC_COUNT_START_H_MASK GENMASK(12, 0)
> > > > +#define RKISP1_CIF_ISP_CAC_COUNT_START_V_MASK GENMASK(28, 16)
> > > > +#define RKISP1_CIF_ISP_CAC_A_RED_MASK GENMASK(8, 0)
> > > > +#define RKISP1_CIF_ISP_CAC_A_BLUE_MASK GENMASK(24, 16)
> > > > +#define RKISP1_CIF_ISP_CAC_B_RED_MASK GENMASK(8, 0)
> > > > +#define RKISP1_CIF_ISP_CAC_B_BLUE_MASK GENMASK(24, 16)
> > > > +#define RKISP1_CIF_ISP_CAC_C_RED_MASK GENMASK(8, 0)
> > > > +#define RKISP1_CIF_ISP_CAC_C_BLUE_MASK GENMASK(24, 16)
> > >
> > > All these masks for coefficients 0, 1 and 2 are identical. Maybe
> > > #define RKISP1_CIF_ISP_CAC_RED_MASK GENMASK(8, 0)
> > > #define RKISP1_CIF_ISP_CAC_BLUE_MASK GENMASK(24, 16)
> > >
> > > is enough
> >
> > Adjusted.
> >
> > > > +#define RKISP1_CIF_ISP_CAC_X_NORM_NF_MASK GENMASK(4, 0)
> > > > +#define RKISP1_CIF_ISP_CAC_X_NORM_NS_MASK GENMASK(19, 16)
> > > > +#define RKISP1_CIF_ISP_CAC_Y_NORM_NF_MASK GENMASK(4, 0)
> > > > +#define RKISP1_CIF_ISP_CAC_Y_NORM_NS_MASK GENMASK(19, 16)
> >
> > Did the same with these as well.
>
> Ah thanks!
>
> > > > +
> > > > /* =================================================================== */
> > > > /* CIF Registers */
> > > > /* =================================================================== */
> > > > @@ -1196,8 +1213,8 @@
> > > > #define RKISP1_CIF_ISP_CAC_A (RKISP1_CIF_ISP_CAC_BASE + 0x00000008)
> > > > #define RKISP1_CIF_ISP_CAC_B (RKISP1_CIF_ISP_CAC_BASE + 0x0000000c)
> > > > #define RKISP1_CIF_ISP_CAC_C (RKISP1_CIF_ISP_CAC_BASE + 0x00000010)
> > > > -#define RKISP1_CIF_ISP_X_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000014)
> > > > -#define RKISP1_CIF_ISP_Y_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000018)
> > > > +#define RKISP1_CIF_ISP_CAC_X_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000014)
> > > > +#define RKISP1_CIF_ISP_CAC_Y_NORM (RKISP1_CIF_ISP_CAC_BASE + 0x00000018)
> > > >
> > > > #define RKISP1_CIF_ISP_EXP_BASE 0x00002600
> > > > #define RKISP1_CIF_ISP_EXP_CTRL (RKISP1_CIF_ISP_EXP_BASE + 0x00000000)
> > > > diff --git a/include/uapi/linux/rkisp1-config.h b/include/uapi/linux/rkisp1-config.h
> > > > index b2d2a71f7baff..d8acccaddd0e9 100644
> > > > --- a/include/uapi/linux/rkisp1-config.h
> > > > +++ b/include/uapi/linux/rkisp1-config.h
> > > > @@ -967,6 +967,92 @@ struct rkisp1_cif_isp_wdr_config {
> > > > __u8 use_iref;
> > > > };
> > > >
> > > > +/*
> > > > + * enum rkisp1_cif_isp_cac_h_clip_mode - horizontal clipping mode
> > > > + *
> > > > + * @RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4PX: +/- 4 pixels
> > > > + * @RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4_5PX: +/- 4/5 pixels depending on bayer position
> > > > + */
> > > > +enum rkisp1_cif_isp_cac_h_clip_mode {
> > > > + RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4PX = 0,
> > > > + RKISP1_CIF_ISP_CAC_H_CLIP_MODE_4_5PX = 1,
> > > > +};
> > > > +
> > > > +/**
> > > > + * enum rkisp1_cif_isp_cac_v_clip_mode - vertical clipping mode
> > > > + *
> > > > + * @RKISP1_CIF_ISP_CAC_V_CLIP_MODE_2PX: +/- 2 pixels
> > > > + * @RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3PX: +/- 3 pixels
> > > > + * @RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3_4PX: +/- 3/4 pixels depending on bayer position
> > > > + */
> > > > +enum rkisp1_cif_isp_cac_v_clip_mode {
> > > > + RKISP1_CIF_ISP_CAC_V_CLIP_MODE_2PX = 0,
> > > > + RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3PX = 1,
> > > > + RKISP1_CIF_ISP_CAC_V_CLIP_MODE_3_4PX = 2,
> > > > +};
> > > > +
> > > > +/**
> > > > + * struct rkisp1_cif_isp_cac_config - chromatic aberration correction configuration
> > > > + *
> > > > + * The correction is carried out by shifting the red and blue pixels relative
> > > > + * to the green ones, depending on the distance from the optical center:
> > >
> > > Yes, the distance to the center is one parameter, but the shifting
> > > amount depends on other things. I would drop the last part of the
> > > sentence and move the description of the two below fields after the
> > > text
> >
> > That's true, but within a specific image, the only varying quantity
> > is the distance, so I think it is important to emphasize that.
> >
> > And I also quite like this structure of
> > - description of step
> > - parameters of step
> > - description of step
> > ...
> >
> > so I would love to keep it like this, if that's ok?
>
> Ok!
Ack.
> > > > + *
> > > > + * @h_count_start: horizontal coordinate of the optical center (13-bit unsigned integer; [1,8191])
> > > > + * @v_count_start: vertical coordinate of the optical center (13-bit unsigned integer; [1,8191])
> > >
> > > so these could go just before @x_nf
> > >
> > > > + *
> > > > + * For each pixel, the x/y distances from the optical center are calculated and
> > >
> > > I forgot: did we establish that the correction is applied to the
> > > euclidean distance or to x and y separately ?
> >
> > Given that there are two sets of "normalization" parameters, the assumption is that
> > at least the x/y distances are transformed separately. I see two reasonable choices
> > after that: (a) use the two distances separately, (b) use the radial distance. The
> > documentation says (b). However, testing with sensor test patterns suggests that
> > it is not the case (a horizontal/vertical boundary between appropriately colored
> > regions should have a curvature after the transformation with appropriate parameters).
>
> I now recall that you have been able to shift just one plan when using
> the sensor's test pattern
I agree about the normalization, but it sounds really weird that the
hardware would then shift separately in the X and Y directions. Below
you document the radial correction formula, which looks correct to me.
> > > > + * then transformed into the [0,255] range based on the following formula:
> > >
> > > s/transformed/normalized ?
> >
> > To be honest I vastly prefer "transform" / "map" over "normalize" here.
>
> You're right here, the below formula doesn't normalize the
> distance in an interval but just re-scale it
>
> > > > + *
> > > > + * (((d << 4) >> s) * f) >> 5
> > > > + *
> > > > + * where `d` is the distance, `s` and `f` are the normalization parameters:
> > >
> > > Can you use 'ns' and 'nf' to match the below ?
> >
> > Adjusted.
>
> Thanks!
>
> > > > + *
> > > > + * @x_nf: horizontal normalization scale parameter (5-bit unsigned integer; [0,31])
> > > > + * @x_ns: horizontal normalization shift parameter (4-bit unsigned integer; [0,15])
> > > > + *
> > > > + * @y_nf: vertical normalization scale parameter (5-bit unsigned integer; [0,31])
> > > > + * @y_ns: vertical normalization shift parameter (4-bit unsigned integer; [0,15])
> > > > + *
> > > > + * These parameters should be chosen based on the image resolution, the position
> > > > + * of the optical center, and the shape of pixels: so that no normalized distance
> > >
> > > s/pixels:/pixels/
> >
> > Replaced `:` with `,`.
> >
> > > > + * is larger than 255. If the pixels have square shape, the two sets of parameters
> > > > + * should be equal.
I wonder if we could have anisotropic lenses (from the point of view of
chromatic aberrations) with square pixels. We can deal with it later.
> > > > + *
> > > > + * The actual amount of correction is calculated with a third degree polynomial:
> > > > + *
> > > > + * c[0] * r + c[1] * r^2 + c[2] * r^3
> > > > + *
> > > > + * where `c` is the set of coefficients for the given color, and `r` is distance:
> > > > + *
> > > > + * @red: red coefficients (5.4 two's complement; [-16,15.9375])
> > > > + * @blue: blue coefficients (5.4 two's complement; [-16,15.9375])
> > > > + *
> > > > + * Finally, the amount is clipped as requested:
> > > > + *
> > > > + * @h_clip_mode: maximum horizontal shift (from enum rkisp1_cif_isp_cac_h_clip_mode)
> > > > + * @v_clip_mode: maximum vertical shift (from enum rkisp1_cif_isp_cac_v_clip_mode)
> > > > + *
> > > > + * A positive result will shift away from the optical center, while a negative
> > > > + * one will shift towards the optical center. In the latter case, the pixel
> > > > + * values at the edges are duplicated.
> > > > + */
> > > > +struct rkisp1_cif_isp_cac_config {
> > > > + __u8 h_clip_mode;
> > > > + __u8 v_clip_mode;
> > > > +
> > > > + __u16 h_count_start;
> > > > + __u16 v_count_start;
> > > > +
> > > > + __u16 red[3];
> > > > + __u16 blue[3];
> > > > +
> > > > + __u8 x_nf;
> > > > + __u8 x_ns;
> > > > +
> > > > + __u8 y_nf;
> > > > + __u8 y_ns;
> > > > +};
> > > > +
> > > > /*---------- PART2: Measurement Statistics ------------*/
> > > >
> > > > /**
> > > > @@ -1161,6 +1247,7 @@ enum rkisp1_ext_params_block_type {
> > > > RKISP1_EXT_PARAMS_BLOCK_TYPE_COMPAND_EXPAND,
> > > > RKISP1_EXT_PARAMS_BLOCK_TYPE_COMPAND_COMPRESS,
> > > > RKISP1_EXT_PARAMS_BLOCK_TYPE_WDR,
> > > > + RKISP1_EXT_PARAMS_BLOCK_TYPE_CAC,
> > > > };
> > > >
> > > > /* For backward compatibility */
> > > > @@ -1507,6 +1594,22 @@ struct rkisp1_ext_params_wdr_config {
> > > > struct rkisp1_cif_isp_wdr_config config;
> > > > } __attribute__((aligned(8)));
> > > >
> > > > +/**
> > > > + * struct rkisp1_ext_params_cac_config - RkISP1 extensible params CAC config
> > > > + *
> > > > + * RkISP1 extensible parameters CAC block.
> > > > + * Identified by :c:type:`RKISP1_EXT_PARAMS_BLOCK_TYPE_CAC`.
> > > > + *
> > > > + * @header: The RkISP1 extensible parameters header, see
> > > > + * :c:type:`rkisp1_ext_params_block_header`
> > > > + * @config: CAC configuration, see
> > > > + * :c:type:`rkisp1_cif_isp_cac_config`
> > > > + */
> > > > +struct rkisp1_ext_params_cac_config {
> > > > + struct rkisp1_ext_params_block_header header;
> > > > + struct rkisp1_cif_isp_cac_config config;
> > > > +} __attribute__((aligned(8)));
> > > > +
> > > > /*
> > > > * The rkisp1_ext_params_compand_curve_config structure is counted twice as it
> > > > * is used for both the COMPAND_EXPAND and COMPAND_COMPRESS block types.
> > > > @@ -1532,7 +1635,8 @@ struct rkisp1_ext_params_wdr_config {
> > > > sizeof(struct rkisp1_ext_params_compand_bls_config) +\
> > > > sizeof(struct rkisp1_ext_params_compand_curve_config) +\
> > > > sizeof(struct rkisp1_ext_params_compand_curve_config) +\
> > > > - sizeof(struct rkisp1_ext_params_wdr_config))
> > > > + sizeof(struct rkisp1_ext_params_wdr_config) +\
> > > > + sizeof(struct rkisp1_ext_params_cac_config))
> > >
> > > All minors, please add
> > > Reviewed-by: Jacopo Mondi <jacopo.mondi@ideasonboard.com>
and
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> > > >
> > > > /**
> > > > * enum rksip1_ext_param_buffer_version - RkISP1 extensible parameters version
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Khristine Andreea Barbulescu @ 2026-03-31 13:43 UTC (permalink / raw)
To: Arnd Bergmann, Krzysztof Kozlowski, Ghennadi Procopciuc
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
Aisheng Dong, Jacky Bai, Greg Kroah-Hartman, Rafael J . Wysocki,
Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, open list:GPIO SUBSYSTEM,
linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
Vincent Guittot, Rob Herring
In-Reply-To: <e1c341d6-e60d-4200-a094-48667e8ccd5c@app.fastmail.com>
On 3/31/2026 1:11 PM, Arnd Bergmann wrote:
> On Tue, Mar 31, 2026, at 09:48, Khristine Andreea Barbulescu wrote:
>>
>> With the current layout, the SIUL2 node itself now contains the two
>> MMIO ranges directly, while the remaining child node is only the
>> pinctrl/GPIO function.
>
> The thread started by saying this is an MFD "It can export information
> about the SoC, configure the pinmux&pinconf for pins and it is also
> a GPIO controller with interrupt capability." Having a combined
> pinctrl/gpio/irqchip driver is normal, but can you clarify what
> you plan to do with the "information about the SoC" part?
>
> Was this a "soc_device" driver, or something else? Have you
> concluded now that this is not going to be needed at all?
> In that case, I guess having a monolithic driver is
> indeed simpler than an MFD.
>
Hi Arnd,
Our initial intention had been to expose that SoC-information as
discussed in the earlier revisions of this series. However,
taking the review feedback into account, the current direction is
to stop handling those SoC information registers in the Linux driver
altogether and instead rely on a boot firmware to pass that
information forward, as you suggested.
With this approach, the SIUL2 driver would no longer be responsible
for any separate SoC-information functionality. In that case,
I understand your point that a monolithic pinctrl/GPIO/irqchip
driver is a better fit than keeping the MFD structure.
> What I wonder about then is whether the binding needs to be changed
> at all. With the current nxp,s32g2-siul2-pinctrl.yaml binding
> and pinctrl-s32g2.c implementation, you seem to have a monolithic
> device already, though missing the gpio functionality. Rather
> than completely replacing this, I assume the easiest way then
> would be to add the PGPD registers into this device node, right?
>
There is indeed the option of extending the current
nxp,s32g2-siul2-pinctrl.yaml binding and adding the GPIO related
register areas to that existing device node.
> It is still a bit weird to list the individual register areas
> inside of the larger device here, but that still seems better
> than an incompatible binding change.
>
> Arnd
However, as you mentioned, this is still weird because it means
listing individual register areas of the larger device inside.
For this reason, I was wondering whether it would still be
acceptable to move forward with the new binding introduced
in this series, but simplify it so that it describes a single
monolithic SIUL2 pinctrl/GPIO device instead of an MFD,
following the example node I included in my previous reply [1].
[1] https://lore.kernel.org/linux-gpio/20260120115923.3463866-4-khristineandreea.barbulescu@oss.nxp.com/T/#m778088251774a15bde7463350d6e75d5e9b9b57d
Best regards,
Khristine
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Pekka Paalanen @ 2026-03-31 13:52 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Maxime Ripard, Nicolas Frattaroli, Harry Wentland, Leo Li,
Rodrigo Siqueira, Alex Deucher, Christian König,
David Airlie, Simona Vetter, Maarten Lankhorst, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc, Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <accfKbYPbH7EgAMc@intel.com>
[-- Attachment #1: Type: text/plain, Size: 11077 bytes --]
On Sat, 28 Mar 2026 02:22:01 +0200
Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> On Thu, Mar 26, 2026 at 07:58:25PM +0200, Ville Syrjälä wrote:
> > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > > > + * semantics.
> > > > > > > > > > > + *
> > > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > > > + *
> > > > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > > > + * how HDMI does it).
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > +
> > > > > > > > > > > + /**
> > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > + */
> > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > >
> > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > should be for each format.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > by other properties.
> > > > > > > > >
> > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > >
> > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > >
> > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > >
> > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > field of its own?
> > > > > >
> > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > I think the assumption is limited range everywhere.
> > > > > >
> > > > > > But I'm not really concerned about documenting struct members.
> > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > will want to know what the new property actually does so the
> > > > > > uapi needs to be documented properly. And down the line some
> > > > > > new driver might also implement the wrong behaviour if there
> > > > > > is no clear specification.
> > > > >
> > > > > Ack
> > > > >
> > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > - YCbCr limited range
> > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > >
> > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > anything else full range?
> > > >
> > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > those would always go hand in hand now.
> > >
> > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > and uses the HDMI state helpers.
> > >
> > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > drm_default_rgb_quant_range() which seems suspicious?
> >
> > If they want just manual full vs. limited then they should
> > limit the property to not expose the "auto" option at all.
> >
> > amdgpu also ties this in with the "colorspace" property, which
> > originally in i915 only controlled the infoframes/etc. But on
> > amdgpu it now controls various aspects of output color
> > transformation. The end result is that the property is a complete
> > mess with most of the values making no sense. And for whatever
> > reason everyone involved refused to remove/deprecate the
> > nonsensical values :/
> >
> > Looks like this series should make sure the documentation for
> > the "colorspace" property is in sync with the new property
> > as well. Currently now it's giving conflicting information.
>
> After pondering about this a bit more I guess we could actually
> use this to make all the values of the colorspace property make
> some sense.
>
> Since we won't have to worry about that RGB->YCbCr 4:2:0
> fallback when using and explicit color format, all we'd have
> to do is explicitly reject the nonsensical combinations:
>
> color_format_and_colorspace_ok()
> {
> switch (color_format) {
> case DRM_CONNECTOR_COLOR_FORMAT_YCBCR444:
> case DRM_CONNECTOR_COLOR_FORMAT_YCBCR422:
> case DRM_CONNECTOR_COLOR_FORMAT_YCBCR420:
> switch (colorspace) {
> case DRM_MODE_COLORIMETRY_NO_DATA:
> case DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> case DRM_MODE_COLORIMETRY_BT601_YCC:
> case DRM_MODE_COLORIMETRY_BT709_YCC:
> case DRM_MODE_COLORIMETRY_XVYCC_601:
> case DRM_MODE_COLORIMETRY_XVYCC_709:
> case DRM_MODE_COLORIMETRY_SYCC_601:
> case DRM_MODE_COLORIMETRY_OPYCC_601:
> case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> case DRM_MODE_COLORIMETRY_BT2020_YCC:
> case DRM_MODE_COLORIMETRY_BT709_YCC:
> return true;
> default:
> return false;
> }
> break;
> case DRM_CONNECTOR_COLOR_FORMAT_RGB444:
> switch (colorspace) {
> case DRM_MODE_COLORIMETRY_NO_DATA:
> case DRM_MODE_COLORIMETRY_OPRGB:
> case DRM_MODE_COLORIMETRY_BT2020_RGB:
> case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> case DRM_MODE_COLORIMETRY_DCI_P3_RGB_THEATER:
> case DRM_MODE_COLORIMETRY_RGB_WIDE_FIXED:
> case DRM_MODE_COLORIMETRY_RGB_WIDE_FLOAT:
> case DRM_MODE_COLORIMETRY_OPRGB:
> case DRM_MODE_COLORIMETRY_DCI_P3_RGB_D65:
> case DRM_MODE_COLORIMETRY_BT2020_RGB:
> return true;
> default
> return false;
> }
> break;
> case DRM_CONNECTOR_COLOR_FORMAT_AUTO:
> switch (colorspace) {
> case DRM_MODE_COLORIMETRY_NO_DATA:
> case DRM_MODE_COLORIMETRY_BT2020_RGB:
> case DRM_MODE_COLORIMETRY_BT2020_YCC:
> return true;
> default:
> return false;
> }
> default:
> bad;
> }
> }
>
> And then presumably the colorspace property is the thing that should
> dictate which conversion matrix to use. So something like this:
>
> csc_matrix()
> {
> switch (colorspace) {
> case DRM_MODE_COLORIMETRY_SMPTE_170M_YCC:
> case DRM_MODE_COLORIMETRY_BT601_YCC:
> case DRM_MODE_COLORIMETRY_XVYCC_601:
> case DRM_MODE_COLORIMETRY_SYCC_601:
> case DRM_MODE_COLORIMETRY_OPYCC_601:
> return 601;
> case DRM_MODE_COLORIMETRY_BT709_YCC:
> case DRM_MODE_COLORIMETRY_XVYCC_709:
> return 709;
> case DRM_MODE_COLORIMETRY_BT2020_YCC:
> case DRM_MODE_COLORIMETRY_BT2020_RGB:
> return 2020;
> case DRM_MODE_COLORIMETRY_BT2020_CYCC:
> return 2020_const;
> case DRM_MODE_COLORIMETRY_NO_DATA:
> return vdisplay >= 720 ? 709 : 601;
> default:
> bad;
> }
> }
>
Hi Ville,
I believe the RGB-to-YCbCr matrix choice belongs in a colorop in the
CRTC color pipeline. It would be really nice to let go of the
requirement that the KMS color pipeline can be only in full-range RGB.
I imagine being able to scan out a YCbCr limited range buffer as-is
would be really useful for professional broadcasting industry and
particularly PLUGE testing which relies on being able to send the
sub-black and super-white YCbCr values for monitor calibration.
However, if there is an "auto" value in the colorop (implies the
input to the colorop must be full-range RGB) or the colorop is missing,
then your proposal could be used there.
Thanks,
pq
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v12 0/3] of: parsing of multi #{iommu,msi}-cells in maps
From: Vijayanand Jitta @ 2026-03-31 14:04 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, 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,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Vijayanand Jitta, Charan Teja Kalla
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.
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
Robin,
Could this series be pulled into an immutable branch/tag, if it doesn't make
it into the v7.1 merge window? There are client changes dependent on it,
So it would help to get them moving forward rather than waiting another
cycle.
Thanks,
Vijay
V12:
- Call of_node_put() unconditionally in imx_pcie_add_lut_by_rid()
thereby addressing comments from Bjorn Helgaas.
Link to v11:
https://lore.kernel.org/r/20260325-parse_iommu_cells-v11-0-1fefa5c0e82c@oss.qualcomm.com
V11:
- Added explicit filter_np parameter to of_map_id() and of_map_msi_id()
per Dmitry Baryshkov's review feedback, making the filter explicit
instead of overloading arg->np as both input filter and output parameter.
- Removed of_node_put() from inside of_map_id(), making the caller responsible
for reference management. Updated of_msi_xlate() to properly handle reference counting.
- Collected ACKed by tags, and fixed minor typos.
Link to v10:
https://lore.kernel.org/r/20260309-parse_iommu_cells-v10-0-c62fcaa5a1d8@oss.qualcomm.com
V10:
- Move of_map_iommu_id()/of_map_msi_id() from include/linux/of.h to
drivers/of/base.c as out-of-line helpers per feedback from Marc Zyngier
and Rob Herring.
- Add kernel-doc to document both helpers for discoverability and
usage clarity.
- Fix of_map_msi_id() wrapper and all its callers (cdx_msi.c,
irq-gic-its-msi-parent.c, drivers/of/irq.c) to correctly use the new
struct of_phandle_args-based API with proper of_node_put() handling
as per feeback from Dmitry.
Link to v9:
https://lore.kernel.org/r/20260301-parse_iommu_cells-v9-0-4d1bceecc5e1@oss.qualcomm.com
V9:
- Updated TO/CC list based on feedback to include all relevant
maintainers.
- No functional changes to the patches themselves.
Link to V8:
https://lore.kernel.org/all/20260226074245.3098486-1-vijayanand.jitta@oss.qualcomm.com/
V8:
- Removed mentions of of_map_args from commit message to match code.
Link to V7:
https://lore.kernel.org/all/20260210101157.2145113-1-vijayanand.jitta@oss.qualcomm.com/
V7:
- Removed of_map_id_args structure and replaced it with
of_phandle_args as suggested by Dmitry.
Link to V6:
https://lore.kernel.org/all/20260121055400.937856-1-vijayanand.jitta@oss.qualcomm.com/
V6:
- Fixed build error reported by kernel test bot.
Link to V5:
https://lore.kernel.org/all/20260118181125.1436036-1-vijayanand.jitta@oss.qualcomm.com/
V5:
- Fixed Build Warnings.
- Raised PR for iommu-map dtschema: https://github.com/devicetree-org/dt-schema/pull/184
Link to V4:
https://lore.kernel.org/all/20251231114257.2382820-1-vijayanand.jitta@oss.qualcomm.com/
V4:
- Added Reviewed-by tag.
- Resolved warnings reported by kernel test bot, minor code
reorganization.
Link to V3:
https://lore.kernel.org/all/20251221213602.2413124-1-vijayanand.jitta@oss.qualcomm.com/
V3:
- Added Reviewed-by tag.
- Updated of_map_id_args struct as a wrapper to of_phandle_args and
added comment description as suggested by Rob Herring.
Link to V2:
https://lore.kernel.org/all/20251204095530.8627-1-vijayanand.jitta@oss.qualcomm.com/
V2:
- Incorporated the patches from Robin that does the clean implementation.
- Dropped the patches the were adding multi-map support from this series
as suggested.
V1:
https://lore.kernel.org/all/cover.1762235099.git.charan.kalla@oss.qualcomm.com/
RFC:
https://lore.kernel.org/all/20250928171718.436440-1-charan.kalla@oss.qualcomm.com/#r
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
---
Charan Teja Kalla (1):
of: Factor arguments passed to of_map_id() into a struct
Robin Murphy (2):
of: Add convenience wrappers for of_map_id()
of: Respect #{iommu,msi}-cells in maps
drivers/cdx/cdx_msi.c | 8 +-
drivers/iommu/of_iommu.c | 6 +-
drivers/irqchip/irq-gic-its-msi-parent.c | 11 +-
drivers/of/base.c | 213 ++++++++++++++++++++++++-------
drivers/of/irq.c | 11 +-
drivers/pci/controller/dwc/pci-imx6.c | 34 +++--
drivers/pci/controller/pcie-apple.c | 6 +-
drivers/xen/grant-dma-ops.c | 5 +-
include/linux/of.h | 30 ++++-
9 files changed, 240 insertions(+), 84 deletions(-)
---
base-commit: 3fa5e5702a82d259897bd7e209469bc06368bf31
change-id: 20260301-parse_iommu_cells-1c33768aebba
Best regards,
--
Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
^ permalink raw reply
* [PATCH v12 1/3] of: Add convenience wrappers for of_map_id()
From: Vijayanand Jitta @ 2026-03-31 14:04 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, 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,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Vijayanand Jitta
In-Reply-To: <20260331-parse_iommu_cells-v12-0-decfd305eea9@oss.qualcomm.com>
From: Robin Murphy <robin.murphy@arm.com>
Since we now have quite a few users parsing "iommu-map" and "msi-map"
properties, give them some wrappers to conveniently encapsulate the
appropriate sets of property names. This will also make it easier to
then change of_map_id() to correctly account for specifier cells.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
---
drivers/cdx/cdx_msi.c | 3 +--
drivers/iommu/of_iommu.c | 4 +---
drivers/irqchip/irq-gic-its-msi-parent.c | 2 +-
drivers/of/base.c | 38 ++++++++++++++++++++++++++++++++
drivers/of/irq.c | 3 +--
drivers/pci/controller/dwc/pci-imx6.c | 6 ++---
drivers/pci/controller/pcie-apple.c | 3 +--
drivers/xen/grant-dma-ops.c | 3 +--
include/linux/of.h | 18 +++++++++++++++
9 files changed, 64 insertions(+), 16 deletions(-)
diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c
index 91b95422b263..63b3544ec997 100644
--- a/drivers/cdx/cdx_msi.c
+++ b/drivers/cdx/cdx_msi.c
@@ -128,8 +128,7 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain,
int ret;
/* Retrieve device ID from requestor ID using parent device */
- ret = of_map_id(parent->of_node, cdx_dev->msi_dev_id, "msi-map", "msi-map-mask",
- NULL, &dev_id);
+ ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id);
if (ret) {
dev_err(dev, "of_map_id failed for MSI: %d\n", ret);
return ret;
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 6b989a62def2..a511ecf21fcd 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -48,9 +48,7 @@ static int of_iommu_configure_dev_id(struct device_node *master_np,
struct of_phandle_args iommu_spec = { .args_count = 1 };
int err;
- err = of_map_id(master_np, *id, "iommu-map",
- "iommu-map-mask", &iommu_spec.np,
- iommu_spec.args);
+ err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args);
if (err)
return err;
diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c
index d36b278ae66c..b63343a227a9 100644
--- a/drivers/irqchip/irq-gic-its-msi-parent.c
+++ b/drivers/irqchip/irq-gic-its-msi-parent.c
@@ -180,7 +180,7 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u
struct device_node *msi_ctrl __free(device_node) = NULL;
- return of_map_id(dev->of_node, dev->id, "msi-map", "msi-map-mask", &msi_ctrl, dev_id);
+ return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id);
}
static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
diff --git a/drivers/of/base.c b/drivers/of/base.c
index 57420806c1a2..ae04487bd614 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2201,3 +2201,41 @@ int of_map_id(const struct device_node *np, u32 id,
return 0;
}
EXPORT_SYMBOL_GPL(of_map_id);
+
+/**
+ * of_map_iommu_id - Translate an ID using "iommu-map" bindings.
+ * @np: root complex device node.
+ * @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
+ * stream/device ID) used as the lookup key in the iommu-map table.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Convenience wrapper around of_map_id() using "iommu-map" and "iommu-map-mask".
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_iommu_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out)
+{
+ return of_map_id(np, id, "iommu-map", "iommu-map-mask", target, id_out);
+}
+EXPORT_SYMBOL_GPL(of_map_iommu_id);
+
+/**
+ * of_map_msi_id - Translate an ID using "msi-map" bindings.
+ * @np: root complex device node.
+ * @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
+ * stream/device ID) used as the lookup key in the msi-map table.
+ * @target: optional pointer to a target device node.
+ * @id_out: optional pointer to receive the translated ID.
+ *
+ * Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask".
+ *
+ * Return: 0 on success or a standard error code on failure.
+ */
+int of_map_msi_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out)
+{
+ return of_map_id(np, id, "msi-map", "msi-map-mask", target, id_out);
+}
+EXPORT_SYMBOL_GPL(of_map_msi_id);
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index 6367c67732d2..e37c1b3f8736 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -817,8 +817,7 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in)
* "msi-map" or an "msi-parent" property.
*/
for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
- if (!of_map_id(parent_dev->of_node, id_in, "msi-map",
- "msi-map-mask", msi_np, &id_out))
+ if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out))
break;
if (!of_check_msi_parent(parent_dev->of_node, msi_np))
break;
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index a5b8d0b71677..bff8289f804a 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1144,8 +1144,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
u32 sid = 0;
target = NULL;
- err_i = of_map_id(dev->of_node, rid, "iommu-map", "iommu-map-mask",
- &target, &sid_i);
+ err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i);
if (target) {
of_node_put(target);
} else {
@@ -1158,8 +1157,7 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
}
target = NULL;
- err_m = of_map_id(dev->of_node, rid, "msi-map", "msi-map-mask",
- &target, &sid_m);
+ err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m);
/*
* err_m target
diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c
index 2d92fc79f6dd..a0937b7b3c4d 100644
--- a/drivers/pci/controller/pcie-apple.c
+++ b/drivers/pci/controller/pcie-apple.c
@@ -764,8 +764,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
dev_dbg(&pdev->dev, "added to bus %s, index %d\n",
pci_name(pdev->bus->self), port->idx);
- err = of_map_id(port->pcie->dev->of_node, rid, "iommu-map",
- "iommu-map-mask", NULL, &sid);
+ err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid);
if (err)
return err;
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index c2603e700178..1b7696b2d762 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -325,8 +325,7 @@ static int xen_dt_grant_init_backend_domid(struct device *dev,
struct pci_dev *pdev = to_pci_dev(dev);
u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
- if (of_map_id(np, rid, "iommu-map", "iommu-map-mask", &iommu_spec.np,
- iommu_spec.args)) {
+ if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) {
dev_dbg(dev, "Cannot translate ID\n");
return -ESRCH;
}
diff --git a/include/linux/of.h b/include/linux/of.h
index be6ec4916adf..fe841f3cc747 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -465,6 +465,12 @@ int of_map_id(const struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
struct device_node **target, u32 *id_out);
+int of_map_iommu_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out);
+
+int of_map_msi_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out);
+
phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
struct kimage;
@@ -934,6 +940,18 @@ static inline int of_map_id(const struct device_node *np, u32 id,
return -EINVAL;
}
+static inline int of_map_iommu_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out)
+{
+ return -EINVAL;
+}
+
+static inline int of_map_msi_id(const struct device_node *np, u32 id,
+ struct device_node **target, u32 *id_out)
+{
+ return -EINVAL;
+}
+
static inline phys_addr_t of_dma_get_max_cpu_address(struct device_node *np)
{
return PHYS_ADDR_MAX;
--
2.34.1
^ permalink raw reply related
* [PATCH v12 2/3] of: Factor arguments passed to of_map_id() into a struct
From: Vijayanand Jitta @ 2026-03-31 14:04 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, 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,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Vijayanand Jitta, Charan Teja Kalla
In-Reply-To: <20260331-parse_iommu_cells-v12-0-decfd305eea9@oss.qualcomm.com>
From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Change of_map_id() to take a pointer to struct of_phandle_args
instead of passing target device node and translated IDs separately.
Update all callers accordingly.
Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
to separate the filter input from the output. Previously, the target
parameter served dual purpose: as an input filter (if non-NULL, only
match entries targeting that node) and as an output (receiving the
matched node with a reference held). Now filter_np is the explicit
input filter and arg->np is the pure output.
Previously, of_map_id() would call of_node_put() on the matched node
when a filter was provided, making reference ownership inconsistent.
Remove this internal of_node_put() call so that of_map_id() now always
transfers ownership of the matched node reference to the caller via
arg->np. Callers are now consistently responsible for releasing this
reference with of_node_put(arg->np) when done.
Suggested-by: Rob Herring (Arm) <robh@kernel.org>
Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
---
drivers/cdx/cdx_msi.c | 7 ++--
drivers/iommu/of_iommu.c | 4 +-
drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++--
drivers/of/base.c | 68 +++++++++++++++++---------------
drivers/of/irq.c | 10 ++++-
drivers/pci/controller/dwc/pci-imx6.c | 32 +++++++--------
drivers/pci/controller/pcie-apple.c | 5 ++-
drivers/xen/grant-dma-ops.c | 4 +-
include/linux/of.h | 14 ++++---
9 files changed, 89 insertions(+), 66 deletions(-)
diff --git a/drivers/cdx/cdx_msi.c b/drivers/cdx/cdx_msi.c
index 63b3544ec997..6924e07c7528 100644
--- a/drivers/cdx/cdx_msi.c
+++ b/drivers/cdx/cdx_msi.c
@@ -121,22 +121,23 @@ static int cdx_msi_prepare(struct irq_domain *msi_domain,
struct device *dev,
int nvec, msi_alloc_info_t *info)
{
+ struct of_phandle_args msi_spec = {};
struct cdx_device *cdx_dev = to_cdx_device(dev);
struct device *parent = cdx_dev->cdx->dev;
struct msi_domain_info *msi_info;
- u32 dev_id;
int ret;
/* Retrieve device ID from requestor ID using parent device */
- ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &dev_id);
+ ret = of_map_msi_id(parent->of_node, cdx_dev->msi_dev_id, NULL, &msi_spec);
if (ret) {
dev_err(dev, "of_map_id failed for MSI: %d\n", ret);
return ret;
}
+ of_node_put(msi_spec.np);
#ifdef GENERIC_MSI_DOMAIN_OPS
/* Set the device Id to be passed to the GIC-ITS */
- info->scratchpad[0].ul = dev_id;
+ info->scratchpad[0].ul = msi_spec.args[0];
#endif
msi_info = msi_get_domain_info(msi_domain->parent);
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index a511ecf21fcd..a18bb60f6f3d 100644
--- a/drivers/iommu/of_iommu.c
+++ b/drivers/iommu/of_iommu.c
@@ -45,10 +45,10 @@ static int of_iommu_configure_dev_id(struct device_node *master_np,
struct device *dev,
const u32 *id)
{
- struct of_phandle_args iommu_spec = { .args_count = 1 };
+ struct of_phandle_args iommu_spec = {};
int err;
- err = of_map_iommu_id(master_np, *id, &iommu_spec.np, iommu_spec.args);
+ err = of_map_iommu_id(master_np, *id, &iommu_spec);
if (err)
return err;
diff --git a/drivers/irqchip/irq-gic-its-msi-parent.c b/drivers/irqchip/irq-gic-its-msi-parent.c
index b63343a227a9..dd5f84b6470a 100644
--- a/drivers/irqchip/irq-gic-its-msi-parent.c
+++ b/drivers/irqchip/irq-gic-its-msi-parent.c
@@ -152,6 +152,8 @@ static int its_v5_pci_msi_prepare(struct irq_domain *domain, struct device *dev,
static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u32 *dev_id,
phys_addr_t *pa)
{
+ struct device_node *msi_ctrl __free(device_node) = NULL;
+ struct of_phandle_args msi_spec = {};
struct of_phandle_iterator it;
int ret;
@@ -178,9 +180,12 @@ static int of_pmsi_get_msi_info(struct irq_domain *domain, struct device *dev, u
}
}
- struct device_node *msi_ctrl __free(device_node) = NULL;
-
- return of_map_msi_id(dev->of_node, dev->id, &msi_ctrl, dev_id);
+ ret = of_map_msi_id(dev->of_node, dev->id, NULL, &msi_spec);
+ if (!ret) {
+ msi_ctrl = msi_spec.np;
+ *dev_id = msi_spec.args[0];
+ }
+ return ret;
}
static int its_pmsi_prepare(struct irq_domain *domain, struct device *dev,
diff --git a/drivers/of/base.c b/drivers/of/base.c
index ae04487bd614..b3d002015192 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2102,36 +2102,37 @@ int of_find_last_cache_level(unsigned int cpu)
* @id: device ID to map.
* @map_name: property name of the map to use.
* @map_mask_name: optional property name of the mask to use.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
+ * @filter_np: optional device node to filter matches by, or NULL to match any.
+ * If non-NULL, only map entries targeting this node will be matched.
+ * @arg: pointer to a &struct of_phandle_args for the result. On success,
+ * @arg->args[0] will contain the translated ID. If a map entry was
+ * matched, @arg->np will be set to the target node with a reference
+ * held that the caller must release with of_node_put().
*
* Given a device ID, look up the appropriate implementation-defined
* platform ID and/or the target device which receives transactions on that
- * ID, as per the "iommu-map" and "msi-map" bindings. Either of @target or
- * @id_out may be NULL if only the other is required. If @target points to
- * a non-NULL device node pointer, only entries targeting that node will be
- * matched; if it points to a NULL value, it will receive the device node of
- * the first matching target phandle, with a reference held.
+ * ID, as per the "iommu-map" and "msi-map" bindings.
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_id(const struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
- struct device_node **target, u32 *id_out)
+ const struct device_node *filter_np, struct of_phandle_args *arg)
{
u32 map_mask, masked_id;
int map_len;
const __be32 *map = NULL;
- if (!np || !map_name || (!target && !id_out))
+ if (!np || !map_name || !arg)
return -EINVAL;
map = of_get_property(np, map_name, &map_len);
if (!map) {
- if (target)
+ if (filter_np)
return -ENODEV;
/* Otherwise, no map implies no translation */
- *id_out = id;
+ arg->args[0] = id;
+ arg->args_count = 1;
return 0;
}
@@ -2173,18 +2174,14 @@ int of_map_id(const struct device_node *np, u32 id,
if (!phandle_node)
return -ENODEV;
- if (target) {
- if (*target)
- of_node_put(phandle_node);
- else
- *target = phandle_node;
-
- if (*target != phandle_node)
- continue;
+ if (filter_np && filter_np != phandle_node) {
+ of_node_put(phandle_node);
+ continue;
}
- if (id_out)
- *id_out = masked_id - id_base + out_base;
+ arg->np = phandle_node;
+ arg->args[0] = masked_id - id_base + out_base;
+ arg->args_count = 1;
pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
np, map_name, map_mask, id_base, out_base,
@@ -2193,11 +2190,11 @@ int of_map_id(const struct device_node *np, u32 id,
}
pr_info("%pOF: no %s translation for id 0x%x on %pOF\n", np, map_name,
- id, target && *target ? *target : NULL);
+ id, filter_np);
/* Bypasses translation */
- if (id_out)
- *id_out = id;
+ arg->args[0] = id;
+ arg->args_count = 1;
return 0;
}
EXPORT_SYMBOL_GPL(of_map_id);
@@ -2207,17 +2204,19 @@ EXPORT_SYMBOL_GPL(of_map_id);
* @np: root complex device node.
* @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
* stream/device ID) used as the lookup key in the iommu-map table.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
+ * @arg: pointer to a &struct of_phandle_args for the result. On success,
+ * @arg->args[0] contains the translated ID. If a map entry was matched,
+ * @arg->np holds a reference to the target node that the caller must
+ * release with of_node_put().
*
* Convenience wrapper around of_map_id() using "iommu-map" and "iommu-map-mask".
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_iommu_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out)
+ struct of_phandle_args *arg)
{
- return of_map_id(np, id, "iommu-map", "iommu-map-mask", target, id_out);
+ return of_map_id(np, id, "iommu-map", "iommu-map-mask", NULL, arg);
}
EXPORT_SYMBOL_GPL(of_map_iommu_id);
@@ -2226,16 +2225,21 @@ EXPORT_SYMBOL_GPL(of_map_iommu_id);
* @np: root complex device node.
* @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
* stream/device ID) used as the lookup key in the msi-map table.
- * @target: optional pointer to a target device node.
- * @id_out: optional pointer to receive the translated ID.
+ * @filter_np: optional MSI controller node to filter matches by, or NULL
+ * to match any. If non-NULL, only map entries targeting this node will
+ * be matched.
+ * @arg: pointer to a &struct of_phandle_args for the result. On success,
+ * @arg->args[0] contains the translated ID. If a map entry was matched,
+ * @arg->np holds a reference to the target node that the caller must
+ * release with of_node_put().
*
* Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask".
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_msi_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out)
+ const struct device_node *filter_np, struct of_phandle_args *arg)
{
- return of_map_id(np, id, "msi-map", "msi-map-mask", target, id_out);
+ return of_map_id(np, id, "msi-map", "msi-map-mask", filter_np, arg);
}
EXPORT_SYMBOL_GPL(of_map_msi_id);
diff --git a/drivers/of/irq.c b/drivers/of/irq.c
index e37c1b3f8736..f86a56bd81fc 100644
--- a/drivers/of/irq.c
+++ b/drivers/of/irq.c
@@ -817,8 +817,16 @@ u32 of_msi_xlate(struct device *dev, struct device_node **msi_np, u32 id_in)
* "msi-map" or an "msi-parent" property.
*/
for (parent_dev = dev; parent_dev; parent_dev = parent_dev->parent) {
- if (!of_map_msi_id(parent_dev->of_node, id_in, msi_np, &id_out))
+ struct of_phandle_args msi_spec = {};
+
+ if (!of_map_msi_id(parent_dev->of_node, id_in, *msi_np, &msi_spec)) {
+ id_out = msi_spec.args[0];
+ if (!*msi_np)
+ *msi_np = msi_spec.np;
+ else
+ of_node_put(msi_spec.np);
break;
+ }
if (!of_check_msi_parent(parent_dev->of_node, msi_np))
break;
}
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index bff8289f804a..c0544d9c0921 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1137,30 +1137,32 @@ static void imx_pcie_remove_lut(struct imx_pcie *imx_pcie, u16 rid)
static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
{
+ struct of_phandle_args iommu_spec = {};
+ struct of_phandle_args msi_spec = {};
struct device *dev = imx_pcie->pci->dev;
- struct device_node *target;
u32 sid_i, sid_m;
int err_i, err_m;
u32 sid = 0;
- target = NULL;
- err_i = of_map_iommu_id(dev->of_node, rid, &target, &sid_i);
- if (target) {
- of_node_put(target);
- } else {
+ err_i = of_map_iommu_id(dev->of_node, rid, &iommu_spec);
+ if (!err_i)
+ sid_i = iommu_spec.args[0];
+ of_node_put(iommu_spec.np);
+ if (!err_i && !iommu_spec.np) {
/*
- * "target == NULL && err_i == 0" means RID out of map range.
- * Use 1:1 map RID to streamID. Hardware can't support this
- * because the streamID is only 6 bits
+ * "iommu_spec.np == NULL && err_i == 0" means RID out of map
+ * range. Use 1:1 map RID to streamID. Hardware can't support
+ * this because the streamID is only 6 bits.
*/
err_i = -EINVAL;
}
- target = NULL;
- err_m = of_map_msi_id(dev->of_node, rid, &target, &sid_m);
-
+ err_m = of_map_msi_id(dev->of_node, rid, NULL, &msi_spec);
+ if (!err_m)
+ sid_m = msi_spec.args[0];
+ of_node_put(msi_spec.np);
/*
- * err_m target
+ * err_m msi_spec.np
* 0 NULL RID out of range. Use 1:1 map RID to
* streamID, Current hardware can't
* support it, so return -EINVAL.
@@ -1168,10 +1170,8 @@ static int imx_pcie_add_lut_by_rid(struct imx_pcie *imx_pcie, u32 rid)
* 0 != NULL Get correct streamID from RID
* != 0 != NULL Invalid combination
*/
- if (!err_m && !target)
+ if (!err_m && !msi_spec.np)
return -EINVAL;
- else if (target)
- of_node_put(target); /* Find streamID map entry for RID in msi-map */
/*
* msi-map iommu-map
diff --git a/drivers/pci/controller/pcie-apple.c b/drivers/pci/controller/pcie-apple.c
index a0937b7b3c4d..c2cffc0659f4 100644
--- a/drivers/pci/controller/pcie-apple.c
+++ b/drivers/pci/controller/pcie-apple.c
@@ -755,6 +755,7 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
{
u32 sid, rid = pci_dev_id(pdev);
struct apple_pcie_port *port;
+ struct of_phandle_args iommu_spec = {};
int idx, err;
port = apple_pcie_get_port(pdev);
@@ -764,10 +765,12 @@ static int apple_pcie_enable_device(struct pci_host_bridge *bridge, struct pci_d
dev_dbg(&pdev->dev, "added to bus %s, index %d\n",
pci_name(pdev->bus->self), port->idx);
- err = of_map_iommu_id(port->pcie->dev->of_node, rid, NULL, &sid);
+ err = of_map_iommu_id(port->pcie->dev->of_node, rid, &iommu_spec);
if (err)
return err;
+ of_node_put(iommu_spec.np);
+ sid = iommu_spec.args[0];
mutex_lock(&port->pcie->lock);
idx = bitmap_find_free_region(port->sid_map, port->sid_map_sz, 0);
diff --git a/drivers/xen/grant-dma-ops.c b/drivers/xen/grant-dma-ops.c
index 1b7696b2d762..2aa1a772a0ff 100644
--- a/drivers/xen/grant-dma-ops.c
+++ b/drivers/xen/grant-dma-ops.c
@@ -319,13 +319,13 @@ static int xen_dt_grant_init_backend_domid(struct device *dev,
struct device_node *np,
domid_t *backend_domid)
{
- struct of_phandle_args iommu_spec = { .args_count = 1 };
+ struct of_phandle_args iommu_spec = {};
if (dev_is_pci(dev)) {
struct pci_dev *pdev = to_pci_dev(dev);
u32 rid = PCI_DEVID(pdev->bus->number, pdev->devfn);
- if (of_map_iommu_id(np, rid, &iommu_spec.np, iommu_spec.args)) {
+ if (of_map_iommu_id(np, rid, &iommu_spec)) {
dev_dbg(dev, "Cannot translate ID\n");
return -ESRCH;
}
diff --git a/include/linux/of.h b/include/linux/of.h
index fe841f3cc747..8548cd9eb4f1 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -463,13 +463,13 @@ bool of_console_check(const struct device_node *dn, char *name, int index);
int of_map_id(const struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
- struct device_node **target, u32 *id_out);
+ const struct device_node *filter_np, struct of_phandle_args *arg);
int of_map_iommu_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out);
+ struct of_phandle_args *arg);
int of_map_msi_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out);
+ const struct device_node *filter_np, struct of_phandle_args *arg);
phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
@@ -935,19 +935,21 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag
static inline int of_map_id(const struct device_node *np, u32 id,
const char *map_name, const char *map_mask_name,
- struct device_node **target, u32 *id_out)
+ const struct device_node *filter_np,
+ struct of_phandle_args *arg)
{
return -EINVAL;
}
static inline int of_map_iommu_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out)
+ struct of_phandle_args *arg)
{
return -EINVAL;
}
static inline int of_map_msi_id(const struct device_node *np, u32 id,
- struct device_node **target, u32 *id_out)
+ const struct device_node *filter_np,
+ struct of_phandle_args *arg)
{
return -EINVAL;
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCHv2] clk: kirkwood: use kzalloc_flex
From: Brian Masney @ 2026-03-31 14:05 UTC (permalink / raw)
To: Rosen Penev
Cc: linux-clk, Andrew Lunn, Gregory Clement, Sebastian Hesselbarth,
Michael Turquette, Stephen Boyd, Kees Cook, Gustavo A. R. Silva,
moderated list:ARM/Marvell Kirkwood and Armada 370, 375, 38x,...,
open list,
open list:KERNEL HARDENING (not covered by other areas):Keyword:b__counted_by(_le|_be)?b
In-Reply-To: <20260330205504.10143-1-rosenp@gmail.com>
On Mon, Mar 30, 2026 at 01:55:04PM -0700, Rosen Penev wrote:
> Simplify allocation by using a flexible array member and kzalloc_flex to
> combine allocations.
>
> Add __counted_by for extra runtime analysis. Move counting variable
> assignment to right after allocation as required by __counted_by.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> v2: remove unused goto.
Reviewed-by: Brian Masney <bmasney@redhat.com>
For the future, if someone asks for changes in a previous version, then
be sure to CC them on the next revision.
^ permalink raw reply
* [PATCH v12 3/3] of: Respect #{iommu,msi}-cells in maps
From: Vijayanand Jitta @ 2026-03-31 14:04 UTC (permalink / raw)
To: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, 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,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia
Cc: linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Vijayanand Jitta, Charan Teja Kalla
In-Reply-To: <20260331-parse_iommu_cells-v12-0-decfd305eea9@oss.qualcomm.com>
From: Robin Murphy <robin.murphy@arm.com>
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 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.
Since there are multi-cell output specifiers, the callers of of_map_id()
may need to get the exact cell output value for further processing.
Update of_map_id() to set args_count in the output to reflect the actual
number of output specifier cells.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
---
drivers/of/base.c | 155 ++++++++++++++++++++++++++++++++++++++++-------------
include/linux/of.h | 6 ++-
2 files changed, 123 insertions(+), 38 deletions(-)
diff --git a/drivers/of/base.c b/drivers/of/base.c
index b3d002015192..7b22e2484e1c 100644
--- a/drivers/of/base.c
+++ b/drivers/of/base.c
@@ -2096,18 +2096,48 @@ int of_find_last_cache_level(unsigned int cpu)
return cache_level;
}
+/*
+ * Some DTs have an iommu-map targeting a 2-cell IOMMU node while
+ * specifying only 1 cell. Fortunately they all consist of value '1'
+ * as the 2nd cell entry with the same target, so check for that pattern.
+ *
+ * Example:
+ * IOMMU node:
+ * #iommu-cells = <2>;
+ *
+ * Device node:
+ * iommu-map = <0x0000 &smmu 0x0000 0x1>,
+ * <0x0100 &smmu 0x0100 0x1>;
+ */
+static bool of_check_bad_map(const __be32 *map, int len)
+{
+ __be32 phandle = map[1];
+
+ if (len % 4)
+ return false;
+ for (int i = 0; i < len; i += 4) {
+ if (map[i + 1] != phandle || map[i + 3] != cpu_to_be32(1))
+ return false;
+ }
+ return true;
+}
+
/**
* of_map_id - Translate an ID through a downstream mapping.
* @np: root complex device node.
* @id: device ID to map.
* @map_name: property name of the map to use.
+ * @cells_name: property name of target specifier cells.
* @map_mask_name: optional property name of the mask to use.
* @filter_np: optional device node to filter matches by, or NULL to match any.
* If non-NULL, only map entries targeting this node will be matched.
* @arg: pointer to a &struct of_phandle_args for the result. On success,
- * @arg->args[0] will contain the translated ID. If a map entry was
- * matched, @arg->np will be set to the target node with a reference
- * held that the caller must release with of_node_put().
+ * @arg->args_count will be set to the number of output specifier cells
+ * as defined by @cells_name in the target node, and
+ * @arg->args[0..args_count-1] will contain the translated output
+ * specifier values. If a map entry was matched, @arg->np will be set
+ * to the target node with a reference held that the caller must release
+ * with of_node_put().
*
* Given a device ID, look up the appropriate implementation-defined
* platform ID and/or the target device which receives transactions on that
@@ -2116,17 +2146,19 @@ int of_find_last_cache_level(unsigned int cpu)
* Return: 0 on success or a standard error code on failure.
*/
int of_map_id(const struct device_node *np, u32 id,
- const char *map_name, const char *map_mask_name,
+ const char *map_name, const char *cells_name,
+ const char *map_mask_name,
const struct device_node *filter_np, struct of_phandle_args *arg)
{
u32 map_mask, masked_id;
- int map_len;
+ int map_bytes, map_len, offset = 0;
+ bool bad_map = false;
const __be32 *map = NULL;
if (!np || !map_name || !arg)
return -EINVAL;
- map = of_get_property(np, map_name, &map_len);
+ map = of_get_property(np, map_name, &map_bytes);
if (!map) {
if (filter_np)
return -ENODEV;
@@ -2136,11 +2168,9 @@ int of_map_id(const struct device_node *np, u32 id,
return 0;
}
- if (!map_len || map_len % (4 * sizeof(*map))) {
- pr_err("%pOF: Error: Bad %s length: %d\n", np,
- map_name, map_len);
- return -EINVAL;
- }
+ if (map_bytes % sizeof(*map))
+ goto err_map_len;
+ map_len = map_bytes / sizeof(*map);
/* The default is to select all bits. */
map_mask = 0xffffffff;
@@ -2153,39 +2183,82 @@ int of_map_id(const struct device_node *np, u32 id,
of_property_read_u32(np, map_mask_name, &map_mask);
masked_id = map_mask & id;
- for ( ; map_len > 0; map_len -= 4 * sizeof(*map), map += 4) {
+
+ while (offset < map_len) {
struct device_node *phandle_node;
- u32 id_base = be32_to_cpup(map + 0);
- u32 phandle = be32_to_cpup(map + 1);
- u32 out_base = be32_to_cpup(map + 2);
- u32 id_len = be32_to_cpup(map + 3);
+ u32 id_base, phandle, id_len, id_off, cells = 0;
+ const __be32 *out_base;
+
+ if (map_len - offset < 2)
+ goto err_map_len;
+
+ id_base = be32_to_cpup(map + offset);
if (id_base & ~map_mask) {
- pr_err("%pOF: Invalid %s translation - %s-mask (0x%x) ignores id-base (0x%x)\n",
- np, map_name, map_name,
- map_mask, id_base);
+ pr_err("%pOF: Invalid %s translation - %s (0x%x) ignores id-base (0x%x)\n",
+ np, map_name, map_mask_name, map_mask, id_base);
return -EFAULT;
}
- if (masked_id < id_base || masked_id >= id_base + id_len)
- continue;
-
+ phandle = be32_to_cpup(map + offset + 1);
phandle_node = of_find_node_by_phandle(phandle);
if (!phandle_node)
return -ENODEV;
+ if (!bad_map && of_property_read_u32(phandle_node, cells_name, &cells)) {
+ pr_err("%pOF: missing %s property\n", phandle_node, cells_name);
+ of_node_put(phandle_node);
+ return -EINVAL;
+ }
+
+ if (map_len - offset < 3 + cells) {
+ of_node_put(phandle_node);
+ goto err_map_len;
+ }
+
+ if (offset == 0 && cells == 2) {
+ bad_map = of_check_bad_map(map, map_len);
+ if (bad_map) {
+ pr_warn_once("%pOF: %s mismatches target %s, assuming extra cell of 0\n",
+ np, map_name, cells_name);
+ cells = 1;
+ }
+ }
+
+ out_base = map + offset + 2;
+ offset += 3 + cells;
+
+ id_len = be32_to_cpup(map + offset - 1);
+ if (id_len > 1 && cells > 1) {
+ /*
+ * With 1 output cell we reasonably assume its value
+ * has a linear relationship to the input; with more,
+ * we'd need help from the provider to know what to do.
+ */
+ pr_err("%pOF: Unsupported %s - cannot handle %d-ID range with %d-cell output specifier\n",
+ np, map_name, id_len, cells);
+ of_node_put(phandle_node);
+ return -EINVAL;
+ }
+ id_off = masked_id - id_base;
+ if (masked_id < id_base || id_off >= id_len) {
+ of_node_put(phandle_node);
+ continue;
+ }
+
if (filter_np && filter_np != phandle_node) {
of_node_put(phandle_node);
continue;
}
arg->np = phandle_node;
- arg->args[0] = masked_id - id_base + out_base;
- arg->args_count = 1;
+ for (int i = 0; i < cells; i++)
+ arg->args[i] = id_off + be32_to_cpu(out_base[i]);
+ arg->args_count = cells;
pr_debug("%pOF: %s, using mask %08x, id-base: %08x, out-base: %08x, length: %08x, id: %08x -> %08x\n",
- np, map_name, map_mask, id_base, out_base,
- id_len, id, masked_id - id_base + out_base);
+ np, map_name, map_mask, id_base, be32_to_cpup(out_base),
+ id_len, id, id_off + be32_to_cpup(out_base));
return 0;
}
@@ -2196,6 +2269,10 @@ int of_map_id(const struct device_node *np, u32 id,
arg->args[0] = id;
arg->args_count = 1;
return 0;
+
+err_map_len:
+ pr_err("%pOF: Error: Bad %s length: %d\n", np, map_name, map_bytes);
+ return -EINVAL;
}
EXPORT_SYMBOL_GPL(of_map_id);
@@ -2205,18 +2282,21 @@ EXPORT_SYMBOL_GPL(of_map_id);
* @id: Requester ID of the device (e.g. PCI RID/BDF or a platform
* stream/device ID) used as the lookup key in the iommu-map table.
* @arg: pointer to a &struct of_phandle_args for the result. On success,
- * @arg->args[0] contains the translated ID. If a map entry was matched,
- * @arg->np holds a reference to the target node that the caller must
- * release with of_node_put().
+ * @arg->args_count will be set to the number of output specifier cells
+ * and @arg->args[0..args_count-1] will contain the translated output
+ * specifier values. If a map entry was matched, @arg->np holds a
+ * reference to the target node that the caller must release with
+ * of_node_put().
*
- * Convenience wrapper around of_map_id() using "iommu-map" and "iommu-map-mask".
+ * Convenience wrapper around of_map_id() using "iommu-map", "#iommu-cells",
+ * and "iommu-map-mask".
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_iommu_id(const struct device_node *np, u32 id,
struct of_phandle_args *arg)
{
- return of_map_id(np, id, "iommu-map", "iommu-map-mask", NULL, arg);
+ return of_map_id(np, id, "iommu-map", "#iommu-cells", "iommu-map-mask", NULL, arg);
}
EXPORT_SYMBOL_GPL(of_map_iommu_id);
@@ -2229,17 +2309,20 @@ EXPORT_SYMBOL_GPL(of_map_iommu_id);
* to match any. If non-NULL, only map entries targeting this node will
* be matched.
* @arg: pointer to a &struct of_phandle_args for the result. On success,
- * @arg->args[0] contains the translated ID. If a map entry was matched,
- * @arg->np holds a reference to the target node that the caller must
- * release with of_node_put().
+ * @arg->args_count will be set to the number of output specifier cells
+ * and @arg->args[0..args_count-1] will contain the translated output
+ * specifier values. If a map entry was matched, @arg->np holds a
+ * reference to the target node that the caller must release with
+ * of_node_put().
*
- * Convenience wrapper around of_map_id() using "msi-map" and "msi-map-mask".
+ * Convenience wrapper around of_map_id() using "msi-map", "#msi-cells",
+ * and "msi-map-mask".
*
* Return: 0 on success or a standard error code on failure.
*/
int of_map_msi_id(const struct device_node *np, u32 id,
const struct device_node *filter_np, struct of_phandle_args *arg)
{
- return of_map_id(np, id, "msi-map", "msi-map-mask", filter_np, arg);
+ return of_map_id(np, id, "msi-map", "#msi-cells", "msi-map-mask", filter_np, arg);
}
EXPORT_SYMBOL_GPL(of_map_msi_id);
diff --git a/include/linux/of.h b/include/linux/of.h
index 8548cd9eb4f1..51ac8539f2c3 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -462,7 +462,8 @@ const char *of_prop_next_string(const struct property *prop, const char *cur);
bool of_console_check(const struct device_node *dn, char *name, int index);
int of_map_id(const struct device_node *np, u32 id,
- const char *map_name, const char *map_mask_name,
+ const char *map_name, const char *cells_name,
+ const char *map_mask_name,
const struct device_node *filter_np, struct of_phandle_args *arg);
int of_map_iommu_id(const struct device_node *np, u32 id,
@@ -934,7 +935,8 @@ static inline void of_property_clear_flag(struct property *p, unsigned long flag
}
static inline int of_map_id(const struct device_node *np, u32 id,
- const char *map_name, const char *map_mask_name,
+ const char *map_name, const char *cells_name,
+ const char *map_mask_name,
const struct device_node *filter_np,
struct of_phandle_args *arg)
{
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Arnd Bergmann @ 2026-03-31 14:08 UTC (permalink / raw)
To: Khristine Andreea Barbulescu, Krzysztof Kozlowski,
Ghennadi Procopciuc
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
Aisheng Dong, Jacky Bai, Greg Kroah-Hartman, Rafael J . Wysocki,
Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, open list:GPIO SUBSYSTEM,
linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
Vincent Guittot, Rob Herring
In-Reply-To: <fd8c90ec-927e-4395-85ba-9e45c23fd799@oss.nxp.com>
On Tue, Mar 31, 2026, at 15:43, Khristine Andreea Barbulescu wrote:
> On 3/31/2026 1:11 PM, Arnd Bergmann wrote:
>
> Our initial intention had been to expose that SoC-information as
> discussed in the earlier revisions of this series. However,
> taking the review feedback into account, the current direction is
> to stop handling those SoC information registers in the Linux driver
> altogether and instead rely on a boot firmware to pass that
> information forward, as you suggested.
>
> With this approach, the SIUL2 driver would no longer be responsible
> for any separate SoC-information functionality. In that case,
> I understand your point that a monolithic pinctrl/GPIO/irqchip
> driver is a better fit than keeping the MFD structure.
Ok
> However, as you mentioned, this is still weird because it means
> listing individual register areas of the larger device inside.
>
> For this reason, I was wondering whether it would still be
> acceptable to move forward with the new binding introduced
> in this series, but simplify it so that it describes a single
> monolithic SIUL2 pinctrl/GPIO device instead of an MFD,
> following the example node I included in my previous reply [1].
>
> [1]
> https://lore.kernel.org/linux-gpio/20260120115923.3463866-4-khristineandreea.barbulescu@oss.nxp.com/T/#m778088251774a15bde7463350d6e75d5e9b9b57d
I can't think of a justification for making this an incompatible
binding change, if the new "nxp,s32g-siul2-pinctrl" binding is almost
the same as the old "nxp,s32g2-siul2-pinctrl" one, and you still
plan to support both versions in the same driver indefinitely.
It would seem much easier to me to make sure that nxp,s32g-siul2-pinctrl
remains backwards compatible with the existing driver and only
adds the properties for gpio support on top, so a single
driver can handle both old and new dts files.
Arnd
^ permalink raw reply
* Re: [PATCH v3 0/5] Support the FEAT_HDBSS introduced in Armv9.5
From: Leonardo Bras @ 2026-03-31 14:13 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <20260225040421.2683931-1-zhengtian10@huawei.com>
On Wed, Feb 25, 2026 at 12:04:16PM +0800, Tian Zheng wrote:
> This series of patches add support to the Hardware Dirty state tracking
> Structure(HDBSS) feature, which is introduced by the ARM architecture
> in the DDI0601(ID121123) version.
>
> The HDBSS feature is an extension to the architecture that enhances
> tracking translation table descriptors' dirty state, identified as
> FEAT_HDBSS. This feature utilizes hardware assistance to achieve dirty
> page tracking, aiming to significantly reduce the overhead of scanning
> for dirty pages.
>
> The purpose of this feature is to make the execution overhead of live
> migration lower to both the guest and the host, compared to existing
> approaches (write-protect or search stage 2 tables).
>
> After these patches, users(such as qemu) can use the
> KVM_CAP_ARM_HW_DIRTY_STATE_TRACK ioctl to enable or disable the HDBSS
> feature before and after the live migration.
>
> v2:
> https://lore.kernel.org/linux-arm-kernel/20251121092342.3393318-1-zhengtian10@huawei.com/
>
> v2->v3 changes:
> - Remove the ARM64_HDBSS configuration option and ensure this feature
> is only enabled in VHE mode.
> - Move HDBSS-related variables to the arch-independent portion of the
> kvm structure.
> - Remove error messages during HDBSS enable/disable operations
> - Change HDBSS buffer flushing from handle_exit to vcpu_put,
> check_vcpu_requests, and kvm_handle_guest_abort.
> - Add fault handling for HDBSS including buffer full, external abort,
> and general protection fault (GPF).
> - Add support for a 4KB HDBSS buffer size, mapped to the value 0b0000.
> - Add a second argument to the ioctl to turn HDBSS on or off.
>
> Tian Zheng (1):
> KVM: arm64: Document HDBSS ioctl
>
> eillon (4):
> arm64/sysreg: Add HDBSS related register information
> KVM: arm64: Add support to set the DBM attr during memory abort
> KVM: arm64: Add support for FEAT_HDBSS
> KVM: arm64: Enable HDBSS support and handle HDBSSF events
>
> Documentation/virt/kvm/api.rst | 16 +++++
> arch/arm64/include/asm/cpufeature.h | 5 ++
> arch/arm64/include/asm/esr.h | 7 ++
> arch/arm64/include/asm/kvm_host.h | 17 +++++
> arch/arm64/include/asm/kvm_mmu.h | 1 +
> arch/arm64/include/asm/kvm_pgtable.h | 4 ++
> arch/arm64/include/asm/sysreg.h | 11 +++
> arch/arm64/kernel/cpufeature.c | 12 ++++
> arch/arm64/kvm/arm.c | 102 +++++++++++++++++++++++++++
> arch/arm64/kvm/hyp/pgtable.c | 6 ++
> arch/arm64/kvm/hyp/vhe/switch.c | 19 +++++
> arch/arm64/kvm/mmu.c | 70 ++++++++++++++++++
> arch/arm64/kvm/reset.c | 3 +
> arch/arm64/tools/cpucaps | 1 +
> arch/arm64/tools/sysreg | 29 ++++++++
> include/uapi/linux/kvm.h | 1 +
> tools/include/uapi/linux/kvm.h | 1 +
> 17 files changed, 305 insertions(+)
>
> --
> 2.33.0
>
Hi Tian,
I was thinking: maybe instead of putting the HDBSS (and HACDBS) stuff
across a bunch of KVM files, we should try to focus them all on a single
arch/arm64/kvm/dirty_bit.c file (plus a header such as
arch/arm64/include/asm/kvm_dirty_bit.h).
What is your opinion on that?
Thanks!
Leo
^ permalink raw reply
* [PATCH v2] ARM: dts: aspeed: Enable networking for Asus Kommando IPMI Card
From: Anirudh Srinivasan @ 2026-03-31 14:18 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: Andrew Lunn, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Anirudh Srinivasan
Adds the DT nodes needed for ethernet support for Asus Kommando, with
phy mode set to rgmii-id.
When this DT was originally added, the phy mode was set to rgmii (which
was incorrect). It was suggested to remove networking support from the
DT till the Aspeed networking driver was patched so that the correct phy
mode could be used.
The discussion in [1] mentions that u-boot was inserting clk delays that
weren't needed, which resulted in needing to set the phy mode in linux
to rgmii incorrectly. The solution suggested there was to patch u-boot to
no longer insert these clk delays and use rgmii-id as the phy mode for
any future DTs added to linux.
This DT was tested (on the OpenBMC u-boot fork [2]) with a u-boot DT
modified to insert clk delays of 0 (instead of patching u-boot itself).
[3] adds a u-boot DT for this device (without networking) and describes
how to patch it to add networking support. If this patched DT is used,
then networking works with rgmii-id phy mode in both u-boot and linux.
[1] https://lore.kernel.org/linux-aspeed/ef88bb50-9f2c-458d-a7e5-dc5ecb9c777a@lunn.ch/
[2] https://github.com/openbmc/u-boot/tree/v2019.04-aspeed-openbmc
[3] https://lore.kernel.org/openbmc/20260328-asus-kommando-v2-1-2a656f8cd314@gmail.com/
Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com>
---
This patch is based off aspeed/arm/dt from bmc tree
---
Changes in v2:
- Commit message now mentions that the u-boot tested against is the
openbmc u-boot fork
- Link to v1: https://lore.kernel.org/r/20260328-asus-kommando-networking-v1-1-66d308b88536@gmail.com
---
.../dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
index ab7ad320067c1ddc0fea9ac386fd488c8ef28184..e0f7d92efa18ccbad2c336236c3b9d01b7de1bba 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
@@ -107,6 +107,24 @@ &gpio1 {
/*18E0 32*/ "","","","","","","","";
};
+&mac2 {
+ status = "okay";
+
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii3_default>;
+};
+
+&mdio2 {
+ status = "okay";
+
+ ethphy2: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
&vhub {
status = "okay";
};
---
base-commit: 76b4ec8efdc3887cdbf730da2e55881fc1a18770
change-id: 20260328-asus-kommando-networking-5c0612aa6b8c
Best regards,
--
Anirudh Srinivasan <anirudhsriniv@gmail.com>
^ permalink raw reply related
* [PATCH 1/7] arm64: dts: fsl-lx2160a-tqmlx2160a: fix LED polarity
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Both LEDs are active-high.
Fixes: 04b77e0124ef ("arm64: dts: freescale: add fsl-lx2160a-mblx2160a board")
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
index f6a4f8d543015..a79290401551e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
@@ -51,7 +51,7 @@ leds {
compatible = "gpio-leds";
led-user1 {
- gpios = <&gpioex1 15 GPIO_ACTIVE_LOW>;
+ gpios = <&gpioex1 15 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_BLUE>;
function = LED_FUNCTION_HEARTBEAT;
function-enumerator = <0>;
@@ -59,7 +59,7 @@ led-user1 {
};
led-user2 {
- gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
+ gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_BLUE>;
function = LED_FUNCTION_HEARTBEAT;
function-enumerator = <1>;
--
2.43.0
^ permalink raw reply related
* [PATCH 0/7] TQMLX2160A-MBLS2160A DT fixes/updates
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: linux-arm-kernel, linux, devicetree, linux-kernel, Nora Schiffer
Hi,
this series adds small fixes and improvements for TQMLX2160A DTs.
The DT overlays address specific hardware behaviour when serdes is configured
differently.
Best regards,
Alexander
Alexander Stein (1):
arm64: dts: fsl-lx2160a-tqmlx2160a: Remove deprecated properties
Nora Schiffer (6):
arm64: dts: fsl-lx2160a-tqmlx2160a: fix LED polarity
arm64: dts: fsl-lx2160a-tqmlx2160a-mblx2160a: use DPMAC 17 and 18 for
SGMII in SERDES2 configs 7 and 11
arm64: dts: fsl-lx2160a-tqmlx2160a: add aliases for all 18 DPMAC
instances
arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: add various GPIO hogs
arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: enable pcs_mdio17 and
pcs_mdio18 in appropriate overlays
arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: specify Ethernet PHY
reset GPIOs
.../fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 306 +++++++++++++++++-
...l-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso | 20 ++
...sl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso | 20 ++
.../dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 23 +-
4 files changed, 357 insertions(+), 12 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH 4/7] arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: add various GPIO hogs
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Add GPIO hogs for various signals:
- Reset signals not assiciated with a device described in the Device
Tree (SATA, PCIe, ...)
- Inputs that must never be driven to avoid hardware damage
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 259 ++++++++++++++++++
1 file changed, 259 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
index a79290401551e..431e4ed2a8b86 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
@@ -187,6 +187,118 @@ gpioex3: gpio@20 {
#gpio-cells = <2>;
gpio-controller;
vcc-supply = <®_vcc3v3>;
+
+ line0-hog {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "NOR_SWAP#";
+ };
+
+ line1-hog {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "BOOT_SRC2";
+ };
+
+ line2-hog {
+ gpio-hog;
+ gpios = <2 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "BOOT_SRC1";
+ };
+
+ line3-hog {
+ gpio-hog;
+ gpios = <3 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "BOOT_SRC0";
+ };
+
+ line4-hog {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "EMMC_SEL1";
+ };
+
+ line5-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "EMMC_SEL0";
+ };
+
+ line6-hog {
+ gpio-hog;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_4_MUX_SEL";
+ };
+
+ line7-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_3_MUX_SEL";
+ };
+
+ line8-hog {
+ gpio-hog;
+ gpios = <8 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_2_MUX_SEL";
+ };
+
+ line9-hog {
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD1_MUX_SEL";
+ };
+
+ line10-hog {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "ENABLE_FAN";
+ };
+
+ line11-hog {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD3_MUX_SEL";
+ };
+
+ line12-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_7_MUX_SEL";
+ };
+
+ line13-hog {
+ gpio-hog;
+ gpios = <13 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_6_MUX_SEL";
+ };
+
+ line14-hog {
+ gpio-hog;
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ input;
+ /* Reserved */
+ };
+
+ line15-hog {
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "EC2_SEL";
+ };
};
};
@@ -223,6 +335,83 @@ gpioex0: gpio@20 {
#gpio-cells = <2>;
gpio-controller;
vcc-supply = <®_vcc3v3>;
+
+ line2-hog {
+ gpio-hog;
+ gpios = <2 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "QSFP_MODPRS#";
+ };
+
+ line3-hog {
+ gpio-hog;
+ gpios = <3 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "QSFP_INT#";
+ };
+
+ line5-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "IRQ_RETIMER_1#";
+ };
+
+ line6-hog {
+ gpio-hog;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "IRQ_RETIMER_2#";
+ };
+
+ line7-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "MPCIE_1_WAKE#";
+ };
+
+ line8-hog {
+ gpio-hog;
+ gpios = <8 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MPCIE_1_DISABLE#";
+ };
+
+ line9-hog {
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MPCIE_1_RESET#";
+ };
+
+ line10-hog {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "MPCIE_2_WAKE#";
+ };
+
+ line11-hog {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MPCIE_2_DISABLE#";
+ };
+
+ line12-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MPCIE_2_RESET#";
+ };
+
+ line15-hog {
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SIM_CARD_DETECT";
+ };
};
gpioex1: gpio@21 {
@@ -231,6 +420,20 @@ gpioex1: gpio@21 {
#gpio-cells = <2>;
gpio-controller;
vcc-supply = <®_vcc3v3>;
+
+ line13-hog {
+ gpio-hog;
+ gpios = <13 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "RST_M2_SATA_1#";
+ };
+
+ line14-hog {
+ gpio-hog;
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "RST_M2_SATA_2#";
+ };
};
gpioex2: gpio@22 {
@@ -239,6 +442,62 @@ gpioex2: gpio@22 {
#gpio-cells = <2>;
gpio-controller;
vcc-supply = <®_vcc3v3>;
+
+ line8-hog {
+ gpio-hog;
+ gpios = <8 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "XFI1_RET_LOSS";
+ };
+
+ line9-hog {
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "XFI2_RET_LOSS";
+ };
+
+ line10-hog {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "PCIE_1_PERST#";
+ };
+
+ line11-hog {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "PCIE_2_PERST#";
+ };
+
+ line12-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "PCIE_WAKE#";
+ };
+
+ line13-hog {
+ gpio-hog;
+ gpios = <13 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "X8_PRSNT1#";
+ };
+
+ line14-hog {
+ gpio-hog;
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "X4_1_PRSNT1#";
+ };
+
+ line15-hog {
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "X4_2_PRSNT1#";
+ };
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH 2/7] arm64: dts: fsl-lx2160a-tqmlx2160a-mblx2160a: use DPMAC 17 and 18 for SGMII in SERDES2 configs 7 and 11
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
We have been informed that using DPMAC 17 and 18 for RGMII when SERDES2
is configured to provide SGMII lanes for these MACs is unsupported and
will cause errors in certain DPAA2 configurations. Update these
configurations to use SGMII instead.
The total number of available Gbit Ethernet ports does not change, but
the PHYs and physical ports corresponding to DPMAC 17 and 18 do.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso | 12 ++++++++++++
.../fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso | 12 ++++++++++++
2 files changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
index 6d0c808cd840f..0847c786dc1ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
@@ -32,6 +32,18 @@ &dpmac16 {
managed = "in-band-status";
};
+&dpmac17 {
+ phy-handle = <&dp83867_1_2>;
+ phy-connection-type = "sgmii";
+ managed = "in-band-status";
+};
+
+&dpmac18 {
+ phy-handle = <&dp83867_1_3>;
+ phy-connection-type = "sgmii";
+ managed = "in-band-status";
+};
+
&pcs_mdio12 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
index db88a86ff69cd..7520f105d5d8c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
@@ -30,6 +30,18 @@ &dpmac16 {
managed = "in-band-status";
};
+&dpmac17 {
+ phy-handle = <&dp83867_1_2>;
+ phy-connection-type = "sgmii";
+ managed = "in-band-status";
+};
+
+&dpmac18 {
+ phy-handle = <&dp83867_1_3>;
+ phy-connection-type = "sgmii";
+ managed = "in-band-status";
+};
+
&pcs_mdio12 {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH 3/7] arm64: dts: fsl-lx2160a-tqmlx2160a: add aliases for all 18 DPMAC instances
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Each TQMX2160A comes with a block of 18 MAC addresses. Define aliases
to allow firmware to statically assign these addresses to the Ethernet
interfaces.
In addition, udev can use these aliases for predicable interface names.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
index 89a4765737b4f..5ca950ff908e7 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
@@ -8,6 +8,27 @@
#include "fsl-lx2160a.dtsi"
/ {
+ aliases {
+ ethernet0 = &dpmac1;
+ ethernet1 = &dpmac2;
+ ethernet2 = &dpmac3;
+ ethernet3 = &dpmac4;
+ ethernet4 = &dpmac5;
+ ethernet5 = &dpmac6;
+ ethernet6 = &dpmac7;
+ ethernet7 = &dpmac8;
+ ethernet8 = &dpmac9;
+ ethernet9 = &dpmac10;
+ ethernet10 = &dpmac11;
+ ethernet11 = &dpmac12;
+ ethernet12 = &dpmac13;
+ ethernet13 = &dpmac14;
+ ethernet14 = &dpmac15;
+ ethernet15 = &dpmac16;
+ ethernet16 = &dpmac17;
+ ethernet17 = &dpmac18;
+ };
+
reg_vcc3v3: regulator-vcc3v3 {
compatible = "regulator-fixed";
regulator-name = "VCC3V3";
--
2.43.0
^ permalink raw reply related
* [PATCH 5/7] arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: enable pcs_mdio17 and pcs_mdio18 in appropriate overlays
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
The pcs_mdio* instances are only needed with phy-connection-type =
"sgmii" and managed = "in-band-status". Move setting status = "okay" for
pcs_mdio17 and pcs_mdio18 to the appropriate overlays, for consistency
with the other pcs_mdio* instances.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 8 --------
.../fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso | 8 ++++++++
.../freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso | 8 ++++++++
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
index 431e4ed2a8b86..46a9fdc92bb56 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
@@ -545,14 +545,6 @@ i2c@3 {
};
};
-&pcs_mdio17 {
- status = "okay";
-};
-
-&pcs_mdio18 {
- status = "okay";
-};
-
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
index 0847c786dc1ca..497ea4ddef3e6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
@@ -59,3 +59,11 @@ &pcs_mdio14 {
&pcs_mdio16 {
status = "okay";
};
+
+&pcs_mdio17 {
+ status = "okay";
+};
+
+&pcs_mdio18 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
index 7520f105d5d8c..a51edef83317f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
@@ -58,6 +58,14 @@ &pcs_mdio16 {
status = "okay";
};
+&pcs_mdio17 {
+ status = "okay";
+};
+
+&pcs_mdio18 {
+ status = "okay";
+};
+
&sfp_xfi1 {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH 6/7] arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: specify Ethernet PHY reset GPIOs
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Correctly describe the PHY resets.
While the TI DP83867 requires only a 1us reset pulse in RGMII mode, 2.5ms
are needed for SGMII, where series capacitors would result in incorrect
sampling of strap pins if they don't have enough time to discharge.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
index 46a9fdc92bb56..687fd0d62235d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
@@ -106,36 +106,59 @@ &dpmac18 {
phy-connection-type = "rgmii-id";
};
+/*
+ * Assert reset for 2.5ms on SGMII PHYs to let capacitors discharge before
+ * strap pin sampling
+ */
+
&emdio1 {
status = "okay";
dp83867_1_1: ethernet-phy@1 {
reg = <1>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 1 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_2: ethernet-phy@2 {
reg = <2>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 2 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_3: ethernet-phy@3 {
reg = <3>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 3 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_4: ethernet-phy@4 {
reg = <4>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 4 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_5: ethernet-phy@5 {
reg = <5>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 5 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_6: ethernet-phy@6 {
reg = <6>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 6 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
};
@@ -145,16 +168,25 @@ &emdio2 {
dp83867_2_1: ethernet-phy@1 {
reg = <1>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 7 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_2_2: ethernet-phy@2 {
reg = <2>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 8 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_2_3: ethernet-phy@3 {
reg = <3>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 9 GPIO_ACTIVE_LOW>;
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
@@ -162,6 +194,9 @@ dp83867_2_3: ethernet-phy@3 {
dp83867_2_4: ethernet-phy@4 {
reg = <4>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 10 GPIO_ACTIVE_LOW>;
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
--
2.43.0
^ permalink raw reply related
* [PATCH 7/7] arm64: dts: fsl-lx2160a-tqmlx2160a: Remove deprecated properties
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: linux-arm-kernel, linux, devicetree, linux-kernel, Nora Schiffer
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
Setting #size-cells in MTD nodes itself is deprecated by mtd.yaml.
Remove the deprecated properties. Fixes the warning:
fsl-lx2160a-tqmlx2160a.dtsi:62.18-76.4: Warning
(avoid_unnecessary_addr_size): /soc/spi@20c0000/flash@0: unnecessary
#address-cells/#size-cells without "ranges", "dma-ranges" or child "reg"
or "ranges" property
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
index 5ca950ff908e7..d64879ee5e54a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
@@ -62,8 +62,6 @@ &fspi {
flash0: flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
- #address-cells = <1>;
- #size-cells = <1>;
spi-max-frequency = <10000000>;
spi-rx-bus-width = <1>;
spi-tx-bus-width = <1>;
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] reset: amlogic: t7: Fix null reset ops
From: Ronald Claveau @ 2026-03-31 14:24 UTC (permalink / raw)
To: Philipp Zabel, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree,
Ronald Claveau
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-0-eb95b625234c@aliel.fr>
Fix missing reset ops causing kernel null pointer dereference.
This SOC's reset is currently not used yet.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/reset/amlogic/reset-meson.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/reset/amlogic/reset-meson.c b/drivers/reset/amlogic/reset-meson.c
index 84610365a823c..c303e8590dd68 100644
--- a/drivers/reset/amlogic/reset-meson.c
+++ b/drivers/reset/amlogic/reset-meson.c
@@ -42,6 +42,7 @@ static const struct meson_reset_param meson_s4_param = {
};
static const struct meson_reset_param t7_param = {
+ .reset_ops = &meson_reset_ops,
.reset_num = 224,
.reset_offset = 0x0,
.level_offset = 0x40,
--
2.49.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: amlogic: t7: Fix missing required reset property
From: Ronald Claveau @ 2026-03-31 14:24 UTC (permalink / raw)
To: Philipp Zabel, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree,
Ronald Claveau
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-0-eb95b625234c@aliel.fr>
CHECK_DTBS shows missing reset required property in T7 DTBS.
A new CHECK_DTBS with this patch does not show this anymore.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 02a303d4ec39d..5069f29d2fbb7 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -582,6 +582,7 @@ sd_emmc_a: mmc@88000 {
<&clkc_periphs CLKID_SD_EMMC_A>,
<&scmi_clk CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
+ resets = <&reset RESET_SD_EMMC_A>;
assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_A_SEL>;
assigned-clock-parents = <&xtal>;
status = "disabled";
@@ -595,6 +596,7 @@ sd_emmc_b: mmc@8a000 {
<&clkc_periphs CLKID_SD_EMMC_B>,
<&scmi_clk CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
+ resets = <&reset RESET_SD_EMMC_B>;
assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_B_SEL>;
assigned-clock-parents = <&xtal>;
status = "disabled";
@@ -608,6 +610,7 @@ sd_emmc_c: mmc@8c000 {
<&clkc_periphs CLKID_SD_EMMC_C>,
<&scmi_clk CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
+ resets = <&reset RESET_SD_EMMC_C>;
assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C_SEL>;
assigned-clock-parents = <&xtal>;
status = "disabled";
--
2.49.0
^ permalink raw reply related
* [PATCH 0/2] Fix Amlogic T7 null reset ops and DT required property
From: Ronald Claveau @ 2026-03-31 14:24 UTC (permalink / raw)
To: Philipp Zabel, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree,
Ronald Claveau
1. As reset is required for MMC DT, this patch series aims to add the currently missing required driver ops.
Whithout this patch the following kernel null error appears:
[ 0.459197] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 0.459978] Mem abort info:
[ 0.460324] ESR = 0x0000000096000004
[ 0.460791] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.461471] SET = 0, FnV = 0
[ 0.461830] EA = 0, S1PTW = 0
[ 0.462220] FSC = 0x04: level 0 translation fault
[ 0.462722] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 0.462826] Data abort info:
[ 0.462829] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 0.462842] Mem abort info:
[ 0.462849] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 0.462859] ESR = 0x0000000096000004
[ 0.462865] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 0.462874] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.462882] [0000000000000000] user address but active_mm is swapper
[ 0.462890] SET = 0, FnV = 0
[ 0.462901] Internal error: Oops: 0000000096000004 [#1] SMP
[ 0.462909] EA = 0, S1PTW = 0
[ 0.462917] Modules linked in:
[ 0.462925] FSC = 0x04: level 0 translation fault
[ 0.462932]
[ 0.462939] Data abort info:
[ 0.462951] CPU: 4 UID: 0 PID: 90 Comm: kworker/u34:3 Not tainted 7.0.0-rc4-next-20260319 #41 PREEMPT
[ 0.463920] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 0.463927] Hardware name: Khadas VIM4 (DT)
[ 0.463940] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 0.463951] Workqueue: async async_run_entry_fn
[ 0.464277] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 0.464286]
[ 0.464294] [0000000000000000] user address but active_mm is swapper
[ 0.464304] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.465935] pc : reset_control_reset+0x48/0x1d0
[ 0.466409] lr : reset_control_reset+0x38/0x1d0
[ 0.479907] sp : ffff800083943b60
[ 0.479911] x29: ffff800083943b60 x28: 0000000000000000 x27: 0000000000000000
[ 0.479926] x26: ffff80008310a9c0 x25: 0000000000000000 x24: ffff000100372005
[ 0.481212] x23: ffff0001003a4000 x22: ffff000100fee988 x21: 0000000000000000
[ 0.482976] x20: ffff00023f00a788 x19: ffff000100fee980 x18: 0000000000000006
[ 0.483865] x17: 64656c62616e655f x16: 7469647561206465 x15: ffff800083943530
[ 0.484753] x14: 0000000000000000 x13: 000000000000022d x12: 0000000000002000
[ 0.485642] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
[ 0.486530] x8 : ffff00023efd8a40 x7 : fffffffffffffe70 x6 : ffff00023efd89e0
[ 0.487418] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
[ 0.488307] x2 : ffff000102002488 x1 : ffff8000822248c0 x0 : 0000000000000000
[ 0.489196] Call trace:
[ 0.489500] reset_control_reset+0x48/0x1d0 (P)
[ 0.490062] __device_reset+0xc8/0xfc
[ 0.490517] meson_mmc_probe+0xe8/0x3d4
[ 0.490994] platform_probe+0x5c/0x98
[ 0.491448] really_probe+0xbc/0x298
[ 0.491892] __driver_probe_device+0x78/0x12c
[ 0.492434] driver_probe_device+0xd4/0x164
[ 0.492954] __device_attach_driver+0xb8/0x140
[ 0.493507] bus_for_each_drv+0x84/0xe0
[ 0.493983] __device_attach_async_helper+0xac/0xd0
[ 0.494590] async_run_entry_fn+0x34/0xe0
[ 0.495089] process_one_work+0x158/0x29c
[ 0.495587] worker_thread+0x18c/0x308
[ 0.496053] kthread+0x11c/0x128
[ 0.496453] ret_from_fork+0x10/0x20
[ 0.496904] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
[ 0.497661] ---[ end trace 0000000000000000 ]---
[ 0.498234] Internal error: Oops: 0000000096000004 [#2] SMP
[ 0.498935] Modules linked in:
[ 0.499319] CPU: 1 UID: 0 PID: 88 Comm: kworker/u34:1 Tainted: G D 7.0.0-rc4-next-20260319 #41 PREEMPT
[ 0.500669] Tainted: [D]=DIE
[ 0.501025] Hardware name: Khadas VIM4 (DT)
[ 0.501547] Workqueue: async async_run_entry_fn
[ 0.502109] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.502975] pc : reset_control_reset+0x48/0x1d0
[ 0.503538] lr : reset_control_reset+0x38/0x1d0
[ 0.504102] sp : ffff800083903b60
[ 0.504513] x29: ffff800083903b60 x28: 0000000000000000 x27: 0000000000000000
[ 0.505402] x26: ffff000100059028 x25: 0000000000000000 x24: ffff000100372005
[ 0.506290] x23: ffff000100ec9400 x22: ffff0001003f6e08 x21: 0000000000000000
[ 0.507178] x20: ffff00023f00b440 x19: ffff0001003f6e00 x18: 00000000ffffffff
[ 0.508067] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000839037e0
[ 0.508955] x14: 0000000000000000 x13: 0000000000000290 x12: 0000000000002000
[ 0.509843] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
[ 0.510732] x8 : ffff00023efd8bc0 x7 : fffffffffffffe70 x6 : ffff00023efd8b60
[ 0.511620] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
[ 0.512508] x2 : ffff000102002488 x1 : ffff800082224a40 x0 : 0000000000000000
[ 0.513397] Call trace:
[ 0.513700] reset_control_reset+0x48/0x1d0 (P)
[ 0.514263] __device_reset+0xc8/0xfc
[ 0.514718] meson_mmc_probe+0xe8/0x3d4
[ 0.515195] platform_probe+0x5c/0x98
[ 0.515650] really_probe+0xbc/0x298
[ 0.516094] __driver_probe_device+0x78/0x12c
[ 0.516636] driver_probe_device+0xd4/0x164
[ 0.517156] __device_attach_driver+0xb8/0x140
[ 0.517709] bus_for_each_drv+0x84/0xe0
[ 0.518185] __device_attach_async_helper+0xac/0xd0
[ 0.518792] async_run_entry_fn+0x34/0xe0
[ 0.519290] process_one_work+0x158/0x29c
[ 0.519788] worker_thread+0x18c/0x308
[ 0.520254] kthread+0x11c/0x128
[ 0.520655] ret_from_fork+0x10/0x20
[ 0.521103] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
[ 0.521860] ---[ end trace 0000000000000000 ]---
2. The following patch yet to merge reports a missing required property with CHECK_DTBS=y
https://lore.kernel.org/r/20260326-add-emmc-t7-vim4-v5-3-d3f182b48e9d@aliel.fr/
/home/rony/project/khadas/fenix/build/linux/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: mmc@88000 (amlogic,t7-mmc): 'resets' is a required property
from schema $id: http://devicetree.org/schemas/mmc/amlogic,meson-gx-mmc.yaml
/home/rony/project/khadas/fenix/build/linux/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: mmc@8a000 (amlogic,t7-mmc): 'resets' is a required property
from schema $id: http://devicetree.org/schemas/mmc/amlogic,meson-gx-mmc.yaml
/home/rony/project/khadas/fenix/build/linux/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: mmc@8c000 (amlogic,t7-mmc): 'resets' is a required property
from schema $id: http://devicetree.org/schemas/mmc/amlogic,meson-gx-mmc.yaml
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Ronald Claveau (2):
reset: amlogic: t7: Fix null reset ops
arm64: dts: amlogic: t7: Fix missing required reset property
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 3 +++
drivers/reset/amlogic/reset-meson.c | 1 +
2 files changed, 4 insertions(+)
---
base-commit: f6eb9ae8b9fc13c3971e4a6d1e8442f253001f36
change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4
prerequisite-change-id: 20260320-add-emmc-t7-vim4-6ad16e94614f:v5
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* Re: [PATCH v4 0/4] firmware: ti_sci: Introduce BOARDCFG_MANAGED mode for Jacinto family
From: Thomas Richard @ 2026-03-31 14:28 UTC (permalink / raw)
To: Dhruva Gole
Cc: Nishanth Menon, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, Gregory CLEMENT, richard.genoud, Udit Kumar,
Prasanth Mantena, Abhash Kumar, Thomas Petazzoni,
linux-arm-kernel, linux-kernel, linux-clk
In-Reply-To: <20260209095159.pfcthh5a4yo4q2em@lcpd911>
Hello Dhruva,
Thanks for the review.
On 2/9/26 10:51 AM, Dhruva Gole wrote:
> On Feb 04, 2026 at 16:03:37 +0100, Thomas Richard (TI) wrote:
>> The fourth iteration of this series adds support for two new firmware
>> capabilities:
>> - MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST: Indicates that DM-Firmware is not
>> able to restore IRQ context during resume after suspend-to-ram.
>> - MSG_FLAG_CAPS_LPM_CLK_CONTEXT_LOST: Indicates that DM-Firmware is not
>> able to restore clock context (rate and parent configuration) during
>> resume after suspend-to-ram.
>>
>> Now, ti_sci driver determines whether to restore IRQs based on the
>> MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST capability rather than the
>> BOARDCFG_MANAGED mode. The same logic applies to the clock context.
>>
>> Both J784s4 and J7200 platforms support these new capabilities. A
>> corresponding pull request has been submitted on DM-Firmware side to
>> define and enable these capabilities.
>>
>> The value for the BOARDCFG_MANAGED mode has also been fixed.
>>
>> Public documentation for BOARDCFG_MANAGED mode and these new capabilities
>> is currently unavailable. I will update the series with relevant
>> documentation references as soon as they become available.
>>
>> I rebased the series on linux-next next-20260202.
>>
>> Best Regards,
>> Thomas
>>
>> Signed-off-by: Thomas Richard (TI) <thomas.richard@bootlin.com>
>> ---
>> Changes in v4:
>> - rebase on linux-next next-20260202.
>> - fix BOARDCFG_MANAGED value.
>> - add MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST firmware capability.
>> - add MSG_FLAG_CAPS_LPM_CLK_CONTEXT_LOST firmware capability.
>> - Link to v3: https://lore.kernel.org/r/20251205-ti-sci-jacinto-s2r-restore-irq-v3-0-d06963974ad4@bootlin.com
>>
>> Changes in v3:
>> - rebased on linux-next
>> - sci-clk: context_restore() operation restores also rate.
>> - Link to v2: https://lore.kernel.org/r/20251127-ti-sci-jacinto-s2r-restore-irq-v2-0-a487fa3ff221@bootlin.com
>>
>> Changes in v2:
>> - ti_sci: use hlist to store IRQs.
>> - sci-clk: add context_restore operation
>> - ti_sci: restore clock parents during resume
>> - Link to v1: https://lore.kernel.org/r/20251017-ti-sci-jacinto-s2r-restore-irq-v1-0-34d4339d247a@bootlin.com
>>
>> ---
>> Thomas Richard (TI) (4):
>> firmware: ti_sci: add BOARDCFG_MANAGED mode support
>> firmware: ti_sci: add support for restoring IRQs during resume
>> clk: keystone: sci-clk: add restore_context() operation
>> firmware: ti_sci: add support for restoring clock context during resume
>
> The series looks good to me, just checking if maintainer prefers the 2/4
> PATCH on IRQ restore to be split up. IMO similar to how you've split up
> the clk restore support and then actually restored clk context in
> another patch, you can do similar split up for IRQ.
> No strong opinions from my side though.
Splitting clock part in 2 commits makes sense because two drivers are
involved. For IRQ part you would have a first patch adding all the hlist
logic only if MSG_FLAG_CAPS_LPM_IRQ_CONTEXT_LOST, and you just fill the
hlist. Then a second path adds the missing part in resume() path. I
think it is a bit odd, but no strong opinions.
If someone really wants this split up please let me know.
Best Regards,
Thomas
^ permalink raw reply
* Re: [PATCH v4 2/3] driver core: make software nodes available earlier
From: Arnd Bergmann @ 2026-03-31 14:28 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Dmitry Torokhov, Bartosz Golaszewski, Greg Kroah-Hartman,
Rafael J . Wysocki, Danilo Krummrich, Daniel Scally,
Heikki Krogerus, Sakari Ailus, Aaro Koskinen, Janusz Krzysztofik,
Tony Lindgren, Russell King, Kevin Hilman, Bartosz Golaszewski,
driver-core, linux-kernel, linux-acpi, linux-arm-kernel,
Linux-OMAP
In-Reply-To: <acuraLhLVgyP-LUK@ashevche-desk.local>
On Tue, Mar 31, 2026, at 13:09, Andy Shevchenko wrote:
> On Tue, Mar 31, 2026 at 12:45:59PM +0200, Arnd Bergmann wrote:
>> On Tue, Mar 31, 2026, at 10:55, Andy Shevchenko wrote:
>>
>> My best guess is that __exit_call should just use
>> __attribute__((unused)) instead of __attribute__((used)) and
>> have the compiler drop it from built-in code instead of the linker:
>
> But why do we need that at all? Can we just drop the full section for good.
> Or i.o.w. where exactly is it being used in the current kernel?
The main use case I see for __exit_call is for device drivers
that can be either loadable modules or built-in: In a loadable module,
you need the cleanup function, but for built-in code you want
it to be dropped at build time.
For the few direct callers of __exitcall, the only explanation I have
is that these could at some point be turned into loadable modules,
and the author wanted to be prepared for changing it later. In theory
we could change those to module_exit(), or just remove them, but
there is little practical benefit either way.
I've tested the __maybe_unused change on randconfig builds now and
found no (build-time) issues with that, so I'm submitting that
now.
Arnd
^ permalink raw reply
* [PATCH v3] arm: multi_v7_defconfig: Enable BRIDGE and DP83848_PHY for TI AM57xx, AM437x and AM335x
From: Parvathi Pudi @ 2026-03-31 14:10 UTC (permalink / raw)
To: nm, vigneshr, linux, ardb, ebiggers, krzysztof.kozlowski, khilman,
arnd, geert+renesas, parvathi, tiwai, kory.maincent, andreas,
dmitry.baryshkov, prabhakar.mahadev-lad.rj, twoerner
Cc: linux-arm-kernel, linux-kernel, pratheesh, j-rameshbabu, praneeth,
srk, rogerq, danishanwar, m-malladi, krishna, mohan, pmohan,
basharath
This patch enables BRIDGE and DP83848_PHY as kernel modules for AM57xx,
AM437x and AM335x SoCs. BRIDGE is to support STP/RSTP Switch mode using
PRU-ICSS which got recently merged and DP83848 PHY driver to support
TI TLK10X PHY.
Signed-off-by: Parvathi Pudi <parvathi@couthit.com>
---
Changes from v2 to v3 :
*) No changes were made, only the version was updated.
*) Rebased the series on latest linux-next.
Changes from v1 to v2 :
*) Addressed Krzysztof's comments on this patch.
*) Rebased the series on latest linux-next.
arch/arm/configs/multi_v7_defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index bcc9aabc1202..13362286b111 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -149,6 +149,7 @@ CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=m
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
+CONFIG_BRIDGE=m
CONFIG_NET_DSA=m
CONFIG_QRTR=m
CONFIG_QRTR_SMD=m
@@ -288,6 +289,7 @@ CONFIG_ICPLUS_PHY=y
CONFIG_MARVELL_PHY=y
CONFIG_AT803X_PHY=y
CONFIG_ROCKCHIP_PHY=y
+CONFIG_DP83848_PHY=m
CONFIG_DP83867_PHY=y
CONFIG_CAN_AT91=m
CONFIG_CAN_FLEXCAN=m
--
2.43.0
^ permalink raw reply related
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