* Re: [PATCH v2 3/3] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Andrew Lunn @ 2026-04-30 14:06 UTC (permalink / raw)
To: Josua Mayer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Vladimir Oltean, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Yazan Shhady, Mikhail Anikin, Alexander Dahl,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
Vladimir Oltean, Conor Dooley, Krzysztof Kozlowski,
netdev@vger.kernel.org
In-Reply-To: <bd2e73c5-2e61-4ea1-ab3b-42a6573b31f8@solid-run.com>
> > Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> >
> > Andrew
>
> Thanks!
>
> I don't know how to keep this partial review for v3, so I will send it without.
You can add my Reviewed-by. It is on record in the archive that it
only applies to a subset.
And in general, nobody can know the whole kernel, all the different
subsystems, and the details for all the DT bindings. So i would allow
some fuzziness for Reviewed-by: for a DT patch.
Interesting, an Acked-by: might actually be more appropriate.
Acked-by: does not necessarily indicate acknowledgement of the
entire patch. For example, if a patch affects multiple subsystems
and has an Acked-by: from one subsystem maintainer then this
usually indicates acknowledgement of just the part which affects
that maintainer’s code. Judgement should be used here.
So how about:
Acked-by: Andrew Lunn <andrew@lunn.ch>
and you can take your pick :-)
Andrew
^ permalink raw reply
* Re: (subset) [PATCH v8 2/4] backlight: add max25014atg backlight
From: Lee Jones @ 2026-04-30 13:58 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Frank Li, Maud Spierings
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel
In-Reply-To: <20260407-max25014-v8-2-14eac7ed673a@gocontroll.com>
On Tue, 07 Apr 2026 16:41:43 +0200, Maud Spierings wrote:
> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> with integrated boost controller.
Applied, thanks!
[2/4] backlight: add max25014atg backlight
commit: 3014ad47cfaf454cb0bbee353272beacd1e7c4bc
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH v8 1/4] dt-bindings: backlight: Add max25014 support
From: Lee Jones @ 2026-04-30 13:53 UTC (permalink / raw)
To: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Frank Li, Maud Spierings
Cc: dri-devel, linux-leds, devicetree, linux-kernel, linux-fbdev, imx,
linux-arm-kernel
In-Reply-To: <20260407-max25014-v8-1-14eac7ed673a@gocontroll.com>
On Tue, 07 Apr 2026 16:41:42 +0200, Maud Spierings wrote:
> The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> with integrated boost controller.
Applied, thanks!
[1/4] dt-bindings: backlight: Add max25014 support
commit: 5fcbbedec9dfce78044eee922bf2030e1bd03faa
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v4 08/11] thermal: samsung: Add Exynos ACPM TMU driver GS101
From: Tudor Ambarus @ 2026-04-30 13:40 UTC (permalink / raw)
To: Alexey Klimov, Rafael J. Wysocki, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alim Akhtar, Bartlomiej Zolnierkiewicz,
Kees Cook, Gustavo A. R. Silva, Peter Griffin, André Draszik,
Daniel Lezcano, Sylwester Nawrocki, Chanwoo Choi,
Michael Turquette, Stephen Boyd, Lee Jones
Cc: willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening,
linux-clk, Krzysztof Kozlowski
In-Reply-To: <DI6IGZIW2HZ8.OBLZIORMOH2F@linaro.org>
On 4/30/26 4:07 PM, Alexey Klimov wrote:
>> +static struct platform_driver acpm_tmu_driver = {
>> + .driver = {
>> + .name = "gs-tmu",
> What "gs" stands for in the name?
:) Google Silicon I think.
> Shouldn't it be called something more acpm-ish generic like acpm-tmu
> at least?
yes, it should! will update.
Thanks!
ta
^ permalink raw reply
* Re: [PATCH v1 00/12] KVM Dirty-bit cleaning accelerator (HACDBS)
From: Leonardo Bras @ 2026-04-30 13:29 UTC (permalink / raw)
To: Marc Zyngier
Cc: Leonardo Bras, Catalin Marinas, Will Deacon, Oliver Upton,
Joey Gouly, Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki,
Len Brown, Saket Dumbre, Paolo Bonzini, Chengwen Feng,
Jonathan Cameron, Kees Cook, Mikołaj Lenczewski,
Ryan Roberts, Yang Shi, Thomas Huth, mrigendrachaubey,
Yeoreum Yun, Mark Brown, Kevin Brodsky, James Clark,
Ard Biesheuvel, Fuad Tabba, Raghavendra Rao Ananta,
Nathan Chancellor, Vincent Donnefort, Lorenzo Pieralisi,
Sascha Bischoff, Anshuman Khandual, Tian Zheng, Wei-Lin Chang,
linux-kernel, linux-arm-kernel, kvmarm, linux-acpi, acpica-devel,
kvm
In-Reply-To: <86bjf0zj2p.wl-maz@kernel.org>
On Thu, Apr 30, 2026 at 02:14:22PM +0100, Marc Zyngier wrote:
> On Thu, 30 Apr 2026 12:14:04 +0100,
> Leonardo Bras <leo.bras@arm.com> wrote:
>
> [...]
>
> I haven't had a chance to look at any of this yet, but just on these
> points:
>
> > b - checkpatch.pl keeps bothering me to add an entry in MAINTAINERS file,
> > and I like the idea of maintaining this. Is there any rule or
> > common sense on this? Should I add this entry, or should I leave it
> > in the arch/arm64/kvm/ general rule?
>
> No specific entry in MAINTAINERS required (or wanted). This falls into
> the normal KVM/arm64 maintenance. And don't worry, we know where to
> find you when it will come to fixing this stuff.
>
Got it
> > c - There are some trace_prink() I have left in the code, as they could
> > be helpful to check when HACDBS is not performing as well as it
> > should. Should I introduce a tracepoint instead? or just ignore it?
> > (it's triggered on HACDBS error, but as it falls back to software in
> > that case, it should not impact correctness, only performance).
>
> Debug infrastructure should be preferably *removed* altogether.
> trace_printk() is definitely a big no-no.
>
Will remove it then
> > d - In __kvm_arch_dirty_log_clear() there is no way to predict how long
> > should be the buffer, so I used 1x PAGE_SIZE, and when it gets full
> > it's cleaned and reused. Should I let users configure that over a
> > parameter, or is it overthinking?
>
> How long is a piece of string? We can't know that. A single page feels
> very small in the 4kB case, and letting userspace define the size of
> that buffer seems a likely requirement.
>
Ok, as a KVM parameter, or as a compile-time option?
> >
> > Kernel v7.0.0 + this patchset builds properly, passing both kvm selftests
> > for dirty-bit tracking[2], on HW HACDBS enabled or disabled.
>
> I have absolutely no trust in these tests.
>
> Have you enabled a VMM to make use of these APIs, and actively
> migrated running guests? That's the level of testing I'd like to see,
> as the selftests are not what people run in production...
>
There is no enablement needed on VMM side.
Yes, I have created a VM on upstream qemu with --enable-kvm and migrated it
on the same host. (Inside a model)
That was the first test I used, but then I found out that kvm selftests
stress up multiple scenarios in an easier way.
Do you prefer me to test on any specific scenario, or does whatever qemu
uses as a default parameter work well enough?
Thanks!
Leo
^ permalink raw reply
* [PATCH] KVM: arm64: Handle permission faults with guest_memfd
From: Alexandru Elisei @ 2026-04-30 13:23 UTC (permalink / raw)
To: maz, oupton, joey.gouly, suzuki.poulose, yuzenghui,
linux-arm-kernel, kvmarm, tabba
Cc: mark.rutland
gmem_abort() calls kvm_pgtable_stage2_map() to make changes to stage 2. It
does this for both relaxing permissions on an existing mapping and to
install a missing mapping.
kvm_pgtable_stage2_map() doesn't make changes to stage 2 if there is an
existing, valid entry and the new entry modifies only the permissions.
This is checked in:
kvm_pgtable_stage2_map()
stage2_map_walk_leaf()
stage2_map_walker_try_leaf()
stage2_pte_needs_update()
and if only the permissions differ, kvm_pgtable_stage2_map() returns
-EAGAIN and KVM returns to the guest to replay the instruction. The
assumption is that a concurrent fault on a different VCPU already mapped
the faulting IPA, and replaying the instruction will either succeed, or
cause a permission fault, which should be handled with
kvm_pgtable_stage2_relax_perms().
gmem_abort(), on a read or write fault on a system without DIC (instruction
cache invalidation required for data to instruction coherence), installs a
valid entry with read and write permissions, but without executable
permissions. On an execution fault on the same page, gmem_abort() attempts
to relax the permissions to allow execution, but calls
kvm_pgtable_stage2_map() to change the existing, valid, entry.
kvm_pgtable_stage2_map() returns -EAGAIN and KVM resumes execution from the
faulting instruction, which leads to an infinite loop of permission faults
on the same instruction.
Allow the guest to make progress by using kvm_pgtable_stage2_relax_perms()
to relax permissions.
Fixes: a7b57e099592 ("KVM: arm64: Handle guest_memfd-backed guest page faults")
Signed-off-by: Alexandru Elisei <alexandru.elisei@arm.com>
---
Lightly tested on an Orion O6 board, without pkvm, and without nested
virtualisation.
Doesn't apply cleanly on top of a7b57e099592, I can send a patch for that if
needed.
arch/arm64/kvm/mmu.c | 24 +++++++++++++++++-------
1 file changed, 17 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index d089c107d9b7..dff58de7703b 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -1576,6 +1576,7 @@ struct kvm_s2_fault_desc {
static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
{
bool write_fault, exec_fault;
+ bool perm_fault = kvm_vcpu_trap_is_permission_fault(s2fd->vcpu);
enum kvm_pgtable_walk_flags flags = KVM_PGTABLE_WALK_SHARED;
enum kvm_pgtable_prot prot = KVM_PGTABLE_PROT_R;
struct kvm_pgtable *pgt = s2fd->vcpu->arch.hw_mmu->pgt;
@@ -1587,10 +1588,12 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
gfn_t gfn;
int ret;
- memcache = get_mmu_memcache(s2fd->vcpu);
- ret = topup_mmu_memcache(s2fd->vcpu, memcache);
- if (ret)
- return ret;
+ if (!perm_fault) {
+ memcache = get_mmu_memcache(s2fd->vcpu);
+ ret = topup_mmu_memcache(s2fd->vcpu, memcache);
+ if (ret)
+ return ret;
+ }
if (s2fd->nested)
gfn = kvm_s2_trans_output(s2fd->nested) >> PAGE_SHIFT;
@@ -1631,9 +1634,16 @@ static int gmem_abort(const struct kvm_s2_fault_desc *s2fd)
goto out_unlock;
}
- ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, s2fd->fault_ipa, PAGE_SIZE,
- __pfn_to_phys(pfn), prot,
- memcache, flags);
+ if (perm_fault) {
+ /* Preserve the software bits from the existing table entry. */
+ prot &= ~KVM_NV_GUEST_MAP_SZ;
+ ret = KVM_PGT_FN(kvm_pgtable_stage2_relax_perms(pgt, s2fd->fault_ipa,
+ prot, flags));
+ } else {
+ ret = KVM_PGT_FN(kvm_pgtable_stage2_map)(pgt, s2fd->fault_ipa, PAGE_SIZE,
+ __pfn_to_phys(pfn), prot,
+ memcache, flags);
+ }
out_unlock:
kvm_release_faultin_page(kvm, page, !!ret, prot & KVM_PGTABLE_PROT_W);
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v1 00/12] KVM Dirty-bit cleaning accelerator (HACDBS)
From: Marc Zyngier @ 2026-04-30 13:14 UTC (permalink / raw)
To: Leonardo Bras
Cc: Catalin Marinas, Will Deacon, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Rafael J. Wysocki, Len Brown,
Saket Dumbre, Paolo Bonzini, Chengwen Feng, Jonathan Cameron,
Kees Cook, Mikołaj Lenczewski, Ryan Roberts, Yang Shi,
Thomas Huth, mrigendrachaubey, Yeoreum Yun, Mark Brown,
Kevin Brodsky, James Clark, Ard Biesheuvel, Fuad Tabba,
Raghavendra Rao Ananta, Nathan Chancellor, Vincent Donnefort,
Lorenzo Pieralisi, Sascha Bischoff, Anshuman Khandual, Tian Zheng,
Wei-Lin Chang, linux-kernel, linux-arm-kernel, kvmarm, linux-acpi,
acpica-devel, kvm
In-Reply-To: <20260430111424.3479613-2-leo.bras@arm.com>
On Thu, 30 Apr 2026 12:14:04 +0100,
Leonardo Bras <leo.bras@arm.com> wrote:
[...]
I haven't had a chance to look at any of this yet, but just on these
points:
> b - checkpatch.pl keeps bothering me to add an entry in MAINTAINERS file,
> and I like the idea of maintaining this. Is there any rule or
> common sense on this? Should I add this entry, or should I leave it
> in the arch/arm64/kvm/ general rule?
No specific entry in MAINTAINERS required (or wanted). This falls into
the normal KVM/arm64 maintenance. And don't worry, we know where to
find you when it will come to fixing this stuff.
> c - There are some trace_prink() I have left in the code, as they could
> be helpful to check when HACDBS is not performing as well as it
> should. Should I introduce a tracepoint instead? or just ignore it?
> (it's triggered on HACDBS error, but as it falls back to software in
> that case, it should not impact correctness, only performance).
Debug infrastructure should be preferably *removed* altogether.
trace_printk() is definitely a big no-no.
> d - In __kvm_arch_dirty_log_clear() there is no way to predict how long
> should be the buffer, so I used 1x PAGE_SIZE, and when it gets full
> it's cleaned and reused. Should I let users configure that over a
> parameter, or is it overthinking?
How long is a piece of string? We can't know that. A single page feels
very small in the 4kB case, and letting userspace define the size of
that buffer seems a likely requirement.
>
> Kernel v7.0.0 + this patchset builds properly, passing both kvm selftests
> for dirty-bit tracking[2], on HW HACDBS enabled or disabled.
I have absolutely no trust in these tests.
Have you enabled a VMM to make use of these APIs, and actively
migrated running guests? That's the level of testing I'd like to see,
as the selftests are not what people run in production...
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v7 phy-next 17/27] phy: introduce phy_get_max_link_rate() helper for consumers
From: Vladimir Oltean @ 2026-04-30 13:14 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-phy, Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, Markus Schneider-Pargmann, Andrzej Hajda,
Robert Foss, Laurent Pinchart, Jonas Karlman, Jernej Skrabec,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Andy Yan, Marc Kleine-Budde, Vincent Mailhol,
Nicolas Ferre, Alexandre Belloni, Claudiu Beznea,
Geert Uytterhoeven, Magnus Damm
In-Reply-To: <CAMuHMdWbeeRmLf6Ae0Fr0un=-z7z5ONc_hDdjebP=KVkXHPbhw@mail.gmail.com>
On Thu, Apr 30, 2026 at 01:59:53PM +0200, Geert Uytterhoeven wrote:
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # rcar_canfd
Thanks.
> > --- a/include/linux/phy/phy.h
> > +++ b/include/linux/phy/phy.h
> > @@ -57,6 +57,7 @@ int phy_notify_disconnect(struct phy *phy, int port);
> > int phy_notify_state(struct phy *phy, union phy_notify state);
> > int phy_get_bus_width(struct phy *phy);
> > void phy_set_bus_width(struct phy *phy, int bus_width);
> > +u32 phy_get_max_link_rate(struct phy *phy);
>
> This (and all the existing getters) should take a "const struct phy *".
Yeah... Let's see what other review comments pop up (including Sashiko,
which would be seeing this series for the first time) and decide
afterwards whether to make the argument const for the new getters as
part of a separate set, or in v8.
I don't think that modifying the existing getters is in scope for this
27 patch set.
^ permalink raw reply
* Re: [PATCH v5 3/5] mfd: aaeon: Add SRG-IMX8P MCU driver
From: Lee Jones @ 2026-04-30 13:10 UTC (permalink / raw)
To: Thomas Perrot (Schneider Electric)
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Shawn Guo, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
Jérémie Dautheribes, Wim Van Sebroeck, Guenter Roeck,
devicetree, linux-kernel, linux-gpio, imx, linux-arm-kernel,
linux-watchdog, Thomas Petazzoni, Miquel Raynal
In-Reply-To: <20260408-dev-b4-aaeon-mcu-driver-v5-3-ad98bd481668@bootlin.com>
On Wed, 08 Apr 2026, Thomas Perrot (Schneider Electric) wrote:
> Add Multi-Function Device (MFD) driver for the Aaeon SRG-IMX8P
> embedded controller. This driver provides the core I2C communication
> interface and registers child devices (GPIO and watchdog controllers).
>
> The driver implements a custom regmap bus over I2C to match the MCU's
> fixed 3-byte command format [opcode, arg, value]. Register addresses
> are encoded as 16-bit values (opcode << 8 | arg) using the
> AAEON_MCU_REG() macro defined in the shared header. The regmap
> instance is shared with child drivers via dev_get_regmap(). Concurrent
> I2C accesses from child drivers are serialized by regmap's built-in
> locking.
>
> I2C transfers use heap-allocated DMA-safe buffers rather than
> stack-allocated ones, as required by I2C controllers that perform DMA.
>
> Regmap caching is enabled (REGCACHE_MAPLE) with a volatile_reg
> callback that marks GPIO input read registers (opcode 0x72) and the
> watchdog status register (opcode 0x63, arg 0x02) as volatile. All
> other registers written by the driver (GPIO direction,
> GPO state, watchdog control) are stable and can be safely cached.
>
> Co-developed-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Jérémie Dautheribes (Schneider Electric) <jeremie.dautheribes@bootlin.com>
> Signed-off-by: Thomas Perrot (Schneider Electric) <thomas.perrot@bootlin.com>
> ---
> MAINTAINERS | 2 +
> drivers/mfd/Kconfig | 10 +++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/aaeon-mcu.c | 204 ++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/aaeon-mcu.h | 40 +++++++++
> 5 files changed, 257 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index ea9d55f76f35..f91b6a1826d0 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -191,6 +191,8 @@ M: Thomas Perrot <thomas.perrot@bootlin.com>
> R: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> S: Maintained
> F: Documentation/devicetree/bindings/mfd/aaeon,srg-imx8p-mcu.yaml
> +F: drivers/mfd/aaeon-mcu.c
> +F: include/linux/mfd/aaeon-mcu.h
>
> AAEON UPBOARD FPGA MFD DRIVER
> M: Thomas Richard <thomas.richard@bootlin.com>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index aace5766b38a..82ec1d8e7224 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1561,6 +1561,16 @@ config ABX500_CORE
> remain unchanged when IC changes. Binding of the functions to
> actual register access is done by the IC core driver.
>
> +config MFD_AAEON_MCU
> + tristate "Aaeon SRG-IMX8P MCU Driver"
> + depends on I2C || COMPILE_TEST
> + select MFD_CORE
> + help
> + Select this option to enable support for the Aaeon SRG-IMX8P
> + onboard microcontroller (MCU). This driver provides the core
> + functionality to communicate with the MCU over I2C. The MCU
> + provides GPIO and watchdog functionality.
> +
> config AB8500_CORE
> bool "ST-Ericsson AB8500 Mixed Signal Power Management chip"
> depends on ABX500_CORE && MFD_DB8500_PRCMU
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index e75e8045c28a..34db5b033584 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -8,6 +8,7 @@ obj-$(CONFIG_MFD_88PM860X) += 88pm860x.o
> obj-$(CONFIG_MFD_88PM800) += 88pm800.o 88pm80x.o
> obj-$(CONFIG_MFD_88PM805) += 88pm805.o 88pm80x.o
> obj-$(CONFIG_MFD_88PM886_PMIC) += 88pm886.o
> +obj-$(CONFIG_MFD_AAEON_MCU) += aaeon-mcu.o
> obj-$(CONFIG_MFD_ACT8945A) += act8945a.o
> obj-$(CONFIG_MFD_SM501) += sm501.o
> obj-$(CONFIG_ARCH_BCM2835) += bcm2835-pm.o
> diff --git a/drivers/mfd/aaeon-mcu.c b/drivers/mfd/aaeon-mcu.c
> new file mode 100644
> index 000000000000..3b4e2d891534
> --- /dev/null
> +++ b/drivers/mfd/aaeon-mcu.c
> @@ -0,0 +1,204 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Aaeon MCU driver
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#include <linux/err.h>
> +#include <linux/i2c.h>
> +#include <linux/mfd/aaeon-mcu.h>
> +#include <linux/mfd/core.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <linux/slab.h>
> +
> +struct aaeon_mcu {
> + struct i2c_client *client;
> + u8 *cmd; /* DMA-safe 3-byte write buffer [opcode, arg, value] */
> + u8 *response; /* DMA-safe 1-byte read buffer for MCU acknowledgment */
> +};
> +
> +static const struct mfd_cell aaeon_mcu_devs[] = {
> + MFD_CELL_BASIC("aaeon-mcu-wdt", NULL, NULL, 0, 0),
> + MFD_CELL_BASIC("aaeon-mcu-gpio", NULL, NULL, 0, 0),
> +};
> +
> +/* Number of bytes in a MCU command: [opcode, arg, value] */
> +#define AAEON_MCU_CMD_LEN 3
> +
> +/*
> + * Custom regmap bus for the Aaeon MCU I2C protocol.
> + *
> + * The MCU uses a fixed 3-byte command format [opcode, arg, value] followed
> + * by a 1-byte response. It requires a STOP condition between the command
> + * write and the response read, so two separate i2c_transfer() calls are
> + * issued. The regmap lock serialises concurrent accesses from the GPIO
> + * and watchdog child drivers.
> + *
> + * Register addresses are encoded as a 16-bit big-endian value where the
> + * high byte is the opcode and the low byte is the argument, matching the
> + * wire layout produced by regmap for reg_bits=16.
> + */
> +
> +static int aaeon_mcu_regmap_write(void *context, const void *data, size_t count)
> +{
> + struct aaeon_mcu *mcu = context;
> + struct i2c_client *client = mcu->client;
> + struct i2c_msg write_msg;
> + /* The MCU always sends a response byte after each command; discard it. */
> + struct i2c_msg response_msg;
> + int ret;
> +
> + memcpy(mcu->cmd, data, count);
> +
> + write_msg.addr = client->addr;
> + write_msg.flags = 0;
> + write_msg.buf = mcu->cmd;
> + write_msg.len = count;
> +
> + response_msg.addr = client->addr;
> + response_msg.flags = I2C_M_RD;
> + response_msg.buf = mcu->response;
> + response_msg.len = 1;
> +
> + ret = i2c_transfer(client->adapter, &write_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + ret = i2c_transfer(client->adapter, &response_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static int aaeon_mcu_regmap_read(void *context, const void *reg_buf,
> + size_t reg_size, void *val_buf, size_t val_size)
> +{
> + struct aaeon_mcu *mcu = context;
> + struct i2c_client *client = mcu->client;
> + struct i2c_msg write_msg;
> + struct i2c_msg read_msg;
> + int ret;
> +
> + /*
> + * reg_buf holds the 2-byte big-endian register address [opcode, arg].
> + * Append a trailing 0x00 to form the full 3-byte MCU command.
> + */
> + mcu->cmd[0] = ((u8 *)reg_buf)[0];
> + mcu->cmd[1] = ((u8 *)reg_buf)[1];
> + mcu->cmd[2] = 0x00;
> +
> + write_msg.addr = client->addr;
> + write_msg.flags = 0;
> + write_msg.buf = mcu->cmd;
> + write_msg.len = AAEON_MCU_CMD_LEN;
> +
> + read_msg.addr = client->addr;
> + read_msg.flags = I2C_M_RD;
> + read_msg.buf = val_buf;
> + read_msg.len = val_size;
> +
> + ret = i2c_transfer(client->adapter, &write_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + ret = i2c_transfer(client->adapter, &read_msg, 1);
> + if (ret < 0)
> + return ret;
> + if (ret != 1)
> + return -EIO;
> +
> + return 0;
> +}
> +
> +static const struct regmap_bus aaeon_mcu_regmap_bus = {
> + .write = aaeon_mcu_regmap_write,
> + .read = aaeon_mcu_regmap_read,
> +};
> +
> +static bool aaeon_mcu_volatile_reg(struct device *dev, unsigned int reg)
> +{
> + /*
> + * GPIO input registers are driven by external signals and can change
> + * at any time without CPU involvement, always read from hardware.
> + *
> + * The watchdog status register reflects hardware state and can change
> + * autonomously.
> + *
> + * All other registers are written by the driver and their values are
> + * stable, so they can be safely cached.
> + */
> + if ((reg >> 8) == AAEON_MCU_READ_GPIO_OPCODE)
> + return true;
> + if (reg == AAEON_MCU_REG(AAEON_MCU_CONTROL_WDT_OPCODE, 0x02))
> + return true;
> + return false;
> +}
> +
> +static const struct regmap_config aaeon_mcu_regmap_config = {
> + .reg_bits = 16,
> + .val_bits = 8,
> + .reg_format_endian = REGMAP_ENDIAN_BIG,
> + .max_register = AAEON_MCU_MAX_REGISTER,
> + .volatile_reg = aaeon_mcu_volatile_reg,
> + .cache_type = REGCACHE_MAPLE,
> +};
> +
> +static int aaeon_mcu_probe(struct i2c_client *client)
> +{
> + struct aaeon_mcu *mcu;
Nit: We usually call this ddata, but it's not a blocker.
> + struct regmap *regmap;
> +
> + mcu = devm_kzalloc(&client->dev, sizeof(*mcu), GFP_KERNEL);
> + if (!mcu)
> + return -ENOMEM;
> +
> + mcu->client = client;
> +
> + mcu->cmd = devm_kzalloc(&client->dev, AAEON_MCU_CMD_LEN * sizeof(*mcu->cmd), GFP_KERNEL);
> + if (!mcu->cmd)
> + return -ENOMEM;
> +
> + mcu->response = devm_kzalloc(&client->dev, sizeof(*mcu->response), GFP_KERNEL);
> + if (!mcu->response)
> + return -ENOMEM;
> +
> + regmap = devm_regmap_init(&client->dev, &aaeon_mcu_regmap_bus,
> + mcu, &aaeon_mcu_regmap_config);
> + if (IS_ERR(regmap))
> + return dev_err_probe(&client->dev, PTR_ERR(regmap),
> + "failed to initialize regmap\n");
> +
> + return devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
> + aaeon_mcu_devs, ARRAY_SIZE(aaeon_mcu_devs),
> + NULL, 0, NULL);
> +}
> +
> +static const struct of_device_id aaeon_mcu_of_match[] = {
> + { .compatible = "aaeon,srg-imx8p-mcu" },
> + {},
> +};
> +MODULE_DEVICE_TABLE(of, aaeon_mcu_of_match);
> +
> +static struct i2c_driver aaeon_mcu_driver = {
> + .driver = {
> + .name = "aaeon_mcu",
Nit: This should be a '-'.
> + .of_match_table = aaeon_mcu_of_match,
> + },
> + .probe = aaeon_mcu_probe,
> +};
> +module_i2c_driver(aaeon_mcu_driver);
> +
> +MODULE_DESCRIPTION("Aaeon MCU Driver");
> +MODULE_AUTHOR("Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/mfd/aaeon-mcu.h b/include/linux/mfd/aaeon-mcu.h
> new file mode 100644
> index 000000000000..3a1aeec85d60
> --- /dev/null
> +++ b/include/linux/mfd/aaeon-mcu.h
> @@ -0,0 +1,40 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Aaeon MCU driver definitions
> + *
> + * Copyright (C) 2026 Bootlin
> + * Author: Jérémie Dautheribes <jeremie.dautheribes@bootlin.com>
> + * Author: Thomas Perrot <thomas.perrot@bootlin.com>
> + */
> +
> +#ifndef __LINUX_MFD_AAEON_MCU_H
> +#define __LINUX_MFD_AAEON_MCU_H
> +
> +/*
> + * MCU register address: the high byte is the command opcode, the low
> + * byte is the argument. This matches the 3-byte wire format
> + * [opcode, arg, value] used by the MCU I2C protocol.
> + */
> +#define AAEON_MCU_REG(op, arg) (((op) << 8) | (arg))
> +
> +/*
> + * Opcode for GPIO input reads. These registers are volatile, their values
> + * are driven by external signals and can change without CPU involvement.
> + * Used by the MFD driver's volatile_reg callback to bypass the regmap cache.
> + */
> +#define AAEON_MCU_READ_GPIO_OPCODE 0x72
> +
> +/*
> + * Opcode for watchdog control and status commands.
> + * The status register (arg=0x02) reflects hardware state and is volatile.
> + */
> +#define AAEON_MCU_CONTROL_WDT_OPCODE 0x63
> +
> +/*
> + * Highest register address in the MCU register map.
> + * The WRITE_GPIO opcode (0x77) with the highest GPIO argument (0x0B = 11,
> + * i.e. MAX_GPIOS - 1) produces the largest encoded address.
> + */
> +#define AAEON_MCU_MAX_REGISTER AAEON_MCU_REG(0x77, 0x0B)
> +
> +#endif /* __LINUX_MFD_AAEON_MCU_H */
>
> --
> 2.53.0
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v4 08/11] thermal: samsung: Add Exynos ACPM TMU driver GS101
From: Alexey Klimov @ 2026-04-30 13:07 UTC (permalink / raw)
To: Tudor Ambarus, Rafael J. Wysocki, Zhang Rui, Lukasz Luba,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Krzysztof Kozlowski, Alim Akhtar, Bartlomiej Zolnierkiewicz,
Kees Cook, Gustavo A. R. Silva, Peter Griffin, André Draszik,
Daniel Lezcano, Sylwester Nawrocki, Chanwoo Choi,
Michael Turquette, Stephen Boyd, Lee Jones
Cc: willmcvicker, jyescas, shin.son, linux-samsung-soc, linux-kernel,
linux-pm, devicetree, linux-arm-kernel, linux-hardening,
linux-clk, Krzysztof Kozlowski
In-Reply-To: <20260423-acpm-tmu-v4-8-8b59f8548634@linaro.org>
On Thu Apr 23, 2026 at 4:22 PM BST, Tudor Ambarus wrote:
> Add driver for the Thermal Management Unit (TMU) managed via the Alive
> Clock and Power Manager (ACPM), found on Samsung Exynos SoCs such as
> Google GS101 (and Exynos850, autov920, etc.).
>
> The TMU on utilizes a hybrid management model shared between the
> Application Processor (AP) and the ACPM firmware. The driver maintains
> direct memory-mapped access to the TMU interrupt pending registers to
> identify thermal events, while delegating functional tasks - such as
> sensor initialization, threshold configuration, and temperature
> acquisition - to the ACPM firmware via the ACPM IPC protocol.
>
> Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> drivers/thermal/samsung/Kconfig | 17 ++
> drivers/thermal/samsung/Makefile | 2 +
> drivers/thermal/samsung/acpm-tmu.c | 547 +++++++++++++++++++++++++++++++++++++
> 3 files changed, 566 insertions(+)
[...]
> +static struct platform_driver acpm_tmu_driver = {
> + .driver = {
> + .name = "gs-tmu",
What "gs" stands for in the name?
Shouldn't it be called something more acpm-ish generic like acpm-tmu
at least?
Best regards,
Alexey
^ permalink raw reply
* [PATCH v3] arm64: dts: ti: am62-phyboard-lyra: Add DT overlay for Lincoln LCD185-101CT panel
From: Wadim Egorov @ 2026-04-30 13:01 UTC (permalink / raw)
To: nm, vigneshr, kristo, robh, krzk+dt, conor+dt
Cc: linux-arm-kernel, devicetree, linux-kernel, upstream
The panel is a Lincoln Technology Solutions LCD185-101CT [0]. It is
a dual-link LVDS panel and supports WUXGA resolution (1920x1200).
Furthermore, it has an I2C based touch controller: Goodix-GT928.
Add an device tree overlay to support the Lincoln LCD185-101CT panel
in combination with the phyBOARD-Lyra-AM62x.
[0] https://lincolntechsolutions.com/wp-content/uploads/2024/09/LCD185-101CTL1ARNTT_DS_R1.3.pdf
Signed-off-by: Wadim Egorov <w.egorov@phytec.de>
---
I somehow managed to send out 2 v2s. And the last one came from an
internal tree which was tested on older Kernel. Sorry for that.
v1: https://lists.infradead.org/pipermail/linux-arm-kernel/2025-September/1065767.html
v2: https://lkml.org/lkml/2025/9/25/644 / https://www.spinics.net/lists/kernel/msg6075571.html
v3:
- Fixed all schema warnings
- Updated properties order in nodes
---
arch/arm64/boot/dts/ti/Makefile | 4 +
.../ti/k3-am62-phyboard-lyra-oldi-lcd185.dtso | 185 ++++++++++++++++++
2 files changed, 189 insertions(+)
create mode 100644 arch/arm64/boot/dts/ti/k3-am62-phyboard-lyra-oldi-lcd185.dtso
diff --git a/arch/arm64/boot/dts/ti/Makefile b/arch/arm64/boot/dts/ti/Makefile
index 5269c9619b65..6aaa4a2a7561 100644
--- a/arch/arm64/boot/dts/ti/Makefile
+++ b/arch/arm64/boot/dts/ti/Makefile
@@ -29,6 +29,7 @@ dtb-$(CONFIG_ARCH_K3) += k3-am625-verdin-wifi-zinnia.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am62x-phyboard-lyra-gpio-fan.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am62-lp-sk.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am62-lp-sk-nand.dtbo
+dtb-$(CONFIG_ARCH_K3) += k3-am62-phyboard-lyra-oldi-lcd185.dtbo
dtb-$(CONFIG_ARCH_K3) += k3-am62-pocketbeagle2.dtb
dtb-$(CONFIG_ARCH_K3) += k3-am6254atl-sk.dtb
@@ -183,6 +184,8 @@ k3-am625-phyboard-lyra-disable-spi-nor-dtbs := k3-am625-phyboard-lyra-rdk.dtb \
k3-am6xx-phycore-disable-spi-nor.dtbo
k3-am625-phyboard-lyra-gpio-fan-dtbs := k3-am625-phyboard-lyra-rdk.dtb \
k3-am62x-phyboard-lyra-gpio-fan.dtbo
+k3-am625-phyboard-lyra-oldi-lcd185-dtbs := k3-am625-phyboard-lyra-rdk.dtb \
+ k3-am62-phyboard-lyra-oldi-lcd185.dtbo
k3-am625-phyboard-lyra-qspi-nor-dtbs := k3-am625-phyboard-lyra-rdk.dtb \
k3-am6xx-phycore-qspi-nor.dtbo
k3-am625-sk-csi2-imx219-dtbs := k3-am625-sk.dtb \
@@ -287,6 +290,7 @@ dtb- += k3-am625-beagleplay-csi2-ov5640.dtb \
k3-am625-phyboard-lyra-disable-rtc.dtb \
k3-am625-phyboard-lyra-disable-spi-nor.dtb \
k3-am625-phyboard-lyra-gpio-fan.dtb \
+ k3-am625-phyboard-lyra-oldi-lcd185.dtb \
k3-am625-phyboard-lyra-qspi-nor.dtb \
k3-am625-sk-csi2-imx219.dtb \
k3-am625-sk-csi2-ov5640.dtb \
diff --git a/arch/arm64/boot/dts/ti/k3-am62-phyboard-lyra-oldi-lcd185.dtso b/arch/arm64/boot/dts/ti/k3-am62-phyboard-lyra-oldi-lcd185.dtso
new file mode 100644
index 000000000000..ec1187d3b845
--- /dev/null
+++ b/arch/arm64/boot/dts/ti/k3-am62-phyboard-lyra-oldi-lcd185.dtso
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0-only OR MIT
+/*
+ * Copyright (C) 2022-2026 PHYTEC Messtechnik GmbH
+ * Author: Wadim Egorov <w.egorov@phytec.de>
+ */
+
+/dts-v1/;
+/plugin/;
+
+#include <dt-bindings/pwm/pwm.h>
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/interrupt-controller/irq.h>
+#include "k3-pinctrl.h"
+
+&{/} {
+ display {
+ compatible = "lincolntech,lcd185-101ct";
+ backlight = <&backlight>;
+ power-supply = <&vdd_usb_5v0>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+ lcd_in0: endpoint {
+ remote-endpoint = <&oldi_0_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+ lcd_in1: endpoint {
+ remote-endpoint = <&oldi_1_out>;
+ };
+ };
+ };
+ };
+
+ backlight: backlight {
+ compatible = "pwm-backlight";
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <6>;
+ enable-gpios = <&gpio_exp 5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bl_pwm_pins_default>;
+ pwms = <&epwm0 1 50000 0>;
+ };
+
+ vdd_usb_5v0: regulator-vdd-usb5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd-usb5v0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <&main_oldi0_pins_default &main_dss0_pins_default>;
+};
+
+&dss_ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* VP1: Output to OLDI */
+ port@0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dpi0_out0: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&oldi_0_in>;
+ };
+
+ dpi0_out1: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&oldi_1_in>;
+ };
+ };
+};
+
+&epwm0 {
+ status = "okay";
+};
+
+&main_i2c1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ touchscreen@5d {
+ compatible = "goodix,gt928";
+ reg = <0x5d>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&touch_screen_pins_default>;
+
+ interrupt-parent = <&main_gpio0>;
+ interrupts = <19 IRQ_TYPE_LEVEL_LOW>;
+
+ reset-gpios = <&main_gpio0 18 GPIO_ACTIVE_HIGH>;
+ irq-gpios = <&main_gpio0 19 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&main_pmx0 {
+ bl_pwm_pins_default: bl-pwm-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x01b8, PIN_INPUT, 2) /* (C13) SPI0_CS1.EHRPWM0_B */
+ >;
+ };
+
+ touch_screen_pins_default: touch-screen-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x048, PIN_OUTPUT, 7) /* (N25) GPMC0_AD3.GPIO0_18 - RST */
+ AM62X_IOPAD(0x04c, PIN_INPUT, 7) /* (P24) GPMC0_AD4.GPIO0_19 - INT */
+ >;
+ };
+
+ main_oldi0_pins_default: main-oldi0-default-pins {
+ pinctrl-single,pins = <
+ AM62X_IOPAD(0x0260, PIN_OUTPUT, 0) /* (AA5) OLDI0_A0N */
+ AM62X_IOPAD(0x025c, PIN_OUTPUT, 0) /* (Y6) OLDI0_A0P */
+ AM62X_IOPAD(0x0268, PIN_OUTPUT, 0) /* (AD3) OLDI0_A1N */
+ AM62X_IOPAD(0x0264, PIN_OUTPUT, 0) /* (AB4) OLDI0_A1P */
+ AM62X_IOPAD(0x0270, PIN_OUTPUT, 0) /* (Y8) OLDI0_A2N */
+ AM62X_IOPAD(0x026c, PIN_OUTPUT, 0) /* (AA8) OLDI0_A2P */
+ AM62X_IOPAD(0x0278, PIN_OUTPUT, 0) /* (AB6) OLDI0_A3N */
+ AM62X_IOPAD(0x0274, PIN_OUTPUT, 0) /* (AA7) OLDI0_A3P */
+ AM62X_IOPAD(0x0280, PIN_OUTPUT, 0) /* (AC6) OLDI0_A4N */
+ AM62X_IOPAD(0x027c, PIN_OUTPUT, 0) /* (AC5) OLDI0_A4P */
+ AM62X_IOPAD(0x0288, PIN_OUTPUT, 0) /* (AE5) OLDI0_A5N */
+ AM62X_IOPAD(0x0284, PIN_OUTPUT, 0) /* (AD6) OLDI0_A5P */
+ AM62X_IOPAD(0x0290, PIN_OUTPUT, 0) /* (AE6) OLDI0_A6N */
+ AM62X_IOPAD(0x028c, PIN_OUTPUT, 0) /* (AD7) OLDI0_A6P */
+ AM62X_IOPAD(0x0298, PIN_OUTPUT, 0) /* (AD8) OLDI0_A7N */
+ AM62X_IOPAD(0x0294, PIN_OUTPUT, 0) /* (AE7) OLDI0_A7P */
+ AM62X_IOPAD(0x02a0, PIN_OUTPUT, 0) /* (AD4) OLDI0_CLK0N */
+ AM62X_IOPAD(0x029c, PIN_OUTPUT, 0) /* (AE3) OLDI0_CLK0P */
+ AM62X_IOPAD(0x02a8, PIN_OUTPUT, 0) /* (AE4) OLDI0_CLK1N */
+ AM62X_IOPAD(0x02a4, PIN_OUTPUT, 0) /* (AD5) OLDI0_CLK1P */
+ >;
+ };
+};
+
+&oldi0 {
+ ti,companion-oldi = <&oldi1>;
+ status = "okay";
+};
+
+&oldi0_port0 {
+ oldi_0_in: endpoint {
+ remote-endpoint = <&dpi0_out0>;
+ };
+};
+
+&oldi0_port1 {
+ oldi_0_out: endpoint {
+ remote-endpoint = <&lcd_in0>;
+ };
+};
+
+&oldi1 {
+ ti,secondary-oldi;
+ status = "okay";
+};
+
+&oldi1_port0 {
+ oldi_1_in: endpoint {
+ remote-endpoint = <&dpi0_out1>;
+ };
+};
+
+&oldi1_port1 {
+ oldi_1_out: endpoint {
+ remote-endpoint = <&lcd_in1>;
+ };
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v3 2/4] ARM: pxa: spitz: attach software nodes to their target GPIO controllers
From: Bartosz Golaszewski @ 2026-04-30 12:57 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260430-pxa-gpio-swnodes-v3-0-5142e95f0eca@oss.qualcomm.com>
Software nodes describing the GPIO controllers for the spitz platform
are currently "dangling" - they're not actually attached to the relevant
controllers and don't allow real fwnode lookup. Attach them either by
directly assigning them to the struct device or by using the i2c board
info struct.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/spitz.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index 3284b9f62be970555042a7292993e45d56fde47e..5091b601c4e1bf25cfee07429881894929853dfe 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -204,11 +204,15 @@ static struct platform_device spitz_scoop_2_device = {
static void __init spitz_scoop_init(void)
{
+ spitz_scoop_1_device.dev.fwnode = software_node_fwnode(&spitz_scoop_1_gpiochip_node);
platform_device_register(&spitz_scoop_1_device);
/* Akita doesn't have the second SCOOP chip */
- if (!machine_is_akita())
+ if (!machine_is_akita()) {
+ spitz_scoop_2_device.dev.fwnode = software_node_fwnode(
+ &spitz_scoop_2_gpiochip_node);
platform_device_register(&spitz_scoop_2_device);
+ }
}
/* Power control is shared with between one of the CF slots and SD */
@@ -988,6 +992,7 @@ static struct i2c_board_info spitz_i2c_devs[] = {
.type = "max7310",
.addr = 0x18,
.platform_data = &akita_pca953x_pdata,
+ .swnode = &akita_max7310_gpiochip_node,
},
};
--
2.47.3
^ permalink raw reply related
* [PATCH v3 4/4] ARM: pxa: pxa27x: attach software node to its target GPIO controller
From: Bartosz Golaszewski @ 2026-04-30 12:57 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260430-pxa-gpio-swnodes-v3-0-5142e95f0eca@oss.qualcomm.com>
Software node describing the GPIO controller for the pxa27x platforms is
currently "dangling" - it's not actually attached to the relevant
controller and doesn't allow real fwnode lookup. Attach it once it's
registered as a firmware node before adding the platform device.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/pxa27x.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index ff63619790383859ba111e3efe7619aa6cbd248e..49c677f2dac156445447ebdd7a99f3463a762d20 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -342,6 +342,9 @@ static int __init pxa27x_init(void)
if (!of_have_populated_dt()) {
software_node_register(&pxa2xx_gpiochip_node);
+ pxa27x_device_gpio.dev.fwnode = software_node_fwnode(
+ &pxa2xx_gpiochip_node);
+
pxa2xx_set_dmac_info(&pxa27x_dma_pdata);
ret = platform_add_devices(devices,
ARRAY_SIZE(devices));
--
2.47.3
^ permalink raw reply related
* [PATCH v3 3/4] ARM: pxa: pxa25x: attach software node to its target GPIO controller
From: Bartosz Golaszewski @ 2026-04-30 12:57 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260430-pxa-gpio-swnodes-v3-0-5142e95f0eca@oss.qualcomm.com>
Software node describing the GPIO controller for the pxa25x platforms is
currently "dangling" - it's not actually attached to the relevant
controller and doesn't allow real fwnode lookup. Attach it once it's
registered as a firmware node before adding the platform device.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/pxa25x.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index 70509a5998142ec6b9c484e5f094751eda6db6cd..a4e878be004a09a6ee464c8f09e91be249a224b2 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -240,6 +240,9 @@ static int __init pxa25x_init(void)
if (!of_have_populated_dt()) {
software_node_register(&pxa2xx_gpiochip_node);
+ pxa25x_device_gpio.dev.fwnode = software_node_fwnode(
+ &pxa2xx_gpiochip_node);
+
pxa2xx_set_dmac_info(&pxa25x_dma_pdata);
ret = platform_add_devices(pxa25x_devices,
ARRAY_SIZE(pxa25x_devices));
--
2.47.3
^ permalink raw reply related
* [PATCH v3 1/4] ARM: pxa: statify platform device definitions in spitz board file
From: Bartosz Golaszewski @ 2026-04-30 12:57 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
In-Reply-To: <20260430-pxa-gpio-swnodes-v3-0-5142e95f0eca@oss.qualcomm.com>
The scoop devices are not used outside of this board file so make them
static.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
arch/arm/mach-pxa/spitz.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-pxa/spitz.c b/arch/arm/mach-pxa/spitz.c
index c0b1f7e6be87411359b0020257ff12c73bbcbae3..3284b9f62be970555042a7292993e45d56fde47e 100644
--- a/arch/arm/mach-pxa/spitz.c
+++ b/arch/arm/mach-pxa/spitz.c
@@ -165,7 +165,7 @@ static struct scoop_config spitz_scoop_1_setup = {
.gpio_base = SPITZ_SCP_GPIO_BASE,
};
-struct platform_device spitz_scoop_1_device = {
+static struct platform_device spitz_scoop_1_device = {
.name = "sharp-scoop",
.id = 0,
.dev = {
@@ -192,7 +192,7 @@ static struct scoop_config spitz_scoop_2_setup = {
.gpio_base = SPITZ_SCP2_GPIO_BASE,
};
-struct platform_device spitz_scoop_2_device = {
+static struct platform_device spitz_scoop_2_device = {
.name = "sharp-scoop",
.id = 1,
.dev = {
--
2.47.3
^ permalink raw reply related
* [PATCH v3 0/4] ARM: pxa: attach software nodes to the GPIO controllers
From: Bartosz Golaszewski @ 2026-04-30 12:57 UTC (permalink / raw)
To: Daniel Mack, Haojian Zhuang, Robert Jarzmik, Russell King,
Dmitry Torokhov, Arnd Bergmann, Linus Walleij
Cc: brgl, linux-arm-kernel, linux-gpio, linux-kernel,
Bartosz Golaszewski
Convert GPIO controllers and their consumers on the PXA platform to using
"attached" software nodes. Since everything happens in a bord-file, it's
quite straightforward. We technically now have a way of passing an
unregistered software node to platform_device_register_full() but that
requires using struct platform_device_info and since the existing
platform devices are either referenced from other places or defined in a
different compilation unit, I wanted to reduce the impact of the changes
I can't test and went with the older method.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
Changes in v3:
- Simplify patches 3/4 and 4/4 by leaving the devices in the existing
list and limiting the changes to the fwnode assignment
- Link to v2: https://patch.msgid.link/20260427-pxa-gpio-swnodes-v2-0-86fc24b9e714@oss.qualcomm.com
Changes in v2:
- Rebase on top of v7.1-rc1
- Add a patch making some platform device definitions static
- Link to v1: https://patch.msgid.link/20260331-pxa-gpio-swnodes-v1-0-f66d86d10d8d@oss.qualcomm.com
---
Bartosz Golaszewski (4):
ARM: pxa: statify platform device definitions in spitz board file
ARM: pxa: spitz: attach software nodes to their target GPIO controllers
ARM: pxa: pxa25x: attach software node to its target GPIO controller
ARM: pxa: pxa27x: attach software node to its target GPIO controller
arch/arm/mach-pxa/pxa25x.c | 3 +++
arch/arm/mach-pxa/pxa27x.c | 3 +++
arch/arm/mach-pxa/spitz.c | 11 ++++++++---
3 files changed, 14 insertions(+), 3 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260330-pxa-gpio-swnodes-132a81af10e3
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Beleswar Prasad Padhi @ 2026-04-30 12:56 UTC (permalink / raw)
To: Arnaud POULIQUEN, Mathieu Poirier
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <f7ef3417-eb84-4467-ac72-a9bc8b0c81e8@foss.st.com>
Hello Arnaud,
On 30/04/26 13:05, Arnaud POULIQUEN wrote:
> Hello,
>
> On 4/29/26 21:20, Mathieu Poirier wrote:
>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>
>>> Hi Mathieu,
>>>
>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-padhi@ti.com>; Linus
>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof Kozlowski
>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn Andersson
>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>> <s.hauer@pengutronix.de>; Shuah Khan <skhan@linuxfoundation.org>; linux-
>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org;
>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-linux-imx <linux-
>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>; Jonathan
>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>;
>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>> <brgl@bgdev.pl>
>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>> GPIO driver
>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>> __u8 status;
>>>>>>>>>> __u8 value;
>>>>>>>>>> };
>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>
>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same message format.
>>>>>>>>
>>>>>>> Some changes to the message format are necessary.
>>>>>>>
>>>>>>> Virtio uses two communication channels (virtqueues): one for requests and
>>>>>> replies, and a second one for events.
>>>>>>> In contrast, rpmsg provides only a single communication channel, so a
>>>>>>> type field is required to distinguish between different kinds of messages.
>>>>>>>
>>>>>>> Since rpmsg replies and events share the same message format, an additional
>>>>>> line is introduced to handle both cases.
>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port field is added to
>>>>>> uniquely identify the target controller.
>>>>>>
>>>>>> I have commented on this before - RPMSG is already providing multiplexing
>>>>>> capability by way of endpoints. There is no need for a port field. One endpoint,
>>>>>> one GPIO controller.
>>>>>>
>>>>> You still need a way to let the remote side know which port the endpoint maps to, either
>>>>> by embedding the port information in the message (the current way), or by sending it
>>>>> separately.
>>>>>
>>>> An endpoint is created with every namespace request. There should be
>>>> one namespace request for every GPIO controller, which yields a unique
>>>> endpoint for each controller and eliminates the need for an extra
>>>> field to identify them.
>>>
>>>
>>> Right, but this can still be done by just having one namespace request.
>>> We can create new endpoints bound to an existing namespace/channel by
>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>> https://lore.kernel.org/all/29485742-6e49-482e-b73d-228295daaeec@ti.com/
>>>
>>
>> I will look at your suggestion (i.e link above) later this week or next week.
>>
>>> My mental model looks like this for the complete picture:
>>>
>>> 1. namespace/channel#1 = rpmsg-io
>>> a. ept1 -> gpio-controller@1
>>> b. ept2 -> gpio-controller@2
>>>
>>
>> I've asked for one endpoint per GPIO controller since the very
>> beginning. I don't yet have a strong opinion on whether to use one
>> namespace request per GPIO controller or a single request that spins
>> off multiple endpoints. I'll have to look at your link and reflect on
>> that. Regardless of how we proceed on that front, multiplexing needs
>> to happen at the endpoint level rather than the packet level. This is
>> the only way this work can move forward.
>>
>
> I would be more in favor of Mathieu’s proposal: “An endpoint is created with every namespace request.”
>
> If the endpoint is created only on the Linux side, how do we match the Linux endpoint address with the local port field on the remote side?
Simply by sending a message to the remote containing the newly created
endpoint and the port idx. Note that is this done just one time, after this
Linux need not have the port field in the message everytime its sending
a message.
>
> With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where [addr] corresponds to the GPIO controller address in the DT. This would:
You will face the same problem in this case also that you asked above:
"how do we match the Linux endpoint address with the local port field
on the remote side?"
Because the endpoint that is created on a namespace request is also
dynamic in nature. How will the remote know which endpoint addr
Linux allocated for a namespace that it announced?
As an example/PoC, I created a firmware example which announces
2 name services to Linux, one is the standard "rpmsg_chrdev" and
the other is a TI specific name service "ti.ipc4.ping-pong". You can
see it created 2 different addresses (0x400 and 0x401) for each of
the name service request from the same firmware:
root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
[ 9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
[ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
[ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel formed from src = 0x400 to dst = 0xe
[ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel: 0x401 -> 0xd!
So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
Back to same problem. Simple solution is to reply to remote with the
created ept addr and the index.
>
> - match the RPMsg probe with the DT,
We can probe from all controllers with a single name service
announcement too.
> - provide a simple mapping between the port and the endpoint on both sides,
We are trying to get rid of this mapping from Linux side to adapt
the gpio-virtio design.
> - allow multiple endpoints on the remote side,
We can support this as well with single nameservice model.
There is no limitation. Remote has to send a message with
its newly created ept that's all.
> - provide a simple discovery mechanism for remote capabilities.
A single announcement: "rpmsg-io" is also discovery mechanism.
Feel free to let me know if you have concerns with any of the
suggestions!
Thanks,
Beleswar
>
> Regards,
> Arnaud
>
>>> 2. namespace/channel#2 = rpmsg-i2c
>>> a. ept1 -> i2c@1
>>> b. ept2 -> i2c@2
>>> c. ept3 -> i2c@3
>>>
>>> etc...
>>>
>>> This way device groups are isolated with each channel/namespace, and
>>> instances within each device groups are also respected with specific
>>> endpoints.
>>>
>>> Thanks,
>>> Beleswar
>>>
>>
>
^ permalink raw reply
* Re: [PATCH v3 1/6] dt-bindings: thermal: sun8i: Add A523 THS0/1 controllers
From: Chen-Yu Tsai @ 2026-04-30 12:49 UTC (permalink / raw)
To: Jernej Škrabec
Cc: iuncuim, Rob Herring, Vasily Khoruzhick, Yangtao Li,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Krzysztof Kozlowski, Conor Dooley, Samuel Holland, Philipp Zabel,
Andre Przywara, linux-pm, devicetree, linux-arm-kernel,
linux-sunxi, linux-kernel
In-Reply-To: <1935223.tdWV9SEqCh@jernej-laptop>
On Tue, Oct 28, 2025 at 3:01 AM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Hi,
>
> Dne nedelja, 26. oktober 2025 ob 22:09:05 Srednjeevropski standardni čas je Rob Herring napisal(a):
> > On Sat, Oct 25, 2025 at 12:31:24PM +0800, iuncuim wrote:
> > > From: Mikhail Kalashnikov <iuncuim@gmail.com>
> > >
> > > Add a binding for D1/T113s thermal sensor controller. Add dt-bindings
> > > description of the thermal sensors in the A523 processor.
> > > The controllers require activation of the additional frequency of the
> > > associated gpadc controller, so a new clock property has been added.
> > >
> > > The calibration data is split into two cells that are in different areas
> > > of nvmem. Both controllers require access to both memory cell, so a new
> > > property nvmem-cells has been added. To maintain backward compatibility,
> > > the name of the old cell remains the same and the new nvmem-cell-names is
> > > called calibration-second-part
> > >
> > > Signed-off-by: Mikhail Kalashnikov <iuncuim@gmail.com>
> > > ---
> > > .../thermal/allwinner,sun8i-a83t-ths.yaml | 56 ++++++++++++++++++-
> > > 1 file changed, 53 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml
> > > index 3e61689f6..b2f750ef2 100644
> > > --- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml
> > > +++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml
> > > @@ -24,18 +24,23 @@ properties:
> > > - allwinner,sun50i-h5-ths
> > > - allwinner,sun50i-h6-ths
> > > - allwinner,sun50i-h616-ths
> > > + - allwinner,sun55i-a523-ths0
> > > + - allwinner,sun55i-a523-ths1
> > >
> > > clocks:
> > > minItems: 1
> > > items:
> > > - description: Bus Clock
> > > - description: Module Clock
> > > + - description: GPADC Clock
> > >
> > > clock-names:
> > > minItems: 1
> > > + maxItems: 2
> >
> > How can the max be both 2 and...
> >
> > > items:
> > > - const: bus
> > > - const: mod
> > > + - const: gpadc
> >
> > ...3 entries?
> >
>
> Because old variant uses "bus" and "mod" and new variant uses "bus" and
> "gpadc" and none of them uses all 3 entries.
>
> Although, I guess we can simplify and just use "mod" in both cases.
Yes. Please just keep using "mod".
ChenYu
^ permalink raw reply
* Re: [PATCH v22 4/8] drm: bridge: Cadence: Add MHDP8501 DP/HDMI driver
From: Alexander Stein @ 2026-04-30 12:47 UTC (permalink / raw)
To: Luca Ceresoli, Laurentiu Palcu
Cc: Parshuram Thombare, Swapnil Jakhade, Dmitry Baryshkov,
Nikhil Devshatwar, Jayesh Choudhary, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, dri-devel,
devicetree, linux-kernel, linux-phy, imx, linux-arm-kernel, linux,
Ying Liu
In-Reply-To: <q7rze73ohtylj4jgtxun3cg6ih42crfs2u6tioby6yfqciemem@udrdm2g32fgn>
Hi,
Am Montag, 27. April 2026, 16:35:55 CEST schrieb Laurentiu Palcu:
> Hi Luca,
>
> [snip]
> >
> > Another question is whether this driver should have two compatible strings,
> > one for hdmi and one for dp, and set the bridge_type based on that. This
> > would make it a lot simpler and remove the need for this function.
>
> I think this is a good idea. I see no reason why having 2 different
> compatibles wouldn't work. I'll give it a try.
IIRC the original implementation of Sandor had two compatibles, essentially
duplicating lots of code for DP and HDMI. Maybe meanwhile with the rework the
duplication is gone and the different compatibles are feasible again.
Best regards,
Alexander
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v21 08/13] mfd: core: Add firmware-node support to MFD cells
From: Bartosz Golaszewski @ 2026-04-30 12:46 UTC (permalink / raw)
To: Shivendra Pratap
Cc: linux-pm, linux-kernel, linux-arm-msm, linux-arm-kernel,
devicetree, Florian Fainelli, Krzysztof Kozlowski,
Dmitry Baryshkov, Mukesh Ojha, Andre Draszik, Greg Kroah-Hartman,
Kathiravan Thirumoorthy, Srinivas Kandagatla, Sebastian Reichel,
Mark Rutland, Lorenzo Pieralisi, Rafael J. Wysocki,
Daniel Lezcano, Christian Loehle, Ulf Hansson, Lee Jones,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio, Arnd Bergmann, Souvik Chakravarty, Andy Yan,
Matthias Brugger, John Stultz, Moritz Fischer, Sudeep Holla
In-Reply-To: <37ab0178-1c9d-409e-bbaa-832f8075afa4@oss.qualcomm.com>
On Wed, Apr 29, 2026 at 6:10 PM Shivendra Pratap
<shivendra.pratap@oss.qualcomm.com> wrote:
>
>
>
> On 29-04-2026 15:20, Bartosz Golaszewski wrote:
> > On Wed, Apr 29, 2026 at 11:46 AM Shivendra Pratap
> > <shivendra.pratap@oss.qualcomm.com> wrote:
> >>
> >>>>
> >>>> If set, it would be called from MFD core and would do the name lookup
> >>>> and return the fwnode which would then be assigned to the cell device?
> >>>
> >>
> >> Or should we just drop this patch for fwnode in mfd-core?
> >>
> >> Export a new call in reboot-mode framework as:
> >> reboot_mode_register_node(struct reboot_mode_driver *reboot,
> >> struct device_node *np / fwnode)
> >>
> >> Use the parent node in psci-reboot-mode and find reboot-mode and call
> >> reboot_mode_register_node?
> >>
> >
> > No, I think the reboot-mode device (as pointed to by the dev field of
> > struct reboot_mode_driver) should be associated with the right fwnode
> > from the start so it should be handled in MFD core.
>
> Ack. something like should be fine?
>
> drivers/mfd/mfd-core.c :
> + if (!pdev->dev.fwnode && cell->get_fwnode) {
> + fwnode = cell->get_fwnode(parent);
> + if (fwnode)
> + device_set_node(&pdev->dev, fwnode);
> + }
>
Possibly we could find a better name, but yeah the general idea is sound.
Of course, let's maybe here from Lee if he's ok before sending a new version.
> drivers/mfd/psci-mfd.c (goes next patch):
> +static struct fwnode_handle *psci_reboot_mode_get_fwnode(struct device
> *parent)
> +{
> + return fwnode_get_named_child_node(dev_fwnode(parent),
> "reboot-mode");
> +}
>
Yes, something like this.
Bart
^ permalink raw reply
* Re: [PATCH v2 0/4] ARM: pxa: attach software nodes to the GPIO controllers
From: Bartosz Golaszewski @ 2026-04-30 12:39 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Bartosz Golaszewski, Daniel Mack, Haojian Zhuang, Robert Jarzmik,
Russell King, Dmitry Torokhov, Linus Walleij, linux-arm-kernel,
open list:GPIO SUBSYSTEM, linux-kernel
In-Reply-To: <dd8faf98-4c1e-4e08-a41a-849c59a903e7@app.fastmail.com>
On Thu, Apr 30, 2026 at 1:58 PM Arnd Bergmann <arnd@kernel.org> wrote:
>
> On Thu, Apr 30, 2026, at 09:14, Bartosz Golaszewski wrote:
> > On Mon, Apr 27, 2026 at 1:01 PM Bartosz Golaszewski <brgl@kernel.org> wrote:
> >> On Mon, Apr 27, 2026 at 12:50 PM Arnd Bergmann <arnd@kernel.org> wrote:
> >
> > Before I address Russell's comment in v2, can you please let me know
> > if pxa will be removed in v7.2?
>
> I'll need some more time. Not sure about the schedule, but I don't
> expect to remove the board files in 7.2 now, sorry.
>
No worries, I just wanted to know if I should even bother with v3.
I'll send it with hopes of getting it queued for v7.2 and being able
to progress with GPIO core changes in v7.3 then.
Bart
^ permalink raw reply
* Re: [PATCH 1/8] KVM: arm64: Make EL2 exception entry and exit context-synchronization events
From: Mark Rutland @ 2026-04-30 12:37 UTC (permalink / raw)
To: Fuad Tabba
Cc: Will Deacon, maz, oliver.upton, james.morse, suzuki.poulose,
yuzenghui, qperret, vdonnefort, catalin.marinas, linux-arm-kernel,
kvmarm, linux-kernel, stable
In-Reply-To: <CA+EHjTw6rx5rCVnR7Dfva3xmmgGjqUeUaT=3zDCEsN0J909Wsg@mail.gmail.com>
On Thu, Apr 30, 2026 at 01:18:48PM +0100, Fuad Tabba wrote:
> On Thu, 30 Apr 2026 at 10:08, Will Deacon <will@kernel.org> wrote:
> > On Tue, Apr 28, 2026 at 11:30:01AM +0100, Fuad Tabba wrote:
> > > Fixes: fe2c8d19189e ("KVM: arm64: Turn SCTLR_ELx_FLAGS into INIT_SCTLR_EL2_MMU_ON")
> >
> > I don't think this Fixes: tag is accurate:
> >
> > 1. That commit doesn't do anything with EIS/EOS afaict.
> > 2. Back in 5.12 (when that thing landed), SCTLR_EL2_RES1 did actually
> > include EIS and EOS
> >
> > so I think the issue here might be that the auto-generated sysreg file
> > quietly changes the RES1 definitions as bits get allocated, but the
> > macros using the RES1 definition don't get updated. That's a pretty
> > horrible pit that it feels like we might keep falling into :/
I think that's a review failure, and people need to be careful when
updating the sysreg file (e.g. looking at whether any new bits were
previously RESx, and considering the impact). Regardless of tooling, we
need people to conciosuly review that.
> > Looking at 0a35bd285f43 ("arm64: Convert SCTLR_EL2 to sysreg
> > infrastructure"), I think we ended up dropping a whole bunch of fields
> > from the RES1 mask (which became 0!). Have you checked all of those?
> On the wider question of the other bits dropped from the old mask,
> I went through them against DDI 0487 M.b §D24.2.175. The summary
> (SCTLR_EL2 with E2H=0):
>
> bit field E2H=0 status kernel cares?
> -------------------------------------------------------------
> 4 SA0 RES1 unconditionally no
> 5 CP15BEN RES1 unconditionally no
> 11 EOS RES1 iff !FEAT_ExS, else RW yes (this fix)
> 16 nTWI RES1 unconditionally no
> 18 nTWE RES1 unconditionally no
> 22 EIS RES1 iff !FEAT_ExS, else RW yes (this fix)
> 23 SPAN RES1 unconditionally no
> 28 nTLSMD RES1 unconditionally no
> 29 LSMAOE RES1 unconditionally no
>
> The seven non-EIS/EOS bits all fall under the "Otherwise: Reserved,
> RES1" clause for the E2H=0 layout, with no feature guard. Writing 0
> to them is a no-op, so dropping them from the mask should be harmless
> I think. EIS and EOS are the only positions where the bit
> becomes RW (with UNKNOWN reset) on FEAT_ExS hardware and the
> kernel actively relies on the value being 1, which is what this
> patch addresses.
>
> I agree the auto-generator silently zeroing previously hand-rolled
> RES1 masks is a real problem. Happy to look at either teaching the
> sysreg infrastructure to express conditional RES1 (so config.c's
> AS_RES1/FEAT_X facts can flow back into the header masks),
Please don't add that to the syreg code; that's deliberately *only* the
architectural definitions, and overloading that is going to make things
even more confusing, because "I want to treat this as RESx in this piece
of code" isn't a global property.
> or at least adding a build-time check that flags any auto-generated
> <REG>_RES1 that shrinks. After this series, though. Let me know if
> you'd like me to take a stab.
FWIW, having tooling to compare before/after would be useful, but I
don't think that can be a standard build-time check, given that this
would depend on having the old and new sysreg files available for
comparison.
Mark.
^ permalink raw reply
* Re: [PATCH v2 0/5] mm: reduce mmap_lock contention and improve page fault performance
From: Matthew Wilcox @ 2026-04-30 12:37 UTC (permalink / raw)
To: Barry Song (Xiaomi)
Cc: akpm, linux-mm, david, ljs, liam, vbabka, rppt, surenb, mhocko,
jack, pfalcato, wanglian, chentao, lianux.mm, kunwu.chan,
liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20260430040427.4672-1-baohua@kernel.org>
On Thu, Apr 30, 2026 at 12:04:22PM +0800, Barry Song (Xiaomi) wrote:
> (1) If we need to wait for I/O completion, we still drop the per-VMA lock, as
> current page fault handling already does. Holding it for too long may introduce
> various priority inversion issues on mobile devices. After I/O completes, we
> retry the page fault with the per-VMA lock, rather than falling back to
> mmap_lock.
You're going to have to do better than that. You know I hate the
additional complexity you're adding. You need to explain why my idea of
ripping out all the complexity now that we have per-VMA locks doesn't
work.
^ permalink raw reply
* Re: [PATCH v2 4/5] mm: Don't retry page fault if folio is uptodate during swap-in
From: Matthew Wilcox @ 2026-04-30 12:35 UTC (permalink / raw)
To: Barry Song (Xiaomi)
Cc: akpm, linux-mm, david, ljs, liam, vbabka, rppt, surenb, mhocko,
jack, pfalcato, wanglian, chentao, lianux.mm, kunwu.chan,
liyangouwen1, chrisl, kasong, shikemeng, nphamcs, bhe,
youngjun.park, linux-arm-kernel, linux-kernel, loongarch,
linuxppc-dev, linux-riscv, linux-s390
In-Reply-To: <20260430040427.4672-5-baohua@kernel.org>
On Thu, Apr 30, 2026 at 12:04:26PM +0800, Barry Song (Xiaomi) wrote:
> If we are waiting for long I/O to complete, it makes sense to
> avoid holding locks for too long. However, if the folio is
> uptodate, we are likely only waiting for a concurrent PTE
> update to finish. Retrying the entire page fault seems
> excessive.
I think the idea is good, but the implementation is misplaced.
The check for folio_uptodate() should be inside folio_lock_or_retry()
rather than tampering with FAULT_FLAG_ALLOW_RETRY in its caller.
Similarly for your next patch.
> Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
> ---
> mm/memory.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/mm/memory.c b/mm/memory.c
> index 0c740ca363cc..a2e4f2d87ec8 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -4949,6 +4949,13 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
> }
>
> swapcache = folio;
> + /*
> + * If the folio is uptodate, we are likely only waiting for
> + * another concurrent PTE mapping to complete, which should
> + * be brief. No need to drop the lock and retry the fault.
> + */
> + if (folio_test_uptodate(folio))
> + vmf->flags &= ~FAULT_FLAG_ALLOW_RETRY;
> ret |= folio_lock_or_retry(folio, vmf);
> if (ret & VM_FAULT_RETRY) {
> if (fault_flag_allow_retry_first(vmf->flags) &&
> --
> 2.39.3 (Apple Git-146)
>
>
^ permalink raw reply
* [PATCH] dt-bindings: arm-smmu: qcom: Add compatible for Qualcomm Shikra SoC
From: Komal Bajaj @ 2026-04-30 12:24 UTC (permalink / raw)
To: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, iommu, devicetree, linux-kernel, Komal Bajaj
Qualcomm Shikra SoC includes an apps SMMU that implements arm,mmu-500,
which is used to translate device-visible virtual addresses to physical
addresses. Add compatible for it.
Signed-off-by: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
index 06fb5c8e7547..1f544103b574 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
@@ -55,6 +55,7 @@ properties:
- qcom,sdx55-smmu-500
- qcom,sdx65-smmu-500
- qcom,sdx75-smmu-500
+ - qcom,shikra-smmu-500
- qcom,sm6115-smmu-500
- qcom,sm6125-smmu-500
- qcom,sm6350-smmu-500
---
base-commit: 39704f00f747aba3144289870b5fd8ac230a9aaf
change-id: 20260430-shikra-smmu-binding-7befe45ecf2a
Best regards,
--
Komal Bajaj <komal.bajaj@oss.qualcomm.com>
^ 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