* Re: [PATCH v2 5/6] gpio: remove machine hogs
From: Dmitry Torokhov @ 2026-05-20 5:27 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Linus Walleij, Bartosz Golaszewski, Geert Uytterhoeven,
Frank Rowand, Mika Westerberg, Andy Shevchenko, Aaro Koskinen,
Janusz Krzysztofik, Tony Lindgren, Russell King, Jonathan Corbet,
Shuah Khan, linux-gpio, linux-kernel, linux-acpi,
linux-arm-kernel, linux-omap, linux-doc
In-Reply-To: <ag0Dn66ZVnbTc7J2@google.com>
On Tue, May 19, 2026 at 05:46:50PM -0700, Dmitry Torokhov wrote:
> On Mon, Mar 09, 2026 at 01:42:41PM +0100, Bartosz Golaszewski wrote:
> > With no more users, remove legacy machine hog API from the kernel.
> >
> > Reviewed-by: Linus Walleij <linusw@kernel.org>
> > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
> Argh! What is the replacement for this? I have patches for rsk7203 to
> use them to get rid of legacy gpio use, like this:
>
> diff --git a/arch/sh/boards/mach-rsk/devices-rsk7203.c b/arch/sh/boards/mach-rsk/devices-rsk7203.c
> index f8760a91e2f1..5bbd3b31cffb 100644
> --- a/arch/sh/boards/mach-rsk/devices-rsk7203.c
> +++ b/arch/sh/boards/mach-rsk/devices-rsk7203.c
> @@ -12,7 +12,7 @@
> #include <linux/smsc911x.h>
> #include <linux/input.h>
> #include <linux/io.h>
> -#include <linux/gpio.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/gpio/machine.h>
> #include <linux/gpio/property.h>
> #include <asm/machvec.h>
> @@ -165,6 +165,19 @@ static const struct platform_device_info rsk7203_devices[] __initconst = {
> },
> };
>
> +/* The base of the function GPIOs in the flat enum */
> +#define SH7203_FN_BASE GPIO_FN_PINT7_PB
> +
> +static struct gpiod_hog rsk7203_gpio_hogs[] = {
> + GPIO_HOG("sh7203_pfc-fn", GPIO_FN_TXD0 - SH7203_FN_BASE,
> + "TXD0", GPIO_ACTIVE_HIGH, GPIOD_ASIS),
> + GPIO_HOG("sh7203_pfc-fn", GPIO_FN_RXD0 - SH7203_FN_BASE,
> + "RXD0", GPIO_ACTIVE_HIGH, GPIOD_ASIS),
> + GPIO_HOG("sh7203_pfc-fn", GPIO_FN_IRQ0_PB - SH7203_FN_BASE,
> + "IRQ0_PB", GPIO_ACTIVE_HIGH, GPIOD_ASIS),
> + { }
> +};
> +
> static int __init rsk7203_devices_setup(void)
> {
> struct platform_device *pd;
> @@ -172,12 +185,10 @@ static int __init rsk7203_devices_setup(void)
> int i;
>
> /* Select pins for SCIF0 */
> - gpio_request(GPIO_FN_TXD0, NULL);
> - gpio_request(GPIO_FN_RXD0, NULL);
> + gpiod_add_hogs(rsk7203_gpio_hogs);
>
> /* Setup LAN9118: CS1 in 16-bit Big Endian Mode, IRQ0 at Port B */
> __raw_writel(0x36db0400, 0xfffc0008); /* CS1BCR */
> - gpio_request(GPIO_FN_IRQ0_PB, NULL);
>
> error = software_node_register_node_group(rsk7203_swnodes);
> if (error) {
>
>
> If there is no replacement maybe we can resurrect this? Or shoudl we
> have add swnode support for hogs?
Hmm, I guess it is already there so I should simply switch. Sorry about
the noise.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] arm64/mm: Rename ptdesc_t
From: David Hildenbrand (Arm) @ 2026-05-20 5:26 UTC (permalink / raw)
To: Anshuman Khandual, Will Deacon, Mike Rapoport
Cc: linux-arm-kernel, Catalin Marinas, linux-efi, linux-kernel
In-Reply-To: <2f60361d-43b9-4f7f-b786-7852d081f4a1@arm.com>
On 5/20/26 04:08, Anshuman Khandual wrote:
>
>
> On 19/05/26 4:32 PM, David Hildenbrand (Arm) wrote:
>> On 5/19/26 12:44, Will Deacon wrote:
>>>
>>> Yeah, the 'pxx' prefix really hurts my eyes. Please use something else!
>>
>> Fine with me as long as we don't call it something with "pte" in it.
>>
>
> Seems like there are two choices here
>
> (A) pxdval_t
> (B) ptval_t which Mike had suggested earlier
>
> Unless there is a preference will probably go with pxdval_t
given it is ptdesc_t, ptval_t sounds better to me.
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH 8/8] arm64: dts: qcom: monaco: add AEST error nodes
From: Umang Chheda @ 2026-05-20 5:04 UTC (permalink / raw)
To: Konrad Dybcio, Ruidong Tian, Tony Luck, Borislav Petkov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, catalin.marinas, will, lpieralisi, rafael,
mark.rutland, Sudeep Holla
Cc: linux-arm-msm, linux-acpi, linux-arm-kernel, linux-edac,
linux-kernel, devicetree, Faruque Ansari
In-Reply-To: <71eee892-1c0b-49e7-a82d-9016c56e8592@oss.qualcomm.com>
On 5/12/2026 4:58 PM, Konrad Dybcio wrote:
> On 5/5/26 2:23 PM, Umang Chheda wrote:
>> Add AEST RAS error source nodes for the Monaco SoC.
>>
>> The DT describes a processor error source covering all CPU cores and a
>> shared L3 cache error source for the cluster. These nodes model the
>> hardware error reporting blocks and associated interrupts as required
>> by the Arm AEST specification.
>>
>> Co-developed-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
>> Signed-off-by: Faruque Ansari <faruque.ansari@oss.qualcomm.com>
>> Signed-off-by: Umang Chheda <umang.chheda@oss.qualcomm.com>
>> ---
>> arch/arm64/boot/dts/qcom/monaco.dtsi | 41 ++++++++++++++++++++++++++++++++++++
>> 1 file changed, 41 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
>> index 7b1d57460f1e..8e43ceed7d84 100644
>> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
>> @@ -3,6 +3,7 @@
>> * Copyright (c) 2024 Qualcomm Innovation Center, Inc. All rights reserved.
>> */
>>
>> +#include <dt-bindings/arm/aest.h>
>> #include <dt-bindings/clock/qcom,dsi-phy-28nm.h>
>> #include <dt-bindings/clock/qcom,qcs8300-gcc.h>
>> #include <dt-bindings/clock/qcom,rpmh.h>
>> @@ -29,6 +30,46 @@ / {
>> #address-cells = <2>;
>> #size-cells = <2>;
>>
>> + aest {
>> + compatible = "arm,aest";
>> + #address-cells = <2>;
>> + #size-cells = <2>;
>> + ranges;
>
> These 3 properties aren't necessary if none of the subnodes have a
> 'reg' property
Ack
>
> Konrad
Thanks,
Umang
^ permalink raw reply
* RE: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Chancel Liu (OSS) @ 2026-05-20 5:02 UTC (permalink / raw)
To: Krzysztof Kozlowski, Chancel Liu
Cc: robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
Frank Li, s.hauer@pengutronix.de, festevam@gmail.com,
mturquette@baylibre.com, sboyd@kernel.org, kernel@pengutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-clk@vger.kernel.org, Chancel Liu (OSS)
In-Reply-To: <20260519-macho-degu-from-nibiru-960af2@quoll>
> > > >>> +description:
> > > >>> + The NXP I/O connector represents a physically present I/O
> > > >>> +connector on the
> > > >>> + base board. It acts as a nexus that exposes a constrained set
> of
> > > >>> +I/O
> > > >>> + resources, such as GPIOs, clocks, PWMs and interrupts, through
> > > >>> +fixed
> > > >>> + electrical wiring. All actual hardware providers reside on the
> base
> > > board.
> > > >>> + The connector node only defines index-based mappings to those
> > > >> providers.
> > > >>> +
> > > >>> +properties:
> > > >>> + compatible:
> > > >>> + const: fsl,io-connector
> > > >>
> > > >> Everything is IO. Everything is connector, so your compatible does
> > > >> not match requirements from writing bindings.
> > > >>
> > > >
> > > > Yes, this compatible is too generic. I will rename the compatible to
> > > > fsl,aud-io-connector.
> > >
> > > aud is not much better. Which boards have it? What's the pinout?
> What's
> > > standard? Is it described anywhere? If so, provide reference to
> spec/docs.
> > >
> >
> > This is not an industry standard electrical interface. This connector
>
> Then if you do not have standard, then you have board specific layouts
> thus you need board-specific compatibles. You can use fallbacks. Generic
> fallback could work, but both io-connector and aud-io-connector are just
> too generic. Every connector is "connector" and "io", thus absolutely
> anything can be "io-connector". "aud" improves it only a bit, thus
> honestly I would go with board specific fallback as well.
>
How about board specific + common fallback compatible like this:
compatible:
items:
- enum:
- fsl,imx95-19x19-evk-aud-io-connector
- fsl,imx952-evk-aud-io-connector
- const: fsl,imx-aud-io-connector
Since the daughter board is named “IMX-AUD-IO” in publicly available
documentation, common compatible clearly indicates that this connector
is intended for that.
Also, I want to talk about the topic of generic connector. It's a common
design that daughter board is connected to base board through a
connector. This connector more often acts as a nexus that exposes a
constrained subset of GPIO, clock, PWM and interrupt resources to the
daughter board. Can we document this kind of connector as a generic
binding?
Regards,
Chancel Liu
> > is present on i.MX95-19x19-EVK and i.MX952-EVK. For example, the
> > "i.MX 95 19mm x 19mm Evaluation Kit" homepage[1] publicly documents an
> > audio board connection through which IMX-AUD-IO card is connected. The
> > detailed user manual (UM12022) is listed as official documentation[2],
> > but it is behind an NXP login, so it is not suitable as a public
> > reference for upstream. Therefore I list it here to illustrate it's
> > mechanism:
> >
> > +-----------------------------+
> > | Base Board |
> > | +-----+ +---------+ | +---------+
> > | | SPI +------+ | | | |
> > | +-----+ | | | GPIO MAP | |
> > | | +--|-----------+ |
> > | +-----+ | | | | |
> > | | I2C +------+ | | | |
> > | +-----+ | | | CLOCK MAP | AUD-IO |
> > | |connector+--|-----------+ CARD |
> > | +-----+ | | | | |
> > | | I2S +------+ | | | |
> > | +-----+ | | | | |
> > | | | | INT MAP | |
> > | +-----+ | +--|-----------+ |
> > | | I/O +------+ | | | |
> > | +-----+ +---------+ | +---------+
> > +-----------------------------+
> >
> > [1]https://www.nxp.com/design/design-center/development-boards-and-
> designs/IMX95LPD5EVK-19
> > [2]https://docs.nxp.com/bundle/UM12022/page/topics/pcie_interface1.html
>
> Best regards,
> Krzysztof
^ permalink raw reply
* [PATCH] arm64: Add user and kernel page-fault tracepoints
From: Justinien Bouron @ 2026-05-20 4:55 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon, David Hildenbrand, Mark Rutland,
Ryan Roberts, Ada Couprie Diaz, Kevin Brodsky, Lorenzo Stoakes,
Quentin Perret, linux-arm-kernel, linux-kernel
Cc: Justinien Bouron, Gunnar Kudrjavets
Those tracepoints were made generic in commit 06aa9378df01
("x86/tracing, x86/mm: Move page fault tracepoints to generic"), call
them from arm64's page fault handling routine.
Signed-off-by: Justinien Bouron <jbouron@amazon.com>
Reviewed-by: Gunnar Kudrjavets <gunnarku@amazon.com>
---
Benchmarking
============
Since the added code sits in the page-fault handling hot-path, I've also
ran some benchmarks to make sure this change is not accidentally
introducing a regression. All testing below was done on a c6g.metal EC2
instance (i.e. bare-metal) which is an ARM64 CPU with 64 cores and
128GiB of RAM.
First, a microbenchmark that maps anonymous memory and write to the
first four bytes of each page, thus running into page-fault for each
one:
```
#include <stdio.h>
#include <sys/mman.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>
#include <assert.h>
int main(int argc, char **argv) {
int npages = atoi(argv[1]);
size_t size = npages * 4096;
printf("pid = %d\n", getpid());
char *p = mmap((void*)0xcafe0000,
size,
PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED,
-1, 0);
assert(p != MAP_FAILED);
for (int i = 0; i < npages; i++)
*(uint32_t *)(p + i * 4096) = 0xdeadbeef;
munmap(p, size);
}
```
Compiled with: `gcc microbench.c -no-pie -o microbench` (GCC 15.2.0)
Before the change:
$ hyperfine --runs 50 './microbench 100000'
Benchmark 1: ./microbench 100000
Time (mean +/- stddev): 174.3 ms +/- 3.4 ms [User: 5.9 ms, System: 168.3 ms]
Range (min ... max): 168.7 ms ... 185.1 ms 50 runs
After the change:
$ hyperfine --runs 50 './microbench_orig 100000'
Benchmark 1: ./microbench 100000
Time (mean +/- stddev): 177.9 ms +/- 3.1 ms [User: 6.3 ms, System: 171.6 ms]
Range (min ... max): 173.3 ms ... 186.0 ms 50 runs
Second benchmark, linux kernel compilation benchmark with defconfig (on
commit 70390501):
Before the change:
$ hyperfine --runs 3 --prepare 'make clean && sync && echo 3 | sudo tee /proc/sys/vm/drop_caches' 'make -j65'
Benchmark 1: make -j65
Time (mean +/- stddev): 155.744 s +/- 2.767 s [User: 6812.900 s, System: 1156.095 s]
Range (min ... max): 153.709 s ... 158.895 s 3 runs
After the change:
$ hyperfine --runs 3 --prepare 'make clean && sync && echo 3 | sudo tee /proc/sys/vm/drop_caches' 'make -j65'
Benchmark 1: make -j65
Time (mean +/- stddev): 153.315 s +/- 0.179 s [User: 6799.948 s, System: 1148.976 s]
Range (min ... max): 153.119 s ... 153.471 s 3 runs
Testing
=======
Re-using the microbenchmark above, we can see the page-faults generated
by writing to each mmap'ed page (mmap'ed region starts at address
0xcafe0000):
```
$ sudo perf record -e exceptions:page_fault_user -- ./microbench 16
pid = 307352
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.015 MB perf.data (63 samples) ]
$ sudo perf script
microbench 307352 [034] 29395.753387: exceptions:page_fault_user: address=0xfffff7fda640 ip=0xfffff7fda640 error_code=0x82000007
microbench 307352 [034] 29395.753406: exceptions:page_fault_user: address=0xfffff7fff066 ip=0xfffff7fd60c4 error_code=0x92000007
microbench 307352 [034] 29395.753407: exceptions:page_fault_user: address=0xfffff7fff066 ip=0xfffff7fd60cc error_code=0x9200004f
microbench 307352 [034] 29395.753410: exceptions:page_fault_user: address=0xfffff7ffde28 ip=0xfffff7fd60d0 error_code=0x92000007
microbench 307352 [034] 29395.753412: exceptions:page_fault_user: address=0xfffff7ffde70 ip=0xfffff7fd619c error_code=0x9200004f
microbench 307352 [034] 29395.753416: exceptions:page_fault_user: address=0xfffff7fbeb38 ip=0xfffff7fd6304 error_code=0x92000007
microbench 307352 [034] 29395.753419: exceptions:page_fault_user: address=0xfffff7ffcd28 ip=0xfffff7fd62f8 error_code=0x9200004f
microbench 307352 [034] 29395.753422: exceptions:page_fault_user: address=0xffffffffeff0 ip=0xfffff7fcfa90 error_code=0x92000047
microbench 307352 [034] 29395.753428: exceptions:page_fault_user: address=0xfffff7fe1b90 ip=0xfffff7fdc9b0 error_code=0x92000007
microbench 307352 [034] 29395.753431: exceptions:page_fault_user: address=0x400040 ip=0xfffff7fd7160 error_code=0x92000007
microbench 307352 [034] 29395.753432: exceptions:page_fault_user: address=0x41fdf8 ip=0xfffff7fd72f0 error_code=0x92000007
microbench 307352 [034] 29395.753434: exceptions:page_fault_user: address=0xfffff7ffa020 ip=0xfffff7fd7548 error_code=0x92000007
microbench 307352 [034] 29395.753437: exceptions:page_fault_user: address=0xfffff7ffb000 ip=0xfffff7fd7640 error_code=0x92000007
microbench 307352 [034] 29395.753443: exceptions:page_fault_user: address=0xfffff7ff4008 ip=0xfffff7fc4848 error_code=0x92000047
microbench 307352 [034] 29395.753446: exceptions:page_fault_user: address=0x41fec0 ip=0xfffff7fd7cd0 error_code=0x9200004f
microbench 307352 [034] 29395.753464: exceptions:page_fault_user: address=0xfffff7fed000 ip=0xfffff7fd11c4 error_code=0x92000007
microbench 307352 [034] 29395.753502: exceptions:page_fault_user: address=0xfffff7fa14d8 ip=0xfffff7fdcbe0 error_code=0x92000047
microbench 307352 [034] 29395.753509: exceptions:page_fault_user: address=0xfffff7f9fa88 ip=0xfffff7fc54c0 error_code=0x92000007
microbench 307352 [034] 29395.753512: exceptions:page_fault_user: address=0xfffff7f9fb20 ip=0xfffff7fc5534 error_code=0x9200004f
microbench 307352 [034] 29395.753515: exceptions:page_fault_user: address=0xfffff7de02e0 ip=0xfffff7fc5704 error_code=0x92000006
microbench 307352 [034] 29395.753519: exceptions:page_fault_user: address=0xfffff7f887c8 ip=0xfffff7fc4bb0 error_code=0x92000007
microbench 307352 [034] 29395.753522: exceptions:page_fault_user: address=0xfffff7dffcef ip=0xfffff7fdc358 error_code=0x92000007
microbench 307352 [034] 29395.753526: exceptions:page_fault_user: address=0xfffff7e01650 ip=0xfffff7fd027c error_code=0x92000007
microbench 307352 [034] 29395.753530: exceptions:page_fault_user: address=0xfffff7ff5610 ip=0xfffff7fdcc10 error_code=0x92000047
microbench 307352 [034] 29395.753534: exceptions:page_fault_user: address=0xfffff7f9d080 ip=0xfffff7fcb6a4 error_code=0x9200004f
microbench 307352 [034] 29395.753538: exceptions:page_fault_user: address=0xfffff7f9e000 ip=0xfffff7fcb6fc error_code=0x9200004f
microbench 307352 [034] 29395.753542: exceptions:page_fault_user: address=0xfffff7fa02d8 ip=0xfffff7fcb6a4 error_code=0x9200004f
microbench 307352 [034] 29395.753568: exceptions:page_fault_user: address=0xfffff7e821c0 ip=0xfffff7e821c0 error_code=0x82000007
microbench 307352 [034] 29395.753585: exceptions:page_fault_user: address=0xfffff7feb000 ip=0xfffff7fc1a40 error_code=0x92000047
microbench 307352 [034] 29395.753594: exceptions:page_fault_user: address=0xfffff7f2b1e0 ip=0xfffff7f2b1e0 error_code=0x82000007
microbench 307352 [034] 29395.753596: exceptions:page_fault_user: address=0xfffff7e1188c ip=0xfffff7e1188c error_code=0x82000007
microbench 307352 [034] 29395.753597: exceptions:page_fault_user: address=0xfffff7fa7458 ip=0xfffff7f2b21c error_code=0x92000047
microbench 307352 [034] 29395.753600: exceptions:page_fault_user: address=0xfffff7fade39 ip=0xfffff7f2b224 error_code=0x92000047
microbench 307352 [034] 29395.753601: exceptions:page_fault_user: address=0xfffff7ecdd20 ip=0xfffff7ecdd20 error_code=0x82000007
microbench 307352 [034] 29395.753603: exceptions:page_fault_user: address=0xfffff7fa6518 ip=0xfffff7f2b2a0 error_code=0x92000047
microbench 307352 [034] 29395.753605: exceptions:page_fault_user: address=0xfffff7e6ec50 ip=0xfffff7e6ec50 error_code=0x82000007
microbench 307352 [034] 29395.753607: exceptions:page_fault_user: address=0xfffff7fa2180 ip=0xfffff7e1c918 error_code=0x92000047
microbench 307352 [034] 29395.753609: exceptions:page_fault_user: address=0xfffff7e7dac8 ip=0xfffff7e7dac8 error_code=0x82000007
microbench 307352 [034] 29395.753623: exceptions:page_fault_user: address=0xfffff7ed6720 ip=0xfffff7ed6720 error_code=0x82000007
microbench 307352 [034] 29395.753626: exceptions:page_fault_user: address=0xfffff7e28220 ip=0xfffff7e28220 error_code=0x82000007
microbench 307352 [034] 29395.753627: exceptions:page_fault_user: address=0xfffff7f349e2 ip=0xfffff7e282b8 error_code=0x92000007
microbench 307352 [034] 29395.753629: exceptions:page_fault_user: address=0xfffff7ead1c0 ip=0xfffff7ead1c0 error_code=0x82000007
microbench 307352 [034] 29395.753631: exceptions:page_fault_user: address=0xfffff7e39e40 ip=0xfffff7e39e40 error_code=0x82000007
microbench 307352 [034] 29395.753633: exceptions:page_fault_user: address=0xfffff7f453c4 ip=0xfffff7e37c58 error_code=0x92000007
microbench 307352 [034] 29395.753635: exceptions:page_fault_user: address=0xfffff7f53412 ip=0xfffff7e2e788 error_code=0x92000007
microbench 307352 [034] 29395.753636: exceptions:page_fault_user: address=0xfffff7e53bc0 ip=0xfffff7e53bc0 error_code=0x82000007
microbench 307352 [034] 29395.753643: exceptions:page_fault_user: address=0x421008 ip=0xfffff7e7bbc8 error_code=0x92000047
microbench 307352 [034] 29395.753658: exceptions:page_fault_user: address=0xcafe0000 ip=0x4008e4 error_code=0x92000045
microbench 307352 [034] 29395.753663: exceptions:page_fault_user: address=0xcafe1000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753664: exceptions:page_fault_user: address=0xcafe2000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753666: exceptions:page_fault_user: address=0xcafe3000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753675: exceptions:page_fault_user: address=0xcafe4000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753676: exceptions:page_fault_user: address=0xcafe5000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753678: exceptions:page_fault_user: address=0xcafe6000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753679: exceptions:page_fault_user: address=0xcafe7000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753681: exceptions:page_fault_user: address=0xcafe8000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753682: exceptions:page_fault_user: address=0xcafe9000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753684: exceptions:page_fault_user: address=0xcafea000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753686: exceptions:page_fault_user: address=0xcafeb000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753687: exceptions:page_fault_user: address=0xcafec000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753689: exceptions:page_fault_user: address=0xcafed000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753691: exceptions:page_fault_user: address=0xcafee000 ip=0x4008e4 error_code=0x92000047
microbench 307352 [034] 29395.753692: exceptions:page_fault_user: address=0xcafef000 ip=0x4008e4 error_code=0x92000047
```
IP 0x4008e4 corresponds to the instruction where the write to each page
is performed:
```
4008c8: b9402be0 ldr w0, [sp, #40]
4008cc: 53144c00 lsl w0, w0, #12
4008d0: 93407c00 sxtw x0, w0
4008d4: f9401fe1 ldr x1, [sp, #56]
4008d8: 8b000020 add x0, x1, x0
4008dc: 5297dde1 mov w1, #0xbeef // #48879
4008e0: 72bbd5a1 movk w1, #0xdead, lsl #16
=> 4008e4: b9000001 str w1, [x0]
4008e8: b9402be0 ldr w0, [sp, #40]
4008ec: 11000400 add w0, w0, #0x1
4008f0: b9002be0 str w0, [sp, #40]
4008f4: b9402be1 ldr w1, [sp, #40]
4008f8: b9402fe0 ldr w0, [sp, #44]
4008fc: 6b00003f cmp w1, w0
400900: 54fffe4b b.lt 4008c8 <main+0x9c> // b.tstop
```
First error_code when writing to the mmap'ed region is 0x92000045 which,
as expected, corresponds to user-mode, write fault, at page-table level
1 (see https://esr.arm64.dev/#0x92000045). Following faults have similar
error_code but for page-table level 3 fault
(https://esr.arm64.dev/#0x92000047).
For kernel page-faults, tested using tracepoints directly:
```
# echo 1 > events/exceptions/page_fault_kernel/enable
# echo test
test
# cat trace_pipe
ps-307392 [028] ..... 29802.331281: page_fault_kernel: address=0xaaaaaaae0280 ip=__arch_clear_user error_code=0x96000044
ps-307392 [028] ..... 29802.331303: page_fault_kernel: address=0xfffff7ffe8e4 ip=__arch_clear_user error_code=0x96000046
ps-307392 [028] ..... 29802.331851: page_fault_kernel: address=0xfffff7f13360 ip=strncpy_from_user error_code=0x96000007
ps-307392 [028] ..... 29802.349787: page_fault_kernel: address=0xaaaaaab23000 ip=__arch_copy_to_user error_code=0x96000047
...
```
---
arch/arm64/mm/fault.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 0f3c5c7ca054..e75cc0348e74 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -45,6 +45,9 @@
#include <asm/traps.h>
#include <asm/virt.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/exceptions.h>
+
struct fault_info {
int (*fn)(unsigned long far, unsigned long esr,
struct pt_regs *regs);
@@ -606,6 +609,11 @@ static int __kprobes do_page_fault(unsigned long far, unsigned long esr,
int si_code;
int pkey = -1;
+ if (user_mode(regs))
+ trace_page_fault_user(addr, regs, esr);
+ else
+ trace_page_fault_kernel(addr, regs, esr);
+
if (kprobe_page_fault(regs, esr))
return 0;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] ARM: mach-rpc: fix zImage build after recent font-related changes
From: Ethan Nelson-Moore @ 2026-05-20 4:49 UTC (permalink / raw)
To: Helge Deller; +Cc: linux-arm-kernel, linux-fbdev, Russell King
In-Reply-To: <agwpPFGkN3zHKdCj@carbonx1>
Hi, Helge,
Thanks for investigating this issue.
On Tue, May 19, 2026 at 2:11 AM Helge Deller <deller@kernel.org> wrote:
> Ethan, does this compile-only-tested patch fix the issue?
It almost does - I also had to remove #include <linux/math.h> from
include/linux/font.h.
This is probably because of the following highly questionable code in
arch/arm/boot/compressed/Makefile:
CFLAGS_font.o := -Dstatic=
which is causing unused static functions to not be optimized out. (The
real purpose of it is to make the acorndata_8x8 array non-static so
the decompressor can use it.) Really, the decompressor should be fixed
to not use this hack.
> Maybe only the first hunk is necessary.
You're right. The kernel links successfully with only the #include
<linux/math.h> removal and the first hunk applied.
Have a nice day!
Ethan
^ permalink raw reply
* [PATCH v3] media: meson: vdec: Fix memory leak in error path of vdec_open
From: Anand Moon @ 2026-05-20 4:40 UTC (permalink / raw)
To: Neil Armstrong, Mauro Carvalho Chehab, Greg Kroah-Hartman,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Maxime Jourdan,
Hans Verkuil,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:MESON VIDEO DECODER DRIVER FOR AMLOGIC SOCS,
open list:STAGING SUBSYSTEM,
moderated list:ARM/Amlogic Meson SoC support, open list
Cc: Nicolas Dufresne
The vdec_open() function previously jumped directly to
err_m2m_release when vdec_init_ctrls() failed, skipping
release of the m2m context. This caused a resource leak.
Fix it by introducing a proper err_m2m_ctx_release label
that calls v4l2_m2m_ctx_release(sess->m2m_ctx) before
releasing the m2m device.
This was identified via kmemleak:
unreferenced object 0xffff0000205d6878 (size 8):
comm "v4l_id", pid 5289, jiffies 4294938580
hex dump (first 8 bytes):
40 d2 49 18 00 00 ff ff @.I.....
backtrace (crc d3204599):
kmemleak_alloc+0xc8/0xf0
__kvmalloc_node_noprof+0x60c/0x850
v4l2_ctrl_handler_init_class+0x1b4/0x2e8 [videodev]
vdec_open+0x1f4/0x788 [meson_vdec]
v4l2_open+0x144/0x460 [videodev]
chrdev_open+0x1ac/0x500
do_dentry_open+0x3f0/0xfe8
vfs_open+0x68/0x320
do_open+0x2d8/0x9a8
path_openat+0x1d0/0x4f0
do_filp_open+0x190/0x380
do_sys_openat2+0xf8/0x1b0
__arm64_sys_openat+0x13c/0x1e8
invoke_syscall+0xdc/0x268
el0_svc_common.constprop.0+0x178/0x258
do_el0_svc+0x4c/0x70
Cc: Nicolas Dufresne <nicolas@ndufresne.ca>
Fixes: 3e7f51bd9607 ("media: meson: add v4l2 m2m video decoder driver")
Signed-off-by: Anand Moon <linux.amoon@gmail.com>
---
v2: https://lore.kernel.org/all/20260321065408.209723-1-linux.amoon@gmail.com/
updated the commit message, applied the suggestion from sashiko
below.
[3] https://sashiko.dev/#/patchset/20260321065408.209723-1-linux.amoon%40gmail.com
v1: https://lore.kernel.org/all/20260304100557.126488-1-linux.amoon@gmail.com/
tried to address the issue reported by Nicolas
improve the commit message.
---
drivers/staging/media/meson/vdec/vdec.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/meson/vdec/vdec.c b/drivers/staging/media/meson/vdec/vdec.c
index 4b77ec1af5a7..a039d925c0fe 100644
--- a/drivers/staging/media/meson/vdec/vdec.c
+++ b/drivers/staging/media/meson/vdec/vdec.c
@@ -889,7 +889,7 @@ static int vdec_open(struct file *file)
ret = vdec_init_ctrls(sess);
if (ret)
- goto err_m2m_release;
+ goto err_m2m_ctx_release;
sess->pixfmt_cap = formats[0].pixfmts_cap[0];
sess->fmt_out = &formats[0];
@@ -913,6 +913,8 @@ static int vdec_open(struct file *file)
return 0;
+err_m2m_ctx_release:
+ v4l2_m2m_ctx_release(sess->m2m_ctx);
err_m2m_release:
v4l2_m2m_release(sess->m2m_dev);
err_free_sess:
base-commit: 27fa82620cbaa89a7fc11ac3057701d598813e87
--
2.50.1
^ permalink raw reply related
* [PATCH v2] ARM: PCI: merge pci_common_init_dev() into pci_common_init()
From: Ethan Nelson-Moore @ 2026-05-20 4:13 UTC (permalink / raw)
To: linux-arm-kernel, linux-kernel
Cc: Andrew Lunn, Ethan Nelson-Moore, Russell King, Bjorn Helgaas,
Ilpo Järvinen, Kuninori Morimoto
pci_common_init() is a compatibility wrapper that simply calls
pci_common_init_dev() with an additional NULL argument. The comment
above it implies that it should be replaced by pci_common_init_dev(),
but that has never happened - there are no callers of
pci_common_init_dev() in the kernel. Make the PCI code more
straightforward by getting rid of the wrapper function and instead
removing the device argument from pci_common_init_dev() and renaming it
to pci_common_init().
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
---
Changes in v2: Instead of removing pci_common_init() and converting all
callers to use pci_common_init_dev(), simply remove
pci_common_init_dev() and the unused parent parameter in
pcibios_init_hw(). Suggested by Andrew Lunn.
arch/arm/include/asm/mach/pci.h | 11 +----------
arch/arm/kernel/bios32.c | 8 +++-----
2 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/include/asm/mach/pci.h b/arch/arm/include/asm/mach/pci.h
index ece5283bdaec..83777d8c8e65 100644
--- a/arch/arm/include/asm/mach/pci.h
+++ b/arch/arm/include/asm/mach/pci.h
@@ -50,16 +50,7 @@ struct pci_sys_data {
/*
* Call this with your hw_pci struct to initialise the PCI system.
*/
-void pci_common_init_dev(struct device *, struct hw_pci *);
-
-/*
- * Compatibility wrapper for older platforms that do not care about
- * passing the parent device.
- */
-static inline void pci_common_init(struct hw_pci *hw)
-{
- pci_common_init_dev(NULL, hw);
-}
+void pci_common_init(struct hw_pci *hw);
/*
* Setup early fixed I/O mapping.
diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
index ac0e890510da..a5d3c31bfa55 100644
--- a/arch/arm/kernel/bios32.c
+++ b/arch/arm/kernel/bios32.c
@@ -424,8 +424,7 @@ static int pcibios_init_resource(int busnr, struct pci_sys_data *sys)
return 0;
}
-static void pcibios_init_hw(struct device *parent, struct hw_pci *hw,
- struct list_head *head)
+static void pcibios_init_hw(struct hw_pci *hw, struct list_head *head)
{
struct pci_sys_data *sys = NULL;
int ret;
@@ -466,7 +465,6 @@ static void pcibios_init_hw(struct device *parent, struct hw_pci *hw,
else {
list_splice_init(&sys->resources,
&bridge->windows);
- bridge->dev.parent = parent;
bridge->sysdata = sys;
bridge->busnr = sys->busnr;
bridge->ops = hw->ops;
@@ -492,7 +490,7 @@ static void pcibios_init_hw(struct device *parent, struct hw_pci *hw,
}
}
-void pci_common_init_dev(struct device *parent, struct hw_pci *hw)
+void pci_common_init(struct hw_pci *hw)
{
struct pci_sys_data *sys;
LIST_HEAD(head);
@@ -500,7 +498,7 @@ void pci_common_init_dev(struct device *parent, struct hw_pci *hw)
pci_add_flags(PCI_REASSIGN_ALL_BUS);
if (hw->preinit)
hw->preinit();
- pcibios_init_hw(parent, hw, &head);
+ pcibios_init_hw(hw, &head);
if (hw->postinit)
hw->postinit();
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 1/4] dt-bindings: display: verisilicon, dc: generalize for single-output variants
From: Icenowy Zheng @ 2026-05-20 4:07 UTC (permalink / raw)
To: Joey Lu, Conor Dooley
Cc: 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: <a112cb8b-21fb-4c33-89a3-14a4feb5e3f9@gmail.com>
在 2026-05-20三的 11:06 +0800，Joey Lu写道：
> On 5/20/2026 12:47 AM, Conor Dooley wrote:
> > On Tue, May 19, 2026 at 03:26:58PM +0800, Icenowy Zheng wrote:
> > > 在 2026-05-19二的 13:51 +0800，Joey Lu写道：
> > > > The existing schema assumes a fixed clock/reset topology and
> > > > dual-
> > > > output
> > > > port structure matching the DC8200 IP block. This prevents
> > > > reuse for
> > > > single-output variants such as the Verisilicon DCU Lite used in
> > > > the
> > > > Nuvoton MA35D1 SoC.
> > > >
> > > > Rework the schema so that variant-specific constraints are
> > > > expressed
> > > > via allOf/if-then-else:
> > > >
> > > > - The thead,th1520-dc8200 compatible keeps its existing five-
> > > > clock,
> > > > three-reset, dual-port requirements.
> > > >
> > > > - A standalone verisilicon,dc compatible covers IPs whose
> > > > identity is
> > > > discovered entirely through hardware registers; these have
> > > > flexible
> > > > clock and reset counts, a single 'port' property, and no
> > > > 'ports'
> > > > requirement.
> > > >
> > > > Changes to the base schema:
> > > > - Replace the fixed clock/reset items lists with
> > > > minItems/maxItems
> > > > ranges; variant sub-schemas tighten the constraints via if-
> > > > then-
> > > > else.
> > > > - Add a 'port' property (graph.yaml single-port alias)
> > > > alongside the
> > > > existing 'ports', for single-output variants.
> > > > - Drop the unconditional 'ports' requirement; each if-branch
> > > > enforces
> > > > its own port topology.
> > > > - Tighten additionalProperties to unevaluatedProperties to
> > > > allow
> > > > per-variant schemas to add their own constraints cleanly.
> > > > - Fix a stray space in the port@0 description.
> > > > - Add a DT example for the generic verisilicon,dc compatible
> > > > (Nuvoton MA35D1 DCU Lite).
> > > >
> > > > Signed-off-by: Joey Lu <a0987203069@gmail.com>
> > > > ---
> > > > .../bindings/display/verisilicon,dc.yaml | 135
> > > > ++++++++++++++--
> > > > --
> > > > 1 file changed, 108 insertions(+), 27 deletions(-)
> > > >
> > > > diff --git
> > > > a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > > > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > > > index 9dc35ab973f2..3a814c2e083e 100644
> > > > ---
> > > > a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > > > +++
> > > > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > > > @@ -14,10 +14,12 @@ properties:
> > > > pattern: "^display@[0-9a-f]+$"
> > > >
> > > > compatible:
> > > > - items:
> > > > - - enum:
> > > > - - thead,th1520-dc8200
> > > You should add a fallback compatible here for your SoC, in case
> > > its
> > > integration gets something quirky; this compatible is usually not
> > > consumed by the driver (see how thead,th1520-dc8200 exists in the
> > > binding but not the driver).
> > s/fallback compatible/soc-specific compatible/, but yes.
> > NAK to what's been done here, especially after the discussions on
> > earlier versions of this verisilicon binding.
> > pw-bot: changes-requested
> Understood. I will add `nuvoton,ma35d1-dcu` as the SoC-specific
> compatible string paired with `verisilicon,dc` as the generic
> fallback,
> matching the pattern used for `thead,th1520-dc8200`. The standalone
> `verisilicon,dc` compatible will be removed from the binding. The
> driver
No, please don't remove compatible strings from existing binding, and
the generic compatible is still used for driver binding.
The SoC-specific compatible is informative here, it needs to exist, but
it doesn't supersede "verisilicon,dc" .
In addition, the SoC-specific compatible is also used for verification
of the SoC device tree, which is the reason if clauses exist with
compatible match and additional constraints (e.g. for the nuvoton DCU
it's invalid to have a 2nd output port).
> match table is not changed since hardware detection is done via ID
> registers.
> > > > - - const: verisilicon,dc # DC IPs have discoverable
> > > > ID/revision
> > > > registers
> > > > + oneOf:
> > > > + - items:
> > > > + - enum:
> > > > + - thead,th1520-dc8200
> > > > + - const: verisilicon,dc
> > > > + - const: verisilicon,dc # DC IPs have discoverable
> > > > ID/revision registers
> > > >
> > > > reg:
> > > > maxItems: 1
> > > > @@ -26,32 +28,24 @@ properties:
> > > > maxItems: 1
> > > >
> > > > clocks:
> > > > - items:
> > > > - - description: DC Core clock
> > > > - - description: DMA AXI bus clock
> > > > - - description: Configuration AHB bus clock
> > > > - - description: Pixel clock of output 0
> > > > - - description: Pixel clock of output 1
> > > > + minItems: 2
> > > > + maxItems: 5
> > > >
> > > > clock-names:
> > > > - items:
> > > > - - const: core
> > > > - - const: axi
> > > > - - const: ahb
> > > > - - const: pix0
> > > > - - const: pix1
> > > > + minItems: 2
> > > > + maxItems: 5
> > > >
> > > > resets:
> > > > - items:
> > > > - - description: DC Core reset
> > > > - - description: DMA AXI bus reset
> > > > - - description: Configuration AHB bus reset
> > > > + minItems: 1
> > > > + maxItems: 3
> > > >
> > > > reset-names:
> > > > - items:
> > > > - - const: core
> > > > - - const: axi
> > > > - - const: ahb
> > > > + minItems: 1
> > > > + maxItems: 3
> > > > +
> > > > + port:
> > > > + $ref: /schemas/graph.yaml#/properties/port
> > > > + description: Single video output port for single-output
> > > > variants.
> > > Maybe the endpoint numbering rule needs a move to here? (I am not
> > > very
> > > sure).
> I will add a description to the `port` property noting that endpoint
> 0
> is used for DPI output, which is the only output type for
> DCUltraLite.
Please note that DC8000 exists, which is single-port but supports both
DPI and DP.
> > > >
> > > > ports:
> > > > $ref: /schemas/graph.yaml#/properties/ports
> > > > @@ -59,7 +53,7 @@ properties:
> > > > properties:
> > > > port@0:
> > > > $ref: /schemas/graph.yaml#/properties/port
> > > > - description: The first output channel , endpoint 0
> > > > should be
> > > > + description: The first output channel, endpoint 0
> > > > should be
> > > > used for DPI format output and endpoint 1 should be
> > > > used
> > > > for DP format output.
> > > >
> > > > @@ -75,9 +69,75 @@ required:
> > > > - interrupts
> > > > - clocks
> > > > - clock-names
> > > > - - ports
> > > >
> > > > -additionalProperties: false
> > > > +allOf:
> > > > + - if:
> > > > + properties:
> > > > + compatible:
> > > > + contains:
> > > > + const: thead,th1520-dc8200
> > > > + then:
> > > > + properties:
> > > > + clocks:
> > > > + items:
> > > > + - description: DC Core clock
> > > > + - description: DMA AXI bus clock
> > > > + - description: Configuration AHB bus clock
> > > > + - description: Pixel clock of output 0
> > > > + - description: Pixel clock of output 1
> > > > +
> > > > + clock-names:
> > > > + items:
> > > > + - const: core
> > > > + - const: axi
> > > > + - const: ahb
> > > > + - const: pix0
> > > > + - const: pix1
> > > > +
> > > > + resets:
> > > > + items:
> > > > + - description: DC Core reset
> > > > + - description: DMA AXI bus reset
> > > > + - description: Configuration AHB bus reset
> > > > +
> > > > + reset-names:
> > > > + items:
> > > > + - const: core
> > > > + - const: axi
> > > > + - const: ahb
> > > > +
> > > > + required:
> > > > + - ports
> > > > +
> > > > + else:
> > > > + properties:
> > > > + clocks:
> > > > + items:
> > > > + - description: Bus clock that gates register
> > > > access
> > > > + - description: Pixel clock divider for display
> > > > timing
> > > Please don't make compatible-specific description strings for
> > > individual compatibles, and keep these descriptions outside of
> > > the if.
> > > The compatible-specific part should be used to specify what's
> > > required
> > > for the specific SoC, for dt validation purpose.
> > >
> > > BTW if the clock is both the working clock and bus clock for the
> > > controller, I suggest listing it twice, except if the IP core is
> > > provided without a dedicated core clock (in the case I suggest to
> > > use
> > > "bus" only).
> > I agree. If the same clock is provided to two+ ports on the IP,
> > that
> > should still be two+ clocks in the devicetree.
> >
> > > Here's an example for "listing it twice":
> > > ```
> > > clocks = <&clk DCU_GATE>, <&clk DCU_GATE>, <&clk DCUP_DIV>;
> > > clock-names = "core", "bus", "pix0";
> > > ```
> > >
> > > Well nonetheless the name "core" does not match the description
> > > "Bus
> > > clock that gates register access".
> > >
> > > Thanks,
> > > Icenowy
>
> Understood. I will remove all description strings from the if/else
> branches; the if/then clauses will only constrain clock-names and
> reset-names items (name values only, no descriptions). Regarding
> clock
Well I think a required properties list is also needed in the if/then
clause, to prevent DT's from lacking properties.
> naming: DCU_GATE on MA35D1 is a peripheral gate clock without a
> separate
> dedicated core working clock, so I will keep "core" as the name and
Do you mean there's no seperate dedicated bus clock? I find that in the
clock driver dcu_gate has no parent as bus clocks -- its parent is
dcu_mux, and dcu_mux's 2 parents are both pll ("epll_div2" and
"syspll").
Thanks,
Icenowy
> drop
> the misleading description "Bus clock that gates register access".
> The
> description mismatch was entirely in the if/else strings which are
> now
> removed.
>
> Thanks.
>
> > >
> > > > +
> > > > + clock-names:
> > > > + items:
> > > > + - const: core
> > > > + - const: pix0
> > > > +
> > > > + resets:
> > > > + maxItems: 1
> > > > + description:
> > > > + Reset line for the display controller.
> > > > +
> > > > + reset-names:
> > > > + items:
> > > > + - const: core
> > > > +
> > > > + required:
> > > > + - port
> > > > +
> > > > + not:
> > > > + required:
> > > > + - ports
> > > > +
> > > > +unevaluatedProperties: false
> > > >
> > > > examples:
> > > > - |
> > > > @@ -120,3 +180,24 @@ examples:
> > > > };
> > > > };
> > > > };
> > > > +
> > > > + - |
> > > > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > > > + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
> > > > + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
> > > > +
> > > > + display@40260000 {
> > > > + compatible = "verisilicon,dc";
> > > > + reg = <0x40260000 0x20000>;
> > > > + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
> > > > + clocks = <&clk DCU_GATE>, <&clk DCUP_DIV>;
> > > > + clock-names = "core", "pix0";
> > > > + resets = <&sys MA35D1_RESET_DISP>;
> > > > + reset-names = "core";
> > > > +
> > > > + port {
> > > > + dpi_out: endpoint {
> > > > + remote-endpoint = <&panel_in>;
> > > > + };
> > > > + };
> > > > + };
^ permalink raw reply
* Re: [PATCH] ARM64: remove unnecessary architecture-specific <asm/device.h>
From: Ethan Nelson-Moore @ 2026-05-20 4:03 UTC (permalink / raw)
To: Will Deacon; +Cc: linux-arm-kernel, linux-kernel, Catalin Marinas
In-Reply-To: <agxToDJ6y_ciI1Oj@willie-the-truck>
Hi, Will,
On Tue, May 19, 2026 at 5:12 AM Will Deacon <will@kernel.org> wrote:
> Do we need to add a generic-y entry to arch/arm64/include/asm/Kbuild
> so that we pick up the asm-generic variant?
No, we don't, because device.h is in the list of mandatory headers in
include/asm-generic/Kbuild, which means a header including the generic
version will automatically be generated if an architecture-specific
version does not exist.
Ethan
^ permalink raw reply
* RE: [PATCH v4 00/24] iommu/arm-smmu-v3: Quarantine device upon ATC invalidation timeout
From: Tian, Kevin @ 2026-05-20 3:59 UTC (permalink / raw)
To: Nicolin Chen, Will Deacon, Robin Murphy, Joerg Roedel,
Bjorn Helgaas, Jason Gunthorpe
Cc: Rafael J . Wysocki, Len Brown, Pranjal Shrivastava, Mostafa Saleh,
Lu Baolu, linux-arm-kernel@lists.infradead.org,
iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
linux-acpi@vger.kernel.org, linux-pci@vger.kernel.org,
Vikram Sethi, Shuai Xue
In-Reply-To: <cover.1779161849.git.nicolinc@nvidia.com>
> From: Nicolin Chen <nicolinc@nvidia.com>
> Sent: Tuesday, May 19, 2026 11:39 AM
>
> Changelog
> v4:
> * Rebase on Joerg's IOMMU "fixes" branch
> * Rebase on Jason's SMMUv3 cmd_ent series
> https://lore.kernel.org/all/0-v2-47b2bf710ad5+716ac-
> smmu_no_cmdq_ent_jgg@nvidia.com/
> * [PCI] Don't suspend IOMMU in probe mode
> * [iommu] kfree_rcu() iommu_group
> * [iommu] Convert gdev->blocked to enum gdev_blocked
> * [iommu] Use disable_work_sync() to fix UAF and ref leak
> * [iommu] Gate done() transitions to preserve BLOCKED_BROKEN
> * [iommu] Decrement recovery_cnt when unplugging a blocked gdev
> * [iommu] Drop racy dev_has_iommu() in iommu_report_device_broken()
> * [iommu] Add gdev->broken_pending to skip worker after racing recovery
> * [smmuv3] Add master->ats_invs scratch
> * [smmuv3] Add arm_smmu_cmdq_batch_issue() wrapper
> * [smmuv3] Force per-flush sync for has_ats batches
> * [smmuv3] Serialize STE.EATS and ats_broken updates
> * [smmuv3] Co-clear pending CMDQ_ERR from cmdq issuer
> * [smmuv3] Add invs and has_ats to arm_smmu_cmdq_batch
> * [smmuv3] Move arm_smmu_invs_for_each_entry to header
> * [smmuv3] Set master->ats_broken after clearing STE.EATS
> * [smmuv3] Issue CFGI_STE via arm_smmu_cmdq_issue_cmd_with_sync()
> * [smmuv3] Keep "smmu" pointer in arm_smmu_inv but add "master" for
> ATS
Not check the detail yet, but this v4 more than doubles the number of
patches in v3. Are they all necessary to be in one series? any chance to
split to ease the review...
^ permalink raw reply
* Re: [PATCH v4 04/13] dma: swiotlb: track pool encryption state and honor DMA_ATTR_CC_SHARED
From: Aneesh Kumar K.V @ 2026-05-20 3:57 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: Mostafa Saleh, iommu, linux-arm-kernel, linux-kernel, linux-coco,
Robin Murphy, Marek Szyprowski, Will Deacon, Marc Zyngier,
Steven Price, Suzuki K Poulose, Catalin Marinas, Jiri Pirko,
Petr Tesarik, Alexey Kardashevskiy, Dan Williams, Xu Yilun,
linuxppc-dev, linux-s390, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy (CS GROUP), Alexander Gordeev,
Gerald Schaefer, Heiko Carstens, Vasily Gorbik,
Christian Borntraeger, Sven Schnelle, x86
In-Reply-To: <20260519161120.GO7702@ziepe.ca>
Jason Gunthorpe <jgg@ziepe.ca> writes:
> On Tue, May 19, 2026 at 09:35:30PM +0530, Aneesh Kumar K.V wrote:
>> Yes, that also resulted in simpler and cleaner code.
>>
>> swiotlb_tbl_map_single
>> /*
>> * If the physical address is encrypted but the device requires
>> * decrypted DMA, use a decrypted io_tlb_mem and update the
>> * attributes so the caller knows that a decrypted io_tlb_mem
>> * was used.
>> */
>> if (!(*attrs & DMA_ATTR_CC_SHARED) && force_dma_unencrypted(dev))
>> *attrs |= DMA_ATTR_CC_SHARED;
>>
>> if (mem->unencrypted != !!(*attrs & DMA_ATTR_CC_SHARED))
>> return (phys_addr_t)DMA_MAPPING_ERROR;
>
> Yeah, exactly that is so much clearer now that the mem->unecrypted is
> tied directly.
>
> That logic is reversed though, the incoming ATTR_CC doesn't matter for
> swiotlb, that is just the source of the memcpy.
>
> /* swiotlb pool is incorrect for this device */
> if (mem->unencrypted != force_dma_unencrypted(dev))
> return (phys_addr_t)DMA_MAPPING_ERROR;
>
> /* Force attrs to match the kind of memory in the pool */
> if (mem->unencrypted)
> *attrs |= DMA_ATTR_CC_SHARED;
> else
> *attrs &= ~DMA_ATTR_CC_SHARED;
>
>
> Attrs should be forced to whatever memory swiotlb selected.
>
But that will not handle a T=1 device that wants to use swiotlb to
bounce unencrypted memory. That is:
force_dma_unencrypted(dev) == 0 /* T=1 device */
attrs = DMA_ATTR_CC_SHARED;
In that case, it should use an unencrypted io_tlb_mem:
mem->unencrypted == 1
-aneesh
^ permalink raw reply
* Re: [PATCH v7 5/6] phy: move and rename Airoha PCIe PHY driver to dedicated directory
From: Baruch Siach @ 2026-05-20 3:57 UTC (permalink / raw)
To: Christian Marangi
Cc: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Vinod Koul, Neil Armstrong,
Lorenzo Bianconi, Felix Fietkau, linux-clk, devicetree,
linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260519220813.28468-6-ansuelsmth@gmail.com>
Hi Christian,
On Wed, May 20 2026, Christian Marangi wrote:
> To keep the generic PHY directory tidy, move the PCIe PHY driver for
> Airoha AN7581 SoC to a dedicated directory.
>
> Also rename the driver and add the relevant SoC name to the .c and .h
> file in preparation for support of PCIe and USB PHY driver for Airoha
> AN7583 SoC that use a completely different implementation and
> calibration for PHYs and will have their own dedicated drivers.
>
> The rename permits to better identify the specific usage of the driver
> in the future once the airoha PHY directory will have multiple driver
> for multiple SoC.
>
> The config is changed from PHY_AIROHA_PCIE to PHY_AIROHA_AN7581_PCIE.
>
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
> MAINTAINERS | 4 +-
> drivers/phy/Kconfig | 11 +-
> drivers/phy/Makefile | 4 +-
> drivers/phy/airoha/Kconfig | 13 +
> drivers/phy/airoha/Makefile | 3 +
> drivers/phy/airoha/phy-an7581-pcie-regs.h | 494 ++++++++
> drivers/phy/airoha/phy-an7581-pcie.c | 1290 +++++++++++++++++++++
This patch creates a .c file under drivers/phy/airoha/, but doesn't remove
the existing file under drivers/phy/.
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH v7] arm64: dts: imx95: Correct PCIe outbound address space configuration
From: Richard Zhu @ 2026-05-20 3:56 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, frank.li, s.hauer, festevam
Cc: kernel, devicetree, imx, linux-arm-kernel, linux-kernel,
Richard Zhu
Fix the PCIe outbound memory ranges for both pcie0 and pcie1
controllers on i.MX95.
The memory window size was incorrectly set to 256MB during initial
bring-up, but the hardware supports up to 4GB of outbound address space
per controller.
Additionally, the ECAM region cannot be mapped as I/O space. Use a
memory-mapped region for I/O space instead, and relocate the 1MB I/O
region to immediately follow the memory region at offset 0xf0000000
within each window.
Update the outbound address space layout per controller as follows:
- 3.5GB 64-bit prefetchable memory
- 256MB 32-bit non-prefetchable memory
- 1MB I/O
Fixes: 3b1d5deb29ff ("arm64: dts: imx95: add pcie[0,1] and pcie-ep[0,1] support")
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
---
arch/arm64/boot/dts/freescale/imx95.dtsi | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
---
Changes in v6:
- Map the large outbound window into 64-bit PCI address, to eliminate both
the inbound DMA routing conflict and the IOVA exhaustion problem.
Changes in v5:
- Expand the outbound address space from 256MB to 3840MB, starting at the
base of each controller's assigned CPU address range.
- Use a memory region to map the I/O space.
Changes in v4:
Update the flag from 0x82000000 to 0x83000000 to declare a 64-bit PCI space.
Changes in v3:
Update the commit message, and set the region size to the max hardware-supported memory space 4G.
Changes in v2:
Add the Fixes tag, and rebase to latest imx/dt64 branch.
diff --git a/arch/arm64/boot/dts/freescale/imx95.dtsi b/arch/arm64/boot/dts/freescale/imx95.dtsi
index adcc0e1d3696..d776cd350c4b 100644
--- a/arch/arm64/boot/dts/freescale/imx95.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx95.dtsi
@@ -1939,8 +1939,9 @@ pcie0: pcie@4c300000 {
<0 0x4c360000 0 0x10000>,
<0 0x4c340000 0 0x4000>;
reg-names = "dbi", "config", "atu", "app";
- ranges = <0x81000000 0x0 0x00000000 0x0 0x6ff00000 0 0x00100000>,
- <0x82000000 0x0 0x10000000 0x9 0x10000000 0 0x10000000>;
+ ranges = <0x43000000 0x9 0x00000000 0x9 0x00000000 0x0 0xe0000000>,
+ <0x82000000 0x0 0x00000000 0x9 0xe0000000 0x0 0x10000000>,
+ <0x81000000 0x0 0x00000000 0x9 0xf0000000 0x0 0x00100000>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
@@ -2014,8 +2015,9 @@ pcie1: pcie@4c380000 {
<0 0x4c3e0000 0 0x10000>,
<0 0x4c3c0000 0 0x4000>;
reg-names = "dbi", "config", "atu", "app";
- ranges = <0x81000000 0 0x00000000 0x8 0x8ff00000 0 0x00100000>,
- <0x82000000 0 0x10000000 0xa 0x10000000 0 0x10000000>;
+ ranges = <0x43000000 0xa 0x00000000 0xa 0x00000000 0x0 0xe0000000>,
+ <0x82000000 0x0 0x00000000 0xa 0xe0000000 0x0 0x10000000>,
+ <0x81000000 0x0 0x00000000 0xa 0xf0000000 0x0 0x00100000>;
#address-cells = <3>;
#size-cells = <2>;
device_type = "pci";
--
2.37.1
^ permalink raw reply related
* Re: [PATCH v2 0/7] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Dev Jain @ 2026-05-20 3:40 UTC (permalink / raw)
To: Andrew Morton, Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
Xueyuan.chen21, rppt, david, ryan.roberts, anshuman.khandual, ajd,
linux-kernel, Wen Jiang
In-Reply-To: <20260519131738.11a78ba88e1be28ba5cb26eb@linux-foundation.org>
On 20/05/26 1:47 am, Andrew Morton wrote:
> On Thu, 14 May 2026 17:41:01 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
>> This patchset accelerates ioremap, vmalloc, and vmap when the memory
>> is physically fully or partially contiguous.
>>
>> ...
>>
>> On the RK3588 8-core ARM64 SoC, with tasks pinned to a little core and
>> the performance CPUfreq policy enabled, benchmark results:
>>
>> * ioremap(1 MB): 1.35× faster (3407 ns -> 2526 ns)
>> * vmalloc(1 MB) mapping time (excluding allocation) with
>> VM_ALLOW_HUGE_VMAP: 1.42× faster (5.00 us -> 3.53us)
>> * vmap(100MB) with order-8 pages: 8.3× faster (1235 us -> 149 us)
>
> Nice.
>
> AI review found a bunch of things to ask about:
> https://sashiko.dev/#/patchset/20260514094108.2016201-1-jiangwen6@xiaomi.com
>
> It doesn't appear that you'll be getting any more review on this
> series, so please check the above questions and resend?
I have to review this but struggling to find time right now. So please
don't wait for me : )
>
^ permalink raw reply
* Re: [PATCH 06/10] clk: amlogic: PLL reset signal supports active-low configuration
From: Jian Hu @ 2026-05-20 3:35 UTC (permalink / raw)
To: Jerome Brunet, Jian Hu via B4 Relay
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, linux-kernel, linux-clk, devicetree,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1jmry26my3.fsf@starbuckisacylon.baylibre.com>
On 5/14/2026 11:16 PM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> In the A9 design, the PLL reset signal is configured as active-low.
>>
>> Add the flag 'CLK_MESON_PLL_RST_N' to indicate that the PLL reset signal
>> is active-low.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> drivers/clk/meson/clk-pll.c | 42 +++++++++++++++++++++++++++++++-----------
>> drivers/clk/meson/clk-pll.h | 2 ++
>> 2 files changed, 33 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
>> index 5a0bd75f85a9..8568ad6ba7b6 100644
>> --- a/drivers/clk/meson/clk-pll.c
>> +++ b/drivers/clk/meson/clk-pll.c
>> @@ -295,10 +295,14 @@ static int meson_clk_pll_is_enabled(struct clk_hw *hw)
>> {
>> struct clk_regmap *clk = to_clk_regmap(hw);
>> struct meson_clk_pll_data *pll = meson_clk_pll_data(clk);
>> + unsigned int rst;
>>
>> - if (MESON_PARM_APPLICABLE(&pll->rst) &&
>> - meson_parm_read(clk->map, &pll->rst))
>> - return 0;
>> + if (MESON_PARM_APPLICABLE(&pll->rst)) {
>> + rst = meson_parm_read(clk->map, &pll->rst);
>> + if ((rst && !(pll->flags & CLK_MESON_PLL_RST_ACTIVE_LOW)) ||
>> + (!rst && (pll->flags & CLK_MESON_PLL_RST_ACTIVE_LOW)))
> Again not a great usage of binary ops. What you've written above is the
> verbose version of a XOR.
>
> The code duplication remarks applies to the rest of the patch too
Ok, I will update this and the other similar instances below in the next
version.
Here is the updated code for it:
int active_low = !!(pll->flags & CLK_MESON_PLL_RST_ACTIVE_LOW);
if (MESON_PARM_APPLICABLE(&pll->rst) &&
(meson_parm_read(clk->map, &pll->rst) ^ active_low))
[...]
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH 05/10] clk: amlogic: PLL l_detect signal supports active-high configuration
From: Jian Hu @ 2026-05-20 3:25 UTC (permalink / raw)
To: Jerome Brunet, Jian Hu via B4 Relay
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, linux-kernel, linux-clk, devicetree,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1jse7u6n3q.fsf@starbuckisacylon.baylibre.com>
On 5/14/2026 11:13 PM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> l_detect controls the enable/disable of the PLL lock-detect module.
>>
>> For A9, the l_detect signal is active-high:
>> 0 -> Disable lock-detect module;
>> 1 -> Enable lock-detect module.
>>
>> Here, a flag CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH is added to handle cases
>> like A9, where the signal is active-high.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> drivers/clk/meson/clk-pll.c | 9 +++++++--
>> drivers/clk/meson/clk-pll.h | 2 ++
>> 2 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/clk/meson/clk-pll.c b/drivers/clk/meson/clk-pll.c
>> index 1ea6579a760f..5a0bd75f85a9 100644
>> --- a/drivers/clk/meson/clk-pll.c
>> +++ b/drivers/clk/meson/clk-pll.c
>> @@ -388,8 +388,13 @@ static int meson_clk_pll_enable(struct clk_hw *hw)
>> }
>>
>> if (MESON_PARM_APPLICABLE(&pll->l_detect)) {
>> - meson_parm_write(clk->map, &pll->l_detect, 1);
>> - meson_parm_write(clk->map, &pll->l_detect, 0);
>> + if (pll->flags & CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH) {
>> + meson_parm_write(clk->map, &pll->l_detect, 0);
>> + meson_parm_write(clk->map, &pll->l_detect, 1);
>> + } else {
>> + meson_parm_write(clk->map, &pll->l_detect, 1);
>> + meson_parm_write(clk->map, &pll->l_detect, 0);
>> + }
> I'm not a fan of this code duplication.
> Use the introduced CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH to compute the
> first value, then flip the bit.
Ok, I will update this in the next version.
Here is the updated code:
if (MESON_PARM_APPLICABLE(&pll->l_detect)) {
meson_parm_write(clk->map, &pll->l_detect,
!(pll->flags &
CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH));
meson_parm_write(clk->map, &pll->l_detect,
!!(pll->flags &
CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH));
}
>> }
>>
>> if (meson_clk_pll_wait_lock(hw))
>> diff --git a/drivers/clk/meson/clk-pll.h b/drivers/clk/meson/clk-pll.h
>> index 949157fb7bf5..97b7c70376a3 100644
>> --- a/drivers/clk/meson/clk-pll.h
>> +++ b/drivers/clk/meson/clk-pll.h
>> @@ -29,6 +29,8 @@ struct pll_mult_range {
>>
>> #define CLK_MESON_PLL_ROUND_CLOSEST BIT(0)
>> #define CLK_MESON_PLL_NOINIT_ENABLED BIT(1)
>> +/* l_detect signal is active-high */
>> +#define CLK_MESON_PLL_L_DETECT_ACTIVE_HIGH BIT(2)
>>
>> struct meson_clk_pll_data {
>> struct parm en;
> --
> Jerome
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH 03/10] dt-bindings: clock: Add Amlogic A9 peripherals clock controller
From: Jian Hu @ 2026-05-20 3:16 UTC (permalink / raw)
To: Jerome Brunet, Jian Hu via B4 Relay
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, linux-kernel, linux-clk, devicetree,
linux-amlogic, linux-arm-kernel
In-Reply-To: <1jbjei6k75.fsf@starbuckisacylon.baylibre.com>
Hi Jerome,
Thanks for your review.
On 5/15/2026 12:15 AM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On lun. 11 mai 2026 at 20:47, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> Add the peripherals clock controller dt-bindings for the Amlogic A9
>> SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> .../clock/amlogic,a9-peripherals-clkc.yaml | 150 +++++++++
>> .../clock/amlogic,a9-peripherals-clkc.h | 352 +++++++++++++++++++++
>> 2 files changed, 502 insertions(+)
>>
>> diff --git
>> a/Documentation/devicetree/bindings/clock/amlogic,a9-peripherals-clkc.yaml
>> b/Documentation/devicetree/bindings/clock/amlogic,a9-peripherals-clkc.yaml
>> new file mode 100644
>> index 000000000000..97e2c44d8630
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/clock/amlogic,a9-peripherals-clkc.yaml
>> @@ -0,0 +1,150 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +# Copyright (C) 2026 Amlogic, Inc. All rights reserved
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/clock/amlogic,a9-peripherals-clkc.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Amlogic A9 Series Peripherals Clock Controller
>> +
>> +maintainers:
>> + - Neil Armstrong <neil.armstrong@linaro.org>
>> + - Jerome Brunet <jbrunet@baylibre.com>
>> + - Jian Hu <jian.hu@amlogic.com>
>> + - Xianwei Zhao <xianwei.zhao@amlogic.com>
>> +
>> +properties:
>> + compatible:
>> + const: amlogic,a9-peripherals-clkc
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + '#clock-cells':
>> + const: 1
>> +
>> + clocks:
>> + minItems: 20
>> + items:
>> + - description: input oscillator
>> + - description: input fclk div 2
>> + - description: input fclk div 3
>> + - description: input fclk div 4
>> + - description: input fclk div 5
>> + - description: input fclk div 7
>> + - description: input fclk div 2p5
>> + - description: input sys clk
>> + - description: input gp1 pll
>> + - description: input gp2 pll
>> + - description: input sys pll div 16
>> + - description: input cpu clk div 16
>> + - description: input a78 clk div 16
>> + - description: input dsu clk div 16
>> + - description: input rtc clk
>> + - description: input gp0 pll
>> + - description: input hifi0 pll
>> + - description: input hifi1 pll
>> + - description: input mclk0 pll
>> + - description: input mclk1 pll
>> + - description: input video1 pll (optional)
>> + - description: input video2 pll (optional)
>> + - description: input hdmi out2 clk (optional)
>> + - description: input hdmi pixel clk (optional)
>> + - description: input pixel0 pll (optional)
>> + - description: input pixel1 pll (optional)
>> + - description: input usb2 drd clk (optional)
> Why are those optional ? they seem internal to the SoC.
> If so, they don't have a reason to be optional
Yes , these clocks are sourced from other analog modules and will be
added in the future.
I will remove the optional in the next version.
>> + - description: external input rmii oscillator (optional)
>> +
[...]
> --
> Jerome
Best regards,
Jian
^ permalink raw reply
* Re: [PATCH v2 4/4] drm/verisilicon: add Nuvoton MA35D1 DCU Lite display controller support
From: Joey Lu @ 2026-05-20 3:09 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <4d3c239ff1c560791668e571c5e6ab58c08ea002.camel@iscas.ac.cn>
On 5/19/2026 3:44 PM, Icenowy Zheng wrote:
> 在 2026-05-19二的 13:51 +0800，Joey Lu写道：
>> The Nuvoton MA35D1 SoC integrates a Verisilicon DCU Lite display
>> controller. While its register layout is broadly similar to the
>> DC8200,
>> several differences require dedicated hardware ops:
>>
>> 1. No CONFIG_EX commit path: framebuffer updates use enable (bit 0)
>> and
>> reset (bit 4) bits in FB_CONFIG instead of the DC8200 staging
>> registers
>> (FB_CONFIG_EX, FB_TOP_LEFT, FB_BOTTOM_RIGHT, FB_BLEND_CONFIG,
>> PANEL_CONFIG_EX).
>>
>> 2. No PANEL_START register: panel output starts when
>> PANEL_CONFIG.RUNNING is set; no multi-display sync start register
>> is used.
>>
>> 3. Different IRQ registers: DCU Lite uses DISP_IRQ_STA (0x147C) /
>> DISP_IRQ_EN (0x1480) versus DC8200's TOP_IRQ_ACK (0x0010) /
>> TOP_IRQ_EN (0x0014).
>>
>> 4. Per-frame commit cycle: DCU Lite requires the VALID bit in
>> FB_CONFIG
>> to be set at the start of each atomic commit (crtc_begin) and
>> cleared
>> after (crtc_flush).
>>
>> 5. Simpler clock topology: only "core" (bus gate) and "pix0" (pixel
>> divider) clocks; no axi or ahb clocks. Make axi_clk and ahb_clk
>> optional (devm_clk_get_optional_enabled) so DCU Lite nodes without
>> those clocks are handled gracefully.
>>
>> Add vs_dcu_lite.c implementing the vs_dc_funcs vtable for the above
>> differences. After chip identity detection, vs_dc_probe() now
>> selects
>> vs_dcu_lite_funcs when the identified model is VSDC_MODEL_DCU_LITE
>> (model register reads 0, revision 0x5560, customer_id 0x305).
>>
>> Extend Kconfig to allow building on ARCH_MA35 platforms.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> drivers/gpu/drm/verisilicon/Kconfig | 2 +-
>> drivers/gpu/drm/verisilicon/Makefile | 2 +-
>> drivers/gpu/drm/verisilicon/vs_dc.c | 9 ++-
>> drivers/gpu/drm/verisilicon/vs_dc.h | 1 +
>> drivers/gpu/drm/verisilicon/vs_dcu_lite.c | 78
>> +++++++++++++++++++++++
>> 5 files changed, 87 insertions(+), 5 deletions(-)
>> create mode 100644 drivers/gpu/drm/verisilicon/vs_dcu_lite.c
>>
>> diff --git a/drivers/gpu/drm/verisilicon/Kconfig
>> b/drivers/gpu/drm/verisilicon/Kconfig
>> index 7cce86ec8603..295d246eb4b4 100644
>> --- a/drivers/gpu/drm/verisilicon/Kconfig
>> +++ b/drivers/gpu/drm/verisilicon/Kconfig
>> @@ -2,7 +2,7 @@
>> config DRM_VERISILICON_DC
>> tristate "DRM Support for Verisilicon DC-series display
>> controllers"
>> depends on DRM && COMMON_CLK
>> - depends on RISCV || COMPILE_TEST
>> + depends on RISCV || ARCH_MA35 || COMPILE_TEST
>> select DRM_BRIDGE_CONNECTOR
>> select DRM_CLIENT_SELECTION
>> select DRM_DISPLAY_HELPER
>> diff --git a/drivers/gpu/drm/verisilicon/Makefile
>> b/drivers/gpu/drm/verisilicon/Makefile
>> index f4fbd9f7d6a2..bf88f627e65c 100644
>> --- a/drivers/gpu/drm/verisilicon/Makefile
>> +++ b/drivers/gpu/drm/verisilicon/Makefile
>> @@ -1,5 +1,5 @@
>> # SPDX-License-Identifier: GPL-2.0-only
>>
>> -verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
>> vs_drm.o vs_hwdb.o vs_plane.o vs_primary_plane.o
>> +verisilicon-dc-objs := vs_bridge.o vs_crtc.o vs_dc.o vs_dc8200.o
>> vs_dcu_lite.o vs_drm.o vs_hwdb.o vs_plane.o vs_primary_plane.o
>>
>> obj-$(CONFIG_DRM_VERISILICON_DC) += verisilicon-dc.o
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.c
>> b/drivers/gpu/drm/verisilicon/vs_dc.c
>> index c94957024189..77bc63c629f7 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.c
>> @@ -90,13 +90,13 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> return PTR_ERR(dc->core_clk);
>> }
>>
>> - dc->axi_clk = devm_clk_get_enabled(dev, "axi");
>> + dc->axi_clk = devm_clk_get_optional_enabled(dev, "axi");
>> if (IS_ERR(dc->axi_clk)) {
>> dev_err(dev, "can't get axi clock\n");
>> return PTR_ERR(dc->axi_clk);
>> }
>>
>> - dc->ahb_clk = devm_clk_get_enabled(dev, "ahb");
>> + dc->ahb_clk = devm_clk_get_optional_enabled(dev, "ahb");
>> if (IS_ERR(dc->ahb_clk)) {
>> dev_err(dev, "can't get ahb clock\n");
>> return PTR_ERR(dc->ahb_clk);
>> @@ -134,7 +134,10 @@ static int vs_dc_probe(struct platform_device
>> *pdev)
>> dev_info(dev, "Found DC%x rev %x customer %x\n", dc-
>>> identity.model,
>> dc->identity.revision, dc->identity.customer_id);
>>
>> - dc->funcs = &vs_dc8200_funcs;
>> + if (dc->identity.model == VSDC_MODEL_DC8200)
> Don't do that. The model value is only for matching hardware values,
> not for detecting what's present. Don't forget that DC8000 has a model
> value of 0x8000, but behaves similarly with DCUltraLite with a model
> value of 0x0.
>
> I suggest adding another field for assigning helper functions.
>
> My suggestion is here:
>
> ```
> enum vs_dc_generation {
> VSDC_GEN_DC8000,
> VSDC_GEN_DC8200
> };
> ```
>
> Thanks,
> Icenowy
Understood. I will add `enum vs_dc_generation` to vs_hwdb.h and a
`generation` field to `vs_chip_identity`. Each entry in
`vs_chip_identities[]` will set `.generation` accordingly (DC8200
entries → `VSDC_GEN_DC8200`; DCUltraLite → `VSDC_GEN_DC8000`). The probe
will then branch on `dc->identity.generation == VSDC_GEN_DC8200` instead
of the model register value.
>> + dc->funcs = &vs_dc8200_funcs;
>> + else
>> + dc->funcs = &vs_dcu_lite_funcs;
>>
>> if (port_count > dc->identity.display_count) {
>> dev_err(dev, "too many downstream ports than HW
>> capability\n");
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dc.h
>> b/drivers/gpu/drm/verisilicon/vs_dc.h
>> index 45172c1a525c..d77d4a1babdf 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_dc.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_dc.h
>> @@ -66,5 +66,6 @@ struct vs_dc {
>> };
>>
>> extern const struct vs_dc_funcs vs_dc8200_funcs;
>> +extern const struct vs_dc_funcs vs_dcu_lite_funcs;
>>
>> #endif /* _VS_DC_H_ */
>> diff --git a/drivers/gpu/drm/verisilicon/vs_dcu_lite.c
>> b/drivers/gpu/drm/verisilicon/vs_dcu_lite.c
>> new file mode 100644
>> index 000000000000..11ef57d5ebaa
>> --- /dev/null
>> +++ b/drivers/gpu/drm/verisilicon/vs_dcu_lite.c
>> @@ -0,0 +1,78 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (C) 2026 Joey Lu <yclu4@nuvoton.com>
>> + */
>> +
>> +#include <linux/regmap.h>
>> +
>> +#include "vs_crtc_regs.h"
>> +#include "vs_dc.h"
>> +#include "vs_primary_plane_regs.h"
>> +
>> +static void vs_dcu_lite_bridge_enable(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_RESET);
>> +}
>> +
>> +static void vs_dcu_lite_bridge_disable(struct vs_dc *dc, unsigned
>> int output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_RESET);
>> +}
>> +
>> +static void vs_dcu_lite_crtc_begin(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_VALID);
>> +}
>> +
>> +static void vs_dcu_lite_crtc_flush(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_VALID);
>> +}
>> +
>> +static void vs_dcu_lite_crtc_enable(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_ENABLE);
>> +}
>> +
>> +static void vs_dcu_lite_crtc_disable(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_FB_CONFIG(output),
>> + VSDC_FB_CONFIG_ENABLE);
>> +}
>> +
>> +static void vs_dcu_lite_enable_vblank(struct vs_dc *dc, unsigned int
>> output)
>> +{
>> + regmap_set_bits(dc->regs, VSDC_DISP_IRQ_EN,
>> + VSDC_DISP_IRQ_VSYNC(output));
>> +}
>> +
>> +static void vs_dcu_lite_disable_vblank(struct vs_dc *dc, unsigned
>> int output)
>> +{
>> + regmap_clear_bits(dc->regs, VSDC_DISP_IRQ_EN,
>> + VSDC_DISP_IRQ_VSYNC(output));
>> +}
>> +
>> +static u32 vs_dcu_lite_irq_handler(struct vs_dc *dc)
>> +{
>> + u32 irqs;
>> +
>> + regmap_read(dc->regs, VSDC_DISP_IRQ_STA, &irqs);
>> + return irqs;
>> +}
>> +
>> +const struct vs_dc_funcs vs_dcu_lite_funcs = {
>> + .bridge_enable = vs_dcu_lite_bridge_enable,
>> + .bridge_disable =
>> vs_dcu_lite_bridge_disable,
>> + .crtc_begin = vs_dcu_lite_crtc_begin,
>> + .crtc_flush = vs_dcu_lite_crtc_flush,
>> + .crtc_enable = vs_dcu_lite_crtc_enable,
>> + .crtc_disable = vs_dcu_lite_crtc_disable,
>> + .enable_vblank = vs_dcu_lite_enable_vblank,
>> + .disable_vblank =
>> vs_dcu_lite_disable_vblank,
>> + .irq_handler = vs_dcu_lite_irq_handler,
>> +};
^ permalink raw reply
* Re: [PATCH v2 2/4] drm/verisilicon: add model ID constants and DCU Lite chip identity
From: Joey Lu @ 2026-05-20 3:08 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <5b7b28558aece1d99e93c1d69ce2c381929813a2.camel@iscas.ac.cn>
On 5/19/2026 3:37 PM, Icenowy Zheng wrote:
> 在 2026-05-19二的 13:51 +0800，Joey Lu写道：
>> Introduce symbolic constants VSDC_MODEL_DC8200 and
>> VSDC_MODEL_DCU_LITE
>> to replace magic numbers in the hardware database and probe path.
>>
>> Register the DCU Lite chip identity (model 0x0, revision 0x5560,
>> customer_id 0x305) in vs_chip_identities[], making the existing
>> vs_fill_chip_identity() path able to recognise Nuvoton MA35D1
>> hardware
>> purely through register reads.
> The HWDB change should be added in the end of the series, making it a
> gate to the newly added changes that is finally opened when
> everything's ready.
>
>> Also add three register-level macros for forthcoming DCU Lite
>> support:
>> - VSDC_DISP_IRQ_VSYNC(n) in vs_crtc_regs.h, for per-output VSYNC IRQ
>> bits used by the DCU Lite IRQ enable/status registers.
>> - VSDC_FB_CONFIG_ENABLE, VSDC_FB_CONFIG_VALID and
>> VSDC_FB_CONFIG_RESET
>> in vs_primary_plane_regs.h, for the framebuffer enable and
>> commit-cycle bits used by the DCU Lite plane update path.
> Maybe you can split the register change
Understood. I will split the register macro additions into a separate
patch: one for the new vs_crtc_regs.h IRQ macro and one for the
vs_primary_plane_regs.h FB_CONFIG bits, keeping them independent of the
HWDB identity change.
>> No behaviour change for existing DC8200 platforms.
>>
>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>> ---
>> drivers/gpu/drm/verisilicon/vs_crtc_regs.h | 1 +
>> drivers/gpu/drm/verisilicon/vs_hwdb.c | 16 ++++++++++++--
>> --
>> drivers/gpu/drm/verisilicon/vs_hwdb.h | 3 +++
>> .../gpu/drm/verisilicon/vs_primary_plane_regs.h | 3 +++
>> 4 files changed, 19 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
>> b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
>> index c7930e817635..d4da22b08cd5 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_crtc_regs.h
>> @@ -54,6 +54,7 @@
>> #define VSDC_DISP_GAMMA_DATA(n) (0x1460 +
>> 0x4 * (n))
>>
>> #define VSDC_DISP_IRQ_STA 0x147C
>> +#define VSDC_DISP_IRQ_VSYNC(n) BIT(n)
>>
>> #define VSDC_DISP_IRQ_EN 0x1480
>>
>> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> b/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> index 09336af0900a..a25c4b16181d 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.c
>> @@ -90,7 +90,7 @@ static const struct vs_formats
>> vs_formats_with_yuv444 = {
>>
>> static struct vs_chip_identity vs_chip_identities[] = {
>> {
>> - .model = 0x8200,
>> + .model = VSDC_MODEL_DC8200,
> I don't think such a macro is needed.
Understood. I will remove `VSDC_MODEL_DC8200` and use the literal
`0x8200` directly in vs_hwdb.c with a comment.
>> .revision = 0x5720,
>> .customer_id = ~0U,
>>
>> @@ -98,7 +98,7 @@ static struct vs_chip_identity vs_chip_identities[]
>> = {
>> .formats = &vs_formats_no_yuv444,
>> },
>> {
>> - .model = 0x8200,
>> + .model = VSDC_MODEL_DC8200,
>> .revision = 0x5721,
>> .customer_id = 0x30B,
>>
>> @@ -106,7 +106,7 @@ static struct vs_chip_identity
>> vs_chip_identities[] = {
>> .formats = &vs_formats_no_yuv444,
>> },
>> {
>> - .model = 0x8200,
>> + .model = VSDC_MODEL_DC8200,
>> .revision = 0x5720,
>> .customer_id = 0x310,
>>
>> @@ -114,13 +114,21 @@ static struct vs_chip_identity
>> vs_chip_identities[] = {
>> .formats = &vs_formats_with_yuv444,
>> },
>> {
>> - .model = 0x8200,
>> + .model = VSDC_MODEL_DC8200,
>> .revision = 0x5720,
>> .customer_id = 0x311,
>>
>> .display_count = 2,
>> .formats = &vs_formats_no_yuv444,
>> },
>> + {
>> + .model = VSDC_MODEL_DCU_LITE,
> The number is 0x0 and the whole public name of this IP is
> "DCUltraLite", w/o any numbers.
>
> I suggest leave it at 0x0 and add a comment saying this is DCUltraLite
> -- Verisilicon people are abusing suffix for their IP names now.
Understood. I will remove the `VSDC_MODEL_DCU_LITE` macro and use `0x0`
directly with a `/* DCUltraLite */` comment in vs_hwdb.c.
>> + .revision = 0x5560,
>> + .customer_id = 0x305,
>> +
>> + .display_count = 1,
>> + .formats = &vs_formats_no_yuv444,
>> + },
>> };
>>
>> int vs_fill_chip_identity(struct regmap *regs,
>> diff --git a/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> b/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> index 92192e4fa086..cca126bd2da5 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_hwdb.h
>> @@ -9,6 +9,9 @@
>> #include <linux/regmap.h>
>> #include <linux/types.h>
>>
>> +#define VSDC_MODEL_DC8200 0x8200
>> +#define VSDC_MODEL_DCU_LITE 0x0
>> +
>> struct vs_formats {
>> const u32 *array;
>> unsigned int num;
>> diff --git a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
>> b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
>> index cbb125c46b39..67d4b00f294e 100644
>> --- a/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
>> +++ b/drivers/gpu/drm/verisilicon/vs_primary_plane_regs.h
>> @@ -16,6 +16,9 @@
>> #define VSDC_FB_STRIDE(n) (0x1408 + 0x4 * (n))
>>
>> #define VSDC_FB_CONFIG(n) (0x1518 + 0x4 * (n))
>> +#define VSDC_FB_CONFIG_ENABLE BIT(0)
>> +#define VSDC_FB_CONFIG_VALID BIT(3)
>> +#define VSDC_FB_CONFIG_RESET BIT(4)
> Should the new IRQ register to be added here too?
>
> Thanks,
> Icenowy
`VSDC_DISP_IRQ_VSYNC(n)` is a bit-mask for the IRQ status/enable
registers (`VSDC_DISP_IRQ_STA` / `VSDC_DISP_IRQ_EN`) which already live
in vs_crtc_regs.h. Keeping it there alongside the register addresses it
operates on is cleaner than splitting the IRQ definitions across two
headers.
>> #define VSDC_FB_CONFIG_CLEAR_EN BIT(8)
>> #define VSDC_FB_CONFIG_ROT_MASK GENMASK(13,
>> 11)
>> #define VSDC_FB_CONFIG_ROT(v) ((v) << 11)
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: display: verisilicon, dc: generalize for single-output variants
From: Joey Lu @ 2026-05-20 3:06 UTC (permalink / raw)
To: Conor Dooley, Icenowy Zheng
Cc: 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: <20260519-fretful-blush-1aac18fa1360@spud>
On 5/20/2026 12:47 AM, Conor Dooley wrote:
> On Tue, May 19, 2026 at 03:26:58PM +0800, Icenowy Zheng wrote:
>> 在 2026-05-19二的 13:51 +0800，Joey Lu写道：
>>> The existing schema assumes a fixed clock/reset topology and dual-
>>> output
>>> port structure matching the DC8200 IP block. This prevents reuse for
>>> single-output variants such as the Verisilicon DCU Lite used in the
>>> Nuvoton MA35D1 SoC.
>>>
>>> Rework the schema so that variant-specific constraints are expressed
>>> via allOf/if-then-else:
>>>
>>> - The thead,th1520-dc8200 compatible keeps its existing five-clock,
>>> three-reset, dual-port requirements.
>>>
>>> - A standalone verisilicon,dc compatible covers IPs whose identity is
>>> discovered entirely through hardware registers; these have flexible
>>> clock and reset counts, a single 'port' property, and no 'ports'
>>> requirement.
>>>
>>> Changes to the base schema:
>>> - Replace the fixed clock/reset items lists with minItems/maxItems
>>> ranges; variant sub-schemas tighten the constraints via if-then-
>>> else.
>>> - Add a 'port' property (graph.yaml single-port alias) alongside the
>>> existing 'ports', for single-output variants.
>>> - Drop the unconditional 'ports' requirement; each if-branch enforces
>>> its own port topology.
>>> - Tighten additionalProperties to unevaluatedProperties to allow
>>> per-variant schemas to add their own constraints cleanly.
>>> - Fix a stray space in the port@0 description.
>>> - Add a DT example for the generic verisilicon,dc compatible
>>> (Nuvoton MA35D1 DCU Lite).
>>>
>>> Signed-off-by: Joey Lu <a0987203069@gmail.com>
>>> ---
>>> .../bindings/display/verisilicon,dc.yaml | 135 ++++++++++++++--
>>> --
>>> 1 file changed, 108 insertions(+), 27 deletions(-)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>>> b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>>> index 9dc35ab973f2..3a814c2e083e 100644
>>> --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>>> +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
>>> @@ -14,10 +14,12 @@ properties:
>>> pattern: "^display@[0-9a-f]+$"
>>>
>>> compatible:
>>> - items:
>>> - - enum:
>>> - - thead,th1520-dc8200
>> You should add a fallback compatible here for your SoC, in case its
>> integration gets something quirky; this compatible is usually not
>> consumed by the driver (see how thead,th1520-dc8200 exists in the
>> binding but not the driver).
> s/fallback compatible/soc-specific compatible/, but yes.
> NAK to what's been done here, especially after the discussions on
> earlier versions of this verisilicon binding.
> pw-bot: changes-requested
Understood. I will add `nuvoton,ma35d1-dcu` as the SoC-specific
compatible string paired with `verisilicon,dc` as the generic fallback,
matching the pattern used for `thead,th1520-dc8200`. The standalone
`verisilicon,dc` compatible will be removed from the binding. The driver
match table is not changed since hardware detection is done via ID
registers.
>>> - - const: verisilicon,dc # DC IPs have discoverable ID/revision
>>> registers
>>> + oneOf:
>>> + - items:
>>> + - enum:
>>> + - thead,th1520-dc8200
>>> + - const: verisilicon,dc
>>> + - const: verisilicon,dc # DC IPs have discoverable
>>> ID/revision registers
>>>
>>> reg:
>>> maxItems: 1
>>> @@ -26,32 +28,24 @@ properties:
>>> maxItems: 1
>>>
>>> clocks:
>>> - items:
>>> - - description: DC Core clock
>>> - - description: DMA AXI bus clock
>>> - - description: Configuration AHB bus clock
>>> - - description: Pixel clock of output 0
>>> - - description: Pixel clock of output 1
>>> + minItems: 2
>>> + maxItems: 5
>>>
>>> clock-names:
>>> - items:
>>> - - const: core
>>> - - const: axi
>>> - - const: ahb
>>> - - const: pix0
>>> - - const: pix1
>>> + minItems: 2
>>> + maxItems: 5
>>>
>>> resets:
>>> - items:
>>> - - description: DC Core reset
>>> - - description: DMA AXI bus reset
>>> - - description: Configuration AHB bus reset
>>> + minItems: 1
>>> + maxItems: 3
>>>
>>> reset-names:
>>> - items:
>>> - - const: core
>>> - - const: axi
>>> - - const: ahb
>>> + minItems: 1
>>> + maxItems: 3
>>> +
>>> + port:
>>> + $ref: /schemas/graph.yaml#/properties/port
>>> + description: Single video output port for single-output
>>> variants.
>> Maybe the endpoint numbering rule needs a move to here? (I am not very
>> sure).
I will add a description to the `port` property noting that endpoint 0
is used for DPI output, which is the only output type for DCUltraLite.
>>>
>>> ports:
>>> $ref: /schemas/graph.yaml#/properties/ports
>>> @@ -59,7 +53,7 @@ properties:
>>> properties:
>>> port@0:
>>> $ref: /schemas/graph.yaml#/properties/port
>>> - description: The first output channel , endpoint 0 should be
>>> + description: The first output channel, endpoint 0 should be
>>> used for DPI format output and endpoint 1 should be used
>>> for DP format output.
>>>
>>> @@ -75,9 +69,75 @@ required:
>>> - interrupts
>>> - clocks
>>> - clock-names
>>> - - ports
>>>
>>> -additionalProperties: false
>>> +allOf:
>>> + - if:
>>> + properties:
>>> + compatible:
>>> + contains:
>>> + const: thead,th1520-dc8200
>>> + then:
>>> + properties:
>>> + clocks:
>>> + items:
>>> + - description: DC Core clock
>>> + - description: DMA AXI bus clock
>>> + - description: Configuration AHB bus clock
>>> + - description: Pixel clock of output 0
>>> + - description: Pixel clock of output 1
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: core
>>> + - const: axi
>>> + - const: ahb
>>> + - const: pix0
>>> + - const: pix1
>>> +
>>> + resets:
>>> + items:
>>> + - description: DC Core reset
>>> + - description: DMA AXI bus reset
>>> + - description: Configuration AHB bus reset
>>> +
>>> + reset-names:
>>> + items:
>>> + - const: core
>>> + - const: axi
>>> + - const: ahb
>>> +
>>> + required:
>>> + - ports
>>> +
>>> + else:
>>> + properties:
>>> + clocks:
>>> + items:
>>> + - description: Bus clock that gates register access
>>> + - description: Pixel clock divider for display timing
>> Please don't make compatible-specific description strings for
>> individual compatibles, and keep these descriptions outside of the if.
>> The compatible-specific part should be used to specify what's required
>> for the specific SoC, for dt validation purpose.
>>
>> BTW if the clock is both the working clock and bus clock for the
>> controller, I suggest listing it twice, except if the IP core is
>> provided without a dedicated core clock (in the case I suggest to use
>> "bus" only).
> I agree. If the same clock is provided to two+ ports on the IP, that
> should still be two+ clocks in the devicetree.
>
>> Here's an example for "listing it twice":
>> ```
>> clocks = <&clk DCU_GATE>, <&clk DCU_GATE>, <&clk DCUP_DIV>;
>> clock-names = "core", "bus", "pix0";
>> ```
>>
>> Well nonetheless the name "core" does not match the description "Bus
>> clock that gates register access".
>>
>> Thanks,
>> Icenowy
Understood. I will remove all description strings from the if/else
branches; the if/then clauses will only constrain clock-names and
reset-names items (name values only, no descriptions). Regarding clock
naming: DCU_GATE on MA35D1 is a peripheral gate clock without a separate
dedicated core working clock, so I will keep "core" as the name and drop
the misleading description "Bus clock that gates register access". The
description mismatch was entirely in the if/else strings which are now
removed.
Thanks.
>>
>>> +
>>> + clock-names:
>>> + items:
>>> + - const: core
>>> + - const: pix0
>>> +
>>> + resets:
>>> + maxItems: 1
>>> + description:
>>> + Reset line for the display controller.
>>> +
>>> + reset-names:
>>> + items:
>>> + - const: core
>>> +
>>> + required:
>>> + - port
>>> +
>>> + not:
>>> + required:
>>> + - ports
>>> +
>>> +unevaluatedProperties: false
>>>
>>> examples:
>>> - |
>>> @@ -120,3 +180,24 @@ examples:
>>> };
>>> };
>>> };
>>> +
>>> + - |
>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>>> + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
>>> +
>>> + display@40260000 {
>>> + compatible = "verisilicon,dc";
>>> + reg = <0x40260000 0x20000>;
>>> + interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>;
>>> + clocks = <&clk DCU_GATE>, <&clk DCUP_DIV>;
>>> + clock-names = "core", "pix0";
>>> + resets = <&sys MA35D1_RESET_DISP>;
>>> + reset-names = "core";
>>> +
>>> + port {
>>> + dpi_out: endpoint {
>>> + remote-endpoint = <&panel_in>;
>>> + };
>>> + };
>>> + };
^ permalink raw reply
* Re: [PATCH 0/2] CPPC: reduce FFH feedback-counter sampling skew on arm64
From: Pengjie Zhang @ 2026-05-20 2:55 UTC (permalink / raw)
To: Will Deacon
Cc: catalin.marinas, rafael, lenb, robert.moore, beata.michalska,
zhenglifeng1, zhanjie9, sumitg, cuiyunhui, linux-arm-kernel,
linux-kernel, linux-acpi, acpica-devel, linuxarm,
jonathan.cameron, prime.zeng, wanghuiqiang, xuwei5, lihuisong,
yubowen8, wangzhi12, ionela.voinescu, jeremy.linton
In-Reply-To: <agw_1IYaY4zeobZE@willie-the-truck>
On 5/19/2026 6:47 PM, Will Deacon wrote:
> On Thu, Apr 30, 2026 at 06:00:44PM +0800, zhangpengjie (A) wrote:
>> Hi all,
>>
>> Gentle ping on this thread. It has been a while since I posted it.
>>
>> Could someone please take a look when you have time? If there is anything
>> I should revise or any additional information needed, I'd be happy to
>> update it.
> It's hard to find active folks who have contributed meaningfully to the
> cppc_acpi driver... I've added Ionella and Jeremy, in case they can take
> a look.
>
> Will
Thanks Will, and thanks for adding Ionela and Jeremy.
While waiting for further comments, I would like to add some
test data to make the effect of this series clearer.
On the test platform, the maximum frequency reported by the platform
is 2300000. I sampled cpuinfo_cur_freq before and after applying this
series.
Before applying the series, the samples showed visible transient outliers.
The minimum value was 2154583 and the maximum value was 2491071.
There were 8 samples above 2400000 and 8 samples below 2200000.
The largest value exceeded the platform maximum by about 8.3%.
After applying the series, the samples became much more stable.
The minimum value was 2290243 and the maximum value was 2306310.
There were no samples above 2400000 and no samples below 2200000.
The largest value exceeded the platform maximum by only about 0.27%.
A summary of the 96 samples is:
before after
min 2154583 2290243
max 2491071 2306310
range 336488 16067
average 2298436.4 2298479.4
stddev 55184.1 2868.2
samples > 2300000 26 / 96 16 / 96
samples > 2400000 8 / 96 0 / 96
samples < 2200000 8 / 96 0 / 96
So this series does not try to clamp the value to the platform maximum.
Instead, it reduces the sampling skew between the delivered and reference
feedback counters. The remaining small deviation around 2300000 is
much smaller than the previous transient spikes.
One concern that may come up is that an FFH read may cause an idle
target CPU to be woken, depending on the platform/vendor implementation.
However, that behavior is not introduced by this series. It is already part
of how FFH counter reads are implemented on such platforms. This series
only changes the sampling form for the FFH feedback counters: when both
delivered and reference counters are FFH counters, read them together
instead of issuing two separate FFH reads.
If the target CPU has to be involved for an FFH read, doing one paired
read should be no worse than doing two separate reads, and it also
narrows the sampling window between the two counters.
If there is any concern about the generic hook or the arm64 implementation,
I would be happy to revise it.
The raw data is as follows:
before:
2303809 2294827 2300000 2293643 2290740 2300000 2297228 2296082
2301707 2295354 2296601 2303163 2296766 2296543 2295412 2298394
2297387 2300000 2308274 2301882 2297752 2418568 2491071 2300000
2183264 2296238 2434731 2296721 2439777 2302159 2301773 2298226
2300000 2305936 2301133 2297511 2300000 2300000 2294408 2298494
2295011 2302721 2295955 2301505 2298064 2297419 2298933 2189595
2298058 2296046 2300000 2301449 2414908 2296559 2305251 2166666
2296626 2173303 2300000 2298806 2411389 2301822 2297291 2300000
2423831 2297902 2300000 2435730 2302433 2295353 2298898 2296043
2321868 2294907 2300000 2157841 2296052 2206530 2300000 2297811
2297920 2294382 2297767 2157230 2302564 2298504 2296822 2300000
2296868 2294866 2154583 2290888 2302542 2292549 2300000 2184259
after:
2303738 2296153 2298087 2295607 2301373 2298076 2300000 2295081
2297788 2300000 2300000 2295238 2301449 2300000 2298488 2297911
2301477 2298507 2294976 2296852 2293689 2294077 2293887 2292619
2300000 2300000 2298072 2300000 2291943 2300000 2295370 2300000
2301873 2304645 2300000 2296766 2300000 2300000 2290243 2297954
2297183 2306310 2300000 2296889 2300000 2303800 2301970 2296888
2300000 2301354 2300000 2298405 2298202 2296767 2298663 2302522
2297821 2302471 2300000 2303233 2298226 2298698 2300000 2297291
2296470 2300000 2298398 2300000 2295681 2300000 2300000 2296344
2300000 2296008 2302375 2297977 2298447 2296519 2295565 2294866
2297945 2300000 2294978 2303595 2300000 2300000 2294930 2301096
2296271 2296086 2294482 2300000 2294843 2300000 2296803 2295708
>> On 4/10/2026 5:41 PM, Pengjie Zhang wrote:
>>> The legacy CPPC feedback-counter path reads the delivered and reference
>>> performance counters separately.
>>>
>>> On arm64 systems using AMU-backed CPPC FFH counters, each FFH read is
>>> served through a cross-CPU counter read helper. Reading the counters
>>> separately therefore widens the sampling window between them and can
>>> skew the delivered/reference ratio used by cpuinfo_cur_freq. Under heavy
>>> load, the skew is observable as transient values that may exceed the
>>> platform maximum, as discussed in [1] and [2].
>>>
>>> This series adds a small generic hook for architectures that can obtain
>>> both FFH feedback counters in one operation, while preserving the
>>> existing per-register read path as the fallback.
>>>
>>> Patch 1 adds the generic CPPC hook and uses it from cppc_get_perf_ctrs().
>>> Patch 2 implements the hook on arm64 by sampling both AMU counters in a
>>> single operation on the target CPU.
>>>
>>> [1] https://lore.kernel.org/all/20231025093847.3740104-4-zengheng4@huawei.com/
>>> [2] https://lore.kernel.org/all/20231212072617.14756-1-lihuisong@huawei.com/
>>>
>>> Signed-off-by: Pengjie Zhang <zhangpengjie2@huawei.com>
>>>
>>> Pengjie Zhang (2):
>>> ACPI: CPPC: add paired FFH feedback-counter read hook
>>> arm64: topology: read CPPC FFH feedback counters in one operation
>>>
>>> arch/arm64/kernel/topology.c | 75 ++++++++++++++++++++++++++++++++----
>>> drivers/acpi/cppc_acpi.c | 58 +++++++++++++++++++++++++---
>>> include/acpi/cppc_acpi.h | 7 ++++
>>> 3 files changed, 127 insertions(+), 13 deletions(-)
>>>
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: dts: imx94: fix DDR PMU interrupt number
From: Xu Yang @ 2026-05-20 2:36 UTC (permalink / raw)
To: alice.guo
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <20260519105517.3638614-1-alice.guo@oss.nxp.com>
On Tue, May 19, 2026 at 06:55:15PM +0800, alice.guo@oss.nxp.com wrote:
> From: Alice Guo <alice.guo@nxp.com>
>
> The DDR Performance Monitor node was added with incorrect interrupt
> number 91, which actually belongs to the wdog4 watchdog. Fix it to the
> correct interrupt number 374.
>
> Fixes: e918e5f847b3 ("arm64: dts: imx94: add DDR Perf Monitor node")
>
> Signed-off-by: Alice Guo <alice.guo@nxp.com>
Thanks for the fixes!
Reviewed-by: Xu Yang <xu.yang_2@nxp.com>
> ---
> arch/arm64/boot/dts/freescale/imx94.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx94.dtsi b/arch/arm64/boot/dts/freescale/imx94.dtsi
> index c460ece6070f..379429b3072a 100644
> --- a/arch/arm64/boot/dts/freescale/imx94.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx94.dtsi
> @@ -1481,7 +1481,7 @@ netc_emdio: mdio@18,0 {
> ddr-pmu@4e090dc0 {
> compatible = "fsl,imx94-ddr-pmu", "fsl,imx93-ddr-pmu";
> reg = <0x0 0x4e090dc0 0x0 0x200>;
> - interrupts = <GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH>;
> + interrupts = <GIC_SPI 374 IRQ_TYPE_LEVEL_HIGH>;
> };
> };
> };
> --
> 2.34.1
>
^ permalink raw reply
* [STATUS] arm64/for-kernelci - 4b4362973b6ffc2c351f1c7b8999da36597a5752
From: KernelCI bot @ 2026-05-20 2:30 UTC (permalink / raw)
To: kernelci-results; +Cc: will, linux-arm-kernel
Hello,
Status summary for arm64/for-kernelci
Dashboard:
https://d.kernelci.org/c/arm64/for-kernelci/4b4362973b6ffc2c351f1c7b8999da36597a5752/
giturl: https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git
branch: for-kernelci
commit hash: 4b4362973b6ffc2c351f1c7b8999da36597a5752
origin: maestro
test start time: 2026-05-19 15:36:18.173000+00:00
Builds: 8 ✅ 0 ❌ 0 ⚠️
Boots: 35 ✅ 0 ❌ 1 ⚠️
Tests: 9863 ✅ 0 ❌ 93 ⚠️
### POSSIBLE REGRESSIONS
No possible regressions observed.
### FIXED REGRESSIONS
No fixed regressions observed.
### UNSTABLE TESTS
Hardware: bcm2711-rpi-4-b
> Config: defconfig+lab-setup+kselftest
- Architecture/compiler: arm64/gcc-14
- boot
last run: https://d.kernelci.org/test/maestro:6a0c90e5744d1c1da0226bfe
history: > ⚠️ > ✅ > ✅
Sent every day if there were changes in the past 24 hours.
Legend: ✅ PASS ❌ FAIL ⚠️ INCONCLUSIVE
--
This is an experimental report format. Please send feedback in!
Talk to us at kernelci@lists.linux.dev
Made with love by the KernelCI team - https://kernelci.org
^ permalink raw reply
* [PATCH v3] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Jinjie Ruan @ 2026-05-20 2:20 UTC (permalink / raw)
To: catalin.marinas, will, corbet, skhan, punit.agrawal, jic23,
osama.abdelkader, chenl311, fengchengwen, suzuki.poulose, maz,
lpieralisi, timothy.hayes, sascha.bischoff, arnd,
mrigendra.chaubey, pierre.gondois, dietmar.eggemann, yangyicong,
sudeep.holla, linux-arm-kernel, linux-doc, linux-kernel
Cc: ruanjinjie
On arm64, when booting with `maxcpus` greater than the number of present
CPUs (e.g., QEMU -smp cpus=4,maxcpus=8), some CPUs are marked as 'present'
but have not yet been registered via register_cpu(). Consequently,
the per-cpu device objects for these CPUs are not yet initialized.
In cpuhp_smt_enable(), the code iterates over all present CPUs. Calling
_cpu_up() for these unregistered CPUs eventually leads to
sysfs_create_group() being called with a NULL kobject (or a kobject
without a directory), triggering the following warning in
fs/sysfs/group.c:
if (WARN_ON(!kobj || (!update && !kobj->sd)))
return -EINVAL;
When booting with ACPI, arm64 smp_prepare_cpus() currently sets all
enumerated CPUs as "present" regardless of their status in the MADT. This
causes issues with SMT hotplug control. For instance, with QEMU's
"-smp 4,maxcpus=8" configuration, the MADT GICC entries are populated as
follows: the first four CPUs are marked Enabled while the remaining four
are marked Online Capable to support potential hot-plugging.
Fix this by:
1. When booting with ACPI, checking the ACPI_MADT_ENABLED flag in the GICC
entry before calling set_cpu_present() during SMP initialization.
2. Properly managing the present mask in acpi_map_cpu() and
acpi_unmap_cpu() to support actual CPU hotplug events, This aligns with
other architectures like x86 and LoongArch.
3. Update the arm64 CPU hotplug documentation to no longer state that all
online-capable vCPUs are marked as present by the kernel at boot time.
This ensures that only physically available or explicitly enabled CPUs
are in the present mask, keeping the SMT control logic consistent with
the actual hardware state.
How to reproduce:
1. echo off > /sys/devices/system/cpu/smt/control
psci: CPU1 killed (polled 0 ms)
psci: CPU3 killed (polled 0 ms)
2. echo 2 > /sys/devices/system/cpu/smt/control
Detected PIPT I-cache on CPU1
GICv3: CPU1: found redistributor 1 region 0:0x00000000080c0000
CPU1: Booted secondary processor 0x0000000001 [0x410fd082]
Detected PIPT I-cache on CPU3
GICv3: CPU3: found redistributor 3 region 0:0x0000000008100000
CPU3: Booted secondary processor 0x0000000003 [0x410fd082]
------------[ cut here ]------------
WARNING: fs/sysfs/group.c:137 at internal_create_group+0x41c/0x4bc, CPU#2: sh/181
Modules linked in:
CPU: 2 UID: 0 PID: 181 Comm: sh Not tainted 7.0.0-rc1-00010-g8d13386c7624 #142 PREEMPT
Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015
pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : internal_create_group+0x41c/0x4bc
lr : sysfs_create_group+0x18/0x24
sp : ffff80008078ba40
x29: ffff80008078ba40 x28: ffff296c980ad000 x27: ffff00007fb94128
x26: 0000000000000054 x25: ffffd693e845f3f0 x24: 0000000000000001
x23: 0000000000000001 x22: 0000000000000004 x21: 0000000000000000
x20: ffffd693e845fc10 x19: 0000000000000004 x18: 00000000ffffffff
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000358 x13: 0000000000000007 x12: 0000000000000350
x11: 0000000000000008 x10: 0000000000000407 x9 : 0000000000000400
x8 : ffff00007fbf3b60 x7 : 0000000000000000 x6 : ffffd693e845f3f0
x5 : ffff00007fb94128 x4 : 0000000000000000 x3 : ffff000000f4eac0
x2 : ffffd693e7095a08 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
internal_create_group+0x41c/0x4bc (P)
sysfs_create_group+0x18/0x24
topology_add_dev+0x1c/0x28
cpuhp_invoke_callback+0x104/0x20c
__cpuhp_invoke_callback_range+0x94/0x11c
_cpu_up+0x200/0x37c
cpuhp_smt_enable+0xbc/0x114
control_store+0xe8/0x1d4
dev_attr_store+0x18/0x2c
sysfs_kf_write+0x7c/0x94
kernfs_fop_write_iter+0x128/0x1b8
vfs_write+0x2b0/0x354
ksys_write+0x68/0xfc
__arm64_sys_write+0x1c/0x28
invoke_syscall+0x48/0x10c
el0_svc_common.constprop.0+0x40/0xe8
do_el0_svc+0x20/0x2c
el0_svc+0x34/0x124
el0t_64_sync_handler+0xa0/0xe4
el0t_64_sync+0x198/0x19c
---[ end trace 0000000000000000 ]---
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Yicong Yang <yangyicong@hisilicon.com>
Cc: stable@vger.kernel.org
Link: https://uefi.org/specs/ACPI/6.5/05_ACPI_Software_Programming_Model.html#gic-cpu-interface-gicc-structure
Fixes: eed4583bcf9a6 ("arm64: Kconfig: Enable HOTPLUG_SMT")
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
---
v3:
- Update the arm64 cpu-hotplug documentation as Catalin suggested.
- Update the commit message.
v2:
- Update the fix way.
---
Documentation/arch/arm64/cpu-hotplug.rst | 11 +++++++----
arch/arm64/kernel/acpi.c | 2 ++
arch/arm64/kernel/smp.c | 12 +++++++++++-
3 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst
index 8fb438bf7781..60f7f51d7b96 100644
--- a/Documentation/arch/arm64/cpu-hotplug.rst
+++ b/Documentation/arch/arm64/cpu-hotplug.rst
@@ -47,8 +47,9 @@ ever have can be described at boot. There are no power-domain considerations
as such devices are emulated.
CPU Hotplug on virtual systems is supported. It is distinct from physical
-CPU Hotplug as all resources are described as ``present``, but CPUs may be
-marked as disabled by firmware. Only the CPU's online/offline behaviour is
+CPU Hotplug as all resources are described in the static configuration tables,
+but vCPUs that are not enabled at boot are not marked as ``present`` by the
+kernel until they are hotplugged. Only the CPU's online/offline behaviour is
influenced by firmware. An example is where a virtual machine boots with a
single CPU, and additional CPUs are added once a cloud orchestrator deploys
the workload.
@@ -68,8 +69,10 @@ redistributors.
CPUs described as ``online capable`` but not ``enabled`` can be set to enabled
by the DSDT's Processor object's _STA method. On virtual systems the _STA method
-must always report the CPU as ``present``. Changes to the firmware policy can
-be notified to the OS via device-check or eject-request.
+must report the CPU as ``present`` when it is activated by the firmware.
+The kernel will then set the vCPU as ``present`` dynamically during the hotplug
+configuration process. Changes can be notified to the OS via device-check or
+eject-request.
CPUs described as ``enabled`` in the static table, should not have their _STA
modified dynamically by firmware. Soft-restart features such as kexec will
diff --git a/arch/arm64/kernel/acpi.c b/arch/arm64/kernel/acpi.c
index 5891f92c2035..681aa2bbc399 100644
--- a/arch/arm64/kernel/acpi.c
+++ b/arch/arm64/kernel/acpi.c
@@ -448,12 +448,14 @@ int acpi_map_cpu(acpi_handle handle, phys_cpuid_t physid, u32 apci_id,
return *pcpu;
}
+ set_cpu_present(*pcpu, true);
return 0;
}
EXPORT_SYMBOL(acpi_map_cpu);
int acpi_unmap_cpu(int cpu)
{
+ set_cpu_present(cpu, false);
return 0;
}
EXPORT_SYMBOL(acpi_unmap_cpu);
diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
index 1aa324104afb..5932e5b30b71 100644
--- a/arch/arm64/kernel/smp.c
+++ b/arch/arm64/kernel/smp.c
@@ -566,6 +566,11 @@ struct acpi_madt_generic_interrupt *acpi_cpu_get_madt_gicc(int cpu)
}
EXPORT_SYMBOL_GPL(acpi_cpu_get_madt_gicc);
+static bool acpi_cpu_is_present(int cpu)
+{
+ return acpi_cpu_get_madt_gicc(cpu)->flags & ACPI_MADT_ENABLED;
+}
+
/*
* acpi_map_gic_cpu_interface - parse processor MADT entry
*
@@ -670,6 +675,10 @@ static void __init acpi_parse_and_init_cpus(void)
early_map_cpu_to_node(i, acpi_numa_get_nid(i));
}
#else
+static bool acpi_cpu_is_present(int cpu)
+{
+ return false;
+}
#define acpi_parse_and_init_cpus(...) do { } while (0)
#endif
@@ -808,7 +817,8 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
if (err)
continue;
- set_cpu_present(cpu, true);
+ if (acpi_disabled || acpi_cpu_is_present(cpu))
+ set_cpu_present(cpu, true);
numa_store_cpu_info(cpu);
}
}
--
2.34.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox