Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH] dt-bindings: dma: mediatek,uart-dma: add support for MT8189 SoC
From: AngeloGioacchino Del Regno @ 2026-07-01 16:55 UTC (permalink / raw)
  To: Louis-Alexis Eyraud, Sean Wang, Vinod Koul, Frank Li, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Long Cheng
  Cc: kernel, dmaengine, linux-arm-kernel, linux-mediatek, devicetree,
	linux-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-uart-dma-v1-1-c7106216a40d@collabora.com>

On 7/1/26 17:47, Louis-Alexis Eyraud wrote:
> Add the compatible string for the APDMA IP found in MT8189 SoC,
> that supports 35-bits addressing as MT6985 SoC.
> 
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>


^ permalink raw reply

* Re: [PATCH] dt-bindings: PCI: mediatek-gen3: Add support for MT8189 SoC
From: AngeloGioacchino Del Regno @ 2026-07-01 16:55 UTC (permalink / raw)
  To: Louis-Alexis Eyraud, Ryder Lee, Bjorn Helgaas, Lorenzo Pieralisi,
	Krzysztof Wilczyński, Manivannan Sadhasivam, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Jianjun Wang
  Cc: kernel, linux-pci, linux-mediatek, devicetree, linux-kernel,
	linux-arm-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-pcie-v1-1-7c7a65087654@collabora.com>

On 7/1/26 17:27, Louis-Alexis Eyraud wrote:
> Add compatible for MT8189 PCIe Gen3 controller, that is compatible with
> the one found MT8192.
> 
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>



^ permalink raw reply

* Re: [PATCH v2 2/4] dt-bindings: arm: mediatek: add Mediatek Genio 520/720-EVK boards
From: AngeloGioacchino Del Regno @ 2026-07-01 16:55 UTC (permalink / raw)
  To: Louis-Alexis Eyraud, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Sean Wang
  Cc: kernel, linux-kernel, linux-serial, devicetree, linux-arm-kernel,
	linux-mediatek, Krzysztof Kozlowski
In-Reply-To: <20260701-add-mediatek-genio-520-720-evk-v2-2-19d5da4ef984@collabora.com>

On 7/1/26 18:35, Louis-Alexis Eyraud wrote:
> Add compatible strings for the Mediatek Genio 520-EVK (based on
> MT8371 SoC) and Mediatek Genio 720-EVK (based on MT8391 SoC) boards.
> MT8391 and MT8371 SoC are less powerful variants of MT8189 SoC,
> with identical hardware register maps.
> 
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>



^ permalink raw reply

* Re: [PATCH v2 1/4] dt-bindings: serial: mediatek,uart: Add compatible for MT8189 SoC
From: AngeloGioacchino Del Regno @ 2026-07-01 16:55 UTC (permalink / raw)
  To: Louis-Alexis Eyraud, Greg Kroah-Hartman, Jiri Slaby, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Matthias Brugger, Sean Wang
  Cc: kernel, linux-kernel, linux-serial, devicetree, linux-arm-kernel,
	linux-mediatek, Krzysztof Kozlowski
In-Reply-To: <20260701-add-mediatek-genio-520-720-evk-v2-1-19d5da4ef984@collabora.com>

On 7/1/26 18:35, Louis-Alexis Eyraud wrote:
> Add a compatible string for the MT8189 SoC.
> The UART IPs in this chip are fully compatible with the one found in
> MT6577 SoC.
> 
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> Signed-off-by: Louis-Alexis Eyraud <louisalexis.eyraud@collabora.com>

Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>



^ permalink raw reply

* [PATCH 13/42] drm/mediatek: mtk_hdmi_v2: Don't warn on RPM active during detach
From: AngeloGioacchino Del Regno @ 2026-07-01 12:20 UTC (permalink / raw)
  To: chunkuang.hu
  Cc: p.zabel, airlied, simona, maarten.lankhorst, mripard, tzimmermann,
	robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
	dri-devel, linux-mediatek, devicetree, linux-kernel,
	linux-arm-kernel, justin.yeh, jason-jh.lin, kernel
In-Reply-To: <20260701122057.19648-1-angelogioacchino.delregno@collabora.com>

The Runtime PM may be active during bridge .detach() and this
happens especially at boot, when probe deferrals in the display
controller driver happen.

Even though it looks safe to assume that RPM has to be inactive
at that time, this happens to be true only if the DDC was to be
handled internally (like before .hpd_{en,dis}able() existed).

At this point in time, this driver uses HPD callbacks, and for
HPD to actually work it is necessary to raise the RPM refcount
to wake up the entire HDMI IP: since it's not granted that the
HPD or other children of the HDMI node are disabled during the
display controller probe sequence, the WARN at bridge .detach()
time may trigger (and will do that when mediatek-drm defers),
unnecessarily bloating the kernel log, as the RPM refcount will
be decreased anyway when removing the driver.

This is why the WARN(pm_runtime_active()) check during detach
is simply a development stage leftover: remove it!

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_hdmi_v2.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c b/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
index 7bbf463056c9..0cc80e80ae26 100644
--- a/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
+++ b/drivers/gpu/drm/mediatek/mtk_hdmi_v2.c
@@ -995,8 +995,6 @@ static void mtk_hdmi_v2_bridge_detach(struct drm_bridge *bridge)
 {
 	struct mtk_hdmi *hdmi = hdmi_ctx_from_bridge(bridge);
 
-	WARN_ON(pm_runtime_active(hdmi->dev));
-
 	/* The controller is already powered off, just disable irq here */
 	disable_irq(hdmi->irq);
 }
-- 
2.54.0



^ permalink raw reply related

* [PATCH 17/42] drm/mediatek: mtk_crtc: Dynamically find vblank/cfg component indices
From: AngeloGioacchino Del Regno @ 2026-07-01 12:20 UTC (permalink / raw)
  To: chunkuang.hu
  Cc: p.zabel, airlied, simona, maarten.lankhorst, mripard, tzimmermann,
	robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
	dri-devel, linux-mediatek, devicetree, linux-kernel,
	linux-arm-kernel, justin.yeh, jason-jh.lin, kernel
In-Reply-To: <20260701122057.19648-1-angelogioacchino.delregno@collabora.com>

As of now mtk_crtc assumes that, on all MediaTek SoCs, both the
vblank and configuration components are the same one, and also
that this would always be the first one in a display pipeline.

This is not true!

Or at least, it's true for the display pipelines supported by the
legacy SoCs like MT8173, and also for the ones that are currently
used in the upstream boards on more recent SoCs like MT8188/95,
but for the latter ones it just happens to be like this because
of how the boards are configured.

This is done both in preparation for adding support for complex
Display Controller pipelines like needed in MT8196 and MT8894, but
also for supporting display pipelines in MT8188/89/95 (and others
from the same generation) that are not starting with a component
that handles both vblank and layer configuration at the same time.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_crtc.c | 56 ++++++++++++++++++++++++++---
 1 file changed, 51 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_crtc.c b/drivers/gpu/drm/mediatek/mtk_crtc.c
