* [PATCH v2 28/30] KVM: arm64: Directly expose mapping prot and kill kvm_s2_fault
From: Marc Zyngier @ 2026-03-27 11:36 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-1-maz@kernel.org>
The 'prot' field is the only one left in kvm_s2_fault. Expose it
directly to the functions needing it, and get rid of kvm_s2_fault.
It has served us well during this refactoring, but it is now no
longer needed.
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 45 +++++++++++++++++++++-----------------------
1 file changed, 21 insertions(+), 24 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 23245ee7b1ec2..0fbdac77b1140 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1729,10 +1729,6 @@ static short kvm_s2_resolve_vma_size(const struct kvm_s2_fault_desc *s2fd,
return vma_shift;
}
-struct kvm_s2_fault {
- enum kvm_pgtable_prot prot;
-};
-
static bool kvm_s2_fault_is_perm(const struct kvm_s2_fault_desc *s2fd)
{
return kvm_vcpu_trap_is_permission_fault(s2fd->vcpu);
@@ -1856,8 +1852,8 @@ static int kvm_s2_fault_pin_pfn(const struct kvm_s2_fault_desc *s2fd,
}
static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
- struct kvm_s2_fault *fault,
- const struct kvm_s2_fault_vma_info *s2vi)
+ const struct kvm_s2_fault_vma_info *s2vi,
+ enum kvm_pgtable_prot *prot)
{
struct kvm *kvm = s2fd->vcpu->kvm;
bool writable = s2vi->map_writable;
@@ -1885,23 +1881,25 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
return 1;
}
+ *prot = KVM_PGTABLE_PROT_R;
+
if (s2fd->nested)
- adjust_nested_fault_perms(s2fd->nested, &fault->prot, &writable);
+ adjust_nested_fault_perms(s2fd->nested, prot, &writable);
if (writable)
- fault->prot |= KVM_PGTABLE_PROT_W;
+ *prot |= KVM_PGTABLE_PROT_W;
if (kvm_vcpu_trap_is_exec_fault(s2fd->vcpu))
- fault->prot |= KVM_PGTABLE_PROT_X;
+ *prot |= KVM_PGTABLE_PROT_X;
if (s2vi->map_non_cacheable)
- fault->prot |= (s2vi->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
- KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
+ *prot |= (s2vi->vm_flags & VM_ALLOW_ANY_UNCACHED) ?
+ KVM_PGTABLE_PROT_NORMAL_NC : KVM_PGTABLE_PROT_DEVICE;
else if (cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
- fault->prot |= KVM_PGTABLE_PROT_X;
+ *prot |= KVM_PGTABLE_PROT_X;
if (s2fd->nested)
- adjust_nested_exec_perms(kvm, s2fd->nested, &fault->prot);
+ adjust_nested_exec_perms(kvm, s2fd->nested, prot);
if (!kvm_s2_fault_is_perm(s2fd) && !s2vi->map_non_cacheable && kvm_has_mte(kvm)) {
/* Check the VMM hasn't introduced a new disallowed VMA */
@@ -1913,11 +1911,12 @@ static int kvm_s2_fault_compute_prot(const struct kvm_s2_fault_desc *s2fd,
}
static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
- struct kvm_s2_fault *fault,
- const struct kvm_s2_fault_vma_info *s2vi, void *memcache)
+ const struct kvm_s2_fault_vma_info *s2vi,
+ enum kvm_pgtable_prot prot,
+ void *memcache)
{
enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
- bool writable = fault->prot & KVM_PGTABLE_PROT_W;
+ bool writable = prot & KVM_PGTABLE_PROT_W;
struct kvm *kvm = s2fd->vcpu->kvm;
struct kvm_pgtable *pgt;
long perm_fault_granule;
@@ -1970,12 +1969,12 @@ static int kvm_s2_fault_map(const struct kvm_s2_fault_desc *s2fd,
* Drop the SW bits in favour of those stored in the
* PTE, which will be preserved.
*/
- fault->prot &= ~KVM_NV_GUEST_MAP_SZ;
+ prot &= ~KVM_NV_GUEST_MAP_SZ;
ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms)(pgt, gfn_to_gpa(gfn),
- fault->prot, flags);
+ prot, flags);
} else {
ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, gfn_to_gpa(gfn), mapping_size,
- __pfn_to_phys(pfn), fault->prot,
+ __pfn_to_phys(pfn), prot,
memcache, flags);
}
@@ -2003,9 +2002,7 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
{
bool perm_fault = kvm_vcpu_trap_is_permission_fault(s2fd->vcpu);
struct kvm_s2_fault_vma_info s2vi = {};
- struct kvm_s2_fault fault = {
- .prot = KVM_PGTABLE_PROT_R,
- };
+ enum kvm_pgtable_prot prot;
void *memcache = NULL;
int ret;
@@ -2030,13 +2027,13 @@ static int user_mem_abort(const struct kvm_s2_fault_desc *s2fd)
if (ret != 1)
return ret;
- ret = kvm_s2_fault_compute_prot(s2fd, &fault, &s2vi);
+ ret = kvm_s2_fault_compute_prot(s2fd, &s2vi, &prot);
if (ret) {
kvm_release_page_unused(s2vi.page);
return ret;
}
- return kvm_s2_fault_map(s2fd, &fault, &s2vi, memcache);
+ return kvm_s2_fault_map(s2fd, &s2vi, prot, memcache);
}
/* Resolve the access fault by making the page young again. */
--
2.47.3
^ permalink raw reply related
* [PATCH v2 30/30] KVM: arm64: Convert gmem_abort() to struct kvm_s2_fault_desc
From: Marc Zyngier @ 2026-03-27 11:36 UTC (permalink / raw)
To: kvmarm, linux-arm-kernel, kvm
Cc: Joey Gouly, Suzuki K Poulose, Oliver Upton, Zenghui Yu,
Fuad Tabba, Will Deacon, Quentin Perret
In-Reply-To: <20260327113618.4051534-1-maz@kernel.org>
Having fully converted user_mem_abort() to kvm_s2_fault_desc and
co, convert gmem_abort() to it as well. The change is obviously
much simpler.
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
---
arch/arm64/kvm/mmu.c | 41 +++++++++++++++++++----------------------
1 file changed, 19 insertions(+), 22 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index f4c8f72642e02..1fe7182be45ac 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1575,33 +1575,31 @@ struct kvm_s2_fault_desc {
unsigned long hva;
};
-static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
- struct kvm_s2_trans *nested,
- struct kvm_memory_slot *memslot, bool is_perm)
+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 = vcpu->arch.hw_mmu->pgt;
+ struct kvm_pgtable *pgt = s2fd->vcpu->arch.hw_mmu->pgt;
unsigned long mmu_seq;
struct page *page;
- struct kvm *kvm = vcpu->kvm;
+ struct kvm *kvm = s2fd->vcpu->kvm;
void *memcache;
kvm_pfn_t pfn;
gfn_t gfn;
int ret;
- ret = prepare_mmu_memcache(vcpu, true, &memcache);
+ ret = prepare_mmu_memcache(s2fd->vcpu, true, &memcache);
if (ret)
return ret;
- if (nested)
- gfn = kvm_s2_trans_output(nested) >> PAGE_SHIFT;
+ if (s2fd->nested)
+ gfn = kvm_s2_trans_output(s2fd->nested) >> PAGE_SHIFT;
else
- gfn = fault_ipa >> PAGE_SHIFT;
+ gfn = s2fd->fault_ipa >> PAGE_SHIFT;
- write_fault = kvm_is_write_fault(vcpu);
- exec_fault = kvm_vcpu_trap_is_exec_fault(vcpu);
+ write_fault = kvm_is_write_fault(s2fd->vcpu);
+ exec_fault = kvm_vcpu_trap_is_exec_fault(s2fd->vcpu);
VM_WARN_ON_ONCE(write_fault && exec_fault);
@@ -1609,24 +1607,24 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
/* Pairs with the smp_wmb() in kvm_mmu_invalidate_end(). */
smp_rmb();
- ret = kvm_gmem_get_pfn(kvm, memslot, gfn, &pfn, &page, NULL);
+ ret = kvm_gmem_get_pfn(kvm, s2fd->memslot, gfn, &pfn, &page, NULL);
if (ret) {
- kvm_prepare_memory_fault_exit(vcpu, fault_ipa, PAGE_SIZE,
+ kvm_prepare_memory_fault_exit(s2fd->vcpu, s2fd->fault_ipa, PAGE_SIZE,
write_fault, exec_fault, false);
return ret;
}
- if (!(memslot->flags & KVM_MEM_READONLY))
+ if (!(s2fd->memslot->flags & KVM_MEM_READONLY))
prot |= KVM_PGTABLE_PROT_W;
- if (nested)
- prot = adjust_nested_fault_perms(nested, prot);
+ if (s2fd->nested)
+ prot = adjust_nested_fault_perms(s2fd->nested, prot);
if (exec_fault || cpus_have_final_cap(ARM64_HAS_CACHE_DIC))
prot |= KVM_PGTABLE_PROT_X;
- if (nested)
- prot = adjust_nested_exec_perms(kvm, nested, prot);
+ if (s2fd->nested)
+ prot = adjust_nested_exec_perms(kvm, s2fd->nested, prot);
kvm_fault_lock(kvm);
if (mmu_invalidate_retry(kvm, mmu_seq)) {
@@ -1634,7 +1632,7 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
goto out_unlock;
}
- ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, fault_ipa, PAGE_SIZE,
+ ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, s2fd->fault_ipa, PAGE_SIZE,
__pfn_to_phys(pfn), prot,
memcache, flags);
@@ -1643,7 +1641,7 @@ static int gmem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
kvm_fault_unlock(kvm);
if ((prot & KVM_PGTABLE_PROT_W) && !ret)
- mark_page_dirty_in_slot(kvm, memslot, gfn);
+ mark_page_dirty_in_slot(kvm, s2fd->memslot, gfn);
return ret != -EAGAIN ? ret : 0;
}
@@ -2300,8 +2298,7 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
};
if (kvm_slot_has_gmem(memslot))
- ret = gmem_abort(vcpu, fault_ipa, nested, memslot,
- esr_fsc_is_permission_fault(esr));
+ ret = gmem_abort(&s2fd);
else
ret = user_mem_abort(&s2fd);
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v2 1/3] pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
From: Chen-Yu Tsai @ 2026-03-27 11:38 UTC (permalink / raw)
To: Andre Przywara
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, linux-gpio, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <20260327113006.3135663-2-andre.przywara@arm.com>
On Fri, Mar 27, 2026 at 7:30 PM Andre Przywara <andre.przywara@arm.com> wrote:
>
> The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when
> that line is muxed for IRQ triggering (muxval 6), but only if it's
> explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this
> behaviour, so we added a optional workaround, triggered by a quirk bit,
> which triggers remuxing the pin when it's configured for IRQ, while we
> need to read its value.
>
> For some reasons this quirk flag was copied over to newer SoCs, even
> though they don't show this behaviour, and the GPIO data register
> reflects the true GPIO state even with a pin muxed to IRQ trigger.
>
> Remove the unneeded quirk from the A523 family, where it's definitely
> not needed (confirmed by experiments), and where it actually breaks,
> because the workaround is not compatible with the newer generation
> pinctrl IP used in that chip.
>
> Together with a DT change this fixes GPIO IRQ operation on the A523
> family of SoCs, as for instance used for the SD card detection.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports")
Acked-by: Chen-Yu Tsai <wens@kernel.org>
> ---
> drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c | 1 -
> drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c | 1 -
> 2 files changed, 2 deletions(-)
>
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> index 69cd2b4ebd7d..462aa1c4a5fa 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523-r.c
> @@ -26,7 +26,6 @@ static const u8 a523_r_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
> static struct sunxi_pinctrl_desc a523_r_pinctrl_data = {
> .irq_banks = ARRAY_SIZE(a523_r_irq_bank_map),
> .irq_bank_map = a523_r_irq_bank_map,
> - .irq_read_needs_mux = true,
> .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> .pin_base = PL_BASE,
> };
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> index 7d2308c37d29..b6f78f1f30ac 100644
> --- a/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun55i-a523.c
> @@ -26,7 +26,6 @@ static const u8 a523_irq_bank_muxes[SUNXI_PINCTRL_MAX_BANKS] =
> static struct sunxi_pinctrl_desc a523_pinctrl_data = {
> .irq_banks = ARRAY_SIZE(a523_irq_bank_map),
> .irq_bank_map = a523_irq_bank_map,
> - .irq_read_needs_mux = true,
> .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_SEL,
> };
>
> --
> 2.43.0
>
^ permalink raw reply
* Re: [RFC PATCH] dmaengine: xilinx_dma: Fix per-channel direction reporting via device_caps
From: Michal Simek @ 2026-03-27 11:43 UTC (permalink / raw)
To: Rahul Navale, dmaengine, Gupta, Suraj
Cc: Rahul Navale, dev, linux-arm-kernel, linux-kernel, vkoul,
Frank.Li, suraj.gupta2, thomas.gessler, radhey.shyam.pandey,
tomi.valkeinen, marex, marex
In-Reply-To: <20260325142300.3680-1-rahulnavale04@gmail.com>
+Suraj,
On 3/25/26 15:22, Rahul Navale wrote:
> From: Rahul Navale <rahul.navale@ifm.com>
>
> @Xilinx/AMD maintainers:
>
> Quick status: the ASoC playback regression is still present.
> when 7e01511443c3 ("dmaengine: xilinx_dma: Set dma_device directions")
> is present. Reverting 7e01511443c3 restores normal playback.
>
> Could you please advice the next steps / preferred fix direction to address
> this regression upstream?
Suraj will take a look at it soon.
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v5 00/15] hwspinlock: move device alloc into core and refactor includes
From: Wolfram Sang @ 2026-03-27 11:43 UTC (permalink / raw)
To: linux-renesas-soc
Cc: linux-kernel, Alexandre Torgue, Andy Shevchenko, Antonio Borneo,
Arnd Bergmann, Baolin Wang, Bjorn Andersson, Boqun Feng,
Chen-Yu Tsai, Chunyan Zhang, Danilo Krummrich, David Lechner,
driver-core, Greg Kroah-Hartman, Ingo Molnar, Jernej Skrabec,
Jonathan Cameron, Jonathan Corbet, Konrad Dybcio, Lee Jones,
Linus Walleij, linux-arm-kernel, linux-arm-msm, linux-doc,
linux-gpio, linux-iio, linux-omap, linux-remoteproc, linux-spi,
linux-stm32, linux-sunxi, Mark Brown, Maxime Coquelin,
Nuno Sá, Orson Zhai, Peter Zijlstra, Rafael J. Wysocki,
Samuel Holland, Shuah Khan, Srinivas Kandagatla, Thomas Gleixner,
Waiman Long, Wilken Gottwalt, Will Deacon
In-Reply-To: <20260319105947.6237-1-wsa+renesas@sang-engineering.com>
On Thu, Mar 19, 2026 at 11:59:22AM +0100, Wolfram Sang wrote:
> Changes since v4:
>
> * update Documentation, too, when ABI gets changed (Thanks Antonio!)
> * rebased to 7.0-rc4
> * added more tags (Thanks!)
>
> My ultimate goal is to allow hwspinlock provider drivers outside of the
> subsystem directory. It turned out that a simple split of the headers
> files into a public provider and a public consumer header file is not
> enough because core internal structures need to stay hidden. Even more,
> their opaqueness could and should even be increased. That would also
> allow the core to handle the de-/allocation of the hwspinlock device
> itself.
>
> This series does all that. Patches 1-2 remove the meanwhile unused
> platform_data to ease further refactoring. Patches 3-9 abstract access
> to internal structures away using helpers. Patch 10 then moves
> hwspinlock device handling to the core, simplifying drivers. The
> remaining patches refactor the headers until the internal one is gone
> and the public ones are divided into provider and consumer parts. More
> details are given in the patch descriptions.
>
> One note about using a callback to initialize hwspinlock priv: I also
> experimented with a dedicated 'set_priv' helper function. It felt a bit
> clumsy to me. Drivers would need to save the 'bank' pointer again and
> iterate over it. Because most drivers will only have a simple callback
> anyhow, it looked leaner to me.
>
> This series has been tested on a Renesas SparrowHawk board (R-Car V4H)
> with a yet-to-be-upstreamed hwspinlock driver for the MFIS IP core. A
> branch can be found here (without the MFIS driver currently):
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git renesas/hwspinlock/refactor-alloc-buildtest
>
> Build bots reported success.
Sashiko found some valid issues[1], so I am already working on a v6.
[1] https://sashiko.dev/#/patchset/20260319105947.6237-1-wsa%2Brenesas%40sang-engineering.com
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: pinctrl: sun55i-a523: increase IRQ banks number
From: Jernej Škrabec @ 2026-03-27 11:41 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Andre Przywara
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260327113006.3135663-3-andre.przywara@arm.com>
Dne petek, 27. marec 2026 ob 12:30:05 Srednjeevropski standardni čas je Andre Przywara napisal(a):
> The Allwinner A523 SoC implements 10 GPIO banks in the first pinctrl
> instance, but it skips the first bank (PortA), so their index goes from
> 1 to 10. The same is actually true for the IRQ banks: there are registers
> for 11 banks, though the first bank is not implemented (RAZ/WI).
> In contrast to previous SoCs, the count of the IRQ banks starts with this
> first unimplemented bank, so we need to provide an interrupt for it.
> And indeed the A523 user manual lists an interrupt number for PortA, so we
> need to increase the maximum number of interrupts per pin controller to 11,
> to be able to assign the correct interrupt number for each bank.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: allwinner: a523: Add missing GPIO interrupt
From: Jernej Škrabec @ 2026-03-27 11:42 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Andre Przywara
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260327113006.3135663-4-andre.przywara@arm.com>
Dne petek, 27. marec 2026 ob 12:30:06 Srednjeevropski standardni čas je Andre Przywara napisal(a):
> Even though the Allwinner A523 SoC implements 10 GPIO banks, it has
> actually registers for 11 IRQ banks, and even an interrupt assigned to
> the first, non-implemented IRQ bank.
> Add that first interrupt to the list of GPIO interrupts, to correct the
> association between IRQs and GPIO banks.
>
> This fixes GPIO IRQ operation on boards with A523 SoCs, as seen by
> broken SD card detect functionality, for instance.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Fixes: 35ac96f79664 ("arm64: dts: allwinner: Add Allwinner A523 .dtsi file")
> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* Re: [PATCH v2 1/3] pinctrl: sunxi: a523: Remove unneeded IRQ remuxing flag
From: Jernej Škrabec @ 2026-03-27 11:39 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Andre Przywara
Cc: linux-gpio, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
In-Reply-To: <20260327113006.3135663-2-andre.przywara@arm.com>
Dne petek, 27. marec 2026 ob 12:30:04 Srednjeevropski standardni čas je Andre Przywara napisal(a):
> The Allwinner A10 and H3 SoCs cannot read the state of a GPIO line when
> that line is muxed for IRQ triggering (muxval 6), but only if it's
> explicitly muxed for GPIO input (muxval 0). Other SoCs do not show this
> behaviour, so we added a optional workaround, triggered by a quirk bit,
> which triggers remuxing the pin when it's configured for IRQ, while we
> need to read its value.
>
> For some reasons this quirk flag was copied over to newer SoCs, even
> though they don't show this behaviour, and the GPIO data register
> reflects the true GPIO state even with a pin muxed to IRQ trigger.
>
> Remove the unneeded quirk from the A523 family, where it's definitely
> not needed (confirmed by experiments), and where it actually breaks,
> because the workaround is not compatible with the newer generation
> pinctrl IP used in that chip.
>
> Together with a DT change this fixes GPIO IRQ operation on the A523
> family of SoCs, as for instance used for the SD card detection.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Fixes: b8a51e95b376 ("pinctrl: sunxi: Add support for the secondary A523 GPIO ports")
Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
^ permalink raw reply
* [PATCH v3 1/1] arm64: defconfig: Enable CIX Sky1 pinctrl, PCIe host, and Cadence GPIO
From: Peter Chen @ 2026-03-27 11:46 UTC (permalink / raw)
To: arnd
Cc: krzysztof.kozlowski, geert+renesas, linux-kernel,
linux-arm-kernel, cix-kernel-upstream, Peter Chen, Yunseong Kim
Enable the CIX Sky1 pinctrl driver (PINCTRL_SKY1), CIX Sky1 PCIe host
controller (PCI_SKY1_HOST), and Cadence GPIO controller (GPIO_CADENCE)
for the Radxa Orion O6 board which uses the CIX Sky1 SoC.
The pinctrl driver is a dependency for other on-SoC peripherals. The
Cadence-based PCIe host controller enables use of PCIe peripherals on
the board. The Cadence GPIO controller provides GPIO support for the
SoC.
Cc: Yunseong Kim <ysk@kzalloc.com>
Signed-off-by: Peter Chen <peter.chen@cixtech.com>
---
Changes for v3:
- Use specific driver names (CIX Sky1 pinctrl, CIX Sky1 PCIe host
controller, Cadence GPIO) in subject and commit message instead of
generic terms.
- Remove external Debian bug reference; explain rationale directly.
- Remove NVMe mention since only PCIe host controller is enabled.
Changes for v2:
- Delete CIX HDA configurations due to it is not used at current
Orion O6 board device tree.
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b67d5b1fc45b..f9be52484008 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -241,6 +241,7 @@ CONFIG_PCIE_XILINX_DMA_PL=y
CONFIG_PCIE_XILINX_NWL=y
CONFIG_PCIE_XILINX_CPM=y
CONFIG_PCI_J721E_HOST=m
+CONFIG_PCI_SKY1_HOST=m
CONFIG_PCI_IMX6_HOST=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
@@ -676,6 +677,7 @@ CONFIG_PINCTRL_SDM660=y
CONFIG_PINCTRL_SDM670=y
CONFIG_PINCTRL_SDM845=y
CONFIG_PINCTRL_SDX75=y
+CONFIG_PINCTRL_SKY1=y
CONFIG_PINCTRL_SM4450=y
CONFIG_PINCTRL_SM6115=y
CONFIG_PINCTRL_SM6125=y
@@ -701,6 +703,7 @@ CONFIG_PINCTRL_SM8550_LPASS_LPI=m
CONFIG_PINCTRL_SM8650_LPASS_LPI=m
CONFIG_PINCTRL_SOPHGO_SG2000=y
CONFIG_GPIO_ALTERA=m
+CONFIG_GPIO_CADENCE=m
CONFIG_GPIO_DAVINCI=y
CONFIG_GPIO_DWAPB=y
CONFIG_GPIO_MB86S7X=y
--
2.50.1
^ permalink raw reply related
* [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Padmashree S S @ 2026-03-27 11:46 UTC (permalink / raw)
To: andrew, gregory.clement, sebastian.hesselbarth
Cc: robh, krzk+dt, conor+dt, linux-arm-kernel, devicetree,
linux-kernel, Padmashree S S
Convert armada-380-mpcore-soc-ctrl to DT schema
Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
---
.../marvell/armada-380-mpcore-soc-ctrl.txt | 14 --------
.../marvell/armada-380-mpcore-soc-ctrl.yaml | 32 +++++++++++++++++++
2 files changed, 32 insertions(+), 14 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
create mode 100644 Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
deleted file mode 100644
index 8781073029e9..000000000000
--- a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-Marvell Armada 38x CA9 MPcore SoC Controller
-============================================
-
-Required properties:
-
-- compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
-
-- reg: should be the register base and length as documented in the
- datasheet for the CA9 MPcore SoC Control registers
-
-mpcore-soc-ctrl@20d20 {
- compatible = "marvell,armada-380-mpcore-soc-ctrl";
- reg = <0x20d20 0x6c>;
-};
diff --git a/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
new file mode 100644
index 000000000000..a897d4ba4e32
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell/armada-380-mpcore-soc-ctrl.yaml
@@ -0,0 +1,32 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/marvell/armada-380-mpcore-soc-ctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Marvell Armada 38x CA9 MPcore SoC Controller
+
+maintainers:
+ - Andrew Lunn <andrew@lunn.ch>
+ - Gregory Clement <gregory.clement@bootlin.com>
+ - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
+
+properties:
+ compatible:
+ const: marvell,armada-380-mpcore-soc-ctrl
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ mpcore-soc-ctrl@20d20 {
+ compatible = "marvell,armada-380-mpcore-soc-ctrl";
+ reg = <0x20d20 0x6c>;
+ };
--
2.43.0
^ permalink raw reply related
* Re: [GIT,PULL,1/2] MediaTek ARM64 Device Tree updates for v7.1
From: Krzysztof Kozlowski @ 2026-03-27 11:48 UTC (permalink / raw)
To: AngeloGioacchino Del Regno
Cc: arm-soc, soc, linux-arm-kernel, linux-mediatek, matthias.bgg
In-Reply-To: <20260320085641.15843-1-angelogioacchino.delregno@collabora.com>
On Fri, Mar 20, 2026 at 09:56:38AM +0100, AngeloGioacchino Del Regno wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mediatek/linux.git tags/mtk-dts64-for-v7.1
>
> for you to fetch changes up to 820ed0c1a13c5fafb36232538d793f99a0986ef3:
>
> arm64: dts: mediatek: mt7986a: Fix gpio-ranges pin count (2026-03-12 13:32:17 +0100)
>
> ----------------------------------------------------------------
> MediaTek ARM64 DeviceTree updates
Thanks, applied both.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] i.MX fixes for 7.0 (v2)
From: Krzysztof Kozlowski @ 2026-03-27 11:51 UTC (permalink / raw)
To: Frank Li; +Cc: soc, arm, Fabio Estevam, kernel, imx, linux-arm-kernel
In-Reply-To: <20260323162849.1203617-1-Frank.Li@nxp.com>
On Mon, Mar 23, 2026 at 12:28:46PM -0400, Frank Li wrote:
> From: Frank Li <Frank.li@nxp.com>
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux.git tags/imx-fixes-7.0
>
> for you to fetch changes up to 511f76bf1dce5acf8907b65a7d1bc8f7e7c0d637:
>
> arm64: dts: imx8mq-librem5: Bump BUCK1 suspend voltage up to 0.85V (2026-03-17 23:24:44 -0400)
>
> ----------------------------------------------------------------
> i.MX fixes for 7.0:
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL 1/2] Broadcom devicetree changes for 7.1
From: Krzysztof Kozlowski @ 2026-03-27 11:53 UTC (permalink / raw)
To: Florian Fainelli
Cc: soc, Rosen Penev, Rob Herring, Linus Walleij, Linus Walleij,
William Zhang, Miquel Raynal, Rafał Miłecki,
linux-arm-kernel, arnd, khilman, bcm-kernel-feedback-list
In-Reply-To: <20260323190239.1890505-1-florian.fainelli@broadcom.com>
On Mon, Mar 23, 2026 at 12:02:38PM -0700, Florian Fainelli wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-7.1/devicetree
>
> for you to fetch changes up to 220bdfcb4b4788f57faa2c28454d8b2dd3bcab6c:
>
> ARM: dts: BCM5301X: EA9200: specify partitions (2026-03-20 16:57:31 -0700)
Four days after:
Days in linux-next:
----------------------------------------
0 | ++++++++++++++++ (16)
...
Commits with 0 days in linux-next (16 of 19: 84.2%)...
Are you sure your tree is included in the next?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL v2] Rockchip dts fixes for 7.0 #1
From: Krzysztof Kozlowski @ 2026-03-27 11:57 UTC (permalink / raw)
To: Heiko Stuebner; +Cc: arm, soc, linux-rockchip, linux-arm-kernel
In-Reply-To: <5057236.GXAFRqVoOG@phil>
On Mon, Mar 23, 2026 at 10:58:16PM +0100, Heiko Stuebner wrote:
> Hi SoC maintainers,
>
> As requested by Krzysztof, here is a more condensed PR.
>
> Changes in v2 are that I dropped fixes for dt-schema errors and fixes
> for commits introduced not closesly to the current release. These have
> been moved to the current branches.
>
> The Pinebook regression fix actually also is for a commit from august
> last year, but fixes an actively tracked regression, so maybe carries
> a bit more weight.
>
>
> Please pull
>
> Thanks
> Heiko
>
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.0-rockchip-dtsfixes1-v2
>
> for you to fetch changes up to 29d1f56c4f3001b7f547123e0a307c009ac717f8:
>
> Revert "arm64: dts: rockchip: Further describe the WiFi for the Pinebook Pro" (2026-02-22 23:28:06 +0100)
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] arm64: dts: juno/fvp: Updates for v7.1
From: Krzysztof Kozlowski @ 2026-03-27 12:00 UTC (permalink / raw)
To: Sudeep Holla
Cc: ARM SoC Team, SoC Team, ALKML, Arnd Bergmann, Lorenzo Pieralisi,
Liviu Dudau
In-Reply-To: <20260325160027.4115793-1-sudeep.holla@kernel.org>
On Wed, Mar 25, 2026 at 04:00:21PM +0000, Sudeep Holla wrote:
> Hi ARM SoC Team,
>
> Please pull !
>
> Regards,
> Sudeep
>
> -->8
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux.git tags/juno-updates-7.1
>
> for you to fetch changes up to 87599f1843d3baa4083dc9dd01c95826b536de24:
>
> arm64: dts: arm/corstone1000: Add corstone-1000-a320 (2026-03-23 10:03:28 +0000)
>
> ----------------------------------------------------------------
> Armv8 Juno/FVP/Vexpress updates for v7.1
>
> 1. The primary addition is initial support for Zena CSS that includes:
> a new binding compatibility, a shared `zena-css.dtsi` description, and
> an FVP device tree.
>
> 2. Extension of Corstone-1000 FVP platform support with binding updates
> to add the new `arm,corstone1000-a320-fvp` platform, and the
> `arm,corstone1000-ethos-u85` NPU integration.
>
> Overall, this combines new platform enablement with some DTS layout
> cleanup for Arm reference FVP based systems.
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
From: patchwork-bot+netdevbpf @ 2026-03-27 12:10 UTC (permalink / raw)
To: David CARLIER
Cc: danishanwar, rogerq, andrew+netdev, davem, edumazet, kuba, pabeni,
m-malladi, jacob.e.keller, horms, linux-arm-kernel, netdev,
linux-kernel
In-Reply-To: <20260325125131.53399-1-devnexen@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by David S. Miller <davem@davemloft.net>:
On Wed, 25 Mar 2026 12:51:30 +0000 you wrote:
> emac_dispatch_skb_zc() allocates a new skb via napi_alloc_skb() but
> never copies the packet data from the XDP buffer into it. The skb is
> passed up the stack containing uninitialized heap memory instead of
> the actual received packet, leaking kernel heap contents to userspace.
>
> Copy the received packet data from the XDP buffer into the skb using
> skb_copy_to_linear_data().
>
> [...]
Here is the summary with links:
- net: ti: icssg-prueth: fix missing data copy and wrong recycle in ZC RX dispatch
https://git.kernel.org/netdev/net/c/5597dd284ff8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Andrew Lunn @ 2026-03-27 12:23 UTC (permalink / raw)
To: Padmashree S S
Cc: gregory.clement, sebastian.hesselbarth, robh, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260327114653.593582-1-padmashreess2006@gmail.com>
On Fri, Mar 27, 2026 at 05:16:53PM +0530, Padmashree S S wrote:
> Convert armada-380-mpcore-soc-ctrl to DT schema
You have already been asked once to slow down. Please don't ignore
Reviewers/Maintainer comments.
Please don't post new versions of a patch within 24 hours. And 24
hours can be too fast, particularly at the weekend.
> Signed-off-by: Padmashree S S <padmashreess2006@gmail.com>
> ---
Here, under the --- you should indicate what changed since the last
version of the patch.
Andrew
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: arm: marvell: Convert armada-380-mpcore-soc-ctrl to DT Schema
From: Andrew Lunn @ 2026-03-27 12:24 UTC (permalink / raw)
To: Padmashree S S
Cc: gregory.clement, sebastian.hesselbarth, robh, krzk+dt, conor+dt,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260327114653.593582-1-padmashreess2006@gmail.com>
> +maintainers:
> + - Andrew Lunn <andrew@lunn.ch>
> + - Gregory Clement <gregory.clement@bootlin.com>
> + - Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>
Please drop Sebastian. He has not been active for many years.
Andrew
^ permalink raw reply
* Re: [PATCH v5 0/4] arm64: dts: rockchip: Fix vdec register blocks order on RK3576/RK3588
From: Cristian Ciocaltea @ 2026-03-27 12:51 UTC (permalink / raw)
To: Heiko Stuebner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Detlev Casanova, Ezequiel Garcia, Mauro Carvalho Chehab,
Nicolas Dufresne, Hans Verkuil
Cc: kernel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Conor Dooley, linux-media, Conor Dooley,
Krzysztof Kozlowski
In-Reply-To: <4358847.1IzOArtZ34@phil>
On 3/10/26 10:44 AM, Heiko Stuebner wrote:
> Am Mittwoch, 4. März 2026, 22:00:39 Mitteleuropäische Normalzeit schrieb Cristian Ciocaltea:
>> When building device trees for the RK3576 based boards, DTC shows the
>> following complaint:
>>
>> rk3576.dtsi:1282.30-1304.5: Warning (simple_bus_reg): /soc/video-codec@27b00000: simple-bus unit address format error, expected "27b00100"
>
> [...]
>
>> Cristian Ciocaltea (4):
>> media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88}
>> media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88}
>
> due to media "applied" messages most of the time not reaching all Cc'ed
> recipients, please tell me once the binding patches landed somewhere.
Yeah, sadly I also haven't received any notification so far, but just noticed
the binding patches are now in next-20260326, as a result of merging branch
'next' of https://git.linuxtv.org/media-ci/media-pending.git:
a11db8d8b403 ("media: dt-bindings: rockchip,vdec: Mark reg-names required for RK35{76,88}")
35c8178ed2bd ("media: dt-bindings: rockchip,vdec: Add alternative reg-names order for RK35{76,88}")
Thanks,
Cristian
^ permalink raw reply
* Re: [PATCH v1] arm64: mm: __ptep_set_access_flags must hint correct TTL
From: Catalin Marinas @ 2026-03-27 12:54 UTC (permalink / raw)
To: Will Deacon, Anshuman Khandual, Linu Cherian, Ryan Roberts
Cc: linux-arm-kernel, linux-kernel, Aishwarya TCV
In-Reply-To: <20260323163918.2028109-1-ryan.roberts@arm.com>
On Mon, 23 Mar 2026 16:39:16 +0000, Ryan Roberts wrote:
> It has been reported that since commit 752a0d1d483e9 ("arm64: mm:
> Provide level hint for flush_tlb_page()"), the arm64
> check_hugetlb_options selftest has been locking up while running "Check
> child hugetlb memory with private mapping, sync error mode and mmap
> memory".
>
> This is due to hugetlb (and THP) helpers casting their PMD/PUD entries
> to PTE and calling __ptep_set_access_flags(), which issues a
> __flush_tlb_page(). Now that this is hinted for level 3, in this case,
> the TLB entry does not get evicted and we end up in a spurious fault
> loop.
>
> [...]
Applied to arm64 (for-next/tlbflush), thanks!
[1/1] arm64: mm: __ptep_set_access_flags must hint correct TTL
https://git.kernel.org/arm64/c/b7d9d2e3a8ab
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-27 12:56 UTC (permalink / raw)
To: Maxime Ripard, Ville Syrjälä
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acVzwRyk_J24GrJ4@intel.com>
On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > > + * semantics.
> > > > > > > > > > + *
> > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > > + *
> > > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > > + * how HDMI does it).
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > + * not subsampled)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > +
> > > > > > > > > > + /**
> > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > + */
> > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > >
> > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > should be for each format.
> > > > > > > > >
> > > > > > > >
> > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > by other properties.
> > > > > > > >
> > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > knowledge, and hopefully none ever will.
> > > > > > >
> > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > >
> > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > RGB can either be full or limited range depending on the
> > > > > > > "Broadcast RGB" property and other related factors.
> > > > > >
> > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > field of its own?
> > > > >
> > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > I think the assumption is limited range everywhere.
> > > > >
> > > > > But I'm not really concerned about documenting struct members.
> > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > will want to know what the new property actually does so the
> > > > > uapi needs to be documented properly. And down the line some
> > > > > new driver might also implement the wrong behaviour if there
> > > > > is no clear specification.
> > > >
> > > > Ack
> > > >
> > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > - YCbCr limited range
> > > > > - RGB full range if "Broadcast RGB" property is not present
> > > >
> > > > Isn't it much more complicated than that for HDMI though? My
> > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > anything else full range?
> > >
> > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > those would always go hand in hand now.
> >
> > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > think?) but it looks like only vc4 registers the Broadcast RGB property
> > and uses the HDMI state helpers.
> >
> > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > drm_default_rgb_quant_range() which seems suspicious?
>
> If they want just manual full vs. limited then they should
> limit the property to not expose the "auto" option at all.
>
> amdgpu also ties this in with the "colorspace" property, which
> originally in i915 only controlled the infoframes/etc. But on
> amdgpu it now controls various aspects of output color
> transformation. The end result is that the property is a complete
> mess with most of the values making no sense. And for whatever
> reason everyone involved refused to remove/deprecate the
> nonsensical values :/
>
> Looks like this series should make sure the documentation for
> the "colorspace" property is in sync with the new property
> as well. Currently now it's giving conflicting information.
>
I take it the problematic information is in
* DOC: standard connector properties
*
* Colorspace:
and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
that they "produce RGB content".
I think we probably just have to change the statement "The variants
BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
RGB and YCbCr on its own."
The "on its own" here would get turned into "based on the color format
property".
Speaking of i915, that patch is one of the very few (5) patches in
this series still lacking a review (hint hint nudge nudge). I'd like
to get some more feedback on the remaining patches before I send out
another revision, so that it's hopefully not just docs changes (I
know better than to think those patches must be perfect and won't
need revision.)
If `drm/bridge: Act on the DRM color format property` and
`drm/atomic-helper: Add HDMI bridge output bus formats helper` get a
reviewed-by/acked-by and it's still crickets on the amdgpu and i915
front, then I will just drop the amdgpu/i915 implementations so that
they don't block this from landing.
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] selftests/arm64: Fix sve2p1_sigill() and add cmpbr_sigill() for hwcap test
From: Catalin Marinas @ 2026-03-27 12:58 UTC (permalink / raw)
To: will, shuah, broonie, yeoreum.yun, jonathan.cameron, linux-kernel,
linux-arm-kernel, linux-kselftest, linuxarm, Yifan Wu
Cc: xiaqinxin, prime.zeng, wangyushan12, xuwei5, fanghao11, wangzhou1
In-Reply-To: <20260305013638.992301-1-wuyifan50@huawei.com>
On Thu, 05 Mar 2026 09:36:36 +0800, Yifan Wu wrote:
> This patch series fixes and adds two selftests in the arm64 hwcap
> test suite.
>
> Patch 1/2 fixes the sve2p1_sigill() test to correctly detect the
> FEAT_SVE2p1 feature. Previously, the test incorrectly assumed that
> the presence of FEAT_SVE2.1 implied support for the BFADD
> instruction, which actually depends on the FEAT_SVE_B16B16 feature.
> The test is updated to use the LD1Q instruction, which is
> unambiguously implied by FEAT_SVE2p1.
>
> [...]
Applied to arm64 (for-kernelci), thanks!
[2/2] selftests/arm64: Implement cmpbr_sigill() to hwcap test
https://git.kernel.org/arm64/c/74cd4e0e5399
--
Catalin
^ permalink raw reply
* Re: (subset) [PATCH v2 0/2] selftests/arm64: Fix sve2p1_sigill() and add cmpbr_sigill() for hwcap test
From: Catalin Marinas @ 2026-03-27 13:00 UTC (permalink / raw)
To: will, shuah, broonie, yeoreum.yun, jonathan.cameron, linux-kernel,
linux-arm-kernel, linux-kselftest, linuxarm, Yifan Wu
Cc: xiaqinxin, prime.zeng, wangyushan12, xuwei5, fanghao11, wangzhou1
In-Reply-To: <177461612664.2271410.12022212735709481989.b4-ty@arm.com>
On Fri, Mar 27, 2026 at 12:58:11PM +0000, Catalin Marinas wrote:
> On Thu, 05 Mar 2026 09:36:36 +0800, Yifan Wu wrote:
> > This patch series fixes and adds two selftests in the arm64 hwcap
> > test suite.
> >
> > Patch 1/2 fixes the sve2p1_sigill() test to correctly detect the
> > FEAT_SVE2p1 feature. Previously, the test incorrectly assumed that
> > the presence of FEAT_SVE2.1 implied support for the BFADD
> > instruction, which actually depends on the FEAT_SVE_B16B16 feature.
> > The test is updated to use the LD1Q instruction, which is
> > unambiguously implied by FEAT_SVE2p1.
> >
> > [...]
>
> Applied to arm64 (for-kernelci), thanks!
Wrong branch, it's for-next/kselftest (script got confused).
^ permalink raw reply
* [PATCH v4 0/3] KVM: arm64: Fix SPE and TRBE nVHE world switch
From: Will Deacon @ 2026-03-27 13:00 UTC (permalink / raw)
To: kvmarm
Cc: mark.rutland, linux-arm-kernel, Will Deacon, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose, Fuad Tabba,
Alexandru Elisei, Yabin Cui
Hi all,
I got the Sashiko treatment on v3, so here's a quick respin to address
the BRBE thinko it found in the last patch.
Previous versions of the series are available at:
v1: https://lore.kernel.org/r/20260216130959.19317-1-will@kernel.org
v2: https://lore.kernel.org/r/20260227212136.7660-1-will@kernel.org
v3: https://lore.kernel.org/r/20260326141214.18990-1-will@kernel.org
Changes since v3 include:
* Retain zeroing of *brbcr_el1 when saving BRBE state
* Dropped R-b / T-b tags on the BRBE patch
Cheers,
Will
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: James Clark <james.clark@linaro.org>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
Cc: Yabin Cui <yabinc@google.com>
--->8
Will Deacon (3):
KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest
context
KVM: arm64: Disable SPE Profiling Buffer when running in guest context
KVM: arm64: Don't pass host_debug_state to BRBE world-switch routines
arch/arm64/include/asm/kvm_host.h | 2 +
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 116 +++++++++++++++++++++++------
arch/arm64/kvm/hyp/nvhe/switch.c | 2 +-
3 files changed, 95 insertions(+), 25 deletions(-)
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply
* [PATCH v4 1/3] KVM: arm64: Disable TRBE Trace Buffer Unit when running in guest context
From: Will Deacon @ 2026-03-27 13:00 UTC (permalink / raw)
To: kvmarm
Cc: mark.rutland, linux-arm-kernel, Will Deacon, Marc Zyngier,
Oliver Upton, James Clark, Leo Yan, Suzuki K Poulose, Fuad Tabba,
Alexandru Elisei, Yabin Cui
In-Reply-To: <20260327130047.21065-1-will@kernel.org>
The nVHE world-switch code relies on zeroing TRFCR_EL1 to disable trace
generation in guest context when self-hosted TRBE is in use by the host.
Per D3.2.1 ("Controls to prohibit trace at Exception levels"), clearing
TRFCR_EL1 means that trace generation is prohibited at EL1 and EL0 but
per R_YCHKJ the Trace Buffer Unit will still be enabled if
TRBLIMITR_EL1.E is set. R_SJFRQ goes on to state that, when enabled, the
Trace Buffer Unit can perform address translation for the "owning
exception level" even when it is out of context.
Consequently, we can end up in a state where TRBE performs speculative
page-table walks for a host VA/IPA in guest/hypervisor context depending
on the value of MDCR_EL2.E2TB, which changes over world-switch. The
potential result appears to be a heady mixture of SErrors, data
corruption and hardware lockups.
Extend the TRBE world-switch code to clear TRBLIMITR_EL1.E after
draining the buffer, restoring the register on return to the host. This
unfortunately means we need to tackle CPU errata #2064142 and #2038923
which add additional synchronisation requirements around manipulations
of the limit register. Hopefully this doesn't need to be fast.
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oupton@kernel.org>
Cc: James Clark <james.clark@linaro.org>
Cc: Leo Yan <leo.yan@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Fuad Tabba <tabba@google.com>
Cc: Alexandru Elisei <alexandru.elisei@arm.com>
Tested-by: Leo Yan <leo.yan@arm.com>
Tested-by: Fuad Tabba <tabba@google.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Fuad Tabba <tabba@google.com>
Fixes: a1319260bf62 ("arm64: KVM: Enable access to TRBE support for host")
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/asm/kvm_host.h | 1 +
arch/arm64/kvm/hyp/nvhe/debug-sr.c | 71 ++++++++++++++++++++++++++----
arch/arm64/kvm/hyp/nvhe/switch.c | 2 +-
3 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
index 70cb9cfd760a..b1335c55dbef 100644
--- a/arch/arm64/include/asm/kvm_host.h
+++ b/arch/arm64/include/asm/kvm_host.h
@@ -770,6 +770,7 @@ struct kvm_host_data {
u64 pmscr_el1;
/* Self-hosted trace */
u64 trfcr_el1;
+ u64 trblimitr_el1;
/* Values of trap registers for the host before guest entry. */
u64 mdcr_el2;
u64 brbcr_el1;
diff --git a/arch/arm64/kvm/hyp/nvhe/debug-sr.c b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
index 2a1c0f49792b..0955af771ad1 100644
--- a/arch/arm64/kvm/hyp/nvhe/debug-sr.c
+++ b/arch/arm64/kvm/hyp/nvhe/debug-sr.c
@@ -57,12 +57,54 @@ static void __trace_do_switch(u64 *saved_trfcr, u64 new_trfcr)
write_sysreg_el1(new_trfcr, SYS_TRFCR);
}
-static bool __trace_needs_drain(void)
+static void __trace_drain_and_disable(void)
{
- if (is_protected_kvm_enabled() && host_data_test_flag(HAS_TRBE))
- return read_sysreg_s(SYS_TRBLIMITR_EL1) & TRBLIMITR_EL1_E;
+ u64 *trblimitr_el1 = host_data_ptr(host_debug_state.trblimitr_el1);
+ bool needs_drain = is_protected_kvm_enabled() ?
+ host_data_test_flag(HAS_TRBE) :
+ host_data_test_flag(TRBE_ENABLED);
- return host_data_test_flag(TRBE_ENABLED);
+ if (!needs_drain) {
+ *trblimitr_el1 = 0;
+ return;
+ }
+
+ *trblimitr_el1 = read_sysreg_s(SYS_TRBLIMITR_EL1);
+ if (*trblimitr_el1 & TRBLIMITR_EL1_E) {
+ /*
+ * The host has enabled the Trace Buffer Unit so we have
+ * to beat the CPU with a stick until it stops accessing
+ * memory.
+ */
+
+ /* First, ensure that our prior write to TRFCR has stuck. */
+ isb();
+
+ /* Now synchronise with the trace and drain the buffer. */
+ tsb_csync();
+ dsb(nsh);
+
+ /*
+ * With no more trace being generated, we can disable the
+ * Trace Buffer Unit.
+ */
+ write_sysreg_s(0, SYS_TRBLIMITR_EL1);
+ if (cpus_have_final_cap(ARM64_WORKAROUND_2064142)) {
+ /*
+ * Some CPUs are so good, we have to drain 'em
+ * twice.
+ */
+ tsb_csync();
+ dsb(nsh);
+ }
+
+ /*
+ * Ensure that the Trace Buffer Unit is disabled before
+ * we start mucking with the stage-2 and trap
+ * configuration.
+ */
+ isb();
+ }
}
static bool __trace_needs_switch(void)
@@ -79,15 +121,26 @@ static void __trace_switch_to_guest(void)
__trace_do_switch(host_data_ptr(host_debug_state.trfcr_el1),
*host_data_ptr(trfcr_while_in_guest));
-
- if (__trace_needs_drain()) {
- isb();
- tsb_csync();
- }
+ __trace_drain_and_disable();
}
static void __trace_switch_to_host(void)
{
+ u64 trblimitr_el1 = *host_data_ptr(host_debug_state.trblimitr_el1);
+
+ if (trblimitr_el1 & TRBLIMITR_EL1_E) {
+ /* Re-enable the Trace Buffer Unit for the host. */
+ write_sysreg_s(trblimitr_el1, SYS_TRBLIMITR_EL1);
+ isb();
+ if (cpus_have_final_cap(ARM64_WORKAROUND_2038923)) {
+ /*
+ * Make sure the unit is re-enabled before we
+ * poke TRFCR.
+ */
+ isb();
+ }
+ }
+
__trace_do_switch(host_data_ptr(trfcr_while_in_guest),
*host_data_ptr(host_debug_state.trfcr_el1));
}
diff --git a/arch/arm64/kvm/hyp/nvhe/switch.c b/arch/arm64/kvm/hyp/nvhe/switch.c
index 779089e42681..f00688e69d88 100644
--- a/arch/arm64/kvm/hyp/nvhe/switch.c
+++ b/arch/arm64/kvm/hyp/nvhe/switch.c
@@ -278,7 +278,7 @@ int __kvm_vcpu_run(struct kvm_vcpu *vcpu)
* We're about to restore some new MMU state. Make sure
* ongoing page-table walks that have started before we
* trapped to EL2 have completed. This also synchronises the
- * above disabling of BRBE, SPE and TRBE.
+ * above disabling of BRBE and SPE.
*
* See DDI0487I.a D8.1.5 "Out-of-context translation regimes",
* rule R_LFHQG and subsequent information statements.
--
2.53.0.1018.g2bb0e51243-goog
^ permalink raw reply related
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