* Re: [PATCH v4 13/14] arm64: dts: imx8mp-var-som-symphony: add second Ethernet port
From: Fabio Estevam @ 2026-06-08 11:50 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team
In-Reply-To: <302638ba16d4684c5b0bf8660a42615dad67f3eb.1780912893.git.stefano.r@variscite.com>
On Mon, Jun 8, 2026 at 7:09 AM Stefano Radaelli
<stefano.radaelli21@gmail.com> wrote:
> + reg_fec_phy: regulator-fec-phy {
> + compatible = "regulator-fixed";
> + regulator-name = "fec-phy";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-enable-ramp-delay = <20000>;
> + gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-always-on;
There is no need to mark it as regulator-always-on, as reg_fec_phy has
a consumer.
Please check globally.
^ permalink raw reply
* Re: [PATCH 17/37] drm/display: bridge-connector: protect dynconn creation and destruction with a mutex
From: Maxime Ripard @ 2026-06-08 11:49 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
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: <20260519-drm-bridge-hotplug-v1-17-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 444 bytes --]
On Tue, May 19, 2026 at 12:37:34PM +0200, Luca Ceresoli wrote:
> Bridge hotplug will make the connector dynamically created and destroyed
> based on hotplug events.
>
> In preparation for that, add a mutex to mutually exclude connector creation
> and destruction.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
What is the source of concurrency, and what are you protecting against
exactly with that lock?
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2] drm/rockchip: dsi: Open-code drm_simple_encoder_init()
From: Diogo Silva @ 2026-06-08 11:49 UTC (permalink / raw)
To: Jonas Karlman
Cc: heiko, airlied, andy.yan, dri-devel, hjc, linux-arm-kernel,
linux-kernel, linux-rockchip, maarten.lankhorst, mripard, simona,
tzimmermann
In-Reply-To: <c8f30973-450e-4995-b6f5-03e7b6afc75b@kwiboo.se>
Hey Jonas,
> Please base your work on latest drm-misc tree, this has already been
> addressed in commit 3de723684be5 ("drm/rockchip: dw_hdmi: Use drmres
> helpers for encoder resources") [1].
Sorry, I'll rebase it on the DRM tree.
>
> Also instead of open-code, maybe a change to use drmm_encoder_init() is
> more appropriate for some of the other drivers?
>
Wouldn't it be better to first remove the deprecated function and then,
in another patch, change to the managed encoder as an improvement?
BR,
Diogo
^ permalink raw reply
* Re: [PATCH 15/37] drm/display: bridge-connector: allocate the connector dynamically
From: Maxime Ripard @ 2026-06-08 11:46 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
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: <20260519-drm-bridge-hotplug-v1-15-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1463 bytes --]
On Tue, May 19, 2026 at 12:37:32PM +0200, Luca Ceresoli wrote:
> Currently the drm_bridge_connector has an embedded drm_connector, so their
> allocation lifetimes are tied to each other. This is insufficient to
> support DRM bridge hotplugging, which requires the connector to be added
> and removed dynamically at runtime multiple times based on hotplug/unplug
> events while the drm_bridge_connector is persistent.
>
> Moreover the drm_connector is exposed to user space and thus an ongoing
> operation (e.g. an ioctl) might last for an arbitrarily long time even
> after the hardware gets removed. This means a new connector might have to
> be added when the previous one is still referenced by user space.
>
> In preparation to handle hotplug, allocate the drm-connector dynamically,
> to allow:
>
> * creating and destroying a connector multiple times during a single
> drm_bridge_connector lifetime
> * creating a new connector even though the previous one is still in use
> and thus still refcounted and not yet freed
>
> This commit does not introduce the actions in the two bullets (it will
> happen in a later commit), it only moves to dynamic APIs for connector
> allocation and init.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
I think this patch should be split in half, with the switch to using
destroy first, and then the actual move to the dynamically allocated
connector API.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] spi: ma35d1-qspi: Add Nuvoton MA35D1 QSPI controller support
From: Chi-Wen Weng @ 2026-06-08 11:45 UTC (permalink / raw)
To: Mark Brown
Cc: robh, krzk+dt, conor+dt, linux-arm-kernel, linux-spi, devicetree,
linux-kernel, cwweng
In-Reply-To: <8e751df3-6237-4c8e-9c87-34bb67e435f7@sirena.org.uk>
Hi Mark,
Thanks for the review.
I will add mem_caps in v3 and set per_op_freq for the spi-mem path.
I will keep the direct CS polarity handling for now, and also add
SPI_CS_HIGH to mode_bits. I understand that moving this handling into
the core would be a separate issue.
Best regards,
Chi-Wen
Mark Brown 於 2026/6/8 下午 06:53 寫道:
> On Mon, Jun 08, 2026 at 10:50:09AM +0800, Chi-Wen Weng wrote:
>> Add SPI controller driver support for the Nuvoton MA35D1 Quad SPI
>> controller.
>> +static void nuvoton_qspi_mem_set_cs(struct spi_device *spi, bool enable)
>> +{
>> + struct nuvoton_qspi *qspi = spi_controller_get_devdata(spi->controller);
>> + bool assert = enable;
>> +
>> + if (spi->mode & SPI_CS_HIGH)
>> + assert = !assert;
> Hrm, we should have the core deal with this. Separate issue though.
>
>> + ctlr->num_chipselect = NUVOTON_QSPI_DEFAULT_NUM_CS;
>> + ctlr->mem_ops = &nuvoton_qspi_mem_ops;
> We don't specify mem_caps, I'm vaugely surprised nothing trips over that
> when testing.
^ permalink raw reply
* Re: [PATCH 06/37] drm/display: bridge-connector: use a drm_bridge_connector internally, not a drm_connector
From: Maxime Ripard @ 2026-06-08 11:41 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
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: <20260519-drm-bridge-hotplug-v1-6-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1084 bytes --]
On Tue, May 19, 2026 at 12:37:23PM +0200, Luca Ceresoli wrote:
> Currently drm_bridge_connector_init() always returns the added connector or
> errors out. When adding bridge hotplug the bridge-connector can be
> successfully initialized without creating a connector, which can be added
> later when the pipeline will be complete.
>
> For this the internal function drm_bridge_connector_add_connector() must be
> able to return a valid drm_bridge_connector even without any drm_connector.
>
> In preparation to support bridge hotplug, change its return value to be the
> same drm_bridge_connector pointer it gets as input, or a PTR_ERR.
>
> No functional changes, just changing an internal API.
>
> Note the return value could now become an int (0 or negative error) because
> returning the same value received as input does not carry any added
> value. However this would be change a lot of lines, so leave such change as
> a future cleanup.
You just created that function and changed "a lot of lines" already, so
I'm not sure that argument holds.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: spi: nuvoton,ma35d1-qspi: Add Nuvoton MA35D1 QSPI
From: Chi-Wen Weng @ 2026-06-08 11:41 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: broonie, robh, krzk+dt, conor+dt, linux-arm-kernel, linux-spi,
devicetree, linux-kernel, cwweng
In-Reply-To: <20260608-aquatic-alluring-asp-b5fcb6@quoll>
Hi Krzysztof,
Thanks for pointing this out.
I will fix the DCO mismatch in the next version by making the commit
author and Signed-off-by consistent, and I will also make sure the
send-email From address does not conflict with them.
I will rerun both checkpatch.pl and checkpatch.pl --strict on the full
patch series before sending v3.
Best regards,
Chi-Wen
Krzysztof Kozlowski 於 2026/6/8 下午 06:02 寫道:
> On Mon, Jun 08, 2026 at 10:50:08AM +0800, Chi-Wen Weng wrote:
>> Add a devicetree binding for the Quad SPI controller found in
>> Nuvoton MA35D1 SoCs.
>>
>> The controller supports SPI memory devices such as SPI NOR and SPI NAND
>> flashes. It has one register range, one clock input and one reset line,
>> and supports up to two chip selects.
>>
>> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
> DCO mismatch.
>
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Maxime Ripard @ 2026-06-08 11:40 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
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: <20260519-drm-bridge-hotplug-v1-5-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 413 bytes --]
On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
> In preparation to introduce bridge hotplug, split out from
> drm_bridge_connector_init() the code adding the drm_connector into a
> dedicated function. This will be needed to be able to add (and re-add) the
> connector from different code paths.
Same story here, explaining what you need later on that calls for that
change would be nice.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH 01/37] drm/connector: split drmm_connector_hdmi_init() in 3 parts
From: Maxime Ripard @ 2026-06-08 11:37 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
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: <20260519-drm-bridge-hotplug-v1-1-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
On Tue, May 19, 2026 at 12:37:18PM +0200, Luca Ceresoli wrote:
> In preparation for adding a dynamic variant of drmm_connector_hdmi_init(),
> split reusable parts of the code to subfunctions.
>
> drmm_connector_hdmi_init() currently has 3 sections:
> 1. sanity checks
> 2. call drmm_connector_init()
> 3. initialize HDMI-specific fields not initialized at step 2
>
> Split 1 and 3 to new functions, reusable independently.
>
> No functional changes. Just moving code around.
Explaining what you need later on, and why these three functions help in
particular, would be nice.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH 04/37] drm/display: bridge-connector: store the drm_device pointer
From: Maxime Ripard @ 2026-06-08 11:34 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
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: <20260519-drm-bridge-hotplug-v1-4-45e2bdb3dfb4@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]
Hi,
On Tue, May 19, 2026 at 12:37:21PM +0200, Luca Ceresoli wrote:
> Currently the struct drm_device pointer is only needed during the initial
> drm_bridge_connector_init() and in drm_bridge_connector_handle_hpd() which
> gets it from the struct drm_connector.
>
> This will be insufficient when introducing bridge hotplugging, because:
>
> * some of the actions in drm_bridge_connector_init() will have to be
> performed later on, when a bridge is hot(un)plugged
> * the connector will be removed and re-added based on hotplug events,
> so the drm_connector might just not exist or its content be cleared
>
> Store the drm_device pointer in struct drm_bridge_connector for any later
> needs. Also convert drm_bridge_connector_handle_hpd() to use the newly
> stored value.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
This is already accessible as drm_connector->dev and drm_bridge->dev. I
think it would be great to list why this is different, and how it is
different (ie, when it's set, unset).
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/5] phy: fsl-imx8mq-usb: keep PHY power domain runtime always-on for i.MX8MP
From: Xu Yang @ 2026-06-08 11:27 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, Neil Armstrong, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jun Li, linux-phy, imx, linux-arm-kernel,
linux-kernel, Xu Yang
In-Reply-To: <aiLrhzEdQE6zAauv@lizhi-Precision-Tower-5810>
On Fri, Jun 05, 2026 at 11:30:15AM -0400, Frank Li wrote:
> On Fri, Jun 05, 2026 at 07:13:06PM +0800, Xu Yang wrote:
> > From: Xu Yang <xu.yang_2@nxp.com>
> >
> > On i.MX8MP, the USB PHY has a dedicated power domain that was previously
> > never powered off at runtime. With the introduction of runtime PM support,
> > the power domain will be powered off if the device is runtime suspended,
> > which breaks USB wakeup functionality.
>
> Does it need depend on if device enable wakeup?
No. The wakeup is for system suspend. We handle the runtime case here.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH v6 6/8] perf cs-etm: Filter synthesized branch samples
From: Leo Yan @ 2026-06-08 11:28 UTC (permalink / raw)
To: James Clark
Cc: linux-arm-kernel, coresight, linux-perf-users, Leo Yan,
Arnaldo Carvalho de Melo, John Garry, Will Deacon, Mike Leach,
Suzuki K Poulose, Namhyung Kim, Mark Rutland, Alexander Shishkin,
Jiri Olsa, Ian Rogers, Adrian Hunter, Al Grant, Paschalis Mpeis,
Amir Ayupov
In-Reply-To: <fbe0a097-ced7-44c6-ada1-01c3e9c1d7e7@linaro.org>
On Thu, Jun 04, 2026 at 03:42:32PM +0100, James Clark wrote:
[...]
> > @@ -3442,6 +3447,16 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
> > etm->synth_opts.thread_stack = session->itrace_synth_opts->thread_stack;
> > }
> > + if (etm->synth_opts.calls)
> > + etm->branches_filter |= PERF_IP_FLAG_CALL |
> > + PERF_IP_FLAG_TRACE_BEGIN |
> > + PERF_IP_FLAG_TRACE_END;
> > +
> > + if (etm->synth_opts.returns)
> > + etm->branches_filter |= PERF_IP_FLAG_RETURN |
> > + PERF_IP_FLAG_TRACE_BEGIN |
> > + PERF_IP_FLAG_TRACE_END;
> > +
>
> This changes the default "perf script" output quite significantly and will
> possibly break people's workflows. synth_opts.calls is true by default but
> synth_opts.returns is false so we lose all the returns that we used to have.
> Not sure if the new behavior is more consistent with other tools so we can
> justify changing it? Personally I think including returns by default made
> more sense, and it's a more literal representation of the flow.
Makes sense. I will add below chunk to enable return events for default
option:
diff --git a/tools/perf/util/cs-etm.c b/tools/perf/util/cs-etm.c
index ab3aa76dddb3..bd9eb794cc07 100644
--- a/tools/perf/util/cs-etm.c
+++ b/tools/perf/util/cs-etm.c
@@ -3541,6 +3541,14 @@ int cs_etm__process_auxtrace_info_full(union perf_event *event,
session->itrace_synth_opts->default_no_sample);
etm->synth_opts.callchain = false;
etm->synth_opts.thread_stack = session->itrace_synth_opts->thread_stack;
+
+ /*
+ * By default, only call events are enabled but no return
+ * events. Enable return events to better represent the
+ * execution flow.
+ */
+ if (etm->synth_opts.calls)
+ etm->synth_opts.returns = true;
}
>
> itrace.txt says the default is "all events i.e. the same as
> --itrace=iybxwpe", but I thought the default was branches? At least for
> Coresight it is, so I'm a bit confused.
"--itrace=iybxwpe" would be used for "perf report" command, the doc also
mentions "--itrace=ce" for "perf script" specific.
Thanks,
Leo
^ permalink raw reply related
* Re: [PATCH v4 4/5] phy: fsl-imx8mq-usb: add control register regmap
From: Xu Yang @ 2026-06-08 11:26 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, Neil Armstrong, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jun Li, linux-phy, imx, linux-arm-kernel,
linux-kernel, Xu Yang
In-Reply-To: <aiLrMs7AMECq7U66@lizhi-Precision-Tower-5810>
On Fri, Jun 05, 2026 at 11:28:50AM -0400, Frank Li wrote:
> On Fri, Jun 05, 2026 at 07:13:05PM +0800, Xu Yang wrote:
> > From: Xu Yang <xu.yang_2@nxp.com>
> >
> > The CR port is a simple 16-bit data/address parallel port that is
> > accessed through 32-bit MMIO registers for on-chip access to the
> > control registers inside the USB 3.0 femtoPHY. Add control register
> > regmap and export these registers by debugfs to help PHY's diagnostic.
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> >
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> > ---
> > Changes in v4:
> > - improve commit message as Haibo's suggestion
> > Changes in v3:
> > - drop Frank's tag because it includes other changes
> > - new patch
> > ---
> > drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 27 ++++++++++++++++++++++++++-
> > 1 file changed, 26 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > index 27aa696f5dd4..e24f46d7924b 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > @@ -1,5 +1,5 @@
> > // SPDX-License-Identifier: GPL-2.0+
> > -/* Copyright (c) 2017 NXP. */
> > +/* Copyright 2017-2026 NXP. */
> >
> > #include <linux/bitfield.h>
> > #include <linux/clk.h>
> > @@ -11,6 +11,7 @@
> > #include <linux/platform_device.h>
> > #include <linux/pm_runtime.h>
> > #include <linux/regulator/consumer.h>
> > +#include <linux/regmap.h>
> > #include <linux/usb/typec_mux.h>
> >
> > #define PHY_CTRL0 0x0
> > @@ -56,6 +57,8 @@
> > #define PHY_CTRL6_ALT_CLK_EN BIT(1)
> > #define PHY_CTRL6_ALT_CLK_SEL BIT(0)
> >
> > +#define PHY_CRCTL 0x30
> > +
> > #define PHY_TUNE_DEFAULT 0xffffffff
> >
> > #define TCA_CLK_RST 0x00
> > @@ -119,6 +122,7 @@ struct imx8mq_usb_phy {
> > void __iomem *base;
> > struct regulator *vbus;
> > struct tca_blk *tca;
> > + struct regmap *cr_regmap;
> > u32 pcs_tx_swing_full;
> > u32 pcs_tx_deemph_3p5db;
> > u32 tx_vref_tune;
> > @@ -667,6 +671,14 @@ static const struct of_device_id imx8mq_usb_phy_of_match[] = {
> > };
> > MODULE_DEVICE_TABLE(of, imx8mq_usb_phy_of_match);
> >
> > +static const struct regmap_config imx_cr_regmap_config = {
> > + .name = "cr",
> > + .reg_bits = 32,
> > + .val_bits = 32,
> > + .reg_stride = 4,
> > + .max_register = 0x7,
> > +};
> > +
> > static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> > {
> > struct phy_provider *phy_provider;
> > @@ -696,6 +708,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> > if (IS_ERR(imx_phy->base))
> > return PTR_ERR(imx_phy->base);
> >
> > + imx_phy->cr_regmap = devm_regmap_init_mmio(dev, imx_phy->base + PHY_CRCTL,
> > + &imx_cr_regmap_config);
> > + if (IS_ERR(imx_phy->cr_regmap)) {
> > + dev_warn(dev, "Fail to init debug register regmap\n");
> > + imx_phy->cr_regmap = NULL;
> > + }
> > +
> > ret = devm_pm_runtime_set_active_enabled(dev);
> > if (ret)
> > return dev_err_probe(dev, ret, "Failed to enable runtime PM\n");
> > @@ -731,6 +750,9 @@ static int imx8mq_usb_phy_runtime_suspend(struct device *dev)
> > {
> > struct imx8mq_usb_phy *imx_phy = dev_get_drvdata(dev);
> >
> > + if (imx_phy->cr_regmap)
> > + regcache_cache_only(imx_phy->cr_regmap, true);
> > +
>
> I think this common problem, is possible to change
> regmap_read_debugfs(), let it call runtime_pm_get(), there are already
> have runtime_pm in regmap field.
Yes, it should be a common issue when access debugfs on a suspended device.
Not sure why regmap common driver doesn't add it. We can do it in future if
more such cases appear.
>
> So you debug fs always to get update value, instead cached value?
The default cache type is REGCACHE_NONE in imx_cr_regmap_config. So no
cache at all. The main purpose is to block register access here. Once
cache_only is disabled, it will read HW register value.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH v6 3/4] firmware: smccc: arm-cca-guest: Bind the TSM provider to an SMCCC device
From: Aneesh Kumar K.V @ 2026-06-08 11:26 UTC (permalink / raw)
To: Suzuki K Poulose, Sudeep Holla
Cc: linux-coco, linux-arm-kernel, linux-kernel, Catalin Marinas,
Greg KH, Jeremy Linton, Jonathan Cameron, Lorenzo Pieralisi,
Mark Rutland, Will Deacon, Steven Price
In-Reply-To: <e0071e90-c2f5-4d15-b3c6-fe05bf1464e4@arm.com>
Suzuki K Poulose <suzuki.poulose@arm.com> writes:
> On 08/06/2026 09:19, Aneesh Kumar K.V wrote:
>> Sudeep Holla <sudeep.holla@kernel.org> writes:
>>
>>> On Thu, Jun 04, 2026 at 06:56:28PM +0530, Aneesh Kumar K.V wrote:
>>>> Sudeep Holla <sudeep.holla@kernel.org> writes:
>>>>
>>>> ...
...
>>> I was trying to avoid conditional compilation altogether and hence the
>>> reason for keeping it as simple as possible. Also IS_ENABLED(CONFIG_ARM64)
>>> in above snippet must come as some condition to this generic probe.
>>>
>>> Adding any more logic or callback defeats the bus idea here if we need
>>> to rely/depend on multiple conditional compilation or callbacks IMO.
>>>
>>> Let's find see if it can work with what we are adding now and may add in
>>> near future and then decide.
>>>
>>
>> If we move all the conditional checks to the driver probe path, then I
>> think this can work. Something like the below:
>>
>> struct smccc_device_info {
>> u32 func_id;
>> bool requires_smc;
>> const char *device_name;
>> };
>>
>> static const struct smccc_device_info smccc_devices[] __initconst = {
>> {
>> .func_id = ARM_SMCCC_TRNG_VERSION,
>> .requires_smc = false,
>> .device_name = "arm-smccc-trng",
>> },
>>
>> {
>> .func_id = RSI_ABI_VERSION,
>
> Don't we need parameters passed to this (Requested Interface version for
> e.g.) ? See more below.
>
The idea is that we only check whether the function ID is supported. All
other conditional logic should be handled in the driver probe path, as
demonstrated by the changes in drivers/char/hw_random/arm_smccc_trng.c.
>
>> .requires_smc = true,
>> .device_name = RSI_DEV_NAME,
>> },
>> };
>>
>> static bool __init smccc_probe_smccc_device(const struct smccc_device_info *smccc_dev)
>> {
>> unsigned long ret;
>> struct arm_smccc_res res;
>>
>> if (smccc_conduit == SMCCC_CONDUIT_NONE)
>> return false;
>>
>> if (smccc_dev->requires_smc && smccc_conduit != SMCCC_CONDUIT_SMC)
>> return false;
>>
>> arm_smccc_1_1_invoke(smccc_dev->func_id, &res);
>> ret = res.a0;
>>
>> if ((s32)ret == SMCCC_RET_NOT_SUPPORTED)
>
> Is this a reliable check for all possible SMCCC services ? i.e., Are we
> expected to get RET_NOT_SUPPORTED for any service for which the backend
> is not available ?
>
That is correct. That is what the SMCCC specification says
> Also, as pointed out RSI_ABI_VERSION may return other errors based on
> the input (requested version, e.g., RSI_ERROR_INPUT) and we may still go
> ahead and register the device ?
>
Correct, and the driver probe will check for the minimum and maximum supported versions.
>> return false;
>>
>> return true;
>> }
>>
>> static int __init smccc_devices_init(void)
>> {
>> struct arm_smccc_device *sdev;
>> const struct smccc_device_info *smccc_dev;
>>
>> for (int i = 0; i < ARRAY_SIZE(smccc_devices); i++) {
>> smccc_dev = &smccc_devices[i];
>>
>> if (!smccc_probe_smccc_device(smccc_dev))
>> continue;
>>
>> sdev = arm_smccc_device_register(smccc_dev->device_name);
>> if (IS_ERR(sdev))
>> pr_err("%s: could not register device: %ld\n",
>> smccc_dev->device_name, PTR_ERR(sdev));
>>
>> }
>>
>> return 0;
>> }
>> device_initcall(smccc_devices_init);
>>
>> with the diff to hw_random/smccc_trng
>>
>> modified arch/arm64/include/asm/archrandom.h
>> @@ -12,7 +12,7 @@
>>
>> extern bool smccc_trng_available;
>>
>> -static inline bool __init smccc_probe_trng(void)
>> +static inline bool smccc_probe_trng(void)
>> {
>> struct arm_smccc_res res;
>>
>> modified drivers/char/hw_random/arm_smccc_trng.c
>> @@ -19,6 +19,8 @@
>> #include <linux/arm-smccc.h>
>> #include <linux/arm-smccc-bus.h>
>>
>> +#include <asm/archrandom.h>
>> +
>> #ifdef CONFIG_ARM64
>> #define ARM_SMCCC_TRNG_RND ARM_SMCCC_TRNG_RND64
>> #define MAX_BITS_PER_CALL (3 * 64UL)
>> @@ -98,6 +100,10 @@ static int smccc_trng_probe(struct arm_smccc_device *sdev)
>> {
>> struct hwrng *trng;
>>
>> + /* validate the minimum version requirement */
>> + if (!smccc_probe_trng())
>> + return -ENODEV;
>> +
>> trng = devm_kzalloc(&sdev->dev, sizeof(*trng), GFP_KERNEL);
>> if (!trng)
>> return -ENOMEM;
>>
>> We can also move arch/arm64/include/asm/rsi_smc.h to
>> include/linux/arm-rsi-smccc.h. There was a suggestion to move these
>
> super minor nit: arm-smccc-rsi.h ?
>
-aneesh
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
From: Alexander Stein @ 2026-06-08 11:22 UTC (permalink / raw)
To: Frank Li
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Geert Uytterhoeven,
Magnus Damm, Shawn Guo, devicetree, linux-kernel, imx,
linux-arm-kernel, linux, linux-renesas-soc
In-Reply-To: <aiL9i6IQzK3EHGpm@lizhi-Precision-Tower-5810>
Hi Frank,
Am Freitag, 5. Juni 2026, 18:47:07 CEST schrieb Frank Li:
> On Wed, Jun 03, 2026 at 11:36:09AM +0200, Alexander Stein wrote:
> > This adds an overlay for the supported LVDS display AUO G133HAN01.
> > Configure the video PLL frequency to exactly match typical pixel clock of
> > 141.200 MHz.
> >
> > Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
> > ---
>
> Can you fix W=1 dtb build warnings?
That would require to duplicate the setting from imx8mp.dtsi. Is this really
intended?
imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso:51.10-55.5: Warning (unit_address_vs_reg): /fragment@3/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso:57.10-61.5: Warning (unit_address_vs_reg): /fragment@3/__overlay__/ports/port@2: node has a unit name, but no reg or ranges property
IMHO this warning is not suitable for .dtbo, while it is for .dtb
(with applied overlays). The .dtbo doesn't have all the information.
Best reagrds
Alexander
> Frank
>
> > Changes in v4:
> > * New to series v4
> >
> > arch/arm64/boot/dts/freescale/Makefile | 2 +
> > ...p-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso | 74 +++++++++++++++++++
> > 2 files changed, 76 insertions(+)
> > create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> > index dee2bea156740..3f466f102dc1d 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -385,8 +385,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
> >
> > +imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtbo
> > imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
> > imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
> > +dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
> >
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
> > new file mode 100644
> > index 0000000000000..9595cf4d43cd0
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
> > @@ -0,0 +1,74 @@
> > +// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
> > +/*
> > + * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
> > + * D-82229 Seefeld, Germany.
> > + * Author: Martin Schmiedel
> > + */
> > +
> > +/dts-v1/;
> > +/plugin/;
> > +
> > +&backlight_lvds0 {
> > + status = "okay";
> > +};
> > +
> > +&panel_lvds0 {
> > + compatible = "auo,g133han01";
> > + status = "okay";
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + dual-lvds-odd-pixels;
> > +
> > + panel_in_lvds0: endpoint {
> > + remote-endpoint = <&ldb_lvds_ch0>;
> > + };
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + dual-lvds-even-pixels;
> > +
> > + panel_in_lvds1: endpoint {
> > + remote-endpoint = <&ldb_lvds_ch1>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +&lcdif2 {
> > + status = "okay";
> > +};
> > +
> > +&lvds_bridge {
> > + status = "okay";
> > +
> > + ports {
> > + port@1 {
> > + ldb_lvds_ch0: endpoint {
> > + remote-endpoint = <&panel_in_lvds0>;
> > + };
> > + };
> > +
> > + port@2 {
> > + ldb_lvds_ch1: endpoint {
> > + remote-endpoint = <&panel_in_lvds1>;
> > + };
> > + };
> > + };
> > +};
> > +
> > +// Update VIDEO_PLL1 frequency
> > +&media_blk_ctrl {
> > + assigned-clock-rates = <500000000>, <200000000>,
> > + <0>, <0>, <500000000>,
> > + <988400000>;
> > +};
> > +
> > +&pwm3 {
> > + status = "okay";
> > +};
> > --
> > 2.54.0
> >
>
--
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 v4 3/5] phy: fsl-imx8mq-usb: add runtime PM support
From: Xu Yang @ 2026-06-08 11:14 UTC (permalink / raw)
To: Frank Li
Cc: Vinod Koul, Neil Armstrong, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Jun Li, linux-phy, imx, linux-arm-kernel,
linux-kernel, Xu Yang
In-Reply-To: <aiLn81lg32BPDZVp@lizhi-Precision-Tower-5810>
On Fri, Jun 05, 2026 at 11:14:59AM -0400, Frank Li wrote:
> On Fri, Jun 05, 2026 at 07:13:04PM +0800, Xu Yang wrote:
> > From: Xu Yang <xu.yang_2@nxp.com>
> >
> > Add runtime PM to ensure the PHY is properly powered and clocked during
> > register access, preventing potential system hangs.
> >
> > It guards register access in the following scenarios:
> > - PHY operations: init() and power_on/off() callbacks are guarded by
> > phy core
> > - Type-C orientation switching when PHY/Controller are suspended which
> > needs explicitly care
> > - Future PHY control port register regmap debugfs access
> >
> > Signed-off-by: Xu Yang <xu.yang_2@nxp.com>
> >
> > ---
> > Changes in v4:
> > - replace guard() with PM_RUNTIME_ACQUIRE()
> > Changes in v3:
> > - new patch
> > ---
> > drivers/phy/freescale/phy-fsl-imx8mq-usb.c | 62 +++++++++++++++++++++---------
> > 1 file changed, 43 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > index 591ddf346061..27aa696f5dd4 100644
> > --- a/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > +++ b/drivers/phy/freescale/phy-fsl-imx8mq-usb.c
> > @@ -9,6 +9,7 @@
> > #include <linux/of.h>
> > #include <linux/phy/phy.h>
> > #include <linux/platform_device.h>
> > +#include <linux/pm_runtime.h>
> > #include <linux/regulator/consumer.h>
> > #include <linux/usb/typec_mux.h>
> >
> > @@ -136,17 +137,15 @@ static int tca_blk_typec_switch_set(struct typec_switch_dev *sw,
> > {
> > struct imx8mq_usb_phy *imx_phy = typec_switch_get_drvdata(sw);
> > struct tca_blk *tca = imx_phy->tca;
> > - int ret;
> >
> > if (tca->orientation == orientation)
> > return 0;
> >
> > - ret = clk_prepare_enable(imx_phy->clk);
> > - if (ret)
> > - return ret;
> > + PM_RUNTIME_ACQUIRE(&imx_phy->phy->dev, pm);
> > + if (PM_RUNTIME_ACQUIRE_ERR(&pm))
> > + return -ENXIO;
> >
> > tca_blk_orientation_set(tca, orientation);
> > - clk_disable_unprepare(imx_phy->clk);
> >
> > return 0;
> > }
> > @@ -620,16 +619,6 @@ static int imx8mq_phy_power_on(struct phy *phy)
> > if (ret)
> > return ret;
> >
> > - ret = clk_prepare_enable(imx_phy->clk);
> > - if (ret)
> > - return ret;
> > -
> > - ret = clk_prepare_enable(imx_phy->alt_clk);
> > - if (ret) {
> > - clk_disable_unprepare(imx_phy->clk);
> > - return ret;
> > - }
> > -
> > /* Disable rx term override */
> > value = readl(imx_phy->base + PHY_CTRL6);
> > value &= ~PHY_CTRL6_RXTERM_OVERRIDE_SEL;
> > @@ -648,8 +637,6 @@ static int imx8mq_phy_power_off(struct phy *phy)
> > value |= PHY_CTRL6_RXTERM_OVERRIDE_SEL;
> > writel(value, imx_phy->base + PHY_CTRL6);
> >
> > - clk_disable_unprepare(imx_phy->alt_clk);
> > - clk_disable_unprepare(imx_phy->clk);
> > regulator_disable(imx_phy->vbus);
> >
> > return 0;
> > @@ -686,6 +673,7 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> > struct device *dev = &pdev->dev;
> > struct imx8mq_usb_phy *imx_phy;
> > const struct phy_ops *phy_ops;
> > + int ret;
> >
> > imx_phy = devm_kzalloc(dev, sizeof(*imx_phy), GFP_KERNEL);
> > if (!imx_phy)
> > @@ -693,13 +681,13 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> >
> > platform_set_drvdata(pdev, imx_phy);
> >
> > - imx_phy->clk = devm_clk_get(dev, "phy");
> > + imx_phy->clk = devm_clk_get_enabled(dev, "phy");
> > if (IS_ERR(imx_phy->clk)) {
> > dev_err(dev, "failed to get imx8mq usb phy clock\n");
> > return PTR_ERR(imx_phy->clk);
> > }
> >
> > - imx_phy->alt_clk = devm_clk_get_optional(dev, "alt");
> > + imx_phy->alt_clk = devm_clk_get_optional_enabled(dev, "alt");
>
> when driver remove, devm will disable clock, which may cause refcound
> wrong if device already suspend by runtime pm
Right, so it's improper to use both devm for clk and runtime PM. I will
remove devm_pm_runtime_set_active_enabled() and use non-devm callbacks
to avoid such issue.
>
> > if (IS_ERR(imx_phy->alt_clk))
> > return dev_err_probe(dev, PTR_ERR(imx_phy->alt_clk),
> > "Failed to get alt clk\n");
> > @@ -708,6 +696,10 @@ static int imx8mq_usb_phy_probe(struct platform_device *pdev)
> > if (IS_ERR(imx_phy->base))
> > return PTR_ERR(imx_phy->base);
> >
> > + ret = devm_pm_runtime_set_active_enabled(dev);
> > + if (ret)
> > + return dev_err_probe(dev, ret, "Failed to enable runtime PM\n");
> > +
>
> You have not set auto suspend, so runtime_suspend will never entry.
At the end of __driver_probe_device(), it will call pm_request_idle() for
the device. So runtime_suspend() will run. And the test result align with
this logic.
Thanks,
Xu Yang
^ permalink raw reply
* Re: [PATCH v14 32/44] KVM: arm64: Handle Realm PSCI requests
From: Steven Price @ 2026-06-08 11:15 UTC (permalink / raw)
To: Gavin Shan, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <775a0d29-4d92-4ecc-96dd-5b0eaeff1528@redhat.com>
On 28/05/2026 07:55, Gavin Shan wrote:
> Hi Steve,
>
> On 5/13/26 11:17 PM, Steven Price wrote:
>> The RMM needs to be informed of the target REC when a PSCI call is made
>> with an MPIDR argument.
>>
>> This requirement will be removed in a future release of the RMM 2.0
>> specification but is still required for v2.0-bet1.
>>
>> Co-developed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Chanegs since v13:
>> * The ioctl KVM_ARM_VCPU_RMI_PSCI_COMPLETE has gone. The RMI call is
>> made automatically just before entering the REC again.
>> Changes since v12:
>> * Chance return code for non-realms to -ENXIO to better represent that
>> the ioctl is invalid for non-realms (checkpatch is insistent that
>> "ENOSYS means 'invalid syscall nr' and nothing else").
>> Changes since v11:
>> * RMM->RMI renaming.
>> Changes since v6:
>> * Use vcpu_is_rec() rather than kvm_is_realm(vcpu->kvm).
>> * Minor renaming/formatting fixes.
>> ---
>> arch/arm64/include/asm/kvm_rmi.h | 3 ++
>> arch/arm64/kvm/psci.c | 15 ++++++++-
>> arch/arm64/kvm/rmi.c | 58 ++++++++++++++++++++++++++++++++
>> 3 files changed, 75 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/include/asm/kvm_rmi.h b/arch/arm64/include/
>> asm/kvm_rmi.h
>> index b65cfec10dee..eacf82a7467d 100644
>> --- a/arch/arm64/include/asm/kvm_rmi.h
>> +++ b/arch/arm64/include/asm/kvm_rmi.h
>> @@ -109,6 +109,9 @@ int realm_map_non_secure(struct realm *realm,
>> unsigned long size,
>> enum kvm_pgtable_prot prot,
>> struct kvm_mmu_memory_cache *memcache);
>> +int realm_psci_complete(struct kvm_vcpu *source,
>> + struct kvm_vcpu *target,
>> + unsigned long status);
>> static inline bool kvm_realm_is_private_address(struct realm *realm,
>> unsigned long addr)
>> diff --git a/arch/arm64/kvm/psci.c b/arch/arm64/kvm/psci.c
>> index 3b5dbe9a0a0e..a2cd55dc7b5b 100644
>> --- a/arch/arm64/kvm/psci.c
>> +++ b/arch/arm64/kvm/psci.c
>> @@ -103,7 +103,6 @@ static unsigned long kvm_psci_vcpu_on(struct
>> kvm_vcpu *source_vcpu)
>> reset_state->reset = true;
>> kvm_make_request(KVM_REQ_VCPU_RESET, vcpu);
>> -
>
> This change isn't supposed to be part of this patch :-)
Whoops - indeed it isn't!
>> /*
>> * Make sure the reset request is observed if the RUNNABLE
>> mp_state is
>> * observed.
>> @@ -142,6 +141,20 @@ static unsigned long
>> kvm_psci_vcpu_affinity_info(struct kvm_vcpu *vcpu)
>> /* Ignore other bits of target affinity */
>> target_affinity &= target_affinity_mask;
>> + if (vcpu_is_rec(vcpu)) {
>> + struct kvm_vcpu *target_vcpu;
>> +
>> + /* RMM supports only zero affinity level */
>> + if (lowest_affinity_level != 0)
>> + return PSCI_RET_INVALID_PARAMS;
>> +
>> + target_vcpu = kvm_mpidr_to_vcpu(kvm, target_affinity);
>> + if (!target_vcpu)
>> + return PSCI_RET_INVALID_PARAMS;
>> +
>> + return PSCI_RET_SUCCESS;
>> + }
>> +
>> /*
>> * If one or more VCPU matching target affinity are running
>> * then ON else OFF
>> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
>> index 761b38a4071c..2b03e962ee41 100644
>> --- a/arch/arm64/kvm/rmi.c
>> +++ b/arch/arm64/kvm/rmi.c
>> @@ -3,6 +3,7 @@
>> * Copyright (C) 2023-2025 ARM Ltd.
>> */
>> +#include <uapi/linux/psci.h>
>> #include <linux/kvm_host.h>
>> #include <asm/kvm_emulate.h>
>> @@ -127,6 +128,25 @@ static void free_rtt(phys_addr_t phys)
>> kvm_account_pgtable_pages(phys_to_virt(phys), -1);
>> }
>> +int realm_psci_complete(struct kvm_vcpu *source, struct kvm_vcpu
>> *target,
>> + unsigned long status)
>> +{
>> + int ret;
>> +
>> + /*
>> + * XXX: RMM-v2.0 doesn't require the target REC address for
>> completing
>> + * PSCI requests. Temporary hack until RMM implementation catches up
>> + * to the full spec.
>> + */
>> + ret = rmi_psci_complete(virt_to_phys(source->arch.rec.rec_page),
>> + virt_to_phys(target->arch.rec.rec_page),
>> + status);
>> + if (ret)
>> + return -EINVAL;
>
> return -ENXIO;
Ack, although as the comment says this should be going away.
Thanks,
Steve
>> +
>> + return 0;
>> +}
>> +
>> static int realm_rtt_create(struct realm *realm,
>> unsigned long addr,
>> int level,
>> @@ -1004,6 +1024,41 @@ static void kvm_complete_ripas_change(struct
>> kvm_vcpu *vcpu)
>> rec->run->exit.ripas_base = base;
>> }
>> +static void kvm_rec_complete_psci(struct kvm_vcpu *vcpu)
>> +{
>> + struct rec_run *run = vcpu->arch.rec.run;
>> + unsigned long status = PSCI_RET_DENIED;
>> + unsigned long ret = vcpu_get_reg(vcpu, 0);
>> + struct kvm_vcpu *target;
>> +
>> + switch (run->exit.gprs[0]) {
>> + /*
>> + * XXX: RMM-v2.0 doesn't cause RMI_EXIT_PSCI for AFFINITY_INFO
>> + * Temporary hack until tf-RMM gets the REC to MPIDR mapping via
>> + * RD Auxiliary granules.
>> + * For now always report SUCCESS
>> + */
>> + case PSCI_0_2_FN64_AFFINITY_INFO:
>> + status = PSCI_RET_SUCCESS;
>> + break;
>> + case PSCI_0_2_FN64_CPU_ON: {
>> + if (ret != PSCI_RET_SUCCESS &&
>> + ret != PSCI_RET_ALREADY_ON)
>> + status = PSCI_RET_DENIED;
>> + else
>> + status = PSCI_RET_SUCCESS;
>> + break;
>> + }
>> + default:
>> + return;
>> + }
>> +
>> + target = kvm_mpidr_to_vcpu(vcpu->kvm, run->exit.gprs[1]);
>> + /* RMM makes sure that we don't get RMI_EXIT_PSCI for invalid
>> mpidrs */
>> + if (target)
>> + realm_psci_complete(vcpu, target, status);
>> +}
>> +
>> /*
>> * kvm_rec_pre_enter - Complete operations before entering a REC
>> *
>> @@ -1028,6 +1083,9 @@ int kvm_rec_pre_enter(struct kvm_vcpu *vcpu)
>> for (int i = 0; i < REC_RUN_GPRS; i++)
>> rec->run->enter.gprs[i] = vcpu_get_reg(vcpu, i);
>> break;
>> + case RMI_EXIT_PSCI:
>> + kvm_rec_complete_psci(vcpu);
>> + break;
>> case RMI_EXIT_RIPAS_CHANGE:
>> kvm_complete_ripas_change(vcpu);
>> break;
>
> Thanks,
> Gavin
>
^ permalink raw reply
* Re: [PATCH v14 29/44] arm64: RMI: Runtime faulting of memory
From: Steven Price @ 2026-06-08 10:56 UTC (permalink / raw)
To: Gavin Shan, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Suzuki K Poulose, Zenghui Yu, linux-arm-kernel,
linux-kernel, Joey Gouly, Alexandru Elisei, Christoffer Dall,
Fuad Tabba, linux-coco, Ganapatrao Kulkarni, Shanker Donthineni,
Alper Gun, Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve,
WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <d08ca4d6-1e7c-473d-909e-89642bd8c4c2@redhat.com>
On 05/06/2026 12:20, Gavin Shan wrote:
> Hi Steve,
>
> On 5/13/26 11:17 PM, Steven Price wrote:
>> At runtime if the realm guest accesses memory which hasn't yet been
>> mapped then KVM needs to either populate the region or fault the guest.
>>
>> For memory in the lower (protected) region of IPA a fresh page is
>> provided to the RMM which will zero the contents. For memory in the
>> upper (shared) region of IPA, the memory from the memslot is mapped
>> into the realm VM non secure.
>>
>> Signed-off-by: Steven Price <steven.price@arm.com>
>> ---
>> Changes since v13:
>> * Numerous changes due to rebasing.
>> * Fix addr_range_desc() to encode the correct block size.
>> Changes since v12:
>> * Switch to RMM v2.0 range based APIs.
>> Changes since v11:
>> * Adapt to upstream changes.
>> Changes since v10:
>> * RME->RMI renaming.
>> * Adapt to upstream gmem changes.
>> Changes since v9:
>> * Fix call to kvm_stage2_unmap_range() in kvm_free_stage2_pgd() to set
>> may_block to avoid stall warnings.
>> * Minor coding style fixes.
>> Changes since v8:
>> * Propagate the may_block flag.
>> * Minor comments and coding style changes.
>> Changes since v7:
>> * Remove redundant WARN_ONs for realm_create_rtt_levels() - it will
>> internally WARN when necessary.
>> Changes since v6:
>> * Handle PAGE_SIZE being larger than RMM granule size.
>> * Some minor renaming following review comments.
>> Changes since v5:
>> * Reduce use of struct page in preparation for supporting the RMM
>> having a different page size to the host.
>> * Handle a race when delegating a page where another CPU has faulted on
>> a the same page (and already delegated the physical page) but not yet
>> mapped it. In this case simply return to the guest to either use the
>> mapping from the other CPU (or refault if the race is lost).
>> * The changes to populate_par_region() are moved into the previous
>> patch where they belong.
>> Changes since v4:
>> * Code cleanup following review feedback.
>> * Drop the PTE_SHARED bit when creating unprotected page table entries.
>> This is now set by the RMM and the host has no control of it and the
>> spec requires the bit to be set to zero.
>> Changes since v2:
>> * Avoid leaking memory if failing to map it in the realm.
>> * Correctly mask RTT based on LPA2 flag (see rtt_get_phys()).
>> * Adapt to changes in previous patches.
>> ---
>> arch/arm64/include/asm/kvm_emulate.h | 8 ++
>> arch/arm64/include/asm/kvm_rmi.h | 12 ++
>> arch/arm64/kvm/mmu.c | 128 ++++++++++++++++----
>> arch/arm64/kvm/rmi.c | 173 +++++++++++++++++++++++++++
>> 4 files changed, 301 insertions(+), 20 deletions(-)
>>
>
> [...]
>
>> @@ -1604,27 +1641,52 @@ static int gmem_abort(const struct
>> kvm_s2_fault_desc *s2fd)
>> bool write_fault, exec_fault;
>> enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
>> enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R;
>> - struct kvm_pgtable *pgt = s2fd->vcpu->arch.hw_mmu->pgt;
>> + struct kvm_vcpu *vcpu = s2fd->vcpu;
>> + struct kvm_pgtable *pgt = vcpu->arch.hw_mmu->pgt;
>> + gpa_t gpa = kvm_gpa_from_fault(vcpu->kvm, s2fd->fault_ipa);
>> unsigned long mmu_seq;
>> struct page *page;
>> - struct kvm *kvm = s2fd->vcpu->kvm;
>> + struct kvm *kvm = vcpu->kvm;
>> void *memcache;
>> kvm_pfn_t pfn;
>> gfn_t gfn;
>> int ret;
>> - memcache = get_mmu_memcache(s2fd->vcpu);
>> - ret = topup_mmu_memcache(s2fd->vcpu, memcache);
>> + if (kvm_is_realm(vcpu->kvm)) {
>> + /* check for memory attribute mismatch */
>> + bool is_priv_gfn = kvm_mem_is_private(kvm, gpa >> PAGE_SHIFT);
>> + /*
>> + * For Realms, the shared address is an alias of the private
>> + * PA with the top bit set. Thus if the fault address matches
>> + * the GPA then it is the private alias.
>> + */
>> + bool is_priv_fault = (gpa == s2fd->fault_ipa);
>> +
>> + if (is_priv_gfn != is_priv_fault) {
>> + kvm_prepare_memory_fault_exit(vcpu, gpa, PAGE_SIZE,
>> + kvm_is_write_fault(vcpu),
>> + false,
>> + is_priv_fault);
>> + /*
>> + * KVM_EXIT_MEMORY_FAULT requires an return code of
>> + * -EFAULT, see the API documentation
>> + */
>> + return -EFAULT;
>> + }
>> + }
>> +
>
> For a Realm, gmem_abort() is called by kvm_handle_guest_abort() only when
> we're faulting in the private (protected) space.
>
> if (kvm_slot_has_gmem(memslot) && !shared_ipa_fault(vcpu->kvm,
> fault_ipa))
> ret = gmem_abort(&s2fd);
> else
> ret = user_mem_abort(&s2fd);
>
> With the condition, this block of code can be simplied to handle conversion
> (shared -> private) instead of both directions.
>
> /* Convert the shared address to the private adress for Realm */
> if (kvm_is_realm(vcpu->kvm) &&
> !kvm_mem_is_private(kvm, gpa >> PAGE_SHIFT)) {
> /*
> * KVM_EXIT_MEMORY_FAULT requires an return code of
> * -EFAULT, see the API documentation
> */
> kvm_prepare_memory_fault_exit(vcpu, gpa, PAGE_SIZE,
> kvm_is_write_fault(vcpu),
> false, true);
> return -EFAULT;
> }
>
>
> [...]
>
>> @@ -2396,7 +2475,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
>> !write_fault &&
>> !kvm_vcpu_trap_is_exec_fault(vcpu));
>> - if (kvm_slot_has_gmem(memslot))
>> + if (kvm_slot_has_gmem(memslot) && !shared_ipa_fault(vcpu-
>> >kvm, fault_ipa))
>> ret = gmem_abort(&s2fd);
>> else
>> ret = user_mem_abort(&s2fd);
> gmem_abort() is only called for faults in the protected (private) space.
You're absolutely correct - that's a nice simplification!
Thanks,
Steve
^ permalink raw reply
* Re: [PATCH v14 29/44] arm64: RMI: Runtime faulting of memory
From: Steven Price @ 2026-06-08 10:56 UTC (permalink / raw)
To: Suzuki K Poulose, Gavin Shan, kvm, kvmarm
Cc: Catalin Marinas, Marc Zyngier, Will Deacon, James Morse,
Oliver Upton, Zenghui Yu, linux-arm-kernel, linux-kernel,
Joey Gouly, Alexandru Elisei, Christoffer Dall, Fuad Tabba,
linux-coco, Ganapatrao Kulkarni, Shanker Donthineni, Alper Gun,
Aneesh Kumar K . V, Emi Kisanuki, Vishal Annapurve, WeiLin.Chang,
Lorenzo.Pieralisi2
In-Reply-To: <cecbd148-5d33-49c8-928f-572f71b3dd69@arm.com>
On 08/06/2026 10:30, Suzuki K Poulose wrote:
> On 05/06/2026 07:23, Gavin Shan wrote:
>> Hi Steve,
>>
>> On 5/13/26 11:17 PM, Steven Price wrote:
>>> At runtime if the realm guest accesses memory which hasn't yet been
>>> mapped then KVM needs to either populate the region or fault the guest.
>>>
>>> For memory in the lower (protected) region of IPA a fresh page is
>>> provided to the RMM which will zero the contents. For memory in the
>>> upper (shared) region of IPA, the memory from the memslot is mapped
>>> into the realm VM non secure.
>>>
>>> Signed-off-by: Steven Price <steven.price@arm.com>
>>> ---
>>> Changes since v13:
>>> * Numerous changes due to rebasing.
>>> * Fix addr_range_desc() to encode the correct block size.
>>> Changes since v12:
>>> * Switch to RMM v2.0 range based APIs.
>>> Changes since v11:
>>> * Adapt to upstream changes.
>>> Changes since v10:
>>> * RME->RMI renaming.
>>> * Adapt to upstream gmem changes.
>>> Changes since v9:
>>> * Fix call to kvm_stage2_unmap_range() in kvm_free_stage2_pgd() to set
>>> may_block to avoid stall warnings.
>>> * Minor coding style fixes.
>>> Changes since v8:
>>> * Propagate the may_block flag.
>>> * Minor comments and coding style changes.
>>> Changes since v7:
>>> * Remove redundant WARN_ONs for realm_create_rtt_levels() - it will
>>> internally WARN when necessary.
>>> Changes since v6:
>>> * Handle PAGE_SIZE being larger than RMM granule size.
>>> * Some minor renaming following review comments.
>>> Changes since v5:
>>> * Reduce use of struct page in preparation for supporting the RMM
>>> having a different page size to the host.
>>> * Handle a race when delegating a page where another CPU has
>>> faulted on
>>> a the same page (and already delegated the physical page) but not
>>> yet
>>> mapped it. In this case simply return to the guest to either use the
>>> mapping from the other CPU (or refault if the race is lost).
>>> * The changes to populate_par_region() are moved into the previous
>>> patch where they belong.
>>> Changes since v4:
>>> * Code cleanup following review feedback.
>>> * Drop the PTE_SHARED bit when creating unprotected page table
>>> entries.
>>> This is now set by the RMM and the host has no control of it and the
>>> spec requires the bit to be set to zero.
>>> Changes since v2:
>>> * Avoid leaking memory if failing to map it in the realm.
>>> * Correctly mask RTT based on LPA2 flag (see rtt_get_phys()).
>>> * Adapt to changes in previous patches.
>>> ---
>>> arch/arm64/include/asm/kvm_emulate.h | 8 ++
>>> arch/arm64/include/asm/kvm_rmi.h | 12 ++
>>> arch/arm64/kvm/mmu.c | 128 ++++++++++++++++----
>>> arch/arm64/kvm/rmi.c | 173 +++++++++++++++++++++++++++
>>> 4 files changed, 301 insertions(+), 20 deletions(-)
>>>
[...]
>>> diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
>>> index cae29fd3353c..761b38a4071c 100644
>>> --- a/arch/arm64/kvm/rmi.c
>>> +++ b/arch/arm64/kvm/rmi.c
>>> @@ -597,6 +597,179 @@ static int realm_data_map_init(struct kvm *kvm,
>>> unsigned long ipa,
>>> return ret;
>>> }
>>> +static unsigned long addr_range_desc(unsigned long phys, unsigned
>>> long size)
>>> +{
>>> + unsigned long out = 0;
>>> +
>>> + switch (size) {
>>> + case P4D_SIZE:
>>> + out = 3 | (1 << 2);
>>> + break;
>>> + case PUD_SIZE:
>>> + out = 2 | (1 << 2);
>>> + break;
>>> + case PMD_SIZE:
>>> + out = 1 | (1 << 2);
>>> + break;
>>> + case PAGE_SIZE:
>>> + out = 0 | (1 << 2);
>>> + break;
>>> + default:
>>> + /*
>>> + * Only support mapping at the page level granulatity when
>>> + * it's an unusual length. This should get us back onto a
>>> larger
>>> + * block size for the subsequent mappings.
>>> + */
>>> + out = 0 | ((MIN(size >> PAGE_SHIFT, PTRS_PER_PTE - 1)) << 2);
>>> + break;
>>> + }
>>> +
>>> + WARN_ON(phys & ~PAGE_MASK);
>>> +
>>> + out |= phys & PAGE_MASK;
>>> +
>>> + return out;
>>> +}
>>> +
>>> +int realm_map_protected(struct kvm *kvm,
>>> + unsigned long ipa,
>>> + kvm_pfn_t pfn,
>>> + unsigned long map_size,
>>> + struct kvm_mmu_memory_cache *memcache)
>>> +{
>>> + struct realm *realm = &kvm->arch.realm;
>>> + phys_addr_t phys = __pfn_to_phys(pfn);
>>> + phys_addr_t base_phys = phys;
>>> + phys_addr_t rd = virt_to_phys(realm->rd);
>>> + unsigned long base_ipa = ipa;
>>> + unsigned long ipa_top = ipa + map_size;
>>> + int ret = 0;
>>> +
>>> + if (WARN_ON(!IS_ALIGNED(map_size, PAGE_SIZE) ||
>>> + !IS_ALIGNED(ipa, map_size)))
>>> + return -EINVAL;
>>> +
>>> + if (rmi_delegate_range(phys, map_size)) {
>>> + /*
>>> + * It's likely we raced with another VCPU on the same
>>> + * fault. Assume the other VCPU has handled the fault
>>> + * and return to the guest.
>>> + */
>>> + return 0;
>>> + }
>>> +
>>> + while (ipa < ipa_top) {
>>> + unsigned long flags = RMI_ADDR_TYPE_SINGLE;
>>> + unsigned long range_desc = addr_range_desc(phys, ipa_top -
>>> ipa);
>>> + unsigned long out_top;
>>> +
>>> + ret = rmi_rtt_data_map(rd, ipa, ipa_top, flags, range_desc,
>>> + &out_top);
>>> +
>>> + if (RMI_RETURN_STATUS(ret) == RMI_ERROR_RTT) {
>>> + /* Create missing RTTs and retry */
>>> + int level = RMI_RETURN_INDEX(ret);
>>> +
>>> + WARN_ON(level == KVM_PGTABLE_LAST_LEVEL);
>>> + ret = realm_create_rtt_levels(realm, ipa, level,
>>> + KVM_PGTABLE_LAST_LEVEL,
>>> + memcache);
>
> Could we give the RMM a chance to make use of the Block mappings by
> creating the Missing RTTs to the level that may work for the current
> range_desc ? i.e., if the range_desc is a 2M block size, we could create
> tables upto L2 in the first go and if the RMM still needs RTT, we could
> go further down to the KVM_PGTABLE_LAST_LEVEL. I understand this is
> kind of an optimisation, so may be we could defer it. (Same applies for
> the non_secure map below).
A simple change would be just to create one level at a time like this:
diff --git a/arch/arm64/kvm/rmi.c b/arch/arm64/kvm/rmi.c
index b79b96f7dffb..3f3ade1d3895 100644
--- a/arch/arm64/kvm/rmi.c
+++ b/arch/arm64/kvm/rmi.c
@@ -767,15 +767,15 @@ static int realm_map_protected(struct kvm *kvm,
/* Create missing RTTs and retry */
int level = RMI_RETURN_INDEX(ret);
- WARN_ON(level == KVM_PGTABLE_LAST_LEVEL);
+ if (WARN_ON(level >= KVM_PGTABLE_LAST_LEVEL))
+ goto err_undelegate;
ret = realm_create_rtt_levels(realm, ipa, level,
- KVM_PGTABLE_LAST_LEVEL,
+ level + 1,
memcache);
if (ret)
goto err_undelegate;
- ret = rmi_rtt_data_map(rd, ipa, ipa_top, flags,
- range_desc, &out_top);
+ continue;
}
if (WARN_ON(ret))
Thanks,
Steve
^ permalink raw reply related
* Re: [PATCH v2 2/2] spi: ma35d1-qspi: Add Nuvoton MA35D1 QSPI controller support
From: Mark Brown @ 2026-06-08 10:53 UTC (permalink / raw)
To: Chi-Wen Weng
Cc: robh, krzk+dt, conor+dt, linux-arm-kernel, linux-spi, devicetree,
linux-kernel, cwweng
In-Reply-To: <20260608025009.1504971-3-cwweng@nuvoton.com>
[-- Attachment #1: Type: text/plain, Size: 647 bytes --]
On Mon, Jun 08, 2026 at 10:50:09AM +0800, Chi-Wen Weng wrote:
> Add SPI controller driver support for the Nuvoton MA35D1 Quad SPI
> controller.
> +static void nuvoton_qspi_mem_set_cs(struct spi_device *spi, bool enable)
> +{
> + struct nuvoton_qspi *qspi = spi_controller_get_devdata(spi->controller);
> + bool assert = enable;
> +
> + if (spi->mode & SPI_CS_HIGH)
> + assert = !assert;
Hrm, we should have the core deal with this. Separate issue though.
> + ctlr->num_chipselect = NUVOTON_QSPI_DEFAULT_NUM_CS;
> + ctlr->mem_ops = &nuvoton_qspi_mem_ops;
We don't specify mem_caps, I'm vaugely surprised nothing trips over that
when testing.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: phy: nuvoton: Add MA35D1 USB2 OTG PHY binding
From: Krzysztof Kozlowski @ 2026-06-08 10:45 UTC (permalink / raw)
To: Joey Lu
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacky Huang, Shan-Chun Hung, linux-phy, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260604101220.1092822-2-a0987203069@gmail.com>
On Thu, Jun 04, 2026 at 06:12:19PM +0800, Joey Lu wrote:
A nit, subject: drop second/last, redundant "binding". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
> +properties:
> + compatible:
> + const: nuvoton,ma35d1-usb2-phy-otg
> +
Where is reg? MMIO is expressed with reg, not via custom phandle.
> + clocks:
> + maxItems: 1
> +
> + nuvoton,sys:
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - items:
> + - description: phandle to the system management syscon.
> + - description: PHY instance index.
> + enum:
> + - 0 # USB0, OTG port (shared with DWC2 gadget controller)
> + - 1 # USB1, host-only port
> + description:
> + A phandle to the syscon node covering the SYS register block, with
> + one argument selecting the PHY instance. Index 0 selects the OTG
> + port PHY (USB0) and index 1 selects the host-only PHY (USB1).
> +
> + "#phy-cells":
> + const: 0
> +
> + nuvoton,rcalcode:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 15
> + description:
> + Resistor calibration trim code written to the RCALCODE field in
> + USBPMISCR. The 4-bit value adjusts the PHY's internal termination
> + resistance. When absent the hardware reset default is used.
> +
> + nuvoton,oc-active-high:
> + type: boolean
> + description:
> + When present, the over-current detect input from the VBUS power
> + switch is treated as active-high. The default (property absent) is
> + active-low. This setting is shared by both USB host ports.
> +
> +required:
> + - compatible
> + - clocks
> + - nuvoton,sys
> + - "#phy-cells"
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
> +
> + usb_hphy0: usb-host-phy {
usb-phy
And drop unused label.
> + compatible = "nuvoton,ma35d1-usb2-phy-otg";
> + clocks = <&clk HUSBH0_GATE>;
> + nuvoton,sys = <&sys 0>;
> + #phy-cells = <0>;
> + };
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v5 05/20] dma-pool: track decrypted atomic pools and select them via attrs
From: Marek Szyprowski @ 2026-06-08 10:44 UTC (permalink / raw)
To: Jason Gunthorpe, Aneesh Kumar K.V
Cc: Michael Kelley, iommu@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-coco@lists.linux.dev,
Robin Murphy, Will Deacon, Marc Zyngier, Steven Price,
Suzuki K Poulose, Catalin Marinas, Jiri Pirko, Mostafa Saleh,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Alexander Gordeev, Gerald Schaefer,
Heiko Carstens, Vasily Gorbik, Christian Borntraeger,
Sven Schnelle, x86@kernel.org, Jiri Pirko
In-Reply-To: <20260604182419.GC2487554@ziepe.ca>
On 04.06.2026 20:24, Jason Gunthorpe wrote:
> On Thu, Jun 04, 2026 at 08:27:36PM +0530, Aneesh Kumar K.V wrote:
>> I already sent a v6 in the hope of getting this merged for the next
>> merge window. Should I send a v7, or would you prefer that I do the
>> rename on top of v6?
> I think it is too late for such a major change, but this should be
> imaginged to be for rc2ish next cycle. You also have to spell out how
> the pkvm patch will get sequenced as well, it would be best to push
> that it gets picked up right away.
I would like to give this a bit of time in linux-next so it is a bit too
late for v7.2, but before merging it I would also like to have this code
reviewed by someone with confidential computing knowledge.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
^ permalink raw reply
* [PATCH 1/1] KVM: arm64: Make kvm_s2_fault_pin_pfn() fault-in interruptible
From: Jia He @ 2026-06-08 10:43 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel, Jia He
In-Reply-To: <20260608104336.2405384-1-justin.he@arm.com>
arm64 KVM faults guest memory into the host in kvm_s2_fault_pin_pfn() via
__kvm_faultin_pfn(). Today this request is made non-interruptible, so if
the host fault-in path blocks for a long time, a vCPU thread that already
has a pending signal cannot leave the fault-in path until GUP eventually
completes.
This is particularly painful during VM teardown, where userspace may
signal vCPU threads while they are blocked faulting in guest memory. In
that case there is no benefit in continuing to wait for the fault to
complete; the vCPU should return to userspace and let the pending signal
be handled.
Ask the generic KVM fault-in helper to use FOLL_INTERRUPTIBLE. When GUP
reports a pending signal it returns KVM_PFN_ERR_SIGPENDING; handle it by
calling kvm_handle_signal_exit() and returning -EINTR. This matches the
behaviour expected by the generic KVM fault-in path and mirrors the
signal-exit handling already done by the arm64 run loop, which sets
run->exit_reason = KVM_EXIT_INTR before returning to userspace. It is
also consistent with architectures such as x86 that already allow the
fault-in to be interrupted by pending signals.
The interrupted fault does not install a partial stage-2 mapping: the
-EINTR is returned before any mapping is created, so the fault is simply
retried on a subsequent vCPU entry once userspace re-enters KVM_RUN. The
only observable effect in the absence of a pending signal is none; this
does not make ordinary stage-2 faults abortable.
Signed-off-by: Jia He <justin.he@arm.com>
---
arch/arm64/kvm/mmu.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 4da9281312eb..dfb779e6d792 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1872,19 +1872,27 @@ static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
struct kvm_s2_fault_vma_info *s2vi)
{
int ret;
+ unsigned int flags = FOLL_INTERRUPTIBLE;
ret = kvm_s2_fault_get_vma_info(s2fd, s2vi);
if (ret)
return ret;
+ if (kvm_is_write_fault(s2fd->vcpu))
+ flags |= FOLL_WRITE;
+
s2vi->pfn = __kvm_faultin_pfn(s2fd->memslot, get_canonical_gfn(s2fd, s2vi),
- kvm_is_write_fault(s2fd->vcpu) ? FOLL_WRITE : 0,
+ flags,
&s2vi->map_writable, &s2vi->page);
if (unlikely(is_error_noslot_pfn(s2vi->pfn))) {
if (s2vi->pfn == KVM_PFN_ERR_HWPOISON) {
kvm_send_hwpoison_signal(s2fd->hva, __ffs(s2vi->vma_pagesize));
return 0;
}
+ if (is_sigpending_pfn(s2vi->pfn)) {
+ kvm_handle_signal_exit(s2fd->vcpu);
+ return -EINTR;
+ }
return -EFAULT;
}
--
2.34.1
^ permalink raw reply related
* [PATCH 0/1] KVM: arm64: Make kvm_s2_fault_pin_pfn() fault-in interruptible
From: Jia He @ 2026-06-08 10:43 UTC (permalink / raw)
To: Marc Zyngier, Oliver Upton
Cc: Joey Gouly, Steffen Eiden, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, linux-arm-kernel, kvmarm,
linux-kernel, Jia He
Hi,
I hit this while looking at long vCPU hung-task stalls with nested
virtualization enabled.
The vCPU was blocked in the fault-in path on a userspace folio which was
under migration:
__kvm_faultin_pfn()
-> get_user_pages_unlocked()
-> do_swap_page() /* PTE is a migration entry */
-> migration_entry_wait()
set_current_state(TASK_UNINTERRUPTIBLE);
io_schedule(); /* no timeout */
At this point the vCPU cannot observe a pending signal. If userspace is
trying to tear down the VM, the vCPU thread can still remain stuck until
migration finishes and the folio lock is released.
Nested virtualization makes this much easier to hit. The migration path
can hold the folio lock while the MMU notifier runs kvm_nested_s2_unmap(),
and that can be expensive today since it may walk all active shadow
stage-2s. So the long delay is really caused by the unmap/migration side;
the vCPU is just waiting for it to finish.
This patch does not try to make that unmap path cheaper. That is a
separate issue, and range-aware shadow stage-2 unmap work, such as
Wei-Lin Chang's "KVM: arm64: nv: Avoid full shadow s2 unmap" series,
is aimed at that problem.
What this patch does is narrower: use FOLL_INTERRUPTIBLE when faulting in
the userspace page for the arm64 stage-2 fault path. If the vCPU thread
has a pending signal, GUP can return and KVM can leave KVM_RUN through the
normal KVM_EXIT_INTR path. If there is no pending signal, the behaviour is
unchanged.
Jia He (1):
KVM: arm64: Make kvm_s2_fault_pin_pfn() fault-in interruptible
arch/arm64/kvm/mmu.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v3 3/5] drm/verisilicon: introduce per-variant hardware ops table
From: Joey Lu @ 2026-06-08 10:35 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <340c213ca47dabb8bc3d260311e2fd4818bd8001.camel@iscas.ac.cn>
On 6/8/2026 6:06 PM, Icenowy Zheng wrote:
> 在 2026-06-08一的 17:45 +0800，Joey Lu写道：
>>>> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>>>> b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>>>> index 1f2be41ae496..75bc36a078f7 100644
>>>> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>>>> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane.c
>>>> @@ -53,12 +53,6 @@ static int
>>>> vs_primary_plane_atomic_check(struct
>>>> drm_plane *plane,
>>>> return 0;
>>>> }
>>>>
>>>> -static void vs_primary_plane_commit(struct vs_dc *dc, unsigned
>>>> int
>>>> output)
>>>> -{
>>>> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>>>> - VSDC_FB_CONFIG_EX_COMMIT);
>>>> -}
>>>> -
>>>> static void vs_primary_plane_atomic_enable(struct drm_plane
>>>> *plane,
>>>> struct
>>>> drm_atomic_commit
>>>> *atomic_state)
>>>> {
>>>> @@ -69,13 +63,8 @@ static void
>>>> vs_primary_plane_atomic_enable(struct
>>>> drm_plane *plane,
>>>> unsigned int output = vcrtc->id;
>>>> struct vs_dc *dc = vcrtc->dc;
>>>>
>>>> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>>>> - VSDC_FB_CONFIG_EX_FB_EN);
>>>> - regmap_update_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>>>> - VSDC_FB_CONFIG_EX_DISPLAY_ID_MASK,
>>>> -
>>>> VSDC_FB_CONFIG_EX_DISPLAY_ID(output));
>>>> -
>>>> - vs_primary_plane_commit(dc, output);
>>>> + if (dc->funcs->plane_enable_ex)
>>>> + dc->funcs->plane_enable_ex(dc, output);
>>> Please note that all theae codes are for primary planes, maybe the
>>> helper should be named mentioning primary. Overlay planes will need
>>> a
>>> different codepath because they change different registers.
>>>
>>> Thanks,
>>> Icenowy
>> Understood. To avoid confusion, I will rename `plane_enable_ex`,
>> `plane_disable_ex`, and `plane_update_ex` to `primary_plane_enable`,
>> `primary_plane_disable`, and `primary_plane_update` in `vs_dc_funcs`,
>> `vs_dc8200.c`, and `vs_primary_plane.c`.
> Maybe keep the `_ex` here as some operations is still on the common
> codepath?
>
> Thanks,
> Icenowy
Got it. I’ll keep the `_ex` suffix in place. That way it’s consistent
with the common codepath operations, and the inline comments already
makes the intent clear.
>>>> }
>>>>
>>>> static void vs_primary_plane_atomic_disable(struct drm_plane
>>>> *plane,
>>>> @@ -88,10 +77,8 @@ static void
>>>> vs_primary_plane_atomic_disable(struct
>>>> drm_plane *plane,
>>>> unsigned int output = vcrtc->id;
>>>> struct vs_dc *dc = vcrtc->dc;
>>>>
>>>> - regmap_set_bits(dc->regs, VSDC_FB_CONFIG_EX(output),
>>>> - VSDC_FB_CONFIG_EX_FB_EN);
>>>> -
>>>> - vs_primary_plane_commit(dc, output);
>>>> + if (dc->funcs->plane_disable_ex)
>>>> + dc->funcs->plane_disable_ex(dc, output);
>>>> }
>>>>
>>>> static void vs_primary_plane_atomic_update(struct drm_plane
>>>> *plane,
>>>> @@ -133,18 +120,11 @@ static void
>>>> vs_primary_plane_atomic_update(struct drm_plane *plane,
>>>> regmap_write(dc->regs, VSDC_FB_STRIDE(output),
>>>> fb->pitches[0]);
>>>>
>>>> - regmap_write(dc->regs, VSDC_FB_TOP_LEFT(output),
>>>> - VSDC_MAKE_PLANE_POS(state->crtc_x, state-
>>>>> crtc_y));
>>>> - regmap_write(dc->regs, VSDC_FB_BOTTOM_RIGHT(output),
>>>> - VSDC_MAKE_PLANE_POS(state->crtc_x + state-
>>>>> crtc_w,
>>>> - state->crtc_y + state-
>>>>> crtc_h));
>>>> regmap_write(dc->regs, VSDC_FB_SIZE(output),
>>>> VSDC_MAKE_PLANE_SIZE(state->crtc_w, state-
>>>>> crtc_h));
>>>>
>>>> - regmap_write(dc->regs, VSDC_FB_BLEND_CONFIG(output),
>>>> - VSDC_FB_BLEND_CONFIG_BLEND_DISABLE);
>>>> -
>>>> - vs_primary_plane_commit(dc, output);
>>>> + if (dc->funcs->plane_update_ex)
>>>> + dc->funcs->plane_update_ex(dc, output, state);
>>>> }
>>>>
>>>> static const struct drm_plane_helper_funcs
>>>> vs_primary_plane_helper_funcs = {
^ 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