* Re: [PATCH 3/3] arm64: dts: broadcom: rp1: Add PWM node
From: Krzysztof Kozlowski @ 2026-04-05 7:53 UTC (permalink / raw)
To: Andrea della Porta
Cc: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov
In-Reply-To: <ef79e974c6680202294a4cfde7cc791753bf1b3e.1775223441.git.andrea.porta@suse.com>
On Fri, Apr 03, 2026 at 04:31:56PM +0200, Andrea della Porta wrote:
> +
> &rp1_usb0 {
> pinctrl-0 = <&usb_vbus_default_state>;
> pinctrl-names = "default";
> diff --git a/arch/arm64/boot/dts/broadcom/rp1-common.dtsi b/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
> index 5a815c3797945..7e78501e62b0c 100644
> --- a/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
> +++ b/arch/arm64/boot/dts/broadcom/rp1-common.dtsi
> @@ -56,6 +56,16 @@ rp1_eth: ethernet@40100000 {
> #size-cells = <0>;
> };
>
> + rp1_pwm: pwm@4009c000 {
Don't break the order. Instead please read and follow DTS coding style.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: pwm: Add Raspberry Pi RP1 PWM controller
From: Krzysztof Kozlowski @ 2026-04-05 7:52 UTC (permalink / raw)
To: Andrea della Porta
Cc: Uwe Kleine-König, linux-pwm, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Broadcom internal kernel review list, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel, Naushir Patuck,
Stanimir Varbanov
In-Reply-To: <11b5eee3c22cfd034bb4b425d28a5a3ff2a71828.1775223441.git.andrea.porta@suse.com>
On Fri, Apr 03, 2026 at 04:31:54PM +0200, Andrea della Porta wrote:
> +required:
> + - compatible
> + - reg
> + - clocks
> +
Missing ref to pwm.yaml.
> +additionalProperties: false
and this should be unevaluatedProperties. See other files.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] i2c: p2wi: use dev_err_probe() for clock and reset errors
From: Adeel Zahid @ 2026-04-05 3:40 UTC (permalink / raw)
To: Andi Shyti, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland
Cc: linux-i2c, linux-arm-kernel, linux-sunxi, Adeel Zahid
Replace open-coded error logging and returns with dev_err_probe() when acquiring the clock and reset controller in probe.
This makes the error handling more concise and correctly handles deferred probe.
Signed-off-by: Adeel Zahid <adeel.m.zahid@gmail.com>
---
drivers/i2c/busses/i2c-sun6i-p2wi.c | 16 ++++++----------
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/i2c/busses/i2c-sun6i-p2wi.c b/drivers/i2c/busses/i2c-sun6i-p2wi.c
index fb5280b8cf7f..2be6d50273bd 100644
--- a/drivers/i2c/busses/i2c-sun6i-p2wi.c
+++ b/drivers/i2c/busses/i2c-sun6i-p2wi.c
@@ -245,20 +245,16 @@ static int p2wi_probe(struct platform_device *pdev)
return irq;
p2wi->clk = devm_clk_get_enabled(dev, NULL);
- if (IS_ERR(p2wi->clk)) {
- ret = PTR_ERR(p2wi->clk);
- dev_err(dev, "failed to enable clk: %d\n", ret);
- return ret;
- }
+ if (IS_ERR(p2wi->clk))
+ return dev_err_probe(dev, PTR_ERR(p2wi->clk),
+ "failed to enable clk\n");
parent_clk_freq = clk_get_rate(p2wi->clk);
p2wi->rstc = devm_reset_control_get_exclusive(dev, NULL);
- if (IS_ERR(p2wi->rstc)) {
- dev_err(dev, "failed to retrieve reset controller: %pe\n",
- p2wi->rstc);
- return PTR_ERR(p2wi->rstc);
- }
+ if (IS_ERR(p2wi->rstc))
+ return dev_err_probe(dev, PTR_ERR(p2wi->rstc),
+ "failed to retrieve reset controller\n");
ret = reset_control_deassert(p2wi->rstc);
if (ret) {
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] arm64: pi: validate bootargs before parsing them
From: Pengpeng Hou @ 2026-04-05 1:40 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon; +Cc: linux-arm-kernel, linux-kernel, pengpeng
In-Reply-To: <20260403143004.4-arm64-pi-bootargs-pengpeng@iscas.ac.cn>
Hi Will,
Thanks, that's a fair question.
The reason I cared here is not that we can make every malformed FDT survive
cleanly, but that this particular caller turns a raw property into an
unbounded C string immediately:
fdt_getprop() -> strlen() -> __parse_cmdline()
If `bootargs` is not NUL-terminated within the property bounds, `strlen()`
can walk past the property before the parser even starts. By contrast, a
NUL-terminated but semantically bogus string stays within the property bounds
and is then just handled as bad/ignored command-line content.
So the issue I was trying to harden is specifically “raw FDT property becomes
a C string without a local bound check”, not malformed DT handling in the
broadest sense.
You're also right to ask about scope. I do not think every early
`fdt_getprop()` caller should be converted mechanically; the ones that matter
here are the callers that immediately feed raw properties into unbounded
string helpers or parsers. This arm64 PI bootargs path is one of those.
I will rework this around that boundary instead of pushing this one caller in
isolation. In other words, I will audit the same early-bootargs family of
callers and only convert the ones that have this direct
`raw property -> unbounded C-string helper/parser` shape.
Thanks,
Pengpeng
^ permalink raw reply
* [PATCH v2] ARM: mvebu: validate memory node device_type before strcmp()
From: Pengpeng Hou @ 2026-04-05 0:41 UTC (permalink / raw)
To: Andrew Lunn, Gregory Clement, Sebastian Hesselbarth
Cc: linux-arm-kernel, linux-kernel, pengpeng
In-Reply-To: <20260403111504.4-dt-arm-mvebu-pengpeng@iscas.ac.cn>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]
mvebu_scan_mem() fetches the flat-DT device_type property and immediately
compares it with strcmp(). Flat DT properties are external boot input,
and this path does not prove that the property is NUL-terminated within
the returned property length.
Keep the existing flat-DT lookup path, but reject malformed
unterminated device_type values before comparing them as C strings.
This preserves the current distinction between an absent property and a
bad property value.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1:
- keep `of_get_flat_dt_prop()` instead of switching to `fdt_stringlist_get()`
- preserve the existing “not found” vs malformed-value behavior
arch/arm/mach-mvebu/board-v7.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-mvebu/board-v7.c b/arch/arm/mach-mvebu/board-v7.c
index a0740ab0..db6543ff 100644
--- a/arch/arm/mach-mvebu/board-v7.c
+++ b/arch/arm/mach-mvebu/board-v7.c
@@ -66,11 +66,13 @@ void __iomem *mvebu_get_scu_base(void)
static int __init mvebu_scan_mem(unsigned long node, const char *uname,
int depth, void *data)
{
- const char *type = of_get_flat_dt_prop(node, "device_type", NULL);
+ const char *type;
const __be32 *reg, *endp;
- int l;
+ int len, l;
- if (type == NULL || strcmp(type, "memory"))
+ type = of_get_flat_dt_prop(node, "device_type", &len);
+
+ if (!type || strnlen(type, len) >= len || strcmp(type, "memory"))
return 0;
reg = of_get_flat_dt_prop(node, "linux,usable-memory", &l);
--
2.50.1
^ permalink raw reply related
* [PATCH v2] ARM: xen: validate hypervisor compatible before parsing its version
From: Pengpeng Hou @ 2026-04-05 0:42 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel, linux-arm-kernel, linux-kernel, pengpeng
In-Reply-To: <20260403111502.2-dt-arm-xen-pengpeng@iscas.ac.cn>
fdt_find_hyper_node() reads the raw compatible property and then derives
hyper_node.version from a prefix match before later printing it with %s.
Flat DT properties are external boot input, and this path does not prove
that the first compatible entry is NUL-terminated within the returned
property length.
Keep the existing flat-DT lookup path, but verify that the first
compatible entry terminates within the returned property length before
deriving the version suffix from it.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
Changes since v1:
- keep `of_get_flat_dt_prop()` instead of switching to `fdt_stringlist_get()`
- validate the first compatible entry with bounded `strnlen()`
arch/arm/xen/enlighten.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm/xen/enlighten.c b/arch/arm/xen/enlighten.c
index 4feed2c2..25a0ce3b 100644
--- a/arch/arm/xen/enlighten.c
+++ b/arch/arm/xen/enlighten.c
@@ -218,8 +218,9 @@ static __initdata struct {
static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
int depth, void *data)
{
- const void *s = NULL;
+ const char *s = NULL;
int len;
+ size_t prefix_len = strlen(hyper_node.prefix);
if (depth != 1 || strcmp(uname, "hypervisor") != 0)
return 0;
@@ -228,9 +229,10 @@ static int __init fdt_find_hyper_node(unsigned long node, const char *uname,
hyper_node.found = true;
s = of_get_flat_dt_prop(node, "compatible", &len);
- if (strlen(hyper_node.prefix) + 3 < len &&
- !strncmp(hyper_node.prefix, s, strlen(hyper_node.prefix)))
- hyper_node.version = s + strlen(hyper_node.prefix);
+ if (s && len > 0 && strnlen(s, len) < len &&
+ len > prefix_len + 3 &&
+ !strncmp(hyper_node.prefix, s, prefix_len))
+ hyper_node.version = s + prefix_len;
/*
* Check if Xen supports EFI by checking whether there is the
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v3 1/2] mailbox: Use per-thread completion to fix wrong completion order
From: zhang @ 2026-04-05 0:58 UTC (permalink / raw)
To: joonwonkang
Cc: angelogioacchino.delregno, jassisinghbrar, jonathanh,
linux-arm-kernel, linux-kernel, linux-mediatek, linux-tegra,
matthias.bgg, stable, thierry.reding
In-Reply-To: <20260404124428.3077670-1-joonwonkang@google.com>
Hi! Joonwon Kang.
I just looked at the content of your email, and I think we can design a resource priority scheduling system with 70% and 30% priority allocation. The specific idea is as follows:
During task execution, each task can be tagged. Important tasks can be allocated to the 30% of resources, while the remaining 70% can be used to run low-load and repetitive pipeline tasks.
The specific algorithm can be written as follows: reserve 30% of the runtime space for the system's critical processes. For the remaining 70% of non-critical processes, a judgment can be made: if resource usage exceeds 70%, the excess processes are marked with a priority deferred tag and run only when resources are freed up.
--
the-essence-of-life
^ permalink raw reply
* Re: [PATCH 1/2] pmdomain/rockchip: skip QoS operations for idle-only domains
From: Daniel Bozeman @ 2026-04-04 22:42 UTC (permalink / raw)
To: shawn.lin, finley.xiao, jonas, ulf.hansson, heiko, linux-pm,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <f1b9a97a-f1f9-0757-5dc7-33960318be61@rock-chips.com>
Further testing with NO kernel patches and fw_devlink=strict
reveals both crashes happening simultaneously on different
CPUs:
CPU1 (genpd_power_off_work_fn):
pc : regmap_mmio_read32le+0x8/0x20
Workqueue: pm genpd_power_off_work_fn
CPU2 (deferred_probe_work_func):
pc : clk_gate_endisable+0xa8/0x130
Workqueue: events_unbound deferred_probe_work_func
Kernel panic - not syncing: Asynchronous SError Interrupt
This shows there are perhaps two independent issues:
1. genpd tries to power off idle-only domains and crashes
in rockchip_pmu_set_idle_request (the regmap read at
PMU offset 0x1120 faults)
2. GPIO4 probes while PD_RKVENC is not registered (power
domain controller tore down due to PD_GPU EPROBE_DEFER)
and crashes in clk_gate_endisable
Both crashes occur in the unpatched kernel. Previously we
only observed crash #2 because it appeared first in serial
output, but maybe they're racing on different CPUs?
I also tested removing all pm_qos from all idle-only
domains (PD_VO, PD_RKVENC, PD_VPU). Crash #1 still
occurs. Because it is in rockchip_pmu_set_idle_request,
not in QoS save/restore?
fw_devlink=strict does not prevent either crash.
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
From: Marc Zyngier @ 2026-04-04 21:07 UTC (permalink / raw)
To: Nathan Chancellor
Cc: kvmarm, linux-arm-kernel, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Sascha Bischoff, Will Deacon,
Catalin Marinas
In-Reply-To: <20260404181330.GA3987102@ax162>
On Sat, 04 Apr 2026 19:13:30 +0100,
Nathan Chancellor <nathan@kernel.org> wrote:
>
> Hi Marc,
>
> On Wed, Apr 01, 2026 at 06:00:17PM +0100, Marc Zyngier wrote:
> > As we are missing ID_AA64PFR2_EL1.GCIE from the kernel feature set,
> > userspace cannot write ID_AA64PFR2_EL1 with GCIE set, even if we are
> > on a GICv5 host.
> >
> > Add the required field description.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/kernel/cpufeature.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> > index 32c2dbcc0c641..5bca6e064ca72 100644
> > --- a/arch/arm64/kernel/cpufeature.c
> > +++ b/arch/arm64/kernel/cpufeature.c
> > @@ -327,6 +327,7 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
> > ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_FPMR_SHIFT, 4, 0),
> > ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTEFAR_SHIFT, 4, ID_AA64PFR2_EL1_MTEFAR_NI),
> > ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTESTOREONLY_SHIFT, 4, ID_AA64PFR2_EL1_MTESTOREONLY_NI),
> > + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_GCIE_SHIFT, 4, ID_AA64PFR2_EL1_GCIE_NI),
> > ARM64_FTR_END,
> > };
> >
> > --
> > 2.47.3
> >
>
> After this change in -next as commit 899ff451fcee ("KVM: arm64:
> Advertise ID_AA64PFR2_EL1.GCIE"), I am seeing a warning on boot in my
> simple QEMU boot tests.
>
> $ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- mrproper virtconfig Image.gz
>
> $ curl -LSs https://github.com/ClangBuiltLinux/boot-utils/releases/download/20241120-044434/arm64-rootfs.cpio.zst | zstd -d >rootfs.cpio
>
> $ qemu-system-aarch64 \
> -display none \
> -nodefaults \
> -machine virt,gic-version=max \
> -append 'console=ttyAMA0 earlycon' \
> -kernel arch/arm64/boot/Image.gz \
> -initrd rootfs.cpio \
> -cpu host \
> -enable-kvm \
> -m 1G \
> -smp 8 \
> -serial mon:stdio
> [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x413fd0c1]
> [ 0.000000] Linux version 7.0.0-rc4-00058-g899ff451fcee (nathan@aadp) (aarch64-linux-gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.45) #1 SMP PREEMPT Sat Apr 4 06:55:05 MST 2026
> ...
> [ 0.000000] ------------[ cut here ]------------
> [ 0.000000] SYS_ID_AA64PFR2_EL1 has feature overlap at shift 12
> [ 0.000000] WARNING: arch/arm64/kernel/cpufeature.c:986 at init_cpu_features+0xbc/0x344, CPU#0: swapper/0
> [ 0.000000] Modules linked in:
> [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-rc4-00058-g899ff451fcee #1 PREEMPT
> [ 0.000000] Hardware name: linux,dummy-virt (DT)
> [ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> [ 0.000000] pc : init_cpu_features+0xbc/0x344
> [ 0.000000] lr : init_cpu_features+0xbc/0x344
> [ 0.000000] sp : ffffcd0982373db0
> [ 0.000000] x29: ffffcd0982373db0 x28: 0000000000000010 x27: ffffcd0981c63878
> [ 0.000000] x26: 0000000000000018 x25: ffffcd0982013f38 x24: ffffcd0981c69068
> [ 0.000000] x23: ffffcd0981c635f0 x22: ffffcd0982388640 x21: 0000000000000003
> [ 0.000000] x20: 0000000000000017 x19: ffffcd09824c9308 x18: 000000000000000a
> [ 0.000000] x17: 5d305b203837205d x16: 305b203737205d30 x15: 0000000000000000
> [ 0.000000] x14: 0000000000000000 x13: 3231207466696873 x12: 2074612070616c72
> [ 0.000000] x11: 0000000000000058 x10: 0000000000000018 x9 : ffffcd0982396598
> [ 0.000000] x8 : 0000000000057fa8 x7 : 000000000000002a x6 : ffffcd09823ee598
> [ 0.000000] x5 : ffffcd09823ee598 x4 : 0000000000000000 x3 : 0000000000000000
> [ 0.000000] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffcd09823852c0
> [ 0.000000] Call trace:
> [ 0.000000] init_cpu_features+0xbc/0x344 (P)
> [ 0.000000] cpuinfo_store_boot_cpu+0x48/0x54
> [ 0.000000] smp_prepare_boot_cpu+0x28/0x38
> [ 0.000000] start_kernel+0x248/0x780
> [ 0.000000] __primary_switched+0x88/0x90
> [ 0.000000] ---[ end trace 0000000000000000 ]---
> ...
> ```
>
> Is this expected? I assume not, hence the report. If there is any
> information I can provide or patches I can test, I am more than happy to
> do so.
Gah. No idea how I managed to miss that: the register fields must be
strictly ordered, and I placed the field in the wrong spot. The
following hack fixes it for me:
diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index 5bca6e064ca72..1bfaa96881dab 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -325,9 +325,9 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr1[] = {
static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_FPMR_SHIFT, 4, 0),
+ ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_GCIE_SHIFT, 4, ID_AA64PFR2_EL1_GCIE_NI),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTEFAR_SHIFT, 4, ID_AA64PFR2_EL1_MTEFAR_NI),
ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTESTOREONLY_SHIFT, 4, ID_AA64PFR2_EL1_MTESTOREONLY_NI),
- ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_GCIE_SHIFT, 4, ID_AA64PFR2_EL1_GCIE_NI),
ARM64_FTR_END,
};
If that works for you, I'll fold that into the original patch...
Thanks for pointing this out!
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply related
* [PATCH] ARM: dts: rockchip: Remove invalid properies from rk3288-veyron-analog-audio
From: Fabio Estevam @ 2026-04-04 19:50 UTC (permalink / raw)
To: heiko
Cc: robh, krzk+dt, conor+dt, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Fabio Estevam
From: Fabio Estevam <festevam@nabladev.com>
The 'rockchip,mic-det-gpios' property is not documented anywhere.
The 'rockchip,hp-det-gpios' property is not a valid property for the
'rockchip,rockchip-audio-max98090' compatible.
Remove both invalid properties.
Signed-off-by: Fabio Estevam <festevam@nabladev.com>
---
arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi b/arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi
index 51208d161d65..25c7c0667856 100644
--- a/arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi
+++ b/arch/arm/boot/dts/rockchip/rk3288-veyron-analog-audio.dtsi
@@ -14,8 +14,6 @@ sound {
rockchip,model = "VEYRON-I2S";
rockchip,i2s-controller = <&i2s>;
rockchip,audio-codec = <&max98090>;
- rockchip,hp-det-gpios = <&gpio6 RK_PA5 GPIO_ACTIVE_HIGH>;
- rockchip,mic-det-gpios = <&gpio6 RK_PB3 GPIO_ACTIVE_LOW>;
rockchip,headset-codec = <&headsetcodec>;
rockchip,hdmi-codec = <&hdmi>;
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Paul Kocialkowski @ 2026-04-04 19:29 UTC (permalink / raw)
To: Krzysztof Hałasa
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lucas Stach, Marco Felsch,
Liu Ying
In-Reply-To: <m3ldf4mzh4.fsf@t19.piap.pl>
[-- Attachment #1: Type: text/plain, Size: 2661 bytes --]
Hi Krzysztof,
Le Fri 03 Apr 26, 06:36, Krzysztof Hałasa a écrit :
> Paul Kocialkowski <paulk@sys-base.io> writes:
> > Interestingly I tried to keep the clocks always on as an experiment and it
> > had the opposite effect: the DMA engine would get confused every time after the
> > first mode set and disable. So for some reason the disabling of the clocks seems
> > to mitigate the issue rather than aggravate it.
>
> Interesting. Fortunately we have a workaround.
>
> >> > + ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
> >> > + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
> >> > + 0, 36000); /* Wait ~2 frame times max */
> >>
> >> I guess this comment is not necessarily correct - at 2160p30 one frame =
> >> ca. 33 ms. Still works, though (I guess anything more than one frame is
> >> enough). I don't know how long a frame on HDMI (or LVDS, MIPI etc.) can
> >> take. 30 FPS on 2160p is common because the i.MX8MP can't display 2160p60.
> >
> > Honestly I think we're good assuming 30 fps (33 ms) is a lower bound.
> > And the current 36 ms goes even beyond, so I think it's fine.
>
> Right. It is just the comment in the code which is not exactly true.
> I.e., we "wait for at least 1 complete frame time". I guess.
> Also, the 25 ms in the patch (commit) message is no longer accurate.
In the end I made it 50 ms, which should be fine for all modes, and
adapted the comment in v2.
> >> Also, found an issue. Perhaps unrelated? Powered the board without HDMI
> >> connected. Then connected 1080p60 display. It came in 1024x768, console
> >> 64x24 :-)
> >
> > That looks more related to a failure to fetch the EDID from the monitor.
> > 1024x768 is the default fallback that is used in this situation.
> > Maybe check if there is something wrong with the DDC lines from the hdmi
> > controller, maybe pinmux etc.
>
> No no no, I did that on purpose - the monitor was really disconnected at
> the boot time. Only then (but before starting weston) i reconnected it.
> But it indeed appears to be a separate issue, a software one - a mutex
> deadlock on access to clocks and power management. Both enable and
> disable paths interfere there. "I will post a patch when I have a patch
> to post" :-)
Okay good to know, I'll get back to you if I also see this in the future :)
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Danilo Krummrich @ 2026-04-04 19:20 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Mark Brown,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Alex Williamson, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, linux-kernel, driver-core, linuxppc-dev,
linux-hyperv, linux-pci, platform-driver-x86, linux-arm-msm,
linux-remoteproc, linux-s390, linux-spi, virtualization, kvm,
xen-devel, linux-arm-kernel
In-Reply-To: <a8c85884-e2ba-4a3a-a660-9715f0de2704@kernel.org>
On Sat Apr 4, 2026 at 7:09 PM CEST, Christophe Leroy (CS GROUP) wrote:
> Yes please pick it up as my tree is based on rc1.
Applied the patch to driver-core-testing, thanks!
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
From: Nathan Chancellor @ 2026-04-04 18:13 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Joey Gouly, Suzuki K Poulose,
Oliver Upton, Zenghui Yu, Sascha Bischoff, Will Deacon,
Catalin Marinas
In-Reply-To: <20260401170017.369529-1-maz@kernel.org>
Hi Marc,
On Wed, Apr 01, 2026 at 06:00:17PM +0100, Marc Zyngier wrote:
> As we are missing ID_AA64PFR2_EL1.GCIE from the kernel feature set,
> userspace cannot write ID_AA64PFR2_EL1 with GCIE set, even if we are
> on a GICv5 host.
>
> Add the required field description.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kernel/cpufeature.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 32c2dbcc0c641..5bca6e064ca72 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -327,6 +327,7 @@ static const struct arm64_ftr_bits ftr_id_aa64pfr2[] = {
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_FPMR_SHIFT, 4, 0),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTEFAR_SHIFT, 4, ID_AA64PFR2_EL1_MTEFAR_NI),
> ARM64_FTR_BITS(FTR_VISIBLE, FTR_NONSTRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_MTESTOREONLY_SHIFT, 4, ID_AA64PFR2_EL1_MTESTOREONLY_NI),
> + ARM64_FTR_BITS(FTR_HIDDEN, FTR_STRICT, FTR_LOWER_SAFE, ID_AA64PFR2_EL1_GCIE_SHIFT, 4, ID_AA64PFR2_EL1_GCIE_NI),
> ARM64_FTR_END,
> };
>
> --
> 2.47.3
>
After this change in -next as commit 899ff451fcee ("KVM: arm64:
Advertise ID_AA64PFR2_EL1.GCIE"), I am seeing a warning on boot in my
simple QEMU boot tests.
$ make -skj"$(nproc)" ARCH=arm64 CROSS_COMPILE=aarch64-linux- mrproper virtconfig Image.gz
$ curl -LSs https://github.com/ClangBuiltLinux/boot-utils/releases/download/20241120-044434/arm64-rootfs.cpio.zst | zstd -d >rootfs.cpio
$ qemu-system-aarch64 \
-display none \
-nodefaults \
-machine virt,gic-version=max \
-append 'console=ttyAMA0 earlycon' \
-kernel arch/arm64/boot/Image.gz \
-initrd rootfs.cpio \
-cpu host \
-enable-kvm \
-m 1G \
-smp 8 \
-serial mon:stdio
[ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x413fd0c1]
[ 0.000000] Linux version 7.0.0-rc4-00058-g899ff451fcee (nathan@aadp) (aarch64-linux-gcc (GCC) 15.2.0, GNU ld (GNU Binutils) 2.45) #1 SMP PREEMPT Sat Apr 4 06:55:05 MST 2026
...
[ 0.000000] ------------[ cut here ]------------
[ 0.000000] SYS_ID_AA64PFR2_EL1 has feature overlap at shift 12
[ 0.000000] WARNING: arch/arm64/kernel/cpufeature.c:986 at init_cpu_features+0xbc/0x344, CPU#0: swapper/0
[ 0.000000] Modules linked in:
[ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.0.0-rc4-00058-g899ff451fcee #1 PREEMPT
[ 0.000000] Hardware name: linux,dummy-virt (DT)
[ 0.000000] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.000000] pc : init_cpu_features+0xbc/0x344
[ 0.000000] lr : init_cpu_features+0xbc/0x344
[ 0.000000] sp : ffffcd0982373db0
[ 0.000000] x29: ffffcd0982373db0 x28: 0000000000000010 x27: ffffcd0981c63878
[ 0.000000] x26: 0000000000000018 x25: ffffcd0982013f38 x24: ffffcd0981c69068
[ 0.000000] x23: ffffcd0981c635f0 x22: ffffcd0982388640 x21: 0000000000000003
[ 0.000000] x20: 0000000000000017 x19: ffffcd09824c9308 x18: 000000000000000a
[ 0.000000] x17: 5d305b203837205d x16: 305b203737205d30 x15: 0000000000000000
[ 0.000000] x14: 0000000000000000 x13: 3231207466696873 x12: 2074612070616c72
[ 0.000000] x11: 0000000000000058 x10: 0000000000000018 x9 : ffffcd0982396598
[ 0.000000] x8 : 0000000000057fa8 x7 : 000000000000002a x6 : ffffcd09823ee598
[ 0.000000] x5 : ffffcd09823ee598 x4 : 0000000000000000 x3 : 0000000000000000
[ 0.000000] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffcd09823852c0
[ 0.000000] Call trace:
[ 0.000000] init_cpu_features+0xbc/0x344 (P)
[ 0.000000] cpuinfo_store_boot_cpu+0x48/0x54
[ 0.000000] smp_prepare_boot_cpu+0x28/0x38
[ 0.000000] start_kernel+0x248/0x780
[ 0.000000] __primary_switched+0x88/0x90
[ 0.000000] ---[ end trace 0000000000000000 ]---
...
```
Is this expected? I assume not, hence the report. If there is any
information I can provide or patches I can test, I am more than happy to
do so.
Cheers,
Nathan
# bad: [2febe6e6ee6e34c7754eff3c4d81aa7b0dcb7979] Add linux-next specific files for 20260403
# good: [d8a9a4b11a137909e306e50346148fc5c3b63f9d] Merge tag 'v7.0-rc6-smb3-client-fix' of git://git.samba.org/sfrench/cifs-2.6
git bisect start 'origin/master' 'origin/stable'
# bad: [dc9c72702de7e46679f8c2ab2175ab7070baa3ee] Merge branch 'main' of https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git
git bisect bad dc9c72702de7e46679f8c2ab2175ab7070baa3ee
# bad: [d5ea83fae6558b2431b022781f6ccb74d241b2bb] Merge branch 'for-next' of https://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git
git bisect bad d5ea83fae6558b2431b022781f6ccb74d241b2bb
# bad: [d16ebd2d0dc90f1561d0a44a828db2c9148ad5f4] Merge branch 'for-next/perf' of https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git
git bisect bad d16ebd2d0dc90f1561d0a44a828db2c9148ad5f4
# bad: [768784742008ccebbf3e88a26a6e9e6aad76dc8e] Merge branch 'timekeeping-next' of https://github.com/Rust-for-Linux/linux.git
git bisect bad 768784742008ccebbf3e88a26a6e9e6aad76dc8e
# good: [b671065be2bef906bb3e0c1bc7be4055e84ea1d3] Merge branch 'at91-fixes' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git
git bisect good b671065be2bef906bb3e0c1bc7be4055e84ea1d3
# bad: [bd1f7328e25426f08cafa8333293411788c7957b] Merge branch kvm-arm64/vgic-fixes-7.1 into kvmarm-master/next
git bisect bad bd1f7328e25426f08cafa8333293411788c7957b
# good: [1cd0bb0425594cea9baf862393a4ca9cc0c018a3] Merge branch kvm-arm64/pkvm-psci into kvmarm-master/next
git bisect good 1cd0bb0425594cea9baf862393a4ca9cc0c018a3
# good: [bc20692f528b2ac8226bafe5b1db9a1f8be96dbf] KVM: arm64: Don't hold 'vm_table_lock' across guest page reclaim
git bisect good bc20692f528b2ac8226bafe5b1db9a1f8be96dbf
# good: [adb70b3a8b31e9eb05f2ec3c76d85f9a7a8c8cbc] KVM: arm64: Directly expose mapping prot and kill kvm_s2_fault
git bisect good adb70b3a8b31e9eb05f2ec3c76d85f9a7a8c8cbc
# good: [be46a408f376df31762e8a9914dc6d082755e686] KVM: arm64: Correctly plumb ID_AA64PFR2_EL1 into pkvm idreg handling
git bisect good be46a408f376df31762e8a9914dc6d082755e686
# good: [33cdd7f8fa32c92317aa521bd6f407a3cba8474b] Merge branch kvm-arm64/spe-trbe-nvhe into kvmarm-master/next
git bisect good 33cdd7f8fa32c92317aa521bd6f407a3cba8474b
# good: [e54971a0468a8bc82b1976d5b010392d7cb689b9] Merge branch kvm-arm64/vgic-fixes-7.1 into kvmarm-master/next
git bisect good e54971a0468a8bc82b1976d5b010392d7cb689b9
# bad: [899ff451fcee1289f3f37d061da66c3e38748a69] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
git bisect bad 899ff451fcee1289f3f37d061da66c3e38748a69
# good: [9c1ac77ddfc90b6292ef63a4fa5ab6f9e4b29981] KVM: arm64: vgic-v5: Fold PPI state for all exposed PPIs
git bisect good 9c1ac77ddfc90b6292ef63a4fa5ab6f9e4b29981
# first bad commit: [899ff451fcee1289f3f37d061da66c3e38748a69] KVM: arm64: Advertise ID_AA64PFR2_EL1.GCIE
^ permalink raw reply
* Re: [PATCH] ASoC: rockchip: rockchip_sai: Set slot width for non-TDM mode
From: Nicolas Frattaroli @ 2026-04-04 17:16 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Heiko Stuebner, Sugar Zhang, Alexey Charkov
Cc: linux-rockchip, linux-sound, linux-arm-kernel, linux-kernel,
Alexey Charkov
In-Reply-To: <20260318-sai-slot-width-v1-1-1f68186f71e3@flipper.net>
On Wednesday, 18 March 2026 15:50:25 Central European Summer Time Alexey Charkov wrote:
> Currently the slot width in non-TDM mode is always kept at the POR value
> of 32 bits, regardless of the sample width, which doesn't work well for
> some codecs such as NAU8822.
>
> Set the slot width according to the sample width in non-TDM mode, which
> is what other CPU DAI drivers do.
>
> Tested on the following RK3576 configurations:
> - SAI2 + NAU8822 (codec as the clock master), custom board
> - SAI1 + ES8388 (codec as the clock master), RK3576 EVB1
> - SAI2 + RT5616 (SAI as the clock master), FriendlyElec NanoPi M5
>
> NAU8822 didn't work prior to this patch but works after the patch. Other
> two configurations work both before and after the patch.
>
> Fixes: cc78d1eaabad ("ASoC: rockchip: add Serial Audio Interface (SAI) driver")
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
> ---
> sound/soc/rockchip/rockchip_sai.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/sound/soc/rockchip/rockchip_sai.c b/sound/soc/rockchip/rockchip_sai.c
> index 1bf614dbdf4d..ed393e5034a4 100644
> --- a/sound/soc/rockchip/rockchip_sai.c
> +++ b/sound/soc/rockchip/rockchip_sai.c
> @@ -628,6 +628,10 @@ static int rockchip_sai_hw_params(struct snd_pcm_substream *substream,
>
> regmap_update_bits(sai->regmap, reg, SAI_XCR_VDW_MASK | SAI_XCR_CSR_MASK, val);
>
> + if (!sai->is_tdm)
> + regmap_update_bits(sai->regmap, reg, SAI_XCR_SBW_MASK,
> + SAI_XCR_SBW(params_physical_width(params)));
> +
> regmap_read(sai->regmap, reg, &val);
>
> slot_width = SAI_XCR_SBW_V(val);
>
> ---
> base-commit: 8e5a478b6d6a5bb0a3d52147862b15e4d826af19
> change-id: 20260318-sai-slot-width-378eed5c22cd
>
> Best regards,
>
Okay, so I took a logic analyzer to the SAI today and found the following:
It seems we've always been sending 16-bit samples in 32-bit width slots per
channel before. With this change, we're now correctly sending 16-bit samples
in 16-bit slots.
In a follow-up patch (doesn't have to be in this one, this is fine to merge
as-is) we could also refactor the switch statement just above to no longer
exist but set val = SAI_XCR_VDW(params_width(params)).
So:
Acked-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
Kind regards,
Nicolas Frattaroli
^ permalink raw reply
* Re: [PATCH V2 0/8] PCI: imx6: Integrate pwrctrl API and update device trees
From: Manivannan Sadhasivam @ 2026-04-04 17:10 UTC (permalink / raw)
To: Sherry Sun
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
lpieralisi, kwilczynski, bhelgaas, hongxing.zhu, l.stach, imx,
linux-pci, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260402101007.208419-1-sherry.sun@nxp.com>
On Thu, Apr 02, 2026 at 06:09:59PM +0800, Sherry Sun wrote:
> Note: This patch set depends on my previous patch set [1] which adds
> Root Port device tree nodes and support parsing the reset property in
> new Root Port binding in pci-imx6 driver.
>
> This series integrates the PCI pwrctrl framework into the pci-imx6
> driver and updates i.MX EVK board device trees to support it.
>
> Patches 2-8 update device trees for i.MX EVK boards which maintained
> by NXP to move power supply properties from the PCIe controller node
> to the Root Port child node, which is required for pwrctrl framework.
> Affected boards:
> - i.MX6Q/DL SABRESD
> - i.MX6SX SDB
> - i.MX8MM EVK
> - i.MX8MP EVK
> - i.MX8MQ EVK
> - i.MX8DXL/QM/QXP EVK
> - i.MX95 15x15/19x19 EVK
>
> The driver maintains legacy regulator handling for device trees that
> haven't been updated yet. Both old and new device tree structures are
> supported.
>
Thanks for the work! Due to some recently merged patches, this series (Patch 1)
doesn't apply on top of pci/controller/dwc-imx6 branch. Please rebase and
resend!
- Mani
> [1] https://lore.kernel.org/all/20260318062916.2747472-1-sherry.sun@nxp.com/
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> Changes in V2:
> 1. After commit 2d8c5098b847 ("PCI/pwrctrl: Do not power off on pwrctrl
> device removal"), the pwrctrl drivers no longer power off devices
> during removal. Update pci-imx6 driver's shutdown callback in patch#1
> to explicitly call pci_pwrctrl_power_off_devices() before
> pci_pwrctrl_destroy_devices() to ensure devices are properly powered
> off.
> ---
>
> Sherry Sun (8):
> PCI: imx6: Integrate new pwrctrl API for pci-imx6
> arm: dts: imx6qdl-sabresd: Move power supply property to Root Port
> node
> arm: dts: imx6sx-sdb: Move power supply property to Root Port node
> arm64: dts: imx8mm-evk: Move power supply property to Root Port node
> arm64: dts: imx8mp-evk: Move power supply properties to Root Port node
> arm64: dts: imx8mq-evk: Move power supply properties to Root Port node
> arm64: dts: imx8dxl/qm/qxp: Move power supply properties to Root Port
> node
> arm64: dts: imx95: Move power supply properties to Root Port node
>
> .../arm/boot/dts/nxp/imx/imx6qdl-sabresd.dtsi | 2 +-
> arch/arm/boot/dts/nxp/imx/imx6sx-sdb.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 4 ++--
> arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi | 2 +-
> arch/arm64/boot/dts/freescale/imx8mp-evk.dts | 4 ++--
> arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 4 ++--
> arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 4 ++--
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 ++--
> .../boot/dts/freescale/imx95-15x15-evk.dts | 4 ++--
> .../boot/dts/freescale/imx95-19x19-evk.dts | 8 +++----
> drivers/pci/controller/dwc/Kconfig | 1 +
> drivers/pci/controller/dwc/pci-imx6.c | 24 ++++++++++++++++++-
> 12 files changed, 43 insertions(+), 20 deletions(-)
>
> --
> 2.37.1
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Christophe Leroy (CS GROUP) @ 2026-04-04 17:09 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Mark Brown,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Alex Williamson, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, linux-kernel, driver-core, linuxppc-dev,
linux-hyperv, linux-pci, platform-driver-x86, linux-arm-msm,
linux-remoteproc, linux-s390, linux-spi, virtualization, kvm,
xen-devel, linux-arm-kernel
In-Reply-To: <DHKJ7VWI1CHO.3ETHUGQVPFFDE@kernel.org>
Le 04/04/2026 à 19:04, Danilo Krummrich a écrit :
> On Sat Apr 4, 2026 at 6:58 PM CEST, Christophe Leroy (CS GROUP) wrote:
>>
>>
>> Le 04/04/2026 à 17:07, Danilo Krummrich a écrit :
>>> On Tue Mar 24, 2026 at 1:59 AM CET, Danilo Krummrich wrote:
>>>> Danilo Krummrich (12):
>>>> PCI: use generic driver_override infrastructure
>>>> platform/wmi: use generic driver_override infrastructure
>>>> vdpa: use generic driver_override infrastructure
>>>> s390/cio: use generic driver_override infrastructure
>>>> s390/ap: use generic driver_override infrastructure
>>>
>>> Applied to driver-core-testing, thanks!
>>>
>>>> amba: use generic driver_override infrastructure
>>>> cdx: use generic driver_override infrastructure
>>>> hv: vmbus: use generic driver_override infrastructure
>>>> rpmsg: use generic driver_override infrastructure
>>>
>>> I have not picked these up, as they have not received ACKs from the
>>> corresponding subsystem maintainers so far.
>>>
>>>> bus: fsl-mc: use generic driver_override infrastructure
>>
>> I droped it from soc_fsl tree, some dependency must be missing.
>>
>> Feal free to take it if you can, it is acked-by Ioana.
>
> It is based on v7.0-rc5; if you want I can pick it up.
Yes please pick it up as my tree is based on rc1.
Thanks
Christophe
>
>>>> spi: use generic driver_override infrastructure
>>>
>>> These have already been picked up via the respective subsystem trees -- thanks!
>>>
>>> Thanks,
>>> Danilo
>
^ permalink raw reply
* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Danilo Krummrich @ 2026-04-04 17:04 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki,
Ioana Ciornei, Nipun Gupta, Nikhil Agarwal, K. Y. Srinivasan,
Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li, Bjorn Helgaas,
Armin Wolf, Bjorn Andersson, Mathieu Poirier, Vineeth Vijayan,
Peter Oberparleiter, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Harald Freudenberger, Holger Dengler, Mark Brown,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Alex Williamson, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, linux-kernel, driver-core, linuxppc-dev,
linux-hyperv, linux-pci, platform-driver-x86, linux-arm-msm,
linux-remoteproc, linux-s390, linux-spi, virtualization, kvm,
xen-devel, linux-arm-kernel
In-Reply-To: <76355cb5-0b5d-4a29-9702-8d020a79f4c0@kernel.org>
On Sat Apr 4, 2026 at 6:58 PM CEST, Christophe Leroy (CS GROUP) wrote:
>
>
> Le 04/04/2026 à 17:07, Danilo Krummrich a écrit :
>> On Tue Mar 24, 2026 at 1:59 AM CET, Danilo Krummrich wrote:
>>> Danilo Krummrich (12):
>>> PCI: use generic driver_override infrastructure
>>> platform/wmi: use generic driver_override infrastructure
>>> vdpa: use generic driver_override infrastructure
>>> s390/cio: use generic driver_override infrastructure
>>> s390/ap: use generic driver_override infrastructure
>>
>> Applied to driver-core-testing, thanks!
>>
>>> amba: use generic driver_override infrastructure
>>> cdx: use generic driver_override infrastructure
>>> hv: vmbus: use generic driver_override infrastructure
>>> rpmsg: use generic driver_override infrastructure
>>
>> I have not picked these up, as they have not received ACKs from the
>> corresponding subsystem maintainers so far.
>>
>>> bus: fsl-mc: use generic driver_override infrastructure
>
> I droped it from soc_fsl tree, some dependency must be missing.
>
> Feal free to take it if you can, it is acked-by Ioana.
It is based on v7.0-rc5; if you want I can pick it up.
>>> spi: use generic driver_override infrastructure
>>
>> These have already been picked up via the respective subsystem trees -- thanks!
>>
>> Thanks,
>> Danilo
^ permalink raw reply
* Re: [PATCH v1] PCI: imx6: Fix reference clock source selection
From: Manivannan Sadhasivam @ 2026-04-04 17:00 UTC (permalink / raw)
To: Richard Zhu, Lucas Stach, Lorenzo Pieralisi,
Krzysztof Wilczyński, Rob Herring, Bjorn Helgaas, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Franz Schnyder
Cc: Franz Schnyder, linux-pci, linux-arm-kernel, imx, linux-kernel,
Francesco Dolcini, stable
In-Reply-To: <20260325093118.684142-1-fra.schnyder@gmail.com>
On Wed, 25 Mar 2026 10:31:16 +0100, Franz Schnyder wrote:
> In the PCIe PHY init for the iMX95, the reference clock source selection
> uses a conditional instead of always passing the mask. This currently
> breaks functionality if the internal refclk is used.
>
> Pass always IMX95_PCIE_REF_USE_PAD as the mask and clear the bit if
> external refclk is not used.
>
> [...]
Applied, thanks!
[1/1] PCI: imx6: Fix reference clock source selection
commit: 575d7268ca07fcb1d1a50399e1399ba60df3cb27
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply
* Re: (subset) [PATCH 00/12] treewide: Convert buses to use generic driver_override
From: Christophe Leroy (CS GROUP) @ 2026-04-04 16:58 UTC (permalink / raw)
To: Danilo Krummrich, Russell King, Greg Kroah-Hartman,
Rafael J. Wysocki, Ioana Ciornei, Nipun Gupta, Nikhil Agarwal,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Bjorn Helgaas, Armin Wolf, Bjorn Andersson, Mathieu Poirier,
Vineeth Vijayan, Peter Oberparleiter, Heiko Carstens,
Vasily Gorbik, Alexander Gordeev, Christian Borntraeger,
Sven Schnelle, Harald Freudenberger, Holger Dengler, Mark Brown,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
Alex Williamson, Juergen Gross, Stefano Stabellini,
Oleksandr Tyshchenko, Christophe Leroy (CS GROUP)
Cc: linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel
In-Reply-To: <DHKGQN6D0ANO.2QYY3JTM5435O@kernel.org>
Le 04/04/2026 à 17:07, Danilo Krummrich a écrit :
> On Tue Mar 24, 2026 at 1:59 AM CET, Danilo Krummrich wrote:
>> Danilo Krummrich (12):
>> PCI: use generic driver_override infrastructure
>> platform/wmi: use generic driver_override infrastructure
>> vdpa: use generic driver_override infrastructure
>> s390/cio: use generic driver_override infrastructure
>> s390/ap: use generic driver_override infrastructure
>
> Applied to driver-core-testing, thanks!
>
>> amba: use generic driver_override infrastructure
>> cdx: use generic driver_override infrastructure
>> hv: vmbus: use generic driver_override infrastructure
>> rpmsg: use generic driver_override infrastructure
>
> I have not picked these up, as they have not received ACKs from the
> corresponding subsystem maintainers so far.
>
>> bus: fsl-mc: use generic driver_override infrastructure
I droped it from soc_fsl tree, some dependency must be missing.
Feal free to take it if you can, it is acked-by Ioana.
>> spi: use generic driver_override infrastructure
>
> These have already been picked up via the respective subsystem trees -- thanks!
>
> Thanks,
> Danilo
^ permalink raw reply
* Re: [PATCH 02/12] bus: fsl-mc: use generic driver_override infrastructure
From: Christophe Leroy (CS GROUP) @ 2026-04-04 16:56 UTC (permalink / raw)
To: Ioana Ciornei, Danilo Krummrich
Cc: Russell King, Greg Kroah-Hartman, Rafael J. Wysocki, Nipun Gupta,
Nikhil Agarwal, K. Y. Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Bjorn Helgaas, Armin Wolf, Bjorn Andersson,
Mathieu Poirier, Vineeth Vijayan, Peter Oberparleiter,
Heiko Carstens, Vasily Gorbik, Alexander Gordeev,
Christian Borntraeger, Sven Schnelle, Harald Freudenberger,
Holger Dengler, Mark Brown, Michael S. Tsirkin, Jason Wang,
Xuan Zhuo, Eugenio PĂ©rez, Alex Williamson,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
linux-kernel, driver-core, linuxppc-dev, linux-hyperv, linux-pci,
platform-driver-x86, linux-arm-msm, linux-remoteproc, linux-s390,
linux-spi, virtualization, kvm, xen-devel, linux-arm-kernel,
Gui-Dong Han
In-Reply-To: <4c5e9bad-82f0-4714-99c2-8ccd79a45043@kernel.org>
Le 28/03/2026 à 13:10, Christophe Leroy (CS GROUP) a écrit :
>
>
> Le 25/03/2026 à 13:01, Ioana Ciornei a écrit :
>> On Tue, Mar 24, 2026 at 01:59:06AM +0100, Danilo Krummrich wrote:
>>> When a driver is probed through __driver_attach(), the bus' match()
>>> callback is called without the device lock held, thus accessing the
>>> driver_override field without a lock, which can cause a UAF.
>>>
>>> Fix this by using the driver-core driver_override infrastructure taking
>>> care of proper locking internally.
>>>
>>> Note that calling match() from __driver_attach() without the device lock
>>> held is intentional. [1]
>>>
>>> Link: https://eur01.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Flore.kernel.org%2Fdriver-
>>> core%2FDGRGTIRHA62X.3RY09D9SOK77P%40kernel.org%2F&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C4b9262ddecdd4ce29f9808de8a66485e%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639100369055903282%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=%2BRfjlUkq7oWV%2F0v2S2B%2BEuxCY%2FLRQv6qHiEWiupd6kc%3D&reserved=0 [1]
>>> Reported-by: Gui-Dong Han <hanguidong02@gmail.com>
>>> Closes: https://eur01.safelinks.protection.outlook.com/?
>>> url=https%3A%2F%2Fbugzilla.kernel.org%2Fshow_bug.cgi%3Fid%3D220789&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C4b9262ddecdd4ce29f9808de8a66485e%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639100369055936232%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=XL1K1ICiygOZnlvDUbQFe192KnLsBQms0HFNGCuyz%2Fw%3D&reserved=0
>>> Fixes: 1f86a00c1159 ("bus/fsl-mc: add support for 'driver_override'
>>> in the mc-bus")
>>> Signed-off-by: Danilo Krummrich <dakr@kernel.org>
>>
>> Tested-by: Ioana Ciornei <ioana.ciornei@nxp.com>
>> Signed-off-by: Ioana Ciornei <ioana.ciornei@nxp.com>
>>
>
>
> Applied, thanks
Have to drop it for now, build fails:
CALL scripts/checksyscalls.sh
CC drivers/bus/fsl-mc/fsl-mc-bus.o
drivers/bus/fsl-mc/fsl-mc-bus.c: In function 'fsl_mc_bus_match':
drivers/bus/fsl-mc/fsl-mc-bus.c:92:15: error: implicit declaration of
function 'device_match_driver_override'
[-Werror=implicit-function-declaration]
92 | ret = device_match_driver_override(dev, drv);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/bus/fsl-mc/fsl-mc-bus.c: At top level:
drivers/bus/fsl-mc/fsl-mc-bus.c:321:10: error: 'const struct bus_type'
has no member named 'driver_override'
321 | .driver_override = true,
| ^~~~~~~~~~~~~~~
drivers/bus/fsl-mc/fsl-mc-bus.c:321:28: warning: initialization of
'const char *' from 'int' makes pointer from integer without a cast
[-Wint-conversion]
321 | .driver_override = true,
| ^~~~
drivers/bus/fsl-mc/fsl-mc-bus.c:321:28: note: (near initialization for
'fsl_mc_bus_type.dev_name')
cc1: some warnings being treated as errors
make[5]: *** [scripts/Makefile.build:289:
drivers/bus/fsl-mc/fsl-mc-bus.o] Error 1
make[4]: *** [scripts/Makefile.build:546: drivers/bus/fsl-mc] Error 2
make[3]: *** [scripts/Makefile.build:546: drivers/bus] Error 2
make[2]: *** [scripts/Makefile.build:546: drivers] Error 2
make[1]: *** [/home/chleroy/linux-powerpc/Makefile:2101: .] Error 2
make: *** [Makefile:248: __sub-make] Error 2
Christophe
^ permalink raw reply
* Re: [GIT PULL] Microchip ARM64 SoC updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:35 UTC (permalink / raw)
To: Claudiu Beznea; +Cc: soc, arm, conor, nicolas.ferre, linux-arm-kernel
In-Reply-To: <20260403070658.2554567-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:06:58AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/microchip-soc-7.1
>
> for you to fetch changes up to e4ffa98a02f4d16eda9a5faec6792493b41dab35:
>
> arm64: Kconfig: provide a top-level switch for Microchip platforms (2026-03-18 10:55:49 +0200)
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Microchip ARM64 device tree updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:33 UTC (permalink / raw)
To: Claudiu Beznea; +Cc: soc, arm, conor, nicolas.ferre, linux-arm-kernel
In-Reply-To: <20260403070637.2554408-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:06:37AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/microchip-dt64-7.1
>
> for you to fetch changes up to 711cca0f1cfef57018654b969da4041c2bab68d3:
>
> arm64: dts: microchip: add EV23X71A board (2026-03-20 10:56:22 +0200)
>
> ----------------------------------------------------------------
> Microchip ARM64 device tree updates for v7.1
>
> This update includes:
> - device tree files for the Microchip LAN9691 SoC and its evaluation
> board (Microchip EV23X71A)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Microchip AT91 SoC updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:31 UTC (permalink / raw)
To: Claudiu Beznea
Cc: soc, arm, nicolas.ferre, alexandre.belloni, linux-arm-kernel
In-Reply-To: <20260403070344.2553018-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:03:44AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-soc-7.1
>
> for you to fetch changes up to f3ae0049ff8a3d2cbd8c05857705744435629d0c:
>
> dt-bindings: arm: atmel,at91rm9200-sdramc: convert to DT schema (2026-03-07 16:41:03 +0200)
>
> ----------------------------------------------------------------
> Microchip AT91 SoC updates for v7.1
>
> This update includes:
> - device tree bindings conversion to DT schema for CHIPID, RAM
> controller and PIT, PIT64b, ST timers
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Microchip AT91 device tree updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:28 UTC (permalink / raw)
To: Claudiu Beznea
Cc: soc, arm, nicolas.ferre, alexandre.belloni, linux-arm-kernel
In-Reply-To: <20260403070327.2552867-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:03:27AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-dt-7.1
>
> for you to fetch changes up to 7d7a9fc1310a0ade8ea61c5eb4d8b29456f8d604:
>
> ARM: dts: microchip: sama7d65: add Cortex-A7 PMU node (2026-03-24 15:35:37 +0200)
>
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
* Re: [GIT PULL] Microchip AT91 defconfig updates for v7.1
From: Krzysztof Kozlowski @ 2026-04-04 15:25 UTC (permalink / raw)
To: Claudiu Beznea
Cc: soc, arm, nicolas.ferre, alexandre.belloni, linux-arm-kernel
In-Reply-To: <20260403070259.2552626-1-claudiu.beznea@tuxon.dev>
On Fri, Apr 03, 2026 at 10:02:59AM +0300, Claudiu Beznea wrote:
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux.git tags/at91-defconfig-7.1
>
> for you to fetch changes up to 1f17fce8bf19a48e5e5610c6da8f806eab81878a:
>
> ARM: configs: at91: sama7: enable LVDS serializer support (2026-02-28 16:04:03 +0200)
>
> ----------------------------------------------------------------
> Microchip AT91 defconfig updates for v7.1
>
> This update includes:
> - LCD controller, LVDS controller, backlight, simple pannel, touchscreen
> configuration flags required by SAMA7D65 SoC
Thanks, applied
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox