* Re: [PATCH v2 3/3] ASoC: sunxi: sun4i-spdif: Reorder clock enable sequence
From: Bui Duc Phuc @ 2026-05-23 12:11 UTC (permalink / raw)
To: wens
Cc: broonie, codekipper, jernej.skrabec, lgirdwood, linux-arm-kernel,
linux-kernel, linux-sound, linux-sunxi, nichen, perex, samuel,
tiwai
In-Reply-To: <CAGb2v67aXgg8BmrtVVBi+_n32OBcQnQgEUe3XdRp6Jj=aEr8fg@mail.gmail.com>
Hi Chen-yu,
Thanks for your feedback
On Sat, May 23, 2026 at 2:20 AM Chen-Yu Tsai <wens@kernel.org> wrote:
> > Enable the APB bus clock before the SPDIF module clock
> > during runtime resume, as register accesses depend on the
> > bus clock being enabled first.
>
> That does not even matter here. Access will only happen once the runtime
> PM callbacks return.
>
I understand your point that sun4i-spdif doesn't immediately access
registers within the current runtime_resume path, so the order might
not trigger a failure right now.
However, if we look at the peer driver for the same Sunxi SoC family,
sun4i-i2s.c:
Links:
https://elixir.bootlin.com/linux/v7.0-rc5/source/sound/soc/sunxi/sun4i-i2s.c#L1296
In sun4i_i2s_runtime_resume(), the sequence is strictly enforced as:
1. Enable bus clock
2. Access and restore/sync I2S registers
3. Enable module clock
Since both IP blocks belong to the same Sunxi platform and share similar
bus/module clock relationships, shouldn't we maintain architectural
consistency across these drivers?
Enforcing the "bus clock before module clock" order keeps the dependency
ordering aligned with the actual hardware roles, where the bus clock is
required for register access while the module clock drives the functional
audio path.
Wouldn't keeping this order also make the runtime PM behavior more
consistent and easier to follow across the Sunxi audio drivers?
Best Regards,
Phuc
^ permalink raw reply
* Re: [PATCH] irqchip/gic-v4: Harden against bogus command line
From: Marc Zyngier @ 2026-05-23 9:53 UTC (permalink / raw)
To: Mostafa Saleh; +Cc: linux-arm-kernel, linux-kernel, tglx
In-Reply-To: <20260521130503.4103369-1-smostafa@google.com>
On Thu, 21 May 2026 14:05:03 +0100,
Mostafa Saleh <smostafa@google.com> wrote:
>
> When accidentally setting “kvm-arm.vgic_v4_enable=1” on the wrong
> setup that has no MSI controller device tree node (it exists but
> not used) and GICv4, it caused a panic as “gic_domain” is NULL and
> the kernel attempted to access its ops.
When you say "that has no MSI controller device tree node", does it
mean that the ITS has not been probed at all?
>
> Originally, I hit this on an older kernel, but was able to reproduce
> it on upstream with Qemu by hacking this unreasonable setup.
>
> [ 33.145536] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000028
> [ 33.145658] Mem abort info:
> [ 33.145751] ESR = 0x0000000096000006
> ...
> [ 33.154057] CPU: 1 UID: 0 PID: 295 Comm: lkvm-static Not tainted 7.1.0-rc4-ge3f15ad3970e #5 PREEMPT
> [ 33.156922] Hardware name: linux,dummy-virt (DT)
> [ 33.158780] pstate: 81402005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
> [ 33.160340] pc : __irq_domain_instantiate+0x1d4/0x578
> [ 33.162602] lr : __irq_domain_instantiate+0x1cc/0x578
>
> Add a hardening check to avoid the NULL access, and fail the VM
> creation in that case.
>
> Signed-off-by: Mostafa Saleh <smostafa@google.com>
> ---
> drivers/irqchip/irq-gic-v4.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
> index 8455b4a5fbb0..7e39f7eae85f 100644
> --- a/drivers/irqchip/irq-gic-v4.c
> +++ b/drivers/irqchip/irq-gic-v4.c
> @@ -159,6 +159,9 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
> {
> int vpe_base_irq, i;
>
> + if (!gic_domain)
> + return -EINVAL;
> +
> vm->fwnode = irq_domain_alloc_named_id_fwnode("GICv4-vpe",
> task_pid_nr(current));
> if (!vm->fwnode)
I think this check is a good few levels too late. If you want to fix
this, I'd rather make sure that kvm_vgic_global_state.has_gicv4 is
reliable and covers this case. Which means making sure that
gic_kvm_info::has_v4 is itself reliable.
If my above understanding is correct, I'd expect the following
(untested) hack to help.
Thanks,
M.
diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 291d7668cc8da..e6b9fee1b6786 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -5838,6 +5838,7 @@ int __init its_init(struct fwnode_handle *handle, struct rdists *rdists,
if (list_empty(&its_nodes)) {
pr_warn("ITS: No ITS available, not enabling LPIs\n");
+ rdists->has_vlpis = false;
return -ENXIO;
}
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply related
* [PATCH] pinctrl: imx1: fix device_node leak in dt_is_flat_functions()
From: Felix Gu @ 2026-05-23 10:27 UTC (permalink / raw)
To: Dong Aisheng, Fabio Estevam, Frank Li, Jacky Bai,
Pengutronix Kernel Team, NXP S32 Linux Team, Linus Walleij,
Sascha Hauer
Cc: linux-gpio, imx, linux-arm-kernel, linux-kernel, Felix Gu
for_each_child_of_node() holds a reference on the iterator node that
must be released on early return. imx1_pinctrl_dt_is_flat_functions()
has two early return paths inside the loop that skip this cleanup.
Replace both loops with the scoped variant so that the reference is
automatically dropped when the iterator goes out of scope.
Fixes: 63d2059cd665 ("pinctrl: imx1: Allow parsing DT without function nodes")
Signed-off-by: Felix Gu <ustc.gu@gmail.com>
---
drivers/pinctrl/freescale/pinctrl-imx1-core.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/pinctrl/freescale/pinctrl-imx1-core.c b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
index b7bd4ef9c0db..4a6bdaefa42f 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx1-core.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx1-core.c
@@ -547,14 +547,11 @@ static int imx1_pinctrl_parse_functions(struct device_node *np,
*/
static bool imx1_pinctrl_dt_is_flat_functions(struct device_node *np)
{
- struct device_node *function_np;
- struct device_node *pinctrl_np;
-
- for_each_child_of_node(np, function_np) {
+ for_each_child_of_node_scoped(np, function_np) {
if (of_property_present(function_np, "fsl,pins"))
return true;
- for_each_child_of_node(function_np, pinctrl_np) {
+ for_each_child_of_node_scoped(function_np, pinctrl_np) {
if (of_property_present(pinctrl_np, "fsl,pins"))
return false;
}
---
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
change-id: 20260523-pinctrl-imx-b198f8391abf
Best regards,
--
Felix Gu <ustc.gu@gmail.com>
^ permalink raw reply related
* [PATCH RESEND] arm64: dts: mediatek: add LED and key support on Xiaomi AX3000T
From: Aleksander Jan Bajkowski @ 2026-05-23 10:18 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, matthias.bgg, angelogioacchino.delregno,
devicetree, linux-kernel, linux-arm-kernel, linux-mediatek
Cc: Aleksander Jan Bajkowski
This patch adds support for keys and LEDs on the Xiaomi AX3000T.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
.../dts/mediatek/mt7981b-xiaomi-ax3000t.dts | 36 +++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts b/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts
index a314c3e05e50..db399cb3ead7 100644
--- a/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts
+++ b/arch/arm64/boot/dts/mediatek/mt7981b-xiaomi-ax3000t.dts
@@ -1,6 +1,9 @@
// SPDX-License-Identifier: GPL-2.0-only OR MIT
/dts-v1/;
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/leds/common.h>
#include "mt7981b.dtsi"
@@ -12,4 +15,37 @@ memory@40000000 {
reg = <0 0x40000000 0 0x10000000>;
device_type = "memory";
};
+
+ keys {
+ compatible = "gpio-keys";
+
+ key-mesh {
+ label = "MESH";
+ gpios = <&pio 0 GPIO_ACTIVE_LOW>;
+ linux,code = <BTN_9>;
+ linux,input-type = <EV_SW>;
+ };
+
+ key-reset {
+ label = "RESET";
+ gpios = <&pio 1 GPIO_ACTIVE_LOW>;
+ linux,code = <KEY_RESTART>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&pio 9 GPIO_ACTIVE_LOW>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&pio 10 GPIO_ACTIVE_LOW>;
+ };
+ };
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] KVM: arm64: Preserve all guest ZCR_EL2.LEN values
From: Marc Zyngier @ 2026-05-23 8:47 UTC (permalink / raw)
To: Mark Brown
Cc: Oliver Upton, Joey Gouly, Steffen Eiden, Suzuki K Poulose,
Catalin Marinas, Will Deacon, Mark Rutland, linux-arm-kernel,
kvmarm, linux-kernel
In-Reply-To: <20260522-kvm-arm64-fix-zcr-len-nv-v1-1-ec254e9078cf@kernel.org>
On Fri, 22 May 2026 19:00:04 +0100,
Mark Brown <broonie@kernel.org> wrote:
>
> Since b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps") when guests
> write to ZCR_EL2 we have clamped the value of ZCR_EL2.LEN to be at most
> that configuring the maximum guest VL.
That's not strictly true. This is only clamped when accessed as
ZCR_EL2. A VHE guest will happily use the ZCR_EL1 accessor for the
same register, and not see the truncation. This has ripple effects
down the line, where the full value will be used at load time.
> This is not the behaviour the
> architecture documents for ZCR_EL2.LEN, the expectation is that all bits
> will be read as written. Further, writing values larger than the largest
> available vector length is part of the documented procedure for enumerating
> the supported vector lengths so we expect to see this happen in practice.
>
> The reasoning for the current behaviour is not specifically articulated, my
> best guess is that it is intended to ensure that the guest can not see an
> effective VL greater than the maximum that has been configured. This can
> instead be achieved by configuring ZCR_EL2 when loading guest state:
>
> - When running at EL0 or EL1 configure ZCR_EL2.LEN to the minimum of the
> guest ZCR_EL2.LEN and vcpu_sve_max_vq(vcpu)-1.
This is not EL0 or EL1. This is when in a nested context (i.e. running
a L2 guest), as EL0 exists for L1 as well.
> - When running at EL2 configure the maximum VL for the guest in
> ZCR_EL2.LEN like we do for non-nested guests and load the guest
> ZCR_EL2 into ZCR_EL1.
>
> This will ensure that the guest sees both the ZCR_EL2.LEN value which it
> wrote and the effective VL that resulting from the values it has configured
> in ZCR_ELx.LEN.
>
> Currently all other bits in ZCR_EL2 are either RES0 or RAZ/WI, values
> written are sanitised based on this.
Only for the direct writes to ZCR_EL2, as they are trapping. I don't
see any sanitisation for writes using the ZCR_EL1 accessor, which is
the common case. This needs fixing at the same time.
>
> Fixes: b3d29a823099 ("KVM: arm64: nv: Handle ZCR_EL2 traps")
> Signed-off-by: Mark Brown <broonie@kernel.org>
Given the nature of the bug, this needs a Cc: stable.
> ---
> arch/arm64/kvm/hyp/include/hyp/switch.h | 8 ++++----
> arch/arm64/kvm/sys_regs.c | 6 +-----
> 2 files changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm64/kvm/hyp/include/hyp/switch.h b/arch/arm64/kvm/hyp/include/hyp/switch.h
> index bf0eb5e43427..fd277cb70967 100644
> --- a/arch/arm64/kvm/hyp/include/hyp/switch.h
> +++ b/arch/arm64/kvm/hyp/include/hyp/switch.h
> @@ -501,11 +501,11 @@ static inline void fpsimd_lazy_switch_to_guest(struct kvm_vcpu *vcpu)
> return;
>
> if (vcpu_has_sve(vcpu)) {
> + zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
> +
> /* A guest hypervisor may restrict the effective max VL. */
> - if (is_nested_ctxt(vcpu))
> - zcr_el2 = __vcpu_sys_reg(vcpu, ZCR_EL2);
> - else
> - zcr_el2 = vcpu_sve_max_vq(vcpu) - 1;
> + if (is_nested_ctxt(vcpu) && !is_hyp_ctxt(vcpu))
> + zcr_el2 = min(zcr_el2, __vcpu_sys_reg(vcpu, ZCR_EL2));
Why the change in the condition guarding this? Given the definition of
is_nested_ctxt(), this seems unnecessary.
>
> write_sysreg_el2(zcr_el2, SYS_ZCR);
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index 148fc3400ea8..c4d3bbae2d14 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2862,8 +2862,6 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
> struct sys_reg_params *p,
> const struct sys_reg_desc *r)
> {
> - unsigned int vq;
> -
> if (guest_hyp_sve_traps_enabled(vcpu)) {
> kvm_inject_nested_sve_trap(vcpu);
> return false;
> @@ -2874,9 +2872,7 @@ static bool access_zcr_el2(struct kvm_vcpu *vcpu,
> return true;
> }
>
> - vq = SYS_FIELD_GET(ZCR_ELx, LEN, p->regval) + 1;
> - vq = min(vq, vcpu_sve_max_vq(vcpu));
> - __vcpu_assign_sys_reg(vcpu, ZCR_EL2, vq - 1);
> + __vcpu_assign_sys_reg(vcpu, ZCR_EL2, p->regval & ZCR_ELx_LEN);
Once you have added the full ZCR_EL2 sanitisation, this masking can go.
> return true;
> }
Thanks,
M.
--
Jazz isn't dead. It just smells funny.
^ permalink raw reply
* Re: [PATCH 5/5] pinctrl: pinctrl-scmi: Log number of pins, groups, functions
From: Linus Walleij @ 2026-05-23 9:20 UTC (permalink / raw)
To: Alex Tran
Cc: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck,
linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon
In-Reply-To: <CAD++jL=6ikpC-BqVqP1Ev5HC37fw=K_n6rP96AxKi0jdVcyvmw@mail.gmail.com>
On Sat, May 23, 2026 at 11:18 AM Linus Walleij <linusw@kernel.org> wrote:
> On Wed, May 13, 2026 at 6:44 PM Alex Tran <alex.tran@oss.qualcomm.com> wrote:
>
> > The SCMI pinctrl driver does not currently log the number of pins,
> > groups, and functions discovered from firmware. This information is
> > useful for confirming the firmware exposed pinctrl resources during
> > debugging.
> >
> > Log these counts after a successful probe to align with the existing
> > SCMI client driver logging pattern.
> >
> > Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
>
> Other kernel maintainers want a minimalist dmesg, but not me,
> so I just applied this.
>
> If someone is upset about the noise they can send a patch
> changing it to dev_dbg().
Ah scratch that, Andy made a fair point that it is available
in debugfs anyway so I dropped the patch.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 5/5] pinctrl: pinctrl-scmi: Log number of pins, groups, functions
From: Linus Walleij @ 2026-05-23 9:18 UTC (permalink / raw)
To: Alex Tran
Cc: Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Sudeep Holla, Cristian Marussi,
Rafael J. Wysocki, Philipp Zabel, Viresh Kumar, Guenter Roeck,
linux-iio, linux-kernel, arm-scmi, linux-arm-kernel, linux-gpio,
linux-pm, linux-hwmon
In-Reply-To: <20260513-scmi-client-probe-log-v1-5-00b47b1be009@oss.qualcomm.com>
On Wed, May 13, 2026 at 6:44 PM Alex Tran <alex.tran@oss.qualcomm.com> wrote:
> The SCMI pinctrl driver does not currently log the number of pins,
> groups, and functions discovered from firmware. This information is
> useful for confirming the firmware exposed pinctrl resources during
> debugging.
>
> Log these counts after a successful probe to align with the existing
> SCMI client driver logging pattern.
>
> Signed-off-by: Alex Tran <alex.tran@oss.qualcomm.com>
Other kernel maintainers want a minimalist dmesg, but not me,
so I just applied this.
If someone is upset about the noise they can send a patch
changing it to dev_dbg().
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: gpio: add Axiado SGPIO controller
From: Linus Walleij @ 2026-05-23 9:13 UTC (permalink / raw)
To: Petar Stepanovic
Cc: Tzu-Hao Wei, Swark Yang, Prasad Bolisetty, Bartosz Golaszewski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Harshit Shah,
SriNavmani A, linux-gpio, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <c20dc0cb-252b-4637-bb22-6078be62b21d@axiado.com>
On Wed, May 13, 2026 at 10:59 AM Petar Stepanovic
<pstepanovic@axiado.com> wrote:
> Some SGPIO outputs may control host-critical signals. For example, if the
> BMC reboots while the host/server remains powered on, changing SGPIO output
> values during driver initialization could potentially reset or shut down the
> running host.
>
> The purpose of `dout-init` is to provide a deterministic safe output state
> during SGPIO initialization, before any GPIO consumer has requested the line.
>
> That said, if the preferred approach is to preserve the existing hardware
> DOUT state during probe and only change the value when a GPIO consumer
> requests the line, I can rework the driver in that direction.
That is usually the best. The gpio framework scans the direction
of each line at probe(). While it does not know about the initial *value*
of each line, consumers can take this into account
when requesting a GPIO line like this:
gpio_vbus = devm_gpiod_get(dev, "vbus", GPIOD_ASIS);
This means the kernel does not put any initial value on the line.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v6 0/7] pinctrl: Add generic pinctrl for board-level mux chips
From: Linus Walleij @ 2026-05-23 9:02 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafał Miłecki, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, linux-kernel, linux-gpio, devicetree, imx,
linux-arm-kernel, Haibo Chen, Conor Dooley, Ahmad Fatoum
In-Reply-To: <agNFaXbd_sMq5eAo@lizhi-Precision-Tower-5810>
On Tue, May 12, 2026 at 5:21 PM Frank Li <Frank.li@nxp.com> wrote:
> On Mon, May 11, 2026 at 10:34:35PM +0200, Linus Walleij wrote:
> > On Mon, May 11, 2026 at 9:38 PM Frank Li <Frank.li@nxp.com> wrote:
> >
> > > I fixed a build warning by missing doc 'np',
> > > https://lore.kernel.org/imx/20260507152117.240612-1-Frank.Li@nxp.com/
> > >
> > > Anything need me to do futher?
> >
> > Sorry was busy!
> >
> > Applied this fixup on top of the branch and merged it into my
> > devel branch for v7.2!
>
> Sorry, I missed picked up fix patch during rebase.
>
> https://lore.kernel.org/imx/20260512144806.22447-1-Frank.Li@nxp.com/T/#u
Ooops I should have seen it.
Applied it now!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 3/3] gpio: zynq: Add eio gpio support
From: Linus Walleij @ 2026-05-23 8:59 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-kernel, git, shubhrajyoti.datta, Srinivas Neeli,
Michal Simek, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260512060917.2096456-4-shubhrajyoti.datta@amd.com>
On Tue, May 12, 2026 at 8:09 AM Shubhrajyoti Datta
<shubhrajyoti.datta@amd.com> wrote:
> Add support for the EIO GPIO controller found on
> xa2ve3288 silicon.
>
> The EIO GPIO block provides access to multiplexed I/O pins exposed
> through the EIO interface. Only bank 0 and bank 1 are connected to
> external MIO pins, with 26 GPIOs per bank (52 GPIOs total). This
> change extends the Zynq GPIO driver to support the EIO GPIO
> variant.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 0/6] mm/vmalloc: Speed up ioremap, vmalloc and vmap with contiguous memory
From: Wen Jiang @ 2026-05-23 8:26 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, urezki, baohua,
Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6
In-Reply-To: <20260522110727.fc7dccf90bc8513abd1fdbf1@linux-foundation.org>
On Sat, 23 May 2026 at 02:07, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> On Fri, 22 May 2026 13:31:40 +0800 Wen Jiang <jiangwenxiaomi@gmail.com> wrote:
>
> > This patchset accelerates ioremap, vmalloc, and vmap when the memory
> > is physically fully or partially contiguous.
>
> Thanks. AI review asked a few things and might have found an existing
> 32-bit bug in vmap():
>
> https://sashiko.dev/#/patchset/20260522053146.83209-1-jiangwenxiaomi@gmail.com
Hi Andrew,
I've gone through the Sashiko findings:
- Patch 5 (arch_vmap_pte_supported_shift on x86): Over-interpretation.
This targets ARM64 CONT_PTE. x86 falls through with PAGE_SHIFT
same as before.
- Patch 5 (1 << order overflow at order=31): Over-interpretation.
Reaching order=31 requires 8TB contiguous in a single vmap()
not a realistic usage pattern.
- Patch 6 (GFP_KERNEL triggering purge): The purge only triggers
when vmalloc space is already under pressure, and benefits the
subsequent PAGE_SIZE fallback as well, not wasted work.
- Patch 6 (32-bit count << PAGE_SHIFT overflow): Pre-existing.
Will send a separate fix.
- Patch 6 (unconditional alignment without checking contiguity):
The main vmap() users typically pass contiguous pages
(e.g. system_heap order 8 -> 4 -> 0).
Thanks,
Wen
^ permalink raw reply
* Re: [GIT PULL] KVM/arm64 fixes for 7.1, take #3
From: Paolo Bonzini @ 2026-05-23 8:03 UTC (permalink / raw)
To: Marc Zyngier
Cc: Michael Bommarito, Vincent Donnefort, Will Deacon, Yuan Yao,
Steffen Eiden, Joey Gouly, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, kvmarm, linux-arm-kernel, kvm
In-Reply-To: <20260520072518.504865-1-maz@kernel.org>
On Wed, May 20, 2026 at 9:25 AM Marc Zyngier <maz@kernel.org> wrote:
>
> Paolo,
>
> Here's the next set of KVM/arm64 fixes for 7.1. Continuing the trend,
> we have two AI-fuelled fixes, both of which are stable candidates.
> Additionally, a minor tidying-up of the hypervisor tracing descriptor
> validation.
>
> Please pull,
>
> M.
>
> The following changes since commit effc0a39b8e0f30670fe24f51e44329d4324e566:
>
> KVM: arm64: Pre-check vcpu memcache for host->guest donate (2026-05-07 14:12:42 +0100)
>
> are available in the Git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm.git tags/kvmarm-fixes-7.1-3
>
> for you to fetch changes up to 1702da76e017ae0fbe1a92b07bc332972c293e89:
>
> KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc (2026-05-20 08:08:37 +0100)
Done, thanks.
Paolo
> ----------------------------------------------------------------
> KVM/arm64 fixes for 7.1, take #3
>
> - Fix ITS EventID sanitisation when restoring an interrupt translation
> table.
>
> - Fix PPI memory leak when failing to initialise a vcpu.
>
> - Correctly return an error when the validation of a hypervisor trace
> descriptor fails, and limit this validation to protected mode only.
>
> ----------------------------------------------------------------
> Michael Bommarito (2):
> KVM: arm64: vgic-its: Reject restored DTE with out-of-range num_eventid_bits
> KVM: arm64: vgic: Free private_irqs when init fails after allocation
>
> Vincent Donnefort (1):
> KVM: arm64: Fix nVHE/pKVM hyp tracing error on invalid desc
>
> arch/arm64/kvm/arm.c | 4 +++-
> arch/arm64/kvm/hyp/nvhe/trace.c | 9 +++++++--
> arch/arm64/kvm/vgic/vgic-its.c | 4 ++++
> 3 files changed, 14 insertions(+), 3 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v3 6/6] mm/vmalloc: align vm_area so vmap() can batch mappings
From: Uladzislau Rezki @ 2026-05-23 7:53 UTC (permalink / raw)
To: Wen Jiang
Cc: linux-mm, linux-arm-kernel, catalin.marinas, will, akpm, urezki,
baohua, Xueyuan.chen21, dev.jain, rppt, david, ryan.roberts,
anshuman.khandual, ajd, linux-kernel, jiangwen6
In-Reply-To: <20260522053146.83209-7-jiangwenxiaomi@gmail.com>
On Fri, May 22, 2026 at 01:31:46PM +0800, Wen Jiang wrote:
> From: "Barry Song (Xiaomi)" <baohua@kernel.org>
>
> Try to align the vmap virtual address to PMD_SHIFT or a
> larger PTE mapping size hinted by the architecture, so
> contiguous pages can be batch-mapped when setting PMD or
> PTE entries.
>
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> Signed-off-by: Wen Jiang <jiangwen6@xiaomi.com>
> Tested-by: Xueyuan Chen <xueyuan.chen21@gmail.com>
> ---
> mm/vmalloc.c | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vmalloc.c b/mm/vmalloc.c
> index 50642246f4d40..040d400928aab 100644
> --- a/mm/vmalloc.c
> +++ b/mm/vmalloc.c
> @@ -3620,6 +3620,37 @@ static int vmap_batched(unsigned long addr, unsigned long end,
> return err;
> }
>
> +static struct vm_struct *get_aligned_vm_area(unsigned long size,
> + unsigned long flags, const void *caller)
> +{
> + struct vm_struct *vm_area;
> + unsigned int shift;
> +
> + /* Try PMD alignment for large sizes */
> + if (size >= PMD_SIZE) {
> + vm_area = __get_vm_area_node(size, PMD_SIZE, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> + if (vm_area)
> + return vm_area;
> + }
> +
> + /* Try CONT_PTE alignment */
> + shift = arch_vmap_pte_supported_shift(size);
> + if (shift > PAGE_SHIFT) {
> + vm_area = __get_vm_area_node(size, 1UL << shift, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> + if (vm_area)
> + return vm_area;
> + }
> +
> + /* Fall back to page alignment */
> + return __get_vm_area_node(size, PAGE_SIZE, PAGE_SHIFT, flags,
> + VMALLOC_START, VMALLOC_END,
> + NUMA_NO_NODE, GFP_KERNEL, caller);
> +}
> +
> /**
> * vmap - map an array of pages into virtually contiguous space
> * @pages: array of page pointers
> @@ -3658,7 +3689,7 @@ void *vmap(struct page **pages, unsigned int count,
> return NULL;
>
> size = (unsigned long)count << PAGE_SHIFT;
> - area = get_vm_area_caller(size, flags, __builtin_return_address(0));
> + area = get_aligned_vm_area(size, flags, __builtin_return_address(0));
> if (!area)
> return NULL;
>
> --
> 2.34.1
>
This one LGTM:
Reviewed-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
--
Uladzislau Rezki
^ permalink raw reply
* Re: [PATCH 2/4] firmware: arm_ffa: Register core as a platform driver
From: Yeoreum Yun @ 2026-05-23 6:27 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Sudeep Holla, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm
In-Reply-To: <20260523050555.GA1121518@ax162>
On Fri, May 22, 2026 at 10:05:55PM -0700, Nathan Chancellor wrote:
> On Sat, May 23, 2026 at 05:50:14AM +0100, Yeoreum Yun wrote:
> > Hi Nathan,
> >
> > > Hi Sudeep,
> > >
> > > On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote:
> > > > Move the FF-A core bring-up and teardown paths into platform driver
> > > > probe and remove callbacks, and register a synthetic arm-ffa platform
> > > > device to bind the driver.
> > > >
> > > > This makes the FF-A core lifetime follow the driver model while keeping
> > > > the device creation internal to the FF-A core. Use normal platform driver
> > > > registration so the probe path has standard driver-core semantics.
> > > >
> > > > The synthetic platform device is a temporary bridge until ACPI and
> > > > devicetree describe the FF-A core device or object. Once those firmware
> > > > description paths are defined, the internal platform device creation can
> > > > be dropped and the driver can bind to the firmware-described device
> > > > directly.
> > > >
> > > > Since the transport selection now happens from the platform probe path,
> > > > drop the __init annotation from ffa_transport_init().
> > > >
> > > > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
> > >
> > > I am seeing
> > >
> > > arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
> > >
> > > on my two arm64 test machines after this change landed in -next as
> > > commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform
> > > driver"), is this expected? If so, perhaps it should be silenced?
> >
> > Could you share the .config file you used for this?
>
> Sure thing! It is attached. If you need anything else, please let me
> know.
Thanks! unless there was other error log from ff-a driver,
I think this happens because your environment either doesn’t
support FF-A or is using an SMCCC version earlier than 1.2 from
ffa_version_check() or ffa_transport_init().
If that’s the case, You can ignore this log since this behavior is
expected, and the dd core should print an error log.
Before this patch, the error was not shown because all FF-A initialization
was done during the initcall phase, and nothing was printed
even when the initcall function returned an error from caller of initcall.
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* [PATCH v2 2/2] usb: dwc3: xilinx: use reset_control_reset() in versal init
From: Radhey Shyam Pandey @ 2026-05-23 7:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <cover.1779518171.git.radhey.shyam.pandey@amd.com>
Replace reset_control_assert()/deassert() with reset_control_reset().
For dwc3-xilinx, reset_control_reset() routes via the zynqmp reset
driver and uses PM_RESET_ACTION_PULSE, which performs assert and
deassert in firmware. This results in a single SMC call issuing a
reset pulse and taking the IP out of reset.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- As suggested by Thinh rephrased commit description to explain
firmware driven reset sequence.
---
drivers/usb/dwc3/dwc3-xilinx.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index 02dc35e110b9..b832505e1b04 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -98,18 +98,10 @@ static int dwc3_xlnx_init_versal(struct dwc3_xlnx *priv_data)
dwc3_xlnx_mask_phy_rst(priv_data, false);
- /* Assert and De-assert reset */
- ret = reset_control_assert(crst);
- if (ret < 0) {
- dev_err_probe(dev, ret, "failed to assert Reset\n");
- return ret;
- }
-
- ret = reset_control_deassert(crst);
- if (ret < 0) {
- dev_err_probe(dev, ret, "failed to De-assert Reset\n");
- return ret;
- }
+ /* assert and deassert reset */
+ ret = reset_control_reset(crst);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to assert and deassert reset\n");
dwc3_xlnx_mask_phy_rst(priv_data, true);
dwc3_xlnx_set_coherency(priv_data, XLNX_USB2_TRAFFIC_ROUTE_CONFIG);
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] minor cleanup for dwc3-xilinx glue driver
From: Radhey Shyam Pandey @ 2026-05-23 7:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
Minor cleanups for the dwc3-xilinx glue driver:
- Fix a comment style violation (missing space before closing delimiter).
- Use reset_control_reset in versal init.
Changes for v2:
- Rephrased commit description for 2/2 patch.
- Drop functional fix (usb: dwc3: xilinx: fix error handling in zynqmp
init error paths) from this series.
Radhey Shyam Pandey (2):
usb: dwc3: xilinx: fix missing space before closing comment delimiter
usb: dwc3: xilinx: use reset_control_reset() in versal init
drivers/usb/dwc3/dwc3-xilinx.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] usb: dwc3: xilinx: fix missing space before closing comment delimiter
From: Radhey Shyam Pandey @ 2026-05-23 7:08 UTC (permalink / raw)
To: Thinh.Nguyen, gregkh, michal.simek, p.zabel
Cc: linux-usb, linux-arm-kernel, linux-kernel, git,
Radhey Shyam Pandey
In-Reply-To: <cover.1779518171.git.radhey.shyam.pandey@amd.com>
Add missing space before '*/' in an inline comment to follow
the kernel coding style.
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Changes for v2:
- Add Thinh Nguyen acked by tag.
---
drivers/usb/dwc3/dwc3-xilinx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-xilinx.c b/drivers/usb/dwc3/dwc3-xilinx.c
index 9b9525592a85..02dc35e110b9 100644
--- a/drivers/usb/dwc3/dwc3-xilinx.c
+++ b/drivers/usb/dwc3/dwc3-xilinx.c
@@ -194,7 +194,7 @@ static int dwc3_xlnx_init_zynqmp(struct dwc3_xlnx *priv_data)
}
if (priv_data->usb3_phy) {
- /* Set PIPE Power Present signal in FPD Power Present Register*/
+ /* Set PIPE Power Present signal in FPD Power Present Register */
writel(FPD_POWER_PRSNT_OPTION, priv_data->regs + XLNX_USB_FPD_POWER_PRSNT);
/* Set the PIPE Clock Select bit in FPD PIPE Clock register */
writel(PIPE_CLK_SELECT, priv_data->regs + XLNX_USB_FPD_PIPE_CLK);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 2/4] firmware: arm_ffa: Register core as a platform driver
From: Yeoreum Yun @ 2026-05-23 4:50 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Sudeep Holla, yeoreum.yun, linux-security-module, linux-kernel,
linux-integrity, linux-arm-kernel, kvmarm
In-Reply-To: <20260523001148.GA1319283@ax162>
Hi Nathan,
> Hi Sudeep,
>
> On Fri, May 08, 2026 at 06:54:16PM +0100, Sudeep Holla wrote:
> > Move the FF-A core bring-up and teardown paths into platform driver
> > probe and remove callbacks, and register a synthetic arm-ffa platform
> > device to bind the driver.
> >
> > This makes the FF-A core lifetime follow the driver model while keeping
> > the device creation internal to the FF-A core. Use normal platform driver
> > registration so the probe path has standard driver-core semantics.
> >
> > The synthetic platform device is a temporary bridge until ACPI and
> > devicetree describe the FF-A core device or object. Once those firmware
> > description paths are defined, the internal platform device creation can
> > be dropped and the driver can bind to the firmware-described device
> > directly.
> >
> > Since the transport selection now happens from the platform probe path,
> > drop the __init annotation from ffa_transport_init().
> >
> > Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org>
>
> I am seeing
>
> arm-ffa arm-ffa: probe with driver arm-ffa failed with error -95
>
> on my two arm64 test machines after this change landed in -next as
> commit e659fc8e537c ("firmware: arm_ffa: Register core as a platform
> driver"), is this expected? If so, perhaps it should be silenced?
>
> Cheers,
> Nathan
>
Could you share the .config file you used for this?
Thanks!
[...]
--
Sincerely,
Yeoreum Yun
^ permalink raw reply
* Re: [PATCH 16/16] media: sun6i-isp: Add support for frame size enumeration
From: arash golgol @ 2026-05-23 4:34 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-staging, Mauro Carvalho Chehab, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Greg Kroah-Hartman,
Laurent Pinchart, Nicolas Dufresne
In-Reply-To: <20260518102451.417971-17-paulk@sys-base.io>
Hi Paul,
On Mon, May 18, 2026 at 2:02 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> This implements the enum_framesizes operation, which reports support for
> even sizes.
>
> Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
> ---
> .../media/sunxi/sun6i-isp/sun6i_isp_capture.c | 22 +++++++++++++++++++
> 1 file changed, 22 insertions(+)
>
> diff --git a/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c b/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> index 372b9331bd6d..e638ec32c7cd 100644
> --- a/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> +++ b/drivers/staging/media/sunxi/sun6i-isp/sun6i_isp_capture.c
> @@ -452,6 +452,26 @@ static int sun6i_isp_capture_enum_fmt(struct file *file, void *priv,
> return 0;
> }
>
> +static int sun6i_isp_capture_enum_framesizes(struct file *file, void *fh,
> + struct v4l2_frmsizeenum *frmsize)
> +{
> + if (frmsize->index)
> + return -EINVAL;
> +
> + if (!sun6i_isp_capture_format_find(frmsize->pixel_format))
> + return -EINVAL;
> +
> + frmsize->type = V4L2_FRMSIZE_TYPE_STEPWISE;
> + frmsize->stepwise.min_width = SUN6I_ISP_CAPTURE_WIDTH_MIN;
> + frmsize->stepwise.max_width = SUN6I_ISP_CAPTURE_WIDTH_MAX;
> + frmsize->stepwise.min_height = SUN6I_ISP_CAPTURE_HEIGHT_MIN;
> + frmsize->stepwise.max_height = SUN6I_ISP_CAPTURE_HEIGHT_MAX;
> + frmsize->stepwise.step_width = 2;
> + frmsize->stepwise.step_height = 2;
> +
> + return 0;
> +}
> +
> static int sun6i_isp_capture_g_fmt(struct file *file, void *priv,
> struct v4l2_format *format)
> {
> @@ -522,6 +542,8 @@ static const struct v4l2_ioctl_ops sun6i_isp_capture_ioctl_ops = {
> .vidioc_s_fmt_vid_cap = sun6i_isp_capture_s_fmt,
> .vidioc_try_fmt_vid_cap = sun6i_isp_capture_try_fmt,
>
> + .vidioc_enum_framesizes = sun6i_isp_capture_enum_framesizes,
> +
> .vidioc_enum_input = sun6i_isp_capture_enum_input,
> .vidioc_g_input = sun6i_isp_capture_g_input,
> .vidioc_s_input = sun6i_isp_capture_s_input,
> --
> 2.54.0
>
Tested on a LicheePi Zero Dock (V3s) with the ov5647 camera setup.
The enum_framesizes implementation behaves as expected and reports the
supported even frame sizes correctly.
Tested-by: Arash Golgol <arash.golgol@gmail.com>
Reviewed-by: Arash Golgol <arash.golgol@gmail.com>
--
Regards,
Arash Golgol
^ permalink raw reply
* Re: [PATCH v5 2/4] kernel: param: initialize module_kset in a pure_initcall
From: Shashank Balaji @ 2026-05-23 3:24 UTC (permalink / raw)
To: Petr Pavlu
Cc: Suzuki K Poulose, James Clark, Alexander Shishkin,
Greg Kroah-Hartman, Rafael J. Wysocki, Danilo Krummrich,
Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Jonathan Corbet, Shuah Khan, Luis Chamberlain, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Mike Leach, Leo Yan, Thierry Reding,
Jonathan Hunter, Rahul Bukte, linux-kernel, coresight,
linux-arm-kernel, driver-core, rust-for-linux, linux-doc,
Daniel Palmer, Tim Bird, linux-modules, linux-tegra, Sumit Gupta
In-Reply-To: <a0b17be8-f7dd-4d05-bc6f-28b32d0b0785@suse.com>
Hi Petr,
Thanks for the feedback!
On Fri, May 22, 2026 at 03:06:04PM +0200, Petr Pavlu wrote:
> On 5/18/26 12:19 PM, Shashank Balaji wrote:
> > Commit "driver core: platform: set mod_name in driver registration" will set
> > struct device_driver's mod_name member for platform driver registration. For a
> > driver to be registered with its mod_name set, module_kset needs to be
> > initialized, which currently happens in a subsys_initcall in param_sysfs_init().
> > The tegra cbb drivers register themselves before module_kset init, in a
> > core_initcall. This works currently because lookup_or_create_module_kobject(),
> > which dereferences module_kset via kset_find_obj(), is not called if mod_name
> > is not set, which is the case now.
> >
> > So in preparation for the commit "driver core: platform: set mod_name in driver registration",
> > move module_kset init to pure_initcall level, ensuring it happens before tegra
> > cbb driver registration.
> >
> > Suggested-by: Gary Guo <gary@garyguo.net>
> > Co-developed-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Rahul Bukte <rahul.bukte@sony.com>
> > Signed-off-by: Shashank Balaji <shashank.mahadasyam@sony.com>
> > ---
> > Patch 4 depends on this patch
> > ---
> > kernel/params.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/kernel/params.c b/kernel/params.c
> > index 74d620bc2521..ac088d4b09a9 100644
> > --- a/kernel/params.c
> > +++ b/kernel/params.c
> > @@ -957,7 +957,7 @@ static int __init param_sysfs_init(void)
> >
> > return 0;
> > }
> > -subsys_initcall(param_sysfs_init);
> > +pure_initcall(param_sysfs_init);
> >
> > /*
> > * param_sysfs_builtin_init - add sysfs version and parameter
> >
>
> The change looks ok to me functionality-wise. Sysfs is initialized
> earlier in do_basic_setup() and other code, such as classes_init(),
> calls kset_create_and_add() similarly early.
>
> One minor issue is that pure_initcall() was originally intended for
> static variable initialization. The file include/linux/init.h says:
>
> | /*
> | * A "pure" initcall has no dependencies on anything else, and purely
> | * initializes variables that couldn't be statically initialized.
> | *
> | * This only exists for built-in code, not for modules.
> | * Keep main.c:initcall_level_names[] in sync.
> | */
> | #define pure_initcall(fn) __define_initcall(fn, 0)
>
> The patch stretches the intended use of pure_initcall() somewhat in this
> regard. However, other code already appears to do the same, so I guess
> this is ok.
Ah yeah, I thought of this too, but it seems like everyone else is doing
it. Linus introduced pure_initcall in b3438f8266cb
("Add "pure_initcall" for static variable initialization") with the
comment, and he introduced another user of it in 140d0b2108fa
("Do 'shm_init_ns()' in an early pure_initcall") which already stretches
the intended use as per the comment.
Given that it's just being used for "run me before core_initcall;
early_initcall is too early for me" without any "pureness" requirements, I
suppose the comment is due for a revision?
> Additionally, I think it would be good to update the comment preceding
> param_sysfs_init(). It currently says:
>
> | /*
> | * param_sysfs_init - create "module" kset
> | *
> | * This must be done before the initramfs is unpacked and
> | * request_module() thus becomes possible, because otherwise the
> | * module load would fail in mod_sysfs_init.
> | */
>
> I suggest changing it to something like follows:
>
> This must be done before any driver registration so that when a driver comes
> from a built-in module, the driver core can add the module under /sys/module
> and create the associated driver symlinks.
Thanks for catching this! I'll add it in the next revision.
Thanks,
Shashank
^ permalink raw reply
* Re: [PATCH 14/16] media: sun6i-isp: Use V4L2 subdev active state
From: arash golgol @ 2026-05-23 3:15 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-media, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-staging, Mauro Carvalho Chehab, Chen-Yu Tsai,
Jernej Skrabec, Samuel Holland, Greg Kroah-Hartman,
Laurent Pinchart, Nicolas Dufresne
In-Reply-To: <ahA61YIGM4Bqipu7@collins>
Hi Paul,
On Fri, May 22, 2026 at 2:45 PM Paul Kocialkowski <paulk@sys-base.io> wrote:
>
> Hi Arash,
>
> Le Thu 21 May 26, 12:53, arash golgol a écrit :
> > I used LicheePi Zero Dock (V3s) with the following pipeline as test setup.
> >
> > ov5647 -> sun6i-mipi-csi2 -> sun6i-csi-bridge -> sun6i-isp-proc ->
> > sun6i-isp-capture
> >
> > I verified TRY and ACTIVE state handling, including changing TRY
> > formats without affecting ACTIVE state. Format propagation from the
> > sink (csi) pad to the source pad was also tested.
> >
> > I also tested streaming with the sensor test pattern enabled and
> > verified the captured output was correct.
> >
> > Tested-by: Arash Golgol <arash.golgol@gmail.com>
>
> Thanks a lot for testing this! Did you test just this patch or the other
> ones (especially sun6i-csi format enumeration) as well?
>
Happy to help.
I only tested patch 14 for now, but I plan to test the other patches
as well when I get some more time, especially the sun6i-csi changes.
> Also if you have an opinion on the code itself feel free to drop a
> Reviewed-by tag, a lot of this work is very similar to what you did for
> sun6i-csi and other drivers.
>
From a code perspective, the changes look good to me.
Reviewed-by: Arash Golgol <arash.golgol@gmail.com>
--
Regards,
Arash Golgol
^ permalink raw reply
* [PATCH 2/2] ARM: dts: aspeed: sanmiguel: Fix the CPU_CHIPTHROT linename
From: Potin Lai @ 2026-05-23 2:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Mike Hsieh, Potin Lai, Potin Lai
In-Reply-To: <20260523-potin-update-sanmiguel-dts-20260522-v1-0-169f5fceb5f9@quantatw.com>
Fix the GPIO linenames for CPU_CHIPTHROT signals.
The signals were incorrectly marked as output ("-O") while they are
actually input signals ("-I").
- B0_M0_CPU_CHIPTHROT_L-O -> B0_M0_CPU_CHIPTHROT_L-I
- B1_M0_CPU_CHIPTHROT_L-O -> B1_M0_CPU_CHIPTHROT_L-I
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
index 61dbef45f8b0..d7ed497d7227 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
@@ -224,7 +224,7 @@ hpm0_ioexp_20: gpio@20 {
"B0_M0_LEAK_DETECT_ALERT_L-I",
"B0_M0_RUN_POWER_EN-O",
"B0_M0_RUN_POWER_PG-I",
- "B0_M0_CPU_CHIPTHROT_L-O",
+ "B0_M0_CPU_CHIPTHROT_L-I",
"B0_M0_SHDN_REQ_L-O",
"B0_M0_CPU_SHDN_OK_L-I",
"B0_M0_CPLD_READY-I",
@@ -398,7 +398,7 @@ hpm1_ioexp_20: gpio@20 {
"B1_M0_LEAK_DETECT_ALERT_L-I",
"B1_M0_RUN_POWER_EN-O",
"B1_M0_RUN_POWER_PG-I",
- "B1_M0_CPU_CHIPTHROT_L-O",
+ "B1_M0_CPU_CHIPTHROT_L-I",
"B1_M0_SHDN_REQ_L-O",
"B1_M0_CPU_SHDN_OK_L-I",
"B1_M0_CPLD_READY-I",
--
2.52.0
^ permalink raw reply related
* [PATCH 1/2] ARM: dts: aspeed: sanmiguel: Add IOEXP interrupt pin settings
From: Potin Lai @ 2026-05-23 2:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Mike Hsieh, Potin Lai, Potin Lai
In-Reply-To: <20260523-potin-update-sanmiguel-dts-20260522-v1-0-169f5fceb5f9@quantatw.com>
Kernel dmesg reports IRQ #44 being disabled due to unhandled
interrupts from multiple PCA953x IO expanders:
```
[ 447.047861] irq 44: nobody cared (try booting with the "irqpoll" option)
[ 447.063124] handlers:
[ 447.068176] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.087268] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.106344] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.125421] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.144513] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.163587] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.182663] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.201756] [<2ab869ad>] irq_default_primary_handler threaded [<b8adc310>] pca953x_irq_handler
[ 447.220837] Disabling IRQ #44
```
The affected IOEXP nodes are missing interrupt pin configuration in
the device tree, causing the interrupt line to remain asserted and
resulting in repeated unhandled IRQ events.
Add the required interrupt-related properties for the affected IOEXP
devices to ensure proper interrupt handling and prevent the IRQ from
being disabled.
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
---
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
index 74c8c1772109..61dbef45f8b0 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts
@@ -334,6 +334,8 @@ hmc_ioexp: gpio@20 {
reg = <0x20>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <ASPEED_GPIO(B, 6) IRQ_TYPE_LEVEL_LOW>;
gpio-line-names =
"", "", "HMC_EROT_FATAL_ERROR_L-I", "",
@@ -552,6 +554,8 @@ smm_ext_ioexp: gpio@38 {
reg = <0x38>;
gpio-controller;
#gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <ASPEED_GPIO(B, 6) IRQ_TYPE_LEVEL_LOW>;
gpio-line-names =
"SSD0_PRSNT_L-I", "E1S_PWR_EN-O",
--
2.52.0
^ permalink raw reply related
* [PATCH 0/2] ARM: dts: aspeed: sanmiguel: Update DTS file
From: Potin Lai @ 2026-05-23 2:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, Patrick Williams
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Cosmo Chou, Mike Hsieh, Potin Lai, Potin Lai
Update the SanMiguel DTS configuration to fix incorrect GPIO
linenames and resolve the IOEXP interrupt handling issue.
Signed-off-by: Potin Lai <potin.lai@quantatw.com>
---
Potin Lai (2):
ARM: dts: aspeed: sanmiguel: Add IOEXP interrupt pin settings
ARM: dts: aspeed: sanmiguel: Fix the CPU_CHIPTHROT linename
arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-sanmiguel.dts | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
---
base-commit: 6e22b9e818d68d7b8ce6680aede0c80a9355929a
change-id: 20260522-potin-update-sanmiguel-dts-20260522-7b3d280e63f8
Best regards,
--
Potin Lai <potin.lai@quantatw.com>
^ permalink raw reply
* Re: [PATCH net-next v5 12/13] misc: lan966x-pci: dts: extend cpu reg to cover PCIE DBI space
From: Jakub Kicinski @ 2026-05-23 2:01 UTC (permalink / raw)
To: Daniel Machon
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Horatiu Vultur, Steen Hegelund, UNGLinuxDriver,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Stanislav Fomichev, Herve Codina, Arnd Bergmann,
Greg Kroah-Hartman, Mohsin Bashir, netdev, linux-kernel, bpf,
linux-arm-kernel
In-Reply-To: <20260520-lan966x-pci-fdma-v5-12-ca56197ae05b@microchip.com>
On Wed, 20 May 2026 10:12:24 +0200 Daniel Machon wrote:
> The ATU outbound windows used by the FDMA engine are programmed through
> registers at offset 0x400000+, which falls outside the current cpu reg
> mapping. Extend the cpu reg size from 0x100000 (1MB) to 0x800000 (8MB)
> to cover the full PCIE DBI and iATU register space.
Are we supposed to take these to net-next ?
^ 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