* [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
* 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
* 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
* [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 v2] irqchip/gic-v3-its: Fix OF node reference leak
From: Marc Zyngier @ 2026-06-26 13:41 UTC (permalink / raw)
To: Yuho Choi; +Cc: Thomas Gleixner, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626033747.1515585-1-dbgh9129@gmail.com>
On Fri, 26 Jun 2026 04:37:47 +0100,
Yuho Choi <dbgh9129@gmail.com> wrote:
>
> of_get_cpu_node() returns a referenced device node. In
> its_cpu_init_collection(), the Cavium 23144 workaround only uses the
> node to compare the CPU NUMA node, but the reference is never dropped.
>
> Use the device_node cleanup helper for the CPU node reference so it is
> released when leaving the workaround block, including the NUMA mismatch
> return path.
>
> Fixes: fbf8f40e1658 ("irqchip/gicv3-its: numa: Enable workaround for Cavium thunderx erratum 23144")
> Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
> ---
> - Use __free(device_node) for the CPU node reference.
> - Correct the Fixes tag to fbf8f40e1658.
>
> drivers/irqchip/irq-gic-v3-its.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
> index b57d81ad33a0..63942cf1dbe3 100644
> --- a/drivers/irqchip/irq-gic-v3-its.c
> +++ b/drivers/irqchip/irq-gic-v3-its.c
> @@ -3290,9 +3290,9 @@ static void its_cpu_init_collection(struct its_node *its)
>
> /* avoid cross node collections and its mapping */
> if (its->flags & ITS_FLAGS_WORKAROUND_CAVIUM_23144) {
> - struct device_node *cpu_node;
> + struct device_node *cpu_node __free(device_node) =
> + of_get_cpu_node(cpu, NULL);
Please keep this on a single line. I find nothing more irritating than
these split assignments.
>
> - cpu_node = of_get_cpu_node(cpu, NULL);
> if (its->numa_node != NUMA_NO_NODE &&
> its->numa_node != of_node_to_nid(cpu_node))
> return;
Worth taking this opportunity to fix the indentation here.
With these two nits addressed:
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* [GIT PULL] KVM/arm64 fixes for 7.2, take #1
From: Marc Zyngier @ 2026-06-26 13:35 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Bradley Morgan, Fuad Tabba, Hyunwoo Kim, Oliver Upton,
Weiming Shi, Will Deacon, Xuanqing Shi, Zhong Wang, Steffen Eiden,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, kvmarm, kvm,
linux-arm-kernel
Paolo,
As predicted, here's another largeish set of fixes for KVM/arm64. A
bunch of them are fairly benign (the PSTATE.IL stuff), but some are
pretty annoying (vgic, MOPS) and are stable material.
On the bright side, Fuad has volunteered to be an official reviewer.
We really need people to engage with the reviewing process instead of
simply dumping patches on us, as me and Oliver really can't be
stretched much further. So many thanks Fuad for offering to help.
I expect to be back next week with a similar delivery, as my Inbox
keeps filling with this stuff...
Please pull,
M.
The following changes since commit 1ee27dacbe5dc4def481794d899d67b0d4570094:
Merge branch kvm-arm64/nv-mmu-7.2 into kvmarm-master/next (2026-06-12 09:29:34 +0100)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.2-1
for you to fetch changes up to d098bb75d14fde2f12155f1a95ec0168160867ce:
KVM: arm64: account pKVM reclaim against the VM mm (2026-06-22 10:48:08 +0100)
----------------------------------------------------------------
KVM/arm64 fixes for 7.2, take #1
- Fix an accounting buglet when reclaiming pages from a protected
guest
- Fix a bunch of architectural compliance issues when injecting a
synthesised exception, most of which were missing the PSTATE.IL bit
indicating a 32bit-wide instruction
- Another set of fixes addressing issues with translation of VNCR_EL2,
including corner cases where the guest point that register at a RO
page...
- Don't warn when trapping accesses to ZCR_EL2 from an L2 guest, as
that's not unexpected at all
- Address a bunch of races with LPI migration vs LPIs being disabled
- Fix a total howler of a bug combining FEAT_MOPS and NV, resulting in
exception returning in the wrong place...
- Coerce Fuad Tabba into a reviewer role, and may his Inbox catch
fire!
----------------------------------------------------------------
Bradley Morgan (1):
KVM: arm64: account pKVM reclaim against the VM mm
Fuad Tabba (11):
KVM: arm64: nv: Write ESR_EL2 for injected nested SError exceptions
KVM: arm64: Sync SPSR_EL1 when injecting an exception into a pVM
KVM: arm64: nv: Fix PSTATE construction on illegal exception return
KVM: arm64: Add Fuad Tabba as a reviewer
KVM: arm64: Set ESR_ELx.IL for injected undefined exceptions at EL2
KVM: arm64: Unconditionally set IL for injected undefined exceptions
KVM: arm64: Unconditionally set IL for injected abort exceptions
KVM: arm64: Set IL for injected FPAC exceptions during ERET emulation
KVM: arm64: Set IL for emulated SError injection
KVM: arm64: Set IL for nested SError injection
KVM: arm64: Set IL in fake ESR for pKVM memory sharing exit
Hyunwoo Kim (1):
KVM: arm64: vgic: Check the interrupt is still ours before migrating it
Marc Zyngier (1):
KVM: arm64: vgic: Handle race between interrupt affinity change and LPI disabling
Oliver Upton (6):
KVM: arm64: nv: Drop bogus WARN for write to ZCR_EL2
KVM: arm64: nv: Respect read-only PFN when mapping L1 VNCR
KVM: arm64: nv: Inject SEA if kvm_translate_vncr() can't resolve PFN
KVM: arm64: nv: Re-translate VNCR before injecting abort
KVM: arm64: nv: Inject SEA if guest VNCR isn't normal memory
KVM: arm64: nv: Mark VM as bugged for unexpected VNCR abort
Weiming Shi (1):
KVM: arm64: nv: Fix SPSR_EL2 restore in kvm_hyp_handle_mops()
MAINTAINERS | 1 +
arch/arm64/include/asm/kvm_nested.h | 8 ++
arch/arm64/kvm/at.c | 8 --
arch/arm64/kvm/emulate-nested.c | 37 +++++--
arch/arm64/kvm/hyp/include/hyp/switch.h | 11 ++-
arch/arm64/kvm/hyp/nvhe/pkvm.c | 3 +-
arch/arm64/kvm/hyp/nvhe/sys_regs.c | 3 +-
arch/arm64/kvm/inject_fault.c | 18 +---
arch/arm64/kvm/nested.c | 164 ++++++++++++++++----------------
arch/arm64/kvm/pkvm.c | 2 +-
arch/arm64/kvm/vgic/vgic.c | 20 ++--
11 files changed, 149 insertions(+), 126 deletions(-)
^ permalink raw reply
* [PATCH] fix: drm/mediatek: mtk_drm_probe: of_node_get in loop overwrites previous node references without release
From: WenTao Liang @ 2026-06-26 13:28 UTC (permalink / raw)
To: chunkuang.hu, p.zabel, airlied, simona, matthias.bgg,
angelogioacchino.delregno
Cc: dri-devel, linux-mediatek, linux-kernel, linux-arm-kernel,
WenTao Liang, stable
In the for_each_child_of_node loop, private->comp_node[comp_id] and
private->mutex_node are assigned via of_node_get without first releasing
any previously stored reference for the same index. When the same comp_id
or mmsys_id matches multiple nodes, earlier node references are
overwritten and permanently leaked.
Cc: stable@vger.kernel.org
Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support")
Signed-off-by: WenTao Liang <vulab@iscas.ac.cn>
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index c86a3f54f35b..2c0d8db9ade2 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -1138,6 +1138,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
id = of_alias_get_id(node, "mutex");
if (id < 0 || id == private->data->mmsys_id) {
+ of_node_put(private->mutex_node);
private->mutex_node = of_node_get(node);
dev_dbg(dev, "get mutex for mmsys %d", private->data->mmsys_id);
}
@@ -1153,7 +1154,7 @@ static int mtk_drm_probe(struct platform_device *pdev)
if (!mtk_drm_find_mmsys_comp(private, comp_id))
continue;
-
+ of_node_put(private->comp_node[comp_id]);
private->comp_node[comp_id] = of_node_get(node);
/*
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* Re: [PATCH v2 6/8] arm64: dts: qcom: Convert to new media orientation definitions
From: Vladimir Zapolskiy @ 2026-06-26 13:22 UTC (permalink / raw)
To: Kieran Bingham, 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,
Laurent Pinchart, 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
Cc: 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 6/26/26 15:07, 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>
> ---
> 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 {
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 3/8] dt-bindings: media: i2c: Utilise video-interface-devices enums
From: Vladimir Zapolskiy @ 2026-06-26 13:22 UTC (permalink / raw)
To: Kieran Bingham, 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,
Laurent Pinchart, 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
Cc: 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 6/26/26 15:07, 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>
> ---
> 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 {
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 2/8] media: dt-bindings: video-interface-devices: add video-interface-devices.h references
From: Vladimir Zapolskiy @ 2026-06-26 13:21 UTC (permalink / raw)
To: Kieran Bingham, 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,
Laurent Pinchart, 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
Cc: 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>
On 6/26/26 15:07, 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.
> +
> $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
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: media: Add macros for video interface devices
From: Vladimir Zapolskiy @ 2026-06-26 13:21 UTC (permalink / raw)
To: Kieran Bingham, 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,
Laurent Pinchart, 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
Cc: linux-kernel, linux-media, devicetree, linux-tegra, linux, imx,
linux-arm-kernel, linux-arm-msm, linux-renesas-soc,
linux-rockchip, Conor Dooley
In-Reply-To: <20260626-kbingham-orientation-v2-1-47178be927b4@ideasonboard.com>
On 6/26/26 15:07, Kieran Bingham wrote:
> Add a new dt-bindings/media/video-interface-devices.h header that
> defines macros corresponding to the orientation enumeration types from
> media/video-interface-devices.yaml.
>
> This allows avoiding hardcoded constants in device tree sources.
>
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Signed-off-by: Kieran Bingham <kieran.bingham@ideasonboard.com>
> ---
> include/dt-bindings/media/video-interface-devices.h | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/include/dt-bindings/media/video-interface-devices.h b/include/dt-bindings/media/video-interface-devices.h
> new file mode 100644
> index 000000000000..d2340b457292
> --- /dev/null
> +++ b/include/dt-bindings/media/video-interface-devices.h
> @@ -0,0 +1,13 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR MIT) */
> +/*
> + * Copyright (C) 2026 Kieran Bingham <kieran.bingham@ideasonboard.com>
> + */
> +
> +#ifndef __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
> +#define __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__
> +
> +#define MEDIA_ORIENTATION_FRONT 0
> +#define MEDIA_ORIENTATION_BACK 1
> +#define MEDIA_ORIENTATION_EXTERNAL 2
> +
> +#endif /* __DT_BINDINGS_MEDIA_VIDEO_INTERFACE_DEVICES_H__ */
>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v4 00/32] pinctrl: mediatek: Enable module build support for all drivers
From: Linus Walleij @ 2026-06-26 13:17 UTC (permalink / raw)
To: Justin Yeh, Luca Leonardo Scorcia
Cc: Sean Wang, Matthias Brugger, AngeloGioacchino Del Regno,
Project_Global_Chrome_Upstream_Group, linux-mediatek, linux-gpio,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260626040112.2436185-1-justin.yeh@mediatek.com>
Hi Justin,
thanks for your patches!
On Fri, Jun 26, 2026 at 6:01 AM Justin Yeh <justin.yeh@mediatek.com> wrote:
> Sorry for the quick v4 - v3 was sent with an incomplete cover letter
> (template placeholders) by mistake. This v4 also unifies MODULE_LICENSE
> to consistently use "GPL v2" across all patches.
>
> This series enables all MediaTek pinctrl drivers to be built as loadable
> kernel modules. This is required for Android GKI (Generic Kernel Image) +
> vendor_dlkm deployments where vendor-specific drivers must be kept separate
> from the GKI vmlinux.
>
> Each patch adds MODULE_LICENSE("GPL v2") and MODULE_DESCRIPTION() macros where
> missing, and changes the Kconfig option from bool to tristate. This allows
> these drivers to be properly packaged as vendor kernel modules while
> maintaining the existing built-in option.
Two things to fix:
1. Squash all these 32 patches into one, "one technical step". We don't wanna
have to revery 32 patches, if this doesn't work on one driver it doesn't work
on any driver.
2. Consider this Sashiko report on an unrelated patch by Luca:
https://lore.kernel.org/linux-input/20260621083053.A3B641F000E9@smtp.kernel.org/
----8<----------8<--------8<----------8<--------
[Severity: High]
This is a pre-existing issue, but does mtk_pinctrl_driver in
drivers/pinctrl/mediatek/pinctrl-mt6397.c need a .remove callback or
suppress_bind_attrs set to true to prevent unbinding?
In drivers/pinctrl/mediatek/pinctrl-mtk-common.c:mtk_pctrl_init(), the driver
allocates the pctl and pctl->chip structures using devm_kzalloc() but
registers the GPIO chip using the unmanaged gpiochip_add_data() API:
mtk_pctrl_init() {
...
pctl->chip = devm_kzalloc(&pdev->dev, sizeof(*pctl->chip), GFP_KERNEL);
...
ret = gpiochip_add_data(pctl->chip, pctl);
...
}
If the driver is unbound via sysfs, the devm_ subsystem will free the memory
backing the GPIO chip while it remains registered with the core subsystem.
Could this lead to a use-after-free if the GPIOs are accessed after the
driver is unbound?
----8<----------8<--------8<----------8<--------
Well now we will unbind the driver by rmmod as well, so this needs fixing.
Please prepend a patch fixing this to the series.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 2/3] dmaengine: xilinx_dma: Enable transfer chaining for AXIDMA and MCDMA by removing idle restriction
From: Folker Schwesinger @ 2026-06-26 13:00 UTC (permalink / raw)
To: Suraj Gupta, vkoul, Frank.Li, michal.simek
Cc: dmaengine, linux-arm-kernel, linux-kernel
In-Reply-To: <20260626092656.1563871-3-suraj.gupta2@amd.com>
On Fri Jun 26, 2026 at 11:26 AM CEST, Suraj Gupta wrote:
> Relax the idle check in xilinx_dma_start_transfer() and
> xilinx_mcdma_start_transfer() that prevented new transfers from being
> queued when the channel was busy, so scatter-gather transfers can be
> chained onto an in-flight transfer.
>
> In scatter-gather mode, only update the CURDESC register when the active
> list is empty to avoid interfering with transfers already in progress.
> When the active list contains transfers, the hardware tail pointer
> extension mechanism handles chaining automatically via the descriptor
> next pointer chain, which is set up at channel allocation and preserved
> across descriptor recycling.
>
> Direct (non-SG) mode has no descriptor queue: writing the BTT register
> launches a transfer immediately, so a new transfer must not be programmed
> while one is in flight. Keep those transfers serialized by retaining the
> idle check on the non-SG path. MCDMA always operates in scatter-gather
> mode, so it is unaffected.
>
> Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com>
> Co-developed-by: Srinivas Neeli <srinivas.neeli@amd.com>
> Signed-off-by: Srinivas Neeli <srinivas.neeli@amd.com>
For the AXIDMA SG-path:
Tested-by: Folker Schwesinger <dev@folker-schwesinger.de>
> ---
> drivers/dma/xilinx/xilinx_dma.c | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/dma/xilinx/xilinx_dma.c b/drivers/dma/xilinx/xilinx_dma.c
> index ca396b709742..6e7b183cb499 100644
> --- a/drivers/dma/xilinx/xilinx_dma.c
> +++ b/drivers/dma/xilinx/xilinx_dma.c
> @@ -1580,7 +1580,14 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
> return;
> }
>
> - if (!chan->idle)
> + /*
> + * Direct (non-SG) mode has no descriptor queue: writing the BTT
> + * register launches a transfer immediately, so a new transfer must
> + * not be programmed while one is in flight. Keep such transfers
> + * serialized. SG mode supports chaining onto a running transfer via
> + * tail-pointer extension, so it is allowed to proceed when busy.
> + */
> + if (!chan->has_sg && !chan->idle)
> return;
>
> head_desc = list_first_entry(&chan->pending_list,
> @@ -1599,7 +1606,7 @@ static void xilinx_dma_start_transfer(struct xilinx_dma_chan *chan)
> dma_ctrl_write(chan, XILINX_DMA_REG_DMACR, reg);
> }
>
> - if (chan->has_sg)
> + if (chan->has_sg && list_empty(&chan->active_list))
> xilinx_write(chan, XILINX_DMA_REG_CURDESC,
> head_desc->async_tx.phys);
> reg &= ~XILINX_DMA_CR_DELAY_MAX;
> @@ -1660,9 +1667,6 @@ static void xilinx_mcdma_start_transfer(struct xilinx_dma_chan *chan)
> if (chan->err)
> return;
>
> - if (!chan->idle)
> - return;
> -
> if (list_empty(&chan->pending_list))
> return;
>
> @@ -1685,8 +1689,9 @@ static void xilinx_mcdma_start_transfer(struct xilinx_dma_chan *chan)
> dma_ctrl_write(chan, XILINX_MCDMA_CHAN_CR_OFFSET(chan->tdest), reg);
>
> /* Program current descriptor */
> - xilinx_write(chan, XILINX_MCDMA_CHAN_CDESC_OFFSET(chan->tdest),
> - head_desc->async_tx.phys);
> + if (chan->has_sg && list_empty(&chan->active_list))
> + xilinx_write(chan, XILINX_MCDMA_CHAN_CDESC_OFFSET(chan->tdest),
> + head_desc->async_tx.phys);
>
> /* Program channel enable register */
> reg = dma_ctrl_read(chan, XILINX_MCDMA_CHEN_OFFSET);
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Update maintainer and git tree for CIX SoC
From: Arnd Bergmann @ 2026-06-26 13:03 UTC (permalink / raw)
To: Gary Yang
Cc: Fugang . duan, linux-arm-kernel, cix-kernel-upstream, Peter Chen
In-Reply-To: <20260626092015.1709904-1-gary.yang@cixtech.com>
On Fri, Jun 26, 2026, at 11:20, Gary Yang wrote:
> Peter Chen has left CIX Technology. Take over maintenance of the CIX SoC
> and Update the git tree URL accordingly.
>
> Signed-off-by: Gary Yang <gary.yang@cixtech.com>
> Reviewed-by: Fugang Duan <fugang.duan@cixtech.com>
This obviously needs an Ack from Peter. I assume he's ok with the
change, but you should document that since maintainership
is tied to the person by default rather than their employer.
I've added peter.chen@kernel.org to Cc, hopefully this forwards
to a current address.
Arnd
> ---
> MAINTAINERS | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2fb1c75afd16..17b3704bbcde 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2692,12 +2692,12 @@ F: arch/arm/mach-ep93xx/
> F: drivers/iio/adc/ep93xx_adc.c
>
> ARM/CIX SOC SUPPORT
> -M: Peter Chen <peter.chen@cixtech.com>
> +M: Gary Yang <gary.yang@cixtech.com>
> M: Fugang Duan <fugang.duan@cixtech.com>
> R: CIX Linux Kernel Upstream Group <cix-kernel-upstream@cixtech.com>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> -T: git git://git.kernel.org/pub/scm/linux/kernel/git/peter.chen/cix.git
> +T: git https://github.com/cixtech/linux-mainline.git
> F: Documentation/devicetree/bindings/arm/cix.yaml
> F: Documentation/devicetree/bindings/mailbox/cix,sky1-mbox.yaml
> F: arch/arm64/boot/dts/cix/
> --
> 2.50.1
^ permalink raw reply
* Re: [PATCH] arm64: mm: refresh stale pmd snapshot after split_contpmd()
From: Dev Jain @ 2026-06-26 13:03 UTC (permalink / raw)
To: lirongqing, Catalin Marinas, Will Deacon, Ryan Roberts,
Ard Biesheuvel, David Hildenbrand, Anshuman Khandual,
Kevin Brodsky, Yang Shi, Chaitanya S Prakash, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260625113953.2332-1-lirongqing@baidu.com>
On 25/06/26 5:09 pm, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> split_contpmd() modifies the pmd entries in-place by clearing the CONT
> bit, but the local 'pmd' variable still holds the old snapshot with CONT
> set. The subsequent split_pmd() call uses this stale value to derive the
> pgprot for the new PTE entries via pmd_pgprot(), causing the resulting
> PTEs to be populated with incorrect protection bits.
Since the block was CONTPMD, it means the pgprot was uniform on that block,
so after splitting, it should be safe to derive the pgprot from individual pmd's
right?
>
> Fix this by re-reading the pmd from memory after split_contpmd() returns
> in both call sites: split_kernel_leaf_mapping_locked() and
> split_to_ptes_pmd_entry().
>
> Fixes: a166563e7ec3 ("arm64: mm: support large block mapping when rodata=full")
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> arch/arm64/mm/mmu.c | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 12e862c..e510336 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -746,8 +746,10 @@ static int split_kernel_leaf_mapping_locked(unsigned long addr)
> if (!pmd_present(pmd))
> goto out;
> if (pmd_leaf(pmd)) {
> - if (pmd_cont(pmd))
> + if (pmd_cont(pmd)) {
> split_contpmd(pmdp);
> + pmd = pmdp_get(pmdp);
> + }
> /*
> * PMD: If addr is PMD aligned then addr already describes a
> * leaf boundary. Otherwise, split to contpte.
> @@ -891,8 +893,10 @@ static int split_to_ptes_pmd_entry(pmd_t *pmdp, unsigned long addr,
> int ret = 0;
>
> if (pmd_leaf(pmd)) {
> - if (pmd_cont(pmd))
> + if (pmd_cont(pmd)) {
> split_contpmd(pmdp);
> + pmd = pmdp_get(pmdp);
> + }
> ret = split_pmd(pmdp, pmd, gfp, false);
>
> /*
^ permalink raw reply
* [PATCH 5.15.y] selftests: arm64: signal: skip SVE VL change test with single VL
From: Yijia Wang @ 2026-06-26 12:59 UTC (permalink / raw)
To: sashal, stable, gregkh
Cc: shuah, linux-kernel, will, catalin.marinas, broonie,
linux-arm-kernel, linux-kselftest, cristian.marussi, Yijia Wang
[ Upstream commit 78c09c0f4df89fabdcfb3e5e53d3196cf67f64ef ]
The fake_sigreturn_sve_change_vl test needs at least two SVE vector
lengths so it can attempt to modify the VL in a signal frame. On systems
that support SVE but expose only one VL, the test initialization returns
false and the signal test harness reports the case as a failure.
Mark the testcase result as KSFT_SKIP before returning false when fewer
than two VLs are available. This preserves the old bool init callback
contract while reporting the unsupported configuration correctly.
This is a minimal backport of the behavior used by newer selftests, where
the same single-VL configuration is reported as SKIP instead of FAIL. The
5.15.y selftest still uses a bool init callback here, so keep returning
false after setting td->result to KSFT_SKIP.
Signed-off-by: Yijia Wang <wangyijia.yeah@bytedance.com>
---
.../selftests/arm64/signal/testcases/fake_sigreturn_sve_change_vl.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_sve_change_vl.c b/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_sve_change_vl.c
index bb50b5adb..915821375 100644
--- a/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_sve_change_vl.c
+++ b/tools/testing/selftests/arm64/signal/testcases/fake_sigreturn_sve_change_vl.c
@@ -6,6 +6,7 @@
* supported and is expected to segfault.
*/
+#include <kselftest.h>
#include <signal.h>
#include <ucontext.h>
#include <sys/prctl.h>
@@ -40,6 +41,7 @@ static bool sve_get_vls(struct tdescr *td)
/* We need at least two VLs */
if (nvls < 2) {
fprintf(stderr, "Only %d VL supported\n", nvls);
+ td->result = KSFT_SKIP;
return false;
}
---
base-commit: eceeec79dbc646d6dace49ed1ba2f656683d5537
change-id: 20260626-b4-arm64-515-preview-clean-9408c3dbd320
Best regards,
--
Yijia Wang <wangyijia.yeah@bytedance.com>
^ permalink raw reply related
* Re: [PATCH 2/2] iio: adc: Add Nuvoton MA35D1 EADC driver
From: Andy Shevchenko @ 2026-06-26 12:54 UTC (permalink / raw)
To: Chi-Wen Weng
Cc: jic23, robh, krzk+dt, conor+dt, dlechner, nuno.sa, andy,
linux-arm-kernel, linux-iio, devicetree, linux-kernel, cwweng
In-Reply-To: <20260625110638.38438-3-cwweng.linux@gmail.com>
On Thu, Jun 25, 2026 at 07:06:38PM +0800, Chi-Wen Weng wrote:
> Add an IIO driver for the Nuvoton MA35D1 Enhanced ADC controller.
>
> The driver supports direct raw reads and triggered buffered capture. The
> controller end-of-conversion interrupt is exposed as the device trigger
> and is used to push samples into the IIO buffer.
>
> Channels are described by firmware child nodes and can be configured as
> single-ended or differential inputs. Since the differential enable bit is
> global, mixed single-ended and differential buffered scans are rejected.
>
> DMA support is intentionally not included in this initial upstream driver;
> conversions are handled through the interrupt-driven path.
Nice written driver, some small issues here and there, and I think in a couple
of versions it will stabilize and can be accepted.
...
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
No need, bitmap.h covers this.
> +#include <linux/bitmap.h>
> +#include <linux/clk.h>
> +#include <linux/completion.h>
> +#include <linux/device.h>
No need, covered by platform_device.h.
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
No way this header should be in the mere drivers.
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/mutex.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm.h>
> +#include <linux/property.h>
Also missing some headers, such as types.h.
...
> +#define MA35D1_EADC_TIMEOUT msecs_to_jiffies(1000)
+ jiffies.h
...
> +static inline u32 ma35d1_adc_read(struct ma35d1_adc *adc, u32 reg)
> +{
> + return readl(adc->regs + reg);
> +}
> +
> +static inline void ma35d1_adc_write(struct ma35d1_adc *adc, u32 reg, u32 val)
> +{
> + writel(val, adc->regs + reg);
> +}
> +
> +static void ma35d1_adc_rmw(struct ma35d1_adc *adc, u32 reg, u32 mask, u32 val)
Name it _update() to be aligned with the _read() and _write() above.
> +{
> + u32 tmp;
> +
> + tmp = ma35d1_adc_read(adc, reg);
> + tmp &= ~mask;
> + tmp |= val;
Correct pattern is to use
tmp = (tmp & ~mask) | (val & mask);
> + ma35d1_adc_write(adc, reg, tmp);
> +}
...
> +static void ma35d1_adc_config_sample(struct ma35d1_adc *adc,
> + unsigned int sample, unsigned int channel)
> +{
> + u32 reg = MA35D1_EADC_SCTL(sample);
I don't see the need of this variable, use the value directly.
> + ma35d1_adc_rmw(adc, reg,
> + MA35D1_EADC_SCTL_CHSEL_MASK |
> + MA35D1_EADC_SCTL_TRGSEL_MASK,
> + FIELD_PREP(MA35D1_EADC_SCTL_CHSEL_MASK, channel) |
> + MA35D1_EADC_SCTL_TRGSEL_ADINT0);
> +}
...
> +static irqreturn_t ma35d1_adc_trigger_handler(int irq, void *p)
> +{
> + struct iio_poll_func *pf = p;
> + struct iio_dev *indio_dev = pf->indio_dev;
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + for (i = 0; i < adc->scan_chancnt; i++)
for (unsigned int i = 0; i < adc->scan_chancnt; i++)
> + adc->scan.channels[i] =
> + ma35d1_adc_read(adc, MA35D1_EADC_DAT(i)) &
> + MA35D1_EADC_DAT_MASK;
> +
> + iio_push_to_buffers_with_timestamp(indio_dev, &adc->scan, pf->timestamp);
> + iio_trigger_notify_done(adc->trig);
> +
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + return IRQ_HANDLED;
> +}
...
> +static int ma35d1_adc_validate_scan(struct iio_dev *indio_dev,
> + const unsigned long *scan_mask)
> +{
> + const struct iio_chan_spec *chan;
> + bool have_single = false;
> + bool have_diff = false;
> + unsigned int count = 0;
> + unsigned long bit;
> +
> + for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
> + chan = &indio_dev->channels[bit];
> +
> + if (chan->type == IIO_TIMESTAMP)
> + continue;
> + count++;
Make it last in the loop, it will be standard pattern. Otherwise it's hard to
read and find. Also it's recommended to split assignment and definition
for better maintenance.
unsigned int count;
...
count = 0;
for_each_set_bit(bit, scan_mask, indio_dev->masklength) {
...
count++;
}
> + if (chan->differential)
> + have_diff = true;
> + else
> + have_single = true;
> + }
> +
> + if (!count || count > MA35D1_EADC_MAX_SAMPLE_MODULES)
> + return -EINVAL;
> + if (have_single && have_diff)
> + return -EINVAL;
Is it possible IRL?
> + return 0;
> +}
...
> +static int ma35d1_adc_buffer_postenable(struct iio_dev *indio_dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + if (!adc->scan_chancnt)
> + return -EINVAL;
> +
> + ma35d1_adc_write(adc, MA35D1_EADC_STATUS2, MA35D1_EADC_STATUS2_ADIF0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_INTSRC0,
> + MA35D1_EADC_INTSRC0_ADINT0,
> + MA35D1_EADC_INTSRC0_ADINT0);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_REFADJCTL,
> + MA35D1_EADC_REFADJCTL_EXT_VREF,
> + MA35D1_EADC_REFADJCTL_EXT_VREF);
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SELSMP0, GENMASK(1, 0), 3);
> + ma35d1_adc_set_diff(adc, adc->scan_differential);
> + for (i = 0; i < adc->scan_chancnt; i++)
for (unsigned int i = 0; i < adc->scan_chancnt; i++)
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
> + MA35D1_EADC_SCTL_TRGDLY_MASK,
> + MA35D1_EADC_SCTL_TRGDLY_MASK);
> +
> + ma35d1_adc_rmw(adc, MA35D1_EADC_CTL, MA35D1_EADC_CTL_ADCIEN0,
> + MA35D1_EADC_CTL_ADCIEN0);
> + ma35d1_adc_write(adc, MA35D1_EADC_SWTRG, 1);
> +
> + return 0;
> +}
> +
> +static int ma35d1_adc_buffer_predisable(struct iio_dev *indio_dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + int i;
> +
> + ma35d1_adc_disable_irq(adc);
> + for (i = 0; i < adc->scan_chancnt; i++)
> + ma35d1_adc_rmw(adc, MA35D1_EADC_SCTL(i),
> + MA35D1_EADC_SCTL_TRGSEL_MASK, 0);
Ditto.
Also looking to the cases of setting 0s, I would rather have a helper
_set_bits() / _clear_bits() in conjunction with _update().
> + return 0;
> +}
...
> +static void ma35d1_adc_init_channel(struct ma35d1_adc *adc,
> + struct iio_chan_spec *chan, u32 vinp,
> + u32 vinn, int scan_index, bool differential)
> +{
> + char *name = adc->chan_name[vinp];
> +
> + chan->type = IIO_VOLTAGE;
> + chan->indexed = 1;
> + chan->channel = vinp;
> + chan->address = vinp;
> + chan->scan_index = scan_index;
> + chan->info_mask_separate = BIT(IIO_CHAN_INFO_RAW);
> + chan->scan_type.sign = 'u';
> + chan->scan_type.realbits = 12;
> + chan->scan_type.storagebits = 16;
> + chan->scan_type.endianness = IIO_CPU;
> +
> + if (differential) {
> + chan->differential = 1;
> + chan->channel2 = vinn;
> + snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d-in%d", vinp,
> + vinn);
Can compiler prove the buffer size is enough?
> + } else {
> + snprintf(name, MA35D1_EADC_CHAN_NAME_LEN, "in%d", vinp);
> + }
> +
> + chan->datasheet_name = name;
Why not use devm_kasprintf() instead?
> +}
...
> +static int ma35d1_adc_parse_channels(struct iio_dev *indio_dev,
> + struct device *dev)
> +{
> + struct ma35d1_adc *adc = iio_priv(indio_dev);
> + DECLARE_BITMAP(used_channels, MA35D1_EADC_MAX_CHANNELS);
> + struct fwnode_handle *child;
> + struct iio_chan_spec *channels;
> + int num_channels;
> + int scan_index = 0;
> + int ret;
> +
> + bitmap_zero(used_channels, MA35D1_EADC_MAX_CHANNELS);
> +
> + num_channels = device_get_child_node_count(dev);
> + if (!num_channels)
> + return dev_err_probe(dev, -ENODATA,
> + "no ADC channels configured\n");
> +
> + if (num_channels > MA35D1_EADC_MAX_CHANNELS)
Perhaps >= ?
> + return dev_err_probe(dev, -EINVAL, "too many ADC channels\n");
> +
> + channels = devm_kcalloc(dev, num_channels + 1, sizeof(*channels),
> + GFP_KERNEL);
> + if (!channels)
> + return -ENOMEM;
> +
> + device_for_each_child_node(dev, child) {
Use _scoped() variant.
> + u32 diff[2];
> + u32 reg;
> + bool differential = false;
> +
> + ret = fwnode_property_read_u32(child, "reg", ®);
> + if (ret) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, ret,
> + "missing channel reg property\n");
> + }
> +
> + if (reg >= MA35D1_EADC_MAX_CHANNELS) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "invalid ADC channel %u\n", reg);
> + }
> +
> + if (test_and_set_bit(reg, used_channels)) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "duplicate ADC channel %u\n", reg);
> + }
> +
> + if (fwnode_property_present(child, "diff-channels")) {
> + ret = fwnode_property_read_u32_array(child,
> + "diff-channels",
> + diff,
> + ARRAY_SIZE(diff));
> + if (ret) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, ret,
> + "invalid diff-channels for channel %u\n",
> + reg);
> + }
> +
> + if (diff[0] != reg ||
> + diff[1] >= MA35D1_EADC_MAX_CHANNELS ||
> + diff[0] == diff[1]) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "invalid differential ADC channel %u-%u\n",
> + diff[0], diff[1]);
> + }
> +
> + if (test_and_set_bit(diff[1], used_channels)) {
> + fwnode_handle_put(child);
> + return dev_err_probe(dev, -EINVAL,
> + "ADC channel %u already used\n",
> + diff[1]);
> + }
> +
> + differential = true;
> + }
> +
> + ma35d1_adc_init_channel(adc, &channels[scan_index], reg,
> + differential ? diff[1] : 0,
> + scan_index, differential);
> + scan_index++;
> + }
> +
> + channels[scan_index] = (struct iio_chan_spec)
> + IIO_CHAN_SOFT_TIMESTAMP(scan_index);
> +
> + indio_dev->channels = channels;
> + indio_dev->num_channels = scan_index + 1;
> + indio_dev->masklength = indio_dev->num_channels;
> +
> + return 0;
> +}
...
> + ret = devm_request_irq(dev, irq, ma35d1_adc_isr, 0, dev_name(dev),
> + indio_dev);
Make it a single line, here it's fine.
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to request IRQ %d\n", irq);
Remove duplicate error message.
...
> + ret = devm_iio_triggered_buffer_setup(dev, indio_dev,
> + iio_pollfunc_store_time,
> + ma35d1_adc_trigger_handler,
> + &ma35d1_adc_buffer_ops);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "failed to setup triggered buffer\n");
So, it seems this is very rarely can be not -ENOMEM, and hence it's 99.99% dead
code, just
return ret;
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] RFC: ARM: breakpoint: CFI breakpoints only on demand
From: Linus Walleij @ 2026-06-26 12:48 UTC (permalink / raw)
To: Russell King, Nathan Chancellor, Sami Tolvanen, Kees Cook,
Russell King (Oracle)
Cc: linux-arm-kernel, linux-kernel, stable, slipher, Linus Walleij
This removes the stub hw_breakpoint_cfi_handler() from ARM, making
it not steal breakpoint type 0x03 (ARM_ENTRY_CFI_BREAKPOINT) unless
CFI is actively used in the kernel.
When not instrumenting with CFI, we fall through to return 1 from
hw_breakpoint_pending() "unhandled fault" so userspace can make use
of this breakpoint.
This of course does not work if userspace want to use CFI and custom
breakpoints at the same time, and CONFIG_CFI does exist as something
users might want to select for their kernel. If this is not good
acceptable we need to think about other ways for CFI to interfer, such
as not using BKPT at all (rather something like BUG()) and back out
the offending patch until the compiler behaviour has changed.
Fixes: c3f89986fde7 ("ARM: 9391/2: hw_breakpoint: Handle CFI breakpoints")
Reported-by: slipher <slipher@protonmail.com>
Closes: https://lore.kernel.org/lkml/kJqktbpLphg_Pk5I5SPptgTLjl3E3eq5mN5UzCslyFj7Q1Irp-wDid4mj5eQVd2iZtRGXgeZd8goq195EkXdjyt864YMc8mVb2B9NGH91NQ=@protonmail.com/
Signed-off-by: Linus Walleij <linusw@kernel.org>
---
Trying to solve the CFI bug. Let's see of this first
approach is acceptable for the reporter.
---
arch/arm/kernel/hw_breakpoint.c | 6 ++----
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index cd4b34c96e35..007023db6a5d 100644
--- a/arch/arm/kernel/hw_breakpoint.c
+++ b/arch/arm/kernel/hw_breakpoint.c
@@ -929,10 +929,6 @@ static void hw_breakpoint_cfi_handler(struct pt_regs *regs)
break;
}
}
-#else
-static void hw_breakpoint_cfi_handler(struct pt_regs *regs)
-{
-}
#endif
/*
@@ -964,9 +960,11 @@ static int hw_breakpoint_pending(unsigned long addr, unsigned int fsr,
case ARM_ENTRY_SYNC_WATCHPOINT:
watchpoint_handler(addr, fsr, regs);
break;
+#ifdef CONFIG_CFI
case ARM_ENTRY_CFI_BREAKPOINT:
hw_breakpoint_cfi_handler(regs);
break;
+#endif
default:
ret = 1; /* Unhandled fault. */
}
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260626-arm32-cfi-bug-10fb960749c4
Best regards,
--
Linus Walleij <linusw@kernel.org>
^ permalink raw reply related
* Re: [PATCH] rtc: zynqmp: Return optional clock lookup errors
From: Michal Simek @ 2026-06-26 12:42 UTC (permalink / raw)
To: Pengpeng Hou, Alexandre Belloni; +Cc: linux-rtc, linux-arm-kernel, linux-kernel
In-Reply-To: <20260624055524.38522-1-pengpeng@iscas.ac.cn>
On 6/24/26 07:55, Pengpeng Hou wrote:
> devm_clk_get_optional() returns NULL when the optional clock is absent,
> but returns an ERR_PTR when the clock provider lookup fails. Probe
> currently keeps the ERR_PTR and then passes it to clk_get_rate().
>
> Return the lookup error instead. A truly absent optional clock still
> reaches the existing calibration fallback through clk_get_rate(NULL).
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/rtc/rtc-zynqmp.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
> index 2ae54804b87a..5bcb7536e973 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -334,10 +334,9 @@ static int xlnx_rtc_probe(struct platform_device *pdev)
>
> /* Getting the rtc info */
> xrtcdev->rtc_clk = devm_clk_get_optional(&pdev->dev, "rtc");
> - if (IS_ERR(xrtcdev->rtc_clk)) {
> - if (PTR_ERR(xrtcdev->rtc_clk) != -EPROBE_DEFER)
> - dev_warn(&pdev->dev, "Device clock not found.\n");
> - }
> + if (IS_ERR(xrtcdev->rtc_clk))
> + return dev_err_probe(&pdev->dev, PTR_ERR(xrtcdev->rtc_clk),
> + "Failed to get rtc clock\n");
> xrtcdev->freq = clk_get_rate(xrtcdev->rtc_clk);
> if (!xrtcdev->freq) {
> ret = of_property_read_u32(pdev->dev.of_node, "calibration",
Fixes: 07dcc6f9c762 ("rtc: zynqmp: Add calibration set and get support")
cc: stable@kernel.org
Reviewed-by: Michal Simek <michal.simek@amd.com>
Thanks,
Michal
^ permalink raw reply
* Re: [PATCH v3 2/2] ARM: mm: protect show_pte() in do_DataAbort() fallback path
From: Russell King @ 2026-06-26 12:37 UTC (permalink / raw)
To: Xie Yuanbin; +Cc: xiqi2, akpm, linux-arm-kernel, linux-kernel, sunnanyong
In-Reply-To: <20260626101615.60920-1-xieyuanbin1@huawei.com>
On Fri, Jun 26, 2026 at 06:16:15PM +0800, Xie Yuanbin wrote:
> On Fri, 26 Jun 2026 15:30:48 +0800, Qi Xi wrote:
> > @@ -638,7 +638,10 @@ do_DataAbort(unsigned long addr, unsigned int fsr, struct pt_regs *regs)
> > pr_alert("8<--- cut here ---\n");
> > pr_alert("Unhandled fault: %s (0x%03x) at 0x%08lx\n",
> > inf->name, fsr, addr);
> > - show_pte(KERN_ALERT, current->mm, addr);
> > + if (mmap_read_trylock(current->mm)) {
> > + show_pte(KERN_ALERT, current->mm, addr);
> > + mmap_read_unlock(current->mm);
> > + }
>
> For kernel faults, `current->mm` maybe NULL, and
> `mmap_read_trylock(current->mm)` may cause a panic.
> Also, interrupts may be disabled here.
>
> I suggest that waiting for this patch to be merged first:
> https://lore.kernel.org/20260625122612.43501-1-xieyuanbin1@huawei.com
> which make sure that interrupts are enabled here.
No, it doesn't ensure that.
show_pte() is also called from die_kernel_fault() and
__do_kernel_fault(), which can be from a path that has interrupts
disabled. See the comments in do_kernel_address_page_fault().
We are not "fixing" show_pte(), which is a diagnostic function when
things go wrong in the kernel, and is there to *try* to give us
information to diagnose what happened. It is *not* a function that
is used routinely in the kernel.
The fact it is racy with other CPUs may be a problem, but it isn't
a big problem because when it's called, the system is practically
dead anyway.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH v2 7/8] arm64: dts: renesas: Convert to new media orientation definitions
From: Geert Uytterhoeven @ 2026-06-26 12: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, Laurent Pinchart, 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, 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, 26 Jun 2026 at 14:08, Kieran Bingham
<kieran.bingham@ideasonboard.com> 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: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()
From: Catalin Marinas @ 2026-06-26 12:31 UTC (permalink / raw)
To: Anshuman Khandual
Cc: linux-arm-kernel, Will Deacon, Ryan Roberts, David Hildenbrand,
linux-kernel, Ben Hutchings
In-Reply-To: <20260626012845.475959-1-anshuman.khandual@arm.com>
On Fri, Jun 26, 2026 at 02:28:45AM +0100, Anshuman Khandual wrote:
> flush_tlb_kernel_range() could flush down an entire block mapping just with
> a single PAGE_SIZE stride. This capability was being used umapping PMD and
> PUD based block mappings in unmap_hotplug_[pmd|pud]_range().
>
> But later on the commit 48478b9f7913
> ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()") replaced
> this PAGE_SIZE stride with [PMD|PUD]_SIZE strides, hence forcing multiple
> PAGE_SIZE stride based TLB flushes on platforms where TLB range operation
> is not supported. Revert back to the earlier TLB behaviour along with the
> required comments that were dropped earlier.
>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Ryan Roberts <ryan.roberts@arm.com>
> Cc: David Hildenbrand <david@kernel.org>
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Reported-by: Ben Hutchings <ben@decadent.org.uk>
> Closes: https://lore.kernel.org/all/b0d5836032ce3135bfc473f6bff791306d086925.camel@decadent.org.uk/
> Fixes: 48478b9f7913 ("arm64/mm: Enable batched TLB flush in unmap_hotplug_range()")
> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v2 6/8] arm64: dts: qcom: Convert to new media orientation definitions
From: Konrad Dybcio @ 2026-06-26 12:30 UTC (permalink / raw)
To: Kieran Bingham, 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,
Laurent Pinchart, 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
Cc: 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 6/26/26 2:07 PM, 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>
> ---
Finally someone shaved this yak, thank you
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Jie Gan @ 2026-06-26 12:09 UTC (permalink / raw)
To: Leo Yan
Cc: Suzuki K Poulose, Konrad Dybcio, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Tingwei Zhang,
Jingyi Wang, Abel Vesa, Mike Leach, James Clark, Yuanfang Zhang,
linux-arm-msm, devicetree, linux-kernel, coresight,
linux-arm-kernel
In-Reply-To: <20260626103015.GE575984@e132581.arm.com>
Hi Leo,
On 6/26/2026 6:30 PM, Leo Yan wrote:
> Hi Jie,
>
> On Fri, Jun 26, 2026 at 10:03:41AM +0800, Jie Gan wrote:
>
> [...]
>
>> Hi Leo,
>>
>> To be honest, I would prefer not to modify the interconnect platform driver.
>> On some Qualcomm platforms, multiple itnoc devices reside within small
>> blocks(one or more than one for each block) and are connected to a dummy
>> source. In such cases, two ATIDs are allocated for a path (the dummy source
>> and the itnoc), which is inefficient. This is why the itnoc platform driver
>> created to avoid this waste.
>>
>> The TraceNoC (called as AG TraceNoC) is a generic TraceNoC device which
>> connected to multiple source and link devices, aggregating data from all
>> source devices into a single output path.
>
> As I said, it may be fragile to couple a specific device property (ATID)
> to the AMBA driver.
>
> You're now facing a case where a device cannot be registered as an AMBA
> device, so it cannot use ATID. Likewise, I can imagine in future where a
> device is registered as an AMBA device, but you don't want ATID.
>
Agree. That's possible.
>> This device is implemented as an AMBA device but lacks proper hardware
>> configuration. As a result, it must be handled in the driver as a
>> workaround, which unfortunately breaks the original design intent.
>
> Seems to me, it is not reasonable to pretend an AMBA device but AMBA
> ID registers are absent.
>
> How about add a new DT property ("qcom,tnoc-enable-atid") to force
> enabling ATID?
That's a good proposal.
I have another proposal: what if we allocate the ATID in trace_noc_id()
when the device does not already have a valid ATID?
Possible scenarios:
If the itnoc device is connected to a TPDM device (which has no ATID),
trace_noc_id() will be invoked via coresight_path_assign_trace_id(), and
a valid ATID can be allocated for the path.
If the itnoc device is connected to sources other than TPDM,
trace_noc_id() will never be invoked, and therefore no ATID will be
allocated for the device, saving resources.
Thanks,
Jie
>
> Thanks,
> Leo
^ permalink raw reply
* [PATCH v2 7/8] arm64: dts: renesas: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 12:07 UTC (permalink / raw)
To: 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, Laurent Pinchart, 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
Cc: 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-0-47178be927b4@ideasonboard.com>
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>
---
.../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 {
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox