* Re: [PATCH v2 15/20] drm/drv: Call drm_mode_config_create_state() by default
From: Dmitry Baryshkov @ 2026-04-21 15:57 UTC (permalink / raw)
To: Thomas Zimmermann
Cc: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <dd39f423-1598-4749-8c95-98b8daf69680@suse.de>
On Tue, Apr 21, 2026 at 05:33:12PM +0200, Thomas Zimmermann wrote:
>
>
> Am 21.04.26 um 15:38 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.03.26 um 17:27 schrieb Maxime Ripard:
> > > Almost all drivers, and our documented skeleton, call
> > > drm_mode_config_reset() prior to calling drm_dev_register() to
> > > initialize its DRM object states.
> > >
> > > Now that we have drm_mode_config_create_state() to create that initial
> > > state if it doesn't exist, we can call it directly in
> > > drm_dev_register(). That way, we know that the initial atomic state will
> > > always be allocated without any boilerplate.
> > >
> > > Signed-off-by: Maxime Ripard <mripard@kernel.org>
> > > ---
> > > drivers/gpu/drm/drm_drv.c | 4 ++++
> > > 1 file changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > > index 2915118436ce8a6640cfb0c59936031990727ed1..820106d56ab399a39cac56d98662b5ddbcae8ded
> > > 100644
> > > --- a/drivers/gpu/drm/drm_drv.c
> > > +++ b/drivers/gpu/drm/drm_drv.c
> > > @@ -1097,10 +1097,14 @@ int drm_dev_register(struct drm_device *dev,
> > > unsigned long flags)
> > > if (drm_core_check_feature(dev, DRIVER_MODESET)) {
> > > ret = drm_modeset_register_all(dev);
> > > if (ret)
> > > goto err_unload;
> > > +
> > > + ret = drm_mode_config_create_state(dev);
> > > + if (ret)
> > > + goto err_unload;
> >
> > Way too late. Lets rather go through drivers and call this where they
> > currently call drm_mode_config_reset() for initialization. This can be a
> > single-patch mass conversion IMHO.
>
> On a second thought, can't we modify the suspend code and leave the reset
> as-is for now? I'd still be interested to use reset as a means of
> initializing the hardware or loading state on probe. So keeping the _reset()
> calls in place might be helpful for that.
But isn't it the expected behaviour? The driver can reset(), but if
it didn't, the default would be to create empty working state. In the
end, the drivers also can call this function to create the state, don't
they (and then perform the readout logic)?
>
> What's the long-term plan here?
>
> Best regards
> Thomas
>
> >
> > Best regards
> > Thomas
> >
> > > }
> > > drm_panic_register(dev);
> > > drm_client_sysrq_register(dev);
> > > DRM_INFO("Initialized %s %d.%d.%d for %s on minor %d\n",
> > >
> >
>
> --
> --
> Thomas Zimmermann
> Graphics Driver Developer
> SUSE Software Solutions Germany GmbH
> Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
> GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
>
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v5 0/6] Add Rockchip RK3576 PWM Support Through MFPWM
From: Jonathan Cameron @ 2026-04-21 15:56 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, Lee Jones, William Breathitt Gray,
Damon Ding, kernel, Jonas Karlman, Alexey Charkov, linux-rockchip,
linux-pwm, devicetree, linux-arm-kernel, linux-kernel, linux-iio,
Conor Dooley
In-Reply-To: <20260420-rk3576-pwm-v5-0-ae7cfbbe5427@collabora.com>
On Mon, 20 Apr 2026 15:52:37 +0200
Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
> This series introduces support for some of the functions of the new PWM
> silicon found on Rockchip's RK3576 SoC. Due to the wide range of
> functionalities offered by it, including many parts which this series'
> first iteration does not attempt to implement for now. The drivers are
> modelled as an MFD, with no leakage of the MFD-ness into the binding, as
> it's a Linux implementation detail.
Just thought I'd point out that as this includes the linux-iio
list sashiko took a look at it. Quite a few things and at least
the first one I looked at was valid (a dereference before a validity
check)
https://sashiko.dev/#/patchset/20260420-rk3576-pwm-v5-0-ae7cfbbe5427%40collabora.com
Whilst this tool does generate some false positives, it also finds
quite a few things it seems us humans fail to spot.
Jonathan
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
From: Robin Murphy @ 2026-04-21 15:56 UTC (permalink / raw)
To: leo.jiang1224, will; +Cc: joro, iommu, linux-arm-kernel
In-Reply-To: <tencent_F6E384A40D990A279B460A0CDE1927FDF509@qq.com>
On 18/04/2026 6:31 am, leo.jiang1224@foxmail.com wrote:
> From: LoserJL <leo.jiang1224@foxmail.com>
>
> In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> allocates at least PAGE_SIZE, retrying with a smaller size after
> a PAGE_SIZE failure is logically redundant.
Says who? It's certainly not a guarantee offered by the DMA API itself,
and indeed some allocation paths can definitely still allocate less than
a page - e.g. anything which hits a per-device or global coherent pool.
> Moreover, if a sub-page retry were to succeed due to concurrent memory
> release, the hardware would be configured with a smaller queue depth
> despite a full page being allocated. This leads to inefficient memory
> usage and unnecessary hardware performance limitation.
>
> Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> consistency and optimal hardware configuration.
That's really not an argument - even if an allocator does happen to
over-allocate for the requested size, that is hardly the caller's
concern; and as far as "optimal" queue sizes go in this case, those very
much depend on the number of CPUs issuing commands and volume of
expected stall/PRI events - in many cases PAGE_SIZE would already be far
too small to really work well.
Also note that if we _were_ to fail to allocate a PAGE_SIZE or smaller
queue, there would be very little chance of the subsequent allocation(s)
for the stream table succeeding, so realistically the driver is probably
going to end up failing to probe in such circumstances anyway.
Thanks,
Robin.
> Signed-off-by: LoserJL <leo.jiang1224@foxmail.com>
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f0..e0ec118ff560 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -4418,7 +4418,14 @@ int arm_smmu_init_one_queue(struct arm_smmu_device *smmu,
> qsz = ((1 << q->llq.max_n_shift) * dwords) << 3;
> q->base = dmam_alloc_coherent(smmu->dev, qsz, &q->base_dma,
> GFP_KERNEL);
> - if (q->base || qsz < PAGE_SIZE)
> + /*
> + * If allocation succeeds, we're done. If it fails, only retry
> + * if the requested size is still larger than a page. Since
> + * dmam_alloc_coherent() allocates at least PAGE_SIZE, retrying
> + * with a sub-page size is logically redundant and could lead
> + * to sub-optimal hardware configuration.
> + */
> + if (q->base || qsz <= PAGE_SIZE)
> break;
>
> q->llq.max_n_shift--;
^ permalink raw reply
* Re: [PATCH 05/18] KVM: arm64: vgic: Constify struct irq_ops usage
From: Joey Gouly @ 2026-04-21 15:54 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260415115559.2227718-6-maz@kernel.org>
On Wed, Apr 15, 2026 at 12:55:46PM +0100, Marc Zyngier wrote:
> vgic-v5 has introduced much more prevalent usage of the struct
> irq_ops mechanism.
>
> In the process, it becomes evident that suffers from two related
> problems:
>
> - it contains flags, rather than only callbacks
> - it is mutable, because we need to update the above flags
>
> Swap the flags for a helper retrieving the flags, and make all
> irq_ops const, something that is slightly satisfying.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
> ---
> arch/arm64/kvm/arch_timer.c | 14 +++++++++-----
> arch/arm64/kvm/vgic/vgic-v5.c | 2 +-
> arch/arm64/kvm/vgic/vgic.c | 2 +-
> include/kvm/arm_vgic.h | 9 +++++----
> 4 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/arch/arm64/kvm/arch_timer.c b/arch/arm64/kvm/arch_timer.c
> index cbea4d9ee9552..f003df76fdda7 100644
> --- a/arch/arm64/kvm/arch_timer.c
> +++ b/arch/arm64/kvm/arch_timer.c
> @@ -52,11 +52,17 @@ static u64 kvm_arm_timer_read(struct kvm_vcpu *vcpu,
> enum kvm_arch_timer_regs treg);
> static bool kvm_arch_timer_get_input_level(int vintid);
>
> -static struct irq_ops arch_timer_irq_ops = {
> +static unsigned long kvm_arch_timer_get_irq_flags(void)
> +{
> + return kvm_vgic_global_state.no_hw_deactivation ? VGIC_IRQ_SW_RESAMPLE : 0;
> +}
> +
> +static const struct irq_ops arch_timer_irq_ops = {
> + .get_flags = kvm_arch_timer_get_irq_flags,
> .get_input_level = kvm_arch_timer_get_input_level,
> };
>
> -static struct irq_ops arch_timer_irq_ops_vgic_v5 = {
> +static const struct irq_ops arch_timer_irq_ops_vgic_v5 = {
> .get_input_level = kvm_arch_timer_get_input_level,
> .queue_irq_unlock = vgic_v5_ppi_queue_irq_unlock,
> .set_direct_injection = vgic_v5_set_ppi_dvi,
> @@ -1392,8 +1398,6 @@ static int kvm_irq_init(struct arch_timer_kvm_info *info)
> return -ENOMEM;
> }
>
> - if (kvm_vgic_global_state.no_hw_deactivation)
> - arch_timer_irq_ops.flags |= VGIC_IRQ_SW_RESAMPLE;
> WARN_ON(irq_domain_push_irq(domain, host_vtimer_irq,
> (void *)TIMER_VTIMER));
> }
> @@ -1591,8 +1595,8 @@ static bool kvm_arch_timer_get_input_level(int vintid)
> int kvm_timer_enable(struct kvm_vcpu *vcpu)
> {
> struct arch_timer_cpu *timer = vcpu_timer(vcpu);
> + const struct irq_ops *ops;
> struct timer_map map;
> - struct irq_ops *ops;
> int ret;
>
> if (timer->enabled)
> diff --git a/arch/arm64/kvm/vgic/vgic-v5.c b/arch/arm64/kvm/vgic/vgic-v5.c
> index 0101ec3f55283..757484d2493b2 100644
> --- a/arch/arm64/kvm/vgic/vgic-v5.c
> +++ b/arch/arm64/kvm/vgic/vgic-v5.c
> @@ -285,7 +285,7 @@ void vgic_v5_set_ppi_dvi(struct kvm_vcpu *vcpu, struct vgic_irq *irq, bool dvi)
> __assign_bit(ppi, cpu_if->vgic_ppi_dvir, dvi);
> }
>
> -static struct irq_ops vgic_v5_ppi_irq_ops = {
> +static const struct irq_ops vgic_v5_ppi_irq_ops = {
> .queue_irq_unlock = vgic_v5_ppi_queue_irq_unlock,
> .set_direct_injection = vgic_v5_set_ppi_dvi,
> };
> diff --git a/arch/arm64/kvm/vgic/vgic.c b/arch/arm64/kvm/vgic/vgic.c
> index 1e9fe8764584d..3ac6d49bc4876 100644
> --- a/arch/arm64/kvm/vgic/vgic.c
> +++ b/arch/arm64/kvm/vgic/vgic.c
> @@ -573,7 +573,7 @@ int kvm_vgic_inject_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
> }
>
> void kvm_vgic_set_irq_ops(struct kvm_vcpu *vcpu, u32 vintid,
> - struct irq_ops *ops)
> + const struct irq_ops *ops)
> {
> struct vgic_irq *irq = vgic_get_vcpu_irq(vcpu, vintid);
>
> diff --git a/include/kvm/arm_vgic.h b/include/kvm/arm_vgic.h
> index ea793479ab254..fe49fb56dc3c9 100644
> --- a/include/kvm/arm_vgic.h
> +++ b/include/kvm/arm_vgic.h
> @@ -205,7 +205,7 @@ struct vgic_irq;
> */
> struct irq_ops {
> /* Per interrupt flags for special-cased interrupts */
> - unsigned long flags;
> + unsigned long (*get_flags)(void);
>
> #define VGIC_IRQ_SW_RESAMPLE BIT(0) /* Clear the active state for resampling */
>
> @@ -271,7 +271,7 @@ struct vgic_irq {
> u8 priority;
> u8 group; /* 0 == group 0, 1 == group 1 */
>
> - struct irq_ops *ops;
> + const struct irq_ops *ops;
>
> void *owner; /* Opaque pointer to reserve an interrupt
> for in-kernel devices. */
> @@ -279,7 +279,8 @@ struct vgic_irq {
>
> static inline bool vgic_irq_needs_resampling(struct vgic_irq *irq)
> {
> - return irq->ops && (irq->ops->flags & VGIC_IRQ_SW_RESAMPLE);
> + return irq->ops && irq->ops->get_flags &&
> + (irq->ops->get_flags() & VGIC_IRQ_SW_RESAMPLE);
> }
>
> struct vgic_register_region;
> @@ -557,7 +558,7 @@ void kvm_vgic_init_cpu_hardware(void);
> int kvm_vgic_inject_irq(struct kvm *kvm, struct kvm_vcpu *vcpu,
> unsigned int intid, bool level, void *owner);
> void kvm_vgic_set_irq_ops(struct kvm_vcpu *vcpu, u32 vintid,
> - struct irq_ops *ops);
> + const struct irq_ops *ops);
> void kvm_vgic_clear_irq_ops(struct kvm_vcpu *vcpu, u32 vintid);
> int kvm_vgic_map_phys_irq(struct kvm_vcpu *vcpu, unsigned int host_irq,
> u32 vintid);
> --
> 2.47.3
>
^ permalink raw reply
* [PATCH v3 2/2] arm64: dts: amlogic: add support for X98Q
From: christian.koever-draxl @ 2026-04-21 15:53 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-1-christian.koever-draxl@student.uibk.ac.at>
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Add dts enabling core hardware for the Amediatech X98Q.
Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
---
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
2 files changed, 250 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
diff --git a/arch/arm64/boot/dts/amlogic/Makefile b/arch/arm64/boot/dts/amlogic/Makefile
index 15f9c817e502..c7752684dea6 100644
--- a/arch/arm64/boot/dts/amlogic/Makefile
+++ b/arch/arm64/boot/dts/amlogic/Makefile
@@ -85,6 +85,7 @@ dtb-$(CONFIG_ARCH_MESON) += meson-gxm-ugoos-am3.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-vega-s96.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-gxm-wetek-core2.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s805x2-aq222.dtb
+dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905w2-x98q.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-s4-s905y4-khadas-vim1s.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air-gbit.dtb
dtb-$(CONFIG_ARCH_MESON) += meson-sm1-a95xf3-air.dtb
diff --git a/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
new file mode 100644
index 000000000000..3eecbc858522
--- /dev/null
+++ b/arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
@@ -0,0 +1,249 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2026 Christian Stefan Köver-Draxl
+ * Based on meson-s4-s905y4-khadas-vim1s.dts:
+ * - Copyright (c) 2026 Khadas Technology Co., Ltd.
+ */
+
+/dts-v1/;
+
+#include "meson-s4.dtsi"
+
+/ {
+ model = "Shenzhen Amediatech Technology Co., Ltd X98Q";
+ compatible = "amediatech,x98q", "amlogic,s905w2", "amlogic,s4";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ mmc0 = &emmc; /* eMMC */
+ mmc1 = &sd; /* SD card */
+ mmc2 = &sdio; /* SDIO */
+ serial0 = &uart_b;
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x0 0x0 0x40000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* 52 MiB reserved for ARM Trusted Firmware */
+ secmon_reserved: secmon@5000000 {
+ reg = <0x0 0x05000000 0x0 0x3400000>;
+ no-map;
+ };
+ };
+
+ emmc_pwrseq: emmc-pwrseq {
+ compatible = "mmc-pwrseq-emmc";
+ reset-gpios = <&gpio GPIOB_9 GPIO_ACTIVE_LOW>;
+ };
+
+ sdio_32k: sdio-32k {
+ compatible = "pwm-clock";
+ #clock-cells = <0>;
+ clock-frequency = <32768>;
+ pwms = <&pwm_ef 0 30518 0>; /* PWM_E at 32.768KHz */
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&gpio GPIOX_6 GPIO_ACTIVE_LOW>;
+ clocks = <&sdio_32k>;
+ clock-names = "ext_clock";
+ };
+
+ main_5v: regulator-main-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "5V";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ sd_3v3: regulator-sd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "SD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio GPIOD_4 GPIO_ACTIVE_LOW>;
+ regulator-always-on;
+ };
+
+ vddio_sd: regulator-vddio-sd {
+ compatible = "regulator-gpio";
+ regulator-name = "VDDIO_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&gpio GPIOD_9 GPIO_ACTIVE_HIGH>;
+ gpios-states = <1>;
+ states = <1800000 1 3300000 0>;
+ };
+
+ vddao_3v3: regulator-vddao-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDAO_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&main_5v>;
+ regulator-always-on;
+ };
+
+ vddio_ao1v8: regulator-vddio-ao1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDDIO_AO1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ vin-supply = <&vddao_3v3>;
+ regulator-always-on;
+ };
+
+ /* SY8120B1ABC DC/DC Regulator. */
+ vddcpu: regulator-vddcpu {
+ compatible = "pwm-regulator";
+
+ regulator-name = "VDDCPU";
+ regulator-min-microvolt = <689000>;
+ regulator-max-microvolt = <1049000>;
+
+ vin-supply = <&main_5v>;
+
+ pwms = <&pwm_ij 1 1500 0>;
+ pwm-dutycycle-range = <100 0>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ /* Voltage Duty-Cycle */
+ voltage-table = <1049000 0>,
+ <1039000 3>,
+ <1029000 6>,
+ <1019000 9>,
+ <1009000 12>,
+ <999000 14>,
+ <989000 17>,
+ <979000 20>,
+ <969000 23>,
+ <959000 26>,
+ <949000 29>,
+ <939000 31>,
+ <929000 34>,
+ <919000 37>,
+ <909000 40>,
+ <899000 43>,
+ <889000 45>,
+ <879000 48>,
+ <869000 51>,
+ <859000 54>,
+ <849000 56>,
+ <839000 59>,
+ <829000 62>,
+ <819000 65>,
+ <809000 68>,
+ <799000 70>,
+ <789000 73>,
+ <779000 76>,
+ <769000 79>,
+ <759000 81>,
+ <749000 84>,
+ <739000 87>,
+ <729000 89>,
+ <719000 92>,
+ <709000 95>,
+ <699000 98>,
+ <689000 100>;
+ };
+};
+
+&emmc {
+ status = "okay";
+ pinctrl-0 = <&emmc_pins>, <&emmc_ds_pins>;
+ pinctrl-1 = <&emmc_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ mmc-ddr-1_8v;
+ mmc-hs200-1_8v;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ mmc-pwrseq = <&emmc_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+ðmac {
+ status = "okay";
+ phy-handle = <&internal_ephy>;
+ phy-mode = "rmii";
+};
+
+&ir {
+ status = "okay";
+ pinctrl-0 = <&remote_pins>;
+ pinctrl-names = "default";
+};
+
+&pwm_ef {
+ status = "okay";
+ pinctrl-0 = <&pwm_e_pins1>;
+ pinctrl-names = "default";
+};
+
+&pwm_ij {
+ status = "okay";
+};
+
+&sd {
+ status = "okay";
+ pinctrl-0 = <&sdcard_pins>;
+ pinctrl-1 = <&sdcard_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ bus-width = <4>;
+ cap-sd-highspeed;
+ max-frequency = <50000000>;
+ disable-wp;
+
+ cd-gpios = <&gpio GPIOC_6 GPIO_ACTIVE_LOW>;
+
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddao_3v3>;
+};
+
+ /*
+ * Wireless SDIO Module (Amlogic W150S1)
+ * Note: There is no driver for this at the moment.
+ */
+
+&sdio {
+ status = "okay";
+ pinctrl-0 = <&sdio_pins>;
+ pinctrl-1 = <&sdio_clk_gate_pins>;
+ pinctrl-names = "default", "clk-gate";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ sd-uhs-sdr50;
+ sd-uhs-sdr104;
+ max-frequency = <200000000>;
+ non-removable;
+ disable-wp;
+
+ no-sd;
+ no-mmc;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ vmmc-supply = <&vddao_3v3>;
+ vqmmc-supply = <&vddio_ao1v8>;
+};
+
+&uart_b {
+ status = "okay";
+};
--
2.53.0
^ permalink raw reply related
* [PATCH v3 1/2] dt-bindings: arm: amlogic: add support for Amediatech X98Q
From: christian.koever-draxl @ 2026-04-21 15:53 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
In-Reply-To: <20260421155328.26359-1-christian.koever-draxl@student.uibk.ac.at>
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Add the board binding for the Amediatech X98Q TV box
Signed-off-by: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
---
Documentation/devicetree/bindings/arm/amlogic.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml
index a885278bc4e2..c0167fbc310a 100644
--- a/Documentation/devicetree/bindings/arm/amlogic.yaml
+++ b/Documentation/devicetree/bindings/arm/amlogic.yaml
@@ -248,6 +248,13 @@ properties:
- const: amlogic,s805x2
- const: amlogic,s4
+ - description: Boards with the Amlogic Meson S4 S905W2 SoC
+ items:
+ - enum:
+ - amediatech,x98q
+ - const: amlogic,s905w2
+ - const: amlogic,s4
+
- description: Boards with the Amlogic Meson S4 S905Y4 SoC
items:
- enum:
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/2] Add support for Amediatech X98Q (Amlogic S905W2)
From: christian.koever-draxl @ 2026-04-21 15:53 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, neil.armstrong, khilman
Cc: jbrunet, martin.blumenstingl, devicetree, linux-amlogic,
linux-arm-kernel, linux-kernel,
Christian Stefan Kövér-Draxl
From: Christian Stefan Kövér-Draxl <christian.koever-draxl@student.uibk.ac.at>
Changes in v3:
- Change position of the entry in the amlogic.yaml.
- Change formatting of the Amlogic W150S1 Wi-Fi module comment.
- Fix several formatting issues.
Changes in v2:
- Split dt-bindings and dts changes into separate patches.
- Updated model string to match documented vendor prefix.
- Put vddio_sd states array in a single line.
- Added a comment for the unsupported Amlogic W150S1 Wi-Fi module.
Christian Stefan Kövér-Draxl (2):
dt-bindings: arm: amlogic: add support for Amediatech X98Q
arm64: dts: amlogic: add support for X98Q
.../devicetree/bindings/arm/amlogic.yaml | 7 +
arch/arm64/boot/dts/amlogic/Makefile | 1 +
.../boot/dts/amlogic/meson-s4-s905w2-x98q.dts | 249 ++++++++++++++++++
3 files changed, 257 insertions(+)
create mode 100644 arch/arm64/boot/dts/amlogic/meson-s4-s905w2-x98q.dts
--
2.53.0
^ permalink raw reply
* Re: [PATCH v2 13/20] drm/connector: Add new atomic_create_state callback
From: Dmitry Baryshkov @ 2026-04-21 15:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-13-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:20PM +0100, Maxime Ripard wrote:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software tate, reset it, but
> also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> And reset() isn't fallible, which makes it harder to handle
> initialization errors properly.
>
> And this is only really relevant for some drivers, since all the helpers
> for reset only create a new state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Let's continue the transition to the new pattern with connectors.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 45 +++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 ++++++++++++++-
> include/drm/drm_atomic_state_helper.h | 4 +++
> include/drm/drm_connector.h | 13 +++++++++
> 4 files changed, 82 insertions(+), 1 deletion(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH] soc: ti: k3-ringacc: Fix access mode for k3_ringacc_ring_pop_tail_io()
From: Hari Prasath G E @ 2026-04-21 15:50 UTC (permalink / raw)
To: Siddharth Vadapalli, nm, ssantosh
Cc: stable, linux-kernel, linux-arm-kernel, srk, s-adivi
In-Reply-To: <20260413065125.627180-1-s-vadapalli@ti.com>
Hello Siddharth,
Thanks for the patch.
On 4/13/2026 12:21 PM, Siddharth Vadapalli wrote:
> k3_ringacc_ring_pop_tail_io() invokes k3_ringacc_ring_access_io() with the
> access mode incorrectly set to K3_RINGACC_ACCESS_MODE_POP_HEAD instead of
> K3_RINGACC_ACCESS_MODE_POP_TAIL. Fix this.
>
> Fixes: 3277e8aa2504 ("soc: ti: k3: add navss ringacc driver")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com>
> ---
>
> Hello,
>
> This patch is based on commit
> 028ef9c96e96 Linux 7.0
> of Mainline Linux.
>
> I noticed (visually) the incorrect access mode while working on:
> https://lore.kernel.org/r/20260325123850.638748-1-s-vadapalli@ti.com/
>
> Regards,
> Siddharth.
>
> drivers/soc/ti/k3-ringacc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
> index 7602b8a909b0..24f658e8c1dc 100644
> --- a/drivers/soc/ti/k3-ringacc.c
> +++ b/drivers/soc/ti/k3-ringacc.c
> @@ -1083,7 +1083,7 @@ static int k3_ringacc_ring_pop_io(struct k3_ring *ring, void *elem)
> static int k3_ringacc_ring_pop_tail_io(struct k3_ring *ring, void *elem)
> {
> return k3_ringacc_ring_access_io(ring, elem,
> - K3_RINGACC_ACCESS_MODE_POP_HEAD);
> + K3_RINGACC_ACCESS_MODE_POP_TAIL);
I see that you have noticed this visually and fixed this,was there any
impact you faced without this change like data corruption or something ?
It would be better to mention the impact this change brings-in by doing
some analysis.
There is a similar function k3_ringacc_ring_pop_tail_proxy() few lines
above where the same change might be required.
Regards,
Hari
> }
>
> /*
^ permalink raw reply
* Re: [PATCH v2 11/20] drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
From: Dmitry Baryshkov @ 2026-04-21 15:50 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-11-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:18PM +0100, Maxime Ripard wrote:
> __drm_atomic_helper_connector_state_reset() is used to initialize a
> newly allocated drm_connector_state, and is being typically called by
> the drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_state_reset() to
> __drm_atomic_helper_connector_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 10 +++++-----
> include/drm/drm_atomic_state_helper.h | 2 +-
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 12/20] drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
From: Dmitry Baryshkov @ 2026-04-21 15:50 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Jyri Sarha, Tomi Valkeinen,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260320-drm-mode-config-init-v2-12-c63f1134e76c@kernel.org>
On Fri, Mar 20, 2026 at 05:27:19PM +0100, Maxime Ripard wrote:
> __drm_atomic_helper_connector_hdmi_reset() is typically used to
> initialize a newly allocated drm_connector_state when the connector is
> using the HDMI helpers, and is being called by the
> drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_hdmi_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_hdmi_reset() to
> __drm_atomic_helper_connector_hdmi_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 4 ++--
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 14 ++++++++------
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> include/drm/display/drm_hdmi_state_helper.h | 4 ++--
> 6 files changed, 15 insertions(+), 13 deletions(-)
>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: mediatek: Convert mtk-btcvsd-snd to DT Schema
From: Luca Leonardo Scorcia @ 2026-04-21 15:46 UTC (permalink / raw)
To: linux-sound
Cc: Luca Leonardo Scorcia, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
Convert the mtk-btcvsd-snd.txt DT binding to DT Schema format.
Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
---
Changes in v2:
- Fixed issues from make dt_binding_check
- Set myself as maintainer for the binding
.../sound/mediatek,mtk-btcvsd-snd.yaml | 60 +++++++++++++++++++
.../bindings/sound/mtk-btcvsd-snd.txt | 24 --------
2 files changed, 60 insertions(+), 24 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml b/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
new file mode 100644
index 000000000000..1ec50c7611df
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mtk-btcvsd-snd.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mtk-btcvsd-snd.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mediatek ALSA BT SCO CVSD/MSBC Driver
+
+maintainers:
+ - Luca Leonardo Scorcia <l.scorcia@gmail.com>
+
+properties:
+ compatible:
+ const: mediatek,mtk-btcvsd-snd
+
+ reg:
+ items:
+ - description: Register location and size of PKV
+ - description: Register location and size of SRAM_BANK2
+
+ interrupts:
+ items:
+ - description: BT-SCO interrupt
+
+ mediatek,infracfg:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: The phandle of the infracfg controller
+
+ mediatek,offset:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ description: Array of register offsets and masks
+ items:
+ - description: infra_misc_offset
+ - description: infra_conn_bt_cvsd_mask
+ - description: cvsd_mcu_read_offset
+ - description: cvsd_mcu_write_offset
+ - description: cvsd_packet_indicator_offset
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - mediatek,infracfg
+ - mediatek,offset
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ mtk-btcvsd-snd@18000000 {
+ compatible = "mediatek,mtk-btcvsd-snd";
+ reg = <0x18000000 0x1000>,
+ <0x18080000 0x8000>;
+ interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_LOW>;
+ mediatek,infracfg = <&infrasys>;
+ mediatek,offset = <0xf00 0x800 0xfd0 0xfd4 0xfd8>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt b/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
deleted file mode 100644
index 679e44839b48..000000000000
--- a/Documentation/devicetree/bindings/sound/mtk-btcvsd-snd.txt
+++ /dev/null
@@ -1,24 +0,0 @@
-Mediatek ALSA BT SCO CVSD/MSBC Driver
-
-Required properties:
-- compatible = "mediatek,mtk-btcvsd-snd";
-- reg: register location and size of PKV and SRAM_BANK2
-- interrupts: should contain BTSCO interrupt
-- mediatek,infracfg: the phandles of INFRASYS
-- mediatek,offset: Array contains of register offset and mask
- infra_misc_offset,
- infra_conn_bt_cvsd_mask,
- cvsd_mcu_read_offset,
- cvsd_mcu_write_offset,
- cvsd_packet_indicator_offset
-
-Example:
-
- mtk-btcvsd-snd@18000000 {
- compatible = "mediatek,mtk-btcvsd-snd";
- reg=<0 0x18000000 0 0x1000>,
- <0 0x18080000 0 0x8000>;
- interrupts = <GIC_SPI 286 IRQ_TYPE_LEVEL_LOW>;
- mediatek,infracfg = <&infrasys>;
- mediatek,offset = <0xf00 0x800 0xfd0 0xfd4 0xfd8>;
- };
--
2.43.0
^ permalink raw reply related
* [PATCH v2] mm/page_alloc: fix initialization of tags of the huge zero folio with init_on_free
From: David Hildenbrand (Arm) @ 2026-04-21 15:39 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Catalin Marinas, Will Deacon, Andrew Morton, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Brendan Jackman,
Johannes Weiner, Zi Yan, Lance Yang, Ryan Roberts, Mark Brown,
Dev Jain, linux-kernel, linux-mm, stable, David Hildenbrand (Arm)
__GFP_ZEROTAGS semantics are currently a bit weird, but effectively this
flag is only ever set alongside __GFP_ZERO and __GFP_SKIP_KASAN.
If we run with init_on_free, we will zero out pages during
__free_pages_prepare(), to skip zeroing on the allocation path.
However, when allocating with __GFP_ZEROTAG set, post_alloc_hook() will
consequently not only skip clearing page content, but also skip
clearing tag memory.
Not clearing tags through __GFP_ZEROTAGS is irrelevant for most pages that
will get mapped to user space through set_pte_at() later: set_pte_at() and
friends will detect that the tags have not been initialized yet
(PG_mte_tagged not set), and initialize them.
However, for the huge zero folio, which will be mapped through a PMD
marked as special, this initialization will not be performed, ending up
exposing whatever tags were still set for the pages.
The docs (Documentation/arch/arm64/memory-tagging-extension.rst) state
that allocation tags are set to 0 when a page is first mapped to user
space. That no longer holds with the huge zero folio when init_on_free
is enabled.
Fix it by decoupling __GFP_ZEROTAGS from __GFP_ZERO, passing to
tag_clear_highpages() whether we want to also clear page content.
Invert the meaning of the tag_clear_highpages() return value to have
clearer semantics.
Reproduced with the huge zero folio by modifying the check_buffer_fill
arm64/mte selftest to use a 2 MiB area, after making sure that pages have
a non-0 tag set when freeing (note that, during boot, we will not
actually initialize tags, but only set KASAN_TAG_KERNEL in the page
flags).
$ ./check_buffer_fill
1..20
...
not ok 17 Check initial tags with private mapping, sync error mode and mmap memory
not ok 18 Check initial tags with private mapping, sync error mode and mmap/mprotect memory
...
This code needs more cleanups; we'll tackle that next, like
decoupling __GFP_ZEROTAGS from __GFP_SKIP_KASAN.
Fixes: adfb6609c680 ("mm/huge_memory: initialise the tags of the huge zero folio")
Cc: stable@vger.kernel.org
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
Changes in v2:
- Drop kasan_hw_tags_enabled() handling, as it missed the case of
user-space MTE without KASAN.
- Keep letting_clear_highpages() return a bool and re-instantiate
system_supports_mte() handling in the arm64 variant.
- Rephrase __GFP_ZEROTAGS comment, making it clearer that this is not
just a performance improvement.
- Retested and more excessively build tested
- Using a new b4 template, hopefully that doesn't mess things up
- Link to v1: https://lore.kernel.org/r/20260420-zerotags-v1-1-3edc93e95bb4@kernel.org
---
arch/arm64/include/asm/page.h | 2 +-
arch/arm64/mm/fault.c | 11 +++++++----
include/linux/gfp_types.h | 10 +++++-----
include/linux/highmem.h | 7 ++++---
mm/page_alloc.c | 8 ++++----
5 files changed, 21 insertions(+), 17 deletions(-)
diff --git a/arch/arm64/include/asm/page.h b/arch/arm64/include/asm/page.h
index e25d0d18f6d7..58200de8a221 100644
--- a/arch/arm64/include/asm/page.h
+++ b/arch/arm64/include/asm/page.h
@@ -33,7 +33,7 @@ struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
unsigned long vaddr);
#define vma_alloc_zeroed_movable_folio vma_alloc_zeroed_movable_folio
-bool tag_clear_highpages(struct page *to, int numpages);
+bool tag_clear_highpages(struct page *to, int numpages, bool clear_pages);
#define __HAVE_ARCH_TAG_CLEAR_HIGHPAGES
#define copy_user_page(to, from, vaddr, pg) copy_page(to, from)
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 0f3c5c7ca054..739800835920 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -1018,7 +1018,7 @@ struct folio *vma_alloc_zeroed_movable_folio(struct vm_area_struct *vma,
return vma_alloc_folio(flags, 0, vma, vaddr);
}
-bool tag_clear_highpages(struct page *page, int numpages)
+bool tag_clear_highpages(struct page *page, int numpages, bool clear_pages)
{
/*
* Check if MTE is supported and fall back to clear_highpage().
@@ -1026,13 +1026,16 @@ bool tag_clear_highpages(struct page *page, int numpages)
* post_alloc_hook() will invoke tag_clear_highpages().
*/
if (!system_supports_mte())
- return false;
+ return clear_pages;
/* Newly allocated pages, shouldn't have been tagged yet */
for (int i = 0; i < numpages; i++, page++) {
WARN_ON_ONCE(!try_page_mte_tagging(page));
- mte_zero_clear_page_tags(page_address(page));
+ if (clear_pages)
+ mte_zero_clear_page_tags(page_address(page));
+ else
+ mte_clear_page_tags(page_address(page));
set_page_mte_tagged(page);
}
- return true;
+ return false;
}
diff --git a/include/linux/gfp_types.h b/include/linux/gfp_types.h
index 6c75df30a281..d79049291b1a 100644
--- a/include/linux/gfp_types.h
+++ b/include/linux/gfp_types.h
@@ -273,11 +273,11 @@ enum {
*
* %__GFP_ZERO returns a zeroed page on success.
*
- * %__GFP_ZEROTAGS zeroes memory tags at allocation time if the memory itself
- * is being zeroed (either via __GFP_ZERO or via init_on_alloc, provided that
- * __GFP_SKIP_ZERO is not set). This flag is intended for optimization: setting
- * memory tags at the same time as zeroing memory has minimal additional
- * performance impact.
+ * %__GFP_ZEROTAGS zeroes memory tags at allocation time. Setting memory tags at
+ * the same time as zeroing memory (e.g., with __GPF_ZERO) has minimal
+ * additional performance impact. However, __GFP_ZEROTAGS also zeroes the tags
+ * even if memory is not getting zeroed at allocation time (e.g.,
+ * with init_on_free).
*
* %__GFP_SKIP_KASAN makes KASAN skip unpoisoning on page allocation.
* Used for userspace and vmalloc pages; the latter are unpoisoned by
diff --git a/include/linux/highmem.h b/include/linux/highmem.h
index af03db851a1d..d7aac9de1c8a 100644
--- a/include/linux/highmem.h
+++ b/include/linux/highmem.h
@@ -347,10 +347,11 @@ static inline void clear_highpage_kasan_tagged(struct page *page)
#ifndef __HAVE_ARCH_TAG_CLEAR_HIGHPAGES
-/* Return false to let people know we did not initialize the pages */
-static inline bool tag_clear_highpages(struct page *page, int numpages)
+/* Returns true if the caller has to initialize the pages */
+static inline bool tag_clear_highpages(struct page *page, int numpages,
+ bool clear_pages)
{
- return false;
+ return clear_pages;
}
#endif
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 65e205111553..71859993dd54 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -1808,9 +1808,9 @@ static inline bool should_skip_init(gfp_t flags)
inline void post_alloc_hook(struct page *page, unsigned int order,
gfp_t gfp_flags)
{
+ const bool zero_tags = gfp_flags & __GFP_ZEROTAGS;
bool init = !want_init_on_free() && want_init_on_alloc(gfp_flags) &&
!should_skip_init(gfp_flags);
- bool zero_tags = init && (gfp_flags & __GFP_ZEROTAGS);
int i;
set_page_private(page, 0);
@@ -1832,11 +1832,11 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
*/
/*
- * If memory tags should be zeroed
- * (which happens only when memory should be initialized as well).
+ * Clearing tags can efficiently clear the memory for us as well, if
+ * required.
*/
if (zero_tags)
- init = !tag_clear_highpages(page, 1 << order);
+ init = tag_clear_highpages(page, 1 << order, /* clear_pages= */init);
if (!should_skip_kasan_unpoison(gfp_flags) &&
kasan_unpoison_pages(page, order, init)) {
---
base-commit: f1541b40cd422d7e22273be9b7e9edfc9ea4f0d7
change-id: 20260417-zerotags-343a3673e18d
--
Cheers,
David
^ permalink raw reply related
* Re: [PATCH v2 15/20] drm/drv: Call drm_mode_config_create_state() by default
From: Thomas Zimmermann @ 2026-04-21 15:33 UTC (permalink / raw)
To: Maxime Ripard, Maarten Lankhorst, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, Simon Ser,
Harry Wentland, Melissa Wen, Sebastian Wick, Alex Hung,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Chen-Yu Tsai, Samuel Holland, Dave Stevenson, Maíra Canal,
Raspberry Pi Kernel Maintenance
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <79cc30d5-80b5-4d87-a3ad-36d6fad98853@suse.de>
Am 21.04.26 um 15:38 schrieb Thomas Zimmermann:
> Hi
>
> Am 20.03.26 um 17:27 schrieb Maxime Ripard:
>> Almost all drivers, and our documented skeleton, call
>> drm_mode_config_reset() prior to calling drm_dev_register() to
>> initialize its DRM object states.
>>
>> Now that we have drm_mode_config_create_state() to create that initial
>> state if it doesn't exist, we can call it directly in
>> drm_dev_register(). That way, we know that the initial atomic state will
>> always be allocated without any boilerplate.
>>
>> Signed-off-by: Maxime Ripard <mripard@kernel.org>
>> ---
>> drivers/gpu/drm/drm_drv.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
>> index
>> 2915118436ce8a6640cfb0c59936031990727ed1..820106d56ab399a39cac56d98662b5ddbcae8ded
>> 100644
>> --- a/drivers/gpu/drm/drm_drv.c
>> +++ b/drivers/gpu/drm/drm_drv.c
>> @@ -1097,10 +1097,14 @@ int drm_dev_register(struct drm_device *dev,
>> unsigned long flags)
>> if (drm_core_check_feature(dev, DRIVER_MODESET)) {
>> ret = drm_modeset_register_all(dev);
>> if (ret)
>> goto err_unload;
>> +
>> + ret = drm_mode_config_create_state(dev);
>> + if (ret)
>> + goto err_unload;
>
> Way too late. Lets rather go through drivers and call this where they
> currently call drm_mode_config_reset() for initialization. This can be
> a single-patch mass conversion IMHO.
On a second thought, can't we modify the suspend code and leave the
reset as-is for now? I'd still be interested to use reset as a means of
initializing the hardware or loading state on probe. So keeping the
_reset() calls in place might be helpful for that.
What's the long-term plan here?
Best regards
Thomas
>
> Best regards
> Thomas
>
>> }
>> drm_panic_register(dev);
>> drm_client_sysrq_register(dev);
>> DRM_INFO("Initialized %s %d.%d.%d for %s on minor %d\n",
>>
>
--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstr. 146, 90461 Nürnberg, Germany, www.suse.com
GF: Jochen Jaser, Andrew McDonald, Werner Knoblich, (HRB 36809, AG Nürnberg)
^ permalink raw reply
* Re: [PATCH] iommu/arm-smmu-v3: Stop queue allocation retry at PAGE_SIZE
From: Will Deacon @ 2026-04-21 15:26 UTC (permalink / raw)
To: leo.jiang1224; +Cc: robin.murphy, joro, iommu, linux-arm-kernel
In-Reply-To: <tencent_F6E384A40D990A279B460A0CDE1927FDF509@qq.com>
On Sat, Apr 18, 2026 at 01:31:43PM +0800, leo.jiang1224@foxmail.com wrote:
> From: LoserJL <leo.jiang1224@foxmail.com>
>
> In arm_smmu_init_one_queue(), the loop reduces max_n_shift if
> dmam_alloc_coherent() fails. However, since dmam_alloc_coherent()
> allocates at least PAGE_SIZE, retrying with a smaller size after
> a PAGE_SIZE failure is logically redundant.
>
> Moreover, if a sub-page retry were to succeed due to concurrent memory
> release, the hardware would be configured with a smaller queue depth
> despite a full page being allocated. This leads to inefficient memory
> usage and unnecessary hardware performance limitation.
>
> Terminate the loop once qsz reaches PAGE_SIZE to ensure logical
> consistency and optimal hardware configuration.
>
> Signed-off-by: LoserJL <leo.jiang1224@foxmail.com>
No pseudonyms, please.
> ---
> drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index e8d7dbe495f0..e0ec118ff560 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -4418,7 +4418,14 @@ int arm_smmu_init_one_queue(struct arm_smmu_device *smmu,
> qsz = ((1 << q->llq.max_n_shift) * dwords) << 3;
> q->base = dmam_alloc_coherent(smmu->dev, qsz, &q->base_dma,
> GFP_KERNEL);
> - if (q->base || qsz < PAGE_SIZE)
> + /*
> + * If allocation succeeds, we're done. If it fails, only retry
> + * if the requested size is still larger than a page. Since
> + * dmam_alloc_coherent() allocates at least PAGE_SIZE, retrying
> + * with a sub-page size is logically redundant and could lead
> + * to sub-optimal hardware configuration.
What do you mean by "sub-optimal hardware configuration"? I think you can
probably just drop this comment.
> + */
> + if (q->base || qsz <= PAGE_SIZE)
> break;
I think this part is fine.
Will
^ permalink raw reply
* Re: [PATCH 06/18] KVM: arm64: vgic: Consolidate vgic_allocate_private_irqs_locked()
From: Joey Gouly @ 2026-04-21 15:22 UTC (permalink / raw)
To: Marc Zyngier
Cc: kvmarm, linux-arm-kernel, Suzuki K Poulose, Oliver Upton,
Zenghui Yu, Sascha Bischoff
In-Reply-To: <20260415115559.2227718-7-maz@kernel.org>
On Wed, Apr 15, 2026 at 12:55:47PM +0100, Marc Zyngier wrote:
> vgic_allocate_private_irqs_locked() calls two helpers, oddly named
> vgic_{,v5_}allocate_private_irq().
>
> Not only these helpers don't allocate anything, but they also
> contain duplicate init code that would be better placed in the
> caller.
>
> Consolidate the common init code in the caller, rename the helpers
> to vgic_{,v5_}setup_private_irq(), and pass the irq pointer around
> instead of the index of the interrupt.
>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> arch/arm64/kvm/vgic/vgic-init.c | 45 +++++++++++++--------------------
> 1 file changed, 18 insertions(+), 27 deletions(-)
>
> diff --git a/arch/arm64/kvm/vgic/vgic-init.c b/arch/arm64/kvm/vgic/vgic-init.c
> index 933983bb20052..907057881b26a 100644
> --- a/arch/arm64/kvm/vgic/vgic-init.c
> +++ b/arch/arm64/kvm/vgic/vgic-init.c
> @@ -271,18 +271,12 @@ int kvm_vgic_vcpu_nv_init(struct kvm_vcpu *vcpu)
> return ret;
> }
>
> -static void vgic_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
> +static void vgic_setup_private_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> + u32 type)
> {
> - struct vgic_irq *irq = &vcpu->arch.vgic_cpu.private_irqs[i];
> + irq->intid = irq - &vcpu->arch.vgic_cpu.private_irqs[0];
These are allocated in one block with kzalloc_objs(), so this pointer offsetting is fine!
>
> - INIT_LIST_HEAD(&irq->ap_list);
> - raw_spin_lock_init(&irq->irq_lock);
> - irq->vcpu = NULL;
> - irq->target_vcpu = vcpu;
> - refcount_set(&irq->refcount, 0);
> -
> - irq->intid = i;
> - if (vgic_irq_is_sgi(i)) {
> + if (vgic_irq_is_sgi(irq->intid)) {
> /* SGIs */
> irq->enabled = 1;
> irq->config = VGIC_CONFIG_EDGE;
> @@ -303,18 +297,11 @@ static void vgic_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
> }
> }
>
> -static void vgic_v5_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
> +static void vgic_v5_setup_private_irq(struct kvm_vcpu *vcpu, struct vgic_irq *irq)
> {
> - struct vgic_irq *irq = &vcpu->arch.vgic_cpu.private_irqs[i];
> - u32 intid = vgic_v5_make_ppi(i);
> -
> - INIT_LIST_HEAD(&irq->ap_list);
> - raw_spin_lock_init(&irq->irq_lock);
> - irq->vcpu = NULL;
> - irq->target_vcpu = vcpu;
> - refcount_set(&irq->refcount, 0);
> + int i = irq - &vcpu->arch.vgic_cpu.private_irqs[0];
>
> - irq->intid = intid;
> + irq->intid = vgic_v5_make_ppi(i);
>
> /* The only Edge architected PPI is the SW_PPI */
> if (i == GICV5_ARCH_PPI_SW_PPI)
> @@ -323,7 +310,7 @@ static void vgic_v5_allocate_private_irq(struct kvm_vcpu *vcpu, int i, u32 type)
> irq->config = VGIC_CONFIG_LEVEL;
>
> /* Register the GICv5-specific PPI ops */
> - vgic_v5_set_ppi_ops(vcpu, intid);
> + vgic_v5_set_ppi_ops(vcpu, irq->intid);
> }
>
> static int vgic_allocate_private_irqs_locked(struct kvm_vcpu *vcpu, u32 type)
> @@ -349,15 +336,19 @@ static int vgic_allocate_private_irqs_locked(struct kvm_vcpu *vcpu, u32 type)
> if (!vgic_cpu->private_irqs)
> return -ENOMEM;
>
> - /*
> - * Enable and configure all SGIs to be edge-triggered and
> - * configure all PPIs as level-triggered.
> - */
> for (i = 0; i < num_private_irqs; i++) {
> + struct vgic_irq *irq = &vcpu->arch.vgic_cpu.private_irqs[i];
> +
> + INIT_LIST_HEAD(&irq->ap_list);
> + raw_spin_lock_init(&irq->irq_lock);
> + irq->vcpu = NULL;
> + irq->target_vcpu = vcpu;
> + refcount_set(&irq->refcount, 0);
> +
> if (vgic_is_v5(vcpu->kvm))
> - vgic_v5_allocate_private_irq(vcpu, i, type);
> + vgic_v5_setup_private_irq(vcpu, irq);
> else
> - vgic_allocate_private_irq(vcpu, i, type);
> + vgic_setup_private_irq(vcpu, irq, type);
> }
>
> return 0;
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Thanks,
Joey
^ permalink raw reply
* Re: [PATCH v2 1/2] kernel: param: handle NULL module_kset in lookup_or_create_module_kobject()
From: Greg Kroah-Hartman @ 2026-04-21 15:20 UTC (permalink / raw)
To: Shashank Balaji
Cc: Kay Sievers, Rafael J. Wysocki, Danilo Krummrich,
Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
Shuah Khan, Rahul Bukte, Daniel Palmer, Tim Bird, linux-kernel,
driver-core, coresight, linux-arm-kernel, rust-for-linux,
linux-doc
In-Reply-To: <aeeQ5x1uMKT6cyxp@JPC00244420>
On Tue, Apr 21, 2026 at 11:59:51PM +0900, Shashank Balaji wrote:
> Hi Greg,
>
> Thanks for the quick feedback!
>
> On Tue, Apr 21, 2026 at 08:27:10AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Apr 21, 2026 at 03:02:34PM +0900, Shashank Balaji wrote:
> > > module_kset is initialized in a subsys_initcall. If a built-in driver tries to
> > > register before subsys_initcall with its struct device_driver's mod_name set,
> > > then a null module_kset is dereferenced via this call trace:
> > >
> > > [ 0.095865] Call trace:
> > > [ 0.095999] _raw_spin_lock+0x4c/0x6c (P)
> > > [ 0.096150] kset_find_obj+0x24/0x104
> > > [ 0.096209] lookup_or_create_module_kobject+0x2c/0xd8
> > > [ 0.096274] module_add_driver+0xd4/0x138
> > > [ 0.096328] bus_add_driver+0x16c/0x268
> > > [ 0.096380] driver_register+0x68/0x100
> > > [ 0.096428] __platform_driver_register+0x24/0x30
> > > [ 0.096486] tegra194_cbb_init+0x24/0x30
> > > [ 0.096540] do_one_initcall+0xdc/0x250
> > > [ 0.096608] do_initcall_level+0x9c/0xd0
> > > [ 0.096660] do_initcalls+0x54/0x94
> > > [ 0.096706] do_basic_setup+0x20/0x2c
> > > [ 0.096753] kernel_init_freeable+0xc8/0x154
> > > [ 0.096807] kernel_init+0x20/0x1a0
> > > [ 0.096851] ret_from_fork+0x10/0x20
> > >
> > > So, return null in lookup_or_create_module_kobject() if module_kset is null.
> > > Existing callers handle null already.
> > >
> > > Fixes: f30c53a873d0 ("MODULES: add the module name for built in kernel drivers")
> >
> > This isn't a bugfix.
>
> I'll drop it in the next version.
>
> > > 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>
> > > ---
> > > This bug is triggered by the next patch on arm64 defconfig: tegra194-cbb tries
> > > to register from a pure_initcall, and with the next patch adding mod_name, this
> > > null deref is hit.
> >
> > So this isn't a bug, it's a "don't do that" type of thing :)
> >
> > > ---
> > > kernel/params.c | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/kernel/params.c b/kernel/params.c
> > > index 74d620bc2521..881c7328c059 100644
> > > --- a/kernel/params.c
> > > +++ b/kernel/params.c
> > > @@ -752,6 +752,9 @@ lookup_or_create_module_kobject(const char *name)
> > > struct kobject *kobj;
> > > int err;
> > >
> > > + if (!module_kset)
> > > + return NULL;
> >
> > Are you sure that making this change is going to be ok?
> > mod_sysfs_init() should have been called first as the module has to be
> > created before it can be looked up.
> >
> > As you are wanting "built in" drivers to show up here, you are going to
> > beat the call to param_sysfs_init(), so don't do that. Make sure that
> > the drivers are NOT called before then.
>
> The reason lookup_or_create_module_kobject() can be reached with module_kset == NULL
> is that some platform drivers register before subsys_initcall: tegra194_cbb and
> tegra234_cbb at pure_initcall, plus roughly 375 others at core_initcall/arch_initcall
> (208 arch, 154 core, plus 2 pure and 13 _sync variants). These are dominated by
> pinctrl, clk, interconnect, gpio, and mailbox drivers across six SoC vendor trees
> (Qualcomm, MediaTek, Freescale, Samsung, Tegra, HiSilicon).
That's not good, everyone wants to be first. It's amazing it works at
all sometimes...
> Given that, three ways forward:
>
> 1. Move module_kset creation out of param_sysfs_init() (currently
> subsys_initcall) and call it directly from do_basic_setup()
> before do_initcalls(). This is the cleanest fix from a
> correctness angle: every initcall level sees a live
> module_kset. But it touches init/main.c and kernel/params.c,
> crosses two subsystem trees. I haven't fully audited
> dependencies at do_basic_setup() time.
That's one way, OR dynamically create the kset the first time it is
asked for.
> 2. Demote the ~377 early-initcall platform drivers to
> subsys_initcall or later. Impractical at scale given coordination
> across six vendor trees, and many of these levels seem to be
> architecturally required.
Ick, yeah, that is sure to be a nightmare as there will be regressions.
> 3. (This patch) Guard lookup_or_create_module_kobject() against
> NULL module_kset. Drivers registered before subsys_initcall
> don't get the /sys/.../module symlink, but they don't get it
> today either (drv->mod_name is NULL pre-patch, so the
> else-if (drv->mod_name) branch in module_add_driver() isn't
> taken). Verified on arm64: /sys/module/tegra194_cbb/ does not
> exist on a booted defconfig with or without my series. The
> guard preserves that exact state while letting the
> device_initcall majority get their symlinks as designed.
THat's going to confuse people as to why some have the link and others
do not. How about moving it earlier OR creating it dynamically when
first needed?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/4] kselftest/arm64: Add POE helpers to test_signals_utils.h
From: Mark Brown @ 2026-04-21 15:00 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, Catalin Marinas, Joey Gouly,
Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-4-kevin.brodsky@arm.com>
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
On Tue, Apr 21, 2026 at 03:42:51PM +0100, Kevin Brodsky wrote:
> In preparation to adding further POE signal tests, move
> get_por_el0() to test_signals_utils.h and add set_por_el0().
Subject line should probably also say move if there's a v2 but otherwise
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] kernel: param: handle NULL module_kset in lookup_or_create_module_kobject()
From: Shashank Balaji @ 2026-04-21 14:59 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Kay Sievers, Rafael J. Wysocki, Danilo Krummrich,
Suzuki K Poulose, Mike Leach, James Clark, Alexander Shishkin,
Maxime Coquelin, Alexandre Torgue, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, Richard Cochran, Jonathan Corbet,
Shuah Khan, Rahul Bukte, Daniel Palmer, Tim Bird, linux-kernel,
driver-core, coresight, linux-arm-kernel, rust-for-linux,
linux-doc
In-Reply-To: <2026042126-majesty-skyline-b76f@gregkh>
Hi Greg,
Thanks for the quick feedback!
On Tue, Apr 21, 2026 at 08:27:10AM +0200, Greg Kroah-Hartman wrote:
> On Tue, Apr 21, 2026 at 03:02:34PM +0900, Shashank Balaji wrote:
> > module_kset is initialized in a subsys_initcall. If a built-in driver tries to
> > register before subsys_initcall with its struct device_driver's mod_name set,
> > then a null module_kset is dereferenced via this call trace:
> >
> > [ 0.095865] Call trace:
> > [ 0.095999] _raw_spin_lock+0x4c/0x6c (P)
> > [ 0.096150] kset_find_obj+0x24/0x104
> > [ 0.096209] lookup_or_create_module_kobject+0x2c/0xd8
> > [ 0.096274] module_add_driver+0xd4/0x138
> > [ 0.096328] bus_add_driver+0x16c/0x268
> > [ 0.096380] driver_register+0x68/0x100
> > [ 0.096428] __platform_driver_register+0x24/0x30
> > [ 0.096486] tegra194_cbb_init+0x24/0x30
> > [ 0.096540] do_one_initcall+0xdc/0x250
> > [ 0.096608] do_initcall_level+0x9c/0xd0
> > [ 0.096660] do_initcalls+0x54/0x94
> > [ 0.096706] do_basic_setup+0x20/0x2c
> > [ 0.096753] kernel_init_freeable+0xc8/0x154
> > [ 0.096807] kernel_init+0x20/0x1a0
> > [ 0.096851] ret_from_fork+0x10/0x20
> >
> > So, return null in lookup_or_create_module_kobject() if module_kset is null.
> > Existing callers handle null already.
> >
> > Fixes: f30c53a873d0 ("MODULES: add the module name for built in kernel drivers")
>
> This isn't a bugfix.
I'll drop it in the next version.
> > 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>
> > ---
> > This bug is triggered by the next patch on arm64 defconfig: tegra194-cbb tries
> > to register from a pure_initcall, and with the next patch adding mod_name, this
> > null deref is hit.
>
> So this isn't a bug, it's a "don't do that" type of thing :)
>
> > ---
> > kernel/params.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/kernel/params.c b/kernel/params.c
> > index 74d620bc2521..881c7328c059 100644
> > --- a/kernel/params.c
> > +++ b/kernel/params.c
> > @@ -752,6 +752,9 @@ lookup_or_create_module_kobject(const char *name)
> > struct kobject *kobj;
> > int err;
> >
> > + if (!module_kset)
> > + return NULL;
>
> Are you sure that making this change is going to be ok?
> mod_sysfs_init() should have been called first as the module has to be
> created before it can be looked up.
>
> As you are wanting "built in" drivers to show up here, you are going to
> beat the call to param_sysfs_init(), so don't do that. Make sure that
> the drivers are NOT called before then.
The reason lookup_or_create_module_kobject() can be reached with module_kset == NULL
is that some platform drivers register before subsys_initcall: tegra194_cbb and
tegra234_cbb at pure_initcall, plus roughly 375 others at core_initcall/arch_initcall
(208 arch, 154 core, plus 2 pure and 13 _sync variants). These are dominated by
pinctrl, clk, interconnect, gpio, and mailbox drivers across six SoC vendor trees
(Qualcomm, MediaTek, Freescale, Samsung, Tegra, HiSilicon).
Given that, three ways forward:
1. Move module_kset creation out of param_sysfs_init() (currently
subsys_initcall) and call it directly from do_basic_setup()
before do_initcalls(). This is the cleanest fix from a
correctness angle: every initcall level sees a live
module_kset. But it touches init/main.c and kernel/params.c,
crosses two subsystem trees. I haven't fully audited
dependencies at do_basic_setup() time.
2. Demote the ~377 early-initcall platform drivers to
subsys_initcall or later. Impractical at scale given coordination
across six vendor trees, and many of these levels seem to be
architecturally required.
3. (This patch) Guard lookup_or_create_module_kobject() against
NULL module_kset. Drivers registered before subsys_initcall
don't get the /sys/.../module symlink, but they don't get it
today either (drv->mod_name is NULL pre-patch, so the
else-if (drv->mod_name) branch in module_add_driver() isn't
taken). Verified on arm64: /sys/module/tegra194_cbb/ does not
exist on a booted defconfig with or without my series. The
guard preserves that exact state while letting the
device_initcall majority get their symlinks as designed.
I went with option 3 because it preserves observable behaviour
everywhere and keeps the series scoped to driver-core. If you'd
rather I do option 1 instead, I'm happy to.
Thanks,
Shashank
^ permalink raw reply
* Re: [PATCH 2/4] kselftest/arm64: Add POE as a feature in the signal tests
From: Mark Brown @ 2026-04-21 14:58 UTC (permalink / raw)
To: Kevin Brodsky
Cc: linux-arm-kernel, linux-kernel, Catalin Marinas, Joey Gouly,
Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-3-kevin.brodsky@arm.com>
[-- Attachment #1: Type: text/plain, Size: 194 bytes --]
On Tue, Apr 21, 2026 at 03:42:50PM +0100, Kevin Brodsky wrote:
> Add the POE feature to the signal tests framework, to allow tests to
> require it.
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: power: Add power-domains-child-ids property
From: Kevin Hilman @ 2026-04-21 14:57 UTC (permalink / raw)
To: Rob Herring
Cc: Ulf Hansson, Geert Uytterhoeven, linux-pm, devicetree,
linux-kernel, arm-scmi, linux-arm-kernel
In-Reply-To: <20260421134949.GA1045294-robh@kernel.org>
Rob Herring <robh@kernel.org> writes:
> On Mon, Apr 20, 2026 at 04:51:17PM -0700, Kevin Hilman (TI) wrote:
>> Add binding documentation for the new power-domains-child-ids property,
>> which works in conjunction with the existing power-domains property to
>> establish parent-child relationships between a multi-domain power domain
>> provider and external parent domains.
>>
>> Each element in the uint32 array identifies the child domain
>> ID (index) within the provider that should be made a child domain of
>> the corresponding phandle entry in power-domains. The two arrays must
>> have the same number of elements.
>>
>> Signed-off-by: Kevin Hilman (TI) <khilman@baylibre.com>
>
> Missing my Reviewed-by.
Oops, I thought I had grabbed it with b4, but I didn't. Sorry.
Kevin
^ permalink raw reply
* Re: [PATCH v2 2/3] pwm: rp1: Add RP1 PWM controller driver
From: Uwe Kleine-König @ 2026-04-21 14:50 UTC (permalink / raw)
To: Andrea della Porta
Cc: 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, mbrugger
In-Reply-To: <aeZUAaQkHGqBL8st@apocalypse>
[-- Attachment #1: Type: text/plain, Size: 3719 bytes --]
Hello Andrea,
On Mon, Apr 20, 2026 at 06:27:45PM +0200, Andrea della Porta wrote:
> On 12:50 Fri 17 Apr , Uwe Kleine-König wrote:
> > What happens if sync is asserted while a disabled channel didn't
> > complete the last period yet?
>
> The output stops immediately without waiting for the current period to finish.
This is a good info for the Limitations block.
> > Maybe it's worth to test the following procedure for updating duty and
> > period:
> >
> > disable channel
> > configure duty
> > configure period
> > enable
> > set update flag
> >
> > Assumint disable is delayed until the end of the currently running
> > period, the effect of this procedure might be that no glitch happens if
> > the update flag is asserted before the currently running period ends and
> > the anormality is reduced to a longer inactive state if the updates are
> > not that lucky (in contrast to more severe glitches).
>
> The disable isn't delayed as explained above. Setting just the new period/duty
> (which do not depend on the sync bit) correctly waits for the end of the current
> period without noticeable glitches (tested with a scope).
So if you happen to change both and one is done before the end of the
current period and the other shortly afterwards (which might happen as
those are configured in two different registers and the update trigger
isn't used), you get a mixed output for one cycle, right? If yes, please
also mention that in the Limitations paragraph.
> > > Let's say that teh user want 10 tick period, we have to use
> > > 9 instead to account for the extra tick at the end, so that the complete period
> > > contains that extra tick?
> >
> > I would describe that a bit differently, but in general: yes.
> >
> > The more straight forward description is that setting
> >
> > RP1_PWM_RANGE(pwm->hwpwm) := x
> >
> > results in a period of x + 1 ticks.
>
> Exactly. So whatever the user request I have to subtract one from the value
> to be written to the RANGE register.
Unless the calculation is already rounded to 0, in that case don't
subtract 1 and let the tohw callback return 1.
> > > This also means that if we ask for 100% duty cycle, the output waveform will
> > > have the high part of the signal lasting one tick less than expected.a I guess
> > > this is the accepted compromise.
> >
> > I assume you considered something like:
> >
> > RP1_PWM_RANGE(pwm->hwpwm) := 17
> > RP1_PWM_DUTY(pwm->hwpwm) := 18
> >
> > to get a 100% relative duty?
>
> Ah right! It's working fine and I've got 100% duty. So at hw register level
> the duty can be greater that the period.
In that case please make sure to not use the maximal value for
RP1_PWM_RANGE(pwm->hwpwm) to ensure that for each (possible) period
length a 100% relative duty cycle can be configured.
> > My (not so well articulated) point is: Please be stringent about clock
> > handling to not bank up technical dept more than necessary and such that
> > the driver can be made unbindable if and when syscons grow
> > that feature. Optionally wail at the syscon guys :-)
>
> Hmmm not sure I've understood your point: is it a requirement that the driver
> must be unbindable? In this case I should avoid registering the syscon. Or
> should I just provide a .remove callback in case there will be a way to
> unregister the syscon (even if this callback will not be called as of now)?
It's a requirement to properly manage the resources you allocate. If a
driver isn't unbindable due to restrictions of other subsystems that's
unfortunate and I don't like it, but I wouldn't block a patch because of
that.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: add tqma9596la-mba95xxca
From: Daniel Baluta @ 2026-04-21 14:48 UTC (permalink / raw)
To: Alexander Stein, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Markus Niebel, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260326111803.1248934-2-alexander.stein@ew.tq-group.com>
[..]
> +
> + reserved-memory {
> + #address-cells = <2>;
> + #size-cells = <2>;
> + ranges;
> +
> + linux_cma: linux,cma {
> + compatible = "shared-dma-pool";
> + reusable;
> + size = <0 0x28000000>;
> + alloc-ranges = <0 0x80000000 0 0x80000000>;
> + linux,cma-default;
> + };
> +
> + vpu_boot: vpu_boot@a0000000 {
Should this be memory@a0000000 ?
^ permalink raw reply
* [PATCH 4/4] kselftest/arm64: Add tests for POR_EL0 save/reset/restore
From: Kevin Brodsky @ 2026-04-21 14:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Kevin Brodsky, Catalin Marinas, Joey Gouly,
Mark Brown, Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-1-kevin.brodsky@arm.com>
POR_EL0 is expected to be:
- Saved in the poe_context record
- Reset to POR_EL0_INIT when invoking the signal handler
- Restored from poe_context when returning from the signal handler
Add a new test, poe_restore, to check that the save/reset/restore
mechanism is working as intended. See commit 2e8a1acea859 ("arm64:
signal: Improve POR_EL0 handling to avoid uaccess failures") for
more details.
This commit did not handle the case where poe_context is missing
correctly. This was recently fixed; add a new test,
poe_missing_poe_context, to check this case.
Note: td->pass is only set to true at the very end, as an unexpected
signal may occur in case of failure (especially in
poe_missing_poe_context if POR_EL0 is restored to an invalid value).
Failures are tracked with a global, failed_check.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
.../testcases/poe_missing_poe_context.c | 73 +++++++++++++++++++
.../arm64/signal/testcases/poe_restore.c | 64 ++++++++++++++++
2 files changed, 137 insertions(+)
create mode 100644 tools/testing/selftests/arm64/signal/testcases/poe_missing_poe_context.c
create mode 100644 tools/testing/selftests/arm64/signal/testcases/poe_restore.c
diff --git a/tools/testing/selftests/arm64/signal/testcases/poe_missing_poe_context.c b/tools/testing/selftests/arm64/signal/testcases/poe_missing_poe_context.c
new file mode 100644
index 000000000000..abab7400d9df
--- /dev/null
+++ b/tools/testing/selftests/arm64/signal/testcases/poe_missing_poe_context.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 Arm Ltd
+ *
+ * Verify that the POR_EL0 register is left untouched on sigreturn if the
+ * POE frame record is missing.
+ */
+
+#include <asm/sigcontext.h>
+
+#include "test_signals_utils.h"
+#include "testcases.h"
+
+#define POR_EL0_INIT 0x07ul
+#define POR_EL0_CUSTOM 0x77ul
+
+static bool failed_check;
+
+static bool modify_por_el0(struct tdescr *td)
+{
+ set_por_el0(POR_EL0_CUSTOM);
+
+ return true;
+}
+
+static int signal_remove_poe_context(struct tdescr *td, siginfo_t *si,
+ ucontext_t *uc)
+{
+ struct _aarch64_ctx *ctx = GET_UC_RESV_HEAD(uc);
+ struct _aarch64_ctx *poe_ctx_head;
+
+ poe_ctx_head = get_header(ctx, POE_MAGIC, sizeof(uc->uc_mcontext),
+ NULL);
+ if (!poe_ctx_head) {
+ fprintf(stderr, "Missing poe_context record\n");
+ failed_check = true;
+ return 0;
+ }
+
+ /*
+ * Actually removing the record would require moving down the next
+ * records. An easier option is to turn it into an ESR record, which is
+ * ignored by sigreturn().
+ */
+ poe_ctx_head->magic = ESR_MAGIC;
+
+ return 0;
+}
+
+static void check_por_el0_preserved(struct tdescr *td)
+{
+ uint64_t por_el0 = get_por_el0();
+
+ if (por_el0 == POR_EL0_INIT) {
+ fprintf(stderr, "POR_EL0 preserved\n");
+ } else {
+ fprintf(stderr, "POR_EL0 unexpectedly set to %lx\n", por_el0);
+ failed_check = true;
+ }
+
+ td->pass = !failed_check;
+}
+
+struct tdescr tde = {
+ .name = "POR_EL0 missing poe_context",
+ .descr = "Remove poe_context record and check POR_EL0 is preserved",
+ .feats_required = FEAT_POE,
+ .timeout = 3,
+ .sig_trig = SIGUSR1,
+ .init = modify_por_el0,
+ .run = signal_remove_poe_context,
+ .check_result = check_por_el0_preserved,
+};
diff --git a/tools/testing/selftests/arm64/signal/testcases/poe_restore.c b/tools/testing/selftests/arm64/signal/testcases/poe_restore.c
new file mode 100644
index 000000000000..9f9a61a4214d
--- /dev/null
+++ b/tools/testing/selftests/arm64/signal/testcases/poe_restore.c
@@ -0,0 +1,64 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2026 Arm Ltd
+ *
+ * Verify that the POR_EL0 register is saved and restored as expected on signal
+ * entry/return.
+ */
+
+#include <asm/sigcontext.h>
+
+#include "test_signals_utils.h"
+#include "testcases.h"
+
+#define POR_EL0_INIT 0x07ul
+#define POR_EL0_CUSTOM 0x77ul
+
+static bool failed_check;
+
+static bool modify_por_el0(struct tdescr *td)
+{
+ set_por_el0(POR_EL0_CUSTOM);
+
+ return true;
+}
+
+static int signal_check_por_el0_reset(struct tdescr *td, siginfo_t *si,
+ ucontext_t *uc)
+{
+ uint64_t signal_por_el0 = get_por_el0();
+
+ if (signal_por_el0 != POR_EL0_INIT) {
+ fprintf(stderr, "POR_EL0 is %lx in signal handler (expected %lx)\n",
+ signal_por_el0, POR_EL0_INIT);
+ failed_check = true;
+ }
+
+ return 0;
+}
+
+static void check_por_el0_restored(struct tdescr *td)
+{
+ uint64_t por_el0 = get_por_el0();
+
+ if (por_el0 == POR_EL0_CUSTOM) {
+ fprintf(stderr, "POR_EL0 restored\n");
+ } else {
+ fprintf(stderr, "POR_EL0 was %lx but is now %lx\n",
+ POR_EL0_CUSTOM, por_el0);
+ failed_check = true;
+ }
+
+ td->pass = !failed_check;
+}
+
+struct tdescr tde = {
+ .name = "POR_EL0 restore",
+ .descr = "Validate that POR_EL0 is saved/restored on signal entry/return",
+ .feats_required = FEAT_POE,
+ .timeout = 3,
+ .sig_trig = SIGUSR1,
+ .init = modify_por_el0,
+ .run = signal_check_por_el0_reset,
+ .check_result = check_por_el0_restored,
+};
--
2.51.2
^ permalink raw reply related
* [PATCH 2/4] kselftest/arm64: Add POE as a feature in the signal tests
From: Kevin Brodsky @ 2026-04-21 14:42 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Kevin Brodsky, Catalin Marinas, Joey Gouly,
Mark Brown, Shuah Khan, Will Deacon, linux-kselftest
In-Reply-To: <20260421144252.1440365-1-kevin.brodsky@arm.com>
Add the POE feature to the signal tests framework, to allow tests to
require it.
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
---
tools/testing/selftests/arm64/signal/test_signals.h | 2 ++
tools/testing/selftests/arm64/signal/test_signals_utils.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/tools/testing/selftests/arm64/signal/test_signals.h b/tools/testing/selftests/arm64/signal/test_signals.h
index ee75a2c25ce7..c7c343494cb8 100644
--- a/tools/testing/selftests/arm64/signal/test_signals.h
+++ b/tools/testing/selftests/arm64/signal/test_signals.h
@@ -36,6 +36,7 @@ enum {
FSME_FA64_BIT,
FSME2_BIT,
FGCS_BIT,
+ FPOE_BIT,
FMAX_END
};
@@ -45,6 +46,7 @@ enum {
#define FEAT_SME_FA64 (1UL << FSME_FA64_BIT)
#define FEAT_SME2 (1UL << FSME2_BIT)
#define FEAT_GCS (1UL << FGCS_BIT)
+#define FEAT_POE (1UL << FPOE_BIT)
/*
* A descriptor used to describe and configure a test case.
diff --git a/tools/testing/selftests/arm64/signal/test_signals_utils.c b/tools/testing/selftests/arm64/signal/test_signals_utils.c
index 5d3621921cfe..4b12dbd7669d 100644
--- a/tools/testing/selftests/arm64/signal/test_signals_utils.c
+++ b/tools/testing/selftests/arm64/signal/test_signals_utils.c
@@ -31,6 +31,7 @@ static char const *const feats_names[FMAX_END] = {
" FA64 ",
" SME2 ",
" GCS ",
+ " POE ",
};
#define MAX_FEATS_SZ 128
@@ -341,6 +342,8 @@ int test_init(struct tdescr *td)
td->feats_supported |= FEAT_SME2;
if (getauxval(AT_HWCAP) & HWCAP_GCS)
td->feats_supported |= FEAT_GCS;
+ if (getauxval(AT_HWCAP2) & HWCAP2_POE)
+ td->feats_supported |= FEAT_POE;
if (feats_ok(td)) {
if (td->feats_required & td->feats_supported)
fprintf(stderr,
--
2.51.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox