* [PATCH] fix: drm/mediatek: mtk_drm_probe: of_node_get in loop overwrites previous node references without release
From: WenTao Liang @ 2026-06-26 13:28 UTC (permalink / raw)
To: chunkuang.hu, p.zabel, airlied, simona, matthias.bgg,
angelogioacchino.delregno
Cc: dri-devel, linux-mediatek, linux-kernel, linux-arm-kernel,
WenTao Liang, stable
In the for_each_child_of_node loop, private->comp_node[comp_id] and
private->mutex_node are assigned via of_node_get without first releasing
any previously stored reference for the same index. When the same comp_id
or mmsys_id matches multiple nodes, earlier node references are
overwritten and permanently leaked.
Cc: stable@vger.kernel.org
Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index c86a3f54f35b..2c0d8db9ade2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -1138,6 +1138,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
id = of_alias_get_id(node, "mutex");
if (id < 0 || id == private->data->mmsys_id) {
+ of_node_put(private->mutex_node);
private->mutex_node = of_node_get(node);
dev_dbg(dev, "get mutex for mmsys %d", private->data->mmsys_id);
}
@@ -1153,7 +1154,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
if (!mtk_drm_find_mmsys_comp(private, comp_id))
continue;
-
+ of_node_put(private->comp_node[comp_id]);
private->comp_node[comp_id] = of_node_get(node);
/*
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* [GIT PULL] KVM/arm64 fixes for 7.2, take #1
From: Marc Zyngier @ 2026-06-26 13:35 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Bradley Morgan, Fuad Tabba, Hyunwoo Kim, Oliver Upton,
Weiming Shi, Will Deacon, Xuanqing Shi, Zhong Wang, Steffen Eiden,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, kvmarm, kvm,
linux-arm-kernel
Paolo,
As predicted, here's another largeish set of fixes for KVM/arm64. A
bunch of them are fairly benign (the PSTATE.IL stuff), but some are
pretty annoying (vgic, MOPS) and are stable material.
On the bright side, Fuad has volunteered to be an official reviewer.
We really need people to engage with the reviewing process instead of
simply dumping patches on us, as me and Oliver really can't be
stretched much further. So many thanks Fuad for offering to help.
I expect to be back next week with a similar delivery, as my Inbox
keeps filling with this stuff...
Please pull,
M.
The following changes since commit 1ee27dacbe5dc4def481794d899d67b0d4570094:
Merge branch kvm-arm64/nv-mmu-7.2 into kvmarm-master/next (2026-06-12 09:29:34 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.2-1
for you to fetch changes up to d098bb75d14fde2f12155f1a95ec0168160867ce:
KVM: arm64: account pKVM reclaim against the VM mm (2026-06-22 10:48:08 +0100)
----------------------------------------------------------------
KVM/arm64 fixes for 7.2, take #1
- Fix an accounting buglet when reclaiming pages from a protected
guest
- Fix a bunch of architectural compliance issues when injecting a
synthesised exception, most of which were missing the PSTATE.IL bit
indicating a 32bit-wide instruction
- Another set of fixes addressing issues with translation of VNCR_EL2,
including corner cases where the guest point that register at a RO
page...
- Don't warn when trapping accesses to ZCR_EL2 from an L2 guest, as
that's not unexpected at all
- Address a bunch of races with LPI migration vs LPIs being disabled
- Fix a total howler of a bug combining FEAT_MOPS and NV, resulting in
exception returning in the wrong place...
- Coerce Fuad Tabba into a reviewer role, and may his Inbox catch
fire!
----------------------------------------------------------------
Bradley Morgan (1):
KVM: arm64: account pKVM reclaim against the VM mm
Fuad Tabba (11):
KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions
KVM: arm64: Sync SPSR_EL1 when injecting an exception into a pVM
KVM: arm64: nv: Fix PSTATE construction on illegal exception return
KVM: arm64: Add Fuad Tabba as a reviewer
KVM: arm64: Set ESR_ELx.IL for injected undefined exceptions at EL2
KVM: arm64: Unconditionally set IL for injected undefined exceptions
KVM: arm64: Unconditionally set IL for injected abort exceptions
KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
KVM: arm64: Set IL for emulated SError injection
KVM: arm64: Set IL for nested SError injection
KVM: arm64: Set IL in fake ESR for pKVM memory sharing exit
Hyunwoo Kim (1):
KVM: arm64: vgic: Check the interrupt is still ours before migrating it
Marc Zyngier (1):
KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
Oliver Upton (6):
KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2
KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR
KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN
KVM: arm64: nv: Re-translate VNCR before injecting abort
KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory
KVM: arm64: nv: Mark VM as bugged for unexpected VNCR abort
Weiming Shi (1):
KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()
MAINTAINERS | 1 +
arch/arm64/include/asm/kvm_nested.h | 8 ++
arch/arm64/kvm/at.c | 8 --
arch/arm64/kvm/emulate-nested.c | 37 +++++--
arch/arm64/kvm/hyp/include/hyp/switch.h | 11 ++-
arch/arm64/kvm/hyp/nvhe/pkvm.c | 3 +-
arch/arm64/kvm/hyp/nvhe/sys_regs.c | 3 +-
arch/arm64/kvm/inject_fault.c | 18 +---
arch/arm64/kvm/nested.c | 164 ++++++++++++++++----------------
arch/arm64/kvm/pkvm.c | 2 +-
arch/arm64/kvm/vgic/vgic.c | 20 ++--
11 files changed, 149 insertions(+), 126 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] irqchip/gic-v3-its: Fix OF node reference leak
From: Marc Zyngier @ 2026-06-26 13:41 UTC (permalink / raw)
To: Yuho Choi; +Cc: Thomas Gleixner, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626033747.1515585-1-dbgh9129@gmail.com>
On Fri, 26 Jun 2026 04:37:47 +0100,
Yuho Choi <dbgh9129@gmail.com> wrote:
>
> of_get_cpu_node() returns a referenced device node. In
> its_cpu_init_collection(), the Cavium 23144 workaround only uses the
> node to compare the CPU NUMA node, but the reference is never dropped.
>
> Use the device_node cleanup helper for the CPU node reference so it is
> released when leaving the workaround block, including the NUMA mismatch
> return path.
>
> Fixes: fbf8f40e1658 ("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144")
> Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
> ---
> - Use __free(device_node) for the CPU node reference.
> - Correct the Fixes tag to fbf8f40e1658.
>
> drivers/irqchip/irq-gic-v3-its.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index b57d81ad33a0..63942cf1dbe3 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3290,9 +3290,9 @@ static void its_cpu_init_collection(struct its_node *its)
>
> /* avoid cross node collections and its mapping */
> if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
> - struct device_node *cpu_node;
> + struct device_node *cpu_node __free(device_node) =
> + of_get_cpu_node(cpu, NULL);
Please keep this on a single line. I find nothing more irritating than
these split assignments.
>
> - cpu_node = of_get_cpu_node(cpu, NULL);
> if (its->numa_node != NUMA_NO_NODE &&
> its->numa_node != of_node_to_nid(cpu_node))
> return;
Worth taking this opportunity to fix the indentation here.
With these two nits addressed:
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [PATCH 6.12] KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
From: Alexander Martyniuk @ 2026-06-26 13:42 UTC (permalink / raw)
To: stable, Greg Kroah-Hartman
Cc: Alexander Martyniuk, Marc Zyngier, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
linux-arm-kernel, kvmarm, linux-kernel, Oliver Upton, Hyunwoo Kim
From: Hyunwoo Kim <imv4bel@gmail.com>
commit f2ca45b50d4216c9cc7ffabf50d9ad1932209251 upstream.
walk_s1() and kvm_walk_nested_s2() expect to be called while holding
kvm->srcu to guard against memslot changes. While this is generally
the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the
respective walkers without taking kvm->srcu.
Fix by acquiring kvm->srcu prior to the table walk in both instances.
Cc: stable@vger.kernel.org
Fixes: 50f77dc87f13 ("KVM: arm64: Populate level on S1PTW SEA injection")
Fixes: be04cebf3e78 ("KVM: arm64: nv: Add emulation of AT S12E{0,1}{R,W}")
Suggested-by: Oliver Upton <oupton@kernel.org>
Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
Reviewed-by: Oliver Upton <oupton@kernel.org>
Link: https://patch.msgid.link/aiAZfdeyanIvP8SD@v4bel
Signed-off-by: Marc Zyngier <maz@kernel.org>
[Alexander: __kvm_find_s1_desc_level() not present, patching only __kvm_at_s12()]
Signed-off-by: Alexander Martyniuk <alexevgmart@gmail.com>
---
arch/arm64/kvm/at.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kvm/at.c b/arch/arm64/kvm/at.c
index 39f0e87a340e..8192bc0bbc87 100644
--- a/arch/arm64/kvm/at.c
+++ b/arch/arm64/kvm/at.c
@@ -1087,7 +1087,8 @@ void __kvm_at_s12(struct kvm_vcpu *vcpu, u32 op, u64 vaddr)
/* Do the stage-2 translation */
ipa = (par & GENMASK_ULL(47, 12)) | (vaddr & GENMASK_ULL(11, 0));
out.esr = 0;
- ret = kvm_walk_nested_s2(vcpu, ipa, &out);
+ scoped_guard(srcu, &vcpu->kvm->srcu)
+ ret = kvm_walk_nested_s2(vcpu, ipa, &out);
if (ret < 0)
return;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] docs: arm64: Document that text_offset is always 0
From: Rasmus Villemoes @ 2026-06-26 13:52 UTC (permalink / raw)
To: Mark Rutland
Cc: linux-arm-kernel, Ard Biesheuvel, Will Deacon, Jonathan Corbet,
linux-doc, linux-kernel
In-Reply-To: <ajVekauNroapwbtm@J2N7QTR9R3.cambridge.arm.com>
On Fri, Jun 19 2026, "Mark Rutland" <mark.rutland@arm.com> wrote:
> On Thu, Jun 04, 2026 at 04:08:39PM +0200, Rasmus Villemoes wrote:
>> When trying to figure out where to place and call an arm64 Image in
>> memory, reading booting.rst should provide the answer. However, it
>> requires quite some digging to figure out that text_offset is set via
>> ".quad 0" in head.S and is thus actually always 0 since v5.10.
>
> What is the actual problem?
>
> The documentation in booting.rst is accurate; I don't see why it's
> necessary to read the source code to look at text_offset. Immediately
> above the text in your diff, the documentation has:
>
> | 4. Call the kernel image
> | ------------------------
> |
> | Requirement: MANDATORY
> |
> | The decompressed kernel image contains a 64-byte header as follows::
> |
> | u32 code0; /* Executable code */
> | u32 code1; /* Executable code */
> | u64 text_offset; /* Image load offset, little endian */
> | u64 image_size; /* Effective Image size, little endian */
> | u64 flags; /* kernel flags, little endian */
> | u64 res2 = 0; /* reserved */
> | u64 res3 = 0; /* reserved */
> | u64 res4 = 0; /* reserved */
> | u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
> | u32 res5; /* reserved (used for PE COFF offset) */
>
> Can you explain the problem you're facing? e.g.
>
> * Is the documentation unclear, in a way that could be better?
>
> * Is there some aspect of the boot protocol that is hard for a
> bootloader to follow?
>
> * Is there some problem with *testing* that bootloaders respect the
> text_offset requirements?
>
> * Something else?
Yes, the structure of the header is documented. But nowhere is it
explained how the text_offset field gets its value.
So imagine I've just built an arm64 kernel. Now I want to put that into
a FIT image, where I tell the bootloader where to place it and what
address to jump to, via the load= and entry= properties. Now, the
documentation
The Image must be placed text_offset bytes from a 2MB aligned base
address anywhere in usable system RAM and called there.
is clear enough that those two have to be the same value. What is not at
all clear is how I'm suppose to determine what that text_offset value is
that I'm suppose to add to some 2MB aligned address I choose.
Prior to 120dc60d0, one could at least 'git grep TEXT_OFFSET --
arch/arm64/' and see 'TEXT_OFFSET := 0x0'.
>> I've included a Fixes tag since I spent way too much time tracking
>> down where that text_offset might be defined. The mentioned commit did
>> get rid of all references to TEXT_OFFSET-the-macro, but not
>> text_offset-the-concept.
>
> Keeping text_offset as a concept was deliberate. That allows us to keep
> the documentation accruate for older kernel versions, and allows for the
> possiblity that a non-zero offset is introduced in future (though I
> admit that might be a tough sell).
Fair enough. But would you at least consider adding just this part:
>> +- As of v5.10, text_offset is always 0.
>> +
One can, using the documented header, read it post-factum from the
kernel binary itself, and perhaps that's what's intended. But to answer
your first question, yes, I did find the documenation unclear and
expected to find some explicit mention of how one is supposed to know
the value of text_offset.
Rasmus
^ permalink raw reply
* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Luca Ceresoli @ 2026-06-26 14:16 UTC (permalink / raw)
To: Maxime Ripard, Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <20260626-polite-hairy-perch-25e1aa@houat>
Hi Maxime,
On Fri Jun 26, 2026 at 12:09 PM CEST, Maxime Ripard wrote:
> On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote:
>> On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
>> > Hi,x
>> >
>> > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote:
>> >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote:
>> >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
>> >> >> In preparation to introduce bridge hotplug, split out from
>> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
>> >> >> dedicated function. This will be needed to be able to add (and re-add) the
>> >> >> connector from different code paths.
>> >> >
>> >> > Same story here, explaining what you need later on that calls for that
>> >> > change would be nice.
>> >>
>> >> Here's a more verbose version:
>> >>
>> >> Currently drm_bridge_connector_init() does two things:
>> >>
>> >> * allocate and initialize the drm_bridge_connector
>> >> (which embeds a drm_connector)
>> >> * initialize and register the embedded drm_connector
>> >>
>> >> For bridge hotplug we need to separate these two actions:
>> >>
>> >> * the drm_connector needs to be added and removed at any time based on
>> >> hotplug events
>> >> * the drm_bridge_connector is designated to create and remove the
>> >> drm_connector, so it must be persistent for the card lifetime
>> >>
>> >> As the lifetimes of drm_bridge_connector and drm_connector become
>> >> different, we need to create them in different moments.
>> >>
>> >> In preparation to support that, split out from
>> >> drm_bridge_connector_init() the code adding the drm_connector into a
>> >> dedicated function. No functional changes, just moving code around for
>> >> now. A future commit will make the drm_connector be created based on
>> >> hotplug events.
>> >>
>> >> Looks good?
>> >
>> > The message itself, yes, thanks.
>> >
>> > However, I have questions now :)
>> >
>> > Do we really expect drm_bridge_connector to stick around when a bridge
>> > gets unplugged? If so, how does it cope with having, say, an HDMI
>> > connector, and then swapping out the hotplugged part for an LVDS one?
>> > Does the HDMI connector sticks around indefinitely?
>>
>> In your example, the HDMI drm_connector would be unregistered and put on
>> hotunplug. Its allocation will stick around until the last put but that's
>> quite irrelevant. Then, on plugging the LVDS addon, a new LVDS
>> drm_connector will be created and registered.
>>
>> > *Especially* if we're using overlays for this, I'd expect everything
>> > after the first hotplugged bridge to be destroyed, no?
>>
>> As said, it would be unregistered immediately but might be freed later on
>> if still refcounted.
>>
>> This is visible in patches 36+15, the path to follow is:
>>
>> drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36]
>> -> drm_bridge_connector_dynconn_release() [patch 15]
>>
>> Does this solve your concern?
>
> Not really, I'm talking about drm_bridge_connector. The fact that
> bridges are destroyed make sense to me. The fact that
> drm_bridge_connector sticks around doesn't. It's supposed to be a
> connector for bridges. If you don't have bridges because they got
> destroyed, and connector, drm_bridge_connector doesn't have a reason to
> exist anymore, unless it's drm_bridge_hotplug in a trench coat :)
It is not a hotplug-bridge in a trench coat, no :) The code is clear about
this.
I'd say with this series a "drm_bridge_connector" is just becoming
something more (perhaps something else too). Somewhat as "a drm_bridge is
either a bridge or something else". :)
But let's leave names aside for a moment. If just looking at the current
code, the drm_bridge_connector is "a handler, owned by the card/encoder and
having the same lifetime, which takes care of drm_connector
creation/destruction at card probe/removal".
What we need now is just the same plug " and on hotplug events" appended.
So in both cases there needs to be "a handler persitent with the card".
Do we agree so far?
Now, the reason I chose to extend the drm_bridge_connector to achieve the
above is what I tried to motivate in the cover letter:
> The drm_bridge_connector is nowadays the recommended way to implement DRM
> connectors when a chain of bridges is used. It takes care of adding the
> drm_connector when the pipeline is composed by an arbitrarily long chain of
> bridges, which it scans to properly implement the drm_connector
> operations.
>
> As such the drm_bridge_connector looked like the ideal component to
> implement DRM bridge hotplug.
>
> This series augments the drm_bridge_connector code to be able to create and
> destroy the drm_connector reacting on hot(un)plug events.
Before taking that approach I considered some options:
1. Create a new component, which is a "a handler, owned by the
card/encoder and having the same lifetime, which takes care of
drm_connector creation/destruction at card probe/removal and on hotplug
events", and wait for drivers to migrate from the drm_bridge_connector
to this new thing
2. Create a new component, which is a "handler, owned by the card/encoder
and having the same lifetime, which reacts to hotplug events by
creating/destroying a drm_bridge_connector (slightly modified to be
non-drmm), which in turn takes care of drm_connector
creation/destruction", and wait for drivers to migrate to this new
thing
3. Extend the dm_bridge_connector to:
- behave as before if using the current API
- behave as before + hotplug if using a new API
(the migration in most cases is as simple as patch 37)
All 3 options require changes in card drivers to use a new API (and a new
object type for cases 1 and 2).
To me options 1 and 2 involve more redundant code and/or more complexity.
Your thoughts?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH v2 0/2] Use __u128 in arm64 UAPI headers
From: Will Deacon @ 2026-06-26 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Will Deacon, Arnd Bergmann,
Arnaldo Carvalho de Melo, Nick Desaulniers, David Matlack,
Steffen Eiden, Andreas Grapentin, Catalin Marinas, Dave Martin,
Mark Rutland, Marc Zyngier
Hi folks,
This is version two of the patch I previously sent here:
https://lore.kernel.org/r/20260619130835.5678-1-will@kernel.org
I even briefly queued that version up, but it exploded spectacularly
when building the kselftests for arm64 [1] [2]. So the only change since
v1 is the addition of a preliminary patch that adds the '__u128' typedef
to the private copy of linux/types.h used by the tools/ directory.
I plan to take this all via the arm64 tree unless anybody objects.
Cheers,
Will
[1] https://lore.kernel.org/r/202606240441.7eZ1TIRM-lkp@intel.com
[2] https://lore.kernel.org/r/ajvGS7UBpWzJtzkw@sirena.org.uk
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Cc: David Matlack <dmatlack@google.com>
Cc: Steffen Eiden <seiden@linux.ibm.com>
Cc: Andreas Grapentin <gra@linux.ibm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Martin <dave.martin@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
--->8
Will Deacon (2):
tools: linux/types.h: Add 128-bit integer types for arm64 UAPI
structures
arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers
arch/arm64/include/uapi/asm/ptrace.h | 12 ++++++------
arch/arm64/include/uapi/asm/sigcontext.h | 6 +++---
tools/include/linux/types.h | 5 +++++
3 files changed, 14 insertions(+), 9 deletions(-)
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply
* [PATCH v2 1/2] tools: linux/types.h: Add 128-bit integer types for arm64 UAPI structures
From: Will Deacon @ 2026-06-26 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Will Deacon, Arnd Bergmann,
Arnaldo Carvalho de Melo, David Matlack
In-Reply-To: <20260626141730.5976-1-will@kernel.org>
The arm64 UAPI exposes some 128-bit integer types to represent things
such as fpsimd registers in the sigcontext. In preparation for defining
these using the '__u128' typedef implemented by uapi/linux/types.h, copy
that typedef over to the private linux/types.h header used by the tools
directory.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Matlack <dmatlack@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
---
tools/include/linux/types.h | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/include/linux/types.h b/tools/include/linux/types.h
index d41f8a261bce..b6c473b7920d 100644
--- a/tools/include/linux/types.h
+++ b/tools/include/linux/types.h
@@ -23,6 +23,11 @@ typedef enum {
__GFP_HIGH
} gfp_t;
+#ifdef __SIZEOF_INT128__
+typedef __signed__ __int128 __s128 __attribute__((aligned(16)));
+typedef unsigned __int128 __u128 __attribute__((aligned(16)));
+#endif
+
/*
* We define u64 as uint64_t for every architecture
* so that we can print it with "%"PRIx64 without getting warnings.
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* [PATCH v2 2/2] arm64: uapi: Use __u128 instead of __uint128_t in UAPI headers
From: Will Deacon @ 2026-06-26 14:17 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Will Deacon, Arnd Bergmann, Nick Desaulniers,
Steffen Eiden, Andreas Grapentin, Catalin Marinas, Dave Martin,
Mark Rutland, Marc Zyngier
In-Reply-To: <20260626141730.5976-1-will@kernel.org>
The arm64 UAPI exposes '__uint128_t' types in the members of
'struct user_fpsimd_state', 'struct user_pac_address_keys' and in the
signal frame via 'struct fpsimd_context'. Since the alignment of such
a type appears to be non-portable (16 bytes on arm64, 8 bytes on s390),
prefer the '__u128' typedef from uapi/linux/types.h, which makes the
alignment explicit and allows the definitions to be reused by other
host architectures.
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Nick Desaulniers <nick.desaulniers+lkml@gmail.com>
Cc: Steffen Eiden <seiden@linux.ibm.com>
Cc: Andreas Grapentin <gra@linux.ibm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Dave Martin <dave.martin@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will@kernel.org>
---
arch/arm64/include/uapi/asm/ptrace.h | 12 ++++++------
arch/arm64/include/uapi/asm/sigcontext.h | 6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm64/include/uapi/asm/ptrace.h b/arch/arm64/include/uapi/asm/ptrace.h
index 6fed93fb2536..15649a253a57 100644
--- a/arch/arm64/include/uapi/asm/ptrace.h
+++ b/arch/arm64/include/uapi/asm/ptrace.h
@@ -93,7 +93,7 @@ struct user_pt_regs {
};
struct user_fpsimd_state {
- __uint128_t vregs[32];
+ __u128 vregs[32];
__u32 fpsr;
__u32 fpcr;
__u32 __reserved[2];
@@ -258,14 +258,14 @@ struct user_pac_mask {
/* pointer authentication keys (NT_ARM_PACA_KEYS, NT_ARM_PACG_KEYS) */
struct user_pac_address_keys {
- __uint128_t apiakey;
- __uint128_t apibkey;
- __uint128_t apdakey;
- __uint128_t apdbkey;
+ __u128 apiakey;
+ __u128 apibkey;
+ __u128 apdakey;
+ __u128 apdbkey;
};
struct user_pac_generic_keys {
- __uint128_t apgakey;
+ __u128 apgakey;
};
/* ZA state (NT_ARM_ZA) */
diff --git a/arch/arm64/include/uapi/asm/sigcontext.h b/arch/arm64/include/uapi/asm/sigcontext.h
index e29bf3e2d0cc..d250ca7a1d46 100644
--- a/arch/arm64/include/uapi/asm/sigcontext.h
+++ b/arch/arm64/include/uapi/asm/sigcontext.h
@@ -78,7 +78,7 @@ struct fpsimd_context {
struct _aarch64_ctx head;
__u32 fpsr;
__u32 fpcr;
- __uint128_t vregs[32];
+ __u128 vregs[32];
};
/*
@@ -266,8 +266,8 @@ struct gcs_context {
* - ---- -----------
* REGS the entire SVE context
*
- * ZREGS __uint128_t[SVE_NUM_ZREGS][vq] all Z-registers
- * ZREG __uint128_t[vq] individual Z-register Zn
+ * ZREGS __u128[SVE_NUM_ZREGS][vq] all Z-registers
+ * ZREG __u128[vq] individual Z-register Zn
*
* PREGS uint16_t[SVE_NUM_PREGS][vq] all P-registers
* PREG uint16_t[vq] individual P-register Pn
--
2.55.0.rc0.799.gd6f94ed593-goog
^ permalink raw reply related
* Re: [PATCH 6.12] KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation
From: Marc Zyngier @ 2026-06-26 14:20 UTC (permalink / raw)
To: Alexander Martyniuk
Cc: stable, Greg Kroah-Hartman, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas, Will Deacon,
linux-arm-kernel, kvmarm, linux-kernel, Oliver Upton, Hyunwoo Kim
In-Reply-To: <20260626134210.228892-1-alexevgmart@gmail.com>
On Fri, 26 Jun 2026 14:42:07 +0100,
Alexander Martyniuk <alexevgmart@gmail.com> wrote:
>
> From: Hyunwoo Kim <imv4bel@gmail.com>
>
> commit f2ca45b50d4216c9cc7ffabf50d9ad1932209251 upstream.
>
> walk_s1() and kvm_walk_nested_s2() expect to be called while holding
> kvm->srcu to guard against memslot changes. While this is generally
> the case, __kvm_at_s12() and __kvm_find_s1_desc_level() call into the
> respective walkers without taking kvm->srcu.
>
> Fix by acquiring kvm->srcu prior to the table walk in both instances.
>
> Cc: stable@vger.kernel.org
> Fixes: 50f77dc87f13 ("KVM: arm64: Populate level on S1PTW SEA injection")
> Fixes: be04cebf3e78 ("KVM: arm64: nv: Add emulation of AT S12E{0,1}{R,W}")
> Suggested-by: Oliver Upton <oupton@kernel.org>
> Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com>
> Reviewed-by: Oliver Upton <oupton@kernel.org>
> Link: https://patch.msgid.link/aiAZfdeyanIvP8SD@v4bel
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> [Alexander: __kvm_find_s1_desc_level() not present, patching only __kvm_at_s12()]
> Signed-off-by: Alexander Martyniuk <alexevgmart@gmail.com>
See thread at [1], which explains why this is not needed.
M.
[1] https://lore.kernel.org/all/aifnUC7gmeniiYPv@v4bel/
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH] fix: clk/samsung: exynos_clkout_probe: success path leaks parent clock references from of_clk_get_by_name
From: Greg KH @ 2026-06-26 14:24 UTC (permalink / raw)
To: WenTao Liang
Cc: krzk, s.nawrocki, cw00.choi, mturquette, sboyd, alim.akhtar,
bmasney, linux-samsung-soc, linux-clk, linux-arm-kernel,
linux-kernel, stable
In-Reply-To: <20260626120135.34173-1-vulab@iscas.ac.cn>
On Fri, Jun 26, 2026 at 08:01:35PM +0800, WenTao Liang wrote:
> of_clk_get_by_name() acquires clock references stored in the local
> parents[] array. All error paths correctly release these via the clks_put
> label, but the success path returns 0 without releasing the parent
> references. The references were only needed to obtain clock names for
> registration and are permanently leaked after probe completes.
>
> Cc: stable@vger.kernel.org
> Fixes: 9484f2cb8332 ("clk: samsung: exynos-clkout: convert to module driver")
> Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
> ---
> drivers/clk/samsung/clk-exynos-clkout.c | 4 ++++
> 1 file changed, 4 insertions(+)
For all of these, you are not using the normal kernel style, which means
a LLM is generating them, which implies that you did not properly
document what tool found/fixed all of these. So please go back and fix
them all up and resend them properly, after telling the
maintainers/developers that the originals should be ignored.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v2 2/8] media: dt-bindings: video-interface-devices: add video-interface-devices.h references
From: Laurent Pinchart @ 2026-06-26 14:30 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-2-47178be927b4@ideasonboard.com>
Hi Kieran,
Thank you for the patch.
On Fri, Jun 26, 2026 at 01:07:54PM +0100, Kieran Bingham wrote:
> Expand the documentation of the video-interface-devices orientation to
> reference the include/dt-bindings/media/video-interface-devices.h header
> which provides human readable defines for the orientation enum, to help
> avoid hardcoding values in dts.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> .../bindings/media/video-interface-devices.yaml | 17 +++++++++++------
> 1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/video-interface-devices.yaml b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> index a81d2a155fe6..c9c3f4f16719 100644
> --- a/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> +++ b/Documentation/devicetree/bindings/media/video-interface-devices.yaml
> @@ -392,17 +392,22 @@ properties:
> The orientation of a device (typically an image sensor or a flash LED)
> describing its mounting position relative to the usage orientation of the
> system where the device is installed on.
> + See include/dt-bindings/media/video-interface-devices.h.
If you want this to be a separate paragraph, you need a blnk line on
top. Otherwise, Move "See" to the previous line.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> +
> $ref: /schemas/types.yaml#/definitions/uint32
> enum:
> - # Front. The device is mounted on the front facing side of the system. For
> - # mobile devices such as smartphones, tablets and laptops the front side
> - # is the user facing side.
> + # MEDIA_ORIENTATION_FRONT
> + # The device is mounted on the front facing side of the system. For
> + # mobile devices such as smartphones, tablets and laptops the front
> + # side is the user facing side.
> - 0
> - # Back. The device is mounted on the back side of the system, which is
> + # MEDIA_ORIENTATION_BACK
> + # The device is mounted on the back side of the system, which is
> # defined as the opposite side of the front facing one.
> - 1
> - # External. The device is not attached directly to the system but is
> - # attached in a way that allows it to move freely.
> + # MEDIA_ORIENTATION_EXTERNAL
> + # The device is not attached directly to the system but is attached in
> + # a way that allows it to move freely.
> - 2
>
> additionalProperties: true
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 3/8] dt-bindings: media: i2c: Utilise video-interface-devices enums
From: Laurent Pinchart @ 2026-06-26 14:31 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-3-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:55PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the existing examples throughout the bindings documentation for
> camera sensors.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml | 3 ++-
> Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml | 3 ++-
> 12 files changed, 24 insertions(+), 12 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> index 1a57f2aa1982..b7bc6ba26e6e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml
> @@ -86,6 +86,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -102,7 +103,7 @@ examples:
> vddio-supply = <®_camera_vddio>;
> reset-gpios = <&gpio1 25 GPIO_ACTIVE_LOW>;
> shutdown-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> index 6f2017c75125..b9c61395b24f 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov08d10.yaml
> @@ -69,6 +69,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -84,7 +85,7 @@ examples:
> avdd-supply = <&ov08d10_vdda_2v8>;
> dvdd-supply = <&ov08d10_vddd_1v2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> index d96199031b66..fcd617848ce3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov4689.yaml
> @@ -96,6 +96,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -114,7 +115,7 @@ examples:
> powerdown-gpios = <&pio 107 GPIO_ACTIVE_LOW>;
> reset-gpios = <&pio 109 GPIO_ACTIVE_LOW>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> index ad07204057f9..6df62fd0c0c0 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5675.yaml
> @@ -85,6 +85,7 @@ examples:
> - |
> #include <dt-bindings/clock/px30-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> i2c {
> @@ -108,7 +109,7 @@ examples:
> dovdd-supply = <&vcc_2v8>;
>
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> ucam_out: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> index 3368b3bd8ef2..5732657e1484 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
> @@ -103,6 +103,7 @@ examples:
> - |
> #include <dt-bindings/clock/px30-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> i2c {
> @@ -126,7 +127,7 @@ examples:
> dovdd-supply = <&vcc_2v8>;
>
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> ucam_out: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> index 2b6143aff391..24787c9aa155 100644
> --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov64a40.yaml
> @@ -72,6 +72,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -87,7 +88,7 @@ examples:
> powerdown-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
> reset-gpios = <&gpio1 10 GPIO_ACTIVE_LOW>;
> rotation = <180>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
>
> port {
> endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> index 20f48d5e9b2d..56fb5f18f07b 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx111.yaml
> @@ -69,6 +69,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -84,7 +85,7 @@ examples:
> dvdd-supply = <&camera_vddd_1v2>;
> avdd-supply = <&camera_vdda_2v7>;
>
> - orientation = <1>;
> + orientation = <MEDIA_ORIENTATION_BACK>;
> rotation = <90>;
>
> nvmem = <&eeprom>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> index 6050d7e7dcfe..b4a88eaa7ef2 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx355.yaml
> @@ -74,6 +74,7 @@ examples:
> - |
> #include <dt-bindings/clock/qcom,camcc-sdm845.h>
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -98,7 +99,7 @@ examples:
> pinctrl-0 = <&cam_front_default>;
>
> rotation = <270>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> cam_front_endpoint: endpoint {
> diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> index 7c11e871dca6..69a37ff68db3 100644
> --- a/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx415.yaml
> @@ -86,6 +86,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -98,7 +99,7 @@ examples:
> clocks = <&clock_cam>;
> dvdd-supply = <&vcc1v1_cam>;
> lens-focus = <&vcm>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&vcc1v8_cam>;
> reset-gpios = <&gpio_expander 14 GPIO_ACTIVE_LOW>;
> rotation = <180>;
> diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> index 060ac6829b66..db9f0c15576c 100644
> --- a/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/st,vd55g1.yaml
> @@ -105,6 +105,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -123,7 +124,7 @@ examples:
> reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> st,leds = <2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> index c6673b8539db..48db22ca4a7e 100644
> --- a/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/st,vd56g3.yaml
> @@ -107,6 +107,7 @@ unevaluatedProperties: false
> examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -125,7 +126,7 @@ examples:
> reset-gpios = <&gpio 5 GPIO_ACTIVE_LOW>;
> st,leds = <6>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> index bc339a7374b2..4a66cb711372 100644
> --- a/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> +++ b/Documentation/devicetree/bindings/media/i2c/thine,thp7312.yaml
> @@ -173,6 +173,7 @@ examples:
> - |
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> + #include <dt-bindings/media/video-interface-devices.h>
>
> i2c {
> #address-cells = <1>;
> @@ -196,7 +197,7 @@ examples:
> vddgpio-0-supply = <&vsys_v4p2>;
> vddgpio-1-supply = <&vsys_v4p2>;
>
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <0>;
>
> sensors {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 4/8] ARM: tegra: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:33 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-4-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:56PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the nvidia device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi | 3 ++-
> arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi | 3 ++-
> arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts | 4 +++-
> arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi | 3 ++-
> 4 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
> index 892d718294dd..a7fdd194300c 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
> +++ b/arch/arm/boot/dts/nvidia/tegra30-asus-nexus7-grouper-common.dtsi
> @@ -3,6 +3,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/power/summit,smb347-charger.h>
> #include <dt-bindings/thermal/thermal.h>
>
> @@ -991,7 +992,7 @@ front-camera@48 {
> vdd-supply = <&vddio_cam>;
> vaa-supply = <&avdd_cam1>;
>
> - orientation = <0>; /* Front camera */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
> <&tegra_car TEGRA30_CLK_CSUS>;
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
> index bf1c3a31d406..76286e15684c 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
> +++ b/arch/arm/boot/dts/nvidia/tegra30-asus-transformer-common.dtsi
> @@ -3,6 +3,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/thermal/thermal.h>
>
> #include "tegra30.dtsi"
> @@ -1262,7 +1263,7 @@ front-camera@48 {
> vdd-supply = <&vdd_1v8_cam>;
> vaa-supply = <&avdd_2v85_fcam>;
>
> - orientation = <0>; /* Front camera */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
> <&tegra_car TEGRA30_CLK_CSUS>;
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
> index 896639599c12..28680063bcc0 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
> +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-p895.dts
> @@ -1,6 +1,8 @@
> // SPDX-License-Identifier: GPL-2.0
> /dts-v1/;
>
> +#include <dt-bindings/media/video-interface-devices.h>
> +
> #include "tegra30-lg-x3.dtsi"
>
> / {
> @@ -132,7 +134,7 @@ front-camera@48 {
> vdd-supply = <&vt_1v8_front>;
> vaa-supply = <&vt_2v8_front>;
>
> - orientation = <0>; /* Front camera */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> assigned-clocks = <&tegra_car TEGRA30_CLK_VI_SENSOR>,
> <&tegra_car TEGRA30_CLK_CSUS>;
> diff --git a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> index 60e8a19aa70e..c58e3026a115 100644
> --- a/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> +++ b/arch/arm/boot/dts/nvidia/tegra30-lg-x3.dtsi
> @@ -4,6 +4,7 @@
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/leds/common.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/mfd/max77620.h>
> #include <dt-bindings/thermal/thermal.h>
>
> @@ -1216,7 +1217,7 @@ rear-camera@10 {
> dvdd-supply = <&vdd_1v2_rear>;
> avdd-supply = <&vdd_2v7_rear>;
>
> - orientation = <1>; /* Rear camera */
> + orientation = <MEDIA_ORIENTATION_REAR>;
This should be MEDIA_ORIENTATION_BACK. And you should compile all the
device trees the series touch.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> rotation = <90>;
>
> nvmem = <&m24c08>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 5/8] arm64: dts: freescale: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:33 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-5-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:57PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the freescale/NXP device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> .../boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso | 3 ++-
> arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
> index e5a2b3780215..7b44ae0f19b2 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtso
> @@ -9,6 +9,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> #include "imx8mp-pinfunc.h"
>
> @@ -47,7 +48,7 @@ camera@10 {
> VANA-supply = <®_cam>;
> VDIG-supply = <®_cam>;
> VDDL-supply = <®_cam>;
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> index f5d529c5baf3..178cfad93483 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mq-librem5.dtsi
> @@ -8,6 +8,7 @@
> #include "dt-bindings/input/input.h"
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include "dt-bindings/pwm/pwm.h"
> #include "dt-bindings/usb/pd.h"
> #include "imx8mq.dtsi"
> @@ -1116,7 +1117,7 @@ camera_front: camera@20 {
> vddd-supply = <®_vcam_1v2>;
> vddio-supply = <®_csi_1v8>;
> rotation = <90>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> camera1_ep: endpoint {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 6/8] arm64: dts: qcom: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:34 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-6-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:58PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the qualcomm device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 3 ++-
> arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts | 3 ++-
> arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi | 3 ++-
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> index 04cb9230d29f..d79be22108c8 100644
> --- a/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> +++ b/arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts
> @@ -13,6 +13,7 @@
> #include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
> #include <dt-bindings/leds/common.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
> #include <dt-bindings/sound/qcom,q6asm.h>
> @@ -701,7 +702,7 @@ camera@10 {
> pinctrl-0 = <&cam_mclk3_default>;
> pinctrl-names = "default";
>
> - orientation = <0>; /* Front facing */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> rotation = <270>;
>
> port {
> diff --git a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> index abd9c5a67b9f..543fc691fd3c 100644
> --- a/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> +++ b/arch/arm64/boot/dts/qcom/sc8280xp-lenovo-thinkpad-x13s.dts
> @@ -11,6 +11,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/regulator/qcom,rpmh-regulator.h>
>
> #include "sc8280xp.dtsi"
> @@ -682,7 +683,7 @@ camera@10 {
>
> clocks = <&camcc CAMCC_MCLK3_CLK>;
>
> - orientation = <0>; /* Front facing */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> avdd-supply = <&vreg_l6q>;
> dvdd-supply = <&vreg_l2q>;
> diff --git a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> index 0f57b915186b..375b3c0edea7 100644
> --- a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
> @@ -9,6 +9,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
> #include <dt-bindings/power/qcom-rpmpd.h>
> #include "sdm670.dtsi"
> @@ -460,7 +461,7 @@ camera@1a {
> pinctrl-names = "default";
>
> rotation = <270>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
>
> port {
> cam_front_endpoint: endpoint {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 7/8] arm64: dts: renesas: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:34 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Kieran Bingham
In-Reply-To: <20260626-kbingham-orientation-v2-7-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:59PM +0100, Kieran Bingham wrote:
> From: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
>
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the renesas device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso | 3 ++-
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso | 3 ++-
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso | 3 ++-
> .../arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso | 3 ++-
> 4 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
> index 3acaf714cf24..b816382bba0a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx219.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j1: clk-cam-j1 {
> @@ -44,7 +45,7 @@ cam@10 {
> VDIG-supply = <®_cam_j1>;
> VDDL-supply = <®_cam_j1>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
> index a19bc0840392..4019b80a88b7 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j1-imx462.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j1: clk-cam-j1 {
> @@ -46,7 +47,7 @@ cam@1a {
> vdda-supply = <®_cam_j1>;
> vddd-supply = <®_cam_j1>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
> index 512810b861aa..fea1ef4a1178 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx219.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j2: clk-cam-j2 {
> @@ -44,7 +45,7 @@ cam@10 {
> VDIG-supply = <®_cam_j2>;
> VDDL-supply = <®_cam_j2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
> index a31524b59834..177201a8a6d2 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
> +++ b/arch/arm64/boot/dts/renesas/r8a779g3-sparrow-hawk-camera-j2-imx462.dtso
> @@ -12,6 +12,7 @@
>
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/media/video-interfaces.h>
> +#include <dt-bindings/media/video-interface-devices.h>
>
> &{/} {
> clk_cam_j2: clk-cam-j2 {
> @@ -46,7 +47,7 @@ cam@1a {
> vdda-supply = <®_cam_j2>;
> vddd-supply = <®_cam_j2>;
>
> - orientation = <2>;
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> rotation = <0>;
>
> port {
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2 8/8] arm64: dts: rockchip: Convert to new media orientation definitions
From: Laurent Pinchart @ 2026-06-26 14:36 UTC (permalink / raw)
To: Kieran Bingham
Cc: Mauro Carvalho Chehab, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jacopo Mondi, Sakari Ailus, Jimmy Su, Matthias Fend,
Mikhail Rudenko, Daniel Scally, Jacopo Mondi, Michael Riesch,
Benjamin Mugnier, Sylvain Petinot, Paul Elder, Martin Kepplinger,
Quentin Schulz, Tommaso Merciai, Svyatoslav Ryhel, Richard Acayan,
Thierry Reding, Jonathan Hunter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Bjorn Andersson,
Konrad Dybcio, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip
In-Reply-To: <20260626-kbingham-orientation-v2-8-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:08:00PM +0100, Kieran Bingham wrote:
> The orientation property for video interface devices now has definitions
> to prevent hardcoded integer values for the enum options.
>
> Update the users throughout the rockchip device trees to use the new
> definitions.
>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> ---
> arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi | 3 ++-
> arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso | 3 ++-
> arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts | 5 +++--
> .../boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso | 3 ++-
> .../boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso | 3 ++-
> 5 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi b/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
> index 192791993f05..d58d6ee6241e 100644
> --- a/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/px30-pp1516.dtsi
> @@ -6,6 +6,7 @@
> /dts-v1/;
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/input/input.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include "px30.dtsi"
>
> @@ -413,7 +414,7 @@ camera@36 {
> dvdd-supply = <&vcc_cam_dvdd>;
> dovdd-supply = <&vcc_cam_dovdd>;
> lens-focus = <&focus>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> pinctrl-names = "default";
> pinctrl-0 = <&cif_clkout_m0 &cam_pwdn>;
> reset-gpios = <&gpio2 RK_PB0 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
> index 760d5139f95d..2168db9168a5 100644
> --- a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
> +++ b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou-video-demo.dtso
> @@ -16,6 +16,7 @@
> #include <dt-bindings/gpio/gpio.h>
> #include <dt-bindings/interrupt-controller/irq.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> &{/} {
> @@ -185,7 +186,7 @@ camera@36 {
> dvdd-supply = <&cam_dvdd_1v2>;
> dovdd-supply = <&cam_dovdd_1v8>;
> lens-focus = <&focus>;
> - orientation = <0>;
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> pinctrl-names = "default";
> pinctrl-0 = <&cif_clkout_m0>;
> reset-gpios = <&pca9670 6 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> index 8d26bd9b7500..6608c777f185 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-pinephone-pro.dts
> @@ -13,6 +13,7 @@
> #include <dt-bindings/input/gpio-keys.h>
> #include <dt-bindings/input/linux-event-codes.h>
> #include <dt-bindings/leds/common.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include "rk3399-s.dtsi"
>
> / {
> @@ -455,7 +456,7 @@ wcam: camera@1a {
> reg = <0x1a>;
> clocks = <&cru SCLK_CIF_OUT>; /* MIPI_MCLK0, derived from CIF_CLKO */
> lens-focus = <&wcam_lens>;
> - orientation = <1>; /* V4L2_CAMERA_ORIENTATION_BACK */
> + orientation = <MEDIA_ORIENTATION_BACK>;
> pinctrl-names = "default";
> pinctrl-0 = <&camera_rst_l>;
> reset-gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_LOW>;
> @@ -487,7 +488,7 @@ ucam: camera@36 {
> clocks = <&cru SCLK_CIF_OUT>; /* MIPI_MCLK1, derived from CIF_CLK0 */
> clock-names = "xvclk";
> dovdd-supply = <&vcc1v8_dvp>;
> - orientation = <0>; /* V4L2_CAMERA_ORIENTATION_FRONT */
> + orientation = <MEDIA_ORIENTATION_FRONT>;
> pinctrl-names = "default";
> pinctrl-0 = <&camera2_rst_l &dvp_pdn0_h>;
> powerdown-gpios = <&gpio2 RK_PB4 GPIO_ACTIVE_LOW>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
> index ee9ecf68a886..8c9a4a1181e4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam0.dtso
> @@ -9,6 +9,7 @@
>
> #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> &{/} {
> @@ -50,7 +51,7 @@ imx415: camera-sensor@1a {
> avdd-supply = <&savdd_cam0>;
> clocks = <&cru CLK_MIPI_CAMARAOUT_M3>;
> dvdd-supply = <&sdvdd_cam0>;
> - orientation = <2>; /* External */
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&siovdd_cam0>;
> pinctrl-names = "default";
> pinctrl-0 = <&cam0_rstn &mipim0_camera3_clk>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
> index 8a4cf3fdbf8e..0cc3d6a34cef 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
> +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b-plus-radxa-cam4k-cam1.dtso
> @@ -9,6 +9,7 @@
>
> #include <dt-bindings/clock/rockchip,rk3588-cru.h>
> #include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/media/video-interface-devices.h>
> #include <dt-bindings/pinctrl/rockchip.h>
>
> &{/} {
> @@ -50,7 +51,7 @@ cam1_imx415: camera-sensor@1a {
> avdd-supply = <&savdd_cam1>;
> clocks = <&cru CLK_MIPI_CAMARAOUT_M4>;
> dvdd-supply = <&sdvdd_cam1>;
> - orientation = <2>; /* External */
> + orientation = <MEDIA_ORIENTATION_EXTERNAL>;
> ovdd-supply = <&siovdd_cam1>;
> pinctrl-names = "default";
> pinctrl-0 = <&cam1_rstn &mipim0_camera4_clk>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH] soc: imx8m: fix clock reference leak in imx8m_soc_prepare()
From: Felix Gu @ 2026-06-26 14:37 UTC (permalink / raw)
To: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Marco Felsch, Peng Fan, Shawn Guo
Cc: imx, linux-arm-kernel, linux-kernel, Felix Gu
When clk_prepare_enable() fails, the error path does not release the
clock reference obtained by of_clk_get_by_name(). Add clk_put() to
the error path before iounmap().
Fixes: 390c01073f5d ("soc: imx8m: Cleanup with adding imx8m_soc_[un]prepare")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/soc/imx/soc-imx8m.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c
index fc080e56f50d..de19972435f9 100644
--- a/drivers/soc/imx/soc-imx8m.c
+++ b/drivers/soc/imx/soc-imx8m.c
@@ -150,10 +150,12 @@ static int imx8m_soc_prepare(struct platform_device *pdev, const char *ocotp_com
ret = clk_prepare_enable(drvdata->clk);
if (ret)
- goto err_clk;
+ goto put_clk;
return 0;
+put_clk:
+ clk_put(drvdata->clk);
err_clk:
iounmap(drvdata->ocotp_base);
return ret;
---
base-commit: 30ffa8de54e5cc80d93fd211ca134d1764a7011f
change-id: 20260626-soc-imx8m-938e89104044
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* Re: [PATCH 05/37] drm/display: bridge-connector: split code creating the connector to a subfunction
From: Maxime Ripard @ 2026-06-26 14:38 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Inki Dae, Jagan Teki,
Marek Szyprowski, Marek Vasut, Stefan Agner, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Hui Pu,
Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel, imx,
linux-arm-kernel
In-Reply-To: <DJJ1MPCEJGZD.UZM9183V6ZE5@bootlin.com>
[-- Attachment #1: Type: text/plain, Size: 5205 bytes --]
On Fri, Jun 26, 2026 at 04:16:39PM +0200, Luca Ceresoli wrote:
> Hi Maxime,
>
> On Fri Jun 26, 2026 at 12:09 PM CEST, Maxime Ripard wrote:
> > On Wed, Jun 24, 2026 at 05:47:10PM +0200, Luca Ceresoli wrote:
> >> On Wed Jun 24, 2026 at 1:41 PM CEST, Maxime Ripard wrote:
> >> > Hi,x
> >> >
> >> > On Fri, Jun 12, 2026 at 02:56:24PM +0200, Luca Ceresoli wrote:
> >> >> On Mon Jun 8, 2026 at 1:40 PM CEST, Maxime Ripard wrote:
> >> >> > On Tue, May 19, 2026 at 12:37:22PM +0200, Luca Ceresoli wrote:
> >> >> >> In preparation to introduce bridge hotplug, split out from
> >> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> >> dedicated function. This will be needed to be able to add (and re-add) the
> >> >> >> connector from different code paths.
> >> >> >
> >> >> > Same story here, explaining what you need later on that calls for that
> >> >> > change would be nice.
> >> >>
> >> >> Here's a more verbose version:
> >> >>
> >> >> Currently drm_bridge_connector_init() does two things:
> >> >>
> >> >> * allocate and initialize the drm_bridge_connector
> >> >> (which embeds a drm_connector)
> >> >> * initialize and register the embedded drm_connector
> >> >>
> >> >> For bridge hotplug we need to separate these two actions:
> >> >>
> >> >> * the drm_connector needs to be added and removed at any time based on
> >> >> hotplug events
> >> >> * the drm_bridge_connector is designated to create and remove the
> >> >> drm_connector, so it must be persistent for the card lifetime
> >> >>
> >> >> As the lifetimes of drm_bridge_connector and drm_connector become
> >> >> different, we need to create them in different moments.
> >> >>
> >> >> In preparation to support that, split out from
> >> >> drm_bridge_connector_init() the code adding the drm_connector into a
> >> >> dedicated function. No functional changes, just moving code around for
> >> >> now. A future commit will make the drm_connector be created based on
> >> >> hotplug events.
> >> >>
> >> >> Looks good?
> >> >
> >> > The message itself, yes, thanks.
> >> >
> >> > However, I have questions now :)
> >> >
> >> > Do we really expect drm_bridge_connector to stick around when a bridge
> >> > gets unplugged? If so, how does it cope with having, say, an HDMI
> >> > connector, and then swapping out the hotplugged part for an LVDS one?
> >> > Does the HDMI connector sticks around indefinitely?
> >>
> >> In your example, the HDMI drm_connector would be unregistered and put on
> >> hotunplug. Its allocation will stick around until the last put but that's
> >> quite irrelevant. Then, on plugging the LVDS addon, a new LVDS
> >> drm_connector will be created and registered.
> >>
> >> > *Especially* if we're using overlays for this, I'd expect everything
> >> > after the first hotplugged bridge to be destroyed, no?
> >>
> >> As said, it would be unregistered immediately but might be freed later on
> >> if still refcounted.
> >>
> >> This is visible in patches 36+15, the path to follow is:
> >>
> >> drm_bridge_connector_handle_event(event = DRM_BRIDGE_DETACHED) [patch 36]
> >> -> drm_bridge_connector_dynconn_release() [patch 15]
> >>
> >> Does this solve your concern?
> >
> > Not really, I'm talking about drm_bridge_connector. The fact that
> > bridges are destroyed make sense to me. The fact that
> > drm_bridge_connector sticks around doesn't. It's supposed to be a
> > connector for bridges. If you don't have bridges because they got
> > destroyed, and connector, drm_bridge_connector doesn't have a reason to
> > exist anymore, unless it's drm_bridge_hotplug in a trench coat :)
>
> It is not a hotplug-bridge in a trench coat, no :) The code is clear about
> this.
>
> I'd say with this series a "drm_bridge_connector" is just becoming
> something more (perhaps something else too). Somewhat as "a drm_bridge is
> either a bridge or something else". :)
>
>
> But let's leave names aside for a moment. If just looking at the current
> code, the drm_bridge_connector is "a handler, owned by the card/encoder and
> having the same lifetime, which takes care of drm_connector
> creation/destruction at card probe/removal".
>
> What we need now is just the same plug " and on hotplug events" appended.
>
> So in both cases there needs to be "a handler persitent with the card".
>
> Do we agree so far?
Ish. If we go for that, then we need to update the name.
drm_bridge_connector for something that is neither a bridge or a
connector is not great.
But even then, I'm not even sure why we need to have that "manager" in
the first place. You want to make bridges be aware if they are the last
in the chain or not. Use that property in attach to either create a
drm_bridge_connector instance if you're last, or attach the next bridge
if you aren't.
And when a bridge is removed, drop everything after it in the chain,
drm_bridge_connector instance included.
And the encoder can take care of handling bridge remove and tearing down
the bridge chain itself.
Maximex
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* [PATCH] arm64: dts: rockchip: fix eMMC reset polarity on PX30 Ringneck
From: Quentin Schulz @ 2026-06-26 14:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Quentin Schulz
Cc: devicetree, linux-arm-kernel, linux-rockchip, linux-kernel,
Quentin Schulz, stable
From: Quentin Schulz <quentin.schulz@cherry.de>
According to the Jedec 5.1 specification, the device is held in reset
when RST_n is low, therefore the polarity of the line must be that, as
specified in the Device Tree binding (mmc/mmc-pwrseq-emmc.yaml).
Due to the wrong polarity, eMMC devices with RST_n_FUNCTION[162]
bitfield [1:0] set to 0x1 (the default is 0x0) will be held in reset
forever.
Cc: stable@vger.kernel.org
Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard")
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
---
PX30 Ringneck is affected by the same issue that Cobra and PP-1516 have
and for which patches[1][2] have already been sent.
Out of the other boards I own, RK3588 Tiger and Jaguar also have an
inverted polarity but I tried making the eMMC chip care about the reset
line polarity to no avail, therefore I'm not changing them until we
figure out a setup in which we can reproduce the issue.
There are a handful of other Rockchip boards with an inverted polarity
but I don't own any of them so I will not change them either.
[1] https://lore.kernel.org/linux-rockchip/20260609081728.30616-2-jakobunt@gmail.com/
[2] https://lore.kernel.org/linux-rockchip/20260612-pp1516-emmc-polarity-v1-1-4816c1c909f7@cherry.de/
---
arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi
index 973b4c5880e24..29794216592d8 100644
--- a/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi
+++ b/arch/arm64/boot/dts/rockchip/px30-ringneck.dtsi
@@ -26,7 +26,7 @@ emmc_pwrseq: emmc-pwrseq {
compatible = "mmc-pwrseq-emmc";
pinctrl-0 = <&emmc_reset>;
pinctrl-names = "default";
- reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 RK_PB3 GPIO_ACTIVE_LOW>;
};
leds {
---
base-commit: 4edcdefd4083ae04b1a5656f4be6cd83ae919ef4
change-id: 20260626-ringneck-emmc-polarity-717003c6b802
Best regards,
--
Quentin Schulz <quentin.schulz@cherry.de>
^ permalink raw reply related
* Re: [PATCH v2 0/2] gpio: fix sleeping-in-atomic in shared-proxy; restore meson non-sleeping
From: Bartosz Golaszewski @ 2026-06-26 14:48 UTC (permalink / raw)
To: Viacheslav Bocharov
Cc: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Marek Szyprowski, Robin Murphy, Diederik de Haas, linux-gpio,
linux-arm-kernel, linux-amlogic, linux-kernel, Linus Walleij,
Bartosz Golaszewski
In-Reply-To: <20260625115718.1678991-1-v@baodeep.com>
On Thu, 25 Jun 2026 13:57:16 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> gpio-shared-proxy chooses its descriptor lock (mutex vs spinlock) from
> the underlying chip's can_sleep, but under that lock it calls config and
> direction ops that reach sleeping pinctrl paths. On a controller with
> non-sleeping MMIO value ops the lock is a spinlock, so a sleeping call
> runs from atomic context:
>
> BUG: sleeping function called from invalid context
> ... pinctrl_gpio_set_config <- gpiochip_generic_config
> <- gpio_shared_proxy_set_config (voting spinlock held)
> <- ... <- mmc_pwrseq_simple_probe
>
> This was reported on Khadas VIM3 and worked around for Amlogic by
> commit 28f240683871 ("pinctrl: meson: mark the GPIO controller as
> sleeping"), which marked the whole meson controller sleeping. That
> workaround broke atomic value-path consumers: w1-gpio (1-Wire bitbang)
> no longer detects devices, because its IRQ-disabled read slot calls the
> non-cansleep gpiod_*_value() and now hits WARN_ON(can_sleep) per bit.
>
> Patch 1 fixes the proxy locking generically (always a sleeping mutex).
> Patch 2 then restores meson can_sleep=false, fixing 1-Wire.
>
> Patch 1 has a trade-off: a proxied GPIO becomes sleeping, so consumers
> gating on gpiod_cansleep() change behaviour. No current device needs
> atomic (non-cansleep) value access on a shared GPIO -- every report
> (Khadas VIM3, ODROID-M1, my test on JetHub D1+) is a shared reset line
> (eMMC/SDIO pwrseq or PCIe reset) driven through the cansleep accessors,
> which is what the proxy exists to vote on; bit-banging that needs atomic
> access cannot work through voting anyway. An alternative that keeps
> atomic value access (split locking) is possible but adds a second lock
> and new race windows, so this series takes the simpler mutex-only
> approach.
>
> The two are a unit: patch 2 must not be applied without patch 1,
> otherwise the original VIM3 splat returns on boards that share a meson
> GPIO -- please keep the order. I have not Cc'd stable; I will request
> stable backports separately once both patches have landed.
>
> Changes since v1:
> - gpio: shared-proxy: open-code the descriptor mutex; drop the
> gpio_shared_desc_lock guard and the gpio_shared_lockdep_assert()
> helper, move the mutex rationale to the can_sleep assignment. No
> functional change.
>
> v1: https://lore.kernel.org/linux-gpio/20260610153329.937833-1-v@baodeep.com/
>
> Viacheslav Bocharov (2):
> gpio: shared-proxy: always serialize with a sleeping mutex
> pinctrl: meson: restore non-sleeping GPIO access
>
> drivers/gpio/gpio-shared-proxy.c | 66 +++++++++++----------------
> drivers/gpio/gpiolib-shared.c | 9 +---
> drivers/gpio/gpiolib-shared.h | 28 +-----------
> drivers/pinctrl/meson/pinctrl-meson.c | 2 +-
> 4 files changed, 30 insertions(+), 75 deletions(-)
>
>
> base-commit: 840ef6c78e6a2f694b578ecb9063241c992aaa9e
> --
> 2.54.0
>
>
I have no idea what's wrong but I'm still getting two copies of each email
as separate messages to my inbox. I'm not seeing it with anyone else. I think
there's some issue with your setup.
Bart
^ permalink raw reply
* Re: [PATCH v2 00/11] iommu/arm-smmu-v3: Add PRI support
From: harsha.v @ 2026-06-26 14:54 UTC (permalink / raw)
To: Nicolin Chen, will, robin.murphy, jgg
Cc: joro, bhelgaas, praan, kevin.tian, kees, smostafa, baolu.lu,
linux-arm-kernel, iommu, linux-kernel, linux-pci, skaestle,
mmarrid, skolothumtho, bbiber
In-Reply-To: <cover.1779944354.git.nicolinc@nvidia.com>
Hi Nicolin Chen,
On 5/28/2026 1:29 PM, Nicolin Chen wrote:
> The SMMUv3 driver doesn't handle events on the PRI queue or respond to IOPF
> faults. This series adds the missing pieces, using the IOPF infrastructure,
> to convert PRI page requests into iopf_faults and issue CMDQ_OP_PRI_RESP.
>
> The iopf_queue_flush_dev() contract requires the driver to first drain the
> hardware PRI queue and synchronize using a threaded IRQ handler before the
> IOPF software flush. This drove the additional commits compared to v1:
> - arm_smmu_drain_queue_for_iopf() drains the hardware queue to the PROD
> snapshot
> - arm_smmu_attach_release() moves the teardown outside the global lock
> - synchronize_irq() closes the gap before the final flush
>
> This is on Github:
> https://github.com/nicolinc/iommufd/commits/smmuv3_pri-v2
>
> FWIW, engineers on the NVIDIA side have managed to verify the PRI feature.
>
> Changelog
> v2:
> * Allocate evtq.iopf for ARM_SMMU_FEAT_PRI
> * Pick up Jean's PRI stubs and PRI export patches
> * Enable PRI for PCI devices in arm_smmu_probe_device()
> * Add arm_smmu_drain_queue_for_iopf() for EVTQ and PRIQ
> * Add arm_smmu_attach_release() to rework the IOPF drain
> * Add IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS for STALL mode
> * Gate pci_enable_pri() on FEAT_PRI plus a non-NULL evtq.iopf
> * Deny unrecognised-StreamID PRG_LAST in arm_smmu_handle_ppr()
> * Disable PRI when no IRQ handler is registered (unique or combined IRQ)
> v1:
> https://lore.kernel.org/all/cover.1772568590.git.nicolinc@nvidia.com/
>
> Jean-Philippe Brucker (2):
> PCI/ATS: Add PRI stubs
> PCI/ATS: Export pci_enable_pri() and pci_reset_pri()
>
> Malak Marrid (1):
> iommu/arm-smmu-v3: Submit CMDQ_OP_PRI_RESP for IOPF event
>
> Nicolin Chen (8):
> iommu/arm-smmu-v3: Add arm_smmu_attach_release()
> iommu/arm-smmu-v3: Factor out __queue_empty() and __queue_consumed()
> iommu/arm-smmu-v3: Add arm_smmu_drain_queue_for_iopf() helper
> iommu/arm-smmu-v3: Drain in-flight fault handlers
> iommu/arm-smmu-v3: Support PRI Page Request in arm_smmu_handle_ppr()
> iommu/arm-smmu-v3: Disable PRI when no IRQ handler is registered
> iommu/arm-smmu-v3: Allocate IOPF queue for ARM_SMMU_FEAT_PRI
> iommu/arm-smmu-v3: Enable PRI for PCI device in
> arm_smmu_probe_device()
>
> drivers/iommu/arm/Kconfig | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 3 +
> include/linux/iommu.h | 1 +
> include/linux/pci-ats.h | 5 +
> .../arm/arm-smmu-v3/arm-smmu-v3-iommufd.c | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 244 +++++++++++++++---
> drivers/pci/ats.c | 2 +
> 7 files changed, 221 insertions(+), 36 deletions(-)
>
>
> base-commit: 74fa4c177ad09800b007cba043370c887bb1b4e3
One thing I noticed while reviewing: when arm_smmu_priq_thread() detects
PRIQ overflow, partial faults (non-LAST pages stored via
report_partial_fault()) whose LAST page was lost in the overflow remain
permanently in iopf_param->partial. This is a monotonic memory leak —
it grows with each overflow event.
Intel VT-d handles this in prq_event_thread() (drivers/iommu/intel/prq.c):
if (head == tail) {
iopf_queue_discard_partial(iommu->iopf_queue);
writel(DMA_PRS_PRO, iommu->reg + DMAR_PRS_REG);
}
iopf_queue_discard_partial() was written for exactly this scenario.
Could we add the same here arm_smmu_priq_thread()
(drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c) ?
if (queue_sync_prod_in(q) == -EOVERFLOW) {
dev_err(smmu->dev, "PRIQ overflow detected -- requests lost\n");
+ iopf_queue_discard_partial(smmu->evtq.iopf);
}
At this point all surviving entries have already been consumed by the
loop above, so discarding unconditionally is safe — implicitly matching
Intel's "head == tail" guard.
Best Regards,
Harsha Vardhan V
^ permalink raw reply
* Re: [RFC v2 PATCH] reserve_mem: add support for static memory
From: Shyam Saini @ 2026-06-26 14:54 UTC (permalink / raw)
To: Mike Rapoport
Cc: linux-mm, linux-doc, linux-kernel, akpm, tgopinath, bboscaccy,
kees, tony.luck, gpiccoli, bp, rdunlap, peterz, feng.tang,
dapeng1.mi, elver, enelsonmoore, kuba, lirongqing, ebiggers,
Catalin Marinas, Will Deacon, Ard Biesheuvel, David Hildenbrand,
linux-arm-kernel
In-Reply-To: <ajzovhWHcFQZ9d3l@kernel.org>
On 25 Jun 2026 11:37, Mike Rapoport wrote:
> Hi Shyam,
>
> On Wed, Jun 24, 2026 at 06:22:33PM -0700, Shyam Saini wrote:
> > On 21 Jun 2026 13:36, Mike Rapoport wrote:
> > > On Thu, Jun 18, 2026 at 11:23:31PM -0700, Shyam Saini wrote:
> > > > reserve_mem relies on dynamic memory allocation, this limits the
> > > > usecase where memory is required to be preserved across the boots.
> > > > Eg: ramoops memory reservation on ACPI platforms
> > > >
> > > > So add support to pass a pre-determined static address and reserve
> > > > memory at a specified location. This enables use case like ramoops
> > > > on ACPI platforms to reliably access ramoops region with previous
> > > > boot logs.
> > > >
> > > > Also skip the parsing of <align> when static address is passed.
> > > >
> > > > Example syntax for static address
> > > > reserve_mem=4M@0x1E0000000:oops
> > >
> > > reserve_mem is best effort by design because such hacks as well as memmap=
> > > cannot guarantee this memory is actually free.
> > >
> > > If you want to preserve ramoops reliably, use KHO with reserve_mem.
> > > The first kernel will allocate memory, this memory will be preserved by KHO
> > > and could be picked up by the second kernel.
> >
> > ok, On ARM64 DTS systems, we can reserve ramoops memory in the device tree during
> > the warm reboot.
>
> The cc list actually implied x86 ;-)
> Added arm64 folks now.
Thanks for adding ARM folks, I had just included whatever get_maintainer script
suggested, sorry.
> > For an equivalent ARM64 ACPI platform, what is the recommended way to reserve
> > and preserve that memory across the boots?
>
> I don't think it exists, but a command line option (be it memmap= or
> reserve_mem=) does not seem the right way to me.
>
> Most of the arguments that were made against adding memmap= to arm64 [1]
> apply here.
>
> If kexec is an option, KHO provides a reliable way to preserve memory
> across boots.
>
> If kexec is not an option, we should look for a generic way to specify
> something like DT's reserved_mem for ACPI/EFI systems.
>
> [1] https://lkml.kernel.org/lkml/20201118063314.22940-1-song.bao.hua@hisilicon.com/T/
>
Well, kexec is one of the option for my use case, it also requires
memory reservation during warm reboot, I think memory can be reserved in
the firmware but this will create a dependency on firmware for Linux
reservation.
It would be great to have a in kernel memory reservation mechanism for
ARM64 ACPI platforms. I believe some other use cases like PMEM
reservation would also benefit from this.
Thanks,
Shyam
^ permalink raw reply
* Re: [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: Vanshidhar Konda @ 2026-06-26 14:55 UTC (permalink / raw)
To: Pengjie Zhang
Cc: Will Deacon, catalin.marinas, rafael, lenb, robert.moore,
beata.michalska, zhenglifeng1, zhanjie9, sumitg, cuiyunhui,
linux-arm-kernel, linux-kernel, linux-acpi, acpica-devel,
linuxarm, jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5,
lihuisong, yubowen8, wangzhi12, ionela.voinescu, jeremy.linton
In-Reply-To: <443104e2-ba6e-454e-8469-909f35817a99@huawei.com>
On Wed, May 20, 2026 at 10:55:54AM +0800, Pengjie Zhang wrote:
>
>On 5/19/2026 6:47 PM, Will Deacon wrote:
>>On Thu, Apr 30, 2026 at 06:00:44PM +0800, zhangpengjie (A) wrote:
>>>Hi all,
>>>
>>>Gentle ping on this thread. It has been a while since I posted it.
>>>
>>>Could someone please take a look when you have time? If there is anything
>>>I should revise or any additional information needed, I'd be happy to
>>>update it.
>>It's hard to find active folks who have contributed meaningfully to the
>>cppc_acpi driver... I've added Ionella and Jeremy, in case they can take
>>a look.
>>
>>Will
>Thanks Will, and thanks for adding Ionela and Jeremy.
>
>While waiting for further comments, I would like to add some
>test data to make the effect of this series clearer.
>
>On the test platform, the maximum frequency reported by the platform
>is 2300000. I sampled cpuinfo_cur_freq before and after applying this
>series.
>
>Before applying the series, the samples showed visible transient outliers.
>??The minimum value was 2154583 and the maximum value was 2491071.
>There were 8 samples above 2400000 and 8 samples below 2200000.
>The largest value exceeded the platform maximum by about 8.3%.
>
>After applying the series, the samples became much more stable.
>The minimum value was 2290243 and the maximum value was 2306310.
>There were no samples above 2400000 and no samples below 2200000.
>The largest value exceeded the platform maximum by only about 0.27%.
>
>A summary of the 96 samples is:
>
>?? ?? ?? ?? ?? ?? ?? ?? ?? ?? before?? ?? ?? ?? ?? after
>min?? ?? ?? ?? ?? ?? ?? 2154583?? ?? ?? ?? ??2290243
>max?? ?? ?? ?? ?? ?? ?? 2491071?? ?? ?? ?? ??2306310
>range?? ?? ?? ?? ?? ?? ??336488?? ?? ?? ?? ?? ??16067
>average?? ?? ?? ?? ?? 2298436.4?? ?? ?? ??2298479.4
>stddev?? ?? ?? ?? ?? ?? ??55184.1?? ?? ?? ?? ?? 2868.2
>samples > 2300000?? 26 / 96?? ?? ?? ?? ??16 / 96
>samples > 2400000?? ??8 / 96?? ?? ?? ?? ?? 0 / 96
>samples < 2200000?? ??8 / 96?? ?? ?? ?? ?? 0 / 96
>
>So this series does not try to clamp the value to the platform maximum.
>??Instead, it reduces the sampling skew between the delivered and reference
>feedback counters. The remaining small deviation around 2300000 is
>??much smaller than the previous transient spikes.
>
>One concern that may come up is that an FFH read may cause an idle
>target CPU to be woken, depending on the platform/vendor implementation.
>However, that behavior is not introduced by this series. It is already part
>of how FFH counter reads are implemented on such platforms. This series
>only changes the sampling form for the FFH feedback counters: when both
>delivered and reference counters are FFH counters, read them together
>instead of issuing two separate FFH reads.
>
>If the target CPU has to be involved for an FFH read, doing one paired
>read should be no worse than doing two separate reads, and it also
>narrows the sampling window between the two counters.
>
I agree with this point. It reduces the number of times the idle CPU
is woken up just to read counters.
>If there is any concern about the generic hook or the arm64 implementation,
>I would be happy to revise it.
>
>The raw data is as follows:
>before:
>2303809 2294827 2300000 2293643 2290740 2300000 2297228 2296082
>2301707 2295354 2296601 2303163 2296766 2296543 2295412 2298394
>2297387 2300000 2308274 2301882 2297752 2418568 2491071 2300000
>2183264 2296238 2434731 2296721 2439777 2302159 2301773 2298226
>2300000 2305936 2301133 2297511 2300000 2300000 2294408 2298494
>2295011 2302721 2295955 2301505 2298064 2297419 2298933 2189595
>2298058 2296046 2300000 2301449 2414908 2296559 2305251 2166666
>2296626 2173303 2300000 2298806 2411389 2301822 2297291 2300000
>2423831 2297902 2300000 2435730 2302433 2295353 2298898 2296043
>2321868 2294907 2300000 2157841 2296052 2206530 2300000 2297811
>2297920 2294382 2297767 2157230 2302564 2298504 2296822 2300000
>2296868 2294866 2154583 2290888 2302542 2292549 2300000 2184259
>
>after:
>2303738 2296153 2298087 2295607 2301373 2298076 2300000 2295081
>2297788 2300000 2300000 2295238 2301449 2300000 2298488 2297911
>2301477 2298507 2294976 2296852 2293689 2294077 2293887 2292619
>2300000 2300000 2298072 2300000 2291943 2300000 2295370 2300000
>2301873 2304645 2300000 2296766 2300000 2300000 2290243 2297954
>2297183 2306310 2300000 2296889 2300000 2303800 2301970 2296888
>2300000 2301354 2300000 2298405 2298202 2296767 2298663 2302522
>2297821 2302471 2300000 2303233 2298226 2298698 2300000 2297291
>2296470 2300000 2298398 2300000 2295681 2300000 2300000 2296344
>2300000 2296008 2302375 2297977 2298447 2296519 2295565 2294866
>2297945 2300000 2294978 2303595 2300000 2300000 2294930 2301096
>2296271 2296086 2294482 2300000 2294843 2300000 2296803 2295708
I tested this series on Ampere AmpereOne A192-32X.
Tested-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
Reviewed-by: Vanshidhar Konda <vanshikonda@os.amperecomputing.com>
Regards,
Vanshidhar Konda
>>>On 4/10/2026 5:41 PM, Pengjie Zhang wrote:
>>>>The legacy CPPC feedback-counter path reads the delivered and reference
>>>>performance counters separately.
>>>>
>>>>On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
>>>>served through a cross-CPU counter read helper. Reading the counters
>>>>separately therefore widens the sampling window between them and can
>>>>skew the delivered/reference ratio used by cpuinfo_cur_freq. Under heavy
>>>>load, the skew is observable as transient values that may exceed the
>>>>platform maximum, as discussed in [1] and [2].
>>>>
>>>>This series adds a small generic hook for architectures that can obtain
>>>>both FFH feedback counters in one operation, while preserving the
>>>>existing per-register read path as the fallback.
>>>>
>>>>Patch 1 adds the generic CPPC hook and uses it from cppc_get_perf_ctrs().
>>>>Patch 2 implements the hook on arm64 by sampling both AMU counters in a
>>>>single operation on the target CPU.
>>>>
>>>>[1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
>>>>[2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>>>>
>>>>Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>>>>
>>>>Pengjie Zhang (2):
>>>> ACPI: CPPC: add paired FFH feedback-counter read hook
>>>> arm64: topology: read CPPC FFH feedback counters in one operation
>>>>
>>>> arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
>>>> drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
>>>> include/acpi/cppc_acpi.h | 7 ++++
>>>> 3 files changed, 127 insertions(+), 13 deletions(-)
>>>>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox