* Re: [PATCH 1/2] dt-bindings: iio: adc: Add Nuvoton MA35D1 EADC
From: David Lechner @ 2026-06-29 15:04 UTC (permalink / raw)
To: Chi-Wen Weng, jic23, robh, krzk+dt, conor+dt
Cc: nuno.sa, andy, linux-arm-kernel, linux-iio, devicetree,
linux-kernel, cwweng
In-Reply-To: <7e96cc1a-eb60-4eeb-937d-64e83bc35279@gmail.com>
On 6/29/26 2:11 AM, Chi-Wen Weng wrote:
>> Should there be a dmas property? Datasheet says it supports PDMA transfer.
>
> The hardware does support PDMA, but DMA support is intentionally not
> included in this initial upstream version. The initial driver will only
> support interrupt-driven direct raw reads, and the MA35D1 PDMA provider
> is not upstream yet.
>
> I would prefer to leave dmas/dma-names out of the initial binding and
> add them later together with DMA support. Please let me know if you
> would prefer optional DMA properties to be described now.
We always want the devicetree to be as complete as possible even
if the drier doesn't use all of the information.
So for trivial/well-known bindings like dmas, we should be able to
add it now.
>
>> I assume 8 is for the internal batter voltage channel? Often, we don't
>> include fixed internal channels like this in the devicetree since they
>> are always the same and don't depend on external wiring.
>
> Correct. Channels 0 to 7 are the external ADC input pins, while channel
> 8 is the internal VBAT input. I will limit the DT child channel nodes to
> external channels 0 to 7.
>
> If VBAT support is added later, it can be exposed by the driver as a
> fixed internal channel rather than being described by devicetree.
>
>> adc.yaml already specifies minItems and maxItems, so we don't need to
>> repeat it.
>
> Since I plan to simplify v2 and drop differential channel support from
> the initial submission, I will remove diff-channels from the initial
> binding.
Same reasoning as above, we want the binding to be as complete as
possible, so we should not omit diff-channels since we know what
the bindings should look like already.
>
> Differential input support can be added later once the fixed hardware
> pair constraints and signed output handling are implemented in the
> driver.
>
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-29 15:02 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Joey Lu, Conor Dooley, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <80ae28925a67b7bee3b8873db3c113111437e717.camel@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 3496 bytes --]
On Mon, Jun 29, 2026 at 01:31:46PM +0800, Icenowy Zheng wrote:
> > > > > > > > > +
> > > > > > > > > + resets:
> > > > > > > > > + minItems: 1
> > > > > > > > > + maxItems: 1
> > > > > > > > > +
> > > > > > > > > + reset-names:
> > > > > > > > > + items:
> > > > > > > > > + - const: core
> > > > > > > > This is just maxItems: 1.
> > > > > > > Well the implicit rules of DT binding schemas are quite
> > > > > > > weird...
> > > > > > I don't think it is that strange, as the binding has
> > > > > > reset-names:
> > > > > > items:
> > > > > > - const: core
> > > > > > - const: axi
> > > > > > - const: ahb
> > > > > Ah does the list constraint the order of items? If it
> > > > > constrains
> > > > > the
> > > > It does, yes.
> > > > Alternatively, using an enum permits free ordering.
> > > Ah in this case this should be converted to an enum, I think.
> > >
> > > Should I send a patch for converting it?
> > >
> > > Thanks,
> > > Icenowy
> > Thank you all for the detailed review and discussion, it really
> > helped
> > clarify the right approach.
> >
> > Since I will supply all four clocks with the same phandle for
> > core/axi/ahb,
> > and only one reset "core" for MA35D1, the ordering constraint in the
> > `items` list is not a problem, "core" is already the first entry.
> > There
> > is no need to convert to an enum.
> >
> > Regarding the clock situation for the MA35D1: I agree with supplying
> > all
> > four clocks (core, axi, ahb, pix0) in the devicetree, even though the
> > MA35D1 clock controller gates core/axi/ahb with a single bit. The DT
> > will
> > use the same clock phandle for core, axi, and ahb:
> >
> > clocks = <&clk X>, <&clk X>, <&clk X>, <&pix_clk Y>;
> > clock-names = "core", "axi", "ahb", "pix0";
> >
> > This correctly models the hardware topology. Since all three names
>
> No, this doesn't correctly model the hardware topology -- this will
> lead to clk_get_rate() return the rate of DC core clock when checking
> the AXI clock rate, which is problematic because both clocks are
> limiting the performance of the DC.
>
> > resolve
> > to the same underlying clock node, the CCF's standard enable
> > refcounting
> > handles the shared gate correctly without any custom implementation
> > needed.
> > I will also revert the change in patch 4/7 that made axi and ahb
> > clocks
> > optional, since they will now always be provided in the devicetree.
> >
> > Regarding moving `resets` and `reset-names` to the top-level
> > `required:`,
> > I will wait for Icenowy's patch to land before sending v6 to avoid
> > duplicating the work.
>
> The patch is sent.
>
> >
> > In v6 I will update patch 1/7 with:
> > - Update the subject to "dt-bindings: display: verisilicon,dc: add
> > support for nuvoton,ma35d1-dcu"
> > - Lower `clocks`/`clock-names` `minItems` to 4 at the top level
> > - Remove the `thead,th1520-dc8200` conditional block entirely
>
> I think this conditional block will still be needed, because it will
> need to constrain the minItems to ensure all clocks / resets are
> populated.
Correct. When the outer constraints are relaxed to deal with the new
device the conditional block for the th1520 becomes required. Or having
an else, but if all devices are likely to be different in terms of
configuration specific conditional blocks is better.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] iommu/mediatek-v1: Fix off-by-one in MT2701_LARB_NR_MAX
From: Akari Tsuyukusa @ 2026-06-29 14:59 UTC (permalink / raw)
To: Yong Wu, Joerg Roedel (AMD), Will Deacon, Robin Murphy,
Matthias Brugger, AngeloGioacchino Del Regno, Miles Chen,
Joerg Roedel
Cc: Akari Tsuyukusa, open list:MEDIATEK IOMMU DRIVER,
moderated list:MEDIATEK IOMMU DRIVER,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
The mt2701_m4u_in_larb[] array contains 4 (for LARB0 to LARB3)
elements, meaning mt2701_m4u_to_larb() can legitimately return 3.
The current check `if (larbid >= MT2701_LARB_NR_MAX)` incorrectly
rejects valid LARB3 with -EINVAL.
Fix this off-by-one error by updating MT2701_LARB_NR_MAX to 4.
Note that this does not cause immediate issues with the current
mt2701.dtsi and mt7623n.dtsi because it only defines 3 LARBs:
mediatek,larbs = <&larb0 &larb1 &larb2>;
Thus, larbid never reaches 3 in the existing upstream device tree.
Fixes: de78657e16f4 ("iommu/mediatek: Fix NULL pointer dereference when printing dev_name")
Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
drivers/iommu/mtk_iommu_v1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/mtk_iommu_v1.c b/drivers/iommu/mtk_iommu_v1.c
index ac97dd2868d4..e907c9953142 100644
--- a/drivers/iommu/mtk_iommu_v1.c
+++ b/drivers/iommu/mtk_iommu_v1.c
@@ -88,7 +88,7 @@ struct dma_iommu_mapping {
/* MTK generation one iommu HW only support 4K size mapping */
#define MT2701_IOMMU_PAGE_SHIFT 12
#define MT2701_IOMMU_PAGE_SIZE (1UL << MT2701_IOMMU_PAGE_SHIFT)
-#define MT2701_LARB_NR_MAX 3
+#define MT2701_LARB_NR_MAX 4
/*
* MTK m4u support 4GB iova address space, and only support 4K page
--
2.54.0
^ permalink raw reply related
* Re: [PATCH] mtd: nand: mtk-ecc: stop on ECC idle timeouts
From: Miquel Raynal @ 2026-06-29 14:58 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Matthias Brugger,
AngeloGioacchino Del Regno, Boris Brezillon, Jorge Ramirez-Ortiz,
Pengpeng Hou
Cc: linux-mtd, linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260623135729.52304-1-pengpeng@iscas.ac.cn>
On Tue, 23 Jun 2026 21:57:29 +0800, Pengpeng Hou wrote:
> mtk_ecc_wait_idle() logs when the encoder or decoder does not become
> idle, but returns void. Callers can therefore configure a non-idle ECC
> engine or read parity bytes after an unconfirmed encoder idle state.
>
> Return the idle poll result and propagate it from the enable and encode
> paths that require the engine to be idle before continuing.
>
> [...]
Applied to mtd/fixes, thanks!
[1/1] mtd: nand: mtk-ecc: stop on ECC idle timeouts
commit: 16f7ec8d5dc100eafd2c8e06cd30340a30b104a1
Patche(s) should be available on mtd/linux.git and will be
part of the next PR (provided that no robot complains by then).
Kind regards,
Miquèl
^ permalink raw reply
* Re: [PATCH 2/5] media: nxp: imx8-isi: Fix per-stream reference counting for multiplexed streams
From: Frank Li @ 2026-06-29 14:55 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Christian Hemp,
Stefan Riedmueller, Jacopo Mondi, Dong Aisheng, Guoniu Zhou,
linux-media, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260629-isi-v1-2-deebfdb1b07b@oss.nxp.com>
On Mon, Jun 29, 2026 at 03:44:56PM +0800, Guoniu Zhou wrote:
subject: use per-stream state to fix ...
> The ISI crossbar fails to properly enable multiple streams from different
> virtual channels on the same input pad. Only the first stream gets enabled
> in hardware, subsequent streams are silently ignored.
>
> The driver uses a single enable_count per input to track the input state.
> When enable_count is non-zero, the code assumes the input is already active
> and skips calling v4l2_subdev_enable_streams() for additional streams:
>
> Call 1: enable_streams(stream 0)
> -> enable_count == 0, enable gasket and stream 0 in hardware
> -> enable_count = 1
>
> Call 2: enable_streams(stream 1)
> -> enable_count == 1, skip hardware enable (BUG!)
> -> enable_count = 2
> -> stream 1 never gets enabled
>
> Similarly on disable, when enable_count reaches zero, ALL streams are
> disabled regardless of which streams are actually still active.
>
> Fix this by tracking per-stream state using:
> - enabled_streams (u64 bitmask): tracks which streams are currently enabled
> - enabled_count[] (array): per-stream reference counter to support the same
> stream being enabled/disabled multiple times
>
> Now each stream is independently enabled/disabled in hardware based on the
> enabled_streams bitmask, while enabled_count[] provides reference counting
> for scenarios where the same stream is enabled multiple times, such as
> duplicate cases in the ISI stream.
>
> Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> .../media/platform/nxp/imx8-isi/imx8-isi-core.h | 4 +-
> .../platform/nxp/imx8-isi/imx8-isi-crossbar.c | 121 +++++++++++++++++----
> 2 files changed, 104 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> index 7547a6559d4c..bb2cfba27e20 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-core.h
> @@ -185,7 +185,9 @@ struct mxc_isi_dma_buffer {
> };
>
> struct mxc_isi_input {
> - unsigned int enable_count;
> + u64 enabled_streams;
> + /* Counter per stream */
> + unsigned int *enabled_count;
> };
>
> struct mxc_isi_crossbar {
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> index 29f14d30dbbb..a4a063c60c76 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> @@ -345,6 +345,8 @@ static int mxc_isi_crossbar_enable_streams(struct v4l2_subdev *sd,
> struct mxc_isi_crossbar *xbar = to_isi_crossbar(sd);
> struct v4l2_subdev *remote_sd;
> struct mxc_isi_input *input;
> + u64 streams_to_enable;
> + unsigned long stream;
> u64 sink_streams;
> u32 sink_pad;
> u32 remote_pad;
> @@ -358,30 +360,47 @@ static int mxc_isi_crossbar_enable_streams(struct v4l2_subdev *sd,
>
> input = &xbar->inputs[sink_pad];
>
> - /*
> - * TODO: Track per-stream enable counts to support multiplexed
> - * streams.
> - */
> - if (!input->enable_count) {
> + if (!input->enabled_streams) {
> ret = mxc_isi_crossbar_gasket_enable(xbar, state, remote_sd,
> remote_pad, sink_pad);
> if (ret)
> return ret;
> + }
> +
> + /*
> + * Track per-stream enable counts to support multiplexed streams.
> + * Only enable streams that are not already enabled.
> + */
> + streams_to_enable = sink_streams & ~input->enabled_streams;
>
> + if (streams_to_enable) {
> ret = v4l2_subdev_enable_streams(remote_sd, remote_pad,
> - sink_streams);
> + streams_to_enable);
> if (ret) {
> dev_err(xbar->isi->dev,
> "failed to enable streams 0x%llx on '%s':%u: %d\n",
> - sink_streams, remote_sd->name, remote_pad, ret);
> - mxc_isi_crossbar_gasket_disable(xbar, sink_pad);
> - return ret;
> + streams_to_enable, remote_sd->name, remote_pad, ret);
> + goto err_gasket_disable;
> }
> +
> + input->enabled_streams |= streams_to_enable;
> }
>
> - input->enable_count++;
> + /* Increment reference count for all requested streams */
> + for (stream = 0; stream < xbar->num_sources; stream++) {
> + if (!(sink_streams & BIT(stream)))
> + continue;
> +
> + input->enabled_count[stream]++;
> + }
>
> return 0;
> +
> +err_gasket_disable:
> + if (!input->enabled_streams)
> + mxc_isi_crossbar_gasket_disable(xbar, sink_pad);
> +
> + return ret;
> }
>
> static int mxc_isi_crossbar_disable_streams(struct v4l2_subdev *sd,
> @@ -391,6 +410,8 @@ static int mxc_isi_crossbar_disable_streams(struct v4l2_subdev *sd,
> struct mxc_isi_crossbar *xbar = to_isi_crossbar(sd);
> struct v4l2_subdev *remote_sd;
> struct mxc_isi_input *input;
> + u64 streams_to_disable = 0;
> + unsigned long stream;
> u64 sink_streams;
> u32 sink_pad;
> u32 remote_pad;
> @@ -404,19 +425,36 @@ static int mxc_isi_crossbar_disable_streams(struct v4l2_subdev *sd,
>
> input = &xbar->inputs[sink_pad];
>
> - input->enable_count--;
> + /*
> + * Decrease the enable count for each stream. Only disable streams
> + * whose count reaches zero.
> + */
> + for (stream = 0; stream < xbar->num_sources; stream++) {
> + if (!(sink_streams & BIT(stream)))
> + continue;
>
> - if (!input->enable_count) {
> - ret = v4l2_subdev_disable_streams(remote_sd, remote_pad,
> - sink_streams);
> - if (ret)
> - dev_err(xbar->isi->dev,
> - "failed to disable streams 0x%llx on '%s':%u: %d\n",
> - sink_streams, remote_sd->name, remote_pad, ret);
> + if (!(input->enabled_streams & BIT(stream)))
> + continue;
>
> - mxc_isi_crossbar_gasket_disable(xbar, sink_pad);
> + if (--input->enabled_count[stream] == 0)
> + streams_to_disable |= BIT(stream);
> }
>
> + if (!streams_to_disable)
> + return 0;
> +
> + ret = v4l2_subdev_disable_streams(remote_sd, remote_pad,
> + streams_to_disable);
> + if (ret)
> + dev_err(xbar->isi->dev,
> + "failed to disable streams 0x%llx on '%s':%u: %d\n",
> + streams_to_disable, remote_sd->name, remote_pad, ret);
> +
> + input->enabled_streams &= ~streams_to_disable;
> +
> + if (!input->enabled_streams)
> + mxc_isi_crossbar_gasket_disable(xbar, sink_pad);
> +
> return ret;
> }
>
> @@ -447,6 +485,42 @@ static const struct media_entity_operations mxc_isi_cross_entity_ops = {
> * Init & cleanup
> */
>
> +static int mxc_isi_stream_counters_alloc(struct mxc_isi_crossbar *xbar)
> +{
> + unsigned int i;
> + int ret;
> +
> + for (i = 0; i < xbar->num_sinks; ++i) {
> + struct mxc_isi_input *input = &xbar->inputs[i];
> +
> + input->enabled_count = kcalloc(xbar->num_sources,
> + sizeof(*input->enabled_count),
> + GFP_KERNEL);
kzalloc_objs();
Frank
> + if (!input->enabled_count) {
> + dev_err(xbar->isi->dev,
> + "failed to alloc memory for ISI input(%d)\n", i);
> + ret = -ENOMEM;
> + goto err_free;
> + }
> + }
> +
> + return 0;
> +
> +err_free:
> + while (i--)
> + kfree(xbar->inputs[i].enabled_count);
> +
> + return ret;
> +}
> +
> +static void mxc_isi_stream_counters_free(struct mxc_isi_crossbar *xbar)
> +{
> + unsigned int i;
> +
> + for (i = 0; i < xbar->num_sinks; ++i)
> + kfree(xbar->inputs[i].enabled_count);
> +}
> +
> int mxc_isi_crossbar_init(struct mxc_isi_dev *isi)
> {
> struct mxc_isi_crossbar *xbar = &isi->crossbar;
> @@ -484,6 +558,10 @@ int mxc_isi_crossbar_init(struct mxc_isi_dev *isi)
> goto err_free;
> }
>
> + ret = mxc_isi_stream_counters_alloc(xbar);
> + if (ret)
> + goto err_free;
> +
> for (i = 0; i < xbar->num_sinks; ++i)
> xbar->pads[i].flags = MEDIA_PAD_FL_SINK
> | MEDIA_PAD_FL_MUST_CONNECT;
> @@ -492,7 +570,7 @@ int mxc_isi_crossbar_init(struct mxc_isi_dev *isi)
>
> ret = media_entity_pads_init(&sd->entity, num_pads, xbar->pads);
> if (ret)
> - goto err_free;
> + goto err_free_cnt;
>
> ret = v4l2_subdev_init_finalize(sd);
> if (ret < 0)
> @@ -502,6 +580,8 @@ int mxc_isi_crossbar_init(struct mxc_isi_dev *isi)
>
> err_entity:
> media_entity_cleanup(&sd->entity);
> +err_free_cnt:
> + mxc_isi_stream_counters_free(xbar);
> err_free:
> kfree(xbar->pads);
> kfree(xbar->inputs);
> @@ -512,6 +592,7 @@ int mxc_isi_crossbar_init(struct mxc_isi_dev *isi)
> void mxc_isi_crossbar_cleanup(struct mxc_isi_crossbar *xbar)
> {
> v4l2_subdev_cleanup(&xbar->sd);
> + mxc_isi_stream_counters_free(xbar);
> media_entity_cleanup(&xbar->sd.entity);
> kfree(xbar->pads);
> kfree(xbar->inputs);
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v3 2/2] iio: adc: add Axiado SARADC driver
From: David Lechner @ 2026-06-29 14:54 UTC (permalink / raw)
To: Petar Stepanovic, Akhila Kavi, Prasad Bolisetty, Jonathan Cameron,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Harshit Shah
Cc: linux-iio, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <b06005e0-b7bc-4967-ac7b-cb170219f131@axiado.com>
On 6/28/26 9:33 PM, Petar Stepanovic wrote:
>
> On 6/28/2026 1:07 AM, David Lechner wrote:
...
>>> +};
>>> +
>>> +static void axiado_saradc_disable(void *data)
>>> +{
>>> + struct axiado_saradc *info = data;
>>> +
>>> + writel(AX_SARADC_GLOBAL_CTRL_PD, info->regs + AX_SARADC_GLOBAL_CTRL_REG);
>> People usual make read and write wrappers or use regmap to avoid having
>> to write `info->regs + AX_SARADC_GLOBAL_CTRL_REG` so many times.
>
> My understanding is that simple read/write wrappers are not always
> preferred unless they provide additional value. Would switching the
> driver to regmap be acceptable here to avoid repeating the base address
> calculation?
>
Yes, regmap is always nice because it brings a lot of extra features
for free.
^ permalink raw reply
* Re: [PATCH net-next v11 1/7] dt-bindings: phy: document the serdes PHY on sa8255p
From: Geert Uytterhoeven @ 2026-06-29 14:51 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Vinod Koul, Giuseppe Cavallaro, Chen-Yu Tsai, Jernej Skrabec,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Shawn Guo,
Fabio Estevam, Jan Petrous, s32, Mohd Ayaan Anwar, Romain Gantois,
Magnus Damm, Maxime Ripard, Christophe Roullier, Radu Rendec,
linux-arm-msm, devicetree, linux-kernel, netdev, linux-stm32,
linux-arm-kernel, Drew Fustini, linux-sunxi, linux-amlogic,
linux-mips, imx, linux-renesas-soc, linux-rockchip, sophgo,
linux-riscv, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <CAMRc=Me3jaZXiXa1sFXr=8Do4sCd+XN1pKTcWC8-0j78SjCkKA@mail.gmail.com>
Hi Bartosz,
On Mon, 29 Jun 2026 at 16:07, Bartosz Golaszewski <brgl@kernel.org> wrote:
> On Mon, 29 Jun 2026 15:51:31 +0200, Geert Uytterhoeven
> <geert@linux-m68k.org> said:
> > On Mon, 29 Jun 2026 at 13:29, Bartosz Golaszewski
> > <bartosz.golaszewski@oss.qualcomm.com> wrote:
> >> Describe the SGMII/SerDes PHY present on the Qualcomm sa8255p platforms.
> >> This is essentially the same hardware as sa8775p rev3 but the PHY is
> >> managed by firmware over SCMI.
> >
> > So why can't it be reuse the DT bindings, and be compatible with
> > qcom,sa8775p-dwmac-sgmii-phy?
> >
> >> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> >
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-dwmac-sgmii-phy.yaml
> >
> >> + power-domains:
> >> + maxItems: 1
> >> +
> >> + power-domain-names:
> >> + items:
> >> + - const: serdes
> >
> >> +examples:
> >> + - |
> >> + phy@8901000 {
> >> + compatible = "qcom,sa8255p-dwmac-sgmii-phy";
> >> + reg = <0x08901000 0xe10>;
> >> + #phy-cells = <0>;
> >> + power-domains = <&scmi7_dvfs 0>;
> >> + power-domain-names = "serdes";
> >
> > Ah, this uses power-domains, while the existing bindings for
> > qcom,sa8775p-dwmac-sgmii-phy use a clock.
> > I guess the clock is the correct hardware description?
> >
> > Adding to my list of examples for backing a hardware-to-SCMI remapping
> > driver...
> >
>
> Russell King asked me to put the PHY logic for SCMI pm domains into the PHY
> driver instead of the MAC driver where it was previously. Instead of cramming
> both HLOS and firmware handling into the same driver, I figured it makes more
> sense to have a dedicated, cleaner driver as the two share very little code (if
> any).
I think you are mixing up DT bindings and driver implementation?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH 5/5] drm/msm/dp: mark the SST connector disconnected when MST is enabled
From: Yongxing Mou @ 2026-06-29 14:48 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Tomi Valkeinen, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, linux-kernel, linux-amlogic, linux-arm-kernel,
linux-arm-msm, freedreno, Yongxing Mou
In-Reply-To: <20260629-msm-dp-msttypec-v1-0-646a10256233@oss.qualcomm.com>
When MST becomes active, the initial HPD plug notification updates the
SST connector state to connected.
However, the subsequent SST connector detect path reports disconnected
while MST is enabled. This connected -> disconnected transition is then
observed by the polling logic and may result in an unnecessary hotplug
event.
Set the SST connector state to disconnected immediately after MST is
initialized so that the detect path does not introduce a transient
state change.
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/gpu/drm/msm/dp/dp_display.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 4ee391cc7165..f8ca60d6d714 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -352,8 +352,10 @@ static int msm_dp_display_process_hpd_high(struct msm_dp_display_private *dp)
if (dp->max_stream > 1 && drm_dp_read_mst_cap(dp->aux, dp->panel->dpcd))
msm_dp_display_mst_init(dp);
- if (dp->msm_dp_display.mst_active)
+ if (dp->msm_dp_display.mst_active) {
+ connector->status = connector_status_disconnected;
msm_dp_mst_display_set_mgr_state(&dp->msm_dp_display, true);
+ }
msm_dp_link_reset_phy_params_vx_px(dp->link);
--
2.43.0
^ permalink raw reply related
* [PATCH 4/5] drm/msm/dp: report IRQ_HPD as an IRQ-only notification
From: Yongxing Mou @ 2026-06-29 14:48 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Tomi Valkeinen, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, linux-kernel, linux-amlogic, linux-arm-kernel,
linux-arm-msm, freedreno, Yongxing Mou
In-Reply-To: <20260629-msm-dp-msttypec-v1-0-646a10256233@oss.qualcomm.com>
MST reuses the SST connector bridge to propagate HPD IRQ events through
the bridge chain.
For IRQ_HPD notifications there is no connector state transition to
report. Use connector_status_unknown together with
DRM_CONNECTOR_DP_IRQ_HPD so that the bridge connector framework treats
them as IRQ-only notifications and forwards them without modifying
connector state.
The DP driver handles IRQ_HPD events based on
DRM_CONNECTOR_DP_IRQ_HPD rather than connector status transitions.
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/gpu/drm/msm/dp/dp_display.c | 22 +++++++++-------------
drivers/soc/qcom/pmic_glink_altmode.c | 14 +++++++++-----
2 files changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index bc93b566fbca..4ee391cc7165 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1119,14 +1119,10 @@ static irqreturn_t msm_dp_display_irq_thread(int irq, void *dev_id)
drm_bridge_hpd_notify(dp->msm_dp_display.bridge,
connector_status_connected);
- /* Send HPD as connected and distinguish it in the notifier */
- if (hpd_isr_status & DP_DP_IRQ_HPD_INT_MASK) {
- if (dp->msm_dp_display.mst_active)
- msm_dp_irq_hpd_handle(dp);
- else
- drm_bridge_hpd_notify(dp->msm_dp_display.bridge,
- connector_status_connected);
- }
+ if (hpd_isr_status & DP_DP_IRQ_HPD_INT_MASK)
+ drm_bridge_hpd_notify_extra(dp->msm_dp_display.bridge,
+ connector_status_unknown,
+ DRM_CONNECTOR_DP_IRQ_HPD);
ret = IRQ_HANDLED;
@@ -1781,11 +1777,11 @@ void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
drm_dbg_dp(dp->drm_dev, "type=%d link hpd_link_status=0x%x, status=%d\n",
msm_dp_display->connector_type, hpd_link_status, status);
- if (status == connector_status_connected) {
- if (hpd_link_status == ISR_IRQ_HPD_PULSE_COUNT ||
- extra_status == DRM_CONNECTOR_DP_IRQ_HPD) {
- msm_dp_irq_hpd_handle(dp);
- } else if (hpd_link_status == ISR_HPD_REPLUG_COUNT) {
+ if (extra_status == DRM_CONNECTOR_DP_IRQ_HPD ||
+ hpd_link_status == ISR_IRQ_HPD_PULSE_COUNT) {
+ msm_dp_irq_hpd_handle(dp);
+ } else if (status == connector_status_connected) {
+ if (hpd_link_status == ISR_HPD_REPLUG_COUNT) {
msm_dp_hpd_unplug_handle(dp);
msm_dp_hpd_plug_handle(dp);
} else {
diff --git a/drivers/soc/qcom/pmic_glink_altmode.c b/drivers/soc/qcom/pmic_glink_altmode.c
index 946eb20b8f83..28ab8cbb5ef9 100644
--- a/drivers/soc/qcom/pmic_glink_altmode.c
+++ b/drivers/soc/qcom/pmic_glink_altmode.c
@@ -373,11 +373,15 @@ static void pmic_glink_altmode_worker(struct work_struct *work)
else
conn_status = connector_status_disconnected;
- drm_aux_hpd_bridge_notify_extra(&alt_port->bridge->dev,
- conn_status,
- alt_port->hpd_irq ?
- DRM_CONNECTOR_DP_IRQ_HPD :
- DRM_CONNECTOR_NO_EXTRA_STATUS);
+ if (alt_port->hpd_irq) {
+ drm_aux_hpd_bridge_notify_extra(&alt_port->bridge->dev,
+ connector_status_unknown,
+ DRM_CONNECTOR_DP_IRQ_HPD);
+ } else {
+ drm_aux_hpd_bridge_notify_extra(&alt_port->bridge->dev,
+ conn_status,
+ DRM_CONNECTOR_NO_EXTRA_STATUS);
+ }
} else if (alt_port->mux_ctrl == MUX_CTRL_STATE_TUNNELING) {
if (alt_port->svid == USB_TYPEC_TBT_SID)
pmic_glink_altmode_enable_tbt(altmode, alt_port);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v15 07/11] arm64: syscall: Introduce syscall_exit_to_user_mode_work()
From: Ada Couprie Diaz @ 2026-06-29 14:48 UTC (permalink / raw)
To: Jinjie Ruan, mark.rutland
Cc: peterz, catalin.marinas, oleg, song, will, kees, thuth,
ryan.roberts, anshuman.khandual, kevin.brodsky, pengcan, broonie,
luto, ldv, linux-arm-kernel, wad, yeoreum.yun, linux-kernel,
james.morse, tglx, liqiang01, linusw
In-Reply-To: <83aed271-5f28-4f30-a800-b94192cb06a6@huawei.com>
On 25/06/2026 10:18, Jinjie Ruan wrote:
> On 6/24/2026 10:37 PM, Ada Couprie Diaz wrote:
>> On 11/05/2026 10:20, Jinjie Ruan wrote:
>>> Refactor the system call exit path to align with the generic entry
>>> framework. This consolidates thread flag checking, rseq handling, and
>>> syscall tracing into a structure that mirrors the generic
>>> syscall_exit_to_user_mode_work() implementation.
>>>
>>> [Rationale]
>>> The generic entry code employs a hierarchical approach for
>>> syscall exit work:
>>>
>>> 1. syscall_exit_to_user_mode_work(): The entry point that handles
>>> rseq and checks if further exit work (tracing/audit) is required.
>>>
>>> 2. syscall_exit_work(): Performs the actual tracing, auditing, and
>>> ptrace reporting.
>>>
>>> [Changes]
>>> - Rename and Encapsulate: Rename syscall_trace_exit() to
>>> syscall_exit_work() and make it static, as it is now an internal
>>> helper for the exit path.
>>>
>>> - New Entry Point: Implement syscall_exit_to_user_mode_work() to
>>> replace the manual flag-reading logic in el0_svc_common(). This
>>> function now encapsulates the rseq_syscall() call and the
>>> conditional execution of syscall_exit_work().
>>>
>>> - Simplify el0_svc_common(): Remove the complex conditional checks
>>> for tracing and CONFIG_DEBUG_RSEQ at the end of the syscall path,
>>> delegating this responsibility to the new helper.
>> It is indeed simpler, however to me there are two changes to the behaviour,
>> which are not called out (apologies if I missed some prior discussion
>> when I looked for some) :
>> 1. As pointed by the removed comment, in mainline we *always* trace on exit
>> if we traced on entry. This is why there are two `has_syscall_work()`
>> checks
>> on exit, with a re-read of the flags after syscall execution in between.
>> This change only checks once on exit after updating the flags, so if
>> there was work on entry but the flags got cleared, it *won't* trace
>> on exit.
>> Is this desired ? Can this change of behaviour have an impact ?
> Hi, Ada,
>
> After rework, `syscall_exit_to_user_mode_work()` will be executed
> unconditionally, regardless of whether the conditions below evaluate to
> true or false. [...]
Hi Jinjie,
Indeed, my worry was about the actual work in
`syscall_exit_to_user_mode_work()`
being gated by a different truth table, but it makes sense now, I will
detail below.
> [...] You can see how this is handled in the finer-grained
> refactoring split which will be shown in v16.
I have seen that you just posted v16, thanks for splitting things up a
bit more !
>
> if (!has_syscall_work(flags) && !IS_ENABLED(CONFIG_DEBUG_RSEQ))
>
>>> - Helper Migration: Move has_syscall_work() to asm/syscall.h
>>> to allow its reuse across ptrace.c and syscall.c.
>>>
>>> - Clean up RSEQ: Remove the explicit IS_ENABLED(CONFIG_DEBUG_RSEQ)
>>> check in the caller, as rseq_syscall() is already a no-op when the
>>> config is disabled.
>> 2. `rseq_syscall()` is indeed a no-op, but removing the explicit check here
>> does change the behaviour : in mainline we *always* trace on exit if
>> `CONFIG_DEBUG_RSEQ` is enabled, bypassing the `has_syscall_work()`
>> check.
>> This change does not bypass the `has_syscall_work()` check if
>> `CONFIG_DEBUG_RSEQ` is enabled, so there might be a change of behaviour.
>> Same questions as above : is this change desired ? Can it have an
>> impact ?
> This should not introduce any functional changes.
>
> Except for "audit", the internal code execution of
> `syscall_trace_exit()` is gated by the "_TIF_SYSCALL_TRACEPOINT,
> _TIF_SYSCALL_TRACE, or _TIF_SINGLESTEP" TIF flags.
>
> And gating audit_syscall_exit() behind `_TIF_SYSCALL_AUDIT` introduces
> no functional changes.
>
> The `SYSCALL_AUDIT` flag and its context are
> statically allocated via audit_alloc() at fork and only freed via
> audit_free() at do_exit(). Since the flag remains persistent and static
> throughout syscall execution, checking the `_TIF_SYSCALL_AUDIT` flag is
> completely equivalent to evaluating audit_context() in
> audit_syscall_exit().
Thank you for the additional details : I did miss that
`audit_syscall_exit()`
did its own check internally for `SYSCALL_WORK_SYSCALL_AUDIT`, which
is part of `SYSCALL_WORK_{ENTRY,EXIT}`, so this indeed does not change
the behaviour.
As you moved `rseq_debug_syscall_return()` outside of `syscall_exit_work()`,
it will indeed always be executed (potentially being no-op),
which removes the need for the removed check and does not change
the actual behaviour, because the rest of `syscall_trace_exit()` used
the exit TIFs as well anyway, as far as I understand.
> I probably moved too fast with this refactoring. I'll split this into
> smaller, more granular steps in v16 to make the logic clearer and easier
> to follow."
There were a bit more subtleties than I expected, so I think it is good
to have split it in more self-contained patches !
>> I understand that the change is to align with the generic entry, but it
>> seems
>> like this could have an impact that I do not really understand, so I prefer
>> asking !
>>
>> Apart from the above everything looks OK to me, but I'd like
>> some confirmation that the change of behaviours either do not exist or
>> are OK !
> Thank you for the review.
>
>> Thanks,
>> Ada
>>
>>> Cc: Mark Rutland <mark.rutland@arm.com>
>>> Cc: Will Deacon <will@kernel.org>
>>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>>> Reviewed-by: Linus Walleij <linusw@kernel.org>
>>> Reviewed-by: Yeoreum Yun <yeoreum.yun@arm.com>
>>> Reviewed-by: Kevin Brodsky <kevin.brodsky@arm.com>
>>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>>> ---
>>> v15
>>> - Make syscall_exit_to_user_mode_work() __always_inline to keep
>>> the fast-path performance as Sashiko pointed out.
>>> ---
>>> arch/arm64/include/asm/syscall.h | 18 +++++++++++++++++-
>>> arch/arm64/kernel/ptrace.c | 5 +----
>>> arch/arm64/kernel/syscall.c | 20 +-------------------
>>> 3 files changed, 19 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/arch/arm64/include/asm/syscall.h b/arch/arm64/include/
>>> asm/syscall.h
>>> index 30b203ef156b..b331e09b937f 100644
>>> --- a/arch/arm64/include/asm/syscall.h
>>> +++ b/arch/arm64/include/asm/syscall.h
>>> @@ -8,6 +8,7 @@
>>> #include <uapi/linux/audit.h>
>>> #include <linux/compat.h>
>>> #include <linux/err.h>
>>> +#include <linux/rseq.h>
>>> typedef long (*syscall_fn_t)(const struct pt_regs *regs);
>>> @@ -121,6 +122,21 @@ static inline int syscall_get_arch(struct
>>> task_struct *task)
>>> }
>>> int syscall_trace_enter(struct pt_regs *regs, unsigned long flags);
>>> -void syscall_trace_exit(struct pt_regs *regs, unsigned long flags);
>>> +void syscall_exit_work(struct pt_regs *regs, unsigned long flags);
>>> +
>>> +static inline bool has_syscall_work(unsigned long flags)
>>> +{
>>> + return unlikely(flags & _TIF_SYSCALL_WORK);
>>> +}
>>> +
>>> +static __always_inline void syscall_exit_to_user_mode_work(struct
>>> pt_regs *regs)
>>> +{
>>> + unsigned long flags = read_thread_flags();
>> ^-- This only reflects the post-syscall flags
>>
>>> +
>>> + rseq_syscall(regs);
>>> +
>>> + if (has_syscall_work(flags) || flags & _TIF_SINGLESTEP)
>>> + syscall_exit_work(regs, flags);
>>> +}
>>> #endif /* __ASM_SYSCALL_H */
>>> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
>>> index 15a45eeb56da..256aa20377e1 100644
>>> --- a/arch/arm64/kernel/ptrace.c
>>> +++ b/arch/arm64/kernel/ptrace.c
>>> @@ -28,7 +28,6 @@
>>> #include <linux/hw_breakpoint.h>
>>> #include <linux/regset.h>
>>> #include <linux/elf.h>
>>> -#include <linux/rseq.h>
>>> #include <asm/compat.h>
>>> #include <asm/cpufeature.h>
>>> @@ -2454,10 +2453,8 @@ int syscall_trace_enter(struct pt_regs *regs,
>>> unsigned long flags)
>>> return syscall;
>>> }
>>> -void syscall_trace_exit(struct pt_regs *regs, unsigned long flags)
>>> +void syscall_exit_work(struct pt_regs *regs, unsigned long flags)
>>> {
>>> - rseq_syscall(regs);
>>> -
>>> audit_syscall_exit(regs);
>> ^-- This was always called if entry had work or CONFIG_DEBUG_RSEQ
>> was enabled,
>> which is not the case anymore (same for the rest of the function)
> As explained above, thank you!
>
>>> if (flags & _TIF_SYSCALL_TRACEPOINT)
>>> diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
>>> index f6f87b042995..dac7bcc4bbdf 100644
>>> --- a/arch/arm64/kernel/syscall.c
>>> +++ b/arch/arm64/kernel/syscall.c
>>> @@ -54,11 +54,6 @@ static void invoke_syscall(struct pt_regs *regs,
>>> unsigned int scno,
>>> syscall_set_return_value(current, regs, 0, ret);
>>> }
>>> -static inline bool has_syscall_work(unsigned long flags)
>>> -{
>>> - return unlikely(flags & _TIF_SYSCALL_WORK);
>>> -}
>>> -
>>> static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
>>> const syscall_fn_t syscall_table[])
>>> {
>>> @@ -120,21 +115,8 @@ static void el0_svc_common(struct pt_regs *regs,
>>> int scno, int sc_nr,
>>> }
>>> invoke_syscall(regs, scno, sc_nr, syscall_table);
>>> -
>>> - /*
>>> - * The tracing status may have changed under our feet, so we have to
>>> - * check again. However, if we were tracing entry, then we always
>>> trace
>>> - * exit regardless, as the old entry assembly did.
>>> - */
>>> - if (!has_syscall_work(flags) && !IS_ENABLED(CONFIG_DEBUG_RSEQ)) {
>> ^-- We always traced exit if CONFIG_DEBUG_RSEQ is
>> enabled
>> ^-- `flags` is unchanged since entry, and exit was always
>> traced if there was work.
> As explained above, thank you!
>
> Best regards,
> Jinjie
Thanks again for the additional details !
Kind regards,
Ada
^ permalink raw reply
* [PATCH 3/5] drm/msm/dp: suppress bridge hotplug events during MST operation
From: Yongxing Mou @ 2026-06-29 14:48 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Tomi Valkeinen, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, linux-kernel, linux-amlogic, linux-arm-kernel,
linux-arm-msm, freedreno, Yongxing Mou
In-Reply-To: <20260629-msm-dp-msttypec-v1-0-646a10256233@oss.qualcomm.com>
The DP MST framework already generates the required hotplug events for
MST topology changes.
Suppress connector hotplug event generation from the bridge connector
path while MST is active, and continue propagating HPD notifications to
the DP driver.
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 6 ++++--
drivers/gpu/drm/msm/dp/dp_display.c | 9 ++++++++-
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 7334d6677604..82ed0dc450ab 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -162,6 +162,7 @@ static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bri
{
struct drm_connector *connector = &drm_bridge_connector->base;
struct drm_device *dev = connector->dev;
+ bool send_hotplug = true;
/*
* IRQ-only notification: extra_status carries the event but
@@ -179,9 +180,10 @@ static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bri
connector->status = status;
mutex_unlock(&dev->mode_config.mutex);
- drm_bridge_connector_hpd_notify(connector, status, extra_status, NULL);
+ drm_bridge_connector_hpd_notify(connector, status, extra_status, &send_hotplug);
- drm_kms_helper_connector_hotplug_event(connector);
+ if (send_hotplug)
+ drm_kms_helper_connector_hotplug_event(connector);
}
static void drm_bridge_connector_hpd_cb(void *cb_data,
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index 6835c68fe510..bc93b566fbca 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1790,10 +1790,17 @@ void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
msm_dp_hpd_plug_handle(dp);
} else {
msm_dp_hpd_plug_handle(dp);
+ /* mst_active is set in plug_handle; suppress SST hotplug */
+ if (send_hotplug && msm_dp_display->mst_active)
+ *send_hotplug = false;
}
} else {
- if (hpd_link_status == ISR_DISCONNECTED)
+ if (!msm_dp_display->mst_active) {
msm_dp_hpd_unplug_handle(dp);
+ } else if (send_hotplug) {
+ msm_dp_hpd_unplug_handle(dp);
+ *send_hotplug = false;
+ }
}
pm_runtime_put_sync(&msm_dp_display->pdev->dev);
--
2.43.0
^ permalink raw reply related
* [PATCH 2/5] drm/bridge_connector: preserve connector status for IRQ-only HPD events
From: Yongxing Mou @ 2026-06-29 14:48 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Tomi Valkeinen, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, linux-kernel, linux-amlogic, linux-arm-kernel,
linux-arm-msm, freedreno, Yongxing Mou
In-Reply-To: <20260629-msm-dp-msttypec-v1-0-646a10256233@oss.qualcomm.com>
The bridge connector HPD handling path currently updates
connector->status for every hpd_notify() invocation.
This does not work well for IRQ-only notifications where the event being
reported is carried by extra_status and no connector status transition is
associated with it.
One example is DP MST. HPD IRQs are propagated through
drm_bridge_hpd_notify_*() so that bridge drivers can process the
notification. During MST operation, however, the SST connector attached
to the bridge connector is intentionally kept disconnected while the MST
topology manager handles all connector creation, removal and hotplug
processing.
Updating connector->status for an IRQ-only MST notification may cause
the SST connector state to oscillate between connected and disconnected
depending on the notification path. These artificial state transitions
can later be detected by the polling logic and result in unnecessary
hotplug events being generated. Userspace then re-probes connector
status, potentially triggering the same sequence again.
Treat notifications with status == connector_status_unknown and a valid
extra_status as IRQ-only events. Forward the notification to bridge
drivers without modifying connector->status.
This keeps IRQ delivery working while leaving connector state management
to the component that actually owns it, such as the DP MST topology
framework.
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 5edca47a025f..7334d6677604 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -163,6 +163,18 @@ static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bri
struct drm_connector *connector = &drm_bridge_connector->base;
struct drm_device *dev = connector->dev;
+ /*
+ * IRQ-only notification: extra_status carries the event but
+ * status is unknown — do not overwrite connector->status.
+ */
+ if (status == connector_status_unknown &&
+ extra_status != DRM_CONNECTOR_NO_EXTRA_STATUS) {
+ drm_bridge_connector_hpd_notify(connector,
+ connector->status,
+ extra_status, NULL);
+ return;
+ }
+
mutex_lock(&dev->mode_config.mutex);
connector->status = status;
mutex_unlock(&dev->mode_config.mutex);
--
2.43.0
^ permalink raw reply related
* [PATCH 1/5] drm/bridge: allow hpd_notify() to suppress connector hotplug events
From: Yongxing Mou @ 2026-06-29 14:48 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Tomi Valkeinen, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, linux-kernel, linux-amlogic, linux-arm-kernel,
linux-arm-msm, freedreno, Yongxing Mou
In-Reply-To: <20260629-msm-dp-msttypec-v1-0-646a10256233@oss.qualcomm.com>
The bridge connector framework currently invokes all bridge
hpd_notify() callbacks and unconditionally emits a connector hotplug
event afterwards.
However, not every HPD notification requires a userspace hotplug event.
In particular, DP MST bridges may use hpd_notify() to propagate HPD and
IRQ notifications through the bridge chain while the actual hotplug
handling is performed by the DRM DP MST core. Connector creation,
removal and userspace hotplug events are already managed by the MST
topology framework.
Allow hpd_notify() implementations to suppress the bridge connector
hotplug event by introducing a bool *send_hotplug parameter. Drivers
can clear this flag when HPD processing should not result in a
connector hotplug notification.
A NULL pointer indicates that hotplug suppression is not supported by
the caller, such as the connector detect polling path.
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 ++-
drivers/gpu/drm/display/drm_bridge_connector.c | 15 +++++++++------
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 3 ++-
drivers/gpu/drm/msm/dp/dp_display.c | 3 ++-
drivers/gpu/drm/msm/dp/dp_drm.h | 3 ++-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 ++-
include/drm/drm_bridge.h | 3 ++-
7 files changed, 21 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
index 8cb17bd0e238..42e1cadcd3fb 100644
--- a/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
+++ b/drivers/gpu/drm/bridge/lontium-lt9611uxc.c
@@ -430,7 +430,8 @@ static const struct drm_edid *lt9611uxc_bridge_edid_read(struct drm_bridge *brid
static void lt9611uxc_bridge_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
const struct drm_edid *drm_edid;
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 8f7075fd2aa5..5edca47a025f 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -142,7 +142,8 @@ struct drm_bridge_connector {
static void drm_bridge_connector_hpd_notify(struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
@@ -150,13 +151,14 @@ static void drm_bridge_connector_hpd_notify(struct drm_connector *connector,
/* Notify all bridges in the pipeline of hotplug events. */
drm_for_each_bridge_in_chain_scoped(bridge_connector->encoder, bridge) {
if (bridge->funcs->hpd_notify)
- bridge->funcs->hpd_notify(bridge, connector, status, extra_status);
+ bridge->funcs->hpd_notify(bridge, connector, status,
+ extra_status, send_hotplug);
}
}
static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bridge_connector,
- enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status status,
+ enum drm_connector_status_extra extra_status)
{
struct drm_connector *connector = &drm_bridge_connector->base;
struct drm_device *dev = connector->dev;
@@ -165,7 +167,7 @@ static void drm_bridge_connector_handle_hpd(struct drm_bridge_connector *drm_bri
connector->status = status;
mutex_unlock(&dev->mode_config.mutex);
- drm_bridge_connector_hpd_notify(connector, status, extra_status);
+ drm_bridge_connector_hpd_notify(connector, status, extra_status, NULL);
drm_kms_helper_connector_hotplug_event(connector);
}
@@ -227,7 +229,8 @@ drm_bridge_connector_detect(struct drm_connector *connector, bool force)
if (hdmi)
drm_atomic_helper_connector_hdmi_hotplug(connector, status);
- drm_bridge_connector_hpd_notify(connector, status, DRM_CONNECTOR_NO_EXTRA_STATUS);
+ drm_bridge_connector_hpd_notify(connector, status,
+ DRM_CONNECTOR_NO_EXTRA_STATUS, NULL);
} else {
switch (connector->connector_type) {
case DRM_MODE_CONNECTOR_DPI:
diff --git a/drivers/gpu/drm/meson/meson_encoder_hdmi.c b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
index 4aecf0ffcf75..a67e7b365c5b 100644
--- a/drivers/gpu/drm/meson/meson_encoder_hdmi.c
+++ b/drivers/gpu/drm/meson/meson_encoder_hdmi.c
@@ -324,7 +324,8 @@ static int meson_encoder_hdmi_atomic_check(struct drm_bridge *bridge,
static void meson_encoder_hdmi_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
struct meson_encoder_hdmi *encoder_hdmi = bridge_to_meson_encoder_hdmi(bridge);
diff --git a/drivers/gpu/drm/msm/dp/dp_display.c b/drivers/gpu/drm/msm/dp/dp_display.c
index fcfee26f0078..6835c68fe510 100644
--- a/drivers/gpu/drm/msm/dp/dp_display.c
+++ b/drivers/gpu/drm/msm/dp/dp_display.c
@@ -1763,7 +1763,8 @@ void msm_dp_bridge_hpd_disable(struct drm_bridge *bridge)
void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
struct msm_dp_bridge *msm_dp_bridge = to_dp_bridge(bridge);
struct msm_dp *msm_dp_display = msm_dp_bridge->msm_dp_display;
diff --git a/drivers/gpu/drm/msm/dp/dp_drm.h b/drivers/gpu/drm/msm/dp/dp_drm.h
index f6b96c27408a..07ddcd055962 100644
--- a/drivers/gpu/drm/msm/dp/dp_drm.h
+++ b/drivers/gpu/drm/msm/dp/dp_drm.h
@@ -32,6 +32,7 @@ void msm_dp_bridge_hpd_disable(struct drm_bridge *bridge);
void msm_dp_bridge_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status);
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug);
#endif /* _DP_DRM_H_ */
diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
index d02d432abde4..ad659cef16f5 100644
--- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
+++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
@@ -430,7 +430,8 @@ static void hdmi4_bridge_disable(struct drm_bridge *bridge,
static void hdmi4_bridge_hpd_notify(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status)
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug)
{
struct omap_hdmi *hdmi = drm_bridge_to_hdmi(bridge);
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index 9c4c88024cc5..e6de665ce8f6 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -616,7 +616,8 @@ struct drm_bridge_funcs {
void (*hpd_notify)(struct drm_bridge *bridge,
struct drm_connector *connector,
enum drm_connector_status status,
- enum drm_connector_status_extra extra_status);
+ enum drm_connector_status_extra extra_status,
+ bool *send_hotplug);
/**
* @hpd_enable:
--
2.43.0
^ permalink raw reply related
* [PATCH 0/5] drm/msm/dp: Add MSM Type-C MST support
From: Yongxing Mou @ 2026-06-29 14:48 UTC (permalink / raw)
To: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Rob Clark,
Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang, Sean Paul,
Marijn Suijten, Tomi Valkeinen, Bjorn Andersson, Konrad Dybcio
Cc: dri-devel, linux-kernel, linux-amlogic, linux-arm-kernel,
linux-arm-msm, freedreno, Yongxing Mou
The bridge connector framework currently treats every HPD notification
as a connector state update and emits a userspace hotplug event.
Once MST is enabled, however, connector creation, removal and hotplug
handling are already managed by the DRM DP MST topology manager.
As a result:
- the SST connector may transiently transition between connected and
disconnected during MST initialization
- MST IRQ notifications may generate duplicate userspace hotplug
events, once from the bridge connector layer and once from the MST
topology manager
Introduce explicit support for IRQ-only HPD notifications in the bridge
connector framework and allow bridge drivers to suppress connector
hotplug events when those events are already handled elsewhere.
MSM DP uses these mechanisms to integrate Type-C MST hubs without
generating duplicate or spurious userspace hotplug notifications.
Testing
-------
Tested on Hamoa-EVK with a Type-C MST hub and dual-monitor setup.
Both fbcon and Weston were exercised. No duplicate hotplug events,
connector state oscillation or display flickering were observed after
hub attachment.
Dependencies
------------
This patch series was made on top of:
[1] drm: handle IRQ_HPD events correctly (v4)
https://lore.kernel.org/r/20260608-hpd-irq-events-v4-0-30b62b335487@oss.qualcomm.com
[2] drm/msm/dp: Add MST support for MSM chipsets (v5)
https://patchwork.freedesktop.org/series/142207/#rev5
[3] drm/msm/dp: Prerequisite cleanup for upcoming MST support (v7)
https://lore.kernel.org/r/20260609-dp_mstclean-v7-0-ea04113e8233@oss.qualcomm.com
Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com>
---
Yongxing Mou (5):
drm/bridge: allow hpd_notify() to suppress connector hotplug events
drm/bridge_connector: preserve connector status for IRQ-only HPD events
drm/msm/dp: suppress bridge hotplug events during MST operation
drm/msm/dp: report IRQ_HPD as an IRQ-only notification
drm/msm/dp: mark the SST connector disconnected when MST is enabled
drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 3 +-
drivers/gpu/drm/display/drm_bridge_connector.c | 31 ++++++++++++++++-----
drivers/gpu/drm/meson/meson_encoder_hdmi.c | 3 +-
drivers/gpu/drm/msm/dp/dp_display.c | 38 +++++++++++++++-----------
drivers/gpu/drm/msm/dp/dp_drm.h | 3 +-
drivers/gpu/drm/omapdrm/dss/hdmi4.c | 3 +-
drivers/soc/qcom/pmic_glink_altmode.c | 14 ++++++----
include/drm/drm_bridge.h | 3 +-
8 files changed, 65 insertions(+), 33 deletions(-)
---
base-commit: e7d700e14934e68f86338c5610cf2ae76798b663
change-id: 20260629-msm-dp-msttypec-b420df7da587
prerequisite-message-id: <20260608-hpd-irq-events-v4-0-30b62b335487@oss.qualcomm.com>
prerequisite-patch-id: adc6d802a2f71d23c077a5cdb9a257809e9db50e
prerequisite-patch-id: bbd956a3b65a90c1fe9e884bc32c49bd83fd3129
prerequisite-patch-id: 014460a25c380d089764ab4e1a58577ebc1b9e71
prerequisite-patch-id: fc03fb9435b8c60321f9ae28e396a6bff2f347ae
prerequisite-patch-id: cd4cd57a72c798fc95afdfdeb9b81cc7a2dbd25d
prerequisite-patch-id: fe431fb614383eb6444f6bfb928e7e40c2de951e
prerequisite-patch-id: 2a058aa8309016f424b1d4ca19a9b20e92f4d8b6
prerequisite-patch-id: 64c3616bb979b663a01342d1f217588b347ae8bb
prerequisite-change-id: 20260410-msm-dp-mst-35130b6e8b84:v5
prerequisite-patch-id: 1d440cb9fed2bdd66d8de0e1e20475f0fe166973
prerequisite-patch-id: be0f4b80697df7224c80362b161b8a9f0a542184
prerequisite-patch-id: eefa6e6353df301420feae1da704a9db2c2155f2
prerequisite-patch-id: 9e9095f82dd6c131c9f3c1de4fdb8a62bd65ca24
prerequisite-patch-id: 3e635f008f9b56823101abd9253905f078fcb3b5
prerequisite-patch-id: e39e0dc124ed043c7a419610ebe03ad105da27db
prerequisite-patch-id: 945af39213cd4241e1a5929fada04a9286aeb5db
prerequisite-patch-id: 898ae7e4582a6b31492c223e7dd167fb9ce78096
prerequisite-patch-id: 3887553893357c1ffbda99eb010801bc2166cbad
prerequisite-patch-id: 7ccd961fa3c6f925659dee7d7a5bd167c8e7331b
prerequisite-patch-id: be2bf918e0e87ec2ea999927f36bd172c498748e
prerequisite-patch-id: 6aacdabb2dd0536dc04da04f8419ae39e35f8b19
prerequisite-patch-id: a9f27eff8f643ff445810b17d670891928f5b416
prerequisite-patch-id: efd300a2b52715153b8c1c7407db696eb331594b
prerequisite-patch-id: 950abefc4862050ef606404977fd27c5dd2cbb2b
prerequisite-patch-id: c6a9aaba753b5538864f7f6e065d910833baec21
prerequisite-patch-id: c73c1f6eb16b2a6ff11b20495fa0981683bdaaee
prerequisite-patch-id: 94957394b3870ec63ab766d682df592da978dd19
prerequisite-patch-id: f27cba0cf5f08d21f59f29a0c9ed7f197ddfa2c7
prerequisite-patch-id: 683855949a9ed37bc0cc4d1899373e55eac4ddc3
prerequisite-patch-id: 9b3a2b526476c32c8a859824e551e23412674766
prerequisite-patch-id: be866cf2acd4960f31f0dbd05e21f0722dcb70ab
prerequisite-patch-id: 58bd115be590c0d892a72e06794f5b244dbdb7f8
prerequisite-patch-id: 87435a0f6827516f4e2b5d8471a2b289bb73a88c
prerequisite-patch-id: 1064db7111fc77377dbf246eb0fdef90c18c46ee
prerequisite-patch-id: e112aaf6088f2bfa90bc67feaac86a4fc1ad23ca
prerequisite-patch-id: fcc0f2ee6dc0358d62593c1295d26a013fa11223
prerequisite-patch-id: 66364b8806fc6abeabe1a0b871e4e8c841ce2aa7
prerequisite-patch-id: 243046f52a14b416caead3469d580ea5b029f9bb
prerequisite-patch-id: efd8014f647a6aa5fadc9d62a6e1920d76a6c80f
prerequisite-patch-id: f4dbd5ae84a01ea89c7d00ca39fd76cd247bc353
prerequisite-patch-id: 30a16a45edefc8769b10d90a7807b6522cd31f15
prerequisite-patch-id: e12fd2908ca33de1f1265fd40190eaad8637e569
prerequisite-patch-id: 3baac076fdda664d00aa9a83481f76ec38c07e8a
prerequisite-patch-id: ee6a93ffa2d5461ee7b07929ff21626a14773b7a
prerequisite-patch-id: c8d444e2a6512f106da2675d4a42a92208d5c6f1
prerequisite-patch-id: 0491a69feb036cfa2e75401e093ebad387cf2846
prerequisite-patch-id: 707e7a3e5114c86f5bcc0b36e7cc8beb0c957780
prerequisite-patch-id: b1ae90d73bd7c3d19cfe4371b5dc9a816f1316a6
prerequisite-patch-id: 4c183b8ffd599169c8d3c5f3aad5ecc467b150f2
prerequisite-message-id: <20260609-dp_mstclean-v7-0-ea04113e8233@oss.qualcomm.com>
prerequisite-patch-id: 1d440cb9fed2bdd66d8de0e1e20475f0fe166973
prerequisite-patch-id: be0f4b80697df7224c80362b161b8a9f0a542184
prerequisite-patch-id: eefa6e6353df301420feae1da704a9db2c2155f2
prerequisite-patch-id: 9e9095f82dd6c131c9f3c1de4fdb8a62bd65ca24
prerequisite-patch-id: 3e635f008f9b56823101abd9253905f078fcb3b5
prerequisite-patch-id: e39e0dc124ed043c7a419610ebe03ad105da27db
prerequisite-patch-id: 945af39213cd4241e1a5929fada04a9286aeb5db
prerequisite-patch-id: 898ae7e4582a6b31492c223e7dd167fb9ce78096
prerequisite-patch-id: 3887553893357c1ffbda99eb010801bc2166cbad
prerequisite-patch-id: 7ccd961fa3c6f925659dee7d7a5bd167c8e7331b
prerequisite-patch-id: be2bf918e0e87ec2ea999927f36bd172c498748e
prerequisite-patch-id: 6aacdabb2dd0536dc04da04f8419ae39e35f8b19
prerequisite-patch-id: a9f27eff8f643ff445810b17d670891928f5b416
prerequisite-patch-id: efd300a2b52715153b8c1c7407db696eb331594b
prerequisite-patch-id: 950abefc4862050ef606404977fd27c5dd2cbb2b
Best regards,
--
Yongxing Mou <yongxing.mou@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH] ASoC: meson: aiu: fifo-spdif: soft reset the S/PDIF datapath on start/stop
From: Christian Hewitt @ 2026-06-29 14:47 UTC (permalink / raw)
To: Jerome Brunet
Cc: Martin Blumenstingl, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Neil Armstrong, Kevin Hilman, linux-sound,
linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <1jwlvha6xv.fsf@starbuckisacylon.baylibre.com>
> On 29 Jun 2026, at 4:04 pm, Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On ven. 26 juin 2026 at 22:41, Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote:
>
>> On Fri, Jun 26, 2026 at 10:04 AM Christian Hewitt
>> <christianshewitt@gmail.com> wrote:
>>>
>>> The I2S FIFO soft-resets its fast domain on start (AIU_RST_SOFT bit 0 +
>>> AIU_I2S_SYNC read in aiu_fifo_i2s_trigger), mirroring the downstream
>>> vendor driver's audio_out_i2s_enable(). The S/PDIF FIFO has no equivalent:
>>> it only toggles the IEC958 DCU, so a stale datapath FIFO can be replayed,
>>> producing the "machine gun noise" buffer underrun - on start when switching
>>> outputs, and on stop when playback ends. The latter is audible on devices
>>> with an always-on S/PDIF-fed DAC (e.g. the ES7144 on the WeTek Play2).
>>>
>>> The vendor driver resets the IEC958 fast domain (AIU_RST_SOFT bit 2) on
>>> both enable and disable (audio_hw_958_enable), and when reconfiguring
>>> (audio_hw_958_reset clears AIU_958_DCU_FF_CTRL then resets). Do the same:
>>> reset before enabling the DCU on start, and after disabling it on stop.
>>>
>>> Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
>> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>>
>> This matches the vendor driver, references:
>> - fast-reset SPDIF is triggered on enable and disable: [0]
>> - fast-reset SPDIF is triggered after all of the configuration is
>> written, then DCU_FF_CTRL is enabled: [1]
>
> Take what the vendor driver does with a grain of salt, especially when
> it comes to audio
>
>>
>> [...]
>>> case SNDRV_PCM_TRIGGER_SUSPEND:
>>> case SNDRV_PCM_TRIGGER_PAUSE_PUSH:
>>> case SNDRV_PCM_TRIGGER_STOP:
>>> fifo_spdif_dcu_enable(component, false);
>>> + snd_soc_component_write(component, AIU_RST_SOFT,
>>> + AIU_RST_SOFT_958_FAST);
>> It doesn't seem to make any difference, so just for the record:
>> The vendor driver first triggers AIU_RST_SOFT_958_FAST then disables DCU: [2]
>>
>
> One could even wonder if there is any point in applying a reset when
> everything is stopped, if the enable path will apply this same
> reset before anything else is started again ? Does it really changes
> anything to the reported issue ?
Using disable/reset or reset/disable didn’t make any difference in my
testing, but without any reset playback stop on the WeTek Play2 board
with hardwired DAC always triggers the buffer underrun.
CH.
^ permalink raw reply
* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Laurent Pinchart @ 2026-06-29 14:44 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maxime Ripard, Maarten Lankhorst, Thomas Zimmermann, David Airlie,
Simona Vetter, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJJ4X22CJ3FG.5EYF84LVRNOG@bootlin.com>
On Fri, Jun 26, 2026 at 06:51:14PM +0200, Luca Ceresoli wrote:
> On Fri Jun 26, 2026 at 4:38 PM CEST, Maxime Ripard wrote:
> > On Fri, Jun 26, 2026 at 04:16:39PM +0200, Luca Ceresoli wrote:
> >> On Fri Jun 26, 2026 at 12:09 PM CEST, Maxime Ripard wrote:
> >> > On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote:
> >> >> On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
> >> >> > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote:
> >> >> >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote:
> >> >> >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
> >> >> >> >> In preparation to introduce bridge hotplug, split out from
> >> >> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> >> >> dedicated function. This will be needed to be able to add (and re-add) the
> >> >> >> >> connector from different code paths.
> >> >> >> >
> >> >> >> > Same story here, explaining what you need later on that calls for that
> >> >> >> > change would be nice.
> >> >> >>
> >> >> >> Here's a more verbose version:
> >> >> >>
> >> >> >> Currently drm_bridge_connector_init() does two things:
> >> >> >>
> >> >> >> * allocate and initialize the drm_bridge_connector
> >> >> >> (which embeds a drm_connector)
> >> >> >> * initialize and register the embedded drm_connector
> >> >> >>
> >> >> >> For bridge hotplug we need to separate these two actions:
> >> >> >>
> >> >> >> * the drm_connector needs to be added and removed at any time based on
> >> >> >> hotplug events
> >> >> >> * the drm_bridge_connector is designated to create and remove the
> >> >> >> drm_connector, so it must be persistent for the card lifetime
> >> >> >>
> >> >> >> As the lifetimes of drm_bridge_connector and drm_connector become
> >> >> >> different, we need to create them in different moments.
> >> >> >>
> >> >> >> In preparation to support that, split out from
> >> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> >> dedicated function. No functional changes, just moving code around for
> >> >> >> now. A future commit will make the drm_connector be created based on
> >> >> >> hotplug events.
> >> >> >>
> >> >> >> Looks good?
> >> >> >
> >> >> > The message itself, yes, thanks.
> >> >> >
> >> >> > However, I have questions now :)
> >> >> >
> >> >> > Do we really expect drm_bridge_connector to stick around when a bridge
> >> >> > gets unplugged? If so, how does it cope with having, say, an HDMI
> >> >> > connector, and then swapping out the hotplugged part for an LVDS one?
> >> >> > Does the HDMI connector sticks around indefinitely?
> >> >>
> >> >> In your example, the HDMI drm_connector would be unregistered and put on
> >> >> hotunplug. Its allocation will stick around until the last put but that's
> >> >> quite irrelevant. Then, on plugging the LVDS addon, a new LVDS
> >> >> drm_connector will be created and registered.
> >> >>
> >> >> > *Especially* if we're using overlays for this, I'd expect everything
> >> >> > after the first hotplugged bridge to be destroyed, no?
> >> >>
> >> >> As said, it would be unregistered immediately but might be freed later on
> >> >> if still refcounted.
> >> >>
> >> >> This is visible in patches 36+15, the path to follow is:
> >> >>
> >> >> drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36]
> >> >> -> drm_bridge_connector_dynconn_release() [patch 15]
> >> >>
> >> >> Does this solve your concern?
> >> >
> >> > Not really, I'm talking about drm_bridge_connector. The fact that
> >> > bridges are destroyed make sense to me. The fact that
> >> > drm_bridge_connector sticks around doesn't. It's supposed to be a
> >> > connector for bridges. If you don't have bridges because they got
> >> > destroyed, and connector, drm_bridge_connector doesn't have a reason to
> >> > exist anymore, unless it's drm_bridge_hotplug in a trench coat :)
> >>
> >> It is not a hotplug-bridge in a trench coat, no :) The code is clear about
> >> this.
> >>
> >> I'd say with this series a "drm_bridge_connector" is just becoming
> >> something more (perhaps something else too). Somewhat as "a drm_bridge is
> >> either a bridge or something else". :)
> >>
> >>
> >> But let's leave names aside for a moment. If just looking at the current
> >> code, the drm_bridge_connector is "a handler, owned by the card/encoder and
> >> having the same lifetime, which takes care of drm_connector
> >> creation/destruction at card probe/removal".
> >>
> >> What we need now is just the same plug " and on hotplug events" appended.
> >>
> >> So in both cases there needs to be "a handler persitent with the card".
> >>
> >> Do we agree so far?
> >
> > Ish. If we go for that, then we need to update the name.
>
> drm_connector_manager?
> drm_bridge_connector_manager?
I'm fine with a rename. When developing drm_bridge_connector I've always
envisioned it as code that manages the creation of a connector for a
chain of bridges. In particular, the drm_bridge_connector object is
*not* and has never been a bridge.
Ideally all this should move to the DRM core and be transparent to
drivers. Drivers could set a flag somewhere to opt-in for connectors
managed by the DRM core.
> > drm_bridge_connector for something that is neither a bridge or a
> > connector is not great.
> >
> > But even then, I'm not even sure why we need to have that "manager" in
> > the first place. You want to make bridges be aware if they are the last
> > in the chain or not.
I don't think bridges should be aware of whether or not they're the last
one in the chain.
> > Use that property in attach to either create a
> > drm_bridge_connector instance if you're last, or attach the next bridge
> > if you aren't.
>
> What? o_O
>
> Several encoder drivers have been painfully converted to create a
> drm_bridge_connector. Now if the bridges start doing it themselves we
> should go back to those encoder drivers and ditch all the
> drm_bridge_connector from there?
>
> I must be missing something. Can you elaborate on this?
--
Regards,
Laurent Pinchart
^ permalink raw reply
* ❌ FAIL: Test report for for-kernelci (7.2.0-rc1, upstream-arm-next, dc59e4fe)
From: cki-project @ 2026-06-29 14:43 UTC (permalink / raw)
To: linux-arm-kernel, ftjahjad, catalin.marinas, will, bgoncalv,
mmalik, omosnace
Hi, we tested your kernel and here are the results:
Overall result: FAILED
Merge: OK
Compile: OK
Test: FAILED
Kernel information:
Commit message: Linux 7.2-rc1
You can find all the details about the test run at
https://datawarehouse.cki-project.org/kcidb/checkouts/redhat:2636852511
One or more kernel tests failed:
Unrecognized or new issues:
Boot test
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2636852511_aarch64_kernel_kcidb_tool_21543639_6
Non-passing ran subtests:
❌ FAIL distribution/kpkginstall/journalctl-check
Reboot test
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2636852511_aarch64_kernel_kcidb_tool_21543639_11
Non-passing ran subtests:
❌ FAIL misc/reboot-test/journalctl-check
selinux-policy: serge-testsuite
aarch64
Logs: https://datawarehouse.cki-project.org/kcidb/tests/redhat:2636852511_aarch64_kernel_kcidb_tool_21543641_8
Non-passing ran subtests:
⚡ ERROR Setup
❌ FAIL Test
We also see the following known issues which are not related to your changes:
Issue: [upstream] Hardware - Firmware test suite - auto-waive failures
URL: https://gitlab.com/cki-project/infrastructure/-/issues/779
Affected tests:
Hardware - Firmware test suite [aarch64]
If you find a failure unrelated to your changes, please ask the test maintainer to review it.
This will prevent the failures from being incorrectly reported in the future.
Please reply to this email if you have any questions about the tests that we
ran or if you have any suggestions on how to make future tests more effective.
,-. ,-.
( C ) ( K ) Continuous
`-',-.`-' Kernel
( I ) Integration
`-'
______________________________________________________________________________
^ permalink raw reply
* Re: [PATCH] mtd: nand: ecc-mtk: handle ECC clock enable failures
From: Miquel Raynal @ 2026-06-29 14:39 UTC (permalink / raw)
To: Richard Weinberger, Vignesh Raghavendra, Matthias Brugger,
AngeloGioacchino Del Regno, linux-mtd, linux-kernel,
linux-arm-kernel, linux-mediatek, Pengpeng Hou
In-Reply-To: <20260615063232.44383-1-pengpeng@iscas.ac.cn>
On Mon, 15 Jun 2026 14:32:32 +0800, Pengpeng Hou wrote:
> mtk_ecc_get() gets a reference to the ECC platform device, obtains the
> provider state and then enables the ECC clock before initializing the
> hardware.
>
> The clk_prepare_enable() return value is currently ignored. If enabling
> the clock fails, the code still touches the ECC registers and returns a
> live ECC handle to the caller. The provider device reference acquired
> by of_find_device_by_node() is also kept even though the handle setup
> failed.
>
> [...]
Applied to mtd/fixes, thanks!
[1/1] mtd: nand: ecc-mtk: handle ECC clock enable failures
commit: 82d9a2b45b170f0c52ac61e0e3e23f212cd065f0
Patche(s) should be available on mtd/linux.git and will be
part of the next PR (provided that no robot complains by then).
Kind regards,
Miquèl
^ permalink raw reply
* Re: [PATCH 1/9] dt-bindings: nvmem: imx-ocotp: Add support for secure-enclave
From: Frieder Schrempf @ 2026-06-29 14:37 UTC (permalink / raw)
To: Krzysztof Kozlowski, Frieder Schrempf
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <30e02780-52c7-4a71-9d4f-4b7a20494161@kernel.org>
On 22.06.26 15:12, Krzysztof Kozlowski wrote:
> On 17/06/2026 13:36, Frieder Schrempf wrote:
>> On 17.06.26 12:49, Krzysztof Kozlowski wrote:
>>> On Tue, Jun 16, 2026 at 01:52:16PM +0200, Frieder Schrempf wrote:
>>>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>>
>>>> Some SoCs like the i.MX9 family allow full access to the fuses only
>>>> through the secure enclave firmware API. Add a property to reference
>>>> the secure enclave node and let the driver use the API.
>>>>
>>>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>>>> ---
>>>> Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>>> index a8076d0e2737..14a6429f4a4c 100644
>>>> --- a/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>>> +++ b/Documentation/devicetree/bindings/nvmem/imx-ocotp.yaml
>>>> @@ -53,6 +53,10 @@ properties:
>>>> reg:
>>>> maxItems: 1
>>>>
>>>> + secure-enclave:
>>>> + $ref: /schemas/types.yaml#/definitions/phandle
>>>> + description: A phandle to the secure enclave node
>>>
>>> Two things here:
>>> 1. Here you describe what for is that phandle, how it is used by the
>>> hardware. Currently the description repeats the property name and type,
>>> so not much useful.
>>
>> Ok, agree.
>>
>>>
>>> 2. If you access OTP via firmware, then this is completely different
>>> interface than MMIO, thus:
>>> A. reg is not appropriate
>>> B. Device is very different thus it has different compatible and I even
>>> claim should be in different binding. Devices having completely
>>> different SW interface should not be in the same binding, at least
>>> usually.
>>>
>>> If any of above is not accurate, then your commit msg should answer why
>>> and give some background.
>>
>> Thanks for the feedback!
>>
>> The driver currently uses the limited MMIO (FSB) interface to access the
>> OTPs. The intention is to support the firmware interface alongside the
>> MMIO interface so the driver can pick the interface that is available
>> (firmware might not be loaded) and fallback to MMIO.
>>
>> Following your argument would mean a driver deciding by itself which
>> interface to use at runtime is not something we want to have in general,
>> right?
>
> No, the property fits DT, but above information should be in commit msg.
> If this SoC has indeed both interfaces - MMIO and firmware calls - then
> everything is in general fine. I assumed that is not the case and MMIO
> is not really working.
>
> What was confusing is that it feels like you are changing existing
> interface, but why wasn't all this documented in the beginning? There is
> imx9 in this binding already, so was it working? Was it not working at
> all? Commit msg must clarify that.
Ok, thanks for clarifying. The MMIO interface for imx9 is working just
fine, but it's limited to access only a subset of the available OTP fuse
register space and only provides read access. Only the firmware
interface provides full access. I will extend the commit message
accordingly.
>
>>
>> In turn this would mean we need two drivers, or at least two
>> compatibles/bindings for something that is effectively the same hardware.
>
> Driver design is orthogonal choice here.
>
> It can reside in separate binding, if MMIO is still valid, but till
> everything is not yet too complex can be also this binding file.
>
> If it stays in this binding, then you need to restrict properties per
> variant, so add if:then: block which will disallow the phandle for other
> variants.
Of course! I totally forgot about this. I will restrict the property to
be only valid for variants that have the ELE firmware interface.
^ permalink raw reply
* [REGRESSION] mainline/master: Apalis iMX6 no longer boots
From: Leonardo Costa @ 2026-06-29 14:34 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam
Cc: leonardo.costa, devicetree, imx, linux-arm-kernel, linux-kernel,
regressions
Hello,
We are seeing a regression on Apalis iMX6 where the kernel doesn't boot in the
newest v7.2-rc1 (it was working before, in v7.1). The device tree being used is the imx6q-apalis-eval.dtb. The kernel
configuration used is the one shown below:
https://gist.github.com/lcosta37/53efdb2fb6e6e0fc05437c7e53b47737
The kernel logs stop almost immediately as the board starts to boot, and I
don't notice any difference in the logs that points to the cause.
Is this known? We are seeing this behavior on all Apalis iMX6 modules, though
we don't see it on Colibri iMX6, so it is not SoC-specific.
Logs from v7.2-rc1 (not working, printing stops after the last line pasted
here):
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 7.2.0-rc1-0.0.0-devel (oe-user@oe-host) (arm-tdx-linux-gnueabi-gcc (GCC) 16.1.0, GNU ld (GNU Binutils) 2.46.1) #1 SMP PREEMPT Sun Jun 28 19:01:31 UTC 2026
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 256 MiB at 0x40000000
[ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] percpu: Embedded 15 pages/cpu s28684 r8192 d24564 u61440
[ 0.000000] Kernel command line: root=PARTUUID=adb2cea1-02 ro rootwait console=tty1 console=ttymxc0,115200
[ 0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 262144
[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
Logs from v7.1 (working) (full logs here: https://paste.debian.net/hidden/0f65ae5f)
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 7.1.0-0.0.0-devel (oe-user@oe-host) (arm-tdx-linux-gnueabi-gcc (GCC) 16.1.0, GNU ld (GNU Binutils) 2.46.1) #1 SMP PREEMPT Wed Jun 24 01:36:41 UTC 2026
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7), cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
[ 0.000000] OF: fdt: Machine model: Toradex Apalis iMX6Q/D Module on Apalis Evaluation Board
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] cma: Reserved 256 MiB at 0x40000000
[ 0.000000] OF: reserved mem: Reserved memory: No reserved-memory node in the DT
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] percpu: Embedded 15 pages/cpu s28684 r8192 d24564 u61440
[ 0.000000] pcpu-alloc: s28684 r8192 d24564 u61440 alloc=15*4096
[ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
[ 0.000000] Kernel command line: root=PARTUUID=4ce4ba92-02 ro rootwait console=tty1 console=ttymxc0,115200
[ 0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 262144
[ 0.000000] mem auto-init: stack:all(zero), heap alloc:off, heap free:off
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[ 0.000000] rcu: Preemptible hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] Trampoline variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 10 jiffies.
[ 0.000000] RCU Tasks: Setting shift to 2 and lim to 1 rcu_task_cb_adjust=1 rcu_task_cpu_ids=4.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[ 0.000000] rcu: srcu_init: Setting srcu_struct sizes based on contention.
[ 0.000000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.000000] Switching to timer-based delay loop, resolution 333ns
[ 0.000001] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every 715827882841ns
[ 0.000018] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 637086815595 ns
[ 0.001910] Console: colour dummy device 80x30
[ 0.001926] printk: legacy console [tty1] enabled
[ 0.002519] Calibrating delay loop (skipped), value calculated using timer frequency.. 6.00 BogoMIPS (lpj=30000)
[ 0.002561] CPU: Testing write buffer coherency: ok
[ 0.002627] CPU0: Spectre v2: using BPIALL workaround
[ 0.002650] pid_max: default: 32768 minimum: 301
[ 0.002989] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.003038] Mountpoint-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.003430] VFS: Finished mounting rootfs on nullfs
[ 0.004538] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.006552] Setting up static identity map for 0x10100000 - 0x10100060
[ 0.006835] rcu: Hierarchical SRCU implementation.
[ 0.006864] rcu: Max phase no-delay instances is 1000.
[ 0.007320] Timer migration: 1 hierarchy levels; 8 children per group; 1 crossnode level
[ 0.008854] smp: Bringing up secondary CPUs ...
[ 0.010035] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.010218] CPU1: Spectre v2: using BPIALL workaround
[ 0.011412] CPU2: thread -1, cpu 2, socket 0, mpidr 80000002
[ 0.011581] CPU2: Spectre v2: using BPIALL workaround
[ 0.012747] CPU3: thread -1, cpu 3, socket 0, mpidr 80000003
[ 0.012917] CPU3: Spectre v2: using BPIALL workaround
[ 0.013109] smp: Brought up 1 node, 4 CPUs
...
^ permalink raw reply
* Re: [PATCH 1/5] media: nxp: imx8-isi: Fix stream ID validation bypass in crossbar routing
From: Frank Li @ 2026-06-29 14:33 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Christian Hemp,
Stefan Riedmueller, Jacopo Mondi, Dong Aisheng, Guoniu Zhou,
linux-media, imx, linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260629-isi-v1-1-deebfdb1b07b@oss.nxp.com>
On Mon, Jun 29, 2026 at 03:44:55PM +0800, Guoniu Zhou wrote:
> The crossbar routing validation has a critical bug where it validates
> the wrong routing table, allowing userspace to bypass validation entirely.
>
> The __mxc_isi_crossbar_set_routing() function is called to validate and
> apply a new routing table from userspace. However, the validation loop
> iterates over state->routing (the currently active routing table) instead
> of the routing parameter (the new table being validated):
>
> for_each_active_route(&state->routing, route) {
>
> This means userspace can submit any invalid routing configuration and it
> will pass validation as long as the currently active routing is valid.
> This is a security issue as it allows userspace to configure routes that
> violate hardware constraints, potentially causing undefined hardware
> behavior.
>
> Fix by validating the routing table that will actually be applied:
>
> for_each_active_route(routing, route) {
>
> Additionally, add validation to enforce hardware constraints that were
> previously missing:
> - SOURCE stream must be 0 (ISI pipes are hardcoded to stream 0)
> - SINK stream must be less than the ISI channel count
> - Memory input can only route to the first pipeline (existing check)
Please use two patches to fix one, one fix for_each_active_route()
other other fix others.
Frank
>
> Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> .../platform/nxp/imx8-isi/imx8-isi-crossbar.c | 24 ++++++++++++++++++++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> index c580c831972e..29f14d30dbbb 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> @@ -106,8 +106,28 @@ static int __mxc_isi_crossbar_set_routing(struct v4l2_subdev *sd,
> if (ret)
> return ret;
>
> - /* The memory input can be routed to the first pipeline only. */
> - for_each_active_route(&state->routing, route) {
> + /*
> + * Validate routes against hardware constraints:
> + * - SOURCE stream must be 0 (pipes are hardcoded to stream 0)
> + * - SINK stream must be < ISI channel count
> + * - Memory input can only route to the first pipeline
> + */
> + for_each_active_route(routing, route) {
> + if (route->source_stream != 0) {
> + dev_dbg(xbar->isi->dev,
> + "route to pipe %u must use source_stream=0, got %u\n",
> + route->source_pad - xbar->num_sinks,
> + route->source_stream);
> + return -ENXIO;
> + }
> +
> + if (route->sink_stream >= xbar->num_sources) {
> + dev_dbg(xbar->isi->dev,
> + "sink_stream %u exceeds hardware limit %u\n",
> + route->sink_stream, xbar->num_sources - 1);
> + return -ENXIO;
> + }
> +
> if (route->sink_pad == xbar->num_sinks - 1 &&
> route->source_pad != xbar->num_sinks) {
> dev_dbg(xbar->isi->dev,
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-29 14:28 UTC (permalink / raw)
To: Jie Gan
Cc: Suzuki K Poulose, Mike Leach, James Clark, Konrad Dybcio,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang, Jingyi Wang, Abel Vesa,
Yuanfang Zhang, linux-arm-msm, devicetree, linux-kernel,
coresight, linux-arm-kernel
In-Reply-To: <9432df20-08bf-4134-b4b9-e6b5d618af81@oss.qualcomm.com>
On Mon, Jun 29, 2026 at 10:08:17AM +0800, Jie Gan wrote:
[...]
> Can I fix the issue by adding "arm,primecell-periphid" property. That's
> would be the best temp solution as it avoids breaking the original design of
> both the TraceNoC AMBA driver and interconnect TraceNoC platform driver.
Before proceeding with the "arm,primecell-periphid" property, could you
clarify a bit:
- For an interconnect TraceNoC, what would be the consequence of
enabling ATID? Would it simply be a no-op, or are there any side
effects? Or is the concern that the trace IDs could be exhausted?
- How can you guarantee that a interconnect TraceNoC will never
require ATID in the future?
> The TraceNoC device here must be treated as an AMBA device and I am
> continuing to investigate the issue with our hardware team.
> We aim to fix it from hardware perspetive for existing platforms if possible
> and ensure it is fixed in future platforms.
I'm concerned that all of use end up repeatedly fixing similar issues
whenever hardware configurations change or modules are reused in
different topologies.
For example, if future platforms may require ATID support for an
interconnect TraceNoC, then the issue will pop up again.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH 00/13] treewide: replace linux/gpio.h
From: Arnd Bergmann @ 2026-06-29 14:24 UTC (permalink / raw)
To: Andreas Schwab, Arnd Bergmann
Cc: open list:GPIO SUBSYSTEM, Bartosz Golaszewski, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Frank Li, Robert Jarzmik,
Krzysztof Kozlowski, Greg Ungerer, Thomas Bogendoerfer,
Hauke Mehrtens, Rafał Miłecki, Yoshinori Sato,
John Paul Adrian Glaubitz, Linus Walleij, Dmitry Torokhov,
Jakub Kicinski, Paolo Abeni, Dominik Brodowski, linux-kernel,
linux-arm-kernel, linux-samsung-soc, patches, linux-m68k,
linux-mips, linux-sh, linux-input, linux-media, Netdev,
linux-sunxi, linux-phy, linux-rockchip, linux-sound
In-Reply-To: <mvmik71win7.fsf@suse.de>
On Mon, Jun 29, 2026, at 16:01, Andreas Schwab wrote:
> On Jun 29 2026, Arnd Bergmann wrote:
>
>> From: Arnd Bergmann <arnd@arndb.de>
>>
>> The linux/gpio.h header used to be the global definition for the gpio
>> interfaces, with 1100 users back in linux-3.17. In linux-7.2, only about
>> 130 of those remain, so this series cleans out the rest.
>>
>> In each subsystem, we can replace the header either with
>> linux/gpio/consumer.h for users of the modern gpio descriptor interface,
>
> A few of them already used <linux/gpio/consumer.h>, and is duplicated
> now.
Indeed, I have removed the extra ones now and folded those into
the patches.
Arnd
diff --git a/drivers/gpib/gpio/gpib_bitbang.c b/drivers/gpib/gpio/gpib_bitbang.c
index 2e8d895db06a..34d14b94a0b8 100644
--- a/drivers/gpib/gpio/gpib_bitbang.c
+++ b/drivers/gpib/gpio/gpib_bitbang.c
@@ -64,7 +64,6 @@
#include <linux/gpio/consumer.h>
#include <linux/gpio/driver.h>
#include <linux/gpio/machine.h>
-#include <linux/gpio/consumer.h>
#include <linux/irq.h>
static int sn7516x_used = 1, sn7516x;
diff --git a/drivers/input/keyboard/matrix_keypad.c b/drivers/input/keyboard/matrix_keypad.c
index 98d0269a978f..8863b741d1a3 100644
--- a/drivers/input/keyboard/matrix_keypad.c
+++ b/drivers/input/keyboard/matrix_keypad.c
@@ -16,7 +16,6 @@
#include <linux/interrupt.h>
#include <linux/jiffies.h>
#include <linux/module.h>
-#include <linux/gpio/consumer.h>
#include <linux/input/matrix_keypad.h>
#include <linux/slab.h>
#include <linux/of.h>
diff --git a/drivers/input/misc/soc_button_array.c b/drivers/input/misc/soc_button_array.c
index eb11bf2e9436..a6c984205123 100644
--- a/drivers/input/misc/soc_button_array.c
+++ b/drivers/input/misc/soc_button_array.c
@@ -15,7 +15,6 @@
#include <linux/dmi.h>
#include <linux/gpio/consumer.h>
#include <linux/gpio_keys.h>
-#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
static bool use_low_level_irq;
diff --git a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
index 88c5c52e0e38..5f5adc9c9e83 100644
--- a/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/ethernet/oki-semi/pch_gbe/pch_gbe_main.c
@@ -16,7 +16,6 @@
#include <linux/net_tstamp.h>
#include <linux/ptp_classify.h>
#include <linux/ptp_pch.h>
-#include <linux/gpio/consumer.h>
#define PCH_GBE_MAR_ENTRIES 16
#define PCH_GBE_SHORT_PKT 64
diff --git a/drivers/net/phy/mdio_device.c b/drivers/net/phy/mdio_device.c
index a18263d5bb02..06151f207134 100644
--- a/drivers/net/phy/mdio_device.c
+++ b/drivers/net/phy/mdio_device.c
@@ -9,7 +9,6 @@
#include <linux/delay.h>
#include <linux/errno.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/kernel.h>
diff --git a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
index d9c06129ed23..171bf097a8b8 100644
--- a/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
+++ b/drivers/phy/broadcom/phy-bcm-ns2-usbdrd.c
@@ -4,7 +4,6 @@
#include <linux/delay.h>
#include <linux/extcon-provider.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
diff --git a/drivers/phy/ti/phy-j721e-wiz.c b/drivers/phy/ti/phy-j721e-wiz.c
index 2233babc0078..1f5dba49ace4 100644
--- a/drivers/phy/ti/phy-j721e-wiz.c
+++ b/drivers/phy/ti/phy-j721e-wiz.c
@@ -12,7 +12,6 @@
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/io.h>
#include <linux/module.h>
#include <linux/mfd/syscon.h>
diff --git a/include/linux/mfd/ti-lmu.h b/include/linux/mfd/ti-lmu.h
index 5040c7d1e1b9..2089ec5124e8 100644
--- a/include/linux/mfd/ti-lmu.h
+++ b/include/linux/mfd/ti-lmu.h
@@ -10,7 +10,6 @@
#ifndef __MFD_TI_LMU_H__
#define __MFD_TI_LMU_H__
-#include <linux/gpio/consumer.h>
#include <linux/notifier.h>
#include <linux/regmap.h>
#include <linux/gpio/consumer.h>
diff --git a/sound/soc/codecs/cs42l84.c b/sound/soc/codecs/cs42l84.c
index 36c3abc21fed..f2448b4c11fc 100644
--- a/sound/soc/codecs/cs42l84.c
+++ b/sound/soc/codecs/cs42l84.c
@@ -16,7 +16,6 @@
#include <linux/init.h>
#include <linux/delay.h>
#include <linux/i2c.h>
-#include <linux/gpio/consumer.h>
#include <linux/regmap.h>
#include <linux/slab.h>
#include <linux/acpi.h>
diff --git a/sound/soc/codecs/dmic.c b/sound/soc/codecs/dmic.c
index 8b05d6f9b429..cbed11136935 100644
--- a/sound/soc/codecs/dmic.c
+++ b/sound/soc/codecs/dmic.c
@@ -7,7 +7,6 @@
#include <linux/delay.h>
#include <linux/gpio/consumer.h>
-#include <linux/gpio/consumer.h>
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/slab.h>
^ permalink raw reply related
* [PATCH] clk: mediatek: fix memory leak on module removal
From: Akari Tsuyukusa @ 2026-06-29 14:23 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Matthias Brugger,
AngeloGioacchino Del Regno, Chen-Yu Tsai, Miles Chen
Cc: Akari Tsuyukusa, open list:COMMON CLK FRAMEWORK,
open list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support,
moderated list:ARM/Mediatek SoC support
Some MediaTek clock drivers do not call platform_set_drvdata() during
probe(), but their remove() callback calls platform_get_drvdata(). This
results in platform_get_drvdata() returning NULL, which leads to calling
mtk_free_clk_data(NULL) -> kfree(NULL).
Therefore, the actual clk_data is never released, causing a memory leak.
Fix this by calling platform_set_drvdata() during probe.
Fixes: 124294ff468f ("clk: mediatek: mt8192: Move apmixedsys clock driver to its own file")
Fixes: 4c02c9af3cb9 ("clk: mediatek: mt8173: Break down clock drivers and allow module build")
Fixes: 54b7026f011e ("clk: mediatek: mt8135-apmixedsys: Convert to platform_driver and module")
Fixes: c50e2ea6507b ("clk: mediatek: mt7622-apmixedsys: Add .remove() callback for module build")
Fixes: 0d363282bb0c ("clk: mediatek: Add MediaTek Helio X10 MT6795 clock drivers")
Fixes: c6368ce86435 ("clk: mediatek: mt2712-apmixedsys: Add .remove() callback for module build")
Fixes: 838b86331c5e ("clk: mediatek: mt7622: Move infracfg to clk-mt7622-infracfg.c")
Signed-off-by: Akari Tsuyukusa <akkun11.open@gmail.com>
---
drivers/clk/mediatek/clk-mt2712-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt6795-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt6795-infracfg.c | 1 +
drivers/clk/mediatek/clk-mt6795-pericfg.c | 1 +
drivers/clk/mediatek/clk-mt7622-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt7622-infracfg.c | 1 +
drivers/clk/mediatek/clk-mt8135-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt8173-apmixedsys.c | 1 +
drivers/clk/mediatek/clk-mt8173-infracfg.c | 1 +
drivers/clk/mediatek/clk-mt8192-apmixedsys.c | 1 +
10 files changed, 10 insertions(+)
diff --git a/drivers/clk/mediatek/clk-mt2712-apmixedsys.c b/drivers/clk/mediatek/clk-mt2712-apmixedsys.c
index 54b18e9f83f8..24522fc24019 100644
--- a/drivers/clk/mediatek/clk-mt2712-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt2712-apmixedsys.c
@@ -129,6 +129,7 @@ static int clk_mt2712_apmixed_probe(struct platform_device *pdev)
goto unregister_plls;
}
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_plls:
diff --git a/drivers/clk/mediatek/clk-mt6795-apmixedsys.c b/drivers/clk/mediatek/clk-mt6795-apmixedsys.c
index 123d5d7fea85..b607592a7c37 100644
--- a/drivers/clk/mediatek/clk-mt6795-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt6795-apmixedsys.c
@@ -175,6 +175,7 @@ static int clk_mt6795_apmixed_probe(struct platform_device *pdev)
dev_dbg(dev, "Performing initial setup for MD1\n");
clk_mt6795_apmixed_setup_md1(base);
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_ref2usb:
diff --git a/drivers/clk/mediatek/clk-mt6795-infracfg.c b/drivers/clk/mediatek/clk-mt6795-infracfg.c
index e4559569f5b0..12146bb3b726 100644
--- a/drivers/clk/mediatek/clk-mt6795-infracfg.c
+++ b/drivers/clk/mediatek/clk-mt6795-infracfg.c
@@ -116,6 +116,7 @@ static int clk_mt6795_infracfg_probe(struct platform_device *pdev)
if (ret)
goto unregister_cpumuxes;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_cpumuxes:
diff --git a/drivers/clk/mediatek/clk-mt6795-pericfg.c b/drivers/clk/mediatek/clk-mt6795-pericfg.c
index d48240eb2a67..28faeb2e657a 100644
--- a/drivers/clk/mediatek/clk-mt6795-pericfg.c
+++ b/drivers/clk/mediatek/clk-mt6795-pericfg.c
@@ -125,6 +125,7 @@ static int clk_mt6795_pericfg_probe(struct platform_device *pdev)
if (ret)
goto unregister_composites;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_composites:
diff --git a/drivers/clk/mediatek/clk-mt7622-apmixedsys.c b/drivers/clk/mediatek/clk-mt7622-apmixedsys.c
index 8a29eaab0cfc..a9fc2e5536b3 100644
--- a/drivers/clk/mediatek/clk-mt7622-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt7622-apmixedsys.c
@@ -109,6 +109,7 @@ static int clk_mt7622_apmixed_probe(struct platform_device *pdev)
if (ret)
goto unregister_gates;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_gates:
diff --git a/drivers/clk/mediatek/clk-mt7622-infracfg.c b/drivers/clk/mediatek/clk-mt7622-infracfg.c
index cfdf3b07c3e0..b44baf521d2f 100644
--- a/drivers/clk/mediatek/clk-mt7622-infracfg.c
+++ b/drivers/clk/mediatek/clk-mt7622-infracfg.c
@@ -90,6 +90,7 @@ static int clk_mt7622_infracfg_probe(struct platform_device *pdev)
if (ret)
goto unregister_cpumuxes;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_cpumuxes:
diff --git a/drivers/clk/mediatek/clk-mt8135-apmixedsys.c b/drivers/clk/mediatek/clk-mt8135-apmixedsys.c
index 19e4ee489ec3..41e5cfbcbb76 100644
--- a/drivers/clk/mediatek/clk-mt8135-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8135-apmixedsys.c
@@ -66,6 +66,7 @@ static int clk_mt8135_apmixed_probe(struct platform_device *pdev)
if (ret)
goto unregister_plls;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_plls:
diff --git a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
index d7d416172ab3..fe36d2eac3da 100644
--- a/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8173-apmixedsys.c
@@ -179,6 +179,7 @@ static int clk_mt8173_apmixed_probe(struct platform_device *pdev)
if (r)
goto unregister_ref2usb;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_ref2usb:
diff --git a/drivers/clk/mediatek/clk-mt8173-infracfg.c b/drivers/clk/mediatek/clk-mt8173-infracfg.c
index fa2d1d557e04..b923b73c64f6 100644
--- a/drivers/clk/mediatek/clk-mt8173-infracfg.c
+++ b/drivers/clk/mediatek/clk-mt8173-infracfg.c
@@ -128,6 +128,7 @@ static int clk_mt8173_infracfg_probe(struct platform_device *pdev)
if (r)
goto unregister_clk_hw;
+ platform_set_drvdata(pdev, clk_data);
return 0;
unregister_clk_hw:
diff --git a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
index b0563a285bd6..446c55b77777 100644
--- a/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt8192-apmixedsys.c
@@ -176,6 +176,7 @@ static int clk_mt8192_apmixed_probe(struct platform_device *pdev)
if (r)
goto unregister_gates;
+ platform_set_drvdata(pdev, clk_data);
return r;
unregister_gates:
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v3] irqchip/gic-v3-its: Fix OF node reference leak
From: Zenghui Yu @ 2026-06-29 12:19 UTC (permalink / raw)
To: Yuho Choi; +Cc: Marc Zyngier, Thomas Gleixner, linux-arm-kernel
In-Reply-To: <20260628220723.1699972-1-dbgh9129@gmail.com>
On 6/29/26 6:07 AM, Yuho Choi wrote:
> of_get_cpu_node() returns a referenced device node. In
> its_cpu_init_collection(), the Cavium 23144 workaround only uses the
> node to compare the CPU NUMA node, but the reference is never dropped.
>
> Use the device_node cleanup helper for the CPU node reference so it is
> released when leaving the workaround block, including the NUMA mismatch
> return path.
>
> Fixes: fbf8f40e1658 ("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144")
> Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
> Acked-by: Marc Zyngier <maz@kernel.org>
> ---
> Changes in v3:
> - Keep the __free(device_node) assignment on a single line.
> - Fix indentation in the Cavium 23144 workaround block.
> - Add Marc's Acked-by.
> Changes in v2:
> - Use __free(device_node) for the CPU node reference.
> - Correct the Fixes tag to fbf8f40e1658.
> drivers/irqchip/irq-gic-v3-its.c | 6 ++----
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index b57d81ad33a0..6f5811aae59c 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3290,11 +3290,9 @@ static void its_cpu_init_collection(struct its_node *its)
>
> /* avoid cross node collections and its mapping */
> if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
> - struct device_node *cpu_node;
> + struct device_node *cpu_node __free(device_node) = of_get_cpu_node(cpu, NULL);
>
> - cpu_node = of_get_cpu_node(cpu, NULL);
> - if (its->numa_node != NUMA_NO_NODE &&
> - its->numa_node != of_node_to_nid(cpu_node))
> + if (its->numa_node != NUMA_NO_NODE && its->numa_node != of_node_to_nid(cpu_node))
> return;
> }
Reviewed-by: Zenghui Yu (Huawei) <zenghui.yu@linux.dev>
Thanks,
Zenghui
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox