* Re: [PATCH v3 phy-next 2/8] soc: fsl: guts: add a global structure to hold state
From: Vladimir Oltean @ 2026-07-20 14:57 UTC (permalink / raw)
To: Michael Walle
Cc: devicetree, robh, conor+dt, vkoul, neil.armstrong, olteanv,
linux-phy
In-Reply-To: <20260720140139.dmgysphpse2jf3fi@skbuf>
Hi Michael,
On Mon, Jul 20, 2026 at 05:01:39PM +0300, Vladimir Oltean wrote:
> On Mon, Jul 20, 2026 at 01:50:49PM +0000, sashiko-bot@kernel.org wrote:
> > [Severity: High]
> > Will jumping to err_nomem cause a NULL pointer dereference?
> >
> > If the allocation of soc_dev_attr fails, the code now jumps to the error
> > handling path which dereferences soc_dev_attr to free its members:
> >
> > > @@ -269,6 +271,8 @@ static int __init fsl_guts_init(void)
> > > kfree(soc_dev_attr->revision);
> > > kfree(soc_dev_attr->serial_number);
> >
> > Since soc_dev_attr is NULL when this allocation fails, won't evaluating
> > soc_dev_attr->revision and other members result in a kernel panic?
>
> yeah.
>
> I tried to be nice and play with the existing "err_nomem" and "err"
> error handling labels, but the truth is that a single error cleanup path
> is just an antipattern that doesn't scale as code becomes more complex.
>
> Instead of having a single error handling procedure which needs to
> carefully fend off from various invalid contexts from all the goto
> sites, the standard convention is to have an incremental set of labels
> which undo just the setup that was done up to the goto jump site.
>
> I'll refactor fsl_guts_init() to use that convention for v4.
While I was doing this refactoring, I noticed that this code path:
if (soc_data)
soc_uid = fsl_guts_get_soc_uid(soc_data->sfp_compat,
soc_data->uid_offset);
if (soc_uid) {
soc_dev_attr->serial_number = kasprintf(GFP_KERNEL, "%016llX",
soc_uid);
// no kasprintf() NULL return code check here, unlike
// the rest of the code
}
soc_dev = soc_device_register(soc_dev_attr);
if (IS_ERR(soc_dev)) {
ret = PTR_ERR(soc_dev);
goto err;
}
proceeds with soc_device_register() even if fsl_guts_get_soc_uid() was
able to get a soc unique id from the security fuse processor, but we
fail to print that string to the soc_dev_attr->serial_number variable.
I don't see anywhere mentioned in commit 786dde1e59d7 ("soc: fsl: guts:
add serial_number support") that this would be intentional, so it can
just as well be an omission.
Is it OK if I replace the silent failure with a loud failure of the
entire fsl_guts_init()? The code executes only if soc_uid is non-zero
anyway.
kasprintf() fails only for memory related reasons.
^ permalink raw reply
* Re: [PATCH v5 2/5] mfd: axp20x-i2c: Fix i2c instantiation
From: Chen-Yu Tsai @ 2026-07-20 14:52 UTC (permalink / raw)
To: Jerome Brunet
Cc: Andre Przywara, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, devicetree, linux-kernel,
Sashiko
In-Reply-To: <20260720-axp318-regulator-v5-2-a1afa7ee24f9@baylibre.com>
On Mon, Jul 20, 2026 at 7:20 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> Apparently this device never really supported i2c instantiation via
> sysfs, because the driver does not even look at the i2c driver, which are
i2c device data?
> not set. It would only probe if the device matched through DT.
>
> Fix that for correctness, even-though it is probably useless.
> Add the missing AXP323 while at it.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/r/20260717090209.2A09B1F000E9@smtp.kernel.org
> Fixes: 41751b033aaa ("mfd: axp20x-i2c: Add i2c-ids to fix module auto-loading")
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Chen-Yu Tsai <wens@kernel.org>
As you said this is correct but mostly useless, as it is unlucky that
just happens to have a spare PMIC on a breakout board for the I2C
connection. And it's also useless if you can't describe all the other
connections.
> ---
> drivers/mfd/axp20x-i2c.c | 24 +++++++++++++-----------
> drivers/mfd/axp20x-rsb.c | 1 +
> drivers/mfd/axp20x.c | 1 -
> include/linux/mfd/axp20x.h | 3 +--
> 4 files changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
> index 5c93136f977e..a76bec5604c4 100644
> --- a/drivers/mfd/axp20x-i2c.c
> +++ b/drivers/mfd/axp20x-i2c.c
> @@ -35,6 +35,7 @@ static int axp20x_i2c_probe(struct i2c_client *i2c)
> axp20x->irq = i2c->irq;
> dev_set_drvdata(axp20x->dev, axp20x);
>
> + axp20x->variant = (kernel_ulong_t)i2c_get_match_data(i2c);
> ret = axp20x_match_device(axp20x);
> if (ret)
> return ret;
> @@ -76,17 +77,18 @@ MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
> #endif
>
> static const struct i2c_device_id axp20x_i2c_id[] = {
> - { "axp152" },
> - { "axp192" },
> - { "axp202" },
> - { "axp209" },
> - { "axp221" },
> - { "axp223" },
> - { "axp313a" },
> - { "axp717" },
> - { "axp803" },
> - { "axp806" },
> - { "axp15060" },
> + { .name = "axp152", .driver_data = AXP152_ID },
> + { .name = "axp192", .driver_data = AXP192_ID },
> + { .name = "axp202", .driver_data = AXP202_ID },
> + { .name = "axp209", .driver_data = AXP209_ID },
> + { .name = "axp221", .driver_data = AXP221_ID },
> + { .name = "axp223", .driver_data = AXP223_ID },
> + { .name = "axp313a", .driver_data = AXP313A_ID },
> + { .name = "axp323", .driver_data = AXP323_ID },
> + { .name = "axp717", .driver_data = AXP717_ID },
> + { .name = "axp803", .driver_data = AXP803_ID },
> + { .name = "axp806", .driver_data = AXP806_ID },
> + { .name = "axp15060", .driver_data = AXP15060_ID },
> { }
> };
> MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
> index 059656f2a1bd..8fdc870c1fe4 100644
> --- a/drivers/mfd/axp20x-rsb.c
> +++ b/drivers/mfd/axp20x-rsb.c
> @@ -35,6 +35,7 @@ static int axp20x_rsb_probe(struct sunxi_rsb_device *rdev)
> axp20x->irq = rdev->irq;
> dev_set_drvdata(&rdev->dev, axp20x);
>
> + axp20x->variant = (kernel_ulong_t)device_get_match_data(axp20x->dev);
> ret = axp20x_match_device(axp20x);
> if (ret)
> return ret;
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index 22baab6e10fa..84839d4aa1ca 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -1267,7 +1267,6 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> const struct mfd_cell *cells_no_irq = NULL;
> int nr_cells_no_irq = 0;
>
> - axp20x->variant = (long)device_get_match_data(dev);
> switch (axp20x->variant) {
> case AXP152_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp152_cells);
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index b352661d99a1..1badb4868d17 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -997,8 +997,7 @@ static inline int axp20x_read_variable_width(struct regmap *regmap,
> /**
> * axp20x_match_device(): Setup axp20x variant related fields
> *
> - * @axp20x: axp20x device to setup (.dev field must be set)
> - * @dev: device associated with this axp20x device
> + * @axp20x: axp20x device to setup (.dev and variant fields must be set)
> *
> * This lets the axp20x core configure the mfd cells and register maps
> * for later use.
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v5 1/5] mfd: axp20x: Constify axp313 and axp717 cells
From: Chen-Yu Tsai @ 2026-07-20 14:50 UTC (permalink / raw)
To: Jerome Brunet
Cc: Andre Przywara, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, devicetree, linux-kernel
In-Reply-To: <20260720-axp318-regulator-v5-1-a1afa7ee24f9@baylibre.com>
On Mon, Jul 20, 2026 at 7:20 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> mfd_cells array should generally be const and there does not seem to be
> anything against it for the axp313 and axp717.
>
> Constify the mfd_cells array for the axp313 and axp717 to be consitent
^ consistent
> with the other supported chips
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Acked-by: Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/2] media: i2c: Add driver for Sony IMX662 sensor
From: Jai Luthra @ 2026-07-20 14:44 UTC (permalink / raw)
To: Alexander Shiyan, Dave Stevenson
Cc: linux-media, devicetree, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sakari Ailus, Hans Verkuil,
Hans de Goede, Tetsuya Nomura, Manivannan Sadhasivam
In-Reply-To: <CAPY8ntAf9TjgW-E6WeJuMdsHy8pV8-CvqQJriWEFpgLB-brD5A@mail.gmail.com>
Hi Dave, Alexander,
Quoting Dave Stevenson (2026-03-13 01:20:15)
> Hi Alexander
>
> On Thu, 12 Mar 2026 at 15:11, Alexander Shiyan
> <eagle.alexander923@gmail.com> wrote:
> >
> > This patch adds a V4L2 subdevice driver for the Sony IMX662 CMOS image
> > sensor. The sensor has a native resolution of 1936x1100 (effective
> > 1920x1080) and can achieve up to 90 frames per second depending on
> > the configuration. The driver supports:
> > - MIPI CSI-2 with 2 or 4 data lanes.
> > - RAW10 and RAW12 formats (both colour and monochrome).
> > - Controls: exposure, analogue gain, horizontal/vertical blanking,
> > horizontal/vertical flip, brightness.
> > - A placeholder V4L2_CID_HDR_SENSOR_MODE control for future Clear HDR
> > support (the actual HDR modes are not yet implemented).
> > - Runtime PM.
> > - Cropping via the selection API.
> > - Multiple link frequencies selectable via device tree.
> >
> > Tested on ARM64 Rockchip RK3568 platform with a 24 MHz external clock
> > and various link frequencies.
>
> Interesting timing as I've been looking at IMX662 too, but on a Raspberry Pi.
> FWIW my driver is at
> https://github.com/6by9/linux/blob/rpi-6.12.y-imx662/drivers/media/i2c/imx662.c
>
I saw libcamera patches for IMX676, does the below branch have the latest
driver you plan to post as v2?
https://github.com/6by9/linux/blob/rpi-6.18.y-imx662-mainline-clean/drivers/media/i2c/imx662.c
> Comments are based on brief testing and reading of the code. This is
> not a full review.
>
> > Signed-off-by: Alexander Shiyan <eagle.alexander923@gmail.com>
[...]
> > +static int imx662_set_selection(struct v4l2_subdev *sd,
> > + struct v4l2_subdev_state *sd_state,
> > + struct v4l2_subdev_selection *sel)
> > +{
Can we keep cropping and binning out of the initial driver, and implement
it using the common raw sensor model directly?
I did it for IMX678 [1] on Sakari's suggestion [2]. The two sensors are
quite similar, so I'm happy to help in whatever way I can on getting this
working with the new model too :-)
[1]: https://lore.kernel.org/all/20260703-imx678-meta-v1-0-7c4924a0df05@ideasonboard.com/
[2]: https://lore.kernel.org/all/ag7oq5jO5G0rwvzb@kekkonen.localdomain/
Thanks,
Jai
> > + struct imx662 *imx662 = to_imx662(sd);
> > + struct v4l2_rect rect = sel->r;
> > + struct v4l2_rect *try_crop;
> > + struct v4l2_mbus_framefmt *try_fmt;
> > + u32 max_left, max_top;
> > +
> > + if (sel->target != V4L2_SEL_TGT_CROP)
> > + return -EINVAL;
> > +
> > + max_left = IMX662_PIXEL_ARRAY_LEFT + IMX662_PIXEL_ARRAY_WIDTH -
> > + IMX662_MIN_CROP_WIDTH;
> > + max_top = IMX662_PIXEL_ARRAY_TOP + IMX662_PIXEL_ARRAY_HEIGHT -
> > + IMX662_MIN_CROP_HEIGHT;
> > +
> > + rect.left = clamp_t(u32, rect.left, IMX662_PIXEL_ARRAY_LEFT, max_left);
> > + rect.top = clamp_t(u32, rect.top, IMX662_PIXEL_ARRAY_TOP, max_top);
> > +
> > + rect.width =
> > + clamp_t(u32,
> > + round_down(rect.width, IMX662_CROP_WIDTH_STEP),
> > + IMX662_MIN_CROP_WIDTH, IMX662_PIXEL_ARRAY_WIDTH);
> > + rect.height =
> > + clamp_t(u32,
> > + round_down(rect.height, IMX662_CROP_HEIGHT_STEP),
> > + IMX662_MIN_CROP_HEIGHT, IMX662_PIXEL_ARRAY_HEIGHT);
> > +
> > + if (rect.left + rect.width - 1 >
> > + IMX662_PIXEL_ARRAY_LEFT + IMX662_PIXEL_ARRAY_WIDTH - 1)
> > + rect.left =
> > + IMX662_PIXEL_ARRAY_LEFT + IMX662_PIXEL_ARRAY_WIDTH -
> > + rect.width;
> > + if (rect.top + rect.height - 1 >
> > + IMX662_PIXEL_ARRAY_TOP + IMX662_PIXEL_ARRAY_HEIGHT - 1)
> > + rect.top =
> > + IMX662_PIXEL_ARRAY_TOP + IMX662_PIXEL_ARRAY_HEIGHT -
> > + rect.height;
> > +
> > + if (sel->flags & V4L2_SEL_FLAG_GE) {
> > + if (rect.width < sel->r.width) {
> > + u32 new_width = rect.width + IMX662_CROP_WIDTH_STEP;
> > +
> > + if (new_width <= IMX662_PIXEL_ARRAY_WIDTH)
> > + rect.width = new_width;
> > + }
> > + if (rect.height < sel->r.height) {
> > + u32 new_height = rect.height + IMX662_CROP_HEIGHT_STEP;
> > +
> > + if (new_height <= IMX662_PIXEL_ARRAY_HEIGHT)
> > + rect.height = new_height;
> > + }
> > + }
> > +
> > + if (sel->flags & V4L2_SEL_FLAG_LE) {
> > + if (rect.width > sel->r.width &&
> > + rect.width >= IMX662_MIN_CROP_WIDTH +
> > + IMX662_CROP_WIDTH_STEP)
> > + rect.width -= IMX662_CROP_WIDTH_STEP;
> > + if (rect.height > sel->r.height &&
> > + rect.height >= IMX662_MIN_CROP_HEIGHT +
> > + IMX662_CROP_HEIGHT_STEP)
> > + rect.height -= IMX662_CROP_HEIGHT_STEP;
> > + }
> > +
> > + if (rect.width < IMX662_MIN_CROP_WIDTH ||
> > + rect.height < IMX662_MIN_CROP_HEIGHT)
> > + return -EINVAL;
> > +
> > + if (sel->which == V4L2_SUBDEV_FORMAT_TRY) {
> > + try_crop = v4l2_subdev_state_get_crop(sd_state, sel->pad);
> > + *try_crop = rect;
> > +
> > + try_fmt = v4l2_subdev_state_get_format(sd_state, sel->pad);
> > + if (try_fmt) {
> > + try_fmt->width = rect.width;
> > + try_fmt->height = rect.height;
> > + }
> > + } else {
> > + if (imx662->streaming)
> > + return -EBUSY;
> > +
> > + if (imx662->crop.left == rect.left &&
> > + imx662->crop.top == rect.top &&
> > + imx662->crop.width == rect.width &&
> > + imx662->crop.height == rect.height) {
> > + sel->r = rect;
> > + return 0;
> > + }
> > +
> > + imx662->crop = rect;
> > +
> > + try_fmt = v4l2_subdev_state_get_format(sd_state, sel->pad);
> > + if (try_fmt) {
> > + try_fmt->width = rect.width;
> > + try_fmt->height = rect.height;
> > + }
> > +
> > + imx662_set_framing_limits(imx662);
> > + }
> > +
> > + sel->r = rect;
> > +
> > + return 0;
> > +}
[...]
^ permalink raw reply
* Re: [PATCH 1/5] dt-bindings: phy: qcom,qmp-usb3-dp: Extend X1E description for USB4
From: Konrad Dybcio @ 2026-07-20 14:41 UTC (permalink / raw)
To: Konrad Dybcio, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson
Cc: linux-kernel, linux-phy, linux-arm-msm, devicetree, usb4-upstream,
Raghavendra Thoorpu, Mika Westerberg, Sven Peter
In-Reply-To: <20260518-topic-usb4phy-v1-1-71d827c49dca@oss.qualcomm.com>
On 5/18/26 12:29 PM, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Some instances of the QMP combo PHY (called USB43DP) feature a third
> functional sub-block, responsible for USB4/Thunderbolt 3 communication.
>
> Compared to the today's state of the binding, one more clock (P2RR2P -
> PHY-to-Router, Router-to-PHY) needs to be enabled for the PHY to be
> able to switch to USB4 mode. Allow that for X1E.
>
> Also, add a bindings define to let consumers access it.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
It's been a while and I see Vinod is picking up patches.
Krzysztof, could you please take a look at this binding change?
Konrad
> .../devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml | 3 ++-
> include/dt-bindings/phy/phy-qcom-qmp.h | 1 +
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> index 3d537b7f9985..eba4bee474fb 100644
> --- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-usb43dp-phy.yaml
> @@ -52,7 +52,7 @@ properties:
> - const: ref
> - const: com_aux
> - const: usb3_pipe
> - - const: cfg_ahb
> + - enum: [ p2rr2p_pipe, cfg_ahb ]
>
> power-domains:
> maxItems: 1
> @@ -186,6 +186,7 @@ allOf:
> enum:
> - qcom,sc7180-qmp-usb3-dp-phy
> - qcom,sdm845-qmp-usb3-dp-phy
> + - qcom,x1e80100-qmp-usb3-dp-phy
> then:
> properties:
> clocks:
> diff --git a/include/dt-bindings/phy/phy-qcom-qmp.h b/include/dt-bindings/phy/phy-qcom-qmp.h
> index 6b43ea9e0051..1c3ce0c02b0c 100644
> --- a/include/dt-bindings/phy/phy-qcom-qmp.h
> +++ b/include/dt-bindings/phy/phy-qcom-qmp.h
> @@ -16,6 +16,7 @@
> /* QMP USB4-USB3-DP PHYs */
> #define QMP_USB43DP_USB3_PHY 0
> #define QMP_USB43DP_DP_PHY 1
> +#define QMP_USB43DP_USB4_PHY 2
>
> /* QMP PCIE PHYs */
> #define QMP_PCIE_PIPE_CLK 0
>
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: iommu: arm,smmu: Document interconnects property
From: Dmitry Baryshkov @ 2026-07-20 14:40 UTC (permalink / raw)
To: Bibek Kumar Patro
Cc: Bjorn Andersson, Will Deacon, Robin Murphy, Joerg Roedel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Rob Clark, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, Krzysztof Kozlowski
In-Reply-To: <9f31bf3d-3c7d-45ba-bc25-e6349f689b70@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 07:41:35PM +0530, Bibek Kumar Patro wrote:
>
>
> On 7/8/2026 8:48 PM, Bjorn Andersson wrote:
> > On Wed, Jul 08, 2026 at 08:22:00PM +0530, Bibek Kumar Patro wrote:
> > >
> > >
> > > On 7/7/2026 10:12 PM, Dmitry Baryshkov wrote:
> > > > On Tue, Jul 07, 2026 at 06:06:59PM +0530, Bibek Kumar Patro wrote:
> > > > >
> > > > >
> > > > > On 7/6/2026 11:09 PM, Dmitry Baryshkov wrote:
> > > > > > On Mon, Jul 06, 2026 at 10:26:34PM +0530, Bibek Kumar Patro wrote:
> > > > > > > Some SoC implementations require a bandwidth vote on an interconnect
> > > > > > > path before the SMMU register space is accessible. Add the optional
> > > > > >
> > > > > > Why is it limited only to those SoCs? Is it also applicable to other
> > > > > > Qualcomm SoCs?
> > > > > >
> > > > >
> > > > > I was hoping to keep this series focused on the core infrastructure
> > > > > changes: the bindings, base ICC bandwidth-voting support, and DT
> > > > > interconnect properties for the platforms currently supported on
> > > > > Qualcomm Linux and have been validated so far.
> > > > >
> > > > > The additional targets have not been tested yet, so I'd prefer
> > > > > to add their support in a separate follow-up series once validation
> > > > > is complete, rather than growing this series further. WDYT?
> > > >
> > > > Then it should be a part of the commit message. All SoCs since SDM12345
> > > > need to vote on the interconnect (and then, in the cover letter mention
> > > > that you convert only a few of the SoCs). We possibly can help with
> > > > testing on other platforms.
> > > >
> > >
> > > Ack, sounds reasonable.
> > > I'll add the first platform onwards which interconnect voting is required in
> > > commit description.
> >
> > But to what degree is this related to a specific set of platforms? If we
> > look ahead, aren't we expecting the list to grow to include all
> > platforms in the end - resulting in a lot of noise and churn.
> >
>
> We have seen this issue consistently on SM8750 and later platforms, along
> with at least one customer-reported instance on SM8550. As a result,
> downstream Android implementations already vote for the required
> interconnect bandwidth explicitly on these platforms.
>
> On Qualcomm Linux targets, we have observed similar issues on Kodiak, with a
> few occurrences on Talos as well.
>
> My understanding is that the interconnects property remains optional, but in
> practice it is needed for Adreno SMMU operation on these platforms.
So, it goes back to Kodiak and Talos. What about SM8150? SDM845? Earlier
platforms? Is it limited to MMU-500? A6xx+?
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 5/9] arm64: dts: imx8ulp-evk: Add gpio-keys node for power button
From: sashiko-bot @ 2026-07-20 14:37 UTC (permalink / raw)
To: Peng Fan (OSS); +Cc: robh, imx, Frank.Li, conor+dt, devicetree
In-Reply-To: <20260720-imx8ulp-dts-v2-5-d05c67676f53@nxp.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The power button lacks the `wakeup-source` property, preventing it from waking up the system from suspend.
--
--- Patch [5]: [PATCH v2 5/9] arm64: dts: imx8ulp-evk: Add gpio-keys node for power button ---
commit 7fed30ac7ebed8088b601492b14b387b09c09f46
Author: Peng Fan <peng.fan@nxp.com>
arm64: dts: imx8ulp-evk: Add gpio-keys node for power button
This commit adds a gpio-keys node for the power-on button to both the
imx8ulp-9x9-evk and imx8ulp-evk device trees. The button is mapped to
report KEY_POWER to user space.
> diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
> index 5497e3d78136f..af8f0d6087f71 100644
> --- a/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
> @@ -10,6 +10,18 @@
> / {
> model = "NXP i.MX8ULP EVK9";
> compatible = "fsl,imx8ulp-9x9-evk", "fsl,imx8ulp";
> +
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + button-power-on {
> + label = "PowerOn";
> + gpios = <&gpiof 11 GPIO_ACTIVE_LOW>;
> + linux,code = <KEY_POWER>;
[Severity: Medium]
Will this power button be able to wake the system from suspend? It looks
like the wakeup-source property is missing from this node, which might
prevent the button from acting as a wake source for the board.
> + };
> + };
> };
[ ... ]
> diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
> index 5dea66c1e7aa0..6a92c5ca9a412 100644
> --- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
> +++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
> @@ -20,6 +21,18 @@ chosen {
> stdout-path = &lpuart5;
> };
>
> + gpio-keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_gpio_keys>;
> +
> + button-power-on {
> + label = "PowerOn";
> + gpios = <&gpiof 31 GPIO_ACTIVE_LOW>;
> + linux,code = <KEY_POWER>;
[Severity: Medium]
Similarly here, does this button need the wakeup-source property to wake
the board from sleep states? Without it, the GPIO interrupt for the power
button may not be configured as a wake source when the system is suspended.
> + };
> + };
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720-imx8ulp-dts-v2-0-d05c67676f53@nxp.com?part=5
^ permalink raw reply
* Re: [PATCH v3 2/4] media: synopsys: hdmirx: add HDMI audio capture support
From: Dmitry Osipenko @ 2026-07-20 14:36 UTC (permalink / raw)
To: Igor Paunovic
Cc: Mauro Carvalho Chehab, Sebastian Reichel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <CAEWPSH70FecQRuGtA=S8+_CnLY5sMyf1j57Uwzwv54zceS1HZg@mail.gmail.com>
On 7/20/26 15:30, Igor Paunovic wrote:
> Hi Dmitry,
>
> Great to hear it works on the 5B -- thanks for testing!
>
> Agreed on the -EBUSY guard, done in my tree exactly as you wrote it.
> It also supersedes the suspend cancel/re-arm I had queued from the
> bot review: with suspend refused while audio_streaming is set, the
> worker can never be armed at suspend time, so those hunks are
> dropped.
>
> v4 follows shortly with this plus Sebastian's dts restructuring
> (shared disabled-by-default card in rk3588-extra.dtsi, renamed to
> "RK3588 HDMI-IN") and Krzysztof's binding comments (dai-common.yaml
> reference + unevaluatedProperties).
Re-arming will be best option if it works properly.
--
Best regards,
Dmitry
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: sound: fsl,imx-asrc: update port binding to support multiple pairs
From: Mark Brown @ 2026-07-20 14:28 UTC (permalink / raw)
To: shengjiu.wang
Cc: lgirdwood, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel,
festevam, shawnguo, linux-sound, devicetree, imx,
linux-arm-kernel, linux-kernel, shengjiu.wang, Xiubo.Lee,
nicoleotsuka, perex, tiwai, linuxppc-dev, Shengjiu Wang
In-Reply-To: <20260720095450.1618747-2-shengjiu.wang@oss.nxp.com>
[-- Attachment #1: Type: text/plain, Size: 668 bytes --]
On Mon, Jul 20, 2026 at 05:54:47PM +0800, shengjiu.wang@oss.nxp.com wrote:
> From: Shengjiu Wang <shengjiu.wang@nxp.com>
>
> The i.MX ASRC hardware supports up to three conversion pairs (A, B, C).
> The existing binding exposed only a single generic audio-graph port,
> which cannot represent the individual pair endpoints.
Please submit patches using subject lines reflecting the style for the
subsystem, this makes it easier for people to identify relevant patches.
Look at what existing commits in the area you're changing are doing and
make sure your subject lines visually resemble what they're doing.
There's no need to resubmit to fix this alone.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/6] dt-bindings: hwmon: add binding for adi,adt7470
From: Guenter Roeck @ 2026-07-20 14:24 UTC (permalink / raw)
To: Krzysztof Kozlowski, Luiz Angelo Daros de Luca
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chris Packham,
Andrew Morton, Darrick J. Wong, Uwe Kleine-König,
linux-hwmon, devicetree, linux-kernel, linux-pwm
In-Reply-To: <20260720-placid-fanatic-shrimp-d2bcd2@quoll>
On 7/19/26 23:47, Krzysztof Kozlowski wrote:
> On Fri, Jul 17, 2026 at 05:59:14PM -0300, Luiz Angelo Daros de Luca wrote:
>> The Analog Devices ADT7470 is a temperature monitor and PWM fan
>> controller. It supports up to 10 external temperature sensors and
>> up to 4 PWM fan outputs.
>
> A nit, subject: drop second/last, redundant "binding for". The
> "dt-bindings" prefix is already stating that these are bindings.
> See also:
> https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
>
>>
>> Add the YAML device tree binding documentation for it. This includes
>
> s/YAML//
> There is no YAML in Devicetree.
>
>> support for the thermal framework by defining the "#thermal-sensor-cells"
>> property, and support for the PWM subsystem by defining the "#pwm-cells"
>> property.
>>
>> Signed-off-by: Luiz Angelo Daros de Luca <luizluca@gmail.com>
>> ---
>> .../devicetree/bindings/hwmon/adi,adt7470.yaml | 62 ++++++++++++++++++++++
>> 1 file changed, 62 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml b/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml
>> new file mode 100644
>> index 000000000000..14bb6359c91f
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwmon/adi,adt7470.yaml
>> @@ -0,0 +1,62 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/hwmon/adi,adt7470.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Analog Devices ADT7470 hwmon sensor
>> +
>> +maintainers:
>> + - Luiz Angelo Daros de Luca <luizluca@gmail.com>
>> +
>> +description: |
>
> Do not need '|' unless you need to preserve formatting.
>
>> + The ADT7470 is a temperature monitor and multiple PWM outputs.
>> + It supports monitoring up to 10 external temperature sensors and controlling
>> + up to four fans.
>
> "controling fans" is confusing and suggests this is a fan controller, so
> you would need to reference proper schema for that. It is just PWM
> output, no? PWM output could also go to LEDs or motors (well, fan is a
> motor).
>
From the datasheet: "The ADT74701 controller is a multichannel
temperature sensor and PWM fan controller and fan speed monitor".
It is a fan controller which happens to use pwm signals to control
fan speeds. It is not a PWM controller, and its pwm outputs are not
intended to be used for anything but controlling fan speeds.
Technically it is _possible_ to use the pwm outputs to control
something else. But that does not mean that chip is a pwm controller.
It is still a fan controller. I don't mind modeling outputs as
non-fan-control pwm channels if that is what they are used for,
but that must be clearly distinguished in both the driver code
and the bindings.
Guenter
^ permalink raw reply
* Re: [PATCH v16 11/12] media: mediatek: jpeg: add jpeg compatible
From: sashiko-bot @ 2026-07-20 14:23 UTC (permalink / raw)
To: Kyrie Wu; +Cc: devicetree, robh, conor+dt, media-ci
In-Reply-To: <20260720133432.1042046-12-kyrie.wu@mediatek.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] Missing bounds check on the number of DT child nodes causes out-of-bounds array accesses and stack overflows.
- [High] Incorrect calculation of the 34-bit extension address for the encoder's stall address.
--
--- Patch [11]: [PATCH v16 11/12] media: mediatek: jpeg: add jpeg compatible ---
Note: The format of this report has been altered to provide a free-form
summary without quoting the original patch code, due to recitation
restrictions.
commit f9b0fac0a51678a6983018a9ca39e5cce2cb6604
Author: Kyrie Wu <kyrie.wu@mediatek.com>
media: mediatek: jpeg: add jpeg compatible
This commit adds JPEG encoder and decoder compatibles for the mt8196
platform. It sets up the variant data structures with appropriate
capabilities like multi-core and 34-bit support.
[Severity: High]
This isn't a bug introduced by this patch, but while reviewing the new
compatibles, I noticed a potential stack overflow in the core driver.
In drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:mtk_jpeg_probe(),
the code iterates over the device tree child nodes and sets
jpeg->max_hw_count to the total number of children, without capping it.
Later, in mtk_jpegenc_worker() and mtk_jpegdec_worker(), this unbounded
jpeg->max_hw_count is used as a loop limit to copy elements into the
comp_jpeg array, which is a fixed-size stack array. Additionally, in
mtk_jpegenc_hw_probe(), the hw_index is incremented and used without
bounds checking to store hardware instances into master_dev->enc_hw_dev.
Could a malformed device tree with more child nodes than the hardware limit
cause a stack buffer overflow or out-of-bounds write here? Should we add
bounds checking against MTK_JPEGENC_HW_MAX and MTK_JPEGDEC_HW_MAX?
[Severity: High]
This isn't a bug introduced by this patch, but adding support_34bit = true
for mt8196_jpegenc_drvdata exposes an existing issue in the encoder address
calculation.
In drivers/media/platform/mediatek/jpeg/mtk_jpeg_enc_hw.c at
mtk_jpeg_set_enc_dst(), when 34-bit support is enabled, the code calculates
the extended address using FIELD_PREP on the upper 32 bits of dma_addr.
It then writes the sum of this extended address and the buffer size to the
JPEG_ENC_STALL_ADDR0_EXT register. Because the extended address is a masked
bitfield representing the upper 32 bits, adding the raw byte length size
directly to this bitfield seems incorrect.
Could this result in writing an invalid, unmasked address extension to the
hardware registers, potentially leading to SMMU faults or memory corruption?
Should this instead calculate the upper 32 bits of the sum of dma_addr
and size?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720133432.1042046-1-kyrie.wu@mediatek.com?part=11
^ permalink raw reply
* Re: [PATCH 0/3] SM8450 IPA support
From: Konrad Dybcio @ 2026-07-20 14:21 UTC (permalink / raw)
To: Esteban Urrutia, Alex Elder, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alex Elder
Cc: linux-arm-msm, devicetree, linux-kernel, netdev
In-Reply-To: <3e70d77e-6bec-4e16-ae88-a4f5161f182e@proton.me>
On 7/8/26 10:45 PM, Esteban Urrutia wrote:
> On 7/8/26 3:49 PM, Alex Elder wrote:
>> This was interesting to see. It's something I should probably
>> document better. Most everything maps to the downstream code,
>> but it's not always completely obvious how, because the upstream
>> driver has evolved substantially.
>
> On a personal note, I'm surprised to see someone not from Qualcomm
> maintaining this driver. It must be hard, so kudos.
>
>> This means that the SRAM size (ipa_mem_data->smem_size) should
>> possibly be defined in devicetree (as the IMEM address and size
>> now are).
>>
>> The SMEM region is used for "IPA filter tables", and access to
>> it is shared between the AP and the modem. Unlike the other
>> (host) memory regions, the size used is *not* included in the
>> ipa_init_modem_driver_req message that communicates from the
>> AP to the modem where the regions are, and their sizes.
>>
>> So it's possible that the size used must actually match what
>> is expected by both the AP and modem. If that is the case,
>> using the smaller size might have problems on whichever
>> platform (SM8450?) expects the larger one.
>>
>> So I'm not sure whether using the smaller size for both
>> platforms is OK; someone from Qualcomm might be able to
>> answer that question.
>
> I actually went ahead and reviewed downstream device trees I found on
> GitHub (1) which contain both SM8450 and SM8475 device trees looking for
> the qcom,ipa-q6-smem-size property, which would correspond to the SRAM
> size, and to my surprise, this was set to 0x9000 for both SoCs.
> Most likely the commit I got the SRAM information from (2) never made it
> to production devices.
OK you meant the qcom,ipa-q6-smem-size property. I can't find what
it corresponds to, the name of the associated IOMMU stream
unfortunately doesn't hint at anything useful either..
Konrad
^ permalink raw reply
* Re: [PATCH v16 04/12] media: mediatek: jpeg: Fix buffer completion on multi-core streaming stop
From: sashiko-bot @ 2026-07-20 14:19 UTC (permalink / raw)
To: Kyrie Wu; +Cc: media-ci, conor+dt, devicetree, robh
In-Reply-To: <20260720133432.1042046-5-kyrie.wu@mediatek.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [High] The newly added calls to `vb2_wait_for_all_buffers(q)` in `mtk_jpeg_enc_stop_streaming()` and `mtk_jpeg_dec_stop_streaming()` introduce an unkillable deadlock (local denial of service) when there are unmatched buffers in the m2m queues.
Pre-existing issues:
- [High] A race condition between the hardware IRQ handler and the job timeout worker leads to a NULL pointer dereference and kernel panic.
--
--- Patch [4]: [PATCH v16 04/12] media: mediatek: jpeg: Fix buffer completion on multi-core streaming stop ---
commit 613fe46e184bc6ab593928ce530f8144c0d9af31
Author: Kyrie Wu <kyrie.wu@mediatek.com>
Subject: media: mediatek: jpeg: Fix buffer completion on multi-core streaming stop
Enhances the Mediatek JPEG driver's stability and reliability by ensuring
that all queued buffers are processed before stopping the streaming in
multi-core environments. It introduces a call to vb2_wait_for_all_buffers()
in the stop_streaming functions to prevent data loss.
> diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> index 7856a556ce68e..d0fb68bc884b4 100644
> --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> @@ -850,8 +850,12 @@ static struct vb2_v4l2_buffer *mtk_jpeg_buf_remove(struct mtk_jpeg_ctx *ctx,
> static void mtk_jpeg_enc_stop_streaming(struct vb2_queue *q)
> {
> struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> struct vb2_v4l2_buffer *vb;
>
> + if (jpeg->variant->multi_core)
> + vb2_wait_for_all_buffers(q);
[Severity: High]
Does this introduce a deadlock if userspace queues an unmatched number of
buffers, such as only OUTPUT buffers but no CAPTURE buffers, and then calls
VIDIOC_STREAMOFF?
When VIDIOC_STREAMOFF is called, the V4L2 framework invokes
v4l2_m2m_cancel_job(), which removes the context from the job queue. This
means no hardware worker will ever process the parked buffers.
Because the worker is cancelled, the buffers remain in the queue. Calling
vb2_wait_for_all_buffers() will block uninterruptibly waiting for the
owned_by_drv_count to drop to 0, which is structurally impossible here and
results in a hung task.
> +
> while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
> v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
> }
> @@ -859,6 +863,7 @@ static void mtk_jpeg_enc_stop_streaming(struct vb2_queue *q)
> static void mtk_jpeg_dec_stop_streaming(struct vb2_queue *q)
> {
> struct mtk_jpeg_ctx *ctx = vb2_get_drv_priv(q);
> + struct mtk_jpeg_dev *jpeg = ctx->jpeg;
> struct vb2_v4l2_buffer *vb;
>
> /*
> @@ -866,6 +871,9 @@ static void mtk_jpeg_dec_stop_streaming(struct vb2_queue *q)
> * Before STREAMOFF, we still have to return the old resolution and
> * subsampling. Update capture queue when the stream is off.
> */
> + if (jpeg->variant->multi_core)
> + vb2_wait_for_all_buffers(q);
[Severity: High]
Does this share the same hang issue as mtk_jpeg_enc_stop_streaming() above?
Waiting for buffers here after v4l2_m2m_cancel_job() has removed the context
from the job queue could similarly lead to an unkillable task if there are
unmatched buffers.
> +
> if (ctx->state == MTK_JPEG_SOURCE_CHANGE &&
> V4L2_TYPE_IS_CAPTURE(q->type)) {
[ ... ]
[Severity: High]
This is a pre-existing issue, but can this code encounter a NULL pointer
dereference if a hardware timeout occurs exactly when the hardware IRQ fires?
If the timeout occurs concurrently with the hardware IRQ, mtk_jpeg_enc_irq()
calls cancel_delayed_work().
Since this does not wait for the work to finish if it has already started
executing on another CPU, both mtk_jpeg_enc_done() and
mtk_jpeg_job_timeout_work() can execute concurrently:
CPU1 in mtk_jpeg_job_timeout_work():
src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
CPU2 in mtk_jpeg_enc_done():
src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
Because these removals are not externally coordinated, one thread will
retrieve NULL pointers for the buffers.
This thread then unconditionally dereferences the NULL dst_buf in
vb2_set_plane_payload() or v4l2_m2m_buf_done(), leading to a panic.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720133432.1042046-1-kyrie.wu@mediatek.com?part=4
^ permalink raw reply
* Re: [PATCH v16 12/12] media: mediatek: jpeg: add jpeg smmu sid setting
From: sashiko-bot @ 2026-07-20 14:19 UTC (permalink / raw)
To: Kyrie Wu; +Cc: robh, conor+dt, devicetree, media-ci
In-Reply-To: <20260720133432.1042046-13-kyrie.wu@mediatek.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Critical] Probe failure in SMMU initialization leaves dangling pointers in the global master device arrays and permanently increments hw_index, causing UAF and array OOB on deferred probes.
Pre-existing issues:
- [High] Blind dereference of HW arrays when child probes fail early.
--
--- Patch [12]: [PATCH v16 12/12] media: mediatek: jpeg: add jpeg smmu sid setting ---
commit 73b8529184733966196568926fff60cf629320ae
Author: Kyrie Wu <kyrie.wu@mediatek.com>
media: mediatek: jpeg: add jpeg smmu sid setting
Add a configuration to set jpeg dec & enc smmu sid
> diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> index 8e96501a4f9fa..bb9bdd9913d94 100644
> --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
[ ... ]
> @@ -1663,6 +1680,11 @@ static void mtk_jpegenc_worker(struct work_struct *work)
> jpeg_dst_buf->frame_num = ctx->total_frame_num;
> ctx->total_frame_num++;
> mtk_jpeg_enc_reset(comp_jpeg[hw_id]->reg_base);
> +
> + if (jpeg->variant->support_smmu && comp_jpeg[hw_id]->smmu_regmap)
> + mtk_jpeg_set_smmu_sid(comp_jpeg[hw_id]->smmu_regmap,
> + JPG_REG_GUSER_ID_ENC_SID);
> +
[Severity: High]
This isn't a bug introduced by this patch, but I have a question about how
unpopulated hardware array entries are handled when a child probe fails.
In mtk_jpegenc_worker(), it calls mtk_jpegenc_get_hw() to select the hw_id.
If an earlier probe failure left the array entry in enc_hw_dev as NULL, could
this result in a NULL pointer dereference?
mtk_jpegenc_get_hw() iterates based on max_hw_count (which is set from the
Device Tree child nodes) and accesses the state directly:
drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c:mtk_jpegenc_get_hw() {
...
for (i = 0; i < jpeg->max_hw_count; i++) {
comp_jpeg = jpeg->enc_hw_dev[i];
if (comp_jpeg->hw_state == MTK_JPEG_HW_IDLE) {
...
}
Could this blindly dereference comp_jpeg if the child probe never completed
and left it NULL? The exact same pattern seems to exist in mtk_jpegdec_get_hw().
> mtk_jpeg_set_enc_dst(ctx,
> comp_jpeg[hw_id]->reg_base,
> &dst_buf->vb2_buf);
[ ... ]
> diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
> index 07452249bcb67..3058fdf4f6054 100644
> --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
> +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_dec_hw.c
[ ... ]
> @@ -665,6 +684,10 @@ static int mtk_jpegdec_hw_probe(struct platform_device *pdev)
> master_dev->reg_decbase[i] = dev->reg_base;
> dev->master_dev = master_dev;
>
> + ret = mtk_jpegdec_smmu_init(dev);
> + if (ret)
> + return ret;
> +
[Severity: Critical]
If mtk_jpegdec_smmu_init() fails and returns an error like -EPROBE_DEFER,
will this leave a dangling pointer in the master_dev->dec_hw_dev array?
Looking earlier in mtk_jpegdec_hw_probe(), dev is allocated with devm_kzalloc
and added to the master_dev array, and hw_index is incremented:
i = atomic_add_return(1, &master_dev->hw_index) - 1;
master_dev->dec_hw_dev[i] = dev;
master_dev->reg_decbase[i] = dev->reg_base;
dev->master_dev = master_dev;
ret = mtk_jpegdec_smmu_init(dev);
if (ret)
return ret;
When returning ret, the devm-managed dev will be freed, but the pointer
remains in master_dev->dec_hw_dev[i] and hw_index is never decremented.
Could this lead to an out-of-bounds write on deferred probe retries and a
use-after-free when the worker thread accesses the array?
This same issue seems to be present in mtk_jpegenc_hw_probe() in
mtk_jpeg_enc_hw.c as well.
> platform_set_drvdata(pdev, dev);
> pm_runtime_enable(&pdev->dev);
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720133432.1042046-1-kyrie.wu@mediatek.com?part=12
^ permalink raw reply
* Re: [PATCH 0/3] SM8450 IPA support
From: Konrad Dybcio @ 2026-07-20 14:18 UTC (permalink / raw)
To: Alex Elder, Esteban Urrutia, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alex Elder
Cc: linux-arm-msm, devicetree, linux-kernel, netdev
In-Reply-To: <8309e9c7-a110-478b-8cd4-c002070d2b4c@riscstar.com>
On 7/8/26 9:49 PM, Alex Elder wrote:
> On 6/23/26 8:57 PM, Esteban Urrutia wrote:
>> On 6/23/26 11:56 AM, Alex Elder wrote:
>>> I assume you have implemented this based on what you found in
>>> some downstream code. And if so, could you please indicate
>>> where to find that (so I can do some cross-referencing myself).
>>> I no longer have access to any Qualcomm internal documentation.
[...]
>> It's worth mentioning that between SM8450 and SM8475, IPA SRAM size is
>> different, so I used the smaller SRAM size to support SM8475 as well. Hence
>> the reason why I included SM8475's downstream device tree as well.
I can't find information that would confirm that. Where do you see
this difference?
Konrad
^ permalink raw reply
* Re: [PATCH v16 10/12] media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgenc compatible
From: sashiko-bot @ 2026-07-20 14:16 UTC (permalink / raw)
To: Kyrie Wu; +Cc: media-ci, robh, conor+dt, devicetree
In-Reply-To: <20260720133432.1042046-11-kyrie.wu@mediatek.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Inaccurate documentation for the `iommus` property regarding the MT8196 SMMU change.
--
--- Patch [10]: [PATCH v16 10/12] media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgenc compatible ---
commit 11c0f39e5d822c22a0e461d70a256b8d2035d561
Author: Kyrie Wu <kyrie.wu@mediatek.com>
media: dt-bindings: mediatek,jpeg: Add mediatek, mt8196-jpgenc compatible
This patch adds the mediatek,mt8196-jpgenc compatible string to the
MediaTek JPEG encoder binding. The commit message notes that the MT8196
uses an SMMU instead of an IOMMU.
> diff --git a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml
> --- a/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml
> +++ b/Documentation/devicetree/bindings/media/mediatek,mt8195-jpegenc.yaml
> @@ -14,14 +14,16 @@ description:
>
> properties:
> compatible:
> - const: mediatek,mt8195-jpgenc
> + enum:
> + - mediatek,mt8195-jpgenc
> + - mediatek,mt8196-jpgenc
>
> power-domains:
> maxItems: 1
>
> iommus:
> maxItems: 4
> description:
> Points to the respective IOMMU block with master port as argument, see
> Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details.
[Severity: Low]
The commit message states that MT8196 uses an SMMU instead of an IOMMU, but the
documentation for properties.iommus still hardcodes references to
mediatek,iommu.yaml and specifies using a master port as argument.
Since SMMUs typically use stream IDs rather than master ports, does this
documentation regression need to be updated or generalized to remain accurate
for the newly added mt8196-jpgenc compatible?
[ ... ]
> @@ -44,14 +46,16 @@ patternProperties:
>
> properties:
> compatible:
> - const: mediatek,mt8195-jpgenc-hw
> + enum:
> + - mediatek,mt8195-jpgenc-hw
> + - mediatek,mt8196-jpgenc-hw
>
> reg:
> maxItems: 1
>
> iommus:
> minItems: 1
> maxItems: 32
> description:
> List of the hardware port in respective IOMMU block for current Socs.
> Refer to bindings/iommu/mediatek,iommu.yaml.
[Severity: Low]
Similarly, the patternProperties.iommus description for the hardware nodes
still hardcodes the legacy mediatek,iommu.yaml reference.
Would it make sense to update this description as well to account for the
SMMU change described in the commit message?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720133432.1042046-1-kyrie.wu@mediatek.com?part=10
^ permalink raw reply
* Re: [PATCH v16 08/12] media: mediatek: jpeg: fix remove buffer removal timing for multi-core
From: sashiko-bot @ 2026-07-20 14:13 UTC (permalink / raw)
To: Kyrie Wu; +Cc: media-ci, devicetree, robh, conor+dt
In-Reply-To: <20260720133432.1042046-9-kyrie.wu@mediatek.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
New issues:
- [High] List corruption and race condition due to delayed buffer removal from the V4L2 M2M ready queues.
Pre-existing issues:
- [High] Potential Use-After-Free due to scheduling timeout work before acquiring hardware locks.
- [High] Lack of synchronization between the hardware IRQ handler and job timeout worker leads to double completion.
- [High] Use-After-Free of `mtk_jpeg_ctx` during file descriptor release.
- [High] Unkillable deadlock in `stop_streaming` when buffers are queued but M2M job is not started.
--
--- Patch [8]: [PATCH v16 08/12] media: mediatek: jpeg: fix remove buffer removal timing for multi-core ---
commit ddec7ab7308507663bea72ead9e975996dce1888
Author: Kyrie Wu <kyrie.wu@mediatek.com>
media: mediatek: jpeg: fix remove buffer removal timing for multi-core
This commit moves the calls to v4l2_m2m_src_buf_remove() and
v4l2_m2m_dst_buf_remove() inside the spinlock-protected scope in the jpeg
encoder and decoder workers. This is intended to ensure buffers are properly
synchronized before removal from their queues to avoid buffer loss.
> diff --git a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> --- a/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mediatek/jpeg/mtk_jpeg_core.c
> @@ -1654,9 +1654,6 @@ static void mtk_jpegenc_worker(struct work_struct *work)
> goto enc_end;
> }
>
> - v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> - v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
> -
> schedule_delayed_work(&comp_jpeg[hw_id]->job_timeout_work,
> msecs_to_jiffies(MTK_JPEG_HW_TIMEOUT_MSEC));
>
> spin_lock_irqsave(&comp_jpeg[hw_id]->hw_lock, flags);
[Severity: High]
This is a pre-existing issue, but does scheduling the timeout work before
acquiring hw_lock risk a use-after-free?
If the worker thread is preempted for more than the timeout duration just
after calling schedule_delayed_work(), the timeout work could execute,
reset the hardware, and return the buffers to userspace via
v4l2_m2m_buf_done().
Userspace might then free or reuse these buffers. When this worker thread
eventually resumes, it would blindly configure the hardware with the
invalidated buffer pointers and start the hardware operation, which could
lead to memory corruption. This appears to affect both mtk_jpegenc_worker()
and mtk_jpegdec_worker().
> @@ -1674,6 +1671,8 @@ static void mtk_jpegenc_worker(struct work_struct *work)
> &src_buf->vb2_buf);
> mtk_jpeg_set_enc_params(ctx, comp_jpeg[hw_id]->reg_base);
> mtk_jpeg_enc_start(comp_jpeg[hw_id]->reg_base);
> + v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
> + v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
[Severity: High]
Can this lead to list corruption if the hardware finishes very quickly?
Because v4l2_m2m_src_buf_remove() and v4l2_m2m_dst_buf_remove() are called
after mtk_jpeg_enc_start(), the hardware can raise an interrupt before the
buffers are removed from the ready queue.
Since the IRQ handler does not acquire hw_lock, it can run concurrently on
another CPU and transition the buffer to userspace via v4l2_m2m_buf_done().
If userspace quickly dequeues and requeues the buffer, list_add_tail() will
be invoked to insert it back into the ready queue.
Because this worker thread has not yet removed the original list node,
could this corrupt the doubly-linked lists? I notice this order is used in
mtk_jpegenc_worker(), but mtk_jpegdec_worker() correctly calls the remove
functions before starting the hardware.
> v4l2_m2m_job_finish(jpeg->m2m_dev, ctx->fh.m2m_ctx);
[Severity: High]
This is a pre-existing issue, but does calling v4l2_m2m_job_finish()
synchronously here open a window for a use-after-free of the context?
If userspace closes the file descriptor while an encode or decode job is
running, mtk_jpeg_release() invokes v4l2_m2m_ctx_release(), which tries
to wait for running jobs by checking the TRANS_RUNNING flag.
Since v4l2_m2m_job_finish() is called immediately after starting the
hardware, the flag is cleared before the hardware actually finishes. This
causes mtk_jpeg_release() to proceed without waiting and free the context.
When the hardware interrupt eventually fires, the IRQ handler dereferences
the freed context:
mtk_jpegenc_hw_irq_handler()
mtk_jpegenc_put_buf()
ctx = jpeg->hw_param.curr_ctx;
spin_lock_irqsave(&ctx->done_queue_lock, flags);
Can this lead to memory corruption when the lock is accessed on the freed
context?
[ ... ]
While reviewing this patch, I noticed a few other pre-existing issues in
related code.
[Severity: High]
This is a pre-existing issue, but is there a race condition between the
hardware IRQ handler and the job timeout worker?
In mtk_jpeg_enc_hw.c, the IRQ handler uses the asynchronous
cancel_delayed_work():
mtk_jpegenc_hw_irq_handler() {
...
cancel_delayed_work(&jpeg->job_timeout_work);
ctx = jpeg->hw_param.curr_ctx;
...
}
If the hardware interrupt fires at the exact moment the timeout worker
begins executing, cancel_delayed_work() returns false and does not wait.
Because neither the IRQ handler nor the timeout worker acquires hw_lock,
both will execute concurrently.
Both paths will read the same buffer pointers from hw_param and invoke
v4l2_m2m_buf_done(), which could result in a double completion of the V4L2
buffers and a double increment of the hw_rdy atomic counter.
[Severity: High]
This is a pre-existing issue, but can mtk_jpeg_enc_stop_streaming()
deadlock if buffers are queued but the M2M job is not started?
In mtk_jpeg_core.c:mtk_jpeg_enc_stop_streaming():
if (jpeg->variant->multi_core)
vb2_wait_for_all_buffers(q);
while ((vb = mtk_jpeg_buf_remove(ctx, q->type)))
v4l2_m2m_buf_done(vb, VB2_BUF_STATE_ERROR);
If userspace queues buffers on only one queue (e.g., OUTPUT but not
CAPTURE), the V4L2 mem2mem core places the buffers in the driver's ready
queue but does not schedule the job.
If userspace then calls STREAMOFF, the wait loop precedes the cleanup
loop. vb2_wait_for_all_buffers() will block waiting for the driver to
return all buffers, but the code that returns the buffers is located after
the wait call.
Could this cause the process calling STREAMOFF to block forever in
uninterruptible sleep? The same logic appears to be present in
mtk_jpeg_dec_stop_streaming() as well.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720133432.1042046-1-kyrie.wu@mediatek.com?part=8
^ permalink raw reply
* Re: [PATCH v3 phy-next 8/8] phy: lynx-10g: use RCW override procedure for dynamic protocol change
From: sashiko-bot @ 2026-07-20 14:13 UTC (permalink / raw)
To: Vladimir Oltean
Cc: robh, linux-phy, conor+dt, vkoul, devicetree, neil.armstrong,
olteanv
In-Reply-To: <20260720133642.136324-9-vladimir.oltean@nxp.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [High] An off-by-one error in the bounds check for `serdes_idx` within `fsl_guts_serdes_get_rcw_override` incorrectly rejects the final SerDes block on the SoC.
- [High] Uninitialized lanes on `ls2088a` SerDes1 have their XGMII clock selection bits blindly overwritten to GMII during RCW initialization.
--
--- Patch [8]: [PATCH v3 phy-next 8/8] phy: lynx-10g: use RCW override procedure for dynamic protocol change ---
commit 7e0651dd0ae8f0fcd028d4877a54ccdb1dcfef2d
Author: Vladimir Oltean <vladimir.oltean@nxp.com>
phy: lynx-10g: use RCW override procedure for dynamic protocol change
Up until this patch, the only protocol change supported was between
1000Base-X/SGMII and 2500Base-X. The others require an RCW override
procedure which was lacking.
Since now the guts driver provides the means of applying this procedure,
make use of it and remove any comment which mentioned the limitation.
> diff --git a/drivers/phy/freescale/phy-fsl-lynx-10g.c b/drivers/phy/freescale/phy-fsl-lynx-10g.c
> index 38def160ef1aa..5ece7889aed7b 100644
> --- a/drivers/phy/freescale/phy-fsl-lynx-10g.c
> +++ b/drivers/phy/freescale/phy-fsl-lynx-10g.c
[ ... ]
> @@ -1225,6 +1223,13 @@ static int lynx_10g_set_mode(struct phy *phy, enum phy_mode mode, int submode)
> if (powered_up)
> lynx_10g_lane_halt(phy);
>
> + if (lynx_10g_lane_mode_needs_rcw_override(lane, lane_mode)) {
> + err = fsl_guts_lane_set_mode(priv->info->index, lane->id,
> + lane_mode);
[Severity: High]
This isn't a bug introduced by this patch, but does the underlying RCW override
procedure contain an off-by-one error that rejects the final SerDes block?
When this calls into fsl_guts_lane_set_mode(), it eventually hits a bounds
check in fsl_guts_serdes_get_rcw_override():
drivers/soc/fsl/guts.c:fsl_guts_serdes_get_rcw_override() {
...
if (serdes_idx >= soc_data->num_serdes || serdes_idx <= 0)
return -ERANGE;
...
}
Since serdes_idx is 1-based, and this uses >= instead of >, won't this
completely fail to apply the dynamic protocol change for any interface on
the last SerDes block (e.g. index 2 on SoCs with 2 SerDes blocks)?
[Severity: High]
This is a pre-existing issue, but does initializing the SerDes RCW
inadvertently corrupt unmanaged lanes on LS2088A?
When fsl_guts_lane_set_mode() is called for the first time on an LS2088A SoC,
it triggers ls2088a_serdes_init_rcwcr() to build a new state for the RCW
utilizing soc.lanes_initialized:
drivers/soc/fsl/guts.c:ls2088a_serdes_init_rcwcr() {
...
for_each_set_bit(i, &soc.lanes_initialized[serdes_idx - 1], MAX_NUM_LANES)
if (lynx_lane_mode_uses_xgmii_mac(soc.lane_mode[serdes_idx - 1][i]))
reg |= LS2088A_RCWSR30_SRDS_CLK_SEL_XGMII_Ln_S1(i);
err = fsl_guts_rcw_rmw(29, reg,
LS2088A_RCWSR30_SRDS_CLK_EN_SEL_XGMII_S1 |
LS2088A_RCWSR30_SRDS_CLK_SEL_MSK);
...
}
Because the blanket mask LS2088A_RCWSR30_SRDS_CLK_SEL_MSK clears the bits
for all 8 lanes but only restores them for explicitly managed lanes, won't
unmanaged lanes (such as those used by DPDK or alternative firmware) have
their hardware protocol selection forced to 0 (GMII), potentially breaking
network connectivity?
> + if (err)
> + goto out;
> + }
> +
> err = lynx_10g_lane_disable_pcvt(lane, lane->mode);
> if (err)
> goto out;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720133642.136324-1-vladimir.oltean@nxp.com?part=8
^ permalink raw reply
* Re: [PATCH v2 2/2] phy: mediatek: Add support for PCI-Express Gen4 S-PHY
From: sashiko-bot @ 2026-07-20 14:13 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: neil.armstrong, olteanv, devicetree, vkoul, linux-phy, conor+dt,
robh
In-Reply-To: <20260720135344.84183-3-angelogioacchino.delregno@collabora.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Improper handling of missing or unsupported NVMEM calibration data causes spurious error logs and hard probe failures.
- [Medium] A valid calibration value of 0 is incorrectly treated as missing data, discarding all calibrations.
- [Low] The TX_IMPSEL registers are updated twice with identical values during initialization.
- [Low] Macros for AEQ_EGEQ_RATIO are defined but unused in favor of literal magic numbers.
--
--- Patch [2]: [PATCH v2 2/2] phy: mediatek: Add support for PCI-Express Gen4 S-PHY ---
commit d91c6c0718440c44adc7e6a83f5aeca706a6c3d5
Author: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Subject: phy: mediatek: Add support for PCI-Express Gen4 S-PHY
This patch adds support for the PCI-Express Gen4 S-PHY found in the latest
MediaTek SoCs, including MT8196 and MT8894.
> --- a/drivers/phy/mediatek/phy-mtk-pcie-sphy.c
> +++ b/drivers/phy/mediatek/phy-mtk-pcie-sphy.c
[ ... ]
> +#define PEXTP_DIG_LN_RX2_AEQ_EDGE_0 0x6004
> +# define RG_XTP_LN_RX_AEQ_EGEQ_RATIO_GEN3 GENMASK(21, 16)
> +# define RG_XTP_LN_RX_AEQ_EGEQ_RATIO_GEN4 GENMASK(29, 24)
> +# define AEQ_EGEQ_RATIO_GEN3_TO_22 0x16
> +# define AEQ_EGEQ_RATIO_GEN4_TO_22 0x16
[ ... ]
> + mtk_phy_update_field(sif_lane_base + PEXTP_DIG_LN_RX2_AEQ_EDGE_0,
> + RG_XTP_LN_RX_AEQ_EGEQ_RATIO_GEN3, 22);
> +
> + mtk_phy_update_field(sif_lane_base + PEXTP_DIG_LN_RX2_AEQ_EDGE_0,
> + RG_XTP_LN_RX_AEQ_EGEQ_RATIO_GEN4, 22);
[Severity: Low]
Is there a reason the literal 22 is used here instead of the
AEQ_EGEQ_RATIO_GEN3_TO_22 and AEQ_EGEQ_RATIO_GEN4_TO_22 macros defined
earlier?
[ ... ]
> +static void mtk_pcie_sphy_apply_calibration(struct mtk_pcie_sphy *pcie_sphy)
> +{
[ ... ]
> + mtk_phy_update_field(sif_lane_base + PEXTP_ANA_LN_TRX_A0,
> + RG_XTP_LN_TX_IMPSEL_PMOS, cal->tx_impsel.pmos);
> +
> + mtk_phy_update_field(sif_lane_base + PEXTP_ANA_LN_TRX_A0,
> + RG_XTP_LN_TX_IMPSEL_NMOS, cal->tx_impsel.nmos);
> + }
> +}
> +
[ ... ]
> +static int mtk_pcie_sphy_init(struct phy *phy)
> +{
[ ... ]
> + if (pcie_sphy->calibration.supported) {
> + mtk_pcie_sphy_apply_calibration(pcie_sphy);
> +
> + tx_impsel.pmos = pcie_sphy->calibration.tx_impsel.pmos;
> + tx_impsel.nmos = pcie_sphy->calibration.tx_impsel.nmos;
> + } else {
> + /* Set P=10, N=9 to prevent EMI if no calibration present */
> + tx_impsel.pmos = 10;
> + tx_impsel.nmos = 9;
> + }
> +
> + /* Select TX Impedance on N and P MOSFETs */
> + for (i = 0; i < pcie_sphy->num_lanes; i++) {
> + void __iomem *sif_lane_base = pcie_sphy->sif_base + PEXTP_REG_LANE(i);
> +
> + mtk_phy_update_field(sif_lane_base + PEXTP_ANA_LN_TRX_A0,
> + RG_XTP_LN_TX_IMPSEL_PMOS, tx_impsel.pmos);
> +
> + mtk_phy_update_field(sif_lane_base + PEXTP_ANA_LN_TRX_A0,
> + RG_XTP_LN_TX_IMPSEL_NMOS, tx_impsel.nmos);
> + }
[Severity: Low]
Are these register updates redundant?
When calibration is supported, mtk_pcie_sphy_apply_calibration() already
writes cal->tx_impsel.pmos and cal->tx_impsel.nmos to PEXTP_ANA_LN_TRX_A0.
Then this loop immediately overwrites the same registers with the exact same
values.
[ ... ]
> +static int mtk_pcie_sphy_get_one_cal_para(struct device *dev, const char *name, u8 max_val)
> +{
[ ... ]
> + ret = nvmem_cell_read_u8(dev, name, &tmp);
> + if (ret == 0)
> + buf = tmp;
> + else
> + ret = nvmem_cell_read_u16(dev, name, &buf);
> +
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Cannot get calibration data for %s\n", name);
[Severity: High]
Will this cause spurious error logs or fail the probe when calibration data is
missing or unsupported?
If the system does not have CONFIG_NVMEM enabled, nvmem_cell_read_u8() returns
-EOPNOTSUPP, which gets logged as an error here.
This error is then passed back up to mtk_pcie_sphy_get_calibration_data(),
where it is not caught. This will cause the entire driver probe to fail.
Similarly, if the cell is simply missing from the Device Tree, it returns
-ENOENT. This also triggers an error log via dev_err_probe(), even though
missing calibration data is explicitly documented as non-fatal and optional.
> +
> + if (buf == 0) {
> + dev_info(dev, "No calibration for %s. Using defaults\n", name);
> + return -ENOENT;
> + }
[Severity: Medium]
Is a value of 0 always indicative of missing calibration?
If a valid tuned calibration value is 0, this check will return -ENOENT and
cause mtk_pcie_sphy_get_calibration_data() to discard all calibrations entirely.
This also seems to prevent the quirk for cal-version == 0 from ever being
applied:
[ ... ]
> +static int mtk_pcie_sphy_get_calibration_data(struct mtk_pcie_sphy *pcie_sphy)
> +{
[ ... ]
> + ret = mtk_pcie_sphy_get_one_cal_para(dev, "cal-version", 15);
> + if (ret < 0)
> + goto end;
> + version = ret;
> +
> + /* Quirk for eFuse calibration table versions 0 to 4 */
> + if ((version <= MTK_PCIE_SPHY_CALIBRATION_LAST_QUIRK_VER) &&
> + cal->rx_leq_rl_ctle == 10) {
Because mtk_pcie_sphy_get_one_cal_para() returns -ENOENT when it reads a 0,
the version == 0 condition will never be reached.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260720135344.84183-1-angelogioacchino.delregno@collabora.com?part=2
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: iommu: arm,smmu: Document interconnects property
From: Bibek Kumar Patro @ 2026-07-20 14:11 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Dmitry Baryshkov, Will Deacon, Robin Murphy, Joerg Roedel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Rob Clark, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, Krzysztof Kozlowski
In-Reply-To: <ak5pC_meP8KRc3wJ@baldur>
On 7/8/2026 8:48 PM, Bjorn Andersson wrote:
> On Wed, Jul 08, 2026 at 08:22:00PM +0530, Bibek Kumar Patro wrote:
>>
>>
>> On 7/7/2026 10:12 PM, Dmitry Baryshkov wrote:
>>> On Tue, Jul 07, 2026 at 06:06:59PM +0530, Bibek Kumar Patro wrote:
>>>>
>>>>
>>>> On 7/6/2026 11:09 PM, Dmitry Baryshkov wrote:
>>>>> On Mon, Jul 06, 2026 at 10:26:34PM +0530, Bibek Kumar Patro wrote:
>>>>>> Some SoC implementations require a bandwidth vote on an interconnect
>>>>>> path before the SMMU register space is accessible. Add the optional
>>>>>
>>>>> Why is it limited only to those SoCs? Is it also applicable to other
>>>>> Qualcomm SoCs?
>>>>>
>>>>
>>>> I was hoping to keep this series focused on the core infrastructure
>>>> changes: the bindings, base ICC bandwidth-voting support, and DT
>>>> interconnect properties for the platforms currently supported on
>>>> Qualcomm Linux and have been validated so far.
>>>>
>>>> The additional targets have not been tested yet, so I'd prefer
>>>> to add their support in a separate follow-up series once validation
>>>> is complete, rather than growing this series further. WDYT?
>>>
>>> Then it should be a part of the commit message. All SoCs since SDM12345
>>> need to vote on the interconnect (and then, in the cover letter mention
>>> that you convert only a few of the SoCs). We possibly can help with
>>> testing on other platforms.
>>>
>>
>> Ack, sounds reasonable.
>> I'll add the first platform onwards which interconnect voting is required in
>> commit description.
>
> But to what degree is this related to a specific set of platforms? If we
> look ahead, aren't we expecting the list to grow to include all
> platforms in the end - resulting in a lot of noise and churn.
>
We have seen this issue consistently on SM8750 and later platforms,
along with at least one customer-reported instance on SM8550. As a
result, downstream Android implementations already vote for the required
interconnect bandwidth explicitly on these platforms.
On Qualcomm Linux targets, we have observed similar issues on Kodiak,
with a few occurrences on Talos as well.
My understanding is that the interconnects property remains optional,
but in practice it is needed for Adreno SMMU operation on these platforms.
> Can you give an example of a platform where there is no interconnect
> path to vote for here or where it would be harmful to do so?
>
I do not anticipate any functional issues or side effects from
explicitly voting for the interconnect on Qualcomm platforms where the
path exists.
>> And update the cover letter to clarify that this series adds
>> support for the Qualcomm Linux-supported targets available today, and
>> the list will be expanded in follow-up series as additional platforms
>> are enabled.
>>
>
> The binding should not reflect what has been implemented and verified in
> Linux, it defines the contract between DeviceTree and the OS.
>
Since the property is optional, would it be necessary to add in AllOf
the list of compatible for which the property hasn't been added yet, or
for the compatibles where it is added?
Thanks & regards,
Bibek
> Regards,
> Bjorn
>
>> Thanks & regards,
>> Bibek
>>
>>>>>> 'interconnects' property to the binding to allow platform DT nodes
>>>>>> to describe this path.
>>>>>>
>>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>>> Signed-off-by: Bibek Kumar Patro <bibek.patro@oss.qualcomm.com>
>>>>>> ---
>>>>>> .../devicetree/bindings/iommu/arm,smmu.yaml | 27 ++++++++++++++++++++++
>>>>>> 1 file changed, 27 insertions(+)
>>>>>>
>>>
>>
^ permalink raw reply
* [PATCH v2 9/9] arm64: dts: imx8ulp-9x9-evk: Rename model string to reflect die size
From: Peng Fan (OSS) @ 2026-07-20 14:12 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260720-imx8ulp-dts-v2-0-d05c67676f53@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Rename the board model from "NXP i.MX8ULP EVK9" to "NXP i.MX8ULP 9x9
EVK" to follow the i.MX naming convention where the die size (9x9 mm)
is used instead of an opaque board revision suffix.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
index 71c66c58edc4d..e6bc6e6555f57 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
@@ -8,7 +8,7 @@
#include "imx8ulp-evk.dts"
/ {
- model = "NXP i.MX8ULP EVK9";
+ model = "NXP i.MX8ULP 9x9 EVK";
compatible = "fsl,imx8ulp-9x9-evk", "fsl,imx8ulp";
gpio-keys {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 8/9] arm64: dts: imx8ulp-evk: Change the values of some PCRs of ENET
From: Peng Fan (OSS) @ 2026-07-20 14:12 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan,
Wei Fang
In-Reply-To: <20260720-imx8ulp-dts-v2-0-d05c67676f53@nxp.com>
From: Wei Fang <wei.fang@nxp.com>
Change to use standard drive strength and slow slew rate on
PTE14-17, 22, 23, otherwise the overshoot of ENET is too high.
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 9da54291c7534..22c1d542798d5 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -323,15 +323,15 @@ &mu {
&iomuxc1 {
pinctrl_enet: enetgrp {
fsl,pins = <
- MX8ULP_PAD_PTE15__ENET0_MDC 0x43
- MX8ULP_PAD_PTE14__ENET0_MDIO 0x43
- MX8ULP_PAD_PTE17__ENET0_RXER 0x43
+ MX8ULP_PAD_PTE15__ENET0_MDC 0x7
+ MX8ULP_PAD_PTE14__ENET0_MDIO 0x7
+ MX8ULP_PAD_PTE17__ENET0_RXER 0x7
MX8ULP_PAD_PTE18__ENET0_CRS_DV 0x43
MX8ULP_PAD_PTF1__ENET0_RXD0 0x43
MX8ULP_PAD_PTE20__ENET0_RXD1 0x43
- MX8ULP_PAD_PTE16__ENET0_TXEN 0x43
- MX8ULP_PAD_PTE23__ENET0_TXD0 0x43
- MX8ULP_PAD_PTE22__ENET0_TXD1 0x43
+ MX8ULP_PAD_PTE16__ENET0_TXEN 0x7
+ MX8ULP_PAD_PTE23__ENET0_TXD0 0x7
+ MX8ULP_PAD_PTE22__ENET0_TXD1 0x7
MX8ULP_PAD_PTE19__ENET0_REFCLK 0x43
MX8ULP_PAD_PTF10__ENET0_1588_CLKIN 0x43
>;
--
2.34.1
^ permalink raw reply related
* [PATCH v2 7/9] arm64: dts: imx8ulp-evk: Enable LPUART7
From: Peng Fan (OSS) @ 2026-07-20 14:12 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan,
Sherry Sun
In-Reply-To: <20260720-imx8ulp-dts-v2-0-d05c67676f53@nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
The i.MX 8ULP EVK proto1B revision routes LPUART7 TX/RX to the FT4232
PortD connector (J25/J26 pins 2-3). Enable the port by default so the
additional serial console is available out of the box.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 84c61656f3f2b..9da54291c7534 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -178,6 +178,13 @@ bluetooth {
};
};
+&lpuart7 {
+ /* FT4232 PortD: need to connect J25/J26 2-3 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart7>;
+ status = "okay";
+};
+
&lpi2c7 {
#address-cells = <1>;
#size-cells = <0>;
@@ -369,6 +376,13 @@ MX8ULP_PAD_PTE8__LPUART6_CTS_B 0x3
>;
};
+ pinctrl_lpuart7: lpuart7grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF22__LPUART7_TX 0x3
+ MX8ULP_PAD_PTF23__LPUART7_RX 0x3
+ >;
+ };
+
pinctrl_lpi2c7: lpi2c7grp {
fsl,pins = <
MX8ULP_PAD_PTE12__LPI2C7_SCL 0x20
--
2.34.1
^ permalink raw reply related
* [PATCH v2 6/9] arm64: dts: imx8ulp-evk: Enable LPUART6 for Bluetooth
From: Peng Fan (OSS) @ 2026-07-20 14:12 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan,
Sherry Sun
In-Reply-To: <20260720-imx8ulp-dts-v2-0-d05c67676f53@nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Enable lpuart6 with RTS/CTS flow control on the i.MX 8ULP EVK board
and add an NXP 88W8987 Bluetooth companion node to pair the UART
transport with the wireless chip.
i.MX8ULP 9X9 EVK use different lpuart6 pins which used for M.2 bluetooth,
also use the sai6 instead of sai5 for PCM interface on M.2, so need to
update the pin setting in dts.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts | 17 +++++++++++++++++
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 20 ++++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
index af8f0d6087f71..71c66c58edc4d 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
@@ -75,6 +75,23 @@ MX8ULP_PAD_PTE20__USB1_OC 0x10003
>;
};
+&pinctrl_lpuart6 {
+ fsl,pins = <
+ MX8ULP_PAD_PTF18__LPUART6_TX 0x3
+ MX8ULP_PAD_PTF19__LPUART6_RX 0x3
+ MX8ULP_PAD_PTF16__LPUART6_CTS_B 0x3
+ MX8ULP_PAD_PTF17__LPUART6_RTS_B 0x3
+ >;
+};
+
+&lpspi5 { /* conflict with lpuart6 PAD_PTF16-19 */
+ status = "disabled";
+};
+
+&sai5 {
+ status = "disabled";
+};
+
&sai6 {
pinctrl-names = "default", "sleep";
pinctrl-0 = <&pinctrl_sai6>;
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 6a92c5ca9a412..84c61656f3f2b 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -167,6 +167,17 @@ &lpuart5 {
status = "okay";
};
+&lpuart6 {
+ /* BT */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpuart6>;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
&lpi2c7 {
#address-cells = <1>;
#size-cells = <0>;
@@ -349,6 +360,15 @@ MX8ULP_PAD_PTF15__LPUART5_RX 0x3
>;
};
+ pinctrl_lpuart6: lpuart6grp {
+ fsl,pins = <
+ MX8ULP_PAD_PTE10__LPUART6_TX 0x3
+ MX8ULP_PAD_PTE11__LPUART6_RX 0x3
+ MX8ULP_PAD_PTE9__LPUART6_RTS_B 0x3
+ MX8ULP_PAD_PTE8__LPUART6_CTS_B 0x3
+ >;
+ };
+
pinctrl_lpi2c7: lpi2c7grp {
fsl,pins = <
MX8ULP_PAD_PTE12__LPI2C7_SCL 0x20
--
2.34.1
^ permalink raw reply related
* [PATCH v2 5/9] arm64: dts: imx8ulp-evk: Add gpio-keys node for power button
From: Peng Fan (OSS) @ 2026-07-20 14:12 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
Cc: devicetree, imx, linux-arm-kernel, linux-kernel, Peng Fan
In-Reply-To: <20260720-imx8ulp-dts-v2-0-d05c67676f53@nxp.com>
From: Peng Fan <peng.fan@nxp.com>
Add a gpio-keys node for the power-on button, report it as KEY_POWER to
user space.
Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts | 18 ++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8ulp-evk.dts | 19 +++++++++++++++++++
2 files changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
index 5497e3d78136f..af8f0d6087f71 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-9x9-evk.dts
@@ -10,6 +10,18 @@
/ {
model = "NXP i.MX8ULP EVK9";
compatible = "fsl,imx8ulp-9x9-evk", "fsl,imx8ulp";
+
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ button-power-on {
+ label = "PowerOn";
+ gpios = <&gpiof 11 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_POWER>;
+ };
+ };
};
&btcpu {
@@ -43,6 +55,12 @@ MX8ULP_PAD_PTF10__ENET0_1588_CLKIN 0x43
>;
};
+&pinctrl_gpio_keys {
+ fsl,pins = <
+ MX8ULP_PAD_PTF11__PTF11 0x3
+ >;
+};
+
&pinctrl_usb1 {
fsl,pins = <
MX8ULP_PAD_PTE16__USB0_ID 0x10003
diff --git a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
index 5dea66c1e7aa0..6a92c5ca9a412 100644
--- a/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8ulp-evk.dts
@@ -5,6 +5,7 @@
/dts-v1/;
+#include <dt-bindings/input/input.h>
#include "imx8ulp.dtsi"
/ {
@@ -20,6 +21,18 @@ chosen {
stdout-path = &lpuart5;
};
+ gpio-keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_keys>;
+
+ button-power-on {
+ label = "PowerOn";
+ gpios = <&gpiof 31 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_POWER>;
+ };
+ };
+
memory@80000000 {
device_type = "memory";
reg = <0x0 0x80000000 0 0x80000000>;
@@ -323,6 +336,12 @@ MX8ULP_PAD_PTD22__FLEXSPI2_A_DATA4 0x42
>;
};
+ pinctrl_gpio_keys: gpiokeysgrp {
+ fsl,pins = <
+ MX8ULP_PAD_PTF31__PTF31 0x3
+ >;
+ };
+
pinctrl_lpuart5: lpuart5grp {
fsl,pins = <
MX8ULP_PAD_PTF14__LPUART5_TX 0x3
--
2.34.1
^ 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