* Re: [PATCH] clocksource/drivers/owl: fix refcount leak
From: Markus Elfring @ 2026-05-21 12:10 UTC (permalink / raw)
To: Alexander A. Klimov, linux-actions, linux-arm-kernel,
Andreas Färber, Daniel Lezcano, Manivannan Sadhasivam,
Thomas Gleixner
Cc: LKML
In-Reply-To: <20260521041901.542964-1-grandmaster@al2klimov.de>
> Every value returned from of_clk_get() is supposed to be cleaned up
> via clk_put() once not needed anymore.
How do you think about to add a wording like “Thus add a missing function call.”?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.1-rc4#n94
Would the application of another guard become helpful?
How will chances evolve to adjust variable scopes accordingly?
https://elixir.bootlin.com/linux/v7.1-rc4/source/drivers/clocksource/timer-owl.c#L116-L173
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 2/2] kselftest/arm64: Add test for atomic futex uaccess with POE
From: Mark Brown @ 2026-05-21 12:06 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, Catalin Marinas, Joey Gouly, Shuah Khan,
Will Deacon, linux-kernel, linux-kselftest
In-Reply-To: <c140c0da-4ad7-48ed-ad83-663ada282b14@arm.com>
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
On Thu, May 21, 2026 at 02:01:17PM +0200, Kevin Brodsky wrote:
> On 21/05/2026 13:22, Mark Brown wrote:
> > Doesn't matter while there's only one test but we should probably
> > munmap() this when we're done.
> Fair enough, I was being lazy :) A pkey_free() is also in order to be
> comprehensive, another wrapper to add. I considered using
> ../../mm/pkey-helpers.h but helpers there aren't implemented inline...
> Maybe refactoring for later.
There was another thread librifying the GUP helpers which might be a
good model:
https://lore.kernel.org/linux-mm/20260521111801.173019-1-sarthak.sharma@arm.com/T/#t
I'm always a bit nervous about peering inside other selftest
directories, it can work well but some instances of it are relatively
frequent sources of regressions as people working in the main directory
don't think about users in other directories when doing updates.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND v3 1/6] drm/connector: report IRQ_HPD events to drm_connector_oob_hotplug_event()
From: Dmitry Baryshkov @ 2026-05-21 12:05 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Heikki Krogerus, Greg Kroah-Hartman, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Adrien Grassein, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Tomi Valkeinen,
Bjorn Andersson, Konrad Dybcio, Pengyu Luo, Nikita Travkin,
Yongxing Mou, dri-devel, linux-kernel, linux-usb, intel-gfx,
intel-xe, linux-amlogic, linux-arm-kernel, linux-arm-msm,
freedreno
In-Reply-To: <20260521-funny-astonishing-mackerel-cc5a01@penduick>
On Thu, May 21, 2026 at 09:47:29AM +0200, Maxime Ripard wrote:
> On Wed, May 13, 2026 at 09:23:21PM +0300, Dmitry Baryshkov wrote:
> > The DisplayPort standard defines a special kind of events called IRQ.
> > These events are used to notify DP Source about the events on the Sink
> > side. It is extremely important for DP MST handling, where the MST
> > events are reported through this IRQ.
> >
> > In case of the USB-C DP AltMode there is no actual HPD pulse, but the
> > events are ported through the bits in the AltMode VDOs.
> >
> > Extend the drm_connector_oob_hotplug_event() interface and report IRQ
> > events to the DisplayPort Sink drivers.
> >
> > Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> > ---
> > drivers/gpu/drm/drm_connector.c | 5 ++++-
> > drivers/usb/typec/altmodes/displayport.c | 15 +++++++++++----
> > include/drm/drm_connector.h | 19 ++++++++++++++++++-
> > 3 files changed, 33 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> > index 47dc53c4a738..edee9daccd51 100644
> > --- a/drivers/gpu/drm/drm_connector.c
> > +++ b/drivers/gpu/drm/drm_connector.c
> > @@ -3510,6 +3510,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> > * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to connector
> > * @connector_fwnode: fwnode_handle to report the event on
> > * @status: hot plug detect logical state
> > + * @extra_status: additional information provided by the sink without changing
> > + * the HPD state (or in addition to such a change).
> > *
> > * On some hardware a hotplug event notification may come from outside the display
> > * driver / device. An example of this is some USB Type-C setups where the hardware
> > @@ -3520,7 +3522,8 @@ struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
> > * a drm_connector reference through calling drm_connector_find_by_fwnode().
> > */
> > void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode,
> > - enum drm_connector_status status)
> > + enum drm_connector_status status,
> > + enum drm_connector_status_extra extra_status)
> > {
> > struct drm_connector *connector;
> >
> > diff --git a/drivers/usb/typec/altmodes/displayport.c b/drivers/usb/typec/altmodes/displayport.c
> > index 35d9c3086990..7182a8e2e710 100644
> > --- a/drivers/usb/typec/altmodes/displayport.c
> > +++ b/drivers/usb/typec/altmodes/displayport.c
> > @@ -189,7 +189,9 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
> > } else {
> > drm_connector_oob_hotplug_event(dp->connector_fwnode,
> > hpd ? connector_status_connected :
> > - connector_status_disconnected);
> > + connector_status_disconnected,
> > + (hpd && irq_hpd) ? DRM_CONNECTOR_DP_IRQ_HPD :
> > + DRM_CONNECTOR_NO_EXTRA_STATUS);
>
> Since the extra status itself, and what the options mean, are DP specific, do we really want to
> extend drm_connector_oob_hotplug_event()? I think I'd prefer to have a DP specific variant, with its
> own set of parameters.
I can try arguing that drm_connector_oob_hotplug_event() is DP-specific,
there are no other users for it, only the DP AltMode driver.
Anyway, do you just mean new API here or new API and a new connector
callback?
--
With best wishes
Dmitry
^ permalink raw reply
* RE: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Carlos Song (OSS) @ 2026-05-21 12:02 UTC (permalink / raw)
To: Mukesh Savaliya, Carlos Song (OSS), o.rempel@pengutronix.de,
kernel@pengutronix.de, andi.shyti@kernel.org, Frank Li,
s.hauer@pengutronix.de, festevam@gmail.com, Carlos Song,
Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <ab96c900-9c77-455a-88f1-b6d8d8e4ff78@oss.qualcomm.com>
> -----Original Message-----
> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
> Sent: Thursday, May 21, 2026 7:14 PM
> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>; Mukesh Savaliya
> <mukesh.savaliya@oss.qualcomm.com>; o.rempel@pengutronix.de;
> kernel@pengutronix.de; andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> stable@vger.kernel.org
> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered
> down
>
>
> On 5/21/2026 4:21 PM, Carlos Song (OSS) wrote:
>
> [...]
>
> >>>> -----Original Message-----
> >>>> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
> >>>> Sent: Thursday, May 21, 2026 3:40 PM
> >>>> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>;
> >>>> o.rempel@pengutronix.de; kernel@pengutronix.de;
> >>>> andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
> >>>> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
> >>>> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> >>>> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> >>>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> >>>> stable@vger.kernel.org
> >>>> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is
> >>>> powered down
> >>>>
> >>>> Hi Carlos,
> >>>>
> >>>> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
> >>>>> From: Carlos Song <carlos.song@nxp.com>
> >>>>>
> >>>>> Mark the I2C adapter as suspended during system suspend to block
> >>>>> further transfers, and resume it on system resume. This prevents
> >>>>> potential hangs when the hardware is powered down but clients
> >>>>> still attempt
> >>>> I2C transfers.
> >>>>>
> >> what was the reason of this hang ? I was thinking you don't have
> >> interrupts working when client requested transfer but adapter was
> >> suspended. Please correct me if wrong.
> >>
> >> And it would be good to mention the actual problem and why/how it
> occurred.
> >>>> Code changes looks fine to me but have comment on commit log.
> >>>>
> >>>> It seems, you are adding support of _noirq() callbacks to allow
> >>>> transfers during suspend/resume noirq phase of PM.
> >>>>
> >>>> Would it make sense if you can write "Replace system PM callbacks
> >>>> with noirq PM callbacks" OR "Allow transfers during _noirq phase of
> >>>> the PM ops" instead of "mark I2C adapter when hardware is powered
> >> down" ?
> >>>>
> >>>
> >>> Hi,
> >>>
> >>> Thank you for your comments!
> >>>
> >>> But this patch is added is not for support noirq PM callback or
> >>> transfer in noirq
> >> phase.
> >>>
> >> Okay, may be actual problem description can help me.
> >>> In fact, this fix is to mark the I2C adapter as suspended during
> >>> system noirq suspend to block further transfers, and resume it on
> >>> system noirq resume. This is to prohibit I2C device calling the I2C
> >>> controller after the system noirq suspend and before noirq resume,
> >>> because at
> >> this time the I2C instance is powered off or the clock is disabled
> >> ... So I want to keep current commit. How do you think?
> >> completely Makes sense. Please help add how this problem occurred and
> why ?
> >> So the change/fix will be good to understand against it.
> >
> > Hi,
> >
> > In some I.MX platform, some I2C devices will keep a work queue all
> > time, the work queue will trigger I2C xfer every once in a while, but the work
> queue shouldn't be free in system suspend.
> >
>
> work queue has transfers queued even if system is suspended ? IMO, the client
> i2c devices should not let system go to suspend.
>
Hi Mukesh,
Thank you for the detailed discussion.
Yes, I totally agree that I2C client drivers should ideally stop
issuing transfers when the system is suspending.
However, in practice there are many different I2C clients, and not all
of them strictly adhere to this requirement. Some clients may still
trigger transfers through workqueues or deferred contexts during the
suspend/resume window.
Therefore, adding this protection at the I2C controller side helps to
avoid unexpected accesses when the hardware resources are unavailable,
making the system more robust.
> > Within a very short time window, possibly from noirq_suspend to the
> > system actually being suspended, or possibly from the system starting
> > to resume to before noirq_resume, this work queue will trigger an I2C
> > transfer, and at this time the I2C controller's clk and pinctrl have
> > not yet been restored, reading and
>
> Right, this kind of explains the problem to me. I think you are trying to serve
> i2c transfers when your resources(clk, pinctrl) are not turned ON and also
> interrupt remains disabled. And that's why you need to add
> _noir() PM callbacks supports along with IRQF_NO_SUSPEND |
> IRQF_EARLY_RESUME flags.
>
> > writing I2C registers causes the system to hang. This patch make all
> > I2C operations are performed in a safe hardware state.
> >
> > Is it better if I add these comment to patch commit log?
> >>>
> if my latest comments makes sense against the issue, you may write
> accordingly. if i am wrong, then your explanation makes sense. Cause of the
> hang needs to be clearly mention int the commit log in your next patch.
>
Based on our discussion, I have updated the commit log as below:
On some i.MX platforms, certain I2C client drivers keep a periodic
workqueue which continues to trigger I2C transfers.
During system suspend/resume, there exists a time window between:
- noirq_suspend and full suspend
- resume start and noirq_resume
In this window, the I2C controller resources such as clock and pinctrl
may already be disabled or not yet restored.
If a workqueue triggers an I2C transfer in this period, the driver
attempts to access I2C registers while the hardware resources are
unavailable, which may lead to system hang.
Mark the I2C adapter as suspended during noirq suspend and block new
transfers until resume, ensuring that I2C transfers are only issued
when hardware resources are available.
Does this look good to you?
> >>
> >
^ permalink raw reply
* Re: [PATCH 2/2] kselftest/arm64: Add test for atomic futex uaccess with POE
From: Kevin Brodsky @ 2026-05-21 12:01 UTC (permalink / raw)
To: Mark Brown
Cc: linux-arm-kernel, Catalin Marinas, Joey Gouly, Shuah Khan,
Will Deacon, linux-kernel, linux-kselftest
In-Reply-To: <8fc7713d-6451-4f05-86cd-df833cedd94b@sirena.org.uk>
On 21/05/2026 13:22, Mark Brown wrote:
> On Thu, May 21, 2026 at 10:42:31AM +0100, Kevin Brodsky wrote:
>
>> Add a new test to ensure that atomic futex uaccess succeeds on
>> memory mapped with a non-default POIndex/pkey.
>> + ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
>> + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>> + ASSERT_NE(ptr, MAP_FAILED);
> Doesn't matter while there's only one test but we should probably
> munmap() this when we're done.
Fair enough, I was being lazy :) A pkey_free() is also in order to be
comprehensive, another wrapper to add. I considered using
../../mm/pkey-helpers.h but helpers there aren't implemented inline...
Maybe refactoring for later.
- Kevin
^ permalink raw reply
* Re: [PATCH v4 13/13] x86/amd-gart: preserve the direct DMA address until GART mapping succeeds
From: Aneesh Kumar K.V @ 2026-05-21 11:54 UTC (permalink / raw)
To: iommu, linux-arm-kernel, linux-kernel, linux-coco
Cc: Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Jason Gunthorpe, Mostafa Saleh, Petr Tesarik,
Alexey Kardashevskiy, Dan Williams, Xu Yilun, linuxppc-dev,
linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260512090408.794195-14-aneesh.kumar@kernel.org>
"Aneesh Kumar K.V (Arm)" <aneesh.kumar@kernel.org> writes:
> gart_alloc_coherent() first allocates memory through dma_direct_alloc(),
> which returns a direct-mapped DMA address in dma_addr. When force_iommu is
> enabled, the buffer is then remapped.
>
> Do not overwrite dma_addr before dma_map_area() has succeeded. Keep the
> dma_map_area result in a temporary variable so the direct DMA address
> remains available for dma_direct_free() on the error path.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
> arch/x86/kernel/amd_gart_64.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c
> index b5f1f031d45b..a109649c5649 100644
> --- a/arch/x86/kernel/amd_gart_64.c
> +++ b/arch/x86/kernel/amd_gart_64.c
> @@ -467,18 +467,20 @@ gart_alloc_coherent(struct device *dev, size_t size, dma_addr_t *dma_addr,
> gfp_t flag, unsigned long attrs)
> {
> void *vaddr;
> + dma_addr_t dma_map_addr;
>
> vaddr = dma_direct_alloc(dev, size, dma_addr, flag, attrs);
> if (!vaddr ||
> !force_iommu || dev->coherent_dma_mask <= DMA_BIT_MASK(24))
> return vaddr;
>
> - *dma_addr = dma_map_area(dev, virt_to_phys(vaddr), size,
> - DMA_BIDIRECTIONAL,
> - (1UL << get_order(size)) - 1, attrs);
> + dma_map_addr = dma_map_area(dev, virt_to_phys(vaddr), size,
> + DMA_BIDIRECTIONAL,
> + (1UL << get_order(size)) - 1, attrs);
> flush_gart();
> - if (unlikely(*dma_addr == DMA_MAPPING_ERROR))
> + if (unlikely(dma_map_addr == DMA_MAPPING_ERROR))
> goto out_free;
> + *dma_addr = dma_map_addr;
> return vaddr;
> out_free:
> dma_direct_free(dev, size, vaddr, *dma_addr, attrs);
> --
> 2.43.0
>
This needs corresponding changes on the gart_free_coherent() side as well.
https://sashiko.dev/#/patchset/20260512090408.794195-1-aneesh.kumar%40kernel.org?part=13
I will avoid making that change as part of this series, since I assume
it would require specific testing.
-aneesh
^ permalink raw reply
* Re: [PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for i.MX93
From: Alexander Stein @ 2026-05-21 11:52 UTC (permalink / raw)
To: Michael Riesch, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Laurent Pinchart, Frank Li, Sakari Ailus, Bryan O'Donoghue,
Mehdi Djait, Hans Verkuil, G.N. Zhou (OSS), G.N. Zhou (OSS)
Cc: linux-media@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-rockchip@lists.infradead.org, G.N. Zhou (OSS)
In-Reply-To: <AS8PR04MB9080D3B1A6B522F3F9342E23FA0E2@AS8PR04MB9080.eurprd04.prod.outlook.com>
Hi,
thanks for the replay.
Am Donnerstag, 21. Mai 2026, 11:29:39 CEST schrieb G.N. Zhou (OSS):
> Hi Alexander,
>
> > -----Original Message-----
> > From: Alexander Stein <alexander.stein@ew.tq-group.com>
> > Sent: Wednesday, May 20, 2026 7:12 PM
> > To: Michael Riesch <michael.riesch@collabora.com>; Mauro Carvalho Chehab
> > <mchehab@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
> > <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Heiko Stuebner
> > <heiko@sntech.de>; Laurent Pinchart <laurent.pinchart@ideasonboard.com>;
> > Frank Li <frank.li@nxp.com>; Sakari Ailus <sakari.ailus@linux.intel.com>; Bryan
> > O'Donoghue <bryan.odonoghue@linaro.org>; Mehdi Djait
> > <mehdi.djait@linux.intel.com>; Hans Verkuil <hverkuil+cisco@kernel.org>;
> > G.N. Zhou (OSS) <guoniu.zhou@oss.nxp.com>
> > Cc: linux-media@vger.kernel.org; linux-kernel@vger.kernel.org;
> > devicetree@vger.kernel.org; imx@lists.linux.dev; linux-arm-
> > kernel@lists.infradead.org; linux-rockchip@lists.infradead.org; G.N. Zhou (OSS)
> > <guoniu.zhou@oss.nxp.com>
> > Subject: Re: [PATCH v4 4/6] media: synopsys: Add PHY stopstate wait for
> > i.MX93
> >
> > Hi,
> >
> > Am Dienstag, 19. Mai 2026, 04:07:41 CEST schrieb Guoniu Zhou:
> > > Implement waiting for D-PHY lanes to enter stop state on i.MX93. This
> > > ensures proper PHY initialization by verifying that the clock lane and
> > > all active data lanes have entered the stop state before proceeding
> > > with further operations.
> > >
> > > Reviewed-by: Frank Li <Frank.Li@nxp.com>
> > > Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> > > ---
> > > Changes in v2:
> > > - Removes redundant register availability check
> > > - Uses read_poll_timeout() with dw_mipi_csi2rx_read() instead of
> > > readl_poll_timeout() with direct register address
> > > - Fixes stopstate condition logic
> > > - Check PHY stopstate after sensor enable instead of before to ensure
> > > correct timing.
> > > - Optimize PHY stopstate polling parameters (1000us->10us, 2s->1ms) to
> > > balance performance and responsiveness.
> > > ---
> > > drivers/media/platform/synopsys/dw-mipi-csi2rx.c | 36
> > > ++++++++++++++++++++++++
> > > 1 file changed, 36 insertions(+)
> > >
> > > diff --git a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> > > b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> > > index 92178a3dec5d..8a34aec550ad 100644
> > > --- a/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> > > +++ b/drivers/media/platform/synopsys/dw-mipi-csi2rx.c
> > > @@ -11,6 +11,7 @@
> > > #include <linux/clk.h>
> > > #include <linux/delay.h>
> > > #include <linux/io.h>
> > > +#include <linux/iopoll.h>
> > > #include <linux/module.h>
> > > #include <linux/of.h>
> > > #include <linux/phy/phy.h>
> > > @@ -35,6 +36,8 @@
> > > #define DW_REG_EXIST BIT(31)
> > > #define DW_REG(x) (DW_REG_EXIST | (x))
> > >
> > > +#define DPHY_STOPSTATE_CLK_LANE BIT(16)
> > > +
> > > #define DPHY_TEST_CTRL0_TEST_CLR BIT(0)
> > >
> > > #define IPI_VCID_VC(x) FIELD_PREP(GENMASK(1, 0),
> > (x))
> > > @@ -65,6 +68,7 @@ enum dw_mipi_csi2rx_regs_index {
> > > DW_MIPI_CSI2RX_PHY_TST_CTRL0,
> > > DW_MIPI_CSI2RX_PHY_TST_CTRL1,
> > > DW_MIPI_CSI2RX_PHY_SHUTDOWNZ,
> > > + DW_MIPI_CSI2RX_PHY_STOPSTATE,
> > > DW_MIPI_CSI2RX_IPI_DATATYPE,
> > > DW_MIPI_CSI2RX_IPI_MEM_FLUSH,
> > > DW_MIPI_CSI2RX_IPI_MODE,
> > > @@ -87,6 +91,7 @@ struct dw_mipi_csi2rx_drvdata {
> > > void (*dphy_assert_reset)(struct dw_mipi_csi2rx_device *csi2);
> > > void (*dphy_deassert_reset)(struct dw_mipi_csi2rx_device *csi2);
> > > void (*ipi_enable)(struct dw_mipi_csi2rx_device *csi2);
> > > + int (*wait_for_phy_stopstate)(struct dw_mipi_csi2rx_device *csi2);
> > > };
> > >
> > > struct dw_mipi_csi2rx_format {
> > > @@ -139,6 +144,7 @@ static const u32 imx93_regs[DW_MIPI_CSI2RX_MAX]
> > = {
> > > [DW_MIPI_CSI2RX_PHY_SHUTDOWNZ] = DW_REG(0x40),
> > > [DW_MIPI_CSI2RX_DPHY_RSTZ] = DW_REG(0x44),
> > > [DW_MIPI_CSI2RX_PHY_STATE] = DW_REG(0x48),
> > > + [DW_MIPI_CSI2RX_PHY_STOPSTATE] = DW_REG(0x4c),
> > > [DW_MIPI_CSI2RX_PHY_TST_CTRL0] = DW_REG(0x50),
> > > [DW_MIPI_CSI2RX_PHY_TST_CTRL1] = DW_REG(0x54),
> > > [DW_MIPI_CSI2RX_IPI_MODE] = DW_REG(0x80), @@ -556,10 +562,19
> > @@
> > > static int dw_mipi_csi2rx_enable_streams(struct v4l2_subdev *sd,
> > > if (ret)
> > > goto err_csi_stop;
> > >
> > > + if (!csi2->enabled_streams &&
> > > + csi2->drvdata->wait_for_phy_stopstate) {
> > > + ret = csi2->drvdata->wait_for_phy_stopstate(csi2);
> > > + if (ret)
> > > + goto err_disable_streams;
> > > + }
> > > +
> > > csi2->enabled_streams |= streams_mask;
> > >
> > > return 0;
> > >
> > > +err_disable_streams:
> > > + v4l2_subdev_disable_streams(remote_sd, remote_pad->index, mask);
> > > err_csi_stop:
> > > /* Stop CSI hardware if no streams are enabled */
> > > if (!csi2->enabled_streams)
> > > @@ -871,11 +886,32 @@ static void imx93_csi2rx_dphy_ipi_enable(struct
> > dw_mipi_csi2rx_device *csi2)
> > > dw_mipi_csi2rx_write(csi2, DW_MIPI_CSI2RX_IPI_MODE, val); }
> > >
> > > +static int imx93_csi2rx_wait_for_phy_stopstate(struct
> > > +dw_mipi_csi2rx_device *csi2) {
> > > + struct device *dev = csi2->dev;
> > > + u32 stopstate_mask;
> > > + u32 val;
> > > + int ret;
> > > +
> > > + stopstate_mask = DPHY_STOPSTATE_CLK_LANE | GENMASK(csi2-
> > >lanes_num -
> > > +1, 0);
> > > +
> > > + ret = read_poll_timeout(dw_mipi_csi2rx_read, val,
> > > + (val & stopstate_mask) == stopstate_mask,
> > > + 10, 1000, true,
> > > + csi2, DW_MIPI_CSI2RX_PHY_STOPSTATE);
> > > + if (ret)
> > > + dev_err(dev, "lanes are not in stop state: %#x,
> > expected %#x\n",
> > > + val, stopstate_mask);
> >
> > Did you actually test this on imx93? I'm trying to get my imx327 sensor to run,
> > but only run into this error message:
> > dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected
> > 0x10003
>
> Thanks for testing. Regarding the lane stop state error on i.MX93 with imx327:
>
> This error indicates the CSI-2 lanes are not in LP-11 (stop) state when
> expected. Please check:
>
> 1) Verify the sensor PHY is in LP-11 state before returning from the sensor's
> s_stream(1) call. The CSI-2 receiver expects lanes to be in stop state
> initially.
Well, this might be tricky as I don't have D-PHY capable scopes.
I can successfully use this sensor on a imx8mp, so I am expecting this to be
okay.
> 2) Check if the imx327 driver has a delay between starting the stream and
> returning from s_stream(). If the sensor transitions PHY out of LP-11
> state during this delay, the CSI driver's lane state check will fail
> when it runs later. The sensor should remain in LP-11 until the CSI
> controller completes its initialization.
In imx290_set_stream() and subsequently imx290_start_streaming() setting
IMX290_XMSTA starts the stream. I expect this is the point when the sensors
switches from LP-11 to HS. But again, I can't verify.
With enabling debug
> echo "module videodev +p" > /sys/kernel/debug/dynamic_debug/control
> echo 0xff > /sys/class/video4linux/video0/dev_debug
After I setup the media pipeline, running the command
> v4l2-ctl -z "platform:4ae40000.isi" -d "mxc_isi.0.capture" --stream-mmap --stream-count=1 --stream-to=imx93.raw
I get the following debug output:
--8<--
plane 0: bytesperline=3840 sizeimage=4147200
mxc-isi 4ae40000.isi: validating link "crossbar":2 -> "mxc_isi.0":0
mxc-isi 4ae40000.isi: validating stream "crossbar":2:0 -> "mxc_isi.0":0:0
mxc-isi 4ae40000.isi: validating link "dw-mipi-csi2rx 4ae00000.mipi-csi":1 -> "crossbar":0
mxc-isi 4ae40000.isi: validating stream "dw-mipi-csi2rx 4ae00000.mipi-csi":1:0 -> "crossbar":0:0
mxc-isi 4ae40000.isi: validating link "imx327 4-001a":0 -> "dw-mipi-csi2rx 4ae00000.mipi-csi":0
mxc-isi 4ae40000.isi: validating stream "imx327 4-001a":0:0 -> "dw-mipi-csi2rx 4ae00000.mipi-csi":0:0
mxc-isi 4ae40000.isi: enable streams "crossbar":2/0x1
mxc-isi 4ae40000.isi: collect_streams: "crossbar":2: found 0x1 enabled 0x0
imx290 4-001a: Frame descriptor on pad 0, type CSI-2
imx290 4-001a: stream 0, code 0x300f, length 0, flags 0x0000, vc 0, dt 0x2b
dw-mipi-csi2rx 4ae00000.mipi-csi: Frame descriptor on pad 1, type CSI-2
dw-mipi-csi2rx 4ae00000.mipi-csi: stream 0, code 0x300f, length 0, flags 0x0000, vc 0, dt 0x2b
mxc-isi 4ae40000.isi: enable streams "dw-mipi-csi2rx 4ae00000.mipi-csi":1/0x1
dw-mipi-csi2rx 4ae00000.mipi-csi: collect_streams: "dw-mipi-csi2rx 4ae00000.mipi-csi":1: found 0x1 enabled 0x0
mxc-isi 4ae40000.isi: enable streams "imx327 4-001a":0/0x1
imx290 4-001a: collect_streams: sub-device "imx327 4-001a" does not support streams
dw-mipi-csi2rx 4ae00000.mipi-csi: lanes are not in stop state: 0x0, expected 0x10003
mxc-isi 4ae40000.isi: disable streams "imx327 4-001a":0/0x1
imx290 4-001a: collect_streams: sub-device "imx327 4-001a" does not support streams
mxc-isi 4ae40000.isi: enable streams 1:0x1 failed: -110
mxc-isi 4ae40000.isi: failed to enable streams 0x1 on 'dw-mipi-csi2rx 4ae00000.mipi-csi':1: -110
mxc-isi 4ae40000.isi: enable streams 2:0x1 failed: -110
mxc-isi 4ae40000.isi: Failed to enable pipe 0
video0: VIDIOC_STREAMON: error -110: type=vid-cap-mplane
videodev: v4l2_release: video0: release
--8<--
For completeness this is my media device config
--8<--
# media-ctl -p
Media controller API version 7.1.0
Media device information
------------------------
driver mxc-isi
model FSL Capture Media Device
serial
bus info platform:4ae40000.isi
hw revision 0x0
driver version 7.1.0
Device topology
- entity 1: crossbar (3 pads, 2 links, 1 route)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev0
routes:
0/0 -> 2/0 [ACTIVE]
pad0: SINK,MUST_CONNECT
[stream:0 fmt:SRGGB10_1X10/1920x1080 field:none colorspace:raw]
<- "dw-mipi-csi2rx 4ae00000.mipi-cs":1 [ENABLED,IMMUTABLE]
pad1: SINK,MUST_CONNECT
pad2: SOURCE
[stream:0 fmt:SRGGB10_1X10/1920x1080 field:none colorspace:raw]
-> "mxc_isi.0":0 [ENABLED,IMMUTABLE]
- entity 5: mxc_isi.0 (2 pads, 2 links, 0 routes)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev1
pad0: SINK
[stream:0 fmt:SRGGB10_1X10/1920x1080 field:none colorspace:raw
compose.bounds:(0,0)/1920x1080
compose:(0,0)/1920x1080]
<- "crossbar":2 [ENABLED,IMMUTABLE]
pad1: SOURCE
[stream:0 fmt:SRGGB10_1X10/1920x1080 field:none colorspace:jpeg xfer:srgb ycbcr:601 quantization:full-range
crop.bounds:(0,0)/1920x1080
crop:(0,0)/1920x1080]
-> "mxc_isi.0.capture":0 [ENABLED,IMMUTABLE]
- entity 8: mxc_isi.0.capture (1 pad, 1 link)
type Node subtype V4L flags 0
device node name /dev/video0
pad0: SINK
<- "mxc_isi.0":1 [ENABLED,IMMUTABLE]
- entity 16: dw-mipi-csi2rx 4ae00000.mipi-cs (2 pads, 2 links, 1 route)
type V4L2 subdev subtype Unknown flags 0
device node name /dev/v4l-subdev2
routes:
0/0 -> 1/0 [ACTIVE]
pad0: SINK,MUST_CONNECT
[stream:0 fmt:SRGGB10_1X10/1920x1080 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range]
<- "imx327 4-001a":0 [ENABLED]
pad1: SOURCE
[stream:0 fmt:SRGGB10_1X10/1920x1080 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range]
-> "crossbar":0 [ENABLED,IMMUTABLE]
- entity 21: imx327 4-001a (1 pad, 1 link, 0 routes)
type V4L2 subdev subtype Sensor flags 0
device node name /dev/v4l-subdev3
pad0: SOURCE
[stream:0 fmt:SRGGB10_1X10/1920x1080 field:none colorspace:raw xfer:none ycbcr:601 quantization:full-range
crop.bounds:(0,0)/1945x1097
crop:(12,8)/1920x1080]
-> "dw-mipi-csi2rx 4ae00000.mipi-cs":0 [ENABLED]
--8<--
Anything odd here?
> You may need to remove any delays in the imx327 s_stream implementation, or
> ensure the sensor stays in LP-11 state until the CSI receiver is ready.
>
> If possible, could you share the imx327 driver code or check its s_stream implementation?
It's essentially upstream in drivers/media/i2c/imx290.c.
I only have a dummy implementation for get_frame_desc and a small adjustement
for my camera module regarding i2c access.
--8<--
static int imx290_get_frame_desc(struct v4l2_subdev *sd, unsigned int pad,
struct v4l2_mbus_frame_desc *fd)
{
const struct v4l2_mbus_framefmt *format;
struct v4l2_subdev_state *state;
state = v4l2_subdev_lock_and_get_active_state(sd);
format = v4l2_subdev_state_get_format(state, pad);
v4l2_subdev_unlock_state(state);
fd->type = V4L2_MBUS_FRAME_DESC_TYPE_CSI2;
fd->num_entries = 1;
fd->entry[0].pixelcode = format->code;
fd->entry[0].stream = 0;
fd->entry[0].bus.csi2.vc = 0;
fd->entry[0].bus.csi2.dt = MIPI_CSI2_DT_RAW10; //TODO: get_data_type_by_code(format->code);
return 0;
}
--8<--
Another thing. I use https://lore.kernel.org/imx/20250701-95_cam-v1-2-c5172bab387b@nxp.com/
for the D-PHY. Is there any update/progress on that driver?
Best regards,
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v2 1/1] arm64: dts: imx8mq-evk: Enable MIPI CSI and dual OV5640 cameras
From: Robby Cai @ 2026-05-21 11:49 UTC (permalink / raw)
To: Frank Li
Cc: robh, krzk+dt, conor+dt, s.hauer, festevam,
sebastian.krzyszkowiak, kernel, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <ag4C6MjnOJGjEpKN@lizhi-Precision-Tower-5810>
On Wed, May 20, 2026 at 02:52:24PM -0400, Frank Li wrote:
> On Wed, May 20, 2026 at 02:54:52PM +0800, Robby Cai wrote:
> > On Fri, May 15, 2026 at 10:01:47AM -0400, Frank Li wrote:
> > > On Fri, May 15, 2026 at 07:11:43PM +0800, Robby Cai wrote:
> > > > Enable the MIPI CSI bridges and corresponding CSI-2 host interfaces
> > > > on the i.MX8MQ EVK, and add two OV5640 camera sensors.
> > > >
> > > > The sensors are connected via I2C1 and I2C2, each with proper
> > > > endpoint descriptions to form complete media pipelines.
> > > >
> > > > The resulting pipelines are:
> > > >
> > > > - OV5640 (I2C2) -> MIPI CSI1 -> CSI1 bridge
> > > > - OV5640 (I2C1) -> MIPI CSI2 -> CSI2 bridge
> > > >
> > > > Both pipelines have been validated on the i.MX8MQ EVK using the
> > > > upstream OV5640 driver.
> > > >
> > > > Both OV5640 sensors share a single reset GPIO on this board,
> > > > which prevents independent hardware reset when both cameras
> > > > are enabled. As a result, the reset line is kept deasserted
> > > > via a GPIO hog, and sensor reset is performed via software.
> > >
> > > Does reset_control_get_shared() resolve this problem?
> > >
> >
> > No, reset_control_get_shared() does not really solve this issue.
> >
> > The problem here is not about software coordination, but about the
> > hardware topology: both sensors are physically tied to the same reset
> > line. This means any reset operation will always affect both devices
> > simultaneously, regardless of how the reset framework is used.
>
> Reset framework is resolve this problem. It is quite common that many devices
> shared one reset pin.
okay, I'll try to switch to use this approach in next revision.
Some devices require coordinated RESET and PWDN sequencing, but in this
case the device can be properly initialized with RESET held inactive and
controlled solely via the PWDN signal, which makes this approach viable.
>
> >
> > While reset_control_get_shared() introduces reference counting to avoid
> > unintended assertions, it does not allow independent reset control.
> > In particular:
> >
> > - A reset operation (assert) will still impact both sensors.
>
> yes, only when first devices toggle reset signal. Second device do nothing.
>
> > - It does not solve the requirement for per-device hardware reset.
>
> It is hardware limitation.
>
> >
> > Therefore, using a shared reset control does not provide true isolation
> > between the two OV5640 instances.
>
> It is not isolation. Just don't allow second device to toggle reset pin.
>
> >
> > Keeping the reset line permanently deasserted (e.g. via GPIO hog) and
> > handling initialization through software/power sequencing is a valid
> > and practical solution for this hardware design.
>
> If use i2c gpio, expandor driver may probe after sensor driver probe. So
> reset may happen after sensor driver probe.
Just to clarify, the reset GPIO in this design is provided by the SoC GPIO
controller (gpio1), not an external I2C GPIO expander.
Therefore, the "late reset" issue you mentioned does not apply here.
Regards,
Robby
>
> Frank
> >
> > This matches the intention of the upstream changes as well, where GPIO-
> > based resets are treated as simple control signals rather than fully
> > isolated reset domains.
> >
> > In practice, using a shared reset here can even introduce subtle
> > interference between the two cameras during probe or power cycling,
> > so it is safer to avoid using reset for runtime control entirely.
> >
> > Regards,
> > Robby
> >
^ permalink raw reply
* [PATCH v2 2/3] dt-bindings: rockchip: analogix-dp: Add data-lanes example
From: Damon Ding @ 2026-05-21 11:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521114459.1394264-1-damon.ding@rock-chips.com>
Add data-lanes setting in endpoint example to show actual lane mapping
usage.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
.../bindings/display/rockchip/rockchip,analogix-dp.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
index bb75d898a5c5..cf75c926318b 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
@@ -151,6 +151,7 @@ examples:
reg = <1>;
edp_out_panel: endpoint {
+ data-lanes = <0 1>;
remote-endpoint = <&panel_in_edp>;
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH v2 3/3] drm/bridge: analogix_dp: Add support for optional data-lanes mapping
From: Damon Ding @ 2026-05-21 11:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521114459.1394264-1-damon.ding@rock-chips.com>
Parse the optional 'data-lanes' device tree property to support
custom physical lane mapping configuration.
If no valid configuration is found, fall back to the default
lane map (0, 1, 2, 3) automatically and keep the driver running.
Lane mapping is mainly used for below scenarios:
1. Correct PCB lane swap and differential line routing crossover
without hardware changes;
2. Adapt mismatched lane pin definitions between SoC and eDP panel;
3. Support multiple panel hardware variants on the same board
by configuring data-lanes in device tree only.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v2:
- Add lane mapping application scenarios in commit message.
---
.../drm/bridge/analogix/analogix_dp_core.c | 56 +++++++++++++++++++
.../drm/bridge/analogix/analogix_dp_core.h | 4 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 15 +++--
.../gpu/drm/bridge/analogix/analogix_dp_reg.h | 4 ++
4 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5dc07ff84cd3..d1c6365118de 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -1234,6 +1234,59 @@ static const struct drm_bridge_funcs analogix_dp_bridge_funcs = {
.detect = analogix_dp_bridge_detect,
};
+static int analogix_dp_dt_parse_lanes_map(struct analogix_dp_device *dp)
+{
+ struct video_info *video_info = &dp->video_info;
+ struct device_node *endpoint;
+ u32 tmp[LANE_COUNT4];
+ u32 map[LANE_COUNT4] = {0, 1, 2, 3};
+ bool used[LANE_COUNT4] = {false};
+ int num_lanes;
+ int ret, i;
+
+ memcpy(video_info->lane_map, map, sizeof(map));
+
+ num_lanes = drm_of_get_data_lanes_count_ep(dp->dev->of_node, 1, 0, 1,
+ video_info->max_lane_count);
+ if (num_lanes < 0)
+ return -EINVAL;
+
+ endpoint = of_graph_get_endpoint_by_regs(dp->dev->of_node, 1, -1);
+ if (!endpoint)
+ return -EINVAL;
+
+ ret = of_property_read_u32_array(endpoint, "data-lanes", tmp, num_lanes);
+ of_node_put(endpoint);
+ if (ret)
+ return -EINVAL;
+
+ for (i = 0; i < num_lanes; i++) {
+ if (tmp[i] >= LANE_COUNT4) {
+ dev_dbg(dp->dev, "data-lanes[%d] = %u is out of range\n", i, tmp[i]);
+ return -EINVAL;
+ }
+
+ if (used[tmp[i]]) {
+ dev_dbg(dp->dev, "data-lanes[%d] = %u is duplicate\n", i, tmp[i]);
+ return -EINVAL;
+ }
+
+ used[tmp[i]] = true;
+ map[i] = tmp[i];
+ }
+
+ for (i = 0; i < LANE_COUNT4 && num_lanes < LANE_COUNT4; i++) {
+ if (!used[i])
+ map[num_lanes++] = i;
+ }
+
+ dev_dbg(dp->dev, "Using parsed lane map: <%u %u %u %u>\n", map[0], map[1], map[2], map[3]);
+
+ memcpy(video_info->lane_map, map, sizeof(map));
+
+ return 0;
+}
+
static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
{
struct device_node *dp_node = dp->dev->of_node;
@@ -1266,6 +1319,9 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
break;
}
+ if (analogix_dp_dt_parse_lanes_map(dp))
+ dev_dbg(dp->dev, "No valid data-lanes found, using default lane map\n");
+
return 0;
}
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
index 94348c4e3623..a75d0fb8f980 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.h
@@ -137,6 +137,8 @@ struct video_info {
int max_link_rate;
enum link_lane_count_type max_lane_count;
+
+ u32 lane_map[LANE_COUNT4];
};
struct link_train {
@@ -175,7 +177,7 @@ struct analogix_dp_device {
/* analogix_dp_reg.c */
void analogix_dp_enable_video_mute(struct analogix_dp_device *dp, bool enable);
void analogix_dp_stop_video(struct analogix_dp_device *dp);
-void analogix_dp_lane_swap(struct analogix_dp_device *dp, bool enable);
+void analogix_dp_lane_mapping(struct analogix_dp_device *dp);
void analogix_dp_init_analog_param(struct analogix_dp_device *dp);
void analogix_dp_init_interrupt(struct analogix_dp_device *dp);
void analogix_dp_reset(struct analogix_dp_device *dp);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
index ea8401293a23..c1344a3f013a 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c
@@ -48,16 +48,15 @@ void analogix_dp_stop_video(struct analogix_dp_device *dp)
writel(reg, dp->reg_base + ANALOGIX_DP_VIDEO_CTL_1);
}
-void analogix_dp_lane_swap(struct analogix_dp_device *dp, bool enable)
+void analogix_dp_lane_mapping(struct analogix_dp_device *dp)
{
+ u32 *lane_map = dp->video_info.lane_map;
u32 reg;
- if (enable)
- reg = LANE3_MAP_LOGIC_LANE_0 | LANE2_MAP_LOGIC_LANE_1 |
- LANE1_MAP_LOGIC_LANE_2 | LANE0_MAP_LOGIC_LANE_3;
- else
- reg = LANE3_MAP_LOGIC_LANE_3 | LANE2_MAP_LOGIC_LANE_2 |
- LANE1_MAP_LOGIC_LANE_1 | LANE0_MAP_LOGIC_LANE_0;
+ reg = lane_map[0] << LANE0_MAP_SHIFT;
+ reg |= lane_map[1] << LANE1_MAP_SHIFT;
+ reg |= lane_map[2] << LANE2_MAP_SHIFT;
+ reg |= lane_map[3] << LANE3_MAP_SHIFT;
writel(reg, dp->reg_base + ANALOGIX_DP_LANE_MAP);
}
@@ -140,7 +139,7 @@ void analogix_dp_reset(struct analogix_dp_device *dp)
usleep_range(20, 30);
- analogix_dp_lane_swap(dp, 0);
+ analogix_dp_lane_mapping(dp);
writel(0x0, dp->reg_base + ANALOGIX_DP_SYS_CTL_1);
writel(0x40, dp->reg_base + ANALOGIX_DP_SYS_CTL_2);
diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
index 12735139046c..ac914e37089b 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_reg.h
@@ -209,6 +209,10 @@
#define LANE0_MAP_LOGIC_LANE_1 (0x1 << 0)
#define LANE0_MAP_LOGIC_LANE_2 (0x2 << 0)
#define LANE0_MAP_LOGIC_LANE_3 (0x3 << 0)
+#define LANE3_MAP_SHIFT (6)
+#define LANE2_MAP_SHIFT (4)
+#define LANE1_MAP_SHIFT (2)
+#define LANE0_MAP_SHIFT (0)
/* ANALOGIX_DP_ANALOG_CTL_1 */
#define TX_TERMINAL_CTRL_50_OHM (0x1 << 4)
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: display: bridge: analogix-dp: Add data-lanes support for endpoint
From: Damon Ding @ 2026-05-21 11:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
In-Reply-To: <20260521114459.1394264-1-damon.ding@rock-chips.com>
Add data-lanes property support to the port@1 endpoint for physical
lane mapping configuration.
Lane mapping is mainly used for below scenarios:
1. Correct PCB lane swap and differential line routing crossover
without hardware changes;
2. Adapt mismatched lane pin definitions between SoC and eDP panel;
3. Support multiple panel hardware variants on the same board
by configuring data-lanes in device tree only.
Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
---
Changes in v2:
- Add lane mapping application scenarios in commit message.
- Remove redundant deprecated property 'data-lanes' for eDP node.
- Update port@1 $ref to /schemas/graph.yaml#/$defs/port-base.
---
.../bindings/display/bridge/analogix,dp.yaml | 17 ++++++++++++-----
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
index 62f0521b0924..e34fdb21adb4 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
@@ -42,13 +42,20 @@ properties:
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
- description:
- Input node to receive pixel data.
+ description: Input node to receive pixel data.
port@1:
- $ref: /schemas/graph.yaml#/properties/port
- description:
- Port node with one endpoint connected to a dp-connector node.
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ description: Port node with one endpoint connected to sink device node.
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ properties:
+ data-lanes:
+ minItems: 1
+ maxItems: 4
+ items:
+ enum: [ 0, 1, 2, 3 ]
required:
- port@0
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/3] Add eDP lane mapping support
From: Damon Ding @ 2026-05-21 11:44 UTC (permalink / raw)
To: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss
Cc: Laurent.pinchart, jonas, jernej.skrabec, nicolas.frattaroli,
cristian.ciocaltea, sebastian.reichel, dmitry.baryshkov,
luca.ceresoli, dianders, m.szyprowski, dri-devel, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel, Damon Ding
This series adds configurable eDP/DP physical lane mapping support
via device tree data-lanes property.
Lane mapping is mainly used for below scenarios:
1. Correct PCB lane swap and differential line routing crossover
without hardware changes;
2. Adapt mismatched lane pin definitions between SoC and eDP panel;
3. Support multiple panel hardware variants on the same board
by configuring data-lanes in device tree only.
The series includes driver implementation and device tree binding
updates to support custom lane mapping configuration from endpoint
node, and keeps default linear lane order if no configuration is given.
Patch 1: Add endpoint data-lanes property to analogix-dp binding
Patch 2: Add data-lanes property example in rockchip analogix-dp binding
Patch 3: Implement lane mapping in analogix_dp driver
Damon Ding (3):
dt-bindings: display: bridge: analogix-dp: Add data-lanes support for
endpoint
dt-bindings: rockchip: analogix-dp: Add data-lanes example
drm/bridge: analogix_dp: Add support for optional data-lanes mapping
.../bindings/display/bridge/analogix,dp.yaml | 17 ++++--
.../rockchip/rockchip,analogix-dp.yaml | 1 +
.../drm/bridge/analogix/analogix_dp_core.c | 56 +++++++++++++++++++
.../drm/bridge/analogix/analogix_dp_core.h | 4 +-
.../gpu/drm/bridge/analogix/analogix_dp_reg.c | 15 +++--
.../gpu/drm/bridge/analogix/analogix_dp_reg.h | 4 ++
6 files changed, 83 insertions(+), 14 deletions(-)
---
Changes in v2:
- Add lane mapping application scenarios in commit message.
- Remove redundant deprecated property 'data-lanes' for eDP node.
- Update port@1 $ref to /schemas/graph.yaml#/$defs/port-base.
--
2.34.1
^ permalink raw reply
* Re: [PATCH v5 4/6] dt-bindings: display: mediatek: tdshp: Add support for MT8196
From: Jay Liu (刘博) @ 2026-05-21 11:40 UTC (permalink / raw)
To: chunkuang.hu@kernel.org, tzimmermann@suse.de, simona@ffwll.ch,
mripard@kernel.org, p.zabel@pengutronix.de,
CK Hu (胡俊光),
maarten.lankhorst@linux.intel.com, conor+dt@kernel.org,
robh@kernel.org, airlied@gmail.com, matthias.bgg@gmail.com,
krzk+dt@kernel.org, AngeloGioacchino Del Regno
Cc: dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org,
linux-mediatek@lists.infradead.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <c9ed6676f1ae77e21b2ba2daf75a76f3a9a13389.camel@mediatek.com>
On Wed, 2026-05-13 at 08:03 +0000, CK Hu (胡俊光) wrote:
> On Mon, 2026-04-27 at 19:20 +0800, Jay Liu wrote:
> > Add tdshp hardware description for MediaTek MT8196 SoC
> >
> > Signed-off-by: Jay Liu <jay.liu@mediatek.com>
> > ---
> > .../display/mediatek/mediatek,tdshp.yaml | 46
> > +++++++++++++++++++
> > 1 file changed, 46 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp.y
> > aml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp
> > .yaml
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp
> > .yaml
> > new file mode 100644
> > index 000000000000..50b24cc22420
> > --- /dev/null
> > +++
> > b/Documentation/devicetree/bindings/display/mediatek/mediatek,tdshp
> > .yaml
> > @@ -0,0 +1,46 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id:
> > https://urldefense.com/v3/__http://devicetree.org/schemas/display/mediatek/mediatek,tdshp.yaml*__;Iw!!CTRNKA9wMg0ARbw!jvLiL6w7ScJqhkM0IyiLok4cwzb-e1gME-mO9r5lLT3JTrgaBBiiV1j8LFkmJkIafaGiBya2GJN6h38e$
> >
> > +$schema:
> > https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!CTRNKA9wMg0ARbw!jvLiL6w7ScJqhkM0IyiLok4cwzb-e1gME-mO9r5lLT3JTrgaBBiiV1j8LFkmJkIafaGiBya2GCPflrFz$
> >
> > +
> > +title: MediaTek display 2D sharpness processor
> > +
> > +maintainers:
> > + - Chun-Kuang Hu <chunkuang.hu@kernel.org>
> > + - Philipp Zabel <p.zabel@pengutronix.de>
> > +
> > +description: |
> > + MediaTek display 2D sharpness processor, namely TDSHP, provides
> > a
>
> a -> an
>
> > + operation used to adjust sharpness in display system.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - mediatek,mt8196-disp-tdshp
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + clocks:
> > + maxItems: 1
>
> Refer to other display block binding document, and find out the
> common property.
> Such as power-domains, gce-client-reg, ports.
>
> Regards,
> CK
>
Thank you for your review and helpful suggestions.
I will review other display block binding documents and identify the
common properties, such as power-domains, gce-client-reg, and ports.
If I have further questions or need clarification, I will reach out.
Thanks again for your guidance.
Best regards,
Jay
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - clocks
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + soc {
> > + #address-cells = <2>;
> > + #size-cells = <2>;
> > +
> > + tdshp@321e0000 {
> > + compatible = "mediatek,mt8196-disp-tdshp";
> > + reg = <0 0x321e0000 0 0x1000>;
> > + clocks = <&dispsys_config_clk 107>;
> > + };
> > + };
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/2] arm64: add SMCCC cache invalidation backend for memregion users
From: Jonathan Cameron @ 2026-05-21 11:28 UTC (permalink / raw)
To: Srirangan Madhavan
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
conor, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams
In-Reply-To: <20260521073047.320614-1-smadhavan@nvidia.com>
On Thu, 21 May 2026 07:30:45 +0000
Srirangan Madhavan <smadhavan@nvidia.com> wrote:
> This series adds an arm64 backend for memregion cache invalidation users
> based on the Arm SMCCC cache clean+invalidate interface.
>
> Per DEN0028, this interface targets systems where a Normal Cacheable
> memory region can be modified in ways that are not handled by usual PE
> coherency mechanisms, and where VA-based CMOs may be too slow or
> insufficient for large ranges and/or system-cache implementations.
>
> Representative use cases include device-backed memory state transitions
> where stale CPU/system cache lines must be invalidated reliably (for
> example secure erase, reset/offline flows, and dynamic memory
> reconfiguration).
>
Hi Srirangan,
Great to see this moving forwards. I was wondering when it would
surface upstream :)
Usual thing for an RFC is to have some reference to why it is an RFC.
I'm not immediately spotting any open questions or dependencies to
stop this going upstream now (if review of actual code goes well).
So why RFC? Is the spec still in beta?
> Patch 1 introduces the Arm SMCCC cache clean/invalidate function IDs and
> transient return codes needed by callers [1].
>
> Patch 2 adds an arm64 cache maintenance provider that:
> - discovers SMCCC support and attributes at init time
> - registers with the generic cache coherency framework used by
> cpu_cache_invalidate_memregion()
> - handles transient BUSY/RATE_LIMITED responses with bounded retries
> - coalesces waiters when firmware reports a global operation type
>
> This patch set does not add a software fallback path; when firmware does
> not implement the SMCCC cache maintenance interface, the provider is not
> registered and existing behavior is preserved.
By which you mean it kicks out an error? This kind of hints there
might be a software fallback (assuming no other implementation has
registered). In many cases there isn't a safe software solution.
Jonathan
>
> Reference:
> [1] https://developer.arm.com/documentation/den0028/latest
>
> Srirangan Madhavan (2):
> arm64: smccc: add cache clean/invalidate IDs and return codes
> arm64: mm: add SMCCC-backed cache invalidate provider
>
> MAINTAINERS | 1 +
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++
> include/linux/arm-smccc.h | 17 ++-
> tools/include/linux/arm-smccc.h | 17 ++-
> 5 files changed, 212 insertions(+), 4 deletions(-)
> create mode 100644 arch/arm64/mm/cache_maint.c
>
>
> base-commit: 3b3bea6d4b9c162f9e555905d96b8c1da67ecd5b
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Lee Jones @ 2026-05-21 11:26 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Sebastian Reichel, Mark Rutland, Lorenzo Pieralisi,
Rafael J. Wysocki, Daniel Lezcano, Christian Loehle, Ulf Hansson,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer,
Bartosz Golaszewski, Sudeep Holla, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-kernel, devicetree, Florian Fainelli,
Krzysztof Kozlowski, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Greg Kroah-Hartman, Kathiravan Thirumoorthy, Srinivas Kandagatla,
Bartosz Golaszewski
In-Reply-To: <20260514-arm-psci-system_reset2-vendor-reboots-v22-8-28a5bde07483@oss.qualcomm.com>
On Thu, 14 May 2026, Shivendra Pratap wrote:
> MFD core has no way to register a child device using an explicit firmware
> node. This prevents drivers from registering child nodes when those nodes
> do not define a compatible string. One such example is the PSCI
> "reboot-mode" node, which omits a compatible string as it describes
> boot-states provided by the underlying firmware.
>
> Extend struct mfd_cell with a callback that allows drivers to provide an
> explicit firmware node. The node is added to the MFD child device during
> registration when none is assigned by device tree, ACPI, or software
> matching.
>
> Suggested-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> Signed-off-by: Shivendra Pratap <shivendra.pratap@oss.qualcomm.com>
> ---
> drivers/mfd/mfd-core.c | 30 ++++++++++++++++++++++++++++++
> include/linux/mfd/core.h | 14 ++++++++++++++
> 2 files changed, 44 insertions(+)
>
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 7aa32b90cf1eb7fa0a05bf3dc506e60a262c9850..cc2a2a924d6d3044e29a9f864b536ee325ed797b 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -10,6 +10,7 @@
> #include <linux/kernel.h>
> #include <linux/platform_device.h>
> #include <linux/acpi.h>
> +#include <linux/fwnode.h>
> #include <linux/list.h>
> #include <linux/property.h>
> #include <linux/mfd/core.h>
> @@ -148,6 +149,11 @@ static int mfd_match_of_node_to_dev(struct platform_device *pdev,
> return 0;
> }
>
> +static void mfd_child_fwnode_put(void *data)
> +{
> + fwnode_handle_put(data);
> +}
> +
> static int mfd_add_device(struct device *parent, int id,
> const struct mfd_cell *cell,
> struct resource *mem_base,
> @@ -156,6 +162,7 @@ static int mfd_add_device(struct device *parent, int id,
> struct resource *res;
> struct platform_device *pdev;
> struct mfd_of_node_entry *of_entry, *tmp;
> + struct fwnode_handle *fwnode;
> bool disabled = false;
> int ret = -ENOMEM;
> int platform_id;
> @@ -224,6 +231,29 @@ static int mfd_add_device(struct device *parent, int id,
>
> mfd_acpi_add_device(cell, pdev);
>
> + if (!pdev->dev.fwnode && cell->get_child_fwnode) {
> + fwnode = cell->get_child_fwnode(parent);
> + if (fwnode) {
> + device_set_node(&pdev->dev, fwnode);
> +
> + /*
> + * platform_device_release() drops only of_node refs.
> + * Track non-OF fwnodes explicitly so they are put on
> + * all teardown paths.
> + */
> + if (!to_of_node(fwnode)) {
> + ret = devm_add_action(&pdev->dev,
> + mfd_child_fwnode_put,
> + fwnode);
> + if (ret) {
> + device_set_node(&pdev->dev, NULL);
> + fwnode_handle_put(fwnode);
> + goto fail_of_entry;
> + }
> + }
> + }
> + }
mfd_add_device() is getting very busy now with support for all of these
different registration APIs. Suggest that we start breaking them out.
> +
> if (cell->pdata_size) {
> ret = platform_device_add_data(pdev,
> cell->platform_data, cell->pdata_size);
> diff --git a/include/linux/mfd/core.h b/include/linux/mfd/core.h
> index faeea7abd688f223fb0b31cde0a9b69dfe2a61ff..abfc26c057d6ee46947ba2b6f2e99f420e74b127 100644
> --- a/include/linux/mfd/core.h
> +++ b/include/linux/mfd/core.h
> @@ -50,6 +50,7 @@
> #define MFD_DEP_LEVEL_HIGH 1
>
> struct irq_domain;
> +struct fwnode_handle;
> struct software_node;
>
> /* Matches ACPI PNP id, either _HID or _CID, or ACPI _ADR */
> @@ -80,6 +81,19 @@ struct mfd_cell {
>
> /* Software node for the device. */
> const struct software_node *swnode;
> + /*
> + * Callback to return an explicit firmware node.
> + * @parent: MFD parent device passed to mfd_add_devices().
> + *
> + * Called only if OF/ACPI matching did not assign a fwnode.
> + * Ownership of the returned reference is transferred to MFD core.
> + *
> + * Return a referenced fwnode or NULL if none is available.
> + *
> + * mfd_cell must be zero-initialized or get_child_fwnode must be NULL
> + * when unused.
> + */
> + struct fwnode_handle *(*get_child_fwnode)(struct device *parent);
I'm very much against pointers to functions if they can be avoided. Why
does fwnode need this and none of the other APIs do?
> /*
> * Device Tree compatible string
>
> --
> 2.34.1
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH] irqchip/exynos-combiner: switch to raw_spinlock
From: Marek Szyprowski @ 2026-05-21 11:26 UTC (permalink / raw)
To: Thomas Gleixner, linux-arm-kernel, linux-samsung-soc,
linux-rt-devel
Cc: Krzysztof Kozlowski, Alim Akhtar, Sebastian Andrzej Siewior,
Clark Williams, Steven Rostedt
In-Reply-To: <87ecj5w2qf.ffs@tglx>
On 21.05.2026 11:06, Thomas Gleixner wrote:
> On Thu, May 21 2026 at 00:04, Marek Szyprowski wrote:
>> The exynos-combiner driver uses a regular spinlock to protect access to
>> the combiner interrupt status register in combiner_handle_cascade_irq(),
>> which is invoked in hard IRQ context as a chained interrupt handler.
>>
>> When PREEMPT_RT is enabled on ARM, regular spinlock is converted to a
>> sleeping lock (mutex-based), which must not be used in atomic context
>> such as hard interrupt handlers. Switch the irq_controller_lock to
>> raw_spinlock, which remains a true non-sleeping spinlock even under
>> PREEMPT_RT.
> Mechanically this makes sense, but out of curiosity I have to ask:
>
>> -static DEFINE_SPINLOCK(irq_controller_lock);
>> +static DEFINE_RAW_SPINLOCK(irq_controller_lock);
>>
>> struct combiner_chip_data {
>> unsigned int hwirq_offset;
>> @@ -72,9 +72,9 @@ static void combiner_handle_cascade_irq(struct irq_desc *desc)
>>
>> chained_irq_enter(chip, desc);
>>
>> - spin_lock(&irq_controller_lock);
>> + raw_spin_lock(&irq_controller_lock);
>> status = readl_relaxed(chip_data->base + COMBINER_INT_STATUS);
>> - spin_unlock(&irq_controller_lock);
>> + raw_spin_unlock(&irq_controller_lock);
> What is this lock actually protecting?
>
> Each combiner has it's own @base address, so there is no concurrency
> problem between two cascade interrupts being handled at the same time.
>
> That means the only possible problem would be that the same cascade
> interrupt is handled on two CPUs concurrently. Is that even possible?
Frankly speaking I did this conversion mechanically, late in the evening to fix
the bug warning I've spotted. Indeed this spinlock looks like a copy&paste or
development leftover. The only side-effect of it I see is a memory barrier,
which might affect how the register access happens, but this should not affect
cascade operation imho. Do You want me to send a patch removing it completely?
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* Re: [PATCH] [RFC] arm64: mmu: use range based TLB flushing when hot unplugging memory
From: Ryan Roberts @ 2026-05-21 11:24 UTC (permalink / raw)
To: Balbir Singh
Cc: Alistair Popple, linux-arm-kernel, linux-kernel, linux-mm,
catalin.marinas, will, david, anshuman.khandual, dev.jain,
jhubbard
In-Reply-To: <ag7fy4Q9foBBlUcd@parvat>
On 21/05/2026 11:46, Balbir Singh wrote:
> On Thu, May 21, 2026 at 09:50:04AM +0100, Ryan Roberts wrote:
>> On 21/05/2026 05:24, Alistair Popple wrote:
>>> Hot unplugging memory on ARM64 requires a TLB invalidate after unmapping
>>> the page to be hot unplugged from the direct map. Currently that happens
>>> one page at a time, meaning range based invalidates cannot be used. The
>>> result of this is that removing large amounts of memory takes a long
>>> time and in some cases can trigger an RCU stall warning.
>>>
>>> For example on one system hot unplugging 480GB of memory takes ~1
>>> minute. With this change the same operation took ~1 second, a 60x
>>> improvement.
>>>
>>> Signed-off-by: Alistair Popple <apopple@nvidia.com>
>>>
>>> ---
>>>
>>> This is an RFC, because I'm not sure the change is correct as it frees
>>> the PTE page before flushing the TLB. I'm not familiar enough with ARM64
>>> architecture to be sure this is safe, for example I don't know if HW
>>> can update PTE bits such as access/dirty in the page through a stale
>>> TLB entry.
>>>
>>> If so this would open a window during which the page is free but could
>>> still be written to. Likely the safe option would be to collect all the
>>> pages to be free on a list and free them after doing the range based TLB
>>> flush, but wanted to get feedback on the approach before implementing it
>>> which is the goal of this RFC.
>>
>> Hi Alistair,
>>
>> This patch doesn't apply on v7.1-rc4 because it conflicts with this patch:
>>
>> Commit 48478b9f79137 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
>>
>> which has a very similar performance improvement, so hopefully it solves your
>> problem?
>>
>> There are two paths which use this logic; unmapping the linear map and unmapping
>> the corresponding vmemmap. In the latter case, the memory is also freed, so we
>> can't safely do the range optimizaiton there since the TLB needs to be flushed
>> before freeing the memory. But the linear map is the big, slow bit so hopefully
>> it's sufficent for you?
>>
>
> I assume vmemmap path is for tearing down the struct pages corresponding
> to the physical memory and vmemmap teardowns taking a flush should be
> OK. It is worth checking if the issue is already fixed.
Yes, exactly. Assuming you're using 64K pages, I think vmemmap is mapped using
base pages. So you'd get 1024 struct pages on a page, so 1 TLBI per 64M of
memory that is being unplugged on the vmemmap path.
On the linear map path, it's a single range tlbi operation to over the entire range.
Alistair's patch is doing it per 512M in both cases, but is unsafe for vmemmap
as currently written.
>
> Balbir
> <snip>
^ permalink raw reply
* Re: [PATCH 2/2] kselftest/arm64: Add test for atomic futex uaccess with POE
From: Mark Brown @ 2026-05-21 11:22 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, Catalin Marinas, Joey Gouly, Shuah Khan,
Will Deacon, linux-kernel, linux-kselftest
In-Reply-To: <20260521-poe_futex-v1-2-1da286b8f9b2@arm.com>
[-- Attachment #1: Type: text/plain, Size: 405 bytes --]
On Thu, May 21, 2026 at 10:42:31AM +0100, Kevin Brodsky wrote:
> Add a new test to ensure that atomic futex uaccess succeeds on
> memory mapped with a non-default POIndex/pkey.
> + ptr = mmap(NULL, size, PROT_READ | PROT_WRITE,
> + MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
> + ASSERT_NE(ptr, MAP_FAILED);
Doesn't matter while there's only one test but we should probably
munmap() this when we're done.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 2/2] arm64: mm: add SMCCC-backed cache invalidate provider
From: Jonathan Cameron @ 2026-05-21 11:18 UTC (permalink / raw)
To: Srirangan Madhavan
Cc: catalin.marinas, will, mark.rutland, lpieralisi, sudeep.holla,
conor, linux-arm-kernel, linux-kernel, vsethi, jevans,
raghupathyk, srikars, nbenech, alwilliamson, Dan Williams
In-Reply-To: <20260521073047.320614-3-smadhavan@nvidia.com>
On Thu, 21 May 2026 07:30:47 +0000
Srirangan Madhavan <smadhavan@nvidia.com> wrote:
> Add an arm64 cache maintenance backend that discovers SMCCC cache
> clean+invalidate support, queries attributes, handles transient BUSY and
> RATE_LIMITED responses with bounded retries, and registers with the generic
> cache coherency framework.
>
> Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
Hi Srirangan,
Other than the file location and Kconfig option comments, everything else
is really trivial. + some musings about maybe being worth more clever
fusing of ops in the future if it turns out to be useful.
Thanks,
Jonathan
> ---
> MAINTAINERS | 1 +
> arch/arm64/mm/Makefile | 1 +
> arch/arm64/mm/cache_maint.c | 180 ++++++++++++++++++++++++++++++++++++
File location wise, this is a driver for a subsystem, be it one closely
coupled to arm. Arm maintainers, do you want it in there or in drivers/cache ?
My personal preference is always to keep drivers with subsystems but I don't
care that much.
> 3 files changed, 182 insertions(+)
> create mode 100644 arch/arm64/mm/cache_maint.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2fb1c75afd16..33c35f8e6e40 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -25383,6 +25383,7 @@ M: Jonathan Cameron <jic23@kernel.org>
> S: Maintained
> T: git https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/
> F: Documentation/devicetree/bindings/cache/
> +F: arch/arm64/mm/cache_maint.c
I wonder if this should just have a separate maintainers entry?
We did that for the hisi driver.
If not maybe add yourself as at least a Reviewer so that you get +CC'd
on relevant changes.
Conor, what do you think makes sense here.
> F: drivers/cache
> F: include/linux/cache_coherency.h
> F: lib/cache_maint.c
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index c26489cf96cd..b247dc5dfd45 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_TRANS_TABLE) += trans_pgd-asm.o
> obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o
> obj-$(CONFIG_ARM64_MTE) += mteswap.o
> obj-$(CONFIG_ARM64_GCS) += gcs.o
> +obj-$(CONFIG_ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION) += cache_maint.o
I think this should have a separate CONFIG because it is only one option
for how to do it on arm64. The Hisi driver being the other one already
upstream. That will be easier if this is in drivers/cache as can go
in the existing menu.
> KASAN_SANITIZE_physaddr.o += n
>
> obj-$(CONFIG_KASAN) += kasan_init.o
> diff --git a/arch/arm64/mm/cache_maint.c b/arch/arm64/mm/cache_maint.c
> new file mode 100644
> index 000000000000..ea7dd30d5dfa
> --- /dev/null
> +++ b/arch/arm64/mm/cache_maint.c
> @@ -0,0 +1,180 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2026 NVIDIA Corporation
> + *
> + * Arm64 cache maintenance provider using SMCCC cache clean+invalidate calls.
> + */
> +
> +#include <linux/arm-smccc.h>
> +#include <linux/cache_coherency.h>
> +#include <linux/cleanup.h>
> +#include <linux/delay.h>
> +#include <linux/errno.h>
> +#include <linux/init.h>
> +#include <linux/kernel.h>
> +#include <linux/mutex.h>
> +#include <linux/nmi.h>
> +
> +#define SMCCC_CACHE_MAX_RETRIES 5
> +#define SMCCC_CACHE_MAX_DELAY_US 20000
> +
> +/* DEN0028 v1.7: bit[0] == 1 means implementation flushes all caches globally */
> +#define SMCCC_CACHE_ATTR_GLOBAL_OP BIT(0)
> +
> +struct arm64_smccc_cache {
> + /* Must be first member */
> + struct cache_coherency_ops_inst cci;
> + struct mutex lock; /* Serializes SMCCC cache maintenance calls. */
> + u32 latency_us;
> + u32 rate_limit;
> + bool global_op;
> + u64 global_flush_gen;
> +};
> +
> +static struct arm64_smccc_cache *arm64_smccc_cache;
Whilst it is harmless, why do we need the global? I don't think anything outside
of init() ever uses it. Given there is no exit() anyway, might as well just leak
the pointer.
> +
> +static int smccc_cache_status_to_errno(s32 status)
> +{
> + switch (status) {
> + case SMCCC_RET_SUCCESS:
> + return 0;
> + case SMCCC_RET_NOT_SUPPORTED:
> + case SMCCC_RET_NOT_REQUIRED:
I'm not seeing this in the list of possible errors and
I'm far from sure what it would mean in this case if we got it!
Maybe it would indicate that the cache was known not dirty for
some reason. I'd left default deal with this one probably.
> + return -EOPNOTSUPP;
> + case SMCCC_RET_INVALID_PARAMETER:
> + return -EINVAL;
> + case SMCCC_RET_RATE_LIMITED:
> + return -EAGAIN;
> + case SMCCC_RET_BUSY:
> + return -EBUSY;
> + default:
> + return -EIO;
> + }
> +}
> +
> +static int smccc_cache_delay_us(const struct arm64_smccc_cache *cache)
> +{
> + u64 delay_us = 0;
> +
> + if (cache->rate_limit)
> + delay_us = DIV_ROUND_UP_ULL(USEC_PER_SEC, cache->rate_limit);
> +
> + if (cache->latency_us)
> + delay_us = max_t(u64, delay_us, cache->latency_us);
max() should be fine here I think.
> +
> + if (!delay_us)
> + delay_us = 1000;
Why? Needs a comment I think.
> +
> + return min_t(u64, delay_us, SMCCC_CACHE_MAX_DELAY_US);
The type forcing needed? I might be missing why min() isn't fine here.
Doesn't seem to be in the list in the minmax.h docs for when you can't
just use min().
> +}
> +
> +static int arm64_smccc_cache_wbinv(struct cache_coherency_ops_inst *cci,
> + struct cc_inval_params *invp)
> +{
> + struct arm64_smccc_cache *cache =
> + container_of(cci, struct arm64_smccc_cache, cci);
> + struct arm_smccc_res res = {};
> + int delay_us = smccc_cache_delay_us(cache);
> + u64 gen = 0;
> + s32 status;
> + int ret;
> + int i;
> +
> + if (!invp->size)
> + return -EINVAL;
> +
> + if (cache->global_op)
> + gen = READ_ONCE(cache->global_flush_gen);
> +
> + guard(mutex)(&cache->lock);
> +
> + /*
> + * If firmware reports a global operation type, a successful operation
> + * covers every request that was already waiting behind it. Skip if the
> + * generation advanced while this request was waiting to enter the
> + * serialized firmware call path.
Perhaps call out that the serialization is on the lock. I read this as
there being another level of serialization going on and got confused ;)
Can see there might be further improvements to the non global case
using same principle you have here. I guess leave those until we have
any info on whether they are useful.
> + */
> + if (cache->global_op && gen != READ_ONCE(cache->global_flush_gen))
> + return 0;
> +
> + for (i = 0; i < SMCCC_CACHE_MAX_RETRIES; i++) {
Can drag the int i in here, maybe make it unsigned too.
for (unsigned int i = 0; i <...
This is becoming widely accepted in kernel code these days.
> + /* Long firmware operations can trigger watchdog checks. */
> + touch_nmi_watchdog();
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION,
> + invp->addr, invp->size, 0UL, &res);
> + status = (s32)res.a0;
> + ret = smccc_cache_status_to_errno(status);
Given status isn't used for anything else - tiny bit neater perhaps as
ret = smccc_cache_status_to_errno((s32)res.a0);
> + if (!ret) {
> + if (cache->global_op) {
> + WRITE_ONCE(cache->global_flush_gen,
> + cache->global_flush_gen + 1);
> + }
> + return 0;
> + }
> +
> + if (ret != -EBUSY && ret != -EAGAIN)
> + return ret;
> +
> + usleep_range(delay_us, delay_us + 100);
fsleep() for this sort of thing in modern code.
> + }
> +
> + return -EBUSY;
> +}
> +
> +static int __init arm64_smccc_cache_init(void)
> +{
> + struct arm_smccc_res res = {};
> + s32 status;
> + int ret;
> +
> + if (arm_smccc_get_version() < ARM_SMCCC_VERSION_1_1)
> + return -ENODEV;
> +
> + if (arm_smccc_1_1_get_conduit() == SMCCC_CONDUIT_NONE)
> + return -ENODEV;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION, &res);
> + status = (s32)res.a0;
> + if (status < 0)
> + return -ENODEV;
Maybe there is convention for this, but feels a bit odd to return -ENODEV
for a feature check on a 'device' we are talking to. Maybe -EOPNOTSUPP?
Anyhow, that's a question for SMCCC folk. The only error that could
be returned is NOT_SUPPORTED and you do that above for the returns from
actual calls.
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_FEATURES_FUNC_ID,
> + ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
> + status = (s32)res.a0;
> + if (status < 0)
> + return -ENODEV;
> +
> + arm_smccc_1_1_invoke(ARM_SMCCC_ARCH_CLEAN_INV_MEMREGION_ATTRIBUTES, &res);
> + status = (s32)res.a0;
> + if (status)
> + return -ENODEV;
> +
> + arm64_smccc_cache =
> + cache_coherency_ops_instance_alloc(&arm64_smccc_cache_ops,
> + struct arm64_smccc_cache,
> + cci);
I'd go long on that just for readability but not important.
> + if (!arm64_smccc_cache)
> + return -ENOMEM;
> +
> + mutex_init(&arm64_smccc_cache->lock);
> + arm64_smccc_cache->latency_us = lower_32_bits(res.a2);
> + arm64_smccc_cache->rate_limit = lower_32_bits(res.a3);
> + arm64_smccc_cache->global_op = !!(res.a1 & SMCCC_CACHE_ATTR_GLOBAL_OP);
> +
> + ret = cache_coherency_ops_instance_register(&arm64_smccc_cache->cci);
> + if (ret) {
> + cache_coherency_ops_instance_put(&arm64_smccc_cache->cci);
> + arm64_smccc_cache = NULL;
> + return ret;
> + }
> +
> + pr_info("SMCCC cache clean+invalidate provider registered\n")
Trivial: blank line here. Just helps the error path stand out vs the
print.
> + return 0;
> +}
> +arch_initcall(arm64_smccc_cache_init);
^ permalink raw reply
* Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Mukesh Savaliya @ 2026-05-21 11:14 UTC (permalink / raw)
To: Carlos Song (OSS), Mukesh Savaliya, o.rempel@pengutronix.de,
kernel@pengutronix.de, andi.shyti@kernel.org, Frank Li,
s.hauer@pengutronix.de, festevam@gmail.com, Carlos Song,
Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <AM0PR04MB6802FE8B0E0BEF8CDA6DAD5EE80E2@AM0PR04MB6802.eurprd04.prod.outlook.com>
On 5/21/2026 4:21 PM, Carlos Song (OSS) wrote:
[...]
>>>> -----Original Message-----
>>>> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
>>>> Sent: Thursday, May 21, 2026 3:40 PM
>>>> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>;
>>>> o.rempel@pengutronix.de; kernel@pengutronix.de;
>>>> andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
>>>> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
>>>> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
>>>> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
>>>> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
>>>> stable@vger.kernel.org
>>>> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is
>>>> powered down
>>>>
>>>> Hi Carlos,
>>>>
>>>> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
>>>>> From: Carlos Song <carlos.song@nxp.com>
>>>>>
>>>>> Mark the I2C adapter as suspended during system suspend to block
>>>>> further transfers, and resume it on system resume. This prevents
>>>>> potential hangs when the hardware is powered down but clients still
>>>>> attempt
>>>> I2C transfers.
>>>>>
>> what was the reason of this hang ? I was thinking you don't have interrupts
>> working when client requested transfer but adapter was suspended. Please
>> correct me if wrong.
>>
>> And it would be good to mention the actual problem and why/how it occurred.
>>>> Code changes looks fine to me but have comment on commit log.
>>>>
>>>> It seems, you are adding support of _noirq() callbacks to allow
>>>> transfers during suspend/resume noirq phase of PM.
>>>>
>>>> Would it make sense if you can write "Replace system PM callbacks
>>>> with noirq PM callbacks" OR "Allow transfers during _noirq phase of
>>>> the PM ops" instead of "mark I2C adapter when hardware is powered
>> down" ?
>>>>
>>>
>>> Hi,
>>>
>>> Thank you for your comments!
>>>
>>> But this patch is added is not for support noirq PM callback or transfer in noirq
>> phase.
>>>
>> Okay, may be actual problem description can help me.
>>> In fact, this fix is to mark the I2C adapter as suspended during
>>> system noirq suspend to block further transfers, and resume it on
>>> system noirq resume. This is to prohibit I2C device calling the I2C
>>> controller after the system noirq suspend and before noirq resume, because at
>> this time the I2C instance is powered off or the clock is disabled ... So I want to
>> keep current commit. How do you think?
>> completely Makes sense. Please help add how this problem occurred and why ?
>> So the change/fix will be good to understand against it.
>
> Hi,
>
> In some I.MX platform, some I2C devices will keep a work queue all time, the work queue will
> trigger I2C xfer every once in a while, but the work queue shouldn't be free in system suspend.
>
work queue has transfers queued even if system is suspended ? IMO, the
client i2c devices should not let system go to suspend.
> Within a very short time window, possibly from noirq_suspend to the system actually being suspended,
> or possibly from the system starting to resume to before noirq_resume, this work queue will trigger an
> I2C transfer, and at this time the I2C controller's clk and pinctrl have not yet been restored, reading and
Right, this kind of explains the problem to me. I think you are trying
to serve i2c transfers when your resources(clk, pinctrl) are not turned
ON and also interrupt remains disabled. And that's why you need to add
_noir() PM callbacks supports along with IRQF_NO_SUSPEND |
IRQF_EARLY_RESUME flags.
> writing I2C registers causes the system to hang. This patch make all I2C operations are performed in a safe
> hardware state.
>
> Is it better if I add these comment to patch commit log?
>>>
if my latest comments makes sense against the issue, you may write
accordingly. if i am wrong, then your explanation makes sense. Cause of
the hang needs to be clearly mention int the commit log in your next patch.
>>> Carlos Song
>>
>
^ permalink raw reply
* Re: [PATCH v8 net-next 00/15] Add preliminary NETC switch support for i.MX94
From: patchwork-bot+netdevbpf @ 2026-05-21 11:10 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, robh, krzk+dt, conor+dt,
f.fainelli, frank.li, chleroy, horms, linux, maxime.chevallier,
andrew, olteanv, netdev, linux-kernel, devicetree, linuxppc-dev,
linux-arm-kernel, imx
In-Reply-To: <20260518082506.1318236-1-wei.fang@nxp.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 18 May 2026 16:24:51 +0800 you wrote:
> i.MX94 NETC (v4.3) integrates 802.1Q Ethernet switch functionality, the
> switch provides advanced QoS with 8 traffic classes and a full range of
> TSN standards capabilities. It has 3 user ports and 1 CPU port, and the
> CPU port is connected to an internal ENETC through the pseduo link, so
> instead of a back-to-back MAC, the lightweight "pseudo MAC" is used at
> both ends of the pseudo link to transfer Ethernet frames. The pseudo
> link provides a zero-copy interface (no serialization delay) and lower
> power (less logic and memory).
>
> [...]
Here is the summary with links:
- [v8,net-next,01/15] dt-bindings: net: dsa: update the description of 'dsa,member' property
https://git.kernel.org/netdev/net-next/c/0c89a779c373
- [v8,net-next,02/15] dt-bindings: net: dsa: add NETC switch
https://git.kernel.org/netdev/net-next/c/6d019124be60
- [v8,net-next,03/15] net: enetc: add pre-boot initialization for i.MX94 switch
https://git.kernel.org/netdev/net-next/c/f059d55fd8a0
- [v8,net-next,04/15] net: enetc: add basic operations to the FDB table
https://git.kernel.org/netdev/net-next/c/4566269803ff
- [v8,net-next,05/15] net: enetc: add support for the "Add" operation to VLAN filter table
https://git.kernel.org/netdev/net-next/c/d0ac4d4bd299
- [v8,net-next,06/15] net: enetc: add support for the "Update" operation to buffer pool table
https://git.kernel.org/netdev/net-next/c/cb4d95d79d85
- [v8,net-next,07/15] net: enetc: add support for "Add" and "Delete" operations to IPFT
https://git.kernel.org/netdev/net-next/c/123db6a27511
- [v8,net-next,08/15] net: enetc: add multiple command BD rings support
https://git.kernel.org/netdev/net-next/c/c5aed83ddc53
- [v8,net-next,09/15] net: dsa: add NETC switch tag support
https://git.kernel.org/netdev/net-next/c/0850005c26d2
- [v8,net-next,10/15] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
https://git.kernel.org/netdev/net-next/c/187fbae024c8
- [v8,net-next,11/15] net: dsa: netc: add phylink MAC operations
https://git.kernel.org/netdev/net-next/c/bbe97e347219
- [v8,net-next,12/15] net: dsa: netc: add FDB, STP, MTU, port setup and host flooding support
https://git.kernel.org/netdev/net-next/c/46d6407692c8
- [v8,net-next,13/15] net: dsa: netc: initialize buffer pool table and implement flow-control
https://git.kernel.org/netdev/net-next/c/a5ccb7f5e067
- [v8,net-next,14/15] net: dsa: netc: add support for the standardized counters
https://git.kernel.org/netdev/net-next/c/25049d8b6e6b
- [v8,net-next,15/15] net: dsa: netc: add support for ethtool private statistics
https://git.kernel.org/netdev/net-next/c/beb0e54f3806
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* RE: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered down
From: Carlos Song (OSS) @ 2026-05-21 10:51 UTC (permalink / raw)
To: Mukesh Savaliya, Carlos Song (OSS), o.rempel@pengutronix.de,
kernel@pengutronix.de, andi.shyti@kernel.org, Frank Li,
s.hauer@pengutronix.de, festevam@gmail.com, Carlos Song,
Bough Chen
Cc: linux-i2c@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <22af0378-a3c9-4403-a0ee-da794847f41d@oss.qualcomm.com>
> -----Original Message-----
> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
> Sent: Thursday, May 21, 2026 6:17 PM
> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>; Mukesh Savaliya
> <mukesh.savaliya@oss.qualcomm.com>; o.rempel@pengutronix.de;
> kernel@pengutronix.de; andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> stable@vger.kernel.org
> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is powered
> down
>
> [You don't often get email from mukesh.savaliya@oss.qualcomm.com. Learn
> why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Thanks Carlos !
>
> On 5/21/2026 1:57 PM, Carlos Song (OSS) wrote:
> >
> >
> >> -----Original Message-----
> >> From: Mukesh Savaliya <mukesh.savaliya@oss.qualcomm.com>
> >> Sent: Thursday, May 21, 2026 3:40 PM
> >> To: Carlos Song (OSS) <carlos.song@oss.nxp.com>;
> >> o.rempel@pengutronix.de; kernel@pengutronix.de;
> >> andi.shyti@kernel.org; Frank Li <frank.li@nxp.com>;
> >> s.hauer@pengutronix.de; festevam@gmail.com; Carlos Song
> >> <carlos.song@nxp.com>; Bough Chen <haibo.chen@nxp.com>
> >> Cc: linux-i2c@vger.kernel.org; imx@lists.linux.dev;
> >> linux-arm-kernel@lists.infradead.org; linux-kernel@vger.kernel.org;
> >> stable@vger.kernel.org
> >> Subject: Re: [PATCH v3] i2c: imx: mark I2C adapter when hardware is
> >> powered down
> >>
> >> [You don't often get email from mukesh.savaliya@oss.qualcomm.com.
> >> Learn why this is important at
> >> https://aka.ms/LearnAboutSenderIdentification ]
> >>
> >> Hi Carlos,
> >>
> >> On 5/20/2026 3:45 PM, Carlos Song (OSS) wrote:
> >>> From: Carlos Song <carlos.song@nxp.com>
> >>>
> >>> Mark the I2C adapter as suspended during system suspend to block
> >>> further transfers, and resume it on system resume. This prevents
> >>> potential hangs when the hardware is powered down but clients still
> >>> attempt
> >> I2C transfers.
> >>>
> what was the reason of this hang ? I was thinking you don't have interrupts
> working when client requested transfer but adapter was suspended. Please
> correct me if wrong.
>
> And it would be good to mention the actual problem and why/how it occurred.
> >> Code changes looks fine to me but have comment on commit log.
> >>
> >> It seems, you are adding support of _noirq() callbacks to allow
> >> transfers during suspend/resume noirq phase of PM.
> >>
> >> Would it make sense if you can write "Replace system PM callbacks
> >> with noirq PM callbacks" OR "Allow transfers during _noirq phase of
> >> the PM ops" instead of "mark I2C adapter when hardware is powered
> down" ?
> >>
> >
> > Hi,
> >
> > Thank you for your comments!
> >
> > But this patch is added is not for support noirq PM callback or transfer in noirq
> phase.
> >
> Okay, may be actual problem description can help me.
> > In fact, this fix is to mark the I2C adapter as suspended during
> > system noirq suspend to block further transfers, and resume it on
> > system noirq resume. This is to prohibit I2C device calling the I2C
> > controller after the system noirq suspend and before noirq resume, because at
> this time the I2C instance is powered off or the clock is disabled ... So I want to
> keep current commit. How do you think?
> completely Makes sense. Please help add how this problem occurred and why ?
> So the change/fix will be good to understand against it.
Hi,
In some I.MX platform, some I2C devices will keep a work queue all time, the work queue will
trigger I2C xfer every once in a while, but the work queue shouldn't be free in system suspend.
Within a very short time window, possibly from noirq_suspend to the system actually being suspended,
or possibly from the system starting to resume to before noirq_resume, this work queue will trigger an
I2C transfer, and at this time the I2C controller's clk and pinctrl have not yet been restored, reading and
writing I2C registers causes the system to hang. This patch make all I2C operations are performed in a safe
hardware state.
Is it better if I add these comment to patch commit log?
> >
> > Carlos Song
>
^ permalink raw reply
* Re: [PATCH] [RFC] arm64: mmu: use range based TLB flushing when hot unplugging memory
From: Balbir Singh @ 2026-05-21 10:46 UTC (permalink / raw)
To: Ryan Roberts
Cc: Alistair Popple, linux-arm-kernel, linux-kernel, linux-mm,
catalin.marinas, will, david, anshuman.khandual, dev.jain,
jhubbard
In-Reply-To: <bc96d822-bb68-4945-9f74-68f77e389ac6@arm.com>
On Thu, May 21, 2026 at 09:50:04AM +0100, Ryan Roberts wrote:
> On 21/05/2026 05:24, Alistair Popple wrote:
> > Hot unplugging memory on ARM64 requires a TLB invalidate after unmapping
> > the page to be hot unplugged from the direct map. Currently that happens
> > one page at a time, meaning range based invalidates cannot be used. The
> > result of this is that removing large amounts of memory takes a long
> > time and in some cases can trigger an RCU stall warning.
> >
> > For example on one system hot unplugging 480GB of memory takes ~1
> > minute. With this change the same operation took ~1 second, a 60x
> > improvement.
> >
> > Signed-off-by: Alistair Popple <apopple@nvidia.com>
> >
> > ---
> >
> > This is an RFC, because I'm not sure the change is correct as it frees
> > the PTE page before flushing the TLB. I'm not familiar enough with ARM64
> > architecture to be sure this is safe, for example I don't know if HW
> > can update PTE bits such as access/dirty in the page through a stale
> > TLB entry.
> >
> > If so this would open a window during which the page is free but could
> > still be written to. Likely the safe option would be to collect all the
> > pages to be free on a list and free them after doing the range based TLB
> > flush, but wanted to get feedback on the approach before implementing it
> > which is the goal of this RFC.
>
> Hi Alistair,
>
> This patch doesn't apply on v7.1-rc4 because it conflicts with this patch:
>
> Commit 48478b9f79137 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
>
> which has a very similar performance improvement, so hopefully it solves your
> problem?
>
> There are two paths which use this logic; unmapping the linear map and unmapping
> the corresponding vmemmap. In the latter case, the memory is also freed, so we
> can't safely do the range optimizaiton there since the TLB needs to be flushed
> before freeing the memory. But the linear map is the big, slow bit so hopefully
> it's sufficent for you?
>
I assume vmemmap path is for tearing down the struct pages corresponding
to the physical memory and vmemmap teardowns taking a flush should be
OK. It is worth checking if the issue is already fixed.
Balbir
<snip>
^ permalink raw reply
* Re: [PATCH v4 4/5] KVM: arm64: Fix bounds checking in do_ffa_mem_reclaim()
From: Mostafa Saleh @ 2026-05-21 10:43 UTC (permalink / raw)
To: Marc Zyngier
Cc: op-tee, linux-kernel, kvmarm, linux-arm-kernel, oupton,
joey.gouly, suzuki.poulose, catalin.marinas, jens.wiklander,
sumit.garg, sebastianene, vdonnefort, sudeep.holla
In-Reply-To: <ag7eq3bfBOxfaZ59@google.com>
On Thu, May 21, 2026 at 11:30 AM Mostafa Saleh <smostafa@google.com> wrote:
>
> Hi Marc,
>
> On Thu, May 21, 2026 at 09:28:46AM +0100, Marc Zyngier wrote:
> > On Wed, 20 May 2026 21:49:47 +0100,
> > Mostafa Saleh <smostafa@google.com> wrote:
> > >
> > > Sashiko (locally) reports out of bound write possiblity if SPMD
> > > returns an invalid data.
> > >
> > > While SPMD is considered trusted, pKVM does some basic checks,
> > > for offset to be less than or equal len.
> > >
> > > However, that is incorrect as even if the offset is smaller than
> > > len pKVM can still access out of bound memory in the next
> > > ffa_host_unshare_ranges().
> > >
> > > Split this check into 2:
> > > 1- Check that the fixed portion of the descriptor fits.
> > > 2- After getting reg, check the variable array size addr_range_cnt
> > > fits.
> > >
> > > Signed-off-by: Mostafa Saleh <smostafa@google.com>
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/ffa.c | 7 ++++++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/ffa.c b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > index 1af722771178..e6aa2bfa63b1 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/ffa.c
> > > @@ -607,7 +607,7 @@ static void do_ffa_mem_reclaim(struct arm_smccc_1_2_regs *res,
> > > * check that we end up with something that doesn't look _completely_
> > > * bogus.
> > > */
> > > - if (WARN_ON(offset > len ||
> > > + if (WARN_ON(offset + CONSTITUENTS_OFFSET(0) > len ||
> > > fraglen > KVM_FFA_MBOX_NR_PAGES * PAGE_SIZE)) {
> >
> > Do you really want to keep this a WARN_ON(), given that this results
> > in a panic in most pKVM configurations?
>
> Which kind of configuration will that check fail on?
> Does that mean at the moment pKVM does out-of-bound access for
> the header?
>
I might have misunderstood the point. I thought you meant the new
change would cause a panic on most configurations, or were you
suggesting just removing the WARN_ON?
I can do that, I just updated the current faulty check and left the
WARN_ON as is.
Thanks,
Mostafa
> Thanks,
> Mostafa
>
> >
> > Thanks,
> >
> > M.
> >
> > --
> > Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [soc:xz/dt] BUILD SUCCESS 7d1f68e87b7302d0bd22c001e6c0511d0e827875
From: kernel test robot @ 2026-05-21 10:43 UTC (permalink / raw)
To: Stefan Dösinger ; +Cc: linux-arm-kernel, arm
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git xz/dt
branch HEAD: 7d1f68e87b7302d0bd22c001e6c0511d0e827875 ARM: dts: zte: Add D-Link DWR-932M support
elapsed time: 829m
configs tested: 197
configs skipped: 3
The following configs have been built successfully.
More configs may be tested in the coming days.
tested configs:
alpha allnoconfig gcc-15.2.0
alpha allyesconfig gcc-15.2.0
alpha defconfig gcc-15.2.0
arc allmodconfig clang-16
arc allnoconfig gcc-15.2.0
arc allyesconfig clang-23
arc defconfig gcc-15.2.0
arc randconfig-001-20260521 gcc-8.5.0
arc randconfig-002-20260521 gcc-8.5.0
arm allnoconfig clang-23
arm allnoconfig gcc-15.2.0
arm allyesconfig clang-16
arm defconfig gcc-15.2.0
arm footbridge_defconfig clang-17
arm randconfig-001-20260521 gcc-8.5.0
arm randconfig-002-20260521 gcc-8.5.0
arm randconfig-003-20260521 gcc-8.5.0
arm randconfig-004-20260521 gcc-8.5.0
arm64 allmodconfig clang-23
arm64 allnoconfig gcc-15.2.0
arm64 defconfig gcc-15.2.0
arm64 randconfig-001-20260521 gcc-8.5.0
arm64 randconfig-002-20260521 gcc-8.5.0
arm64 randconfig-003-20260521 gcc-8.5.0
arm64 randconfig-004-20260521 gcc-8.5.0
csky allmodconfig gcc-15.2.0
csky allnoconfig gcc-15.2.0
csky defconfig gcc-15.2.0
csky randconfig-001-20260521 gcc-8.5.0
csky randconfig-002-20260521 gcc-8.5.0
hexagon allmodconfig gcc-15.2.0
hexagon allnoconfig clang-23
hexagon allnoconfig gcc-15.2.0
hexagon defconfig gcc-15.2.0
hexagon randconfig-001-20260521 gcc-11.5.0
hexagon randconfig-002-20260521 gcc-11.5.0
i386 allmodconfig clang-20
i386 allmodconfig gcc-14
i386 allnoconfig gcc-14
i386 allnoconfig gcc-15.2.0
i386 allyesconfig clang-20
i386 buildonly-randconfig-001-20260521 clang-20
i386 buildonly-randconfig-002-20260521 clang-20
i386 buildonly-randconfig-003-20260521 clang-20
i386 buildonly-randconfig-004-20260521 clang-20
i386 buildonly-randconfig-005-20260521 clang-20
i386 buildonly-randconfig-006-20260521 clang-20
i386 defconfig gcc-15.2.0
i386 randconfig-001-20260521 clang-20
i386 randconfig-002-20260521 clang-20
i386 randconfig-003-20260521 clang-20
i386 randconfig-004-20260521 clang-20
i386 randconfig-005-20260521 clang-20
i386 randconfig-006-20260521 clang-20
i386 randconfig-007-20260521 clang-20
i386 randconfig-011-20260521 gcc-14
i386 randconfig-012-20260521 gcc-14
i386 randconfig-013-20260521 gcc-14
i386 randconfig-014-20260521 gcc-14
i386 randconfig-015-20260521 gcc-14
i386 randconfig-016-20260521 gcc-14
i386 randconfig-017-20260521 gcc-14
loongarch allmodconfig clang-23
loongarch allnoconfig clang-23
loongarch allnoconfig gcc-15.2.0
loongarch defconfig clang-19
loongarch randconfig-001-20260521 gcc-11.5.0
loongarch randconfig-002-20260521 gcc-11.5.0
m68k allmodconfig gcc-15.2.0
m68k allnoconfig gcc-15.2.0
m68k allyesconfig clang-16
m68k defconfig clang-19
microblaze allnoconfig gcc-15.2.0
microblaze allyesconfig gcc-15.2.0
microblaze defconfig clang-19
mips allmodconfig gcc-15.2.0
mips allnoconfig gcc-15.2.0
mips allyesconfig gcc-15.2.0
mips cavium_octeon_defconfig gcc-15.2.0
mips rt305x_defconfig clang-23
nios2 10m50_defconfig gcc-11.5.0
nios2 allmodconfig clang-23
nios2 allnoconfig clang-23
nios2 defconfig clang-19
nios2 randconfig-001-20260521 gcc-11.5.0
nios2 randconfig-002-20260521 gcc-11.5.0
openrisc allmodconfig clang-23
openrisc allnoconfig clang-23
openrisc defconfig gcc-15.2.0
parisc allmodconfig gcc-15.2.0
parisc allnoconfig clang-23
parisc allyesconfig clang-19
parisc defconfig gcc-15.2.0
parisc randconfig-001-20260521 gcc-12.5.0
parisc randconfig-002-20260521 gcc-12.5.0
parisc64 defconfig clang-19
powerpc allmodconfig gcc-15.2.0
powerpc allnoconfig clang-23
powerpc mgcoge_defconfig clang-23
powerpc mpc837x_rdb_defconfig gcc-15.2.0
powerpc randconfig-001-20260521 gcc-12.5.0
powerpc randconfig-002-20260521 gcc-12.5.0
powerpc sam440ep_defconfig gcc-15.2.0
powerpc64 randconfig-001-20260521 gcc-12.5.0
powerpc64 randconfig-002-20260521 gcc-12.5.0
riscv allmodconfig clang-23
riscv allnoconfig clang-23
riscv allyesconfig clang-16
riscv defconfig gcc-15.2.0
riscv randconfig-001 gcc-15.2.0
riscv randconfig-001-20260521 gcc-15.2.0
riscv randconfig-002 gcc-15.2.0
riscv randconfig-002-20260521 gcc-15.2.0
s390 allmodconfig clang-19
s390 allnoconfig clang-23
s390 allyesconfig gcc-15.2.0
s390 defconfig gcc-15.2.0
s390 randconfig-001 gcc-15.2.0
s390 randconfig-001-20260521 gcc-15.2.0
s390 randconfig-002 gcc-15.2.0
s390 randconfig-002-20260521 gcc-15.2.0
sh allmodconfig gcc-15.2.0
sh allnoconfig clang-23
sh allyesconfig clang-19
sh defconfig gcc-14
sh randconfig-001 gcc-15.2.0
sh randconfig-001-20260521 gcc-15.2.0
sh randconfig-002 gcc-15.2.0
sh randconfig-002-20260521 gcc-15.2.0
sparc allnoconfig clang-23
sparc defconfig gcc-15.2.0
sparc randconfig-001-20260521 gcc-8.5.0
sparc randconfig-002-20260521 gcc-8.5.0
sparc64 allmodconfig clang-23
sparc64 defconfig gcc-14
sparc64 randconfig-001-20260521 gcc-8.5.0
sparc64 randconfig-002-20260521 gcc-8.5.0
um allmodconfig clang-19
um allnoconfig clang-23
um allyesconfig gcc-15.2.0
um defconfig gcc-14
um i386_defconfig gcc-14
um randconfig-001-20260521 gcc-8.5.0
um randconfig-002-20260521 gcc-8.5.0
um x86_64_defconfig gcc-14
x86_64 allmodconfig clang-20
x86_64 allnoconfig clang-23
x86_64 allyesconfig clang-20
x86_64 buildonly-randconfig-001-20260521 clang-20
x86_64 buildonly-randconfig-002-20260521 clang-20
x86_64 buildonly-randconfig-003-20260521 clang-20
x86_64 buildonly-randconfig-004-20260521 clang-20
x86_64 buildonly-randconfig-005-20260521 clang-20
x86_64 buildonly-randconfig-006-20260521 clang-20
x86_64 defconfig gcc-14
x86_64 kexec clang-20
x86_64 randconfig-001-20260521 clang-20
x86_64 randconfig-002-20260521 clang-20
x86_64 randconfig-003-20260521 clang-20
x86_64 randconfig-004-20260521 clang-20
x86_64 randconfig-005-20260521 clang-20
x86_64 randconfig-006-20260521 clang-20
x86_64 randconfig-011 gcc-14
x86_64 randconfig-011-20260521 gcc-14
x86_64 randconfig-012 gcc-14
x86_64 randconfig-012-20260521 gcc-14
x86_64 randconfig-013 gcc-14
x86_64 randconfig-013-20260521 gcc-14
x86_64 randconfig-014 gcc-14
x86_64 randconfig-014-20260521 gcc-14
x86_64 randconfig-015 gcc-14
x86_64 randconfig-015-20260521 gcc-14
x86_64 randconfig-016 gcc-14
x86_64 randconfig-016-20260521 gcc-14
x86_64 randconfig-071 clang-20
x86_64 randconfig-071-20260521 clang-20
x86_64 randconfig-072 clang-20
x86_64 randconfig-072-20260521 clang-20
x86_64 randconfig-073 clang-20
x86_64 randconfig-073-20260521 clang-20
x86_64 randconfig-074 clang-20
x86_64 randconfig-074-20260521 clang-20
x86_64 randconfig-075 clang-20
x86_64 randconfig-075-20260521 clang-20
x86_64 randconfig-076 clang-20
x86_64 randconfig-076-20260521 clang-20
x86_64 rhel-9.4 clang-20
x86_64 rhel-9.4-bpf gcc-14
x86_64 rhel-9.4-func clang-20
x86_64 rhel-9.4-kselftests clang-20
x86_64 rhel-9.4-kunit gcc-14
x86_64 rhel-9.4-ltp gcc-14
x86_64 rhel-9.4-rust clang-20
xtensa allnoconfig clang-23
xtensa allyesconfig clang-23
xtensa randconfig-001-20260521 gcc-8.5.0
xtensa randconfig-002-20260521 gcc-8.5.0
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ 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