* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Maxime Ripard @ 2026-07-20 14:28 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Laurent Pinchart, Maarten Lankhorst, Thomas Zimmermann,
David Airlie, Simona Vetter, Andrzej Hajda, Neil Armstrong,
Robert Foss, Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DK0QXI6KF7PC.3DJW38KB8MJED@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5552 bytes --]
On Fri, Jul 17, 2026 at 11:41:33AM +0200, Luca Ceresoli wrote:
> Hi Maxime,
>
> On Thu Jul 16, 2026 at 3:22 PM CEST, Maxime Ripard wrote:
> > On Thu, Jul 16, 2026 at 10:37:24AM +0200, Luca Ceresoli wrote:
> >> >> > Now if the bridges start doing it themselves we should go back to
> >> >> > those encoder drivers and ditch all the drm_bridge_connector from
> >> >> > there?
> >> >> >
> >> >> > I must be missing something. Can you elaborate on this?
> >> >>
> >> >> drm_bridge_connectors bring together a (complete) bridge chain and a
> >> >> connector. If you don't have either anymore, then we shouldn't keep it
> >> >> around.
> >> >>
> >> >> What I was suggesting before was only a suggestion. I guess we could
> >> >> also make the encoder own the hotplug handling code and create the
> >> >> drm_bridge_connector when the chain is complete, and remove it when it's
> >> >> no longer the case.
> >> >
> >> > That's an interesting option. We don't have to keep drm_bridge_connector
> >> > in its current form, but I don't think we should go back to individual
> >> > bridge driver creating connectors, especially now that we have bridge
> >> > chains where the connector ops are implemented collectively by multiple
> >> > bridges.
> >>
> >> I definitely agree we don't want to add burden back on the encoder.
> >
> > I don't think Laurent mentioned the encoder anywhere.
>
> Ah, indeed, sorry! However, I think both the bridges and the encoder
> drivers should equally have the minimum burden on them.
>
> Right now the recommended practice is:
>
> - bridges do not create connectors (thanks to DRM_BRIDGE_ATTACH_NO_CONNECTOR)
> - encoders just call drm_bridge_connector_init(), which does all the
> common operations to populate a suitable drm_connector
>
> So all common operations involved in connector creation and bridge chain
> analysis are implemented in common code, not per-bridge or
> per-encoder. That's good.
I agree, but another way to phrase it is: bridges aren't aware of how
the chain is setup, the encoder ties it all together.
> >> >> We can discuss alternatives too. But either way, we shouldn't have it
> >> >> stick around.
> >>
> >> Bottom line, I roughly see three ideas mentioned:
> >>
> >> 1. (this series) extend the drm_bridge_connector to create the
> >> drm_connector based on bridge hotplug events [+rename it]
> >> 2. - keep the drm_bridge_connector (mostly) as is
> >> - let each encoder driver add/remove it based on bridge hotplug events
> >> => more burden on encoder drivers -> no
> >
> > Can you motivate that with *any* reason? Because I really feel like it's
> > the best solution going forward.
>
> My understanding of your idea (maybe a bit overstressed just to ensure it's
> clear) is that:
>
> - the drm_bridge_connector should stay (almost) unmodified
Yes, and bridges should ideally remain as lightly affected as possible.
We have probably around 100 bridge drivers at the moment, having some
kind of opt-in to enable hotplug would mean that we can't expect hotplug
to work on a new platform, which should be a last resort.
> - there should be no new "manager" component (not sure this is actually
> your opinion, can you comment on this specifically?)
> - every encoder driver would have to:
> - register to receive hotplug events
> - when receiving one such event, find out whether the hardware is
> complete or not (by calling drm_bridge_connector_pipeline_is_complete()
> or so)
> - create/destroy a drm_bridge_connector based on hotplug events
>
> Is this somewhat close to what you have in mind?
Yes. To make things a bit more precise, we need two things: the encoder
to put the chain together, and "something" (that you used to call
manager) to react to hotplug events and handle the bridge
detach/destruction, connector creation/destruction, etc and should stick
around when we enable hotplug.
What I'm suggesting is that, since the encoder already owns and creates
the chain in the first place, and is there forever, it's only natural
for the encoder to be that "something", and we don't necessarily mean
creating a new entity or piece of code. A bunch of helpers and hooks a
probably going to be enough.
This is where the opt-in part should be, and I'd like, if possible, for
hotplug-enabled encoders to work with any bridge.
> To me the best solution to add hotplug support is that encoder drivers
> replace the single drm_bridge_connector_init() call with a single call to
> something new (let's call it a hotplug manager), which takes care of all
> the common aspects: registering to receive bridge hotplug events, finding
> out whether the hardware pipeline is complete or not, and add/remove the
> drm_connector based on that.
>
> In other words, the changes on encoder drivers would be similar to patch
> 37. In a nutshell:
>
> - connector = drm_bridge_connector_init(lcdif->drm, encoder);
> + drm_hotplug_manager = drm_hotplug_manager_init(lcdif->drm, encoder);
>
> All the hotplug logic would be in common code, and any maintenance and
> future improvements to it would stay in a single place, benefitting all
> encoders at once.
>
> What do you think about this?
From a high level point-of-view, I think we mostly agree. We can argue
on the name, and if we should merge it with something else
(drm_encoder_init, drm_bridge_attach, something else?) but that's the
path forward I think.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v4 7/8] phy: rockchip: samsung-hdptx: Simplify GRF access with FIELD_PREP_WM16()
From: Dmitry Baryshkov @ 2026-07-20 14:30 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov, kernel, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, Thomas Niederprüm,
Simon Wright
In-Reply-To: <20260612-hdptx-clk-fixes-v4-7-ce5e1d456cda@collabora.com>
On Fri, Jun 12, 2026 at 02:45:26AM +0300, Cristian Ciocaltea wrote:
> The 16 most significant bits of the general-purpose register (GRF) are
> used as a write-enable mask for the remaining 16 bits.
>
> Make use of the recently introduced FIELD_PREP_WM16() macro to avoid
> open-coding the bit shift operations and improve code readability.
>
> Tested-by: Thomas Niederprüm <dubito@online.de>
> Tested-by: Simon Wright <simon@symple.nz>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 52 +++++++++++------------
> 1 file changed, 25 insertions(+), 27 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v4 8/8] phy: rockchip: samsung-hdptx: Consistently use bitfield macros
From: Dmitry Baryshkov @ 2026-07-20 14:31 UTC (permalink / raw)
To: Cristian Ciocaltea
Cc: Vinod Koul, Neil Armstrong, Heiko Stuebner, Algea Cao,
Dmitry Baryshkov, kernel, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, Thomas Niederprüm,
Simon Wright
In-Reply-To: <20260612-hdptx-clk-fixes-v4-8-ce5e1d456cda@collabora.com>
On Fri, Jun 12, 2026 at 02:45:27AM +0300, Cristian Ciocaltea wrote:
> Make the code more robust and improve readability by using the available
> bitfield macros (e.g. FIELD_PREP, FIELD_GET) whenever possible, instead
> of open coding the related bit operations.
>
> Tested-by: Thomas Niederprüm <dubito@online.de>
> Tested-by: Simon Wright <simon@symple.nz>
> Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> ---
> drivers/phy/rockchip/phy-rockchip-samsung-hdptx.c | 30 +++++++++++++++--------
> 1 file changed, 20 insertions(+), 10 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()
From: Frank Li @ 2026-07-20 14:34 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla, brgl, driver-core,
linuxppc-dev, linux-kernel, linux-i2c, iommu, netdev, linux-pm,
imx, linux-arm-kernel, mfd, linux-arm-msm, linux-sound
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-3-2dee93f42c54@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 11:24:50AM +0200, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> drivers/iommu/fsl_pamu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/fsl_pamu.c b/drivers/iommu/fsl_pamu.c
> index c83bbc3faad56d6ee1c89b0a7f74028af02c81e9..268a1f752fbceab4fd24013aeea5df1b6982fbb1 100644
> --- a/drivers/iommu/fsl_pamu.c
> +++ b/drivers/iommu/fsl_pamu.c
> @@ -975,7 +975,7 @@ static __init int fsl_pamu_init(void)
> goto error_device_alloc;
> }
>
> - platform_device_set_of_node(pdev, np);
> + platform_device_set_fwnode(pdev, of_fwnode_handle(np));
>
> ret = pamu_domain_init();
> if (ret)
>
> --
> 2.47.3
>
>
^ permalink raw reply
* Re: [PATCH 3/8] iommu/fsl: use platform_device_set_fwnode()
From: Robin Murphy @ 2026-07-20 14:34 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: driver-core, linuxppc-dev, linux-kernel, linux-i2c, iommu, netdev,
linux-pm, imx, linux-arm-kernel, mfd, linux-arm-msm, linux-sound,
Bartosz Golaszewski, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Andi Shyti,
Joerg Roedel (AMD), Will Deacon, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla
In-Reply-To: <CAMRc=MefqCMgVv-o5hWoRwS2iXPQNs5nH2qHiz55+ew162LfSA@mail.gmail.com>
On 20/07/2026 2:39 pm, Bartosz Golaszewski wrote:
> On Mon, 20 Jul 2026 14:58:27 +0200, Robin Murphy <robin.murphy@arm.com> said:
>> On 20/07/2026 10:24 am, Bartosz Golaszewski wrote:
>>> Prefer the higher-level platform_device_set_fwnode() over the
>>> OF-specific platform_device_set_of_node() for dynamically allocated
>>> platform devices.
>>
>> This is very much non-portable code specific to OF-only platforms, but
>> if the intention is to remove platform_device_set_of_node() again
>> already, then FWIW,
>>
>
> Providing platform_device_set_of_node() and using it was done to make the
> transision to expanding reference counting to all firmware nodes possible.
> I don't think we'll remove it just yet as it doesn't make sense to convert
> the code under drivers/of/ to using the fwnode variant.
OK, but in that case why convert these users either? If the OF helper
does continue to exist then I'd imagine the static checker brigade will
eventually end up sending patches to "simplify" these open-coded
equivalents back to using it. And frankly, if drivers do know for sure
they're exclusively dealing with of_nodes, rather than doing something
conditional under an is_of_node() check, then I see little justification
for them *not* using the dedicated helper.
If the complaint is that there are no *public* users to justify
exporting platform_device_set_fwnode(), then as I say AFAICS that's much
more neatly addressed with the static inline approach, such that we
still get to unify the public APIs, actively eliminate something from
the symbol table and save a bit of source and object code, but without
any need to churn the truly OF-based callers at all.
Thanks,
Robin.
>
>> Acked-by: Robin Murphy <robin.murphy@arm.com>
>>
>> (Although I'm slightly puzzled by the cover letter - AFAICS in -next,
>> platform_device_set_of_node() is itself very much a user of
>> platform_device_set_fwnode(), however in terms of symbol exports,
>> perhaps the former could now just be a static inline wrapper?)
>>
>
> Sure that can be done independently later.
>
> Bart
^ permalink raw reply
* Re: [PATCH 5/8] pmdomain: imx: use platform_device_set_fwnode()
From: Frank Li @ 2026-07-20 14:34 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla, brgl, driver-core,
linuxppc-dev, linux-kernel, linux-i2c, iommu, netdev, linux-pm,
imx, linux-arm-kernel, mfd, linux-arm-msm, linux-sound
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-5-2dee93f42c54@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 11:24:52AM +0200, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/pmdomain/imx/gpc.c | 2 +-
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pmdomain/imx/gpc.c b/drivers/pmdomain/imx/gpc.c
> index abca5f449a226fbae4213926e1395c413160c950..c147eaf048ba2b79a744ec87029420981581e48e 100644
> --- a/drivers/pmdomain/imx/gpc.c
> +++ b/drivers/pmdomain/imx/gpc.c
> @@ -487,7 +487,7 @@ static int imx_gpc_probe(struct platform_device *pdev)
> domain->ipg_rate_mhz = ipg_rate_mhz;
>
> pd_pdev->dev.parent = &pdev->dev;
> - platform_device_set_of_node(pd_pdev, np);
> + platform_device_set_fwnode(pd_pdev, of_fwnode_handle(np));
>
> ret = platform_device_add(pd_pdev);
> if (ret) {
>
> --
> 2.47.3
>
>
^ permalink raw reply
* Re: [PATCH v3 2/4] media: synopsys: hdmirx: add HDMI audio capture support
From: Dmitry Osipenko @ 2026-07-20 14:36 UTC (permalink / raw)
To: Igor Paunovic
Cc: Mauro Carvalho Chehab, Sebastian Reichel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner, linux-media,
linux-rockchip, linux-arm-kernel, kernel, devicetree,
linux-kernel
In-Reply-To: <CAEWPSH70FecQRuGtA=S8+_CnLY5sMyf1j57Uwzwv54zceS1HZg@mail.gmail.com>
On 7/20/26 15:30, Igor Paunovic wrote:
> Hi Dmitry,
>
> Great to hear it works on the 5B -- thanks for testing!
>
> Agreed on the -EBUSY guard, done in my tree exactly as you wrote it.
> It also supersedes the suspend cancel/re-arm I had queued from the
> bot review: with suspend refused while audio_streaming is set, the
> worker can never be armed at suspend time, so those hunks are
> dropped.
>
> v4 follows shortly with this plus Sebastian's dts restructuring
> (shared disabled-by-default card in rk3588-extra.dtsi, renamed to
> "RK3588 HDMI-IN") and Krzysztof's binding comments (dai-common.yaml
> reference + unevaluatedProperties).
Re-arming will be best option if it works properly.
--
Best regards,
Dmitry
^ permalink raw reply
* Re: [PATCH 4/8] net: bcmgenet: use platform_device_set_fwnode()
From: Andrew Lunn @ 2026-07-20 14:38 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla, brgl, driver-core,
linuxppc-dev, linux-kernel, linux-i2c, iommu, netdev, linux-pm,
imx, linux-arm-kernel, mfd, linux-arm-msm, linux-sound
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-4-2dee93f42c54@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 11:24:51AM +0200, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
Why?
This driver is OF only. It does not support ACPI, and probably never
will. In general, networking and ACPI don't go together, ACPI is not
sufficiently advanced.
What is you use case here?
Andrew
^ permalink raw reply
* Re: [PATCH 1/3] usb: chipidea: Use %pe to print error pointers
From: Frank Li @ 2026-07-20 14:39 UTC (permalink / raw)
To: Subasri S
Cc: Peter Chen, Greg Kroah-Hartman, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Duncan Sands,
Chas Williams, Minas Harutyunyan, Hans de Goede, Heikki Krogerus,
Badhri Jagan Sridharan, linux-usb, imx, linux-arm-kernel,
linux-kernel, linux-atm-general, netdev
In-Reply-To: <20260719-usb-ptr_err_patchset-v1-1-85f7f2e4fefb@gmail.com>
On Sun, Jul 19, 2026 at 06:25:46PM +0530, Subasri S wrote:
>
> Use the %pe format specifier instead of %ld with PTR_ERR() for printing
> error pointers in imx_get_clks(), ci_hdrc_imx_probe(), and
> ci_get_platdata(). This prints symbolic error names (e.g. -ENOMEM)
> instead of errno numbers (e.g. -12), making error logs more readable.
>
> This patch fixes coccinelle reported warnings:
Avoid use words "This patch", just
Fix coccinelle reported warnings:
> ./chipidea/ci_hdrc_imx.c:452:5-12: WARNING: Consider using %pe to print PTR_ERR()
> ./chipidea/ci_hdrc_imx.c:468:5-12: WARNING: Consider using %pe to print PTR_ERR()
> ./chipidea/ci_hdrc_imx.c:222:4-11: WARNING: Consider using %pe to print PTR_ERR()
> ./chipidea/ci_hdrc_imx.c:222:24-31: WARNING: Consider using %pe to print PTR_ERR()
keep one is enough
> ./chipidea/core.c:684:4-11: WARNING: Consider using %pe to print PTR_ERR()
>
> Compile-tested only.
>
> Signed-off-by: Subasri S <subasris1210@gmail.com>
> ---
> drivers/usb/chipidea/ci_hdrc_imx.c | 12 ++++++------
> drivers/usb/chipidea/core.c | 4 ++--
> 2 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci_hdrc_imx.c b/drivers/usb/chipidea/ci_hdrc_imx.c
> index 56d2ba824a0b..7bfe37ed68ae 100644
> --- a/drivers/usb/chipidea/ci_hdrc_imx.c
> +++ b/drivers/usb/chipidea/ci_hdrc_imx.c
> @@ -218,8 +218,8 @@ static int imx_get_clks(struct device *dev)
> if (IS_ERR(data->clk)) {
> ret = PTR_ERR(data->clk);
> dev_err(dev,
> - "Failed to get clks, err=%ld,%ld\n",
> - PTR_ERR(data->clk), PTR_ERR(data->clk_ipg));
> + "Failed to get clks, err=%pe,%pe\n",
> + data->clk, data->clk_ipg);
> return ret;
> }
> /* Get wakeup clock. Not all of the platforms need to
> @@ -448,8 +448,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> pinctrl_hsic_idle = pinctrl_lookup_state(data->pinctrl, "idle");
> if (IS_ERR(pinctrl_hsic_idle)) {
> dev_err(dev,
> - "pinctrl_hsic_idle lookup failed, err=%ld\n",
> - PTR_ERR(pinctrl_hsic_idle));
> + "pinctrl_hsic_idle lookup failed, err=%pe\n",
> + pinctrl_hsic_idle);
> ret = PTR_ERR(pinctrl_hsic_idle);
> goto err_put;
> }
> @@ -464,8 +464,8 @@ static int ci_hdrc_imx_probe(struct platform_device *pdev)
> "active");
> if (IS_ERR(data->pinctrl_hsic_active)) {
> dev_err(dev,
> - "pinctrl_hsic_active lookup failed, err=%ld\n",
> - PTR_ERR(data->pinctrl_hsic_active));
> + "pinctrl_hsic_active lookup failed, err=%pe\n",
> + data->pinctrl_hsic_active);
> ret = PTR_ERR(data->pinctrl_hsic_active);
> goto err_put;
> }
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index 07563be0013f..09db8a4eace2 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -680,8 +680,8 @@ static int ci_get_platdata(struct device *dev,
> /* no vbus regulator is needed */
> platdata->reg_vbus = NULL;
> } else if (IS_ERR(platdata->reg_vbus)) {
> - dev_err(dev, "Getting regulator error: %ld\n",
> - PTR_ERR(platdata->reg_vbus));
> + dev_err(dev, "Getting regulator error: %pe\n",
> + platdata->reg_vbus);
> return PTR_ERR(platdata->reg_vbus);
> }
> /* Get TPL support */
>
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [PATCH net v2] net: stmmac: dwmac4: mask interrupts when stopping DMA in suspend
From: Maxime Chevallier @ 2026-07-20 14:40 UTC (permalink / raw)
To: Luis Lang, netdev
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Maxime Coquelin, Alexandre Torgue,
Russell King (Oracle), Oleksij Rempel, Ovidiu Panait,
Rohan G Thomas, moderated list:ARM/STM32 ARCHITECTURE,
moderated list:ARM/STM32 ARCHITECTURE, open list
In-Reply-To: <20260720111534.163416-1-luis.la@mail.de>
Hi Luis,
On 7/20/26 13:15, Luis Lang wrote:
> Since commit 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU
> interrupts"), suspending causes an interrupt storm from the RPS
> interrupt.
> Fix this by adding a deinit_chan() op to stmmac_dma_ops, which
> masks all default dma channel interrupts. This is called from
> stmmac_stop_all_dma(), so interrupts don't trigger while suspending.
>
> Fixes: 1b9707e6f1a9 ("net: stmmac: enable RPS and RBU interrupts")
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Suggested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> Signed-off-by: Luis Lang <luis.la@mail.de>
I wasn't able to reproduce the original issue on dwmac4, however
I could test that suspend/resume as well as WoL still works on a
dwmac4 device with this patch applied.
Thanks for the patch !
Tested-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Maxime
> ---
> .../net/ethernet/stmicro/stmmac/dwmac4_dma.c | 24 +++++++++++++++++++
> drivers/net/ethernet/stmicro/stmmac/hwif.h | 4 ++++
> .../net/ethernet/stmicro/stmmac/stmmac_main.c | 4 ++++
> 3 files changed, 32 insertions(+)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> index 829a23bdad01..23ffe1adcd0d 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
> @@ -106,6 +106,17 @@ static void dwmac4_dma_init_channel(struct stmmac_priv *priv,
> ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
> }
>
> +static void dwmac4_dma_deinit_channel(struct stmmac_priv *priv,
> + void __iomem *ioaddr, u32 chan)
> +{
> + const struct dwmac4_addrs *dwmac4_addrs = priv->plat->dwmac4_addrs;
> + u32 value;
> +
> + value = readl(ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
> + value &= ~DMA_CHAN_INTR_DEFAULT_MASK;
> + writel(value, ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
> +}
> +
> static void dwmac410_dma_init_channel(struct stmmac_priv *priv,
> void __iomem *ioaddr,
> struct stmmac_dma_cfg *dma_cfg, u32 chan)
> @@ -125,6 +136,17 @@ static void dwmac410_dma_init_channel(struct stmmac_priv *priv,
> ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
> }
>
> +static void dwmac410_dma_deinit_channel(struct stmmac_priv *priv,
> + void __iomem *ioaddr, u32 chan)
> +{
> + const struct dwmac4_addrs *dwmac4_addrs = priv->plat->dwmac4_addrs;
> + u32 value;
> +
> + value = readl(ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
> + value &= ~DMA_CHAN_INTR_DEFAULT_MASK_4_10;
> + writel(value, ioaddr + DMA_CHAN_INTR_ENA(dwmac4_addrs, chan));
> +}
> +
> static void dwmac4_dma_init(void __iomem *ioaddr,
> struct stmmac_dma_cfg *dma_cfg)
> {
> @@ -548,6 +570,7 @@ const struct stmmac_dma_ops dwmac4_dma_ops = {
> .reset = dwmac4_dma_reset,
> .init = dwmac4_dma_init,
> .init_chan = dwmac4_dma_init_channel,
> + .deinit_chan = dwmac4_dma_deinit_channel,
> .init_rx_chan = dwmac4_dma_init_rx_chan,
> .init_tx_chan = dwmac4_dma_init_tx_chan,
> .axi = dwmac4_dma_axi,
> @@ -577,6 +600,7 @@ const struct stmmac_dma_ops dwmac410_dma_ops = {
> .reset = dwmac4_dma_reset,
> .init = dwmac4_dma_init,
> .init_chan = dwmac410_dma_init_channel,
> + .deinit_chan = dwmac410_dma_deinit_channel,
> .init_rx_chan = dwmac4_dma_init_rx_chan,
> .init_tx_chan = dwmac4_dma_init_tx_chan,
> .axi = dwmac4_dma_axi,
> diff --git a/drivers/net/ethernet/stmicro/stmmac/hwif.h b/drivers/net/ethernet/stmicro/stmmac/hwif.h
> index e6317b94fff7..04dafec021b4 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/hwif.h
> +++ b/drivers/net/ethernet/stmicro/stmmac/hwif.h
> @@ -170,6 +170,8 @@ struct stmmac_dma_ops {
> void (*init)(void __iomem *ioaddr, struct stmmac_dma_cfg *dma_cfg);
> void (*init_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
> struct stmmac_dma_cfg *dma_cfg, u32 chan);
> + void (*deinit_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
> + u32 chan);
> void (*init_rx_chan)(struct stmmac_priv *priv, void __iomem *ioaddr,
> struct stmmac_dma_cfg *dma_cfg,
> dma_addr_t phy, u32 chan);
> @@ -235,6 +237,8 @@ struct stmmac_dma_ops {
> stmmac_do_void_callback(__priv, dma, init, __args)
> #define stmmac_init_chan(__priv, __args...) \
> stmmac_do_void_callback(__priv, dma, init_chan, __priv, __args)
> +#define stmmac_deinit_chan(__priv, __args...) \
> + stmmac_do_void_callback(__priv, dma, deinit_chan, __priv, __args)
> #define stmmac_init_rx_chan(__priv, __args...) \
> stmmac_do_void_callback(__priv, dma, init_rx_chan, __priv, __args)
> #define stmmac_init_tx_chan(__priv, __args...) \
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index 2a0d7eff88d3..af29a50ddb89 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -2560,6 +2560,7 @@ static void stmmac_stop_all_dma(struct stmmac_priv *priv)
> {
> u8 rx_channels_count = priv->plat->rx_queues_to_use;
> u8 tx_channels_count = priv->plat->tx_queues_to_use;
> + u8 dma_csr_ch = max(rx_channels_count, tx_channels_count);
> u8 chan;
>
> for (chan = 0; chan < rx_channels_count; chan++)
> @@ -2567,6 +2568,9 @@ static void stmmac_stop_all_dma(struct stmmac_priv *priv)
>
> for (chan = 0; chan < tx_channels_count; chan++)
> stmmac_stop_tx_dma(priv, chan);
> +
> + for (chan = 0; chan < dma_csr_ch; chan++)
> + stmmac_deinit_chan(priv, priv->ioaddr, chan);
> }
>
> /**
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: iommu: arm,smmu: Document interconnects property
From: Dmitry Baryshkov @ 2026-07-20 14:40 UTC (permalink / raw)
To: Bibek Kumar Patro
Cc: Bjorn Andersson, Will Deacon, Robin Murphy, Joerg Roedel,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Rob Clark, linux-arm-kernel, iommu, devicetree, linux-kernel,
linux-arm-msm, Krzysztof Kozlowski
In-Reply-To: <9f31bf3d-3c7d-45ba-bc25-e6349f689b70@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 07:41:35PM +0530, Bibek Kumar Patro wrote:
>
>
> On 7/8/2026 8:48 PM, Bjorn Andersson wrote:
> > On Wed, Jul 08, 2026 at 08:22:00PM +0530, Bibek Kumar Patro wrote:
> > >
> > >
> > > On 7/7/2026 10:12 PM, Dmitry Baryshkov wrote:
> > > > On Tue, Jul 07, 2026 at 06:06:59PM +0530, Bibek Kumar Patro wrote:
> > > > >
> > > > >
> > > > > On 7/6/2026 11:09 PM, Dmitry Baryshkov wrote:
> > > > > > On Mon, Jul 06, 2026 at 10:26:34PM +0530, Bibek Kumar Patro wrote:
> > > > > > > Some SoC implementations require a bandwidth vote on an interconnect
> > > > > > > path before the SMMU register space is accessible. Add the optional
> > > > > >
> > > > > > Why is it limited only to those SoCs? Is it also applicable to other
> > > > > > Qualcomm SoCs?
> > > > > >
> > > > >
> > > > > I was hoping to keep this series focused on the core infrastructure
> > > > > changes: the bindings, base ICC bandwidth-voting support, and DT
> > > > > interconnect properties for the platforms currently supported on
> > > > > Qualcomm Linux and have been validated so far.
> > > > >
> > > > > The additional targets have not been tested yet, so I'd prefer
> > > > > to add their support in a separate follow-up series once validation
> > > > > is complete, rather than growing this series further. WDYT?
> > > >
> > > > Then it should be a part of the commit message. All SoCs since SDM12345
> > > > need to vote on the interconnect (and then, in the cover letter mention
> > > > that you convert only a few of the SoCs). We possibly can help with
> > > > testing on other platforms.
> > > >
> > >
> > > Ack, sounds reasonable.
> > > I'll add the first platform onwards which interconnect voting is required in
> > > commit description.
> >
> > But to what degree is this related to a specific set of platforms? If we
> > look ahead, aren't we expecting the list to grow to include all
> > platforms in the end - resulting in a lot of noise and churn.
> >
>
> We have seen this issue consistently on SM8750 and later platforms, along
> with at least one customer-reported instance on SM8550. As a result,
> downstream Android implementations already vote for the required
> interconnect bandwidth explicitly on these platforms.
>
> On Qualcomm Linux targets, we have observed similar issues on Kodiak, with a
> few occurrences on Talos as well.
>
> My understanding is that the interconnects property remains optional, but in
> practice it is needed for Adreno SMMU operation on these platforms.
So, it goes back to Kodiak and Talos. What about SM8150? SDM845? Earlier
platforms? Is it limited to MMU-500? A6xx+?
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH] thermal/drivers/mediatek/lvts_thermal: Make reset optional for MT8196
From: AngeloGioacchino Del Regno @ 2026-07-20 14:42 UTC (permalink / raw)
To: rafael
Cc: daniel.lezcano, rui.zhang, lukasz.luba, p.zabel, matthias.bgg,
angelogioacchino.delregno, laura.nao, fshao, wenst, jiapeng.chong,
frank-w, linux-pm, linux-kernel, linux-arm-kernel, linux-mediatek,
kernel
Depending on the SoC+Firmware combination, the LVTS hardware may be
may be actively used by one or even multiple concurrent MCUs!
In this case, resetting it may produce either a severe slowdown of
the entire system, or even a thermal protection AP reset, as some
MCU(s) may be reading a very high or very low temperature while the
LVTS is being reset.
On those, don't fail if no reset is found as that may be omitted on
purpose, but still check if there's one, because some board(s) may
be running on a different bootchain with reduced firmwares or using
firmwares with reduced functionality.
Add a new "optional_reset" member to lvts_data and use it to check
whether the resets should be mandatory or not.
Also, while at it, since devm_reset_control_get_by_index() is now
deprecated, change the probe function to instead call function
devm_reset_control_get_exclusive_by_index(), which does the same.
Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
drivers/thermal/mediatek/lvts_thermal.c | 29 ++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/thermal/mediatek/lvts_thermal.c b/drivers/thermal/mediatek/lvts_thermal.c
index 92711896ce24..6670b5458f2c 100644
--- a/drivers/thermal/mediatek/lvts_thermal.c
+++ b/drivers/thermal/mediatek/lvts_thermal.c
@@ -160,6 +160,7 @@ struct lvts_data {
int gt_calib_bit_offset;
unsigned int def_calibration;
u16 msr_offset;
+ bool optional_reset;
};
struct lvts_sensor {
@@ -1473,9 +1474,29 @@ static int lvts_probe(struct platform_device *pdev)
if (IS_ERR(lvts_td->base))
return dev_err_probe(dev, PTR_ERR(lvts_td->base), "Failed to map io resource\n");
- lvts_td->reset = devm_reset_control_get_by_index(dev, 0);
- if (IS_ERR(lvts_td->reset))
- return dev_err_probe(dev, PTR_ERR(lvts_td->reset), "Failed to get reset control\n");
+ /*
+ * Depending on the SoC+Firmware combination, the LVTS hardware may be
+ * may be actively used by one or even multiple concurrent MCUs!
+ * In this case, resetting it may produce either a severe slowdown of
+ * the entire system, or even a thermal protection AP reset, as some
+ * MCU(s) may be reading a very high or very low temperature while the
+ * LVTS is being reset.
+ *
+ * On those, don't fail if no reset is found as that may be omitted on
+ * purpose, but still check if there's one, because some board(s) may
+ * be running on a different bootchain with reduced firmwares or using
+ * firmwares with reduced functionality.
+ */
+ lvts_td->reset = devm_reset_control_get_exclusive_by_index(dev, 0);
+ if (IS_ERR(lvts_td->reset)) {
+ if (lvts_data->optional_reset) {
+ dev_dbg(dev, "No reset found. LVTS may be used by firmware.\n");
+ lvts_td->reset = NULL;
+ } else {
+ return dev_err_probe(dev, PTR_ERR(lvts_td->reset),
+ "Failed to get reset control\n");
+ }
+ }
irq = platform_get_irq(pdev, 0);
if (irq < 0)
@@ -2163,6 +2184,7 @@ static const struct lvts_data mt8196_lvts_mcu_data = {
.num_cal_offsets = LVTS_NUM_CAL_OFFSETS_MT8196,
.msr_offset = LVTS_MSR_OFFSET_MT8196,
.ops = &lvts_platform_ops_mt8196,
+ .optional_reset = true,
};
static const struct lvts_data mt8196_lvts_ap_data = {
@@ -2175,6 +2197,7 @@ static const struct lvts_data mt8196_lvts_ap_data = {
.num_cal_offsets = LVTS_NUM_CAL_OFFSETS_MT8196,
.msr_offset = LVTS_MSR_OFFSET_MT8196,
.ops = &lvts_platform_ops_mt8196,
+ .optional_reset = true,
};
static const struct of_device_id lvts_of_match[] = {
--
2.55.0
^ permalink raw reply related
* Re: [RFC PATCH] firmware: scmi: Make SCMI arch independent
From: Guenter Roeck @ 2026-07-20 14:43 UTC (permalink / raw)
To: Ulf Hansson, Cristian Marussi
Cc: Michal Simek, linux-kernel, monstr, git, vincent.guittot,
Souvik.Chakravarty, Alex Shi, Andy Shevchenko,
Bartosz Golaszewski, Brian Masney, David Lechner, Dongliang Mu,
Fabio Estevam, Frank Li, Jonathan Cameron, Jonathan Corbet,
Len Brown, Liam Girdwood, Linus Walleij, Lukasz Luba, Mark Brown,
Michael Turquette, Nuno Sá, Pavel Machek, Peng Fan,
Pengutronix Kernel Team, Philipp Zabel, Rafael J. Wysocki,
Sascha Hauer, Shuah Khan, Stephen Boyd, Sudeep Holla, Ulf Hansson,
Viresh Kumar, Yanteng Si, arm-scmi,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
linux-arm-kernel, open list:COMMON CLK FRAMEWORK,
open list:DOCUMENTATION, open list:GPIO SUBSYSTEM,
open list:HARDWARE MONITORING,
open list:IIO SUBSYSTEM AND DRIVERS, open list:ENERGY MODEL
In-Reply-To: <CAPx+jO9KMcxnmt-wT5jaApj9p7s11B6eSG6K08Jt9J=-vXxjhA@mail.gmail.com>
On 7/14/26 06:16, Ulf Hansson wrote:
> On Thu, Jul 9, 2026 at 5:56 PM Cristian Marussi
> <cristian.marussi@arm.com> wrote:
>>
>> On Thu, Jul 09, 2026 at 03:27:00PM +0200, Michal Simek wrote:
>>> On heterogenious systems like AMD/Xilinx FPGA there is a need to talk to
>>> SCMI server from different architectures than ARM that's why remove
>>> ARM/ARM64 Kconfig dependency with also remove ARM from description and
>>> rename folder to reflect it.
>>
>> While I understand dropping the dependency on ARM (I always wanted to do
>> that and test if it worked at all on some otehr archs with QEMU), I am
>> not sure about the whole renaming party ? why is needed just for
>> cosmetic reasons ? it is at the end an arm originated protocol so I dont
>> see it as a being wrong to be named as such even though used by other
>> archs...I have not really strong opinion on this...
>
> This is certainly not my call to make, but I have to admit that I
> fully agree with the above.
>
> Usually we don't rename files that indicate a legacy platform name,
> just because a new company/platform wants to make use of it.
>
I agree.
Guenter
^ permalink raw reply
* Re: [PATCH 7/8] net: mv643xx: use platform_device_set_fwnode()
From: Andrew Lunn @ 2026-07-20 14:43 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Andi Shyti, Joerg Roedel (AMD),
Will Deacon, Robin Murphy, Andy Shevchenko, Doug Berger,
Florian Fainelli, Broadcom internal kernel review list,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ulf Hansson, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lee Jones,
Sebastian Hesselbarth, Srinivas Kandagatla, brgl, driver-core,
linuxppc-dev, linux-kernel, linux-i2c, iommu, netdev, linux-pm,
imx, linux-arm-kernel, mfd, linux-arm-msm, linux-sound
In-Reply-To: <20260720-pdev-set-fwnode-instead-of-of-node-v1-7-2dee93f42c54@oss.qualcomm.com>
On Mon, Jul 20, 2026 at 11:24:54AM +0200, Bartosz Golaszewski wrote:
> Prefer the higher-level platform_device_set_fwnode() over the
> OF-specific platform_device_set_of_node() for dynamically allocated
> platform devices.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
> ---
> drivers/net/ethernet/marvell/mv643xx_eth.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c b/drivers/net/ethernet/marvell/mv643xx_eth.c
> index 9caa1e47c174c9d7a161b7f2e2ee12a829b813d4..2f2d6cce8d852b9ec3ab42678a04a7915d1f00cc 100644
> --- a/drivers/net/ethernet/marvell/mv643xx_eth.c
> +++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
> @@ -2780,7 +2780,7 @@ static int mv643xx_eth_shared_of_add_port(struct platform_device *pdev,
> goto put_err;
> }
> ppdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> - platform_device_set_of_node(ppdev, pnp);
> + platform_device_set_fwnode(ppdev, of_fwnode_handle(pnp));
This is definitely an OF only driver. There are no other calls to
fwnode functions in this driver, so this is the wrong thing to do.
Sorry, NACK.
Andrew
^ permalink raw reply
* Re: [PATCH] clk: mmp: allow COMPILE_TEST builds
From: Duje Mihanović @ 2026-07-20 14:46 UTC (permalink / raw)
To: linux-clk, Rosen Penev
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, open list,
moderated list:ARM/Marvell PXA1908 SOC support,
open list:CLANG/LLVM BUILD SUPPORT:Keyword:b(?i:clang|llvm)b
In-Reply-To: <20260719214349.734351-1-rosenp@gmail.com>
On Sunday, 19 July 2026 23:43:49 Central European Summer Time Rosen Penev
wrote:
[...]
> diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> index 4b2c089f46a1..8383f9f1da51 100644
> --- a/drivers/clk/Makefile
> +++ b/drivers/clk/Makefile
> @@ -130,7 +130,7 @@ obj-y +=
mediatek/
> obj-$(CONFIG_ARCH_MESON) += meson/
> obj-y += microchip/
> ifeq ($(CONFIG_COMMON_CLK), y)
> -obj-$(CONFIG_ARCH_MMP) += mmp/
> +obj-$(CONFIG_COMMON_CLK_MMP) += mmp/
Could it be possible to select mmp unconditionally, like most of the other
subtrees are? AFAICT, that would also require creating new Kconfig symbols for
the PXA168, PXA910 and PXA1928 clocks, but I suspect it may be the more proper
choice in the long term.
Regards,
--
Duje
^ permalink raw reply
* Re: [PATCH v2 14/18] KVM: arm64: Use noclear for PGD in __pkvm_init_vm error path
From: Vincent Donnefort @ 2026-07-20 13:41 UTC (permalink / raw)
To: Fuad Tabba
Cc: maz, oliver.upton, joey.gouly, suzuki.poulose, yuzenghui,
catalin.marinas, will, linux-arm-kernel, kvmarm, kernel-team,
qperret
In-Reply-To: <CA+EHjTyFavaVQ=bmo=1s9LgDVQftdsCELUudSza1ARZCJo+dqw@mail.gmail.com>
On Wed, Jul 15, 2026 at 01:09:12PM +0100, Fuad Tabba wrote:
> On Mon, 6 Jul 2026 at 18:54, Vincent Donnefort <vdonnefort@google.com> wrote:
> >
> > In the error path of __pkvm_init_vm(), use unmap_donated_memory_noclear()
> > instead of the clearing variant to release the donated stage-2 PGD back
> > to the host.
> >
> > This intends to eliminate the clearing variant of
> > unmap_donated_memory(), as zeroing the PGD memory before returning it to
> > the host is unnecessary in this failure path.
> >
> > Signed-off-by: Vincent Donnefort <vdonnefort@google.com>
> >
> > diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > index d9ab58226889..0c82f1ddb93d 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > @@ -861,7 +861,7 @@ int __pkvm_init_vm(struct kvm *host_kvm, unsigned long vm_hva,
> > kvm_guest_destroy_stage2(hyp_vm);
> > err_remove_mappings:
> > unmap_donated_memory(hyp_vm, vm_size);
> > - unmap_donated_memory(pgd, pgd_size);
> > + unmap_donated_memory_noclear(pgd, pgd_size);
>
>
> We spoke about this in person before you sent the series and I thought
> it was ok. Sashiko's review made me doubt at first, since the freed
> blocks carry EL2 list_head pointers that the noclear variant hands
> back to the host.
>
> You mentioned that the mapping isn't secret (later when we discussed
> Sashiko's review in person), and I checked: kvm_compute_layout() runs
> at EL1 on the host and rolls the tag itself. The host already knows
> the PA of every page it donated, so it can compute those VAs anyway.
> So I don't think this is a real leak.
>
> However, this relies on the pool and hyp_vm both being donated
> linear-map memory here. Once hyp_vm moves to hyp_alloc() in the
> private range, the free_area anchor becomes a private-range VA, and I
> haven't checked whether that's host-derivable.
>
> Given it's the init error path and not hot, clearing costs basically
> nothing, so I'd lean towards just keeping unmap_donated_memory()
> rather than reasoning about derivability.
>
> What do you think?
Happy to not take any risk and to drop it. It was just an attempt to simplify
the code anyway.
>
>
>
> /fuad
>
> > err_unpin_kvm:
> > hyp_unpin_shared_mem(host_kvm, host_kvm + 1);
> > return ret;
> > --
> > 2.55.0.rc2.803.g1fd1e6609c-goog
> >
^ permalink raw reply
* Re: [PATCH] mailbox: Remove redundant dev_err()/dev_err_probe()
From: Chen-Yu Tsai @ 2026-07-20 14:53 UTC (permalink / raw)
To: Pan Chuang
Cc: Jassi Brar, Viresh Kumar, Tushar Khandelwal, Sudeep Holla,
Cristian Marussi, Marek Behún, Florian Fainelli,
Broadcom internal kernel review list, Ray Jui, Scott Branden,
Conor Dooley, Daire McNamara, Sibi Sankar, Manivannan Sadhasivam,
Orson Zhai, Baolin Wang, Chunyan Zhang, Maxime Coquelin,
Alexandre Torgue, Jernej Skrabec, Samuel Holland, Thierry Reding,
Jonathan Hunter, open list:MAILBOX API,
moderated list:MAILBOX ARM MHUv3,
moderated list:BROADCOM BCM2711/BCM2835 ARM ARCHITECTURE,
open list:RISC-V MICROCHIP SUPPORT,
open list:QUALCOMM CPUCP MAILBOX DRIVER,
moderated list:ARM/STM32 ARCHITECTURE,
open list:ARM/Allwinner sunXi SoC support,
open list:TEGRA ARCHITECTURE SUPPORT
In-Reply-To: <20260716025215.33592-1-panchuang@vivo.com>
On Thu, Jul 16, 2026 at 10:52 AM Pan Chuang <panchuang@vivo.com> wrote:
>
> Since commit 55b48e23f5c4 ("genirq/devres: Add error handling in
> devm_request_*_irq()"), devm_request_irq() and devm_request_threaded_irq()
> automatically log detailed error messages on failure. Remove the
> now-redundant driver-specific dev_err() and dev_err_probe() calls.
>
> Signed-off-by: Pan Chuang <panchuang@vivo.com>
> ---
> drivers/mailbox/arm_mhu_db.c | 1 -
> drivers/mailbox/arm_mhuv2.c | 9 ++-------
> drivers/mailbox/arm_mhuv3.c | 5 ++---
> drivers/mailbox/armada-37xx-rwtm-mailbox.c | 4 +---
> drivers/mailbox/bcm-pdc-mailbox.c | 5 +----
> drivers/mailbox/bcm2835-mailbox.c | 5 +----
> drivers/mailbox/bcm74110-mailbox.c | 2 +-
> drivers/mailbox/cv1800-mailbox.c | 2 +-
> drivers/mailbox/hi6220-mailbox.c | 5 +----
> drivers/mailbox/mailbox-mpfs.c | 2 --
> drivers/mailbox/mailbox-sti.c | 4 +---
> drivers/mailbox/qcom-cpucp-mbox.c | 2 +-
> drivers/mailbox/qcom-ipcc.c | 4 +---
> drivers/mailbox/sprd-mailbox.c | 12 +++---------
> drivers/mailbox/stm32-ipcc.c | 4 +---
> drivers/mailbox/sun6i-msgbox.c | 4 +---
Acked-by: Chen-Yu Tsai <wens@kernel.org> # sun6i
^ permalink raw reply
* Re: [PATCH RFC] arm64: dts: allwinner: a523: Add SPDIF to x96qproplus device
From: Chen-Yu Tsai @ 2026-07-20 14:59 UTC (permalink / raw)
To: Per Larsson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:ARM/Allwinner sunXi SoC support,
open list:ARM/Allwinner sunXi SoC support, open list
In-Reply-To: <20260719030927.2417-1-per@palvencia.se>
On Sun, Jul 19, 2026 at 11:10 AM Per Larsson <per@palvencia.se> wrote:
>
> When spdif support was added for the Allwinner A523 family of SoCs, only
> two of the three possible pins were added to the dtsi, since the third
> would clash with the first ethernet port (emac0)
> However, some devices don't use emac0 and instead use emac1 for the only
> available ethernet port, leaving the pin free to use for spdif.
>
> Add it to the dtsi, and to such a device where this pin is used for spdif
>
> Signed-off-by: Per Larsson <per@palvencia.se>
> ---
> Marking this as RFC for a few reasons
> 1. This is my first submission, hoping everything is properly organized.
This is pretty good. The commit message is also well written. I would
like to see the patch split into two patches though. The first adds the
pinmux (and you can mention in the commit message that a subsequent
patch will reference it). The second patch enables SPDIF on the device
you have.
> 2. My testing setup is not the best: I get sound with this patch, but
> the pulseaudio daemon needs to be restarted far too often.
> Hopefully it's just something on this minirootfs. Testing welcome.
> 3. Not sure where to get the hash for a fixes tag or if that's even OK
This is a new addition, not a fix, so no fixes tag is warranted.
Thanks
ChenYu
> ---
> .../arm64/boot/dts/allwinner/sun55i-a523.dtsi | 7 ++++++
> .../dts/allwinner/sun55i-h728-x96qpro+.dts | 24 +++++++++++++++++++
> 2 files changed, 31 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
> index ca6a16807049..7370e8ed24ec 100644
> --- a/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun55i-a523.dtsi
> @@ -216,6 +216,13 @@ spdif_out_pb_pin: spdif-pb-pin {
> allwinner,pinmux = <2>;
> };
>
> + /omit-if-no-ref/
> + spdif_out_ph_pin: spdif-ph-pin {
> + pins = "PH7";
> + function = "spdif";
> + allwinner,pinmux = <4>;
> + };
> +
> /omit-if-no-ref/
> spdif_out_pi_pin: spdif-pi-pin {
> pins = "PI10";
> diff --git a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
> index a96927fbdadd..b172985583f8 100644
> --- a/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun55i-h728-x96qpro+.dts
> @@ -44,6 +44,24 @@ reg_vcc3v3: vcc3v3 {
> vin-supply = <®_vcc5v>;
> regulator-always-on;
> };
> +
> + sound-spdif {
> + compatible = "simple-audio-card";
> + simple-audio-card,name = "spdif-out";
> +
> + simple-audio-card,cpu {
> + sound-dai = <&spdif>;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <&spdif_out>;
> + };
> + };
> +
> + spdif_out: spdif-out {
> + #sound-dai-cells = <0>;
> + compatible = "linux,spdif-dit";
> + };
> };
>
> &ehci0 {
> @@ -275,6 +293,12 @@ &r_pio {
> vcc-pm-supply = <®_aldo3>;
> };
>
> +&spdif {
> + pinctrl-names = "default";
> + pinctrl-0 = <&spdif_out_ph_pin>;
> + status = "okay";
> +};
> +
> &uart0 {
> pinctrl-names = "default";
> pinctrl-0 = <&uart0_pb_pins>;
> --
> 2.48.1
>
^ permalink raw reply
* Re: [PATCH 03/23] resctrl: Expose MBA resource_schemata mode sysfs
From: Ben Horgan @ 2026-07-20 15:02 UTC (permalink / raw)
To: Fenghua Yu, Reinette Chatre, Tony Luck, James Morse, Dave Martin,
Shaopeng Tan, Chen Yu, Babu Moger, Drew Fustini, Vikram Sethi,
Shanker Donthineni, Newton Liu, Gavin Shan
Cc: linux-kernel, linux-arm-kernel
In-Reply-To: <1778dc0e-4a5a-45d5-865c-ab8c65988636@arm.com>
Hi Fenghua,
On 7/17/26 09:54, Ben Horgan wrote:
> Hi Fenghua,
>
> On 7/16/26 22:02, Fenghua Yu wrote:
>> Node-scoped MBA on MPAM needs a way to distinguish native memory-side
>> controls from legacy L3-shaped MB emulation. Track the selected emulate
>> mode on rdt_resource and expose it as
>> info/<resource>/resource_schemata/mode ("native" or "legacy") when the
>> architecture enables emulation.
>
> This doesn't sound right.
>
> If the MPAM mbwu counters are counting traffic on the egress of the L3 they should be described in
> the acpi tables as such, if they are not then they shouldn't. If they are the MB resource can then
> be scoped to the L3.
>
> If the MPAM mbwu counters are at the memory bandwidth controller then they should be described in
> the acpi tables as such. Currently there is no support for such counters except when there is a
> single L3 and a single NUMA node and so a single link between the caches and the memory. Counting at
> either end of the link, egress of the L3 or entry to the memory gives the same counts and so the
> driver performs some unfortunate gymnastics to use L3 scope in this case. Do you see a reason not to
> do this? If we change the scope to be NUMA node in these platforms all I see changing is the domain
> id for the sole MB domain.
>
> As such, can't we just add support for a NUMA scope memory bandwidth allocation resource, MB_NODE,
> without having a legacy/native switch?
There is some further discussion here on when emulation is required in resctrl. [1] No firm
conclusion as of yet.
[1] https://lore.kernel.org/lkml/8fd6caed-820f-457a-a1ef-a0a006fa52aa@intel.com/
Thanks,
Ben
>
> Thanks,
>
> Ben
>
>>
>> The mode file is only created when rdt_resource::mode is non-zero
>> (RESCTRL_CTRL_LEGACY or RESCTRL_CTRL_NATIVE). It defaults to
>> RESCTRL_CTRL_MODE_NONE, so resources whose architecture does not support
>> control emulation get no mode file and are unaffected. Architecture
>> backends that support emulation set the initial mode when they create
>> their controls; on MPAM this is wired up together with the node-scoped
>> MB_NODE control in a later patch, so this commit only adds the (dormant)
>> generic mechanism.
>>
>> The mode file is added read-only here: switching the mode at runtime
>> requires rebuilding the resource_schemata layout to match the new mode,
>> so the writable interface is added together with that rebuild logic in a
>> later patch. Keeping the file read-only until then avoids exposing a
>> writable-but-no-op interface.
>>
>> Store rdt_resource_final in the resource_schemata directory priv so the
>> mode file can resolve the backing resource without dereferencing NULL.
>>
>> Signed-off-by: Fenghua Yu <fenghuay@nvidia.com>
>> ---
>> fs/resctrl/rdtgroup.c | 77 ++++++++++++++++++++++++++++++++++++++++-
>> include/linux/resctrl.h | 17 +++++++++
>> 2 files changed, 93 insertions(+), 1 deletion(-)
>>
>> diff --git a/fs/resctrl/rdtgroup.c b/fs/resctrl/rdtgroup.c
>> index 2abb7fda6091..6b1f24c6a1f2 100644
>> --- a/fs/resctrl/rdtgroup.c
>> +++ b/fs/resctrl/rdtgroup.c
>> @@ -2696,6 +2696,74 @@ static unsigned long fflags_from_resource(struct rdt_resource *r)
>> return WARN_ON_ONCE(1);
>> }
>>
>> +static int resctrl_ctrl_mb_mode_show(struct kernfs_open_file *of,
>> + struct seq_file *seq, void *v)
>> +{
>> + struct rdt_resource_final *f = rdt_kn_parent_priv(of->kn);
>> + struct rdt_resource *r = f->res;
>> +
>> + guard(mutex)(&rdtgroup_mutex);
>> +
>> + switch (r->mode) {
>> + case RESCTRL_CTRL_LEGACY:
>> + seq_puts(seq, "[legacy] native\n");
>> + break;
>> + case RESCTRL_CTRL_NATIVE:
>> + seq_puts(seq, "legacy [native]\n");
>> + break;
>> + default:
>> + WARN_ONCE(1, "%s: unexpected MB control mode %d\n",
>> + f->name, r->mode);
>> + seq_puts(seq, "legacy native\n");
>> + break;
>> + }
>> +
>> + return 0;
>> +}
>> +
>> +static struct rftype resctrl_ctrl_mb_files[] = {
>> + {
>> + .name = "mode",
>> + .mode = 0444,
>> + .kf_ops = &rdtgroup_kf_single_ops,
>> + .seq_show = resctrl_ctrl_mb_mode_show,
>> + /*
>> + * Directory-level file, not per-control: fflags is only a
>> + * presence flag here, not the BIT(ctrl->type) type filter used
>> + * by resctrl_add_ctrl_files().
>> + */
>> + .fflags = 1,
>> + }
>> +};
>> +
>> +static int resctrl_ctrl_add_files(struct kernfs_node *kn)
>> +{
>> + struct rftype *rfts, *rft;
>> + int ret, len;
>> +
>> + rfts = resctrl_ctrl_mb_files;
>> + len = ARRAY_SIZE(resctrl_ctrl_mb_files);
>> +
>> + lockdep_assert_held(&rdtgroup_mutex);
>> +
>> + for (rft = rfts; rft < rfts + len; rft++) {
>> + if (rft->fflags) {
>> + ret = rdtgroup_add_file(kn, rft);
>> + if (ret)
>> + goto error;
>> + }
>> + }
>> +
>> + return 0;
>> +error:
>> + pr_warn("Failed to add %s, err=%d\n", rft->name, ret);
>> + while (--rft >= rfts) {
>> + if (rft->fflags)
>> + kernfs_remove_by_name(kn, rft->name);
>> + }
>> + return ret;
>> +}
>> +
>> /*
>> * No need to cleanup on exit - caller calls the recursive kernfs_remove()
>> * on failure.
>> @@ -2704,11 +2772,12 @@ static int resctrl_mkdir_schemata_dir(struct kernfs_node *kn,
>> struct rdt_resource_final *f)
>> {
>> struct kernfs_node *kn_subdir, *kn_ctrl;
>> + struct rdt_resource *r = f->res;
>> struct resctrl_ctrl *ctrl;
>> char ctrl_full_name[20];
>> int ret;
>>
>> - kn_subdir = kernfs_create_dir(kn, "resource_schemata", kn->mode, NULL);
>> + kn_subdir = kernfs_create_dir(kn, "resource_schemata", kn->mode, f);
>> if (IS_ERR(kn_subdir))
>> return PTR_ERR(kn_subdir);
>>
>> @@ -2716,6 +2785,12 @@ static int resctrl_mkdir_schemata_dir(struct kernfs_node *kn,
>> if (ret)
>> return ret;
>>
>> + if (r->mode) {
>> + ret = resctrl_ctrl_add_files(kn_subdir);
>> + if (ret)
>> + return ret;
>> + }
>> +
>> for_each_resource_ctrl(ctrl, f->res) {
>> ret = snprintf(ctrl_full_name, sizeof(ctrl_full_name), "%s%s%s",
>> f->name, resctrl_ctrl_is_default(ctrl) ? "" : "_",
>> diff --git a/include/linux/resctrl.h b/include/linux/resctrl.h
>> index 72fb7256270e..4fc41e269d0b 100644
>> --- a/include/linux/resctrl.h
>> +++ b/include/linux/resctrl.h
>> @@ -257,6 +257,16 @@ enum resctrl_ctrl_unit {
>> RESCTRL_CTRL_UNIT_GBPS,
>> };
>>
>> +enum resctrl_ctrl_mode {
>> + /*
>> + * Default (zero) value: the resource does not support control
>> + * emulation, so no resource_schemata/mode file is created for it.
>> + */
>> + RESCTRL_CTRL_MODE_NONE = 0,
>> + RESCTRL_CTRL_LEGACY,
>> + RESCTRL_CTRL_NATIVE,
>> +};
>> +
>> /**
>> * struct resctrl_membw - Memory bandwidth allocation related data
>> * @min_bw: Minimum memory bandwidth percentage user can request
>> @@ -399,6 +409,12 @@ struct resctrl_ctrl {
>> * different memory bandwidths
>> * @cache_io_alloc_capable:True if portion of the cache can be configured
>> * for I/O traffic.
>> + * @mode: Control emulation mode for this resource.
>> + * RESCTRL_CTRL_MODE_NONE if the resource does not support
>> + * emulation. "legacy": keep the legacy MB control,
>> + * emulating it with a native control when it has no MBW
>> + * hardware of its own. "native": expose native controls
>> + * directly with no emulation.
>> * @controls: List of controls of an alloc_capable resource
>> */
>> struct rdt_resource {
>> @@ -413,6 +429,7 @@ struct rdt_resource {
>> bool bw_delay_linear;
>> enum membw_throttle_mode bw_throttle_mode;
>> bool cache_io_alloc_capable;
>> + enum resctrl_ctrl_mode mode;
>> struct list_head controls;
>> };
>>
>
>
^ permalink raw reply
* Re: [PATCH v13 1/3] media: dt-bindings: Add CSI Pixel Formatter DT bindings
From: Laurent Pinchart @ 2026-07-20 15:06 UTC (permalink / raw)
To: guoniu.zhou
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Frank Li, Loic Poulain, Bryan O'Donoghue,
Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd, imx,
linux-media, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, Guoniu Zhou, Krzysztof Kozlowski
In-Reply-To: <20260720-csi_formatter-v13-1-4dc9a80e4cfd@oss.nxp.com>
Hi Guoniu,
Thank you for the patch.
On Mon, Jul 20, 2026 at 05:59:46PM +0800, guoniu.zhou@oss.nxp.com wrote:
> From: Guoniu Zhou <guoniu.zhou@nxp.com>
>
> The i.MX95 CSI pixel formatting module uses packet info, pixel and
> non-pixel data from the CSI-2 host controller and reformat them to
> match Pixel Link(PL) definition.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Changes in v11:
> - Add Rb tags from Frank Li and Krzysztof Kozlowski
>
> Changes in v10:
> - Drop syscon parent node from example
> - Drop Reviewed-by tags from Frank and Krzysztof due to binding changes
> - Add description for reg property
> - Add space after formatter@20 before opening brace in example
> - Enhance the port description with more detailed information
> - Delete the blank line immediately following the endpoint in example
>
> Changes in v9:
> - Use direct node instead of syscon wrapper in example
>
> Changes in v8:
> - Use standard port reference instead of video-interfaces.yaml
> - Add parent syscon node in example to show device integration
> - Add required constraints for port@0 and port@1 in ports node
>
> Changes in v7:
> - Change compatible to imx95-csi-formatter as IP is i.MX95 specific per Marco's suggestion
> Link: https://lore.kernel.org/linux-media/20260511-csi_formatter-v6-0-01028e312e2b@oss.nxp.com/T/#mcd135b3de179b3cb69daa1fd6e0e8e27c85b3332
> ---
> .../bindings/media/fsl,imx95-csi-formatter.yaml | 88 ++++++++++++++++++++++
> 1 file changed, 88 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> new file mode 100644
> index 000000000000..58c4e1cc056b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/fsl,imx95-csi-formatter.yaml
> @@ -0,0 +1,88 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/media/fsl,imx95-csi-formatter.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: i.MX95 CSI Pixel Formatter
> +
> +maintainers:
> + - Guoniu Zhou <guoniu.zhou@nxp.com>
> +
> +description:
> + The CSI pixel formatting module found on i.MX95 uses packet info, pixel
> + and non-pixel data from the CSI-2 host controller and reformat them to
> + match Pixel Link(PL) definition.
> +
> +properties:
> + compatible:
> + const: fsl,imx95-csi-formatter
> +
> + reg:
> + maxItems: 1
> + description: Register offset and size within the parent syscon
> +
> + clocks:
> + maxItems: 1
> +
> + power-domains:
> + maxItems: 1
> +
> + ports:
> + $ref: /schemas/graph.yaml#/properties/ports
> +
> + properties:
> + port@0:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + Input port, connects to MIPI CSI-2 receiver output (IDI interface)
> +
> + port@1:
> + $ref: /schemas/graph.yaml#/properties/port
> + description:
> + Output port, connects to ISI input via Pixel Link (PL)
> +
> + required:
> + - port@0
> + - port@1
> +
> +required:
> + - compatible
> + - reg
> + - clocks
> + - power-domains
> + - ports
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/nxp,imx95-clock.h>
> +
> + formatter@20 {
> + compatible = "fsl,imx95-csi-formatter";
> + reg = <0x20 0x100>;
> + clocks = <&cameramix_csr IMX95_CLK_CAMBLK_CSI2_FOR0>;
> + power-domains = <&scmi_devpd 3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + endpoint {
> + remote-endpoint = <&mipi_csi_0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + endpoint {
> + remote-endpoint = <&isi_in_2>;
> + };
> + };
> + };
> + };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v13 2/3] dt-bindings: clock: imx95-blk-ctl: Define formatter child node schema
From: Laurent Pinchart @ 2026-07-20 15:06 UTC (permalink / raw)
To: guoniu.zhou
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Shawn Guo, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Frank Li, Loic Poulain, Bryan O'Donoghue,
Abel Vesa, Peng Fan, Michael Turquette, Stephen Boyd, imx,
linux-media, devicetree, linux-arm-kernel, linux-kernel,
linux-clk, Guoniu Zhou, Krzysztof Kozlowski
In-Reply-To: <20260720-csi_formatter-v13-2-4dc9a80e4cfd@oss.nxp.com>
Hello Guoniu,
Thank you for the patch.
On Mon, Jul 20, 2026 at 05:59:47PM +0800, guoniu.zhou@oss.nxp.com wrote:
> From: Guoniu Zhou <guoniu.zhou@nxp.com>
>
> The Camera CSR contains control registers for multiple CSI formatter IPs
> at different register offsets. Each formatter is an independent hardware
> block with its own clock input and media pipeline connection.
>
> Define schema to allow formatter child nodes under nxp,imx95-camera-csr,
> with 'reg' property specifying the formatter's register offset within the
> CSR address space.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@nxp.com>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Changes in v13:
> - Add Reviewed-by tag from Frank and Krzysztof
>
> Changes in v11:
> - Move properties to top-level and use if:then:else (Krzysztof/Frank)
>
> Changes in v10:
> - Use single quotes for regex pattern to be consistent (Krzysztof Kozlowski)
> - Add formatter subnode binding and camera-csr syscon example
> - Update commit title and message
>
> Changes in v9:
> - New patch to address the issue of formatter acting as a child node of syscon
> ---
> .../bindings/clock/nxp,imx95-blk-ctl.yaml | 71 ++++++++++++++++++++++
> 1 file changed, 71 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> index 27403b4c52d6..fbbf1b3f1790 100644
> --- a/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> +++ b/Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
> @@ -39,6 +39,18 @@ properties:
> ID in its "clocks" phandle cell. See
> include/dt-bindings/clock/nxp,imx95-clock.h
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
> +patternProperties:
> + '^formatter@[0-9a-f]+$':
> + type: object
> + $ref: /schemas/media/fsl,imx95-csi-formatter.yaml#
> + unevaluatedProperties: false
> +
> required:
> - compatible
> - reg
> @@ -46,6 +58,23 @@ required:
> - power-domains
> - clocks
>
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: nxp,imx95-camera-csr
> + then:
> + required:
> + - '#address-cells'
> + - '#size-cells'
> + else:
> + properties:
> + '#address-cells': false
> + '#size-cells': false
> + patternProperties:
> + '^formatter@[0-9a-f]+$': false
> +
> additionalProperties: false
>
> examples:
> @@ -57,4 +86,46 @@ examples:
> clocks = <&scmi_clk 114>;
> power-domains = <&scmi_devpd 21>;
> };
> +
> + - |
> + #include <dt-bindings/clock/nxp,imx95-clock.h>
> +
> + syscon@4ac10000 {
> + compatible = "nxp,imx95-camera-csr", "syscon";
> + reg = <0x4ac10000 0x10000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + #clock-cells = <1>;
> + clocks = <&scmi_clk 62>;
> + power-domains = <&scmi_devpd 3>;
> +
> + formatter@20 {
> + compatible = "fsl,imx95-csi-formatter";
> + reg = <0x20 0x100>;
> + clocks = <&cameramix_csr IMX95_CLK_CAMBLK_CSI2_FOR0>;
> + power-domains = <&scmi_devpd 3>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + endpoint {
> + remote-endpoint = <&mipi_csi_0_out>;
> + };
> +
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + endpoint {
> + remote-endpoint = <&isi_in_2>;
> + };
> + };
> + };
> + };
> + };
> ...
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 1/6] media: nxp: imx8-isi: Fix stream ID validation bypass in crossbar routing
From: Frank Li @ 2026-07-20 15:09 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Christian Hemp,
Stefan Riedmueller, Jacopo Mondi, Loic Poulain,
Bryan O'Donoghue, Dong Aisheng, Guoniu Zhou, linux-media, imx,
linux-arm-kernel, linux-kernel, stable
In-Reply-To: <20260720-isi-v2-1-45845bc5d4fa@oss.nxp.com>
On Mon, Jul 20, 2026 at 11:34:03AM +0800, Guoniu Zhou wrote:
> The crossbar routing validation has a critical bug where it validates
> the wrong routing table, allowing userspace to bypass validation entirely.
>
> The __mxc_isi_crossbar_set_routing() function is called to validate and
> apply a new routing table from userspace. However, the validation loop
> iterates over state->routing (the currently active routing table) instead
> of the routing parameter (the new table being validated):
>
> for_each_active_route(&state->routing, route) {
>
> This means userspace can submit any invalid routing configuration and it
> will pass validation as long as the currently active routing is valid.
> This is a security issue as it allows userspace to configure routes that
> violate hardware constraints, potentially causing undefined hardware
> behavior.
>
> Fix by validating the routing table that will actually be applied.
>
> Fixes: cf21f328fcaf ("media: nxp: Add i.MX8 ISI driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
> Changes in v2:
> - Split v1 patch 1/5 into two patches: this patch fixes the core
> for_each_active_route() bug, next patch adds additional stream
> validation (Frank Li)
> ---
> drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> index c580c831972e..84871bceb31d 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> @@ -107,7 +107,7 @@ static int __mxc_isi_crossbar_set_routing(struct v4l2_subdev *sd,
> return ret;
>
> /* The memory input can be routed to the first pipeline only. */
> - for_each_active_route(&state->routing, route) {
> + for_each_active_route(routing, route) {
> if (route->sink_pad == xbar->num_sinks - 1 &&
> route->source_pad != xbar->num_sinks) {
> dev_dbg(xbar->isi->dev,
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v2 2/6] media: nxp: imx8-isi: Add stream ID validation for crossbar routing
From: Frank Li @ 2026-07-20 15:11 UTC (permalink / raw)
To: Guoniu Zhou
Cc: Laurent Pinchart, Mauro Carvalho Chehab, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Christian Hemp,
Stefan Riedmueller, Jacopo Mondi, Loic Poulain,
Bryan O'Donoghue, Dong Aisheng, Guoniu Zhou, linux-media, imx,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260720-isi-v2-2-45845bc5d4fa@oss.nxp.com>
On Mon, Jul 20, 2026 at 11:34:04AM +0800, Guoniu Zhou wrote:
> Add validation to enforce hardware constraints that were previously
> missing in the crossbar routing configuration:
>
> - SOURCE stream must be 0 (ISI pipes are hardcoded to stream 0)
>
> This check complements the existing memory input validation and ensures
> that all routing configurations respect hardware limitations.
>
> Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
> ---
> Changes in v2:
> - New patch split from v1 1/5: adds stream ID validation on top of
> for_each_active_route() fix (Frank Li)
> - Remove incorrect sink_stream validation
> ---
> drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> index 84871bceb31d..328d08a278ea 100644
> --- a/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> +++ b/drivers/media/platform/nxp/imx8-isi/imx8-isi-crossbar.c
> @@ -106,8 +106,20 @@ static int __mxc_isi_crossbar_set_routing(struct v4l2_subdev *sd,
> if (ret)
> return ret;
>
> - /* The memory input can be routed to the first pipeline only. */
> + /*
> + * Validate routes against hardware constraints:
> + * - SOURCE stream must be 0 (pipes are hardcoded to stream 0)
> + * - Memory input can only route to the first pipeline
> + */
> for_each_active_route(routing, route) {
> + if (route->source_stream != 0) {
> + dev_dbg(xbar->isi->dev,
it is one error, should be dev_err()?
Frank
> + "route to pipe %u must use source_stream=0, got %u\n",
> + route->source_pad - xbar->num_sinks,
> + route->source_stream);
> + return -ENXIO;
> + }
> +
> if (route->sink_pad == xbar->num_sinks - 1 &&
> route->source_pad != xbar->num_sinks) {
> dev_dbg(xbar->isi->dev,
>
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Simplify ioctl handling
From: Vadim Fedorenko @ 2026-07-20 15:17 UTC (permalink / raw)
To: Andrew Lunn, Maxime Chevallier
Cc: Andrew Lunn, Jakub Kicinski, davem, Eric Dumazet, Paolo Abeni,
Simon Horman, Maxime Coquelin, Alexandre Torgue, Russell King,
thomas.petazzoni, Alexis Lothoré, netdev, linux-kernel,
linux-arm-kernel, linux-stm32
In-Reply-To: <ae82997f-537e-4a2d-abce-d163fcf9d868@lunn.ch>
On 19.07.2026 17:13, Andrew Lunn wrote:
>> Looking at this, I'm wondering if we can't just get rid of SIOCSHWTSTAMP
>> handling in phy_mii_ioctl(). Looks like we can ?
>
> I'm not sure about that. We need Richards input.
>
> The code in phy_mii_ioctl() allows the MAC to be bypassed, it goes
> straight to a PHY based stamper. It could be the MAC has no idea the
> PHY has this capability, so it has not implemented the .ndo?
>
> It might be we need to hoist the code from phy_mii_ioctl() into
> dev_{sg}et_hwtstamp()?
Hi Andrew!
I think I've converted all phy drivers while removing support for
SIOCSHWTSTAMP/SIOCGHWTSTAMP from netdev ioctl. I believe it's impossible right
now to reach SIOCSHWTSTAMP path of phy_mii_ioctl via ioctl on net device.
Is it possible to have ioctl on phy device directly without involving netdev?
^ permalink raw reply
* Re: [PATCH v2] KVM: arm64: Reject guest_memfd memslots when the VM has MTE
From: Fuad Tabba @ 2026-07-20 15:20 UTC (permalink / raw)
To: Alexandru Elisei
Cc: maz, oupton, joey.gouly, seiden, suzuki.poulose, yuzenghui,
linux-arm-kernel, kvmarm, catalin.marinas, will, steven.price
In-Reply-To: <20260720130942.135033-1-alexandru.elisei@arm.com>
On Mon, 20 Jul 2026 at 14:10, Alexandru Elisei <alexandru.elisei@arm.com> wrote:
>
> The user cannot use MTE on VMAs created by mapping a guest_memfd file,
> as arch_calc_vm_flag_bits() does not set VM_MTE_ALLOWED.
>
> When creating a guest_memfd backed memslot,
> kvm_arch_prepare_memory_region() rejects the memslot if MTE is enabled for
> the VM and if guest_memfd has been mapped in a VMA that intersects the
> memslot.
>
> However, the documentation for KVM_SET_USER_MEMORY_REGION2 explicitly
> states that the only condition for userspace_addr is for it to be a legal
> userspace address, but the mapping is not required to be valid nor
> populated at memslot creation.
>
> If userspace sets userspace_addr to an address that hasn't been mapped, or
> if userspace_addr belongs to a VMA that isn't backed by the guest_memfd
> file, or if the VMA doesn't intersect the memslot, memslot creation is
> successful and KVM ends up with a VM with MTE and guest_memfd-backed
> memslots.
>
> The same happens if the order is reversed: when userspace enables MTE, KVM
> does not check if memslots backed by guest_memfd are already present.
>
> Fix both issues by rejecting guest_memfd-backed memslots when MTE is
> enabled, and by reject MTE when guest_memfd-backed memslots are already
> present.
>
> Fixes: 32e200bd6e44 ("KVM: arm64: Enable support for guest_memfd backed memory")
> Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
Reviewed-by: Fuad Tabba <fuad.tabba@linux.dev>
Tested-by: Fuad Tabba < fuad.tabba@linux.dev>
Cheers,
/fuad
> ---
>
> v1 can be found at [1].
>
> Changes in v2:
>
> * Added the Fixes tag (Fuad)
> * Split the condition in kvm_arch_prepare_memory_region() (Fuad)
> * Added the check in kvm_vm_ioctl_enable_cap() (Fuad)
>
> Tested by using Fuad's patches to add guest_memfd support for kvmtool at [2],
> with the following changes:
>
> diff --git a/arm64/kvm.c b/arm64/kvm.c
> index 36b3284e4a92..de83b5d7e517 100644
> --- a/arm64/kvm.c
> +++ b/arm64/kvm.c
> @@ -125,10 +125,12 @@ static void kvm__arch_enable_mte(struct kvm *kvm)
> return;
> }
>
> + /*
> if (kvm->cfg.arch.guest_memfd) {
> pr_debug("MTE is incompatible with guest_memfd");
> return;
> }
> + */
>
> if (kvm->cfg.arch.mte_disabled) {
> pr_debug("MTE disabled by user");
> diff --git a/kvm.c b/kvm.c
> index 96583f916442..cc8628b558ea 100644
> --- a/kvm.c
> +++ b/kvm.c
> @@ -332,8 +332,15 @@ int kvm__register_mem(struct kvm *kvm, u64 guest_phys, u64 size,
> .guest_memfd_offset = guest_memfd_offset,
> };
>
> + if (munmap(userspace_addr, size) < 0)
> + die_perror("munmap hack");
> +
> ret = ioctl(kvm->vm_fd, KVM_SET_USER_MEMORY_REGION2,
> &mem2);
> +
> + if (mmap(userspace_addr, size, PROT_RW, MAP_SHARED | MAP_FIXED,
> + guest_memfd, guest_memfd_offset) == MAP_FAILED)
> + die_perror("mmap hack");
> } else {
> struct kvm_userspace_memory_region mem = {
> .slot = slot,
>
> (indentation is weird on purpose so git doesn't get confused). That's to
> test that the user can create a guest_memfd memslot after MTE has been
> enabled for the VM. Without this patch, I was able to create a VM with MTE
> and guest_memfd backed ram (the guest reported MTE as enabled, but I didn't
> test that it actually worked). With this patch, creating a VM with MTE is
> rejected.
>
> To test that KVM rejects enabling MTE *after* creating a guest_memfd backed
> memslot, I modified kvmtool to enable MTE *after* creating the memslot.
> Same situation: without this patch, KVM allows that, with this patch, KVM
> rejects enabling MTE.
>
> [1] https://lore.kernel.org/kvmarm/20260714110756.116950-1-alexandru.elisei@arm.com/
> [2] https://lore.kernel.org/kvmarm/20260712142536.1391557-1-fuad.tabba@linux.dev/
>
> arch/arm64/kvm/arm.c | 25 +++++++++++++++++++------
> arch/arm64/kvm/mmu.c | 4 ++++
> 2 files changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 50adfff75be8..9a6c72a18672 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -149,14 +149,27 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> set_bit(KVM_ARCH_FLAG_RETURN_NISV_IO_ABORT_TO_USER,
> &kvm->arch.flags);
> break;
> - case KVM_CAP_ARM_MTE:
> - mutex_lock(&kvm->lock);
> - if (system_supports_mte() && !kvm->created_vcpus) {
> - r = 0;
> - set_bit(KVM_ARCH_FLAG_MTE_ENABLED, &kvm->arch.flags);
> + case KVM_CAP_ARM_MTE: {
> + struct kvm_memory_slot *memslot;
> + int bkt;
> +
> + guard(mutex)(&kvm->lock);
> + if (!system_supports_mte() || kvm->created_vcpus)
> + break;
> +
> + r = 0;
> + guard(mutex)(&kvm->slots_lock);
> + kvm_for_each_memslot(memslot, bkt, kvm_memslots(kvm)) {
> + if (kvm_slot_has_gmem(memslot)) {
> + r = -EINVAL;
> + break;
> + }
> }
> - mutex_unlock(&kvm->lock);
> + if (r == 0)
> + set_bit(KVM_ARCH_FLAG_MTE_ENABLED, &kvm->arch.flags);
> break;
> +
> + }
> case KVM_CAP_ARM_SYSTEM_SUSPEND:
> r = 0;
> set_bit(KVM_ARCH_FLAG_SYSTEM_SUSPEND_ENABLED, &kvm->arch.flags);
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 6c941aaa10c6..2d95203386ba 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -2652,6 +2652,10 @@ int kvm_arch_prepare_memory_region(struct kvm *kvm,
> if (kvm_slot_has_gmem(new) && !kvm_memslot_is_gmem_only(new))
> return -EINVAL;
>
> + /* guest_memfd is incompatible with MTE. */
> + if (kvm_slot_has_gmem(new) && kvm_has_mte(kvm))
> + return -EINVAL;
> +
> hva = new->userspace_addr;
> reg_end = hva + (new->npages << PAGE_SHIFT);
>
>
> base-commit: 1590cf0329716306e948a8fc29f1d3ee87d3989f
> --
> 2.55.0
>
^ 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