* [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
* Re: [PATCH v2 1/2] gpio: shared-proxy: always serialize with a sleeping mutex
From: Bartosz Golaszewski @ 2026-06-26 15:01 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-2-v@baodeep.com>
On Thu, 25 Jun 2026 13:57:17 +0200, Viacheslav Bocharov <v@baodeep.com> said:
> The shared GPIO descriptor used either a mutex or a spinlock, chosen at
> runtime from the underlying chip's can_sleep:
>
> shared_desc->can_sleep = gpiod_cansleep(shared_desc->desc);
> ... if (can_sleep) mutex_lock(); else spin_lock_irqsave();
>
> can_sleep describes only the value path (->get/->set). Under the same
> lock, however, the proxy may call gpiod_set_config() and
> gpiod_direction_*(), which can reach pinctrl paths that take a mutex
> (e.g. gpiod_set_config() -> gpiochip_generic_config() ->
> pinctrl_gpio_set_config()), independent of can_sleep. On a controller
> with non-sleeping MMIO value ops the descriptor lock was a spinlock, so
> the sleeping pinctrl call ran from atomic context. Reproduced on an
> Amlogic A113X board with the workaround from commit 28f240683871
> ("pinctrl: meson: mark the GPIO controller as sleeping") reverted; the
> original Khadas VIM3 report hit the same path:
>
> BUG: sleeping function called from invalid context
> __mutex_lock
> pinctrl_get_device_gpio_range
> pinctrl_gpio_set_config
> gpiochip_generic_config
> gpiod_set_config
> gpio_shared_proxy_set_config <- voting spinlock held
> ...
> mmc_pwrseq_simple_probe
>
> The spinlock existed to take the value vote from atomic context, but the
> vote and the (possibly sleeping) control operations share the same state
> and lock, so this scheme cannot serialize config under a mutex and still
> offer atomic value access. Always serialize the shared descriptor with a
> mutex instead and mark the proxy a sleeping gpiochip, driving the
> underlying GPIO through the cansleep value accessors: those are valid
> for both sleeping and non-sleeping chips, so value access keeps working
> on fast controllers, at the cost of no longer being atomic.
>
> This is observable: consumers gating on gpiod_cansleep() take their
> sleeping branch on a proxied GPIO (mmc-pwrseq-emmc skips its
> emergency-restart reset handler; its normal reset is unaffected), and
> consumers that reject sleeping GPIOs (pwm-gpio, ps2-gpio, ...) would
> fail to probe. Such atomic users do not share a pin through the proxy,
> whose purpose is voting on shared reset/enable lines. The same narrowing
> already applies on Amlogic since that workaround, and rockchip
> addressed the identical splat per-driver in commit 7ca497be0016 ("gpio:
> rockchip: Stop calling pinctrl for set_direction"); fixing the proxy
> addresses the locking error once, for every controller.
>
> The lock type was added by commit a060b8c511ab ("gpiolib: implement
> low-level, shared GPIO support"); the sleeping call under it arrived with
> the proxy driver.
>
> Fixes: e992d54c6f97 ("gpio: shared-proxy: implement the shared GPIO proxy driver")
> Reported-by: Marek Szyprowski <m.szyprowski@samsung.com>
> Closes: https://lore.kernel.org/all/00107523-7737-4b92-a785-14ce4e93b8cb@samsung.com/
> Signed-off-by: Viacheslav Bocharov <v@baodeep.com>
> ---
This looks good to me. Linus: do you want me to take patch 2/2 as well? I'll
send it for v7.2-rc2.
Bart
^ permalink raw reply
* RE: [PATCH v2 4/6] Drivers: hv: Mark shared memory as decrypted for CCA Realms
From: Michael Kelley @ 2026-06-26 15:04 UTC (permalink / raw)
To: Kameron Carr, Michael Kelley, kys@microsoft.com,
haiyangz@microsoft.com, wei.liu@kernel.org, decui@microsoft.com,
longli@microsoft.com
Cc: catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
lpieralisi@kernel.org, sudeep.holla@kernel.org, arnd@arndb.de,
thuth@redhat.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org
In-Reply-To: <000801dd055c$2e375050$8aa5f0f0$@linux.microsoft.com>
From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Friday, June 26, 2026 4:09 AM
>
> On Thursday, June 25, 2026 11:59 AM, Michael Kelley wrote:
> > From: Kameron Carr <kameroncarr@linux.microsoft.com> Sent: Thursday,
> > June 25, 2026 10:35 AM
> > > We need to round up the memory allocated for the input/output pages to
> > > the nearest PAGE_SIZE, since set_memory_decrypted() requires the size to
> > > be a multiple of PAGE_SIZE. This only has an effect on ARM VMs that are
> > > using PAGE_SIZE larger than 4K.
> >
> > I think this change resulted from a Sashiko comment. My understanding is
> > that the ARM CCA architecture only supports CCA guests with 4 KiB page
> > size. Is that still the case, or has that restriction been lifted in a later version
> > of the architecture? I'm in favor of handling the larger page sizes, if only for
> > future proofing. But I wondered whether your intent is to always support
> > > 4 KiB page sizes even if CCA doesn't support them now. Another way to
> > put it: In reviewing code, should I flag issues related to page sizes > 4 KiB?
>
> I think you might be right. I'm looking at RMM spec 2.0 beta 2, and the RMI
> can have granule size 4KB, 16KB, 64KB, but the RSI is restricted to granule size
> 4KB.
>
> I'm open to suggestion on best way to move forward.
The best approach probably depends on whether the 4 KiB restriction is
likely to be lifted in a future version of the CCA architecture, and I don't have
any insight into that.
If it is likely to be lifted, then doing the initial implementation to support
larger page sizes probably makes sense (which is what you've done here).
It's less work than going back and adding later. But the commit message
and/or code comments should indicate that the larger page size support
is future-proofing work, so that someone doesn't get the wrong idea that
it should work with larger page sizes now.
The alternate approach is to not do any larger page size support now,
and to explicitly state that the code is assuming the current restriction
of 4 KiB page size only.
Whichever approach is chosen should be used consistently so there's
not a mishmash.
>
> > > @@ -499,14 +500,16 @@ int hv_common_cpu_init(unsigned int cpu)
> > > }
> > >
> > > if (!ms_hyperv.paravisor_present &&
> > > - (hv_isolation_type_snp() || hv_isolation_type_tdx())) {
> > > - ret = set_memory_decrypted((unsigned long)mem, pgcount);
> > > + (hv_isolation_type_snp() || hv_isolation_type_tdx() ||
> > > + hv_isolation_type_cca())) {
> > > + ret = set_memory_decrypted((unsigned long)kasan_reset_tag(mem),
> > > + alloc_size >> PAGE_SHIFT);
> >
> > I don't know enough about KASAN or the tag situation on ARM64
> > to comment on this change. But this same sequence of allocating
> > memory and then decrypting it occurs in other places in Hyper-V
> > code. It seems like those places would also need the same
> > kasan_reset_tag() call.
>
> I'm not sure of the exact behavior of PAGE_END when there are
> KASAN tags, but it looks like tags could mess with the address
> comparison.
>
> I do see that __virt_to_phys_nodebug() and virt_addr_valid() in
> arch/arm64/include/asm/memory.h both reset tags before calling
> __is_lm_address().
>
> If there are many calls that follow this pattern, it may be better to
> add the tag reset in __set_memory_enc_dec().
I had the same thought.
>
> I can undo this change.
>
Unfortunately, I don't know whether undoing it is right or not. I
haven't taken the time to go learn about the whole scheme and its
implications.
Michael
^ permalink raw reply
* Re: [PATCH v4 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Leo Yan @ 2026-06-26 15:12 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6, shanghaoqiang,
Suzuki K Poulose, Mike Leach, James Clark, Tamas.Petz,
Michiel.VanTol
In-Reply-To: <20260618084726.1070022-1-jiangwen6@xiaomi.com>
On Thu, Jun 18, 2026 at 04:47:20PM +0800, Wen Jiang wrote:
> Besides accelerating the mapping path, this also enables large
> mappings (PMD and cont-PTE) for vmap, which are currently not
> supported.
I verified this series with large vmap() mappings for Arm trace buffer
units (TRBE and SPE), and the results are positive.
Arm trace buffer units use the CPU's page tables for address translation
when writing trace data to DRAM. The larger vmap() mapping granules
reduce TLB pressure, resulting in significantly fewer L2D TLB refills
and reduced L1D TLB refills. The decrease in dtlb_walk indicates that
fewer page table walks are required and that address translations are
more often satisfied by cached TLB entries.
The detailed results are included below for reference.
Thanks for working on this, and here is my test tag:
Tested-by: Leo Yan <leo.yan@arm.com>
P.s. I applied a local change to set PERF_PMU_CAP_AUX_PREFER_LARGE in
the CoreSight and SPE drivers to allocate large memory chunks. This
change will be sent out once the MM changes are agreed.
## Results with TRBE
Test command:
taskset -c 2 perf stat -C 10 -e cycles:u,instructions:u,dtlb_walk:u,l1d_tlb:u,l1d_tlb_refill:u,l2d_tlb_refill:u \
-- taskset -c 2 perf record -C 10 -m ,1G -e cs_etm// \
-- taskset -c 10 ./sparse_branch_delay.elf
The benchmark was run 5 times. CPU10 was isolated and dedicated to
running the workload while collecting the TLB statistics.
Before this series:
+----------------+--------+--------+--------+--------+--------+----------+
|TLB Metrics | Run1 | Run2 | Run3 | Run4 | Run5 | Avg. |
+----------------+--------+--------+--------+--------+--------+----------+
| dtlb_walk | 63 | 75 | 62 | 73 | 69 | 68.4 |
+----------------+--------+--------+--------+--------+--------+----------+
| l1d_tlb | 2093 | 2189 | 2237 | 2036 | 2086 | 2128.2 |
+----------------+--------+--------+--------+--------+--------+----------+
| l1d_tlb_refill | 154 | 153 | 150 | 165 | 157 | 155.8 |
+----------------+--------+--------+--------+--------+--------+----------+
| l2d_tlb_refill | 161325 | 161403 | 161432 | 161580 | 161439 | 161435.8 |
+----------------+--------+--------+--------+--------+--------+----------+
After this series:
+----------------+--------+--------+--------+--------+--------+----------+----------+
|TLB Metrics | Run1 | Run2 | Run3 | Run4 | Run5 | Avg. | Diff. |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| dtlb_walk | 67 | 59 | 60 | 58 | 53 | 59.4 | -13.16% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l1d_tlb | 6710 | 7120 | 6662 | 6626 | 6542 | 6732.0 | +216.32% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l1d_tlb_refill | 126 | 117 | 119 | 117 | 119 | 119.6 | -23.23% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l2d_tlb_refill | 506 | 489 | 485 | 506 | 489 | 495.0 | -99.69% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
## Results with SPE
Test command:
taskset -c 2 perf stat -C 10 -e cycles:u,instructions:u,dtlb_walk:u,l1d_tlb:u,l1d_tlb_refill:u,l2d_tlb_refill:u \
-- taskset -c 2 perf record -C 10 -m ,512M -e arm_spe_0/ts_enable=1,pa_enable=1,period=64,min_latency=0/ \
-- taskset -c 10 dd if=/dev/zero of=/dev/shm/dd_mem_test bs=1M count=1024 status=progress
The benchmark was run five times. CPU10 was isolated and dedicated to
running the workload while collecting the TLB statistics.
Before this series:
+----------------+--------+--------+--------+--------+--------+----------+
|TLB Metrics | Run1 | Run2 | Run3 | Run4 | Run5 | Avg. |
+----------------+--------+--------+--------+--------+--------+----------+
| dtlb_walk | 2090 | 1709 | 1679 | 1519 | 1555 | 1710.4 |
+----------------+--------+--------+--------+--------+--------+----------+
| l1d_tlb | 254450 | 257227 | 252517 | 252535 | 254752 | 254296.2 |
+----------------+--------+--------+--------+--------+--------+----------+
| l1d_tlb_refill | 16023 | 16088 | 15944 | 15989 | 15956 | 16000.0 |
+----------------+--------+--------+--------+--------+--------+----------+
| l2d_tlb_refill | 5887 | 4204 | 3713 | 4556 | 5620 | 4796.0 |
+----------------+--------+--------+--------+--------+--------+----------+
After this series:
+----------------+--------+--------+--------+--------+--------+----------+----------+
|TLB Metrics | Run1 | Run2 | Run3 | Run4 | Run5 | Avg. | Diff. |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| dtlb_walk | 1111 | 1301 | 1229 | 1166 | 1771 | 1315.6 | -23.08% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l1d_tlb | 257462 | 257420 | 257241 | 259968 | 261324 | 258683.0 | +1.73% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l1d_tlb_refill | 15954 | 15919 | 15948 | 15962 | 15968 | 15950.2 | -0.31% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
| l2d_tlb_refill | 2672 | 2558 | 2801 | 2478 | 4147 | 2931.2 | -38.88% |
+----------------+--------+--------+--------+--------+--------+----------+----------+
^ 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