index 35e78ece899a..6a1af60de469 100644
--- a/drivers/gpu/drm/mediatek/mtk_crtc.c
+++ b/drivers/gpu/drm/mediatek/mtk_crtc.c
@@ -61,6 +61,8 @@ struct mtk_crtc_hw_layer {
  * @mutex:           Pointer to the MediaTek MuteX device for HW triggers mute/unmuting
  * @ddp_comp_nr:     Number of HW components in ddp_comp structure
  * @ddp_comp:        Array of HW components used in one Display Controller pipeline
+ * @vblank_comp_idx: Index of HW component where to enable sending VBlanks
+ * @config_comp_idx: Index of main HW component to use for plane configuration
  * @num_conn_routes: Number of alternative connection routes for a pipeline
  * @conn_routes:     Array of HW components usable as alternative connection route
  * @hw_lock:         Display HW access mutex lock
@@ -92,6 +94,8 @@ struct mtk_crtc {
 	struct mtk_mutex		*mutex;
 	unsigned int			ddp_comp_nr;
 	struct mtk_ddp_comp		**ddp_comp;
+	s8				vblank_comp_idx;
+	s8				config_comp_idx;
 	unsigned int			num_conn_routes;
 	const struct mtk_drm_route	*conn_routes;
 
@@ -522,7 +526,7 @@ static void mtk_crtc_ddp_config(struct drm_crtc *crtc,
 {
 	struct mtk_crtc *mtk_crtc = to_mtk_crtc(crtc);
 	struct mtk_crtc_state *state = to_mtk_crtc_state(mtk_crtc->base.state);
-	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
+	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[mtk_crtc->config_comp_idx];
 	unsigned int i;
 
 	/*
@@ -692,7 +696,7 @@ static void mtk_crtc_ddp_irq(void *data)
 static int mtk_crtc_enable_vblank(struct drm_crtc *crtc)
 {
 	struct mtk_crtc *mtk_crtc = to_mtk_crtc(crtc);
-	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
+	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[mtk_crtc->vblank_comp_idx];
 
 	mtk_ddp_comp_enable_vblank(comp);
 
@@ -702,7 +706,7 @@ static int mtk_crtc_enable_vblank(struct drm_crtc *crtc)
 static void mtk_crtc_disable_vblank(struct drm_crtc *crtc)
 {
 	struct mtk_crtc *mtk_crtc = to_mtk_crtc(crtc);
-	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
+	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[mtk_crtc->vblank_comp_idx];
 
 	mtk_ddp_comp_disable_vblank(comp);
 }
@@ -815,7 +819,7 @@ static void mtk_crtc_atomic_enable(struct drm_crtc *crtc,
 				   struct drm_atomic_commit *state)
 {
 	struct mtk_crtc *mtk_crtc = to_mtk_crtc(crtc);
-	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
+	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[mtk_crtc->config_comp_idx];
 	struct drm_device *dev = mtk_crtc->base.dev;
 	int ret;
 
@@ -843,7 +847,7 @@ static void mtk_crtc_atomic_disable(struct drm_crtc *crtc,
 				    struct drm_atomic_commit *state)
 {
 	struct mtk_crtc *mtk_crtc = to_mtk_crtc(crtc);
-	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[0];
+	struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[mtk_crtc->config_comp_idx];
 	struct drm_device *dev = mtk_crtc->base.dev;
 	int i;
 
@@ -1181,6 +1185,10 @@ int mtk_crtc_create(struct drm_device *drm_dev,
 		return ret;
 	}
 
+	/* Component 0 would be valid so initialize vblank and config idx to -EINVAL */
+	mtk_crtc->vblank_comp_idx = -EINVAL;
+	mtk_crtc->config_comp_idx = -EINVAL;
+
 	for (i = 0, j = 0; i < mtk_crtc->ddp_comp_nr; i++, j++) {
 		unsigned int comp_id = output_path->comp[i].type;
 		struct mtk_ddp_comp *comp;
@@ -1203,12 +1211,50 @@ int mtk_crtc_create(struct drm_device *drm_dev,
 
 			if (comp->funcs->ctm_set)
 				has_ctm = true;
+
+			/*
+			 * Assumes that there can only be one vblank enabler per CRTC,
+			 * and that should there be more than one, the one that should
+			 * handle vblanks has to be the bottom-most HW component.
+			 */
+			if (mtk_crtc->vblank_comp_idx < 0 && comp->funcs->enable_vblank)
+				mtk_crtc->vblank_comp_idx = j;
+
+			/*
+			 * Assumes that there can only be one main configuration
+			 * component per CRTC, and that if more than one has to
+			 * be configured for at each frame, the main one would
+			 * take care of the config chain.
+			 *
+			 * As a note, such component has specific characteristics:
+			 * - It is configurable, and supports per-layer properties;
+			 * - It is a main layer component and not a layer stage;
+			 * - It is always the first one (the bottom-most) in the
+			 *   pipeline that has the characteristics explaned above.
+			 *
+			 * Such hardware is usually an OVL, RDMA or exDMA.
+			 *
+			 * This may change in the future with more complex pipelines.
+			 */
+			if (mtk_crtc->config_comp_idx < 0 && comp->funcs->config &&
+			    comp->funcs->layer_config && comp->funcs->layer_nr)
+				mtk_crtc->config_comp_idx = j;
 		}
 
 		mtk_ddp_comp_register_vblank_cb(comp, mtk_crtc_ddp_irq,
 						&mtk_crtc->base);
 	}
 
+	if (mtk_crtc->config_comp_idx < 0) {
+		dev_err(dev, "No HW component for layer configuration. Bailing out.\n");
+		return -EINVAL;
+	}
+
+	if (mtk_crtc->vblank_comp_idx < 0) {
+		dev_info(dev, "No vblank enabler component found! Expect timeouts.\n");
+		mtk_crtc->vblank_comp_idx = 0;
+	}
+
 	for (i = 0; i < mtk_crtc->ddp_comp_nr; i++) {
 		struct mtk_ddp_comp *comp = mtk_crtc->ddp_comp[i];
 
-- 
2.54.0



^ permalink raw reply related

* Re: [PATCH v3 1/3] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Leonardo Bras @ 2026-07-01 16:56 UTC (permalink / raw)
  To: Bradley Morgan
  Cc: Leonardo Bras, Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly,
	Steffen Eiden, Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
	Will Deacon, Quentin Perret, Vincent Donnefort, Gavin Shan,
	Alexandru Elisei, linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <EB48DA64-1E2E-4D8C-8F8A-ED6257AD93E9@grrlz.net>

On Wed, Jul 01, 2026 at 05:54:40PM +0100, Bradley Morgan wrote:
> On July 1, 2026 5:53:34 PM GMT+01:00, Leonardo Bras <leo.bras@arm.com>
> wrote:
> >On Wed, Jul 01, 2026 at 05:40:46PM +0100, Bradley Morgan wrote:
> >> On July 1, 2026 5:05:53 PM GMT+01:00, Leonardo Bras <leo.bras@arm.com>
> >> wrote:
> >> >On Wed, Jun 24, 2026 at 04:00:26PM +0000, Bradley Morgan wrote:
> >> >> pKVM keeps its own mapping list for stage 2 operations. Its flush
> >path
> >> >> uses that list directly, so it lost the PTE attribute check done by
> >the
> >> >> generic stage 2 walker.
> >> >> 
> >> >> Record whether a mapping is cacheable and skip cache maintenance for
> >> >> mappings that are not cacheable.
> >> >> 
> >> >> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
> >> >> Signed-off-by: Bradley Morgan <include@grrlz.net>
> >> >> ---
> >> >>  arch/arm64/kvm/pkvm.c | 51
> >++++++++++++++++++++++++++++++++++---------
> >> >>  1 file changed, 41 insertions(+), 10 deletions(-)
> >> >> 
> >> >> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
> >> >> index 428723b1b0f5..ca6e823028c2 100644
> >> >> --- a/arch/arm64/kvm/pkvm.c
> >> >> +++ b/arch/arm64/kvm/pkvm.c
> >> >> @@ -302,9 +302,32 @@ static u64 __pkvm_mapping_start(struct
> >pkvm_mapping
> >> >*m)
> >> >>  	return m->gfn * PAGE_SIZE;
> >> >>  }
> >> >>  
> >> >> +#define PKVM_MAPPING_NR_PAGES_MASK	GENMASK_ULL(47, 0)
> >> >> +#define PKVM_MAPPING_CACHEABLE		BIT_ULL(48)
> >> >
> >> >Out of curiosity here, why do you choose to use bit 48 here instead of,
> >> >let's say, bit 63?
> >> >
> >> >(I know it makes absolutely no difference to inner working here, as
> >there 
> >> >should probably not be 2^48 pages in one mapping.)
> >> >
> >> >Thanks!
> >> >Leo
> >> 
> >> 
> >> sup Leo, here's a quote from maz 
> >
> >Hi Bradley,
> >
> >> 
> >> "This thing is already big enough, let's not add a bool right in the
> >> middle (use pahole to find out why this is bad).
> >
> >I suppose you proposed to add a bool into a struct, maybe?
> >It would screw the struct alignment.
> 
> yep, crappy old me
> 

Hah, you were probably focused on the big picture.

> 
> >> Given that nr_pages
> >> is for a range, and that the minimum page size uses 12 bits, the
> >> largest number of pages you can have here is 56-12=48 bit wide. That's
> >> another 16 bits worth of flags you can use."
> >
> >Humm, makes sense.
> >And since he mentions 16 bits worth of flags, you start by using the 48th 
> >bit. Ok, got your rationale.
> >
> >(I would possibly start with the 63, though, but that's more on personal 
> >taste)
> 
> 48 won't make the world blow up :)

yeap,

> 
> >> 
> >> this should just clarify things, any questions, feel more than free to
> >ask!
> >> 
> >> (btw V4 is coming soon)
> >
> >Thanks!
> >Leo
> >
> >> 
> >> >> +
> >> >> +static u64 pkvm_mapping_nr_pages(struct pkvm_mapping *m)
> >> >> +{
> >> >> +	return m->nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
> >> >> +}
> >> >> +
> >> >> +static bool pkvm_mapping_is_cacheable(struct pkvm_mapping *m)
> >> >> +{
> >> >> +	return m->nr_pages & PKVM_MAPPING_CACHEABLE;
> >> >> +}
> >> >> +
> >> >> +static void pkvm_mapping_set_nr_pages(struct pkvm_mapping *m, u64
> >> >nr_pages,
> >> >> +				      bool cacheable)
> >> >> +{
> >> >> +	WARN_ON_ONCE(nr_pages & ~PKVM_MAPPING_NR_PAGES_MASK);
> >> >> +
> >> >> +	m->nr_pages = nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
> >> >> +	if (cacheable)
> >> >> +		m->nr_pages |= PKVM_MAPPING_CACHEABLE;
> >> >> +}
> >> >> +
> >> >>  static u64 __pkvm_mapping_end(struct pkvm_mapping *m)
> >> >>  {
> >> >> -	return (m->gfn + m->nr_pages) * PAGE_SIZE - 1;
> >> >> +	return (m->gfn + pkvm_mapping_nr_pages(m)) * PAGE_SIZE - 1;
> >> >>  }
> >> >>  
> >> >>  INTERVAL_TREE_DEFINE(struct pkvm_mapping, node, u64, __subtree_last,
> >> >> @@ -350,7 +373,7 @@ static int __pkvm_pgtable_stage2_reclaim(struct
> >> >kvm_pgtable *pgt, u64 start, u64
> >> >>  			continue;
> >> >>  
> >> >>  		page = pfn_to_page(mapping->pfn);
> >> >> -		WARN_ON_ONCE(mapping->nr_pages != 1);
> >> >> +		WARN_ON_ONCE(pkvm_mapping_nr_pages(mapping) != 1);
> >> >>  		unpin_user_pages_dirty_lock(&page, 1, true);
> >> >>  		account_locked_vm(kvm->mm, 1, false);
> >> >>  		pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> >> >> @@ -369,7 +392,7 @@ static int __pkvm_pgtable_stage2_unshare(struct
> >> >kvm_pgtable *pgt, u64 start, u64
> >> >>  
> >> >>  	for_each_mapping_in_range_safe(pgt, start, end, mapping) {
> >> >>  		ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_guest, handle, mapping->gfn,
> >> >> -					mapping->nr_pages);
> >> >> +					pkvm_mapping_nr_pages(mapping));
> >> >>  		if (WARN_ON(ret))
> >> >>  			return ret;
> >> >>  		pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
> >> >> @@ -448,7 +471,7 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable
> >*pgt,
> >> >u64 addr, u64 size,
> >> >>  		 * permission faults are handled in the relax_perms() path.
> >> >>  		 */
> >> >>  		if (mapping) {
> >> >> -			if (size == (mapping->nr_pages * PAGE_SIZE))
> >> >> +			if (size == (pkvm_mapping_nr_pages(mapping) * PAGE_SIZE))
> >> >>  				return -EAGAIN;
> >> >>  
> >> >>  			/*
> >> >> @@ -472,7 +495,9 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable
> >*pgt,
> >> >u64 addr, u64 size,
> >> >>  	swap(mapping, cache->mapping);
> >> >>  	mapping->gfn = gfn;
> >> >>  	mapping->pfn = pfn;
> >> >> -	mapping->nr_pages = size / PAGE_SIZE;
> >> >> +	pkvm_mapping_set_nr_pages(mapping, size / PAGE_SIZE,
> >> >> +				  !(prot & (KVM_PGTABLE_PROT_DEVICE |
> >> >> +					    KVM_PGTABLE_PROT_NORMAL_NC)));
> >> >>  	pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
> >> >>  
> >> >>  	return ret;
> >> >> @@ -503,7 +528,7 @@ int pkvm_pgtable_stage2_wrprotect(struct
> >kvm_pgtable
> >> >*pgt, u64 addr, u64 size)
> >> >>  	lockdep_assert_held(&kvm->mmu_lock);
> >> >>  	for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> >> >>  		ret = kvm_call_hyp_nvhe(__pkvm_host_wrprotect_guest, handle, mapping->gfn,
> >> >> -					mapping->nr_pages);
> >> >> +					pkvm_mapping_nr_pages(mapping));
> >> >>  		if (WARN_ON(ret))
> >> >>  			break;
> >> >>  	}
> >> >> @@ -517,9 +542,13 @@ int pkvm_pgtable_stage2_flush(struct kvm_pgtable
> >> >*pgt, u64 addr, u64 size)
> >> >>  	struct pkvm_mapping *mapping;
> >> >>  
> >> >>  	lockdep_assert_held(&kvm->mmu_lock);
> >> >> -	for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
> >> >> +	for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
> >> >> +		if (!pkvm_mapping_is_cacheable(mapping))
> >> >> +			continue;
> >> >> +
> >> >>  		__clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
> >> >> -					  PAGE_SIZE * mapping->nr_pages);
> >> >> +					  PAGE_SIZE * pkvm_mapping_nr_pages(mapping));
> >> >> +	}
> >> >>  
> >> >>  	return 0;
> >> >>  }
> >> >> @@ -536,8 +565,10 @@ bool pkvm_pgtable_stage2_test_clear_young(struct
> >> >kvm_pgtable *pgt, u64 addr, u64
> >> >>  
> >> >>  	lockdep_assert_held(&kvm->mmu_lock);
> >> >>  	for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
> >> >> -		young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest, handle, mapping->gfn,
> >> >> -					   mapping->nr_pages, mkold);
> >> >> +		young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest,
> >> >> +					   handle, mapping->gfn,
> >> >> +					   pkvm_mapping_nr_pages(mapping),
> >> >> +					   mkold);
> >> >>  
> >> >>  	return young;
> >> >>  }
> >> >> -- 
> >> >> 2.53.0
> >> >> 
> >> >
> >> 
> >> Thanks!
> >
> 
> Thanks!

Thanks!


^ permalink raw reply

* [PATCH 0/5] gpio: nomadik: silence boot log
From: Théo Lebrun @ 2026-07-01 16:56 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski, Philipp Zabel
  Cc: Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
	Tawfik Bayouk, Thomas Petazzoni, linux-arm-kernel, linux-gpio,
	linux-kernel, Théo Lebrun

Currently, on EyeQ5, we might get those error logs:

[    0.544230] nomadik-gpio 1400000.gpio: failed getting reset control: -EPROBE_DEFER
[    0.544274] nomadik-gpio 1400000.gpio: could not populate nmk chip struct

Then on successful probe we get:

[    0.976838] nomadik-gpio 1400000.gpio: chip registered

First line is because we don't use the appropriate dev_err_probe()
helper. Second line is redundant to populate chip dev_err() calls and
shall be dropped. Third line should be dropped.

That's done in patches 3+4+5. Patches 1+2 prepare the terrain.

Have a nice day,
Théo

Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
Théo Lebrun (5):
      gpio: nomadik: convert nmk_gpio_populate_chip() to goto cleanup
      gpio: nomadik: add missing dev_err() call on chip populate failure
      gpio: nomadik: drop duplicate probe error line
      gpio: nomadik: use dev_err_probe()
      gpio: nomadik: drop "chip registered" log on probe success

 drivers/gpio/gpio-nomadik.c | 64 ++++++++++++++++++++++-----------------------
 1 file changed, 32 insertions(+), 32 deletions(-)
---
base-commit: dc59e4fea9d83f03bad6bddf3fa2e52491777482
change-id: 20260701-gpio-nomadik-silent-678abaee1e3e

Best regards,
--  
Théo Lebrun <theo.lebrun@bootlin.com>



^ permalink raw reply

* [PATCH 2/5] gpio: nomadik: add missing dev_err() call on chip populate failure
From: Théo Lebrun @ 2026-07-01 16:56 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski, Philipp Zabel
  Cc: Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
	Tawfik Bayouk, Thomas Petazzoni, linux-arm-kernel, linux-gpio,
	linux-kernel, Théo Lebrun
In-Reply-To: <20260701-gpio-nomadik-silent-v1-0-644d10316cef@bootlin.com>

All error paths of nmk_gpio_populate_chip() lead to logging errors but
this one (ignoring the alloc or ioremap failures that must not log).

Add the single missing dev_err() call.

Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
 drivers/gpio/gpio-nomadik.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpio/gpio-nomadik.c b/drivers/gpio/gpio-nomadik.c
index f25f251f4757..4a7db282bad8 100644
--- a/drivers/gpio/gpio-nomadik.c
+++ b/drivers/gpio/gpio-nomadik.c
@@ -578,6 +578,7 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 	clk = clk_get_optional(gpio_dev, NULL);
 	if (IS_ERR(clk)) {
 		ret = PTR_ERR(clk);
+		dev_err(dev, "failed getting clock: %d\n", ret);
 		goto err_put_pdev;
 	}
 	clk_prepare(clk);

-- 
2.55.0



^ permalink raw reply related

* [PATCH 1/5] gpio: nomadik: convert nmk_gpio_populate_chip() to goto cleanup
From: Théo Lebrun @ 2026-07-01 16:56 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski, Philipp Zabel
  Cc: Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
	Tawfik Bayouk, Thomas Petazzoni, linux-arm-kernel, linux-gpio,
	linux-kernel, Théo Lebrun
In-Reply-To: <20260701-gpio-nomadik-silent-v1-0-644d10316cef@bootlin.com>

Remove duplicate teardown code that is found in all error if
statements. Replace by goto-based cleanup labels.

Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
 drivers/gpio/gpio-nomadik.c | 44 +++++++++++++++++++++++---------------------
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/drivers/gpio/gpio-nomadik.c b/drivers/gpio/gpio-nomadik.c
index e22b713166d7..f25f251f4757 100644
--- a/drivers/gpio/gpio-nomadik.c
+++ b/drivers/gpio/gpio-nomadik.c
@@ -527,15 +527,15 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 
 	if (device_property_read_u32(gpio_dev, "gpio-bank", &id)) {
 		dev_err(dev, "populate: gpio-bank property not found\n");
-		platform_device_put(gpio_pdev);
-		return ERR_PTR(-EINVAL);
+		ret = -EINVAL;
+		goto err_put_pdev;
 	}
 
 #ifdef CONFIG_PINCTRL_NOMADIK
 	if (id >= ARRAY_SIZE(nmk_gpio_chips)) {
 		dev_err(dev, "populate: invalid id: %u\n", id);
-		platform_device_put(gpio_pdev);
-		return ERR_PTR(-EINVAL);
+		ret = -EINVAL;
+		goto err_put_pdev;
 	}
 	/* Already populated? */
 	nmk_chip = nmk_gpio_chips[id];
@@ -547,8 +547,8 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 
 	nmk_chip = devm_kzalloc(dev, sizeof(*nmk_chip), GFP_KERNEL);
 	if (!nmk_chip) {
-		platform_device_put(gpio_pdev);
-		return ERR_PTR(-ENOMEM);
+		ret = -ENOMEM;
+		goto err_put_pdev;
 	}
 
 	if (device_property_read_u32(gpio_dev, "ngpios", &ngpio)) {
@@ -569,16 +569,16 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 	res = platform_get_resource(gpio_pdev, IORESOURCE_MEM, 0);
 	base = devm_ioremap_resource(dev, res);
 	if (IS_ERR(base)) {
-		platform_device_put(gpio_pdev);
-		return ERR_CAST(base);
+		ret = PTR_ERR(base);
+		goto err_put_pdev;
 	}
 	nmk_chip->addr = base;
 
 	/* NOTE: do not use devm_ here! */
 	clk = clk_get_optional(gpio_dev, NULL);
 	if (IS_ERR(clk)) {
-		platform_device_put(gpio_pdev);
-		return ERR_CAST(clk);
+		ret = PTR_ERR(clk);
+		goto err_put_pdev;
 	}
 	clk_prepare(clk);
 	nmk_chip->clk = clk;
@@ -586,12 +586,9 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 	/* NOTE: do not use devm_ here! */
 	reset = reset_control_get_optional_shared(gpio_dev, NULL);
 	if (IS_ERR(reset)) {
-		clk_unprepare(clk);
-		clk_put(clk);
-		platform_device_put(gpio_pdev);
-		dev_err(dev, "failed getting reset control: %pe\n",
-			reset);
-		return ERR_CAST(reset);
+		dev_err(dev, "failed getting reset control: %pe\n", reset);
+		ret = PTR_ERR(reset);
+		goto err_unprepare_clk;
 	}
 
 	/*
@@ -601,18 +598,23 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 	 */
 	ret = reset_control_deassert(reset);
 	if (ret) {
-		reset_control_put(reset);
-		clk_unprepare(clk);
-		clk_put(clk);
-		platform_device_put(gpio_pdev);
 		dev_err(dev, "failed reset deassert: %d\n", ret);
-		return ERR_PTR(ret);
+		goto err_put_reset;
 	}
 
 #ifdef CONFIG_PINCTRL_NOMADIK
 	nmk_gpio_chips[id] = nmk_chip;
 #endif
 	return nmk_chip;
+
+err_put_reset:
+	reset_control_put(reset);
+err_unprepare_clk:
+	clk_unprepare(clk);
+	clk_put(clk);
+err_put_pdev:
+	platform_device_put(gpio_pdev);
+	return ERR_PTR(ret);
 }
 
 static void nmk_gpio_irq_print_chip(struct irq_data *d, struct seq_file *p)

-- 
2.55.0



^ permalink raw reply related

* [PATCH 4/5] gpio: nomadik: use dev_err_probe()
From: Théo Lebrun @ 2026-07-01 16:57 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski, Philipp Zabel
  Cc: Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
	Tawfik Bayouk, Thomas Petazzoni, linux-arm-kernel, linux-gpio,
	linux-kernel, Théo Lebrun
In-Reply-To: <20260701-gpio-nomadik-silent-v1-0-644d10316cef@bootlin.com>

gpio-nomadik depends on a few resources. In one case the reset is taking
time to show up leading to a boot log containing:

[    0.544230] nomadik-gpio 1400000.gpio: failed getting reset control: -EPROBE_DEFER

Fix by replacing all dev_err() calls that might be made at probe with
dev_err_probe().

On nomadik platforms, the nmk_gpio_populate_chip() log calls might
attach their reasons to the gpio or pinctrl device depending on boot
order.

Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
 drivers/gpio/gpio-nomadik.c | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/gpio/gpio-nomadik.c b/drivers/gpio/gpio-nomadik.c
index eba095eeb3d6..1ee46f59d708 100644
--- a/drivers/gpio/gpio-nomadik.c
+++ b/drivers/gpio/gpio-nomadik.c
@@ -520,21 +520,22 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 
 	gpio_dev = bus_find_device_by_fwnode(&platform_bus_type, fwnode);
 	if (!gpio_dev) {
-		dev_err(dev, "populate \"%pfwP\": device not found\n", fwnode);
-		return ERR_PTR(-ENODEV);
+		ret = -ENODEV;
+		dev_err_probe(dev, ret, "populate \"%pfwP\": device not found\n", fwnode);
+		return ERR_PTR(ret);
 	}
 	gpio_pdev = to_platform_device(gpio_dev);
 
 	if (device_property_read_u32(gpio_dev, "gpio-bank", &id)) {
-		dev_err(dev, "populate: gpio-bank property not found\n");
 		ret = -EINVAL;
+		dev_err_probe(dev, ret, "populate: gpio-bank property not found\n");
 		goto err_put_pdev;
 	}
 
 #ifdef CONFIG_PINCTRL_NOMADIK
 	if (id >= ARRAY_SIZE(nmk_gpio_chips)) {
-		dev_err(dev, "populate: invalid id: %u\n", id);
 		ret = -EINVAL;
+		dev_err_probe(dev, ret, "populate: invalid id: %u\n", id);
 		goto err_put_pdev;
 	}
 	/* Already populated? */
@@ -578,7 +579,7 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 	clk = clk_get_optional(gpio_dev, NULL);
 	if (IS_ERR(clk)) {
 		ret = PTR_ERR(clk);
-		dev_err(dev, "failed getting clock: %d\n", ret);
+		dev_err_probe(dev, ret, "failed getting clock\n");
 		goto err_put_pdev;
 	}
 	clk_prepare(clk);
@@ -587,8 +588,8 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 	/* NOTE: do not use devm_ here! */
 	reset = reset_control_get_optional_shared(gpio_dev, NULL);
 	if (IS_ERR(reset)) {
-		dev_err(dev, "failed getting reset control: %pe\n", reset);
 		ret = PTR_ERR(reset);
+		dev_err_probe(dev, ret, "failed getting reset control\n");
 		goto err_unprepare_clk;
 	}
 
@@ -599,7 +600,7 @@ struct nmk_gpio_chip *nmk_gpio_populate_chip(struct fwnode_handle *fwnode,
 	 */
 	ret = reset_control_deassert(reset);
 	if (ret) {
-		dev_err(dev, "failed reset deassert: %d\n", ret);
+		dev_err_probe(dev, ret, "failed reset deassert\n");
 		goto err_put_reset;
 	}
 
@@ -695,7 +696,7 @@ static int nmk_gpio_probe(struct platform_device *pdev)
 	ret = devm_request_irq(dev, irq, nmk_gpio_irq_handler, IRQF_SHARED,
 			       dev_name(dev), nmk_chip);
 	if (ret) {
-		dev_err(dev, "failed requesting IRQ\n");
+		dev_err_probe(dev, ret, "failed requesting IRQ\n");
 		return ret;
 	}
 

-- 
2.55.0



^ permalink raw reply related

* [PATCH 3/5] gpio: nomadik: drop duplicate probe error line
From: Théo Lebrun @ 2026-07-01 16:57 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski, Philipp Zabel
  Cc: Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
	Tawfik Bayouk, Thomas Petazzoni, linux-arm-kernel, linux-gpio,
	linux-kernel, Théo Lebrun
In-Reply-To: <20260701-gpio-nomadik-silent-v1-0-644d10316cef@bootlin.com>

Now that all error codepaths in nmk_gpio_populate_chip() log an error,
drop dev_err() call that is made on nmk_gpio_populate_chip() failure.

Current boot log:

[    0.544230] nomadik-gpio 1400000.gpio: failed getting reset control: -EPROBE_DEFER
[    0.544274] nomadik-gpio 1400000.gpio: could not populate nmk chip struct

The second line is always redundant (or is logged when we shouldn't log,
like ioremap or alloc failures).

Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
 drivers/gpio/gpio-nomadik.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpio/gpio-nomadik.c b/drivers/gpio/gpio-nomadik.c
index 4a7db282bad8..eba095eeb3d6 100644
--- a/drivers/gpio/gpio-nomadik.c
+++ b/drivers/gpio/gpio-nomadik.c
@@ -651,10 +651,8 @@ static int nmk_gpio_probe(struct platform_device *pdev)
 	int ret;
 
 	nmk_chip = nmk_gpio_populate_chip(dev_fwnode(dev), pdev);
-	if (IS_ERR(nmk_chip)) {
-		dev_err(dev, "could not populate nmk chip struct\n");
+	if (IS_ERR(nmk_chip))
 		return PTR_ERR(nmk_chip);
-	}
 
 	supports_sleepmode =
 		device_property_read_bool(dev, "st,supports-sleepmode");

-- 
2.55.0



^ permalink raw reply related

* [PATCH 5/5] gpio: nomadik: drop "chip registered" log on probe success
From: Théo Lebrun @ 2026-07-01 16:57 UTC (permalink / raw)
  To: Linus Walleij, Bartosz Golaszewski, Philipp Zabel
  Cc: Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
	Tawfik Bayouk, Thomas Petazzoni, linux-arm-kernel, linux-gpio,
	linux-kernel, Théo Lebrun
In-Reply-To: <20260701-gpio-nomadik-silent-v1-0-644d10316cef@bootlin.com>

Successful driver probing should be silent. Drop unconditional
dev_info() call that is done at nmk_gpio_probe() exit.

Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
---
 drivers/gpio/gpio-nomadik.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpio/gpio-nomadik.c b/drivers/gpio/gpio-nomadik.c
index 1ee46f59d708..244331f468cc 100644
--- a/drivers/gpio/gpio-nomadik.c
+++ b/drivers/gpio/gpio-nomadik.c
@@ -712,8 +712,6 @@ static int nmk_gpio_probe(struct platform_device *pdev)
 
 	platform_set_drvdata(pdev, nmk_chip);
 
-	dev_info(dev, "chip registered\n");
-
 	return 0;
 }
 

-- 
2.55.0



^ permalink raw reply related

* Re: [PATCH v3 1/3] KVM: arm64: skip pKVM cache flushes for non cacheable mappings
From: Bradley Morgan @ 2026-07-01 16:57 UTC (permalink / raw)
  To: Leonardo Bras
  Cc: Marc Zyngier, Oliver Upton, Fuad Tabba, Joey Gouly, Steffen Eiden,
	Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
	Quentin Perret, Vincent Donnefort, Gavin Shan, Alexandru Elisei,
	linux-arm-kernel, kvmarm, linux-kernel
In-Reply-To: <akVGxdakrVYp8kho@LeoBrasDK>

On July 1, 2026 5:56:37 PM GMT+01:00, Leonardo Bras <leo.bras@arm.com>
wrote:
>On Wed, Jul 01, 2026 at 05:54:40PM +0100, Bradley Morgan wrote:
>> On July 1, 2026 5:53:34 PM GMT+01:00, Leonardo Bras <leo.bras@arm.com>
>> wrote:
>> >On Wed, Jul 01, 2026 at 05:40:46PM +0100, Bradley Morgan wrote:
>> >> On July 1, 2026 5:05:53 PM GMT+01:00, Leonardo Bras
><leo.bras@arm.com>
>> >> wrote:
>> >> >On Wed, Jun 24, 2026 at 04:00:26PM +0000, Bradley Morgan wrote:
>> >> >> pKVM keeps its own mapping list for stage 2 operations. Its flush
>> >path
>> >> >> uses that list directly, so it lost the PTE attribute check done
>by
>> >the
>> >> >> generic stage 2 walker.
>> >> >> 
>> >> >> Record whether a mapping is cacheable and skip cache maintenance
>for
>> >> >> mappings that are not cacheable.
>> >> >> 
>> >> >> Fixes: e912efed485a ("KVM: arm64: Introduce the EL1 pKVM MMU")
>> >> >> Signed-off-by: Bradley Morgan <include@grrlz.net>
>> >> >> ---
>> >> >>  arch/arm64/kvm/pkvm.c | 51
>> >++++++++++++++++++++++++++++++++++---------
>> >> >>  1 file changed, 41 insertions(+), 10 deletions(-)
>> >> >> 
>> >> >> diff --git a/arch/arm64/kvm/pkvm.c b/arch/arm64/kvm/pkvm.c
>> >> >> index 428723b1b0f5..ca6e823028c2 100644
>> >> >> --- a/arch/arm64/kvm/pkvm.c
>> >> >> +++ b/arch/arm64/kvm/pkvm.c
>> >> >> @@ -302,9 +302,32 @@ static u64 __pkvm_mapping_start(struct
>> >pkvm_mapping
>> >> >*m)
>> >> >>  	return m->gfn * PAGE_SIZE;
>> >> >>  }
>> >> >>  
>> >> >> +#define PKVM_MAPPING_NR_PAGES_MASK	GENMASK_ULL(47, 0)
>> >> >> +#define PKVM_MAPPING_CACHEABLE		BIT_ULL(48)
>> >> >
>> >> >Out of curiosity here, why do you choose to use bit 48 here instead
>of,
>> >> >let's say, bit 63?
>> >> >
>> >> >(I know it makes absolutely no difference to inner working here, as
>> >there 
>> >> >should probably not be 2^48 pages in one mapping.)
>> >> >
>> >> >Thanks!
>> >> >Leo
>> >> 
>> >> 
>> >> sup Leo, here's a quote from maz 
>> >
>> >Hi Bradley,
>> >
>> >> 
>> >> "This thing is already big enough, let's not add a bool right in the
>> >> middle (use pahole to find out why this is bad).
>> >
>> >I suppose you proposed to add a bool into a struct, maybe?
>> >It would screw the struct alignment.
>> 
>> yep, crappy old me
>> 
>
>Hah, you were probably focused on the big picture.
>
>> 
>> >> Given that nr_pages
>> >> is for a range, and that the minimum page size uses 12 bits, the
>> >> largest number of pages you can have here is 56-12=48 bit wide.
>That's
>> >> another 16 bits worth of flags you can use."
>> >
>> >Humm, makes sense.
>> >And since he mentions 16 bits worth of flags, you start by using the
>48th 
>> >bit. Ok, got your rationale.
>> >
>> >(I would possibly start with the 63, though, but that's more on
>personal 
>> >taste)
>> 
>> 48 won't make the world blow up :)
>
>yeap,


Would you like to be CCed on v4 or nahhhh?

>> 
>> >> 
>> >> this should just clarify things, any questions, feel more than free
>to
>> >ask!
>> >> 
>> >> (btw V4 is coming soon)
>> >
>> >Thanks!
>> >Leo
>> >
>> >> 
>> >> >> +
>> >> >> +static u64 pkvm_mapping_nr_pages(struct pkvm_mapping *m)
>> >> >> +{
>> >> >> +	return m->nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
>> >> >> +}
>> >> >> +
>> >> >> +static bool pkvm_mapping_is_cacheable(struct pkvm_mapping *m)
>> >> >> +{
>> >> >> +	return m->nr_pages & PKVM_MAPPING_CACHEABLE;
>> >> >> +}
>> >> >> +
>> >> >> +static void pkvm_mapping_set_nr_pages(struct pkvm_mapping *m, u64
>> >> >nr_pages,
>> >> >> +				      bool cacheable)
>> >> >> +{
>> >> >> +	WARN_ON_ONCE(nr_pages & ~PKVM_MAPPING_NR_PAGES_MASK);
>> >> >> +
>> >> >> +	m->nr_pages = nr_pages & PKVM_MAPPING_NR_PAGES_MASK;
>> >> >> +	if (cacheable)
>> >> >> +		m->nr_pages |= PKVM_MAPPING_CACHEABLE;
>> >> >> +}
>> >> >> +
>> >> >>  static u64 __pkvm_mapping_end(struct pkvm_mapping *m)
>> >> >>  {
>> >> >> -	return (m->gfn + m->nr_pages) * PAGE_SIZE - 1;
>> >> >> +	return (m->gfn + pkvm_mapping_nr_pages(m)) * PAGE_SIZE - 1;
>> >> >>  }
>> >> >>  
>> >> >>  INTERVAL_TREE_DEFINE(struct pkvm_mapping, node, u64,
>__subtree_last,
>> >> >> @@ -350,7 +373,7 @@ static int
>__pkvm_pgtable_stage2_reclaim(struct
>> >> >kvm_pgtable *pgt, u64 start, u64
>> >> >>  			continue;
>> >> >>  
>> >> >>  		page = pfn_to_page(mapping->pfn);
>> >> >> -		WARN_ON_ONCE(mapping->nr_pages != 1);
>> >> >> +		WARN_ON_ONCE(pkvm_mapping_nr_pages(mapping) != 1);
>> >> >>  		unpin_user_pages_dirty_lock(&page, 1, true);
>> >> >>  		account_locked_vm(kvm->mm, 1, false);
>> >> >>  		pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
>> >> >> @@ -369,7 +392,7 @@ static int
>__pkvm_pgtable_stage2_unshare(struct
>> >> >kvm_pgtable *pgt, u64 start, u64
>> >> >>  
>> >> >>  	for_each_mapping_in_range_safe(pgt, start, end, mapping) {
>> >> >>  		ret = kvm_call_hyp_nvhe(__pkvm_host_unshare_guest, handle, mapping->gfn,
>> >> >> -					mapping->nr_pages);
>> >> >> +					pkvm_mapping_nr_pages(mapping));
>> >> >>  		if (WARN_ON(ret))
>> >> >>  			return ret;
>> >> >>  		pkvm_mapping_remove(mapping, &pgt->pkvm_mappings);
>> >> >> @@ -448,7 +471,7 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable
>> >*pgt,
>> >> >u64 addr, u64 size,
>> >> >>  		 * permission faults are handled in the relax_perms() path.
>> >> >>  		 */
>> >> >>  		if (mapping) {
>> >> >> -			if (size == (mapping->nr_pages * PAGE_SIZE))
>> >> >> +			if (size == (pkvm_mapping_nr_pages(mapping) * PAGE_SIZE))
>> >> >>  				return -EAGAIN;
>> >> >>  
>> >> >>  			/*
>> >> >> @@ -472,7 +495,9 @@ int pkvm_pgtable_stage2_map(struct kvm_pgtable
>> >*pgt,
>> >> >u64 addr, u64 size,
>> >> >>  	swap(mapping, cache->mapping);
>> >> >>  	mapping->gfn = gfn;
>> >> >>  	mapping->pfn = pfn;
>> >> >> -	mapping->nr_pages = size / PAGE_SIZE;
>> >> >> +	pkvm_mapping_set_nr_pages(mapping, size / PAGE_SIZE,
>> >> >> +				  !(prot & (KVM_PGTABLE_PROT_DEVICE |
>> >> >> +					    KVM_PGTABLE_PROT_NORMAL_NC)));
>> >> >>  	pkvm_mapping_insert(mapping, &pgt->pkvm_mappings);
>> >> >>  
>> >> >>  	return ret;
>> >> >> @@ -503,7 +528,7 @@ int pkvm_pgtable_stage2_wrprotect(struct
>> >kvm_pgtable
>> >> >*pgt, u64 addr, u64 size)
>> >> >>  	lockdep_assert_held(&kvm->mmu_lock);
>> >> >>  	for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
>> >> >>  		ret = kvm_call_hyp_nvhe(__pkvm_host_wrprotect_guest, handle, mapping->gfn,
>> >> >> -					mapping->nr_pages);
>> >> >> +					pkvm_mapping_nr_pages(mapping));
>> >> >>  		if (WARN_ON(ret))
>> >> >>  			break;
>> >> >>  	}
>> >> >> @@ -517,9 +542,13 @@ int pkvm_pgtable_stage2_flush(struct
>kvm_pgtable
>> >> >*pgt, u64 addr, u64 size)
>> >> >>  	struct pkvm_mapping *mapping;
>> >> >>  
>> >> >>  	lockdep_assert_held(&kvm->mmu_lock);
>> >> >> -	for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
>> >> >> +	for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping) {
>> >> >> +		if (!pkvm_mapping_is_cacheable(mapping))
>> >> >> +			continue;
>> >> >> +
>> >> >>  		__clean_dcache_guest_page(pfn_to_kaddr(mapping->pfn),
>> >> >> -					  PAGE_SIZE * mapping->nr_pages);
>> >> >> +					  PAGE_SIZE * pkvm_mapping_nr_pages(mapping));
>> >> >> +	}
>> >> >>  
>> >> >>  	return 0;
>> >> >>  }
>> >> >> @@ -536,8 +565,10 @@ bool
>pkvm_pgtable_stage2_test_clear_young(struct
>> >> >kvm_pgtable *pgt, u64 addr, u64
>> >> >>  
>> >> >>  	lockdep_assert_held(&kvm->mmu_lock);
>> >> >>  	for_each_mapping_in_range_safe(pgt, addr, addr + size, mapping)
>> >> >> -		young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest, handle, mapping->gfn,
>> >> >> -					   mapping->nr_pages, mkold);
>> >> >> +		young |= kvm_call_hyp_nvhe(__pkvm_host_test_clear_young_guest,
>> >> >> +					   handle, mapping->gfn,
>> >> >> +					   pkvm_mapping_nr_pages(mapping),
>> >> >> +					   mkold);
>> >> >>  
>> >> >>  	return young;
>> >> >>  }
>> >> >> -- 
>> >> >> 2.53.0
>> >> >> 
>> >> >
>> >> 
>> >> Thanks!
>> >
>> 
>> Thanks!
>
>Thanks!
>

Thanks!


^ permalink raw reply

* [PATCH 02/12] phy: phy-mtk-dp: Rename regs to regmap in struct mtk_dp_phy
From: AngeloGioacchino Del Regno @ 2026-07-01 12:19 UTC (permalink / raw)
  To: chunfeng.yun
  Cc: vkoul, neil.armstrong, robh, krzk+dt, conor+dt, matthias.bgg,
	angelogioacchino.delregno, chunkuang.hu, p.zabel, justin.yeh,
	linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
	linux-kernel, dri-devel, kernel
In-Reply-To: <20260701122008.19509-1-angelogioacchino.delregno@collabora.com>

In preparation to perform further cleanups and to extend the
driver to support more SoCs, rename the `regs` member to `regmap`
to improve readability, as this is a common name across many
kernel drivers for a struct regmap.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/phy/mediatek/phy-mtk-dp.c | 20 ++++++++++----------
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/phy/mediatek/phy-mtk-dp.c b/drivers/phy/mediatek/phy-mtk-dp.c
index d7024a144335..bf7b3a95e72d 100644
--- a/drivers/phy/mediatek/phy-mtk-dp.c
+++ b/drivers/phy/mediatek/phy-mtk-dp.c
@@ -79,7 +79,7 @@
 				 XTP_LN_TX_LCTXCP1_SW3_PRE0_DEFAULT)
 
 struct mtk_dp_phy {
-	struct regmap *regs;
+	struct regmap *regmap;
 };
 
 static int mtk_dp_phy_init(struct phy *phy)
@@ -94,13 +94,13 @@ static int mtk_dp_phy_init(struct phy *phy)
 		DRIVING_PARAM_8_DEFAULT
 	};
 
-	regmap_bulk_write(dp_phy->regs, MTK_DP_LANE0_DRIVING_PARAM_3,
+	regmap_bulk_write(dp_phy->regmap, MTK_DP_LANE0_DRIVING_PARAM_3,
 			  driving_params, ARRAY_SIZE(driving_params));
-	regmap_bulk_write(dp_phy->regs, MTK_DP_LANE1_DRIVING_PARAM_3,
+	regmap_bulk_write(dp_phy->regmap, MTK_DP_LANE1_DRIVING_PARAM_3,
 			  driving_params, ARRAY_SIZE(driving_params));
-	regmap_bulk_write(dp_phy->regs, MTK_DP_LANE2_DRIVING_PARAM_3,
+	regmap_bulk_write(dp_phy->regmap, MTK_DP_LANE2_DRIVING_PARAM_3,
 			  driving_params, ARRAY_SIZE(driving_params));
-	regmap_bulk_write(dp_phy->regs, MTK_DP_LANE3_DRIVING_PARAM_3,
+	regmap_bulk_write(dp_phy->regmap, MTK_DP_LANE3_DRIVING_PARAM_3,
 			  driving_params, ARRAY_SIZE(driving_params));
 
 	return 0;
@@ -131,10 +131,10 @@ static int mtk_dp_phy_configure(struct phy *phy, union phy_configure_opts *opts)
 			val = BIT_RATE_HBR3;
 			break;
 		}
-		regmap_write(dp_phy->regs, MTK_DP_PHY_DIG_BIT_RATE, val);
+		regmap_write(dp_phy->regmap, MTK_DP_PHY_DIG_BIT_RATE, val);
 	}
 
-	regmap_update_bits(dp_phy->regs, MTK_DP_PHY_DIG_PLL_CTL_1,
+	regmap_update_bits(dp_phy->regmap, MTK_DP_PHY_DIG_PLL_CTL_1,
 			   TPLL_SSC_EN, opts->dp.ssc ? TPLL_SSC_EN : 0);
 
 	return 0;
@@ -144,10 +144,10 @@ static int mtk_dp_phy_reset(struct phy *phy)
 {
 	struct mtk_dp_phy *dp_phy = phy_get_drvdata(phy);
 
-	regmap_update_bits(dp_phy->regs, MTK_DP_PHY_DIG_SW_RST,
+	regmap_update_bits(dp_phy->regmap, MTK_DP_PHY_DIG_SW_RST,
 			   DP_GLB_SW_RST_PHYD, 0);
 	usleep_range(50, 200);
-	regmap_update_bits(dp_phy->regs, MTK_DP_PHY_DIG_SW_RST,
+	regmap_update_bits(dp_phy->regmap, MTK_DP_PHY_DIG_SW_RST,
 			   DP_GLB_SW_RST_PHYD, 1);
 
 	return 0;
@@ -176,7 +176,7 @@ static int mtk_dp_phy_probe(struct platform_device *pdev)
 	if (!dp_phy)
 		return -ENOMEM;
 
-	dp_phy->regs = regs;
+	dp_phy->regmap = regs;
 	phy = devm_phy_create(dev, NULL, &mtk_dp_phy_dev_ops);
 	if (IS_ERR(phy))
 		return dev_err_probe(dev, PTR_ERR(phy),
-- 
2.54.0



^ permalink raw reply related

* Re: [PATCH] dt-bindings: dma: mediatek,uart-dma: add support for MT8189 SoC
From: Conor Dooley @ 2026-07-01 16:59 UTC (permalink / raw)
  To: Louis-Alexis Eyraud
  Cc: Sean Wang, Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
	Long Cheng, kernel, dmaengine, linux-arm-kernel, linux-mediatek,
	devicetree, linux-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-uart-dma-v1-1-c7106216a40d@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply

* Re: [PATCH] dt-bindings: phy: mediatek,tphy: Add support for MT8189 SoC
From: Conor Dooley @ 2026-07-01 16:59 UTC (permalink / raw)
  To: Louis-Alexis Eyraud
  Cc: Chunfeng Yun, Vinod Koul, Neil Armstrong, Rob Herring,
	Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
	AngeloGioacchino Del Regno, kernel, linux-arm-kernel,
	linux-mediatek, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260701-mt8189-dt-bindings-tphy-v1-1-5848a2be8303@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply

* Re: [PATCH] dt-bindings: mfd: mediatek,mt8195-scpsys: Add support for MT8189 SoC
From: Conor Dooley @ 2026-07-01 17:00 UTC (permalink / raw)
  To: Louis-Alexis Eyraud
  Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
	Matthias Brugger, AngeloGioacchino Del Regno, kernel, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260701-mt8189-dt-bindings-scpsys-v1-1-2c04f0fda1b7@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply

* [PATCH 01/11] dt-bindings: display: mediatek: dp: Deprecate nvmem efuse data
From: AngeloGioacchino Del Regno @ 2026-07-01 12:20 UTC (permalink / raw)
  To: chunkuang.hu
  Cc: p.zabel, airlied, simona, maarten.lankhorst, mripard, tzimmermann,
	robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
	jitao.shi, granquet, rex-bc.chen, dmitry.osipenko, ck.hu,
	amergnat, justin.yeh, jason-jh.lin, dri-devel, linux-mediatek,
	devicetree, linux-kernel, linux-arm-kernel, kernel
In-Reply-To: <20260701122024.19557-1-angelogioacchino.delregno@collabora.com>

Deprecate nvmem-cells and nvmem-cell-names and clarify their
purpose, as those are for PHY calibration data, not for the DP
IP itself, and that data shall go in the PHY binding instead.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 .../devicetree/bindings/display/mediatek/mediatek,dp.yaml     | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
index 8f4bd9fb560b..980f76667ada 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
@@ -30,10 +30,12 @@ properties:
     maxItems: 1
 
   nvmem-cells:
+    deprecated: true
     maxItems: 1
-    description: efuse data for display port calibration
+    description: efuse data for display port phy calibration
 
   nvmem-cell-names:
+    deprecated: true
     const: dp_calibration_data
 
   power-domains:
-- 
2.54.0



^ permalink raw reply related

* Re: [PATCH] dt-bindings: mmc: mtk-sd: Document extra clocks for MT8189
From: Conor Dooley @ 2026-07-01 17:03 UTC (permalink / raw)
  To: Louis-Alexis Eyraud
  Cc: Chaotian Jing, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
	Wenbin Mei, kernel, Krzysztof Kozlowski, linux-mmc, devicetree,
	linux-kernel, linux-arm-kernel, linux-mediatek
In-Reply-To: <20260701-mt8189-mmc-dt-bindings-fix-v1-1-e75f241a275b@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 349 bytes --]

On Wed, Jul 01, 2026 at 04:44:26PM +0200, Louis-Alexis Eyraud wrote:
> MT8189 SoC MMC Controller IP has 4 additional clocks.

I think "additional" is slightly confusing wording here, since you go on
to permit 6 not 11 (the binding already allows 7).

Not a big deak though,
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply

* [PATCH 04/11] drm/mediatek: mtk_dp: Clarify SMC eDP/DP video unmute commands
From: AngeloGioacchino Del Regno @ 2026-07-01 12:20 UTC (permalink / raw)
  To: chunkuang.hu
  Cc: p.zabel, airlied, simona, maarten.lankhorst, mripard, tzimmermann,
	robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
	jitao.shi, granquet, rex-bc.chen, dmitry.osipenko, ck.hu,
	amergnat, justin.yeh, jason-jh.lin, dri-devel, linux-mediatek,
	devicetree, linux-kernel, linux-arm-kernel, kernel
In-Reply-To: <20260701122024.19557-1-angelogioacchino.delregno@collabora.com>

The eDP/DP video unmute commands are not expressed as bits:
instead, in the firmware, those are defined as incremental
unsigned integer numbers: use the correct representation of
those to improve readability.

This commit brings no functional changes.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 drivers/gpu/drm/mediatek/mtk_dp.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_dp.c b/drivers/gpu/drm/mediatek/mtk_dp.c
index 2c738c16dafa..f551c4543f4e 100644
--- a/drivers/gpu/drm/mediatek/mtk_dp.c
+++ b/drivers/gpu/drm/mediatek/mtk_dp.c
@@ -36,8 +36,8 @@
 #include "mtk_dp_reg.h"
 
 #define MTK_DP_SIP_CONTROL_AARCH32	MTK_SIP_SMC_CMD(0x523)
-#define MTK_DP_SIP_ATF_EDP_VIDEO_UNMUTE	(BIT(0) | BIT(5))
-#define MTK_DP_SIP_ATF_VIDEO_UNMUTE	BIT(5)
+#define MTK_DP_SIP_ATF_EDP_VIDEO_UNMUTE	33
+#define MTK_DP_SIP_ATF_VIDEO_UNMUTE	32
 
 #define MTK_DP_THREAD_CABLE_STATE_CHG	BIT(0)
 #define MTK_DP_THREAD_HPD_EVENT		BIT(1)
-- 
2.54.0



^ permalink raw reply related

* Re: [PATCH v3 1/2] dt-bindings: arm: fsl: add compatible for new Skov I.MX8MP variant
From: Conor Dooley @ 2026-07-01 17:07 UTC (permalink / raw)
  To: Steffen Trumtrar
  Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
	Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
	devicetree, linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260701-v7-0-topic-imx8mp-skov-dts-jutouch-7inch-v3-1-d74f7e3f8293@pengutronix.de>

[-- Attachment #1: Type: text/plain, Size: 75 bytes --]

Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

^ permalink raw reply

* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Markus Probst @ 2026-07-01 17:08 UTC (permalink / raw)
  To: Alexandre Belloni
  Cc: Krzysztof Kozlowski, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Uwe Kleine-König, Andrew Lunn, Gregory Clement,
	Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
	linux-kernel
In-Reply-To: <20260701164821b7492eac@mail.local>

[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]

On Wed, 2026-07-01 at 18:48 +0200, Alexandre Belloni wrote:
> On 01/07/2026 16:43:07+0000, Markus Probst wrote:
> > On Wed, 2026-07-01 at 17:14 +0200, Krzysztof Kozlowski wrote:
> > > On 01/07/2026 15:25, Markus Probst wrote:
> > > > > > +
> > > > > > +maintainers:
> > > > > > +  - Alexandre Belloni <alexandre.belloni@bootlin.com>
> > > > > 
> > > > > This should be someone caring about this hardware.
> > > > He does have the majority of commits on this driver (excluding merge
> > > > commits and commits not exclusive to this driver), although most of
> > > > them are pretty tiny.
> > > > 
> > > > Who would you suggest instead?
> > > 
> > > Someone adding features for this driver, maybe driver maintainers. But
> > > if Alexandre is fine, you can leave him.
> > > 
> > > > > 
> > > > > > +
> > > > > > +description:
> > > > > > +  The S-35390A is a CMOS 2-wire real-time clock IC which operates with the
> > > > > > +  very low current consumption in the wide range of operation voltage.
> > > > > > +
> > > > > > +allOf:
> > > > > > +  - $ref: rtc.yaml#
> > > > > > +
> > > > > > +properties:
> > > > > > +  compatible:
> > > > > > +    const: sii,s35390a
> > > > > > +
> > > > > > +  reg:
> > > > > > +    maxItems: 1
> > > > > > +
> > > > > > +  sii,wakealarm-output-pin:
> > > > > > +    $ref: /schemas/types.yaml#/definitions/uint32
> > > > > > +    enum: [1, 2]
> > > > > > +    description: |
> > > > > > +      The output pin to wake up the system.
> > > > > > +      Default will use the output pin for interrupt signal 2.
> > > > > > +        <S35390A_OUTPUT_PIN_INT1> : Output pin for interrupt signal 1
> > > > > > +        <S35390A_OUTPUT_PIN_INT2> : Output pin for interrupt signal 2
> > > > > 
> > > > > Does that mean device generates the interrupts?
> > > > Yes.
> > > > 
> > > 
> > > 
> > > Then I think you miss interrupts property.
> > From what I can tell the line is used to generate a system wakeup
> > event.
> > 
> > There would be no obvious benefit of connecting it to an interrupt
> > controller, so this property would be obsolete?
> > 
> 
> Then you need proper wakeup-source support
Wouldn't that break existing devicetrees?

The current driver allows to wake up the system, even without
having wakeup-source set.

As an example: arch/arm/boot/dts/marvell/kirkwood-ts219.dtsi

Thanks
- Markus Probst

> 
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]

^ permalink raw reply

* Re: [PATCH] arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1
From: Oliver Upton @ 2026-07-01 17:09 UTC (permalink / raw)
  To: Jia He
  Cc: Catalin Marinas, Will Deacon, Marc Zyngier, linux-arm-kernel,
	Lorenzo Pieralisi, Mark Brown, Sascha Bischoff, Fuad Tabba,
	Anshuman Khandual, linux-kernel, Bin Guo
In-Reply-To: <20260630222347.1449737-1-justin.he@arm.com>

On Tue, Jun 30, 2026 at 10:23:47PM +0000, Jia He wrote:
> Commit 93d7356e4b30 ("arm64: sysreg: Describe ID_AA64DFR2_EL1 fields")
> encodes the FEAT_BWE2 value of the BWE field as '0b0002'. Binary
> literals only accept the digits 0 and 1, so the intended value is 2,
> i.e. 0b0010.
> 
> The macro generated by gen-sysreg.awk currently expands to
> 	#define ID_AA64DFR2_EL1_BWE_FEAT_BWE2 UL(0b0002)
> is not legal C and would fail to compile if any in-tree code referenced
> it. At present no caller uses this enum value, so the kernel still
> builds cleanly, but the bug is latent.
> 
> Fix the typo by using the correct binary literal 0b0010.
> 
> Cc: Bin Guo <guobin@linux.alibaba.com>
> Fixes: 93d7356e4b30 ("arm64: sysreg: Describe ID_AA64DFR2_EL1 fields")
> Signed-off-by: Jia He <justin.he@arm.com>
> Reviewed-by: Mark Brown <broonie@kernel.org>

Hah, I screwed that up pretty good!

Reviewed-by: Oliver Upton <oupton@kernel.org>

> ---
>  arch/arm64/tools/sysreg | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm64/tools/sysreg b/arch/arm64/tools/sysreg
> index bc1788b1662b..7cb61aca3797 100644
> --- a/arch/arm64/tools/sysreg
> +++ b/arch/arm64/tools/sysreg
> @@ -1806,7 +1806,7 @@ Res0	15:8
>  UnsignedEnum	7:4	BWE
>  	0b0000	NI
>  	0b0001	FEAT_BWE
> -	0b0002	FEAT_BWE2
> +	0b0010	FEAT_BWE2
>  EndEnum
>  UnsignedEnum	3:0	STEP
>  	0b0000	NI
> -- 
> 2.34.1
> 


^ permalink raw reply

* [PATCH 2/7] arm64: dts: mediatek: mt8173: Add and use UART AP_DMA controller
From: AngeloGioacchino Del Regno @ 2026-07-01 12:19 UTC (permalink / raw)
  To: linux-mediatek
  Cc: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
	devicetree, linux-kernel, linux-arm-kernel, kernel, justin.yeh
In-Reply-To: <20260701121929.19374-1-angelogioacchino.delregno@collabora.com>

This SoC has a DMA controller (AP_DMA) that provides one channel
for each data direction (transmit and receive) for all of the
UART controllers in the SoC.

In order to increase the efficiency of data TX/RX over the UART
controllers, add the UART DMA controller and assign the right
channels to each of the four UART controllers.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
---
 arch/arm64/boot/dts/mediatek/mt8173.dtsi | 27 ++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 81ddb4eec48e..43159ae6da8f 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -673,6 +673,25 @@ gic: interrupt-controller@10221000 {
 				(GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
 		};
 
+		apdma: dma-controller@11000300 {
+			compatible = "mediatek,mt8173-uart-dma", "mediatek,mt6577-uart-dma";
+			reg = <0 0x11000300 0 0x80>, <0 0x11000380 0 0x80>,
+			      <0 0x11000400 0 0x80>, <0 0x11000480 0 0x80>,
+			      <0 0x11000500 0 0x80>, <0 0x11000580 0 0x80>,
+			      <0 0x11000600 0 0x80>, <0 0x11000680 0 0x80>;
+			interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_SPI 96 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_SPI 97 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_SPI 98 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_SPI 99 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_SPI 100 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_SPI 101 IRQ_TYPE_LEVEL_LOW>,
+				     <GIC_SPI 100 IRQ_TYPE_LEVEL_LOW>;
+			clocks = <&pericfg CLK_PERI_AP_DMA>;
+			#dma-cells = <1>;
+			dma-requests = <8>;
+		};
+
 		auxadc: auxadc@11001000 {
 			compatible = "mediatek,mt8173-auxadc";
 			reg = <0 0x11001000 0 0x1000>;
@@ -688,6 +707,8 @@ uart0: serial@11002000 {
 			interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_LOW>;
 			clocks = <&pericfg CLK_PERI_UART0_SEL>, <&pericfg CLK_PERI_UART0>;
 			clock-names = "baud", "bus";
+			dmas = <&apdma 0>, <&apdma 1>;
+			dma-names = "tx", "rx";
 			status = "disabled";
 		};
 
@@ -698,6 +719,8 @@ uart1: serial@11003000 {
 			interrupts = <GIC_SPI 84 IRQ_TYPE_LEVEL_LOW>;
 			clocks = <&pericfg CLK_PERI_UART1_SEL>, <&pericfg CLK_PERI_UART1>;
 			clock-names = "baud", "bus";
+			dmas = <&apdma 2>, <&apdma 3>;
+			dma-names = "tx", "rx";
 			status = "disabled";
 		};
 
@@ -708,6 +731,8 @@ uart2: serial@11004000 {
 			interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_LOW>;
 			clocks = <&pericfg CLK_PERI_UART2_SEL>, <&pericfg CLK_PERI_UART2>;
 			clock-names = "baud", "bus";
+			dmas = <&apdma 4>, <&apdma 5>;
+			dma-names = "tx", "rx";
 			status = "disabled";
 		};
 
@@ -718,6 +743,8 @@ uart3: serial@11005000 {
 			interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_LOW>;
 			clocks = <&pericfg CLK_PERI_UART3_SEL>, <&pericfg CLK_PERI_UART3>;
 			clock-names = "baud", "bus";
+			dmas = <&apdma 6>, <&apdma 7>;
+			dma-names = "tx", "rx";
 			status = "disabled";
 		};
 
-- 
2.54.0



^ permalink raw reply related


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox