* 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
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-26 15:16 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Conor Dooley, Joey Lu, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <996c3d442e92e7f908fb3a32973805dd2d2680d7.camel@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 4813 bytes --]
On Fri, Jun 26, 2026 at 05:09:12PM +0800, Icenowy Zheng wrote:
> 在 2026-06-26五的 09:57 +0100，Conor Dooley写道：
> > On Fri, Jun 26, 2026 at 03:58:14PM +0800, Icenowy Zheng wrote:
> > > 在 2026-06-26五的 08:22 +0100，Conor Dooley写道：
> > > > On Thu, Jun 25, 2026 at 05:33:37PM +0100, Conor Dooley wrote:
> > > > > On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> > > > > > +
> > > > > > + - if:
> > > > > > + properties:
> > > > > > + compatible:
> > > > > > + contains:
> > > > > > + const: nuvoton,ma35d1-dcu
> > > > > > + then:
> > > > > > + properties:
> > > > > > + clocks:
> > > > > > + minItems: 2
> > > > >
> > > > > Anything that updates the minimum constraint should be done at
> > > > > the
> > > > > top
> > > > > level of this schema. The conditional section should then
> > > > > tighten
> > > > > the
> > > > > constraint, in this case that means only having maxItems.
> > > > >
> > > > > > + maxItems: 2
> > > > > > +
> > > > > > + clock-names:
> > > > > > + items:
> > > > > > + - const: core
> > > > > > + - const: pix0
> > > > >
> > > > > Does this even work when the top level schema thinks clock 2
> > > > > should
> > > > > be
> > > > > called axi?
> > > >
> > > > Additionally here, only have core and pix0 seems like it might be
> > > > an
> > > > oversimplification. I doubt removing the second output port means
> > > > that
> > > > the axi and ahb clocks are no longer needed.
> > > > Is it the case that your device supplies the same clock to core,
> > > > ahb
> > > > and
> > > > axi? If so, then you should fill those clocks in in your
> > > > devicetree
> > > > and
> > > > this can just constrain the number of clocks/clock-names to 4.
> > >
> > > The clock controller of that SoC is quite weird -- it has only a
> > > single
> > > gate bit, but controlling 3 clock gates. All core, ahb and axi
> > > clocks
> > > have gates controlled by this single bit, so it's why currently
> > > it's
> > > modelled as only core clock supplied.
> >
> > Yeah, then what's in the binding is definitely wrong.
> > Even if the same clock was provided to all clock inputs in the IP,
> > all
> > individual clock should be listed in the devicetree - although it
> > will
> > look a little silly to see clocks = <&foo 2>, <&foo 2>, <&foo 2>,
> > <&foo 2>;
> > In this case, 3 clocks controlled by 1 gate bit is an implementation
> > detail
> > of the SoC's clocking hardware, and not relevant to how the dc
> > instance
> > should be described.
> >
> > > Well it might be worthful to supply the bus clock before the gate
> > > as
> > > ahb/axi, especially axi, because both the AXI clock and the core
> > > clock
> > > constraints the maximum pixel clock.
> >
> > Right. And looking at patch 4/7, and the wording:
> > > The Nuvoton MA35D1 SoC integrates a DCUltraLite display controller
> > > whose
> > > AXI and AHB bus clocks share a single gate enable bit with the
> > > display
> > > core clock, so the clock driver does not expose them separately.
> > > This
> > > patch makes the axi and ahb clocks optional in the probe.
> >
> > It sounds like there's probably some issues with how things are
> > modelled
> > clock wise in this device, unless this is not an accurate statement
> > and
> > there's actually one clock provided to all three inputs. If they're
> > distinct clocks, with different rates, only having one exposed has a
> > lot
> > of potential to be problematic!
>
> Yes, I agree with this, they're different clocks according to the
> manual.
>
> I added the clk people to the CC list in a reply of the previous
> revision, but they didn't react yet. I don't know how to represent
> multiple clock gates sharing a single control bit in the clock
> framework...
Yeah, I have absolutely no idea. Maybe it requires custom refcounting?
Surely this cannot be the only device that does something like this
though.
> Maybe just supplying the ungated AXI/AHB clocks here, and let the core
> clock manage the gate?
I guess, but that seems incorrect and would require commentary about why
it's being done. Feel like they (the missing axi/ahb clocks) should be
added to the clock driver and binding, and any special workarounds done
there.
Of course letting the core clock manage the gate and making the enable
method for the gated AXI/AHB clocks be a NOP is one way of handling it
in the clock driver. Still a bit of a hack compared to refcounting it,
but it makes me happier to have the correct clock tree modelled in DT.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Conor Dooley @ 2026-06-26 15:32 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Conor Dooley, Joey Lu, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, ychuang3, schung, yclu4,
dri-devel, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <9456bde5059bea3aac1ed64355e3f017dd9bd3e5.camel@iscas.ac.cn>
[-- Attachment #1: Type: text/plain, Size: 1099 bytes --]
On Fri, Jun 26, 2026 at 05:33:26PM +0800, Icenowy Zheng wrote:
> > > >
> > > > > > > +
> > > > > > > + resets:
> > > > > > > + minItems: 1
> > > > > > > + maxItems: 1
> > > > > > > +
> > > > > > > + reset-names:
> > > > > > > + items:
> > > > > > > + - const: core
> > > > > >
> > > > > > This is just maxItems: 1.
> > > > >
> > > > > Well the implicit rules of DT binding schemas are quite
> > > > > weird...
> > > >
> > > > I don't think it is that strange, as the binding has
> > > > reset-names:
> > > > items:
> > > > - const: core
> > > > - const: axi
> > > > - const: ahb
> > >
> > > Ah does the list constraint the order of items? If it constrains
> > > the
> >
> > It does, yes.
> > Alternatively, using an enum permits free ordering.
>
> Ah in this case this should be converted to an enum, I think.
>
> Should I send a patch for converting it?
Why do you think it should be an enum? We don't currently have any users
of this that only provide no core or no axi reset.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [GIT PULL] arm64 fixes for -rc1
From: pr-tracker-bot @ 2026-06-26 15:45 UTC (permalink / raw)
To: Will Deacon
Cc: torvalds, catalin.marinas, linux-arm-kernel, linux-kernel,
kernel-team
In-Reply-To: <aj5bfQ9E7Qjeeo1d@willie-the-truck>
The pull request you sent on Fri, 26 Jun 2026 11:59:09 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e7c93451eeb06b67b4eb23017824b3dee90b360e
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: kaanapali: fix traceNoC probe issue
From: Leo Yan @ 2026-06-26 15:49 UTC (permalink / raw)
To: Jie Gan
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: <c1ac3ab4-f214-4947-b42f-cbc635be6bbb@oss.qualcomm.com>
On Fri, Jun 26, 2026 at 08:09:58PM +0800, Jie Gan wrote:
[...]
> 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.
TBH, I'm not sure I can make a judgement here, as I don't have enough
knowledge of the topology. And I'm not sure whether the listed
connections cover all possible cases.
I also found commit 5799dee92dc2:
| This patch adds platform driver support for the CoreSight Interconnect
| TNOC, Interconnect TNOC is a CoreSight link that forwards trace data
| from a subsystem to the Aggregator TNOC. Compared to Aggregator TNOC,
| it does not have aggregation and ATID functionality.
With your proposal, wouldn't ATID be allocated for the interconnect
TNOC while being skipped for the Aggregator TNOC? That seems to
contradict the commit log.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: raspberrypi,bcm2835-firmware: Include 'reboot-mode.yaml'
From: Conor Dooley @ 2026-06-26 15:57 UTC (permalink / raw)
To: Gregor Herburger
Cc: Florian Fainelli, Broadcom internal kernel review list, Ray Jui,
Scott Branden, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Eric Anholt, Stefan Wahren, linux-rpi-kernel, linux-arm-kernel,
linux-kernel, devicetree
In-Reply-To: <20260626-rpi-tryboot-v1-2-490b1c4c4970@linutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1476 bytes --]
On Fri, Jun 26, 2026 at 09:35:05AM +0200, Gregor Herburger wrote:
> The Raspberry Pi firmware allows to set a reboot mode called tryboot
> that allows to try booting from a different partition to allow updating
> of the boot partition. Allow reboot mode properties by referencing the
> reboot-mode schema.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> .../devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index 983ea80eaec97..30b490e0d9fb3 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -133,11 +133,14 @@ properties:
> required:
> - compatible
>
> +allOf:
> + - $ref: /schemas/power/reset/reboot-mode.yaml#
> +
> required:
> - compatible
> - mboxes
>
> -additionalProperties: false
> +unevaluatedProperties: false
I think you should keep additionalProperties: false and add
mode-normal: true
mode-tryboot: true
(I don't know if the latter works though, you may need to have a $ref to
uint32-array).
What you've done permits freeform reboot modes, but I think only normal
and tryboot are valid?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] arm64: mm: refresh stale pmd snapshot after split_contpmd()
From: David Hildenbrand (Arm) @ 2026-06-26 16:03 UTC (permalink / raw)
To: Dev Jain, lirongqing, Catalin Marinas, Will Deacon, Ryan Roberts,
Ard Biesheuvel, Anshuman Khandual, Kevin Brodsky, Yang Shi,
Chaitanya S Prakash, linux-arm-kernel, linux-kernel
In-Reply-To: <e0031cbe-2a49-4611-ad48-bde73fe4cd1c@arm.com>
On 6/26/26 15:03, Dev Jain wrote:
>
>
> 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?
I'm also confused by that, can we get some details why (and how) the cont bit
misguides pmd_pgprot?
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()
From: David Hildenbrand (Arm) @ 2026-06-26 16:09 UTC (permalink / raw)
To: Anshuman Khandual, linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Ryan Roberts, linux-kernel,
Ben Hutchings
In-Reply-To: <20260626012845.475959-1-anshuman.khandual@arm.com>
On 6/26/26 03:28, 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.
>
Right, it looked like the right thing to do in that commit. I wonder if we can
make the comments even clearer to prevent his happening another time,
incorporating the HW consideration.
In any case
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
> 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>
> ---
> arch/arm64/mm/mmu.c | 12 ++++++++++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> index 8242f93f05e4..5ff0041f4a5f 100644
> --- a/arch/arm64/mm/mmu.c
> +++ b/arch/arm64/mm/mmu.c
> @@ -1509,7 +1509,11 @@ static void unmap_hotplug_pmd_range(pud_t *pudp, unsigned long addr,
> if (free_mapped) {
> /* CONT blocks are not supported in the vmemmap */
> WARN_ON(pmd_cont(pmd));
> - flush_tlb_kernel_range(addr, addr + PMD_SIZE);
> + /*
> + * One TLBI should be sufficient here as the PMD_SIZE
> + * range is mapped with a single block entry.
> + */
"Flush only a single page, resulting in a single TLBi for this large block
mapping, avoiding multiple TLBIs on HW without TLB range flushes."
--
Cheers,
David
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: arm: ti: Add bindings for PHYTEC AM67x based hardware
From: Nathan Morrisson @ 2026-06-26 16:10 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: afd, sashiko-reviews, linux-arm-kernel, devicetree, linux-kernel,
upstream
Add device tree bindings for the AM67x based phyCORE-AM67x SoM and
phyBOARD-Rigel.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v2:
* Use spaces instead of tabs for indentation
Documentation/devicetree/bindings/arm/ti/k3.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml
index 69b5441cbf1a..ae47190d1f82 100644
--- a/Documentation/devicetree/bindings/arm/ti/k3.yaml
+++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml
@@ -222,6 +222,13 @@ properties:
- ti,j722s-evm
- const: ti,j722s
+ - description: K3 AM67 SoC PHYTEC phyBOARD-Rigel
+ items:
+ - enum:
+ - phytec,am6754-phyboard-rigel
+ - const: phytec,am67-phycore-som
+ - const: ti,j722s
+
- description: K3 J742S2 SoC
items:
- enum:
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 05/11] iommu/arm-smmu-v3: Submit CMDQ_OP_PRI_RESP for IOPF event
From: Robin Murphy @ 2026-06-26 16:15 UTC (permalink / raw)
To: Nicolin Chen, will, 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: <6c713c724fa09bf5a1b5e2247c633e516036f079.1779944354.git.nicolinc@nvidia.com>
On 28/05/2026 8:59 am, Nicolin Chen wrote:
> From: Malak Marrid <mmarrid@nvidia.com>
>
> To handle IOMMU_FAULT_PAGE_REQ from the PRI queue, arm_smmu_page_response()
> must issue a CMDQ_OP_PRI_RESP back to the SMMU.
>
> However, either a stall event in the EVTQ or a PRI request in the PRIQ can
> surface to the IOPF infrastructure with fault.type == IOMMU_FAULT_PAGE_REQ,
> and a single master can in principle be both stall-capable and PRI-capable
No, the SMMU architecture does all it can to specifically forbid this,
see 3.12.1 and 16.4, it just can't be made architecturally ILLEGAL to
enable stalls for PCIe devices because there's no strict architectural
definition for what "a PCIe device" actually is. Similarly with the note
in the definition of STE.EATS about the relationship with CD.S - the
unwritten implication is that defining specific behaviours would only
create an unreasonable burden for hardware validation, for the sake of
something that nobody in their right mind should ever do anyway.
The expectation is that RCiEPs which do speak stallable non-PCIe bus
protocols will not go to the effort of implementing ATS/PRI capabilities
(not least because there's every chance that such protocols simply
doesn't have that kind of transaction flow anyway). And conversely that
it can be considered an egregious firmware (or system design) error to
even claim (let alone force) stall capability for a real PCIe root port
which may be deadlocked by blocking its requirement for free-flowing
writes. Thus I think we could go so far as to refuse to handle any
endpoint which did somehow claim both.
Thanks,
Robin.
> (e.g. FEAT_STALL_FORCE on a PCIe device with PRI), so master state is not a
> reliable discriminator.
>
> Add IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS to the generic flags so the fault
> reporter can mark a page request that is holding the device's transaction:
> arm_smmu_handle_event() sets it on STALL events
> arm_smmu_handle_ppr() leaves it clear for PRI events
>
> Note: streams[0].id remains the RID because arm_smmu_enable_iopf() rejects
> num_streams != 1.
>
> Co-developed-by: Barak Biber <bbiber@nvidia.com>
> Signed-off-by: Barak Biber <bbiber@nvidia.com>
> Co-developed-by: Stefan Kaestle <skaestle@nvidia.com>
> Signed-off-by: Stefan Kaestle <skaestle@nvidia.com>
> Signed-off-by: Malak Marrid <mmarrid@nvidia.com>
> Signed-off-by: Nicolin Chen <nicolinc@nvidia.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h | 1 +
> include/linux/iommu.h | 1 +
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 75 +++++++++++++++------
> 3 files changed, 58 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> index 2bb810e4d5fce..1083621705f16 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.h
> @@ -1007,6 +1007,7 @@ struct arm_smmu_master {
> /* Locked by the iommu core using the group mutex */
> struct arm_smmu_ctx_desc_cfg cd_table;
> unsigned int num_streams;
> + bool pri_enabled : 1;
> bool ats_enabled : 1;
> bool ste_ats_enabled : 1;
> bool stall_enabled;
> diff --git a/include/linux/iommu.h b/include/linux/iommu.h
> index e587d4ac4d331..83c4dfcf20637 100644
> --- a/include/linux/iommu.h
> +++ b/include/linux/iommu.h
> @@ -76,6 +76,7 @@ struct iommu_fault_page_request {
> #define IOMMU_FAULT_PAGE_REQUEST_PASID_VALID (1 << 0)
> #define IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE (1 << 1)
> #define IOMMU_FAULT_PAGE_RESPONSE_NEEDS_PASID (1 << 2)
> +#define IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS (1 << 3)
> u32 flags;
> u32 pasid;
> u32 grpid;
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index ffc9621cd2288..061f1d46fda0d 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -921,32 +921,68 @@ static int arm_smmu_drain_queue_for_iopf(struct arm_smmu_device *smmu,
> return ret;
> }
>
> -static void arm_smmu_page_response(struct device *dev, struct iopf_fault *unused,
> +static void arm_smmu_page_response(struct device *dev, struct iopf_fault *evt,
> struct iommu_page_response *resp)
> {
> struct arm_smmu_master *master = dev_iommu_priv_get(dev);
> - u8 resume_resp;
> + struct arm_smmu_cmd cmd;
> + int sid;
>
> - if (WARN_ON(!master->stall_enabled))
> + if (WARN_ON_ONCE(evt->fault.type != IOMMU_FAULT_PAGE_REQ))
> return;
>
> - switch (resp->code) {
> - case IOMMU_PAGE_RESP_INVALID:
> - case IOMMU_PAGE_RESP_FAILURE:
> - resume_resp = CMDQ_RESUME_0_RESP_ABORT;
> - break;
> - case IOMMU_PAGE_RESP_SUCCESS:
> - resume_resp = CMDQ_RESUME_0_RESP_RETRY;
> - break;
> - default:
> - resume_resp = CMDQ_RESUME_0_RESP_TERM;
> - break;
> + /* IOPF is gated to num_streams == 1 in arm_smmu_enable_iopf() */
> + sid = master->streams[0].id;
> +
> + if (evt->fault.prm.flags & IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS) {
> + u8 resume_resp;
> +
> + if (WARN_ON_ONCE(!master->stall_enabled))
> + return;
> + switch (resp->code) {
> + case IOMMU_PAGE_RESP_INVALID:
> + case IOMMU_PAGE_RESP_FAILURE:
> + resume_resp = CMDQ_RESUME_0_RESP_ABORT;
> + break;
> + case IOMMU_PAGE_RESP_SUCCESS:
> + resume_resp = CMDQ_RESUME_0_RESP_RETRY;
> + break;
> + default:
> + resume_resp = CMDQ_RESUME_0_RESP_TERM;
> + break;
> + }
> + cmd = arm_smmu_make_cmd_resume(sid, resp->grpid, resume_resp);
> + } else {
> + enum pri_resp pri_resp;
> + bool ssv;
> +
> + if (WARN_ON_ONCE(!master->pri_enabled))
> + return;
> + /* PCIe allows only one PRG Response per group */
> + if (!(evt->fault.prm.flags &
> + IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE))
> + return;
> + switch (resp->code) {
> + case IOMMU_PAGE_RESP_SUCCESS:
> + pri_resp = PRI_RESP_SUCC;
> + break;
> + case IOMMU_PAGE_RESP_FAILURE:
> + pri_resp = PRI_RESP_FAIL;
> + break;
> + case IOMMU_PAGE_RESP_INVALID:
> + pri_resp = PRI_RESP_DENY;
> + break;
> + default:
> + WARN_ON(true);
> + return;
> + }
> + ssv = !!(evt->fault.prm.flags &
> + IOMMU_FAULT_PAGE_REQUEST_PASID_VALID);
> + cmd = arm_smmu_make_cmd_pri_resp(sid, resp->pasid, ssv,
> + resp->grpid, pri_resp);
> }
>
> - arm_smmu_cmdq_issue_cmd(master->smmu,
> - arm_smmu_make_cmd_resume(master->streams[0].id,
> - resp->grpid,
> - resume_resp));
> + arm_smmu_cmdq_issue_cmd(master->smmu, cmd);
> /*
> * Don't send a SYNC, it doesn't do anything for RESUME or PRI_RESP.
> * RESUME consumption guarantees that the stalled transaction will be
> @@ -2081,7 +2117,8 @@ static int arm_smmu_handle_event(struct arm_smmu_device *smmu, u64 *evt,
>
> flt->type = IOMMU_FAULT_PAGE_REQ;
> flt->prm = (struct iommu_fault_page_request){
> - .flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE,
> + .flags = IOMMU_FAULT_PAGE_REQUEST_LAST_PAGE |
> + IOMMU_FAULT_PAGE_REQUEST_STALLS_TRANS,
> .grpid = event->stag,
> .perm = perm,
> .addr = event->iova,
^ permalink raw reply
* Re: [PATCH v4 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Uladzislau Rezki @ 2026-06-26 16:20 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
In-Reply-To: <20260618084726.1070022-7-jiangwen6@xiaomi.com>
On Thu, Jun 18, 2026 at 04:47:26PM +0800, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> Try to align the vmap virtual address to PMD_SHIFT or a
> larger PTE mapping size hinted by the architecture, so
> contiguous pages can be batch-mapped when setting PMD or
> PTE entries.
>
> Add __get_vm_area_node_aligned_caller() as a wrapper over
> __get_vm_area_node() to simplify repeated calls with fixed
> arguments.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> mm/vmalloc.c | 37 ++++++++++++++++++++++++++++++++++++-
> 1 file changed, 36 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index fffb885cb2158..bc9fa93e2bdc6 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3628,6 +3628,41 @@ static int vmap_batched(unsigned long addr, unsigned long end,
> return err;
> }
>
> +static struct vm_struct *__get_vm_area_node_aligned_caller(unsigned long size,
> + unsigned long align, unsigned long flags, const void *caller)
> +{
> + return __get_vm_area_node(size, align, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> +}
> +
> +static struct vm_struct *vmap_get_aligned_vm_area(unsigned long size,
> + unsigned long flags, const void *caller)
> +{
> + struct vm_struct *vm_area;
> + unsigned int shift;
> +
> + /* Try PMD alignment for large sizes */
> + if (size >= PMD_SIZE) {
> + vm_area = __get_vm_area_node_aligned_caller(size, PMD_SIZE,
> + flags, caller);
> + if (vm_area)
> + return vm_area;
> + }
> +
> + /* Try CONT_PTE alignment */
> + shift = arch_vmap_pte_supported_shift(size);
> + if (shift > PAGE_SHIFT) {
> + vm_area = __get_vm_area_node_aligned_caller(size, 1UL << shift,
> + flags, caller);
> + if (vm_area)
> + return vm_area;
> + }
> +
> + /* Fall back to page alignment */
> + return __get_vm_area_node_aligned_caller(size, PAGE_SIZE, flags, caller);
> +}
> +
> /**
> * vmap - map an array of pages into virtually contiguous space
> * @pages: array of page pointers
> @@ -3666,7 +3701,7 @@ void *vmap(struct page **pages, unsigned int count,
> return NULL;
>
> size = (unsigned long)count << PAGE_SHIFT;
> - area = get_vm_area_caller(size, flags, __builtin_return_address(0));
> + area = vmap_get_aligned_vm_area(size, flags, __builtin_return_address(0));
> if (!area)
> return NULL;
>
> --
> 2.34.1
>
Did intensive random mapping/unmaping, so i have not noticed any issues.
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
--
Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: ti: Add support for the phyCORE-AM67x
From: Andrew Davis @ 2026-06-26 16:21 UTC (permalink / raw)
To: Nathan Morrisson, nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: sashiko-reviews, linux-arm-kernel, devicetree, linux-kernel,
upstream
In-Reply-To: <20260626161014.1146128-2-nmorrisson@phytec.com>
On 6/26/26 11:10 AM, Nathan Morrisson wrote:
> Add support for the PHYTEC phyCORE-AM67x SoM [1] and the
> corresponding phyBOARD-Rigel carrier board [2]. The phyCORE-AM67x SoM
> uses the TI AM67x SoC and can come with different sizes and models of
> DDR, eMMC, and SPI NOR Flash.
>
> Supported features:
> * Audio playback and recording
> * CAN
> * Debug UART
> * eMMC
> * Ethernet
> * GPIO buttons
> * Heartbeat LED
> * I2C Current sensor
> * I2C EEPROM
> * I2C Light sensor
> * I2C RTC
> * Micro SD card
> * PCIe
> * SPI NOR flash
> * USB
>
> [1] https://www.phytec.com/product/phycore-am67x/
> [2] https://www.phytec.com/product/phyboard-am67x-development-kit/
>
> Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
> ---
Reviewed-by: Andrew Davis <afd@ti.com>
> Changes in v2:
> * Move k3-j722s.dtsi include from the phyboard to phycore dts
> * Remove cpsw_port2 node because it was already disabled
> * Remove mcasp1 because it is used by HDMI, and HDMI is not included in this dts
> * Fix typo in audio codec properties ai3xx-micbias-vg -> ai31xx-micbias-vg
> * Use IRQ_TYPE_EDGE_FALLING instead of IRQ_TYPE_LEVEL_LOW for gpio expanders
>
> arch/arm64/boot/dts/ti/Makefile | 1 +
> .../boot/dts/ti/k3-am67-phycore-som.dtsi | 325 ++++++++++++
> .../boot/dts/ti/k3-am6754-phyboard-rigel.dts | 478 ++++++++++++++++++
> 3 files changed, 804 insertions(+)
> create mode 100644 arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
> create mode 100644 arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
>
> diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
> index 371f9a043fe5..623ee2369132 100644
> --- a/arch/arm64/boot/dts/ti/Makefile
> +++ b/arch/arm64/boot/dts/ti/Makefile
> @@ -184,6 +184,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-pcie1-ep.dtbo
> dtb-$(CONFIG_ARCH_K3) += k3-j721s2-evm-usb0-type-a.dtbo
>
> # Boards with J722s SoC
> +dtb-$(CONFIG_ARCH_K3) += k3-am6754-phyboard-rigel.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-am67a-beagley-ai.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm.dtb
> dtb-$(CONFIG_ARCH_K3) += k3-j722s-evm-csi2-quad-rpi-cam-imx219.dtbo
> diff --git a/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
> new file mode 100644
> index 000000000000..1bbd6d024c60
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am67-phycore-som.dtsi
> @@ -0,0 +1,325 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Copyright (C) 2026 PHYTEC America LLC
> + * Author: Nathan Morrisson <nmorrisson@phytec.com>
> + */
> +
> +#include <dt-bindings/net/ti-dp83867.h>
> +#include <dt-bindings/leds/common.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include "k3-j722s.dtsi"
> +
> +/ {
> + compatible = "phytec,am67-phycore-som", "ti,j722s";
> + model = "PHYTEC phyCORE-AM67";
> +
> + aliases {
> + ethernet0 = &cpsw_port1;
> + gpio0 = &main_gpio0;
> + mmc0 = &sdhci0;
> + rtc0 = &i2c_som_rtc;
> + rtc1 = &wkup_rtc0;
> + spi0 = &ospi0;
> + };
> +
> + memory@80000000 {
> + /* 4G RAM */
> + reg = <0x00000000 0x80000000 0x00000000 0x80000000>,
> + <0x00000008 0x80000000 0x00000000 0x80000000>;
> + device_type = "memory";
> + bootph-all;
> + };
> +
> + reserved_memory: reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + secure_tfa_ddr: tfa@9e780000 {
> + reg = <0x00 0x9e780000 0x00 0x80000>;
> + no-map;
> + };
> +
> + secure_ddr: optee@9e800000 {
> + reg = <0x00 0x9e800000 0x00 0x01800000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_dma_memory_region: memory@a0000000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa0000000 0x00 0x100000>;
> + no-map;
> + };
> +
> + wkup_r5fss0_core0_memory_region: memory@a0100000 {
> + compatible = "shared-dma-pool";
> + reg = <0x00 0xa0100000 0x00 0xf00000>;
> + no-map;
> + };
> + };
> +
> + vcc_5v0_som: regulator-vcc-5v0-som {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_5V0_SOM";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_pins_default>;
> +
> + led-0 {
> + color = <LED_COLOR_ID_GREEN>;
> + gpios = <&main_gpio0 13 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "heartbeat";
> + function = LED_FUNCTION_HEARTBEAT;
> + };
> + };
> +};
> +
> +&main_pmx0 {
> + leds_pins_default: leds-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x034, PIN_OUTPUT, 7) /* (K22) OSPI0_CSN2.GPIO0_13 */
> + >;
> + };
> +
> + mdio_pins_default: mdio-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0160, PIN_OUTPUT, 0) /* (AC24) MDIO0_MDC */
> + J722S_IOPAD(0x015c, PIN_INPUT, 0) /* (AD25) MDIO0_MDIO */
> + >;
> + bootph-all;
> + };
> +
> + ospi0_pins_default: ospi0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x000, PIN_OUTPUT, 0) /* (L24) OSPI0_CLK */
> + J722S_IOPAD(0x02c, PIN_OUTPUT, 0) /* (K26) OSPI0_CSn0 */
> + J722S_IOPAD(0x00c, PIN_INPUT, 0) /* (K27) OSPI0_D0 */
> + J722S_IOPAD(0x010, PIN_INPUT, 0) /* (L27) OSPI0_D1 */
> + J722S_IOPAD(0x014, PIN_INPUT, 0) /* (L26) OSPI0_D2 */
> + J722S_IOPAD(0x018, PIN_INPUT, 0) /* (L25) OSPI0_D3 */
> + J722S_IOPAD(0x01c, PIN_INPUT, 0) /* (L21) OSPI0_D4 */
> + J722S_IOPAD(0x020, PIN_INPUT, 0) /* (M26) OSPI0_D5 */
> + J722S_IOPAD(0x024, PIN_INPUT, 0) /* (N27) OSPI0_D6 */
> + J722S_IOPAD(0x028, PIN_INPUT, 0) /* (M27) OSPI0_D7 */
> + J722S_IOPAD(0x008, PIN_INPUT, 0) /* (L22) OSPI0_DQS */
> + J722S_IOPAD(0x038, PIN_INPUT, 7) /* (J22) OSPI0_CSn3.GPIO0_14 */
> + >;
> + bootph-all;
> + };
> +
> + pmic_irq_pins_default: pmic-irq-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x030, PIN_INPUT, 7) /* (K23) OSPI0_CSN1.GPIO0_12 */
> + >;
> + };
> +
> + rgmii1_pins_default: rgmii1-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x014c, PIN_INPUT, 0) /* (AC25) RGMII1_RD0 */
> + J722S_IOPAD(0x0150, PIN_INPUT, 0) /* (AD27) RGMII1_RD1 */
> + J722S_IOPAD(0x0154, PIN_INPUT, 0) /* (AE24) RGMII1_RD2 */
> + J722S_IOPAD(0x0158, PIN_INPUT, 0) /* (AE26) RGMII1_RD3 */
> + J722S_IOPAD(0x0148, PIN_INPUT, 0) /* (AE27) RGMII1_RXC */
> + J722S_IOPAD(0x0144, PIN_INPUT, 0) /* (AD23) RGMII1_RX_CTL */
> + J722S_IOPAD(0x0134, PIN_OUTPUT, 0) /* (AF27) RGMII1_TD0 */
> + J722S_IOPAD(0x0138, PIN_OUTPUT, 0) /* (AE23) RGMII1_TD1 */
> + J722S_IOPAD(0x013c, PIN_OUTPUT, 0) /* (AG25) RGMII1_TD2 */
> + J722S_IOPAD(0x0140, PIN_OUTPUT, 0) /* (AF24) RGMII1_TD3 */
> + J722S_IOPAD(0x0130, PIN_OUTPUT, 0) /* (AG26) RGMII1_TXC */
> + J722S_IOPAD(0x012c, PIN_OUTPUT, 0) /* (AF25) RGMII1_TX_CTL */
> + >;
> + bootph-all;
> + };
> +};
> +
> +&mcu_pmx0 {
> + wkup_i2c0_pins_default: wkup-i2c0-default-pins {
> + pinctrl-single,pins = <
> + J722S_MCU_IOPAD(0x04c, PIN_INPUT_PULLUP, 0) /* (B9) WKUP_I2C0_SCL */
> + J722S_MCU_IOPAD(0x050, PIN_INPUT_PULLUP, 0) /* (D11) WKUP_I2C0_SDA */
> + >;
> + bootph-all;
> + };
> +};
> +
> +&cpsw3g {
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmii1_pins_default>;
> + bootph-all;
> + status = "okay";
> +};
> +
> +&cpsw3g_mdio {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mdio_pins_default>;
> + status = "okay";
> +
> + cpsw3g_phy1: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <1>;
> + ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
> + tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
> + ti,min-output-impedance;
> + };
> +};
> +
> +&cpsw_port1 {
> + phy-mode = "rgmii-id";
> + phy-handle = <&cpsw3g_phy1>;
> + status = "okay";
> +};
> +
> +&ospi0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ospi0_pins_default>;
> + bootph-all;
> + status = "okay";
> +
> + serial_flash: flash@0 {
> + compatible = "jedec,spi-nor";
> + reg = <0x0>;
> + spi-tx-bus-width = <8>;
> + spi-rx-bus-width = <8>;
> + spi-max-frequency = <25000000>;
> + vcc-supply = <&vdd_1v8>;
> + cdns,tshsl-ns = <60>;
> + cdns,tsd2d-ns = <60>;
> + cdns,tchsh-ns = <60>;
> + cdns,tslch-ns = <60>;
> + cdns,read-delay = <0>;
> + };
> +};
> +
> +&sdhci0 {
> + non-removable;
> + bootph-all;
> + ti,driver-strength-ohm = <50>;
> + status = "okay";
> +};
> +
> +&wkup_i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&wkup_i2c0_pins_default>;
> + clock-frequency = <400000>;
> + bootph-all;
> + status = "okay";
> +
> + pmic@30 {
> + compatible = "ti,tps65219";
> + reg = <0x30>;
> + buck1-supply = <&vcc_5v0_som>;
> + buck2-supply = <&vcc_5v0_som>;
> + buck3-supply = <&vcc_5v0_som>;
> + ldo1-supply = <&vdd_3v3>;
> + ldo2-supply = <&vdd_1v8>;
> + ldo3-supply = <&vdd_3v3>;
> + ldo4-supply = <&vdd_3v3>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_irq_pins_default>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <12 IRQ_TYPE_EDGE_FALLING>;
> + interrupt-controller;
> + #interrupt-cells = <1>;
> +
> + system-power-controller;
> + ti,power-button;
> +
> + regulators {
> + vdd_3v3: buck1 {
> + regulator-name = "VDD_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdd_1v8: buck2 {
> + regulator-name = "VDD_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdd_lpddr4: buck3 {
> + regulator-name = "VDD_LPDDR4";
> + regulator-min-microvolt = <1100000>;
> + regulator-max-microvolt = <1100000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vddshv_sdio: ldo1 {
> + regulator-name = "VDDSHV_SDIO";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-allow-bypass;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdd_1v2: ldo2 {
> + regulator-name = "VDD_1V2";
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdda_1v8_phy: ldo3 {
> + regulator-name = "VDDA_1V8_PHY";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + vdd_1v8_pll: ldo4 {
> + regulator-name = "VDD_1V8_PLL";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + };
> + };
> +
> + vdd_core: regulator-vdd-core@44 {
> + compatible = "ti,tps62873";
> + reg = <0x44>;
> + bootph-pre-ram;
> + regulator-name = "VDD_CORE";
> + regulator-min-microvolt = <850000>;
> + regulator-max-microvolt = <850000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
> + eeprom@50 {
> + compatible = "atmel,24c32";
> + reg = <0x50>;
> + pagesize = <32>;
> + };
> +
> + som_eeprom_opt: eeprom@51 {
> + compatible = "atmel,24c32";
> + reg = <0x51>;
> + pagesize = <32>;
> + };
> +
> + i2c_som_rtc: rtc@52 {
> + compatible = "microcrystal,rv3028";
> + reg = <0x52>;
> + };
> +};
> +
> +#include "k3-j722s-ti-ipc-firmware.dtsi"
> diff --git a/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
> new file mode 100644
> index 000000000000..e6e74910e0bb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/ti/k3-am6754-phyboard-rigel.dts
> @@ -0,0 +1,478 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Copyright (C) 2026 PHYTEC America LLC
> + * Author: Nathan Morrisson <nmorrisson@phytec.com>
> + */
> +
> +/dts-v1/;
> +
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/phy/phy.h>
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/interrupt-controller/irq.h>
> +#include "k3-serdes.h"
> +#include "k3-am67-phycore-som.dtsi"
> +
> +/ {
> + compatible = "phytec,am6754-phyboard-rigel",
> + "phytec,am67-phycore-som", "ti,j722s";
> + model = "PHYTEC phyBOARD-Rigel AM67";
> +
> + aliases {
> + gpio1 = &main_gpio1;
> + mmc1 = &sdhci1;
> + serial2 = &main_uart0;
> + usb0 = &usb0;
> + usb1 = &usb1;
> + };
> +
> + can_tc0: can-phy0 {
> + compatible = "ti,tcan1042";
> + #phy-cells = <0>;
> + max-bitrate = <8000000>;
> + standby-gpios = <&gpio_exp1 1 GPIO_ACTIVE_HIGH>;
> + };
> +
> + usb0_connector: connector {
> + compatible = "gpio-usb-b-connector", "usb-b-connector";
> + label = "USB-C";
> + data-role = "dual";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_usbc_power_pins_default>;
> +
> + id-gpios = <&main_gpio1 15 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + usb0_con: endpoint {
> + remote-endpoint = <&usb0_ep>;
> + };
> + };
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> + autorepeat;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_keys_pins_default>;
> +
> + key-home {
> + label = "home";
> + linux,code = <KEY_HOME>;
> + gpios = <&main_gpio1 23 GPIO_ACTIVE_HIGH>;
> + };
> +
> + key-menu {
> + label = "menu";
> + linux,code = <KEY_MENU>;
> + gpios = <&gpio_exp1 4 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + pcie_refclk0: pcie-refclk0 {
> + compatible = "gpio-gate-clock";
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_pcie_usb_sel_pins_default>;
> + clocks = <&serdes_refclk>;
> + #clock-cells = <0>;
> + enable-gpios = <&main_gpio0 22 GPIO_ACTIVE_LOW>;
> + };
> +
> + vcc_1v8: regulator-vcc-1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc_3v3_aud: regulator-vcc-3v3-aud {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3_AUD";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc_3v3_mmc: regulator-vcc-3v3-mmc {
> + /* TPS22963C OUTPUT */
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3_MMC";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc_3v3_sw: regulator-vcc-3v3-sw {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3_SW";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + vcc_speaker: regulator-vcc-speaker {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_SPEAKER";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + sound {
> + compatible = "simple-audio-card";
> + simple-audio-card,widgets =
> + "Microphone", "Mic Jack",
> + "Headphone", "Headphone Jack",
> + "Line", "Stereo Jack",
> + "Speaker", "L SPKR",
> + "Speaker", "R SPKR";
> + simple-audio-card,routing =
> + "MIC1RP", "Mic Jack",
> + "Mic Jack", "MICBIAS",
> + "Headphone Jack", "HPL",
> + "Headphone Jack", "HPR",
> + "MIC1LM", "Stereo Jack",
> + "MIC1LP", "Stereo Jack",
> + "SPL", "L SPKR",
> + "SPR", "R SPKR";
> + simple-audio-card,name = "phyBOARD-Rigel";
> + simple-audio-card,format = "dsp_b";
> + simple-audio-card,bitclock-master = <&sound_master>;
> + simple-audio-card,frame-master = <&sound_master>;
> + simple-audio-card,bitclock-inversion;
> +
> + simple-audio-card,cpu {
> + sound-dai = <&mcasp0>;
> + };
> +
> + sound_master: simple-audio-card,codec {
> + sound-dai = <&audio_codec>;
> + clocks = <&audio_refclk1>;
> + };
> + };
> +};
> +
> +&main_pmx0 {
> + audio_ext_refclk1_pins_default: audio-ext-refclk1-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0a0, PIN_OUTPUT, 1) /* (N24) GPMC0_WPn.AUDIO_EXT_REFCLK1 */
> + >;
> + };
> +
> + gpio_exp0_int_pins_default: gpio-exp0-int-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0054, PIN_INPUT, 7) /* (T21) GPMC0_AD6.GPIO0_21 */
> + >;
> + };
> +
> + gpio_exp1_int_pins_default: gpio-exp1-int-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0244, PIN_INPUT, 7) /* (A24) MMC1_SDWP.GPIO1_49 */
> + >;
> + };
> +
> + gpio_exp2_int_pins_default: gpio-exp2-int-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x0050, PIN_INPUT, 7) /* (T24) GPMC0_AD5.GPIO0_20 */
> + >;
> + };
> +
> + gpio_keys_pins_default: gpio-keys-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x01d4, PIN_INPUT, 7) /* (B21) UART0_RTSn.GPIO1_23 */
> + >;
> + };
> +
> + main_i2c0_pins_default: main-i2c0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x01e0, PIN_INPUT_PULLUP, 0) /* (D23) I2C0_SCL */
> + J722S_IOPAD(0x01e4, PIN_INPUT_PULLUP, 0) /* (B22) I2C0_SDA */
> + >;
> + bootph-all;
> + };
> +
> + main_i2c1_pins_default: main-i2c1-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x01e8, PIN_INPUT_PULLUP, 0) /* (C24) I2C1_SCL */
> + J722S_IOPAD(0x01ec, PIN_INPUT_PULLUP, 0) /* (A22) I2C1_SDA */
> + >;
> + bootph-all;
> + };
> +
> + main_mcan0_pins_default: main-mcan0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x1dc, PIN_INPUT, 0) /* (C22) MCAN0_RX */
> + J722S_IOPAD(0x1d8, PIN_OUTPUT, 0) /* (D22) MCAN0_TX */
> + >;
> + };
> +
> + main_mcasp0_pins_default: main-mcasp0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x1a8, PIN_INPUT, 0) /* (C26) MCASP0_AFSX */
> + J722S_IOPAD(0x1a4, PIN_INPUT, 0) /* (D25) MCASP0_ACLKX */
> + J722S_IOPAD(0x198, PIN_OUTPUT, 0) /* (A26) MCASP0_AXR2 */
> + J722S_IOPAD(0x194, PIN_INPUT, 0) /* (A25) MCASP0_AXR3 */
> + >;
> + };
> +
> + main_mmc1_pins_default: main-mmc1-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x023c, PIN_INPUT, 0) /* (H22) MMC1_CMD */
> + J722S_IOPAD(0x0234, PIN_INPUT, 0) /* (H24) MMC1_CLK */
> + J722S_IOPAD(0x0230, PIN_INPUT, 0) /* (H23) MMC1_DAT0 */
> + J722S_IOPAD(0x022c, PIN_INPUT, 0) /* (H20) MMC1_DAT1 */
> + J722S_IOPAD(0x0228, PIN_INPUT, 0) /* (J23) MMC1_DAT2 */
> + J722S_IOPAD(0x0224, PIN_INPUT, 0) /* (H25) MMC1_DAT3 */
> + J722S_IOPAD(0x0240, PIN_INPUT, 0) /* (B24) MMC1_SDCD */
> + >;
> + bootph-all;
> + };
> +
> + main_pcie_pins_default: main-pcie-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x07c, PIN_INPUT, 7) /* (T23) GPMC0_CLK.GPIO0_31 */
> + >;
> + };
> +
> + main_pcie_usb_sel_pins_default: main-pcie-usb-sel-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x058, PIN_INPUT, 7) /* (T22) GPMC0_AD7.GPIO0_22 */
> + >;
> + };
> +
> + main_uart0_pins_default: main-uart0-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x01c8, PIN_INPUT, 0) /* (F19) UART0_RXD */
> + J722S_IOPAD(0x01cc, PIN_OUTPUT, 0) /* (F20) UART0_TXD */
> + >;
> + bootph-all;
> + };
> +
> + main_usbc_power_pins_default: main-usbc-power-default-pins {
> + pinctrl-single,pins = <
> + J722S_IOPAD(0x1b4, PIN_INPUT, 7) /* (B20) SPI0_CS0.GPIO1_15 */
> + >;
> + };
> +};
> +
> +&audio_refclk1 {
> + assigned-clock-rates = <25000000>;
> +};
> +
> +&main_i2c0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_i2c0_pins_default>;
> + clock-frequency = <400000>;
> + status = "okay";
> +
> + veml6030: light-sensor@10 {
> + compatible = "vishay,veml6030";
> + reg = <0x10>;
> + vdd-supply = <&vcc_3v3_sw>;
> + };
> +};
> +
> +&main_i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_i2c1_pins_default>;
> + clock-frequency = <100000>;
> + status = "okay";
> +
> + audio_codec: audio-codec@18 {
> + compatible = "ti,tlv320aic3110";
> + reg = <0x18>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&audio_ext_refclk1_pins_default>;
> + #sound-dai-cells = <0>;
> + ai31xx-micbias-vg = <2>;
> + reset-gpios = <&gpio_exp1 7 GPIO_ACTIVE_LOW>;
> +
> + HPVDD-supply = <&vcc_3v3_aud>;
> + SPRVDD-supply = <&vcc_speaker>;
> + SPLVDD-supply = <&vcc_speaker>;
> + AVDD-supply = <&vcc_3v3_aud>;
> + IOVDD-supply = <&vcc_3v3_aud>;
> + DVDD-supply = <&vcc_1v8>;
> + };
> +
> + gpio_exp0: gpio@20 {
> + compatible = "nxp,pcf8574";
> + reg = <0x20>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_exp0_int_pins_default>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <21 IRQ_TYPE_EDGE_FALLING>;
> + gpio-line-names = "CSI3_STROBE", "CSI3_TRIGGER",
> + "CSI3_SHUTTER", "CSI3_OE",
> + "CSI2_STROBE", "CSI2_TRIGGER",
> + "CSI2_SHUTTER", "CSI2_OE";
> + };
> +
> + gpio_exp1: gpio@21 {
> + compatible = "nxp,pcf8574";
> + reg = <0x21>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_exp1_int_pins_default>;
> + interrupt-parent = <&main_gpio1>;
> + interrupts = <49 IRQ_TYPE_EDGE_FALLING>;
> + gpio-line-names = "GPIO0_HDMI_RST", "GPIO1_CAN_nEN",
> + "GPIO2_LED", "GPIO3_MCU_CAN0_nEN",
> + "GPIO4_BUT2", "GPIO5_MCU_CAN1_nEN",
> + "GPIO6_AUDIO_GPIO", "GPIO7_AUDIO_USER_RESET";
> + };
> +
> + gpio_exp2: gpio@23 {
> + compatible = "nxp,pcf8574";
> + reg = <0x23>;
> + gpio-controller;
> + #gpio-cells = <2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gpio_exp2_int_pins_default>;
> + interrupt-parent = <&main_gpio0>;
> + interrupts = <20 IRQ_TYPE_EDGE_FALLING>;
> + gpio-line-names = "CSI1_STROBE", "CSI1_TRIGGER",
> + "CSI1_SHUTTER", "CSI1_OE",
> + "CSI0_STROBE", "CSI0_TRIGGER",
> + "CSI0_SHUTTER", "CSI0_OE";
> + };
> +
> + current-sensor@40 {
> + compatible = "ti,ina233";
> + reg = <0x40>;
> + shunt-resistor = <18000>;
> + };
> +
> + eeprom@51 {
> + compatible = "atmel,24c02";
> + reg = <0x51>;
> + pagesize = <16>;
> + };
> +};
> +
> +&main_mcan0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcan0_pins_default>;
> + phys = <&can_tc0>;
> + status = "okay";
> +};
> +
> +&main_uart0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_uart0_pins_default>;
> + bootph-all;
> + status = "okay";
> +};
> +
> +&mcasp0 {
> + #sound-dai-cells = <0>;
> + op-mode = <0>; /* MCASP_IIS_MODE */
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mcasp0_pins_default>;
> + tdm-slots = <2>;
> + serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
> + 0 0 1 2
> + 0 0 0 0
> + 0 0 0 0
> + 0 0 0 0
> + >;
> + status = "okay";
> +};
> +
> +&pcie0_rc {
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_pcie_pins_default>;
> + num-lanes = <1>;
> + phys = <&serdes1_pcie_link>;
> + phy-names = "pcie-phy";
> + reset-gpios = <&main_gpio0 31 GPIO_ACTIVE_HIGH>;
> + status = "okay";
> +};
> +
> +&sdhci1 {
> + /* SD/MMC */
> + vmmc-supply = <&vcc_3v3_mmc>;
> + vqmmc-supply = <&vddshv_sdio>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&main_mmc1_pins_default>;
> + disable-wp;
> + no-1-8-v;
> + bootph-all;
> + status = "okay";
> +};
> +
> +&serdes_ln_ctrl {
> + idle-states = <J722S_SERDES0_LANE0_USB>,
> + <J722S_SERDES1_LANE0_PCIE0_LANE0>;
> +};
> +
> +&serdes0 {
> + status = "okay";
> +
> + serdes0_usb_link: phy@0 {
> + reg = <0>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = <PHY_TYPE_USB3>;
> + resets = <&serdes_wiz0 1>;
> + };
> +};
> +
> +&serdes_wiz0 {
> + status = "okay";
> +};
> +
> +&serdes1 {
> + status = "okay";
> +
> + serdes1_pcie_link: phy@0 {
> + reg = <0>;
> + cdns,num-lanes = <1>;
> + #phy-cells = <0>;
> + cdns,phy-type = <PHY_TYPE_PCIE>;
> + resets = <&serdes_wiz1 1>;
> + };
> +};
> +
> +&serdes_wiz1 {
> + clocks = <&k3_clks 280 0>, <&k3_clks 280 1>, <&pcie_refclk0>;
> + status = "okay";
> +};
> +
> +&usbss0 {
> + ti,vbus-divider;
> + status = "okay";
> +};
> +
> +&usb0 {
> + dr_mode = "otg";
> + usb-role-switch;
> + maximum-speed = "high-speed";
> +
> + port {
> + usb0_ep: endpoint {
> + remote-endpoint = <&usb0_con>;
> + };
> + };
> +};
> +
> +&usbss1 {
> + ti,vbus-divider;
> + status = "okay";
> +};
> +
> +&usb1 {
> + dr_mode = "host";
> + phys = <&serdes0_usb_link>;
> + phy-names = "cdns3,usb3-phy";
> + maximum-speed = "super-speed";
> +};
^ permalink raw reply
* Re: [PATCH v4 3/6] mm/vmalloc: Extract vmap_set_ptes() to consolidate PTE mapping logic
From: Uladzislau Rezki @ 2026-06-26 16:21 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
In-Reply-To: <20260618084726.1070022-4-jiangwen6@xiaomi.com>
On Thu, Jun 18, 2026 at 04:47:23PM +0800, Wen Jiang wrote:
> Extract the common PTE mapping logic from vmap_pte_range() into a
> shared helper vmap_set_ptes(). This handles both CONT_PTE and regular
> PTE mappings in a single function, preparing for the next patch which
> will extend vmap_pages_pte_range() to also use this helper.
>
> The #ifdef CONFIG_HUGETLB_PAGE guard is moved inside vmap_set_ptes(),
> so callers no longer need to handle the conditional compilation.
>
> No functional change.
>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> mm/vmalloc.c | 44 +++++++++++++++++++++++++++++++-------------
> 1 file changed, 31 insertions(+), 13 deletions(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 2c2f74a07f396..6660f240d27c9 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -91,6 +91,35 @@ struct vfree_deferred {
> static DEFINE_PER_CPU(struct vfree_deferred, vfree_deferred);
>
> /*** Page table manipulation functions ***/
> +
> +/*
> + * Set PTE mappings for the given PFN. Try CONT_PTE mappings first when
> + * supported, otherwise fall back to PAGE_SIZE mappings.
> + *
> + * Return: mapping size.
> + */
> +static __always_inline unsigned long vmap_set_ptes(pte_t *pte,
> + unsigned long addr, unsigned long end, u64 pfn,
> + pgprot_t prot, unsigned int max_page_shift)
> +{
> +#ifdef CONFIG_HUGETLB_PAGE
> + if (max_page_shift > PAGE_SHIFT) {
> + unsigned long size;
> +
> + size = arch_vmap_pte_range_map_size(addr, end, pfn, max_page_shift);
> + if (size != PAGE_SIZE) {
> + pte_t entry = pfn_pte(pfn, prot);
> +
> + entry = arch_make_huge_pte(entry, ilog2(size), 0);
> + set_huge_pte_at(&init_mm, addr, pte, entry, size);
> + return size;
> + }
> + }
> +#endif
> + set_pte_at(&init_mm, addr, pte, pfn_pte(pfn, prot));
> + return PAGE_SIZE;
> +}
> +
> static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> phys_addr_t phys_addr, pgprot_t prot,
> unsigned int max_page_shift, pgtbl_mod_mask *mask)
> @@ -119,19 +148,8 @@ static int vmap_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
> BUG();
> }
>
> -#ifdef CONFIG_HUGETLB_PAGE
> - size = arch_vmap_pte_range_map_size(addr, end, pfn, max_page_shift);
> - if (size != PAGE_SIZE) {
> - pte_t entry = pfn_pte(pfn, prot);
> -
> - entry = arch_make_huge_pte(entry, ilog2(size), 0);
> - set_huge_pte_at(&init_mm, addr, pte, entry, size);
> - pfn += PFN_DOWN(size);
> - continue;
> - }
> -#endif
> - set_pte_at(&init_mm, addr, pte, pfn_pte(pfn, prot));
> - pfn++;
> + size = vmap_set_ptes(pte, addr, end, pfn, prot, max_page_shift);
> + pfn += PFN_DOWN(size);
> } while (pte += PFN_DOWN(size), addr += size, addr != end);
>
> lazy_mmu_mode_disable();
> --
> 2.34.1
>
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
--
Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH v5 2/4] drm/dp: Add helper to validate DP lane counts
From: Luca Ceresoli @ 2026-06-26 16:29 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260604085220.2862986-3-damon.ding@rock-chips.com>
On Thu, 04 Jun 2026 16:52:18 +0800, Damon Ding <damon.ding@rock-chips.com> wrote:
> Add a generic helper function drm_dp_lane_count_is_valid() to check
> if a DisplayPort lane count is valid. According to the DP specification,
> only 1, 2, or 4 lanes are supported.
>
> This helper avoids duplicating DP lane count validation logic across
> individual DisplayPort drivers.
>
> [...]
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v5 3/4] drm/bridge: analogix_dp: Add validation for samsung,lane-count property
From: Luca Ceresoli @ 2026-06-26 16:29 UTC (permalink / raw)
To: Damon Ding
Cc: hjc, heiko, andy.yan, maarten.lankhorst, mripard, tzimmermann,
airlied, simona, robh, krzk+dt, conor+dt, andrzej.hajda,
neil.armstrong, rfoss, Laurent.pinchart, jonas, jernej.skrabec,
nicolas.frattaroli, cristian.ciocaltea, sebastian.reichel,
dmitry.baryshkov, luca.ceresoli, dianders, m.szyprowski,
dri-devel, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260604085220.2862986-4-damon.ding@rock-chips.com>
On Thu, 04 Jun 2026 16:52:19 +0800, Damon Ding <damon.ding@rock-chips.com> wrote:
Hello Damon,
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> index 7a85774aaac1..e120ef3320c1 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
> @@ -1261,8 +1262,11 @@ static int analogix_dp_dt_parse_pdata(struct analogix_dp_device *dp)
> */
> of_property_read_u32(dp_node, "samsung,link-rate",
> &video_info->max_link_rate);
> - of_property_read_u32(dp_node, "samsung,lane-count",
> - &video_info->max_lane_count);
> + ret = of_property_read_u32(dp_node, "samsung,lane-count",
> + &video_info->max_lane_count);
> + if (ret || !drm_dp_lane_count_is_valid(video_info->max_lane_count))
> + return dev_err_probe(dp->dev, ret ? ret : -EINVAL,
> + "failed to parse samsung,lane-count\n");
I think this report by sashiko makes sense:
> sashiko-bot@kernel.org <sashiko-bot@kernel.org>:
>
> [Severity: High]
> Does this make the optional and deprecated samsung,lane-count property a
> strict requirement?
>
> If samsung,lane-count is absent from the device tree, of_property_read_u32()
> returns -EINVAL. This causes the condition to evaluate to true, aborting the
> probe with an error.
>
> According to the device tree bindings
> (Documentation/devicetree/bindings/display/samsung/samsung,exynos5-dp.yaml),
> this property is marked as deprecated and explicitly optional because the
> lane count can be read from the monitor. Does this patch break compatibility
> with device trees that rightfully omit this deprecated property?
(via: https://patch.msgid.link/20260604090935.7FC051F00898@smtp.kernel.org)
Can you comment on this?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* [PATCH] media: meson: vdec: fix use-after-free of prev_frame in codec_vp9_rm_noshow_frame()
From: Doruk Tan Ozturk @ 2026-06-26 16:40 UTC (permalink / raw)
To: Neil Armstrong, Greg Kroah-Hartman
Cc: Mauro Carvalho Chehab, Hans Verkuil, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, linux-media, linux-amlogic, linux-staging,
linux-arm-kernel, linux-kernel, Doruk Tan Ozturk
codec_vp9_rm_noshow_frame() frees the first non-shown reference frame on
ref_frames_list without excluding vp9->prev_frame. When the previously
decoded frame was a non-show (alt-ref) frame and the current frame is a
non-show inter frame, the freed object is the one vp9->prev_frame still
points to; codec_vp9_set_mpred_mv() then dereferences the stale pointer
(use_prev_frame_mvs and codec_vp9_get_frame_mv_paddr()), a use-after-free.
The sibling cleanup codec_vp9_show_frame() already guards this pointer
(tmp == vp9->prev_frame); rm_noshow_frame() simply omits the same check.
Add it.
The fields that drive this path (show_frame, frame_type, intra_only) are
parsed from the VP9 bitstream, so a crafted stream fed to the stateless
decoder can trigger the free-then-use.
Found by static analysis; not yet runtime-reproduced (Amlogic Meson
hardware required).
Found by 0sec's autonomous vulnerability analysis (https://0sec.ai).
Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai>
---
drivers/staging/media/meson/vdec/codec_vp9.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/media/meson/vdec/codec_vp9.c b/drivers/staging/media/meson/vdec/codec_vp9.c
index 8e80ecf84..572f418c9 100644
--- a/drivers/staging/media/meson/vdec/codec_vp9.c
+++ b/drivers/staging/media/meson/vdec/codec_vp9.c
@@ -1247,6 +1247,15 @@ static void codec_vp9_rm_noshow_frame(struct amvdec_session *sess)
if (tmp->show)
continue;
+ /*
+ * prev_frame is still referenced by the MV predictor in
+ * codec_vp9_set_mpred_mv(); the sibling codec_vp9_show_frame()
+ * already excludes it before freeing. Do the same here to avoid
+ * a use-after-free of vp9->prev_frame.
+ */
+ if (tmp == vp9->prev_frame)
+ continue;
+
pr_debug("rm noshow: %u\n", tmp->index);
v4l2_m2m_buf_queue(sess->m2m_ctx, tmp->vbuf);
list_del(&tmp->list);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v14 29/44] arm64: RMI: Runtime faulting of memory
From: Lorenzo Pieralisi @ 2026-06-26 16:44 UTC (permalink / raw)
To: Gavin Shan
Cc: Suzuki K Poulose, Steven Price, kvm, kvmarm, Catalin Marinas,
Marc Zyngier, Will Deacon, James Morse, Oliver Upton, Zenghui Yu,
linux-arm-kernel, linux-kernel, Joey Gouly, Alexandru Elisei,
Christoffer Dall, Fuad Tabba, linux-coco, Ganapatrao Kulkarni,
Shanker Donthineni, Alper Gun, Aneesh Kumar K . V, Emi Kisanuki,
Vishal Annapurve, WeiLin.Chang, Lorenzo.Pieralisi2
In-Reply-To: <8f81ed99-c53a-4196-baa2-adea9239a000@redhat.com>
On Fri, Jun 26, 2026 at 09:43:03PM +1000, Gavin Shan wrote:
> On 6/26/26 6:47 PM, Suzuki K Poulose wrote:
> > On 26/06/2026 08:43, Gavin Shan wrote:
> > > On 6/26/26 1:58 AM, Suzuki K Poulose wrote:
> > > > On 25/06/2026 14:53, Gavin Shan wrote:
> > > > > On 6/6/26 12:35 AM, Lorenzo Pieralisi wrote:
> > > > > > On Fri, Jun 05, 2026 at 06:11:11PM +1000, Gavin Shan wrote:
> > > > > > > On 6/5/26 5:28 PM, Lorenzo Pieralisi wrote:
> > > > > > > > On Fri, Jun 05, 2026 at 04:23:15PM +1000, Gavin Shan wrote:
> > >
> > > [...]
> > >
> > > > > > >
> > > > > > > I tried to rebase Jean's latest QEMU series [1] to upstream QEMU, and found
> > > > > > > that memory slots backed by THP are broken. With THP disabled on the host and
> > > > > > > other fixes (mentioned in my prevous replies) applied on the top of this (v14)
> > > > > > > series, I'm able to boot a realm guest with rebased QEMU series [2], plus more
> > > > > > > fxies on the top.
> > > > > > >
> > > > > > > [1] https://git.codelinaro.org/linaro/dcap/qemu.git (branch: cca/ latest)
> > > > > > > [2] https://git.qemu.org/git/qemu.git (branch: cca/ gavin)
> > > > > > >
> > > > > > > Lorenzo, You may be saying there is someone making QEMU to support ARM/CCA?
> > > > > >
> > > > > > Mathieu and I are working on that yes and with Steven/Suzuki to fix the THP
> > > > > > issues you pointed out above.
> > > > > >
> > > > > > > If so, I'm not sure if there is a QEMU repository for me to try?
> > > > > >
> > > > > > We should be able to submit patches by end of June - we shall let you know
> > > > > > whether we can make something available earlier.
> > > > > >
> > > > >
> > > > > Not sure if there are other known issues in this series. It seems the stage2
> > > > > page fault handling on the shared space isn't working well. In my test, the
> > > > > vring (struct vring_desc) of virtio-net-pci is updated by the guest, and the
> > > > > data isn't seen by QEMU, I'm suspecting if the host-page-frame-number is properly
> > > > > resolved in the s2 page fault handler for shared (unprotected) space.
> > > > >
> > > > > - I rebased Jean's latest qemu branch to the upstream qemu;
> > > > >
> > > > > - On the host, which is emulated by qemu/tcg, the THP (transparent huge page) is
> > > > > disabled.
> > > > >
> > > > > - On the guest, I can see the virtio vring (struct vring_desc) is updated. The
> > > > > S1 page-table entry looks correct because the corresponding physical address
> > > > > 0x10046880000 is a sane shared (unprotected) space address.
> > > > >
> > > > > [ 52.094143] software IO TLB: Memory encryption is active and system is using DMA bounce buffers
> > > > > [ 52.289746] virtqueue_add_desc_split: desc[0]@0xffff000006880000, [00000100b983f000 00000640 0002 0001]
> > > > > [ 52.432150] PTE 0x00e8010046880707 at address 0xffff000006880000
> > > > >
> > > > > - On the host, the s2 page-table-entry is unmapped due to attribute transition (private -> shared).
> > > > > A subsequent S2 page fault is raised against the adress and the s2 page-table-entry is built.
> > > > >
> > > > > [ 109.259077] ====> realm_unmap_shared_range: tracked_unprot_addr=0x10046880000
> > > > > [ 109.260249] realm_unmap_shared_range: unmapped shared range at 0x10046880000
> > > > > [ 109.317786] realm_unmap_shared_range: unmapped shared range at 0x10046880000
> > > > > [ 109.629939] ====> kvm_handle_guest_abort: fault_ipa=0x10046880000, esr=0x92000007
> > > > > [ 109.630245] realm_map_non_secure: ipa=0x10046880000, pfn=0xb8b59, size=0x1000, prot=0xf
> > > > > [ 109.630331] realm_map_non_secure: ipa=0x10046880000, ipa_top=0x10046881000, flags=0x1e0001, range_desc=0xb8b59004
> > > >
> > > > Are you able to correlate the order of the transitions and the Guest
> > > > access with RMM log ? We haven't seen this from our end. We are aware
> > > > of permission fault issues with Unprotected IPA when backing the memslot
> > > > with MAP_PRIVATE areas. But this looks different.
> > > >
> > > > Lorenzo, have you run into this ?
> > > >
> > >
> > > It's hard to correlate the order since the logs are collected from two separate
> > > consoles. For the write permission, I add code to the host where the permission
> > > is always added for all s2 page faults in the shared space. Otherwise, qemu can
> > > be killed by -EFAULT or similar error.
> >
> > This is the problem. We can't add WRITE permission by default. I believe
> > you may have MAP_PRIVATE mapping and it has to be mapped as READ only
> > and on a permission fault, we replace it with a writable page. By
> > overriding the WRITE permission, you let the guest write to a page
> > that may not be seen by the VMM.
> >
> > We identified this as a bug in the KVM driver in this series (reported
> > by Lorenzo) and there is a corresponding tf-RMM change that is required
> > to get this working. So, please could you wait until the next series
> > when this will be addressed ? Or you could switch to using MAP_SHARED
> > for the "shared" memory in the memslot.
> >
>
> Exactly. the syntax for MAP_PRIVATE is broken if the write permission is
> enforced for a read fault in the shared space. In my case, the host page can
> be the zero page and eventually multiple s2 page-table entries (for multiple
> unprotected or shared pages) point to the zero page. It's why clearing the
> 3rd queue (Ctrl queue) also clears the first queue (Rx queue) in my case.
>
> Yes, this issue can be avoid by using a shared memory backend in qemu, something
> like below. With this, I'm able to see virtio-net-pci starts to work...
>
> -object memory-backend-ram,id=mem0,size=2G,share=yes
Yes, as Suzuki said that's what we have been fixing. QEmu patches
will be on the mailing lists very shortly - the KVM/tf-RMM fixes
to make MAP_PRIVATE work will be included in the next posting.
Feel free to drop your QEmu command line so that I can give it
a shot and check whether the fixes solve the problem you hit
(I think so because that's precisely the kind of issue I got
into when I started debugging THP/MAP_PRIVATE but it is better
to check).
Thanks,
Lorenzo
^ permalink raw reply
* Re: [PATCH v2 1/8] dt-bindings: media: Add macros for video interface devices
From: Frank Li @ 2026-06-26 16:47 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, 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, Conor Dooley
In-Reply-To: <20260626-kbingham-orientation-v2-1-47178be927b4@ideasonboard.com>
On Fri, Jun 26, 2026 at 01:07:53PM +0100, 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>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.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__ */
>
> --
> 2.52.0
>
>
^ permalink raw reply
* Re: [PATCH v2 2/8] media: dt-bindings: video-interface-devices: add video-interface-devices.h references
From: Frank Li @ 2026-06-26 16:47 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, 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>
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>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.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
>
> --
> 2.52.0
>
>
^ 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 16:51 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-classy-nightingale-of-romance-1cacad@houat>
On Fri Jun 26, 2026 at 4:38 PM CEST, Maxime Ripard wrote:
> 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_connector_manager?
drm_bridge_connector_manager?
> 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.
What? o_O
Several encoder drivers have been painfully converted to create a
drm_bridge_connector. Now if the bridges start doing it themselves we
should go back to those encoder drivers and ditch all the
drm_bridge_connector from there?
I must be missing something. Can you elaborate on this?
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
From: Luiz Augusto von Dentz @ 2026-06-26 16:54 UTC (permalink / raw)
To: Rong Zhang
Cc: Chris Lu (陸稚泓),
patchwork-bot+bluetooth@kernel.org, marcel@holtmann.org,
AngeloGioacchino Del Regno, SS Wu (巫憲欣),
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-bluetooth@vger.kernel.org,
linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com
In-Reply-To: <17FE08E9-2229-4C97-846F-6FA099E22C90@rong.moe>
Hi,
On Fri, Jun 26, 2026 at 7:19 AM Rong Zhang <i@rong.moe> wrote:
>
> Hi Chris,
>
> 于 2026年6月26日 GMT+08:00 10:40:54，"Chris Lu (陸稚泓)" <Chris.Lu@mediatek.com> 写道：
> >Hi Luiz,
> >
> >Could we revert this change?
>
> Please don't. The fundamental goal of the patch is to make MT7922/MT7925 *usable* on affected platforms.
>
> Moreover, almost all recent AMD platforms ship with MT7922/MT7925, reverting this patch affects quite a lot of users. Almost every AMD platform I've met suffers from the issue, and there are plenty of bug reports.
>
> Intel platforms never ship with MTK WLAN NICs, so I can't tell if the issue is reproducible on them.
We cannot really remove it anymore, since it has already been pulled.
Therefore, I strongly prefer that the issue is fixed somehow or if
there is no other way then a proper revert patch must be sent, since I
don't have any hardware with this controller I cannot really test this
myself.
> >
> >Sorry, MediaTek wasn't aware someone submitted this change and it had
> >already been merged.
> >
> >MTK believes this issue is strongly related to the platform's USB hub
> >behavior,
>
> Still, I believe that there are some interoperability issues in MT7922/MT7925's hardware or firmware, as reinitializing the XHCI root hub (by logically removing it from the PCI bus and probing it again) doesn't make it recover at all.
>
> > The product lines MTK directly support haven't reported such
> >issue.
>
> ...or did you mean none of the existing AMD platforms are supported by MTK?
>
> >
> >Disable wake capability would severely impact wake on Bluetooth on
> >MTK's official product lines.
>
> Could you kindly explain "MTK's official product lines"?
>
> > Furthermore, this patch looks like a
> >workaround. There should be a better way to handle this issue. We hope
> >this change can be reverted.
>
> The issue is severe on affected platforms by making the Bluetooth interface completely gone. IMHO, we must figure out the "better way" before reverting it, or else it's more like burying your head into sand by shouting "works fine on our platforms" (TM).
>
> That being said, I think we can narrow the range of the quirk down to AMD platforms only. Does it make sense to you? If so, I will submit a patch for this.
Ok, then you guys please coordinate. I don't want to start requiring
Sign-Off-By (SOB) from driver authors because this instance shows that
response time can be very long. Therefore, the best way forward in my
opinion, is to have the issue fixed in a way that works for both of
you.
^ permalink raw reply
* Re: [PATCH v2 4/8] ARM: tegra: Convert to new media orientation definitions
From: Kieran Bingham @ 2026-06-26 16:58 UTC (permalink / raw)
To: Laurent Pinchart
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: <20260626143310.GF2363897@killaraus.ideasonboard.com>
Quoting Laurent Pinchart (2026-06-26 15:33:10)
> 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(-)
> >
<snip>
> > 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>;
>
It must have been hot when I typed that one out...
> This should be MEDIA_ORIENTATION_BACK. And you should compile all the
> device trees the series touch.
Indeed, I got caught out by these being in arm, with the others in arm64
even though I explicitly pulled these out to a separate patch!
Fixed up and now I have compiled also with:
make O=arm32 ARCH=arm multi_v7_defconfig
make O=arm32 ARCH=arm dtbs -j32
which looks clean.
> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Thanks
Kieran
>
> > rotation = <90>;
> >
> > nvmem = <&m24c08>;
>
> --
> Regards,
>
> Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v5 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Andrea della Porta @ 2026-06-26 17:09 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Andrea della Porta, Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
mbrugger, Krzysztof Kozlowski
In-Reply-To: <5b167316-ed50-448c-aa05-6a041a6544d5@suse.de>
Hi Stan,
On 18:24 Fri 12 Jun , Stanimir Varbanov wrote:
>
>
> On 6/12/26 5:01 PM, Andrea della Porta wrote:
> > From: Naushir Patuck <naush@raspberrypi.com>
> >
> > Add the devicetree binding documentation for the PWM
> > controller found in the Raspberry Pi RP1 chipset.
> >
> > Signed-off-by: Naushir Patuck <naush@raspberrypi.com>
> > Co-developed-by: Stanimir Varbanov <svarbanov@suse.de>
> > Signed-off-by: Stanimir Varbanov <svarbanov@suse.de>
> > Signed-off-by: Andrea della Porta <andrea.porta@suse.com>
> > Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> > ---
> > .../bindings/pwm/raspberrypi,rp1-pwm.yaml | 54 +++++++++++++++++++
> > 1 file changed, 54 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
> > new file mode 100644
> > index 0000000000000..6f8461d0454f7
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pwm/raspberrypi,rp1-pwm.yaml
> > @@ -0,0 +1,54 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pwm/raspberrypi,rp1-pwm.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Raspberry Pi RP1 PWM controller
> > +
> > +maintainers:
> > + - Naushir Patuck <naush@raspberrypi.com>
>
> Could you add you or me as a maintainer as well. I'm not sure Naushir
> had agreed to maintain the bindings in mainline.
>
Sure, will do.
Thanks,
Andrea
> ~Stan
^ permalink raw reply
* Re: [PATCH v4 0/4] arm64: cross-CPU NMI via SDEI
From: Catalin Marinas @ 2026-06-26 17:07 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel, Kiryl Shutsemau (Meta)
In-Reply-To: <cover.1781709543.git.kas@kernel.org>
On Wed, Jun 17, 2026 at 08:20:01PM +0100, Kiryl Shutsemau wrote:
> - A CPU stopped by the SDEI rung is parked, not powered off via PSCI
> CPU_OFF. Reaching and dumping the wedged CPU -- the point of the
> series -- works, and it matches the shared stop path's own park
> fallback when CPU_OFF is unavailable. The consequence is that an SMP
> crash-capture kernel cannot re-online such a CPU (it stays "already
> on"); the capture kernel boots and runs on the remaining CPUs.
> Powering the stopped CPU off so a capture kernel can reclaim it
> requires completing the SDEI event and then CPU_OFF, which hit a
> firmware-specific issue still under investigation; it is left as a
> follow-up and does not affect the dump's contents.
Just to understand, your firmware cannot cope with a PSCI CPU_OFF from
the SDEI handler? This is one of the required calls to be supported.
--
Catalin
^ permalink raw reply
* Re: [PATCH v4 4/4] arm64: escalate smp_send_stop() to an SDEI NMI as a last resort
From: Catalin Marinas @ 2026-06-26 17:08 UTC (permalink / raw)
To: Kiryl Shutsemau
Cc: Will Deacon, James Morse, Mark Rutland, Marc Zyngier,
Doug Anderson, Petr Mladek, Thomas Gleixner, Andrew Morton,
Baoquan He, Puranjay Mohan, Usama Arif, Breno Leitao,
Julien Thierry, Lecopzer Chen, Sumit Garg, kernel-team, kexec,
linux-arm-kernel, linux-kernel, Kiryl Shutsemau (Meta)
In-Reply-To: <97a870d0670b7e1c2fb9f5142f6e36c594282017.1781709543.git.kas@kernel.org>
On Wed, Jun 17, 2026 at 08:20:05PM +0100, Kiryl Shutsemau wrote:
> +void sdei_nmi_stop_cpus(const cpumask_t *mask)
> +{
> + unsigned int cpu;
> +
> + WRITE_ONCE(sdei_nmi_stopping, true);
> +
> + /*
> + * Publish the flag before signalling. The SMC is a context-sync
> + * event, not a barrier, so WRITE_ONCE() alone could let the store be
> + * observed after the event it triggers. The barrier is cumulative: a
> + * target that sees the event is guaranteed to see the flag.
> + */
> + smp_wmb();
> +
> + for_each_cpu(cpu, mask)
> + sdei_nmi_fire(cpu);
> +}
The smp_wmb() is not sufficient here. In the GIC IPI code we use a
dsb(ishst). It should be similar here. I think TF-A does this already
but it's unclear from the SDEI spec that it is mandated.
--
Catalin
^ 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