* Re: [PATCH 1/4] exec: inherit HWCAPs from the parent process
From: Mark Rutland @ 2026-03-27 16:06 UTC (permalink / raw)
To: Andrei Vagin
Cc: Will Deacon, Kees Cook, Andrew Morton, Marek Szyprowski,
Cyrill Gorcunov, Mike Rapoport, Alexander Mikhalitsyn,
linux-kernel, linux-fsdevel, linux-mm, criu, Catalin Marinas,
linux-arm-kernel, Chen Ridong, Christian Brauner,
David Hildenbrand, Eric Biederman, Lorenzo Stoakes, Michal Koutny,
Alexander Mikhalitsyn
In-Reply-To: <CAEWA0a7iR8YHooqXJfhersV6YhAXGMZDUhib3QQH5XGn=KNowA@mail.gmail.com>
On Tue, Mar 24, 2026 at 03:19:49PM -0700, Andrei Vagin wrote:
> Hi Mark and Will,
>
> Thanks for the feedback. Please read the inline comments.
>
> On Tue, Mar 24, 2026 at 3:28 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Mar 23, 2026 at 06:21:22PM +0000, Mark Rutland wrote:
> > > On Mon, Mar 23, 2026 at 05:53:37PM +0000, Andrei Vagin wrote:
> > > > Introduces a mechanism to inherit hardware capabilities (AT_HWCAP,
> > > > AT_HWCAP2, etc.) from a parent process when they have been modified via
> > > > prctl.
> > > >
> > > > To support C/R operations (snapshots, live migration) in heterogeneous
> > > > clusters, we must ensure that processes utilize CPU features available
> > > > on all potential target nodes. To solve this, we need to advertise a
> > > > common feature set across the cluster.
> > > >
> > > > This patch adds a new mm flag MMF_USER_HWCAP, which is set when the
> > > > auxiliary vector is modified via prctl(PR_SET_MM, PR_SET_MM_AUXV). When
> > > > execve() is called, if the current process has MMF_USER_HWCAP set, the
> > > > HWCAP values are extracted from the current auxiliary vector and stored
> > > > in the linux_binprm structure. These values are then used to populate
> > > > the auxiliary vector of the new process, effectively inheriting the
> > > > hardware capabilities.
> > > >
> > > > The inherited HWCAPs are masked with the hardware capabilities supported
> > > > by the current kernel to ensure that we don't report more features than
> > > > actually supported. This is important to avoid unexpected behavior,
> > > > especially for processes with additional privileges.
> > >
> > > At a high level, I don't think that's going to be sufficient:
> > >
> > > * On an architecture with other userspace accessible feature
> > > identification mechanism registers (e.g. ID registers), userspace
> > > might read those. So you might need to hide stuff there too, and
> > > that's going to require architecture-specific interfaces to manage.
> > >
> > > It's possible that some code checks HWCAPs and others check ID
> > > registers, and mismatch between the two could be problematic.
> > >
> > > * If the HWCAPs can be inherited by a more privileged task, then a
> > > malicious user could use this to hide security features (e.g. shadow
> > > stack or pointer authentication on arm64), and make it easier to
> > > attack that task. While not a direct attack, it would undermine those
> > > features.
>
> I agree with Mark that only a privileged process have to be able to mask
> certain hardware features. Currently, PR_SET_MM_AUXV is guarded by
> CAP_SYS_RESOURCE, but PR_SET_MM_MAP allows changing the auxiliary vector
> without specific capabilities. This is definitely the issue. To address
> this, I think we can consider to introduce a new prctl command to enable
> HWCAP inheritance explicitly.
>
> > Yeah, this looks like a non-starter to me on arm64. Even if it was
> > extended to apply the same treatment to the idregs, many of the hwcap
> > features can't actually be disabled by the kernel and so you still run
> > the risk of a task that probes for the presence of a feature using
> > something like a SIGILL handler or, perhaps more likely, assumes that
> > the presence of one hwcap implies the presence of another. And then
> > there are the applications that just base everything off the MIDR...
>
> The goal of this mechanism is not to provide strict architectural
> enforcement or to trap the use of hardware features; rather, it is to
> provide a consistent discovery interface for applications. I chose the
> HWCAP vector because it mirrors the existing behavior of running an
> older kernel on newer hardware: while ID registers might report a
> feature as physically present, the HWCAPs will omit it if the kernel
> lacks support.
On arm64, the view of the ID registers that userspace gets *only*
exposes features that the kernel knows about, as userspace reads of
those registers are trapped+emulated by the kernel. On arm64 it's
not true to say that something appears in those but not the HWCAPs.
I understand that might be different on other architectures, and so
maybe this approach is sufficient on other architectures, but it is not
sufficient on arm64.
> Applications are generally expected to treat HWCAPs as
> the source of truth for which features are safe to use, even if the
> underlying hardware is technically capable of more.
I'm fairly certain that there are arm64 applications (and libraries)
which check only the ID register values, and not the HWCAPs.
Architecturally, there are features which are detected via other
mechanisms (e.g. CHKFEAT), for which HWCAPs are also irrelevant. Even if
that happens to be ok today, there are almost certainly future uses that
will not be compatible with the scheme you propose.
I don't think we can say "applications must check the HWCAPs", when we
know that applications and libraries legitimately don't always do that.
> Another significant advantage of using HWCAPs is that many
> applications already rely on them for feature detection. This interface
> allows these applications to work correctly "out-of-the-box" in a
> migrated environment without requiring any userspace modifications. I
> understand that some apps may use other detection methods; however, there
> it no gurantee that these applications will work correctly after
> migration to another machine.
I think the existince of applications that detect features by other
(legitimate!) means implies that there's no guarantee that this feature
is useful and will remain useful going forwards.
For example, what do you plan to do if an application or library starts
doing something legitimate that causes it to become incompatible with
this scheme?
I don't want to be in a position where userspace is asked to steer clear
of legitimate mechanisms, or where architecture code suddently has to
pick up a lot of complexity to make this work.
> > There's also kvm, which provides a roundabout way to query some features
> > of the underlying hardware.
> >
> > You're probably better off using/extending the idreg overrides we have
> > in arch/arm64/kernel/pi/idreg-override.c so that you can make your
> > cluster of heterogeneous machines look alike.
>
> IIRC, idreg-override/cpuid-masking usually works for an entire machine.
> We actually need to have a mechanism that will work on a per-container
> basis. Workloads inside one cluster can have different
> migration/snapshot requirements. Some are pinned to a specific node,
> others are never migrated, while others need to be migratable across a
> cluster or even between clusters. We need a mechanism that can be
> tunable on a per-container/per-process basis.
I think that's theoretically possible, BUT it will require substantially
more complexity, to address the issues that Will and I have mentioned. I
don't think people are very happy to pick up that complexity.
There are many other aspects that are going to be problematic for
heterogeneous migration. Even if you hide the HWCAP for a stateful
feature (e.g. SME), it might appear in one machine's signal frames (and
be mandatory there), but might not appear in anothers, and so migration
might not work either way. Likewise, that state can appear via ptrace.
Thanks,
Mark.
^ permalink raw reply
* [GIT PULL] arm_mpam: Add KVM/arm64 and resctrl glue code
From: James Morse @ 2026-03-27 16:19 UTC (permalink / raw)
To: Catalin Marinas, will@kernel.org
Cc: Ben Horgan, Marc Zyngier, Oliver Upton,
linux-arm-kernel@lists.infradead.org, Dave P Martin,
Shanker Donthineni, Zeng Heng
Hi Catalin, Will,
Below is the MPAM series that plumbs all this stuff out to user-space via resctrl.
3 patches against KVM Acked by Marc Z, 9 patches against arm64 Acked or Reviewed by
Catalin. One patch "arm_mpam: resctrl: Add CDP emulation" adds an include to the
asm/mpam.h header. I'm assuming that doesn't need an ack.
Thanks to Ben for fixing all my bugs!
James
----------------------------------------------------------------
The following changes since commit 1f318b96cc84d7c2ab792fcc0bfd42a7ca890681:
Linux 7.0-rc3 (2026-03-08 16:56:54 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/morse/linux.git mpam/glue/v7.0-rc3
for you to fetch changes up to 4ce0a2ccc0358f3f746fa50815a599f861fd5d68:
arm64: mpam: Add initial MPAM documentation (2026-03-27 15:32:52 +0000)
----------------------------------------------------------------
Expose MPAM to user-space via resctrl based on v7.0-rc3
- Add architecture context-switch and hiding of the feature from KVM.
- Add interface to allow MPAM to be exposed to user-space using resctrl.
- Add errata workaoround for some existing platforms.
- Add documentation for using MPAM and what shape of platforms can use resctrl
----------------------------------------------------------------
Ben Horgan (11):
arm_mpam: Reset when feature configuration bit unset
arm64/sysreg: Add MPAMSM_EL1 register
KVM: arm64: Preserve host MPAM configuration when changing traps
KVM: arm64: Make MPAMSM_EL1 accesses UNDEF
arm64: mpam: Drop the CONFIG_EXPERT restriction
arm64: mpam: Initialise and context switch the MPAMSM_EL1 register
arm_mpam: resctrl: Hide CDP emulation behind CONFIG_EXPERT
arm_mpam: resctrl: Add rmid index helpers
arm_mpam: resctrl: Wait for cacheinfo to be ready
arm_mpam: resctrl: Add monitor initialisation and domain boilerplate
arm64: mpam: Add initial MPAM documentation
Dave Martin (2):
arm_mpam: resctrl: Convert to/from MPAMs fixed-point formats
arm_mpam: resctrl: Add kunit test for control format conversions
James Morse (22):
arm64: mpam: Context switch the MPAM registers
arm64: mpam: Re-initialise MPAM regs when CPU comes online
arm64: mpam: Advertise the CPUs MPAM limits to the driver
arm64: mpam: Add cpu_pm notifier to restore MPAM sysregs
arm64: mpam: Add helpers to change a task or cpu's MPAM PARTID/PMG values
KVM: arm64: Force guest EL1 to use user-space's partid configuration
arm_mpam: resctrl: Add boilerplate cpuhp and domain allocation
arm_mpam: resctrl: Pick the caches we will use as resctrl resources
arm_mpam: resctrl: Implement resctrl_arch_reset_all_ctrls()
arm_mpam: resctrl: Add resctrl_arch_get_config()
arm_mpam: resctrl: Implement helpers to update configuration
arm_mpam: resctrl: Add plumbing against arm64 task and cpu hooks
arm_mpam: resctrl: Add CDP emulation
arm_mpam: resctrl: Add support for 'MB' resource
arm_mpam: resctrl: Add support for csu counters
arm_mpam: resctrl: Allow resctrl to allocate monitors
arm_mpam: resctrl: Add resctrl_arch_rmid_read()
arm_mpam: resctrl: Update the rmid reallocation limit
arm_mpam: resctrl: Add empty definitions for assorted resctrl functions
arm64: mpam: Select ARCH_HAS_CPU_RESCTRL
arm_mpam: resctrl: Call resctrl_init() on platforms that can support resctrl
arm_mpam: Quirk CMN-650's CSU NRDY behaviour
Shanker Donthineni (4):
arm_mpam: Add quirk framework
arm_mpam: Add workaround for T241-MPAM-1
arm_mpam: Add workaround for T241-MPAM-4
arm_mpam: Add workaround for T241-MPAM-6
Zeng Heng (1):
arm_mpam: Ensure in_reset_state is false after applying configuration
Documentation/arch/arm64/index.rst | 1 +
Documentation/arch/arm64/mpam.rst | 72 ++
Documentation/arch/arm64/silicon-errata.rst | 9 +
arch/arm64/Kconfig | 6 +-
arch/arm64/include/asm/el2_setup.h | 3 +-
arch/arm64/include/asm/mpam.h | 96 ++
arch/arm64/include/asm/resctrl.h | 2 +
arch/arm64/include/asm/thread_info.h | 3 +
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/cpufeature.c | 21 +-
arch/arm64/kernel/mpam.c | 62 +
arch/arm64/kernel/process.c | 7 +
arch/arm64/kvm/hyp/include/hyp/switch.h | 12 +-
arch/arm64/kvm/hyp/vhe/sysreg-sr.c | 16 +
arch/arm64/kvm/sys_regs.c | 2 +
arch/arm64/tools/sysreg | 8 +
drivers/resctrl/Kconfig | 9 +-
drivers/resctrl/Makefile | 1 +
drivers/resctrl/mpam_devices.c | 305 ++++-
drivers/resctrl/mpam_internal.h | 108 +-
drivers/resctrl/mpam_resctrl.c | 1704 +++++++++++++++++++++++++++
drivers/resctrl/test_mpam_resctrl.c | 315 +++++
include/linux/arm_mpam.h | 32 +
23 files changed, 2735 insertions(+), 60 deletions(-)
create mode 100644 Documentation/arch/arm64/mpam.rst
create mode 100644 arch/arm64/include/asm/mpam.h
create mode 100644 arch/arm64/include/asm/resctrl.h
create mode 100644 arch/arm64/kernel/mpam.c
create mode 100644 drivers/resctrl/mpam_resctrl.c
create mode 100644 drivers/resctrl/test_mpam_resctrl.c
^ permalink raw reply
* Re: [PATCH v6 02/40] arm_mpam: Reset when feature configuration bit unset
From: James Morse @ 2026-03-27 16:21 UTC (permalink / raw)
To: Ben Horgan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, jonathan.cameron, kobak, lcherian,
linux-arm-kernel, linux-kernel, peternewman, punit.agrawal,
quic_jiles, reinette.chatre, rohit.mathew, scott, sdonthineni,
tan.shaopeng, xhao, catalin.marinas, will, corbet, maz, oupton,
joey.gouly, suzuki.poulose, kvmarm, zengheng4, linux-doc
In-Reply-To: <20260313144617.3420416-3-ben.horgan@arm.com>
Hi Ben,
On 13/03/2026 14:45, Ben Horgan wrote:
> To indicate that the configuration, of the controls used by resctrl, in a
> RIS need resetting to driver defaults the reset flags in mpam_config are
> set. However, these flags are only ever set temporarily at RIS scope in
> mpam_reset_ris() and hence mpam_cpu_online() will never reset these
> controls to default. As the hardware reset is unknown this leads to unknown
> configuration when the control values haven't been configured away from the
> defaults.
>
> Use the policy that an unset feature configuration bit means reset. In this
> way the mpam_config in the component can encode that it should be in reset
> state and mpam_reprogram_msc() will reset controls as needed.
> diff --git a/drivers/resctrl/mpam_devices.c b/drivers/resctrl/mpam_devices.c
> index 0fd6590a9b5c..ff861291bd4e 100644
> --- a/drivers/resctrl/mpam_devices.c
> +++ b/drivers/resctrl/mpam_devices.c
> @@ -1364,17 +1364,15 @@ static void mpam_reprogram_ris_partid(struct mpam_msc_ris *ris, u16 partid,
> __mpam_intpart_sel(ris->ris_idx, partid, msc);
> }
>
> - if (mpam_has_feature(mpam_feat_cpor_part, rprops) &&
> - mpam_has_feature(mpam_feat_cpor_part, cfg)) {
> - if (cfg->reset_cpbm)
After this, nothing reads/writes these explicit reset flags so they can be removed from
struct mpam_config.
(I'll do this locally)
> - mpam_reset_msc_bitmap(msc, MPAMCFG_CPBM, rprops->cpbm_wd);
> - else
> + if (mpam_has_feature(mpam_feat_cpor_part, rprops)) {
> + if (mpam_has_feature(mpam_feat_cpor_part, cfg))
> mpam_write_partsel_reg(msc, CPBM, cfg->cpbm);
> + else
> + mpam_reset_msc_bitmap(msc, MPAMCFG_CPBM, rprops->cpbm_wd);
> }
>
> - if (mpam_has_feature(mpam_feat_mbw_part, rprops) &&
> - mpam_has_feature(mpam_feat_mbw_part, cfg)) {
> - if (cfg->reset_mbw_pbm)
> + if (mpam_has_feature(mpam_feat_mbw_part, rprops)) {
> + if (mpam_has_feature(mpam_feat_mbw_part, cfg))
> mpam_reset_msc_bitmap(msc, MPAMCFG_MBW_PBM, rprops->mbw_pbm_bits);
> else
> mpam_write_partsel_reg(msc, MBW_PBM, cfg->mbw_pbm);
Reviewed-by: James Morse <james.morse@arm.com>
Thanks!
James
^ permalink raw reply
* Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For i.MX7D/i.MX8M
From: Frank Li @ 2026-03-27 16:22 UTC (permalink / raw)
To: Hongxing Zhu
Cc: l.stach@pengutronix.de, lpieralisi@kernel.org,
kwilczynski@kernel.org, mani@kernel.org, robh@kernel.org,
bhelgaas@google.com, s.hauer@pengutronix.de,
kernel@pengutronix.de, festevam@gmail.com,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
imx@lists.linux.dev, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
In-Reply-To: <AS8PR04MB883306406390FCB4106C3A978C57A@AS8PR04MB8833.eurprd04.prod.outlook.com>
On Fri, Mar 27, 2026 at 08:12:29AM +0000, Hongxing Zhu wrote:
> > -----Original Message-----
> > From: Frank Li <frank.li@nxp.com>
> > Sent: 2026年3月19日 22:17
> > To: Hongxing Zhu <hongxing.zhu@nxp.com>
> > Cc: l.stach@pengutronix.de; lpieralisi@kernel.org; kwilczynski@kernel.org;
> > mani@kernel.org; robh@kernel.org; bhelgaas@google.com;
> > s.hauer@pengutronix.de; kernel@pengutronix.de; festevam@gmail.com;
> > linux-pci@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
> > imx@lists.linux.dev; linux-kernel@vger.kernel.org; stable@vger.kernel.org
> > Subject: Re: [PATCH v2] PCI: imx6: Don't remove MSI capability For
> > i.MX7D/i.MX8M
> >
> > On Thu, Mar 19, 2026 at 05:18:23PM +0800, Richard Zhu wrote:
> > > The MSI trigger mechanism for endpoint devices connected to i.MX7D,
> > > i.MX8MM, and i.MX8MQ PCIe root complex ports depends on the MSI
> > > capability register settings in the root complex. Removing the MSI
> > > capability breaks MSI functionality for these endpoints.
> > >
> > > Preserve the MSI capability for i.MX7D/i.MX8M PCIe root complex to
> > > maintain MSI functionality.
> > >
> > > Cc: stable@vger.kernel.org
> > > Fixes: f5cd8a929c825 ("PCI: dwc: Remove MSI/MSIX capability for Root
> > > Port if iMSI-RX is used as MSI controller")
> >
> > I think it'd better add another varible to check in f5cd8a929c825 if
> > (pp->has_msi_ctrl && !pp->xxx_broken) or direct use IP version, which
> > already auto detected.
> >
> > Previous patch have not consider this old version controller.
> Hi Frank:
> From what I've observed, this behavior seems tied to the specific controller
> design. For example, neither the i.MX6Q nor the i.MX6SX exhibit this issue.
Yes, should rename has_msi_ctrl -> disable_msi_ctrl. Set it according to
difference condition, such as has_msi_ctrl or skip it for problem platform
such as i.MX8MM and i.MX8MQ.
Disable it and overwrite later will cause confuse.
>
> The intention of commit f5cd8a929c825 is to remove the MSI capability from the
> Root Complex (RC). From the author's perspective, this change should not
> affect the Endpoint's (EP) MSI functionality.
Yes, your patch fix RC mode?
Frank
>
> I'm not sure do this check (pp->has_msi_ctrl && !pp->msi_broken) is proper or not.
> Best Regards
> Richard Zhu
> > >
^ permalink raw reply
* Re: [GIT PULL 1/2] Broadcom devicetree changes for 7.1
From: Florian Fainelli @ 2026-03-27 16:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: soc, Rosen Penev, Rob Herring, Linus Walleij, Linus Walleij,
William Zhang, Miquel Raynal, Rafał Miłecki,
linux-arm-kernel, arnd, khilman, bcm-kernel-feedback-list
In-Reply-To: <20260327-lurking-amazing-pudu-114fe8@quoll>
On 3/27/26 04:53, Krzysztof Kozlowski wrote:
> On Mon, Mar 23, 2026 at 12:02:38PM -0700, Florian Fainelli wrote:
>> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>>
>> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>>
>> are available in the Git repository at:
>>
>> https://github.com/Broadcom/stblinux.git tags/arm-soc/for-7.1/devicetree
>>
>> for you to fetch changes up to 220bdfcb4b4788f57faa2c28454d8b2dd3bcab6c:
>>
>> ARM: dts: BCM5301X: EA9200: specify partitions (2026-03-20 16:57:31 -0700)
>
> Four days after:
>
> Days in linux-next:
> ----------------------------------------
> 0 | ++++++++++++++++ (16)
>
> ...
>
> Commits with 0 days in linux-next (16 of 19: 84.2%)...
>
> Are you sure your tree is included in the next?
The branch that is included in linux-next is my "next" branch which is a
merge of all branches. In this particular case however it looks like the
branch was not updated.
--
Florian
^ permalink raw reply
* [PATCH v1 1/1] arm64: dts: imx91-var-dart-sonata: add RGB select supply for PCA6408
From: Stefano Radaelli @ 2026-03-27 16:32 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam
From: Stefano Radaelli <stefano.r@variscite.com>
RGB_SEL controls the routing of some carrier board lines on the Sonata
board. The two PCA6408 GPIO expanders depend on that path being enabled,
so describe the selector as a fixed regulator and use it as their
vcc-supply.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
index afa39dab240a..3b5816884f24 100644
--- a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
+++ b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
@@ -90,6 +90,13 @@ reg_vref_1v8: regulator-adc-vref {
regulator-max-microvolt = <1800000>;
};
+ reg_rgb_sel: regulator-rgb-sel {
+ compatible = "regulator-fixed";
+ regulator-name = "rgb-select";
+ gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
compatible = "regulator-fixed";
pinctrl-names = "default";
@@ -195,6 +202,7 @@ pca6408_1: gpio@20 {
#gpio-cells = <2>;
interrupt-parent = <&gpio1>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ vcc-supply = <®_rgb_sel>;
};
pca6408_2: gpio@21 {
@@ -204,6 +212,7 @@ pca6408_2: gpio@21 {
#gpio-cells = <2>;
interrupt-parent = <&gpio1>;
interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ vcc-supply = <®_rgb_sel>;
};
pca9534: gpio@22 {
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v9 0/5] PCI: of: Remove max-link-speed generation validation
From: Bjorn Helgaas @ 2026-03-27 16:42 UTC (permalink / raw)
To: Hans Zhang
Cc: lpieralisi, jingoohan1, mani, kwilczynski, bhelgaas,
florian.fainelli, jim2101024, robh, ilpo.jarvinen, linux-arm-msm,
linux-arm-kernel, linux-renesas-soc, claudiu.beznea.uj,
linux-mediatek, linux-tegra, linux-omap, bcm-kernel-feedback-list,
linux-pci, linux-kernel, shawn.lin
In-Reply-To: <20260313165522.123518-1-18255117159@163.com>
On Sat, Mar 14, 2026 at 12:55:17AM +0800, Hans Zhang wrote:
> Hi,
>
> This series moves the validation from the common OF function to the
> individual PCIe controller drivers. To protect against out-of-bounds
> accesses to the pcie_link_speed[] array, we first introduce a helper
> function pcie_get_link_speed() that safely returns the speed value
> (or PCI_SPEED_UNKNOWN) for a given generation number.
>
> Then all direct uses of pcie_link_speed[] as an array are converted to
> use the new helper, ensuring that even if an invalid generation number
> reaches those code paths, no out-of-bounds access occurs.
>
> For several drivers that read the "max-link-speed" property
> (pci-j721e, brcmstb, mediatek-gen3, rzg3s-host), we add an explicit
> validation step: if the value is missing, out of range, or unsupported
> by the hardware, a safe default is used (usually Gen2). Other drivers
> (mainly DesignWare glue drivers) rely on the helper to safely handle
> invalid values, but do not yet include fallback logic or warnings.
>
> Finally, the range check is removed from of_pci_get_max_link_speed(),
> so that future PCIe generations can be supported without modifying
> drivers/pci/of.c.
Thanks for this series.
We still have a couple references to pcie_link_speed[] that bypass
pcie_get_link_speed(). These are safe because PCI_EXP_LNKSTA_CLS is
0xf and pcie_link_speed[] is size 16, but I'm not sure the direct
reference is necessary.
The array itself is exported, which I suppose we needed for modular
PCI controller drivers, but we probably don't need it now that
pcie_get_link_speed() is exported?
$ git grep "\<pcie_link_speed\>"
drivers/pci/pci-sysfs.c: speed = pcie_link_speed[linkstat & PCI_EXP_LNKSTA_CLS];
drivers/pci/pci.c: return pcie_link_speed[FIELD_GET(PCI_EXP_LNKSTA_CLS, lnksta)];
drivers/pci/pci.h:extern const unsigned char pcie_link_speed[];
drivers/pci/pci.h: bus->cur_bus_speed = pcie_link_speed[linksta & PCI_EXP_LNKSTA_CLS];
drivers/pci/probe.c:const unsigned char pcie_link_speed[] = {
drivers/pci/probe.c:EXPORT_SYMBOL_GPL(pcie_link_speed);
drivers/pci/probe.c: if (speed >= ARRAY_SIZE(pcie_link_speed))
drivers/pci/probe.c: return pcie_link_speed[speed];
drivers/pci/probe.c: bus->max_bus_speed = pcie_link_speed[linkcap & PCI_EXP_LNKCAP_SLS];
^ permalink raw reply
* [PATCH v4 0/5] dt-bindings: usb: atmel: convert Atmel USB controller bindings to YAML
From: Charan Pedumuru @ 2026-03-27 16:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Claudiu Beznea, Herve Codina, Nicolas Ferre,
Alexandre Belloni
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel,
Charan Pedumuru
This patch series converts the legacy text-based Device Tree bindings for
Atmel/Microchip USB controllers to DT schema (YAML) format.
Note:
The patch "dt-bindings: usb: atmel,at91sam9rl-udc: convert to DT schema"
depends on the patch "arm: dts: at91: remove unused #address-cells/#size-cells
from sam9x60 UDC node". If the DT schema patch is applied before the DTS
cleanup patch, `dtbs_check` will fail due to the presence of the removed
properties in the existing DTS.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
Changes in v4:
- generic-ohci: Modify the commit message and modify description for the
properties "atmel,vbus-gpio" and "atmel,oc-gpio".
- atmel,at91rm9200-udc: Remove minItems for clocks and rename
unevaluatedProperties to additionalProperties.
- atmel,at91sam9rl-udc: Remove minItems for clocks and modify commit
message.
- all: Remove the corresponding text binding node for each patch from
the text binding file.
- Link to v3: https://lore.kernel.org/r/20260307-atmel-usb-v3-0-3dc48fe772be@gmail.com
Changes in v3:
- sam9x60: Add a new patch removing the unnecessary #address-cells and
#size-cells properties from the sam9x60 UDC node.
- atmel,at91sam9rl-udc: Remove #address-cells and #size-cells from the
atmel,at91sam9rl-udc binding properties.
- generic-ohci: Add an else condition to the generic-ohci schema properties
for improved validation precision.
- Link to v2: https://lore.kernel.org/r/20260224-atmel-usb-v2-0-6d6a615c9c47@gmail.com
Changes in v2:
- Drop the separate YAML patches for OHCI and EHCI.
- Add the compatibles "atmel,at91rm9200-ohci" and "atmel,at91sam9g45-ehci"
to the existing generic OHCI and EHCI binding files.
- Link to v1: https://lore.kernel.org/r/20260201-atmel-usb-v1-0-d1a3e93003f1@gmail.com
---
Charan Pedumuru (5):
arm: dts: at91: remove unused #address-cells/#size-cells from sam9x60 udc node
dt-bindings: usb: generic-ohci: add AT91RM9200 OHCI binding support
dt-bindings: usb: generic-ehci: fix schema structure and add at91sam9g45 constraints
dt-bindings: usb: atmel,at91rm9200-udc: convert to DT schema
dt-bindings: usb: atmel,at91sam9rl-udc: convert to DT schema
.../bindings/usb/atmel,at91rm9200-udc.yaml | 76 +++++++++++++
.../bindings/usb/atmel,at91sam9rl-udc.yaml | 74 ++++++++++++
.../devicetree/bindings/usb/atmel-usb.txt | 125 ---------------------
.../devicetree/bindings/usb/generic-ehci.yaml | 46 +++++---
.../devicetree/bindings/usb/generic-ohci.yaml | 41 +++++++
arch/arm/boot/dts/microchip/sam9x60.dtsi | 2 -
6 files changed, 224 insertions(+), 140 deletions(-)
---
base-commit: 3f24e4edcd1b8981c6b448ea2680726dedd87279
change-id: 20260129-atmel-usb-37f89a141e48
Best regards,
--
Charan Pedumuru <charan.pedumuru@gmail.com>
^ permalink raw reply
* [PATCH v4 1/5] arm: dts: at91: remove unused #address-cells/#size-cells from sam9x60 udc node
From: Charan Pedumuru @ 2026-03-27 16:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Claudiu Beznea, Herve Codina, Nicolas Ferre,
Alexandre Belloni
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel,
Charan Pedumuru
In-Reply-To: <20260327-atmel-usb-v4-0-eb8b6e49b29d@gmail.com>
The UDC node does not define any child nodes, so the "#address-cells" and
"#size-cells" properties are unnecessary. Remove these unused properties
to simplify the devicetree node and keep it consistent with DT conventions.
Reviewed-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
arch/arm/boot/dts/microchip/sam9x60.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/microchip/sam9x60.dtsi b/arch/arm/boot/dts/microchip/sam9x60.dtsi
index b075865e6a76..e708b3df4ccd 100644
--- a/arch/arm/boot/dts/microchip/sam9x60.dtsi
+++ b/arch/arm/boot/dts/microchip/sam9x60.dtsi
@@ -75,8 +75,6 @@ ahb {
ranges;
usb0: gadget@500000 {
- #address-cells = <1>;
- #size-cells = <0>;
compatible = "microchip,sam9x60-udc";
reg = <0x00500000 0x100000
0xf803c000 0x400>;
--
2.53.0
^ permalink raw reply related
* [PATCH v4 2/5] dt-bindings: usb: generic-ohci: add AT91RM9200 OHCI binding support
From: Charan Pedumuru @ 2026-03-27 16:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Claudiu Beznea, Herve Codina, Nicolas Ferre,
Alexandre Belloni
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel,
Charan Pedumuru
In-Reply-To: <20260327-atmel-usb-v4-0-eb8b6e49b29d@gmail.com>
Convert the Atmel AT91RM9200 OHCI USB host controller binding to DT schema
by defining it in the existing generic OHCI schema.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../devicetree/bindings/usb/atmel-usb.txt | 27 --------------
.../devicetree/bindings/usb/generic-ohci.yaml | 41 ++++++++++++++++++++++
2 files changed, 41 insertions(+), 27 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 12183ef47ee4..c09685283109 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -1,32 +1,5 @@
Atmel SOC USB controllers
-OHCI
-
-Required properties:
- - compatible: Should be "atmel,at91rm9200-ohci" for USB controllers
- used in host mode.
- - reg: Address and length of the register set for the device
- - interrupts: Should contain ohci interrupt
- - clocks: Should reference the peripheral, host and system clocks
- - clock-names: Should contain three strings
- "ohci_clk" for the peripheral clock
- "hclk" for the host clock
- "uhpck" for the system clock
- - num-ports: Number of ports.
- - atmel,vbus-gpio: If present, specifies a gpio that needs to be
- activated for the bus to be powered.
- - atmel,oc-gpio: If present, specifies a gpio that needs to be
- activated for the overcurrent detection.
-
-usb0: ohci@500000 {
- compatible = "atmel,at91rm9200-ohci", "usb-ohci";
- reg = <0x00500000 0x100000>;
- clocks = <&uhphs_clk>, <&uhphs_clk>, <&uhpck>;
- clock-names = "ohci_clk", "hclk", "uhpck";
- interrupts = <20 4>;
- num-ports = <2>;
-};
-
EHCI
Required properties:
diff --git a/Documentation/devicetree/bindings/usb/generic-ohci.yaml b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
index 961cbf85eeb5..d42f448fa204 100644
--- a/Documentation/devicetree/bindings/usb/generic-ohci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ohci.yaml
@@ -55,6 +55,7 @@ properties:
- ti,ohci-omap3
- items:
- enum:
+ - atmel,at91rm9200-ohci
- cavium,octeon-6335-ohci
- nintendo,hollywood-usb-ohci
- nxp,ohci-nxp
@@ -137,6 +138,24 @@ properties:
The associated ISP1301 device. Necessary for the UDC controller for
connecting to the USB physical layer.
+ atmel,vbus-gpio:
+ description:
+ GPIO used to control or sense the USB VBUS power. Each entry
+ represents a VBUS-related GPIO; count and order may vary by hardware.
+ Entries follow standard GPIO specifier format. A value of 0 indicates
+ an unused or unavailable VBUS signal.
+ minItems: 1
+ maxItems: 3
+
+ atmel,oc-gpio:
+ description:
+ GPIO used to signal USB overcurrent condition. Each entry represents
+ an OC detection GPIO; count and order may vary by hardware. Entries
+ follow standard GPIO specifier format. A value of 0 indicates an
+ unused or unavailable OC signal.
+ minItems: 1
+ maxItems: 3
+
required:
- compatible
- reg
@@ -144,6 +163,28 @@ required:
allOf:
- $ref: usb-hcd.yaml
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,at91rm9200-ohci
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: ohci_clk
+ - const: hclk
+ - const: uhpck
+
+ required:
+ - clocks
+ - clock-names
+
+ else:
+ properties:
+ atmel,vbus-gpio: false
+ atmel,oc-gpio: false
+
- if:
not:
properties:
--
2.53.0
^ permalink raw reply related
* [PATCH v4 3/5] dt-bindings: usb: generic-ehci: fix schema structure and add at91sam9g45 constraints
From: Charan Pedumuru @ 2026-03-27 16:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Claudiu Beznea, Herve Codina, Nicolas Ferre,
Alexandre Belloni
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel,
Charan Pedumuru
In-Reply-To: <20260327-atmel-usb-v4-0-eb8b6e49b29d@gmail.com>
Add clock and phy constraints for atmel,at91sam9g45-ehci and reorganize
the allOf section to fix dtbs_check warnings.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../devicetree/bindings/usb/atmel-usb.txt | 24 -----------
.../devicetree/bindings/usb/generic-ehci.yaml | 46 ++++++++++++++++------
2 files changed, 33 insertions(+), 37 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index c09685283109..bf2149e5f0b3 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -1,29 +1,5 @@
Atmel SOC USB controllers
-EHCI
-
-Required properties:
- - compatible: Should be "atmel,at91sam9g45-ehci" for USB controllers
- used in host mode.
- - reg: Address and length of the register set for the device
- - interrupts: Should contain ehci interrupt
- - clocks: Should reference the peripheral and the UTMI clocks
- - clock-names: Should contain two strings
- "ehci_clk" for the peripheral clock
- "usb_clk" for the UTMI clock
-
-Optional properties:
- - phy_type : For multi port host USB controllers, should be one of
- "utmi", or "hsic".
-
-usb1: ehci@800000 {
- compatible = "atmel,at91sam9g45-ehci", "usb-ehci";
- reg = <0x00800000 0x100000>;
- interrupts = <22 4>;
- clocks = <&utmi>, <&uhphs_clk>;
- clock-names = "usb_clk", "ehci_clk";
-};
-
AT91 USB device controller
Required properties:
diff --git a/Documentation/devicetree/bindings/usb/generic-ehci.yaml b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
index 601f097c09a6..55a5aa7d7a54 100644
--- a/Documentation/devicetree/bindings/usb/generic-ehci.yaml
+++ b/Documentation/devicetree/bindings/usb/generic-ehci.yaml
@@ -9,19 +9,6 @@ title: USB EHCI Controller
maintainers:
- Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-allOf:
- - $ref: usb-hcd.yaml
- - if:
- properties:
- compatible:
- not:
- contains:
- const: ibm,usb-ehci-440epx
- then:
- properties:
- reg:
- maxItems: 1
-
properties:
compatible:
oneOf:
@@ -167,6 +154,39 @@ required:
- reg
- interrupts
+allOf:
+ - $ref: usb-hcd.yaml
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: ibm,usb-ehci-440epx
+ then:
+ properties:
+ reg:
+ maxItems: 1
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: atmel,at91sam9g45-ehci
+ then:
+ properties:
+ clock-names:
+ items:
+ - const: usb_clk
+ - const: ehci_clk
+
+ phy_type:
+ enum:
+ - utmi
+ - hsic
+
+ required:
+ - clocks
+ - clock-names
+
unevaluatedProperties: false
examples:
--
2.53.0
^ permalink raw reply related
* [PATCH v4 4/5] dt-bindings: usb: atmel,at91rm9200-udc: convert to DT schema
From: Charan Pedumuru @ 2026-03-27 16:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Claudiu Beznea, Herve Codina, Nicolas Ferre,
Alexandre Belloni
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel,
Charan Pedumuru
In-Reply-To: <20260327-atmel-usb-v4-0-eb8b6e49b29d@gmail.com>
Convert Atmel AT91 USB Device Controller (UDC) binding to DT schema.
Changes during conversion:
- Include "atmel,pullup-gpio" and "atmel,matrix" in the properties since
they are required by existing in-tree DTS definitions.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../bindings/usb/atmel,at91rm9200-udc.yaml | 76 ++++++++++++++++++++++
.../devicetree/bindings/usb/atmel-usb.txt | 28 --------
2 files changed, 76 insertions(+), 28 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/atmel,at91rm9200-udc.yaml b/Documentation/devicetree/bindings/usb/atmel,at91rm9200-udc.yaml
new file mode 100644
index 000000000000..a4eabb935e6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/atmel,at91rm9200-udc.yaml
@@ -0,0 +1,76 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/atmel,at91rm9200-udc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel AT91 USB Device Controller (UDC)
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+description:
+ The Atmel AT91 USB Device Controller provides USB gadget (device-mode)
+ functionality on AT91 SoCs. It requires a peripheral clock and an AHB
+ clock for operation and may optionally control VBUS power through a GPIO.
+
+properties:
+ compatible:
+ enum:
+ - atmel,at91rm9200-udc
+ - atmel,at91sam9260-udc
+ - atmel,at91sam9261-udc
+ - atmel,at91sam9263-udc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: pclk
+ - const: hclk
+
+ atmel,vbus-gpio:
+ description: GPIO used to enable or control VBUS power for the USB bus.
+ maxItems: 1
+
+ atmel,matrix:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle to the Atmel bus matrix controller.
+
+ atmel,pullup-gpio:
+ description:
+ GPIO controlling the USB D+ pull-up resistor used to signal device
+ connection to the host.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/gpio/gpio.h>
+ gadget@fffa4000 {
+ compatible = "atmel,at91rm9200-udc";
+ reg = <0xfffa4000 0x4000>;
+ interrupts = <11 IRQ_TYPE_LEVEL_HIGH 2>;
+ clocks = <&udc_clk>, <&udpck>;
+ clock-names = "pclk", "hclk";
+ atmel,vbus-gpio = <&pioC 5 GPIO_ACTIVE_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index bf2149e5f0b3..ab353576d1de 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -1,33 +1,5 @@
Atmel SOC USB controllers
-AT91 USB device controller
-
-Required properties:
- - compatible: Should be one of the following
- "atmel,at91rm9200-udc"
- "atmel,at91sam9260-udc"
- "atmel,at91sam9261-udc"
- "atmel,at91sam9263-udc"
- - reg: Address and length of the register set for the device
- - interrupts: Should contain macb interrupt
- - clocks: Should reference the peripheral and the AHB clocks
- - clock-names: Should contain two strings
- "pclk" for the peripheral clock
- "hclk" for the AHB clock
-
-Optional properties:
- - atmel,vbus-gpio: If present, specifies a gpio that needs to be
- activated for the bus to be powered.
-
-usb1: gadget@fffa4000 {
- compatible = "atmel,at91rm9200-udc";
- reg = <0xfffa4000 0x4000>;
- interrupts = <10 4>;
- clocks = <&udc_clk>, <&udpck>;
- clock-names = "pclk", "hclk";
- atmel,vbus-gpio = <&pioC 5 0>;
-};
-
Atmel High-Speed USB device controller
Required properties:
--
2.53.0
^ permalink raw reply related
* [PATCH v4 5/5] dt-bindings: usb: atmel,at91sam9rl-udc: convert to DT schema
From: Charan Pedumuru @ 2026-03-27 16:47 UTC (permalink / raw)
To: Greg Kroah-Hartman, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Claudiu Beznea, Herve Codina, Nicolas Ferre,
Alexandre Belloni
Cc: linux-usb, devicetree, linux-arm-kernel, linux-kernel,
Charan Pedumuru
In-Reply-To: <20260327-atmel-usb-v4-0-eb8b6e49b29d@gmail.com>
Convert Atmel High-Speed USB Device Controller (USBA) binding to DT schema.
Changes during conversion:
- Make the "clock-names" property flexible enough to accept the items
in any order as the existing in tree DTS nodes doesn't follow an order.
Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
---
.../bindings/usb/atmel,at91sam9rl-udc.yaml | 74 ++++++++++++++++++++++
.../devicetree/bindings/usb/atmel-usb.txt | 46 --------------
2 files changed, 74 insertions(+), 46 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/atmel,at91sam9rl-udc.yaml b/Documentation/devicetree/bindings/usb/atmel,at91sam9rl-udc.yaml
new file mode 100644
index 000000000000..cdbbd17f8036
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/atmel,at91sam9rl-udc.yaml
@@ -0,0 +1,74 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/usb/atmel,at91sam9rl-udc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel High-Speed USB Device Controller (USBA)
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+description:
+ The Atmel High-Speed USB Device Controller (USBA) provides USB 2.0
+ high-speed gadget functionality on several Atmel and Microchip SoCs.
+ The controller requires a peripheral clock and a host clock for operation
+ and may optionally use a GPIO to detect VBUS presence.
+
+properties:
+ compatible:
+ oneOf:
+ - enum:
+ - atmel,at91sam9rl-udc
+ - atmel,at91sam9g45-udc
+ - atmel,sama5d3-udc
+ - items:
+ - const: microchip,lan9662-udc
+ - const: atmel,sama5d3-udc
+ - const: microchip,sam9x60-udc
+
+ reg:
+ maxItems: 2
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ minItems: 2
+ maxItems: 2
+ items:
+ enum: [pclk, hclk]
+
+ atmel,vbus-gpio:
+ description: GPIO used to detect the presence of VBUS, indicating that
+ the USB cable is connected.
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/clock/at91.h>
+ #include <dt-bindings/gpio/gpio.h>
+ gadget@fff78000 {
+ compatible = "atmel,at91sam9g45-udc";
+ reg = <0x00600000 0x80000
+ 0xfff78000 0x400>;
+ interrupts = <27 IRQ_TYPE_LEVEL_HIGH 0>;
+ clocks = <&pmc PMC_TYPE_PERIPHERAL 27>, <&pmc PMC_TYPE_CORE PMC_UTMI>;
+ clock-names = "pclk", "hclk";
+ atmel,vbus-gpio = <&pioC 15 GPIO_ACTIVE_HIGH>;
+ };
+...
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
deleted file mode 100644
index ab353576d1de..000000000000
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-Atmel SOC USB controllers
-
-Atmel High-Speed USB device controller
-
-Required properties:
- - compatible: Should be one of the following
- "atmel,at91sam9rl-udc"
- "atmel,at91sam9g45-udc"
- "atmel,sama5d3-udc"
- "microchip,sam9x60-udc"
- "microchip,lan9662-udc"
- For "microchip,lan9662-udc" the fallback "atmel,sama5d3-udc"
- is required.
- - reg: Address and length of the register set for the device
- - interrupts: Should contain usba interrupt
- - clocks: Should reference the peripheral and host clocks
- - clock-names: Should contain two strings
- "pclk" for the peripheral clock
- "hclk" for the host clock
-
-Deprecated property:
- - ep childnode: To specify the number of endpoints and their properties.
-
-Optional properties:
- - atmel,vbus-gpio: If present, specifies a gpio that allows to detect whether
- vbus is present (USB is connected).
-
-Deprecated child node properties:
- - name: Name of the endpoint.
- - reg: Num of the endpoint.
- - atmel,fifo-size: Size of the fifo.
- - atmel,nb-banks: Number of banks.
- - atmel,can-dma: Boolean to specify if the endpoint support DMA.
- - atmel,can-isoc: Boolean to specify if the endpoint support ISOC.
-
-usb2: gadget@fff78000 {
- #address-cells = <1>;
- #size-cells = <0>;
- compatible = "atmel,at91sam9rl-udc";
- reg = <0x00600000 0x80000
- 0xfff78000 0x400>;
- interrupts = <27 4 0>;
- clocks = <&utmi>, <&udphs_clk>;
- clock-names = "hclk", "pclk";
- atmel,vbus-gpio = <&pioB 19 0>;
-};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v1 1/1] arm64: dts: imx91-var-dart-sonata: add RGB select supply for PCA6408
From: Frank Li @ 2026-03-27 16:51 UTC (permalink / raw)
To: Stefano Radaelli
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <20260327163243.17334-1-stefano.r@variscite.com>
On Fri, Mar 27, 2026 at 05:32:43PM +0100, Stefano Radaelli wrote:
> From: Stefano Radaelli <stefano.r@variscite.com>
>
> RGB_SEL controls the routing of some carrier board lines on the Sonata
> board. The two PCA6408 GPIO expanders depend on that path being enabled,
> so describe the selector as a fixed regulator and use it as their
> vcc-supply.
Does below resolve your problem?
https://lore.kernel.org/imx/20260325-pinctrl-mux-v4-0-043c2c82e623@nxp.com/
So needn't hack select as regualtor
Frank
>
> Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
> ---
> arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts | 9 +++++++++
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
> index afa39dab240a..3b5816884f24 100644
> --- a/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
> +++ b/arch/arm64/boot/dts/freescale/imx91-var-dart-sonata.dts
> @@ -90,6 +90,13 @@ reg_vref_1v8: regulator-adc-vref {
> regulator-max-microvolt = <1800000>;
> };
>
> + reg_rgb_sel: regulator-rgb-sel {
> + compatible = "regulator-fixed";
> + regulator-name = "rgb-select";
> + gpio = <&pca9534 7 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
> compatible = "regulator-fixed";
> pinctrl-names = "default";
> @@ -195,6 +202,7 @@ pca6408_1: gpio@20 {
> #gpio-cells = <2>;
> interrupt-parent = <&gpio1>;
> interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
> + vcc-supply = <®_rgb_sel>;
> };
>
> pca6408_2: gpio@21 {
> @@ -204,6 +212,7 @@ pca6408_2: gpio@21 {
> #gpio-cells = <2>;
> interrupt-parent = <&gpio1>;
> interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
> + vcc-supply = <®_rgb_sel>;
> };
>
> pca9534: gpio@22 {
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v2 3/4] elf: align ET_DYN base to max folio size for PTE coalescing
From: Usama Arif @ 2026-03-27 16:51 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Andrew Morton, david, ryan.roberts, linux-mm, r, jack, ajd,
apopple, baohua, baolin.wang, brauner, catalin.marinas, dev.jain,
kees, kevin.brodsky, lance.yang, Liam.Howlett, linux-arm-kernel,
linux-fsdevel, linux-kernel, lorenzo.stoakes, mhocko, npache,
pasha.tatashin, rmclure, rppt, surenb, vbabka, Al Viro,
wilts.infradead.org, ziy, hannes, kas, shakeel.butt, kernel-team
In-Reply-To: <ab1uqdcMBP1cBr7Q@casper.infradead.org>
On 20/03/2026 18:58, Matthew Wilcox wrote:
> On Fri, Mar 20, 2026 at 06:58:53AM -0700, Usama Arif wrote:
>> -static unsigned long maximum_alignment(struct elf_phdr *cmds, int nr)
>> +static unsigned long maximum_alignment(struct elf_phdr *cmds, int nr,
>> + struct file *filp)
>> {
>> unsigned long alignment = 0;
>> + unsigned long max_folio_size = PAGE_SIZE;
>> int i;
>>
>> + if (filp && filp->f_mapping)
>> + max_folio_size = mapping_max_folio_size(filp->f_mapping);
>
> Under what circumstances can bprm->file be NULL?
Yeah its unnecessary here. Its used in other places and this is never
checked, so we can remove it.
>
> Also we tend to prefer the name "file" rather than "filp" for new code
> (yes, there's a lot of old code out there).
>
ack. will change in next revision.
>> +
>> + /*
>> + * Try to align the binary to the largest folio
>> + * size that the page cache supports, so the
>> + * hardware can coalesce PTEs (e.g. arm64
>> + * contpte) or use PMD mappings for large folios.
>> + *
>> + * Use the largest power-of-2 that fits within
>> + * the segment size, capped by what the page
>> + * cache will allocate. Only align when the
>> + * segment's virtual address and file offset are
>> + * already aligned to the folio size, as
>> + * misalignment would prevent coalescing anyway.
>> + *
>> + * The segment size check avoids reducing ASLR
>> + * entropy for small binaries that cannot
>> + * benefit.
>> + */
>> + if (!cmds[i].p_filesz)
>> + continue;
>> + size = rounddown_pow_of_two(cmds[i].p_filesz);
>> + size = min(size, max_folio_size);
>> + if (size > PAGE_SIZE &&
>> + IS_ALIGNED(cmds[i].p_vaddr, size) &&
>> + IS_ALIGNED(cmds[i].p_offset, size))
>> + alignment = max(alignment, size);
>
> Can this not all be factored out into a different function? Also, I
> think it was done a bit better here:
> https://lore.kernel.org/linux-fsdevel/20260313005211.882831-1-r@hev.cc/
>
> + if (!IS_ALIGNED(cmd->p_vaddr | cmd->p_offset, PMD_SIZE))
> + return false;
>
ack, will try and address this accordingly.
Thanks for the reviews!!
^ permalink raw reply
* Re: [PATCH v2 3/4] elf: align ET_DYN base to max folio size for PTE coalescing
From: Usama Arif @ 2026-03-27 16:53 UTC (permalink / raw)
To: WANG Rui
Cc: Liam.Howlett, ajd, akpm, apopple, baohua, baolin.wang, brauner,
catalin.marinas, david, dev.jain, jack, kees, kevin.brodsky,
lance.yang, linux-arm-kernel, linux-fsdevel, linux-fsdevel,
linux-kernel, linux-mm, lorenzo.stoakes, mhocko, npache,
pasha.tatashin, rmclure, rppt, ryan.roberts, surenb, vbabka, viro,
willy
In-Reply-To: <20260320160519.80962-1-r@hev.cc>
On 20/03/2026 19:05, WANG Rui wrote:
> Hi Usama,
>
> On Fri, Mar 20, 2026 at 10:04 PM Usama Arif <usama.arif@linux.dev> wrote:
>> diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
>> index 8e89cc5b28200..042af81766fcd 100644
>> --- a/fs/binfmt_elf.c
>> +++ b/fs/binfmt_elf.c
>> @@ -49,6 +49,7 @@
>> #include <uapi/linux/rseq.h>
>> #include <asm/param.h>
>> #include <asm/page.h>
>> +#include <linux/pagemap.h>
>>
>> #ifndef ELF_COMPAT
>> #define ELF_COMPAT 0
>> @@ -488,19 +489,51 @@ static int elf_read(struct file *file, void *buf, size_t len, loff_t pos)
>> return 0;
>> }
>>
>> -static unsigned long maximum_alignment(struct elf_phdr *cmds, int nr)
>> +static unsigned long maximum_alignment(struct elf_phdr *cmds, int nr,
>> + struct file *filp)
>> {
>> unsigned long alignment = 0;
>> + unsigned long max_folio_size = PAGE_SIZE;
>> int i;
>>
>> + if (filp && filp->f_mapping)
>> + max_folio_size = mapping_max_folio_size(filp->f_mapping);
>
> From experiments (with 16K base pages), mapping_max_folio_size() appears to
> depend on the filesystem. It returns 8M on ext4, while on btrfs it always
> falls back to PAGE_SIZE (it seems CONFIG_BTRFS_EXPERIMENTAL=y may change this).
> This looks overly conservative and ends up missing practical optimization
> opportunities.
mapping_max_folio_size() reflects what the page cache will actually
allocate for a given filesystem, since readahead caps folio allocation
at mapping_max_folio_order() (in page_cache_ra_order()). If btrfs
reports PAGE_SIZE, readahead won't allocate large folios for it, so
there are no large folios to coalesce PTEs for, aligning the binary
beyond that would only reduce ASLR entropy for no benefit.
I don't think we should over-align binaries on filesystems that can't
take advantage of it.
>
>> +
>> for (i = 0; i < nr; i++) {
>> if (cmds[i].p_type == PT_LOAD) {
>> unsigned long p_align = cmds[i].p_align;
>> + unsigned long size;
>>
>> /* skip non-power of two alignments as invalid */
>> if (!is_power_of_2(p_align))
>> continue;
>> alignment = max(alignment, p_align);
>> +
>> + /*
>> + * Try to align the binary to the largest folio
>> + * size that the page cache supports, so the
>> + * hardware can coalesce PTEs (e.g. arm64
>> + * contpte) or use PMD mappings for large folios.
>> + *
>> + * Use the largest power-of-2 that fits within
>> + * the segment size, capped by what the page
>> + * cache will allocate. Only align when the
>> + * segment's virtual address and file offset are
>> + * already aligned to the folio size, as
>> + * misalignment would prevent coalescing anyway.
>> + *
>> + * The segment size check avoids reducing ASLR
>> + * entropy for small binaries that cannot
>> + * benefit.
>> + */
>> + if (!cmds[i].p_filesz)
>> + continue;
>> + size = rounddown_pow_of_two(cmds[i].p_filesz);
>> + size = min(size, max_folio_size);
>> + if (size > PAGE_SIZE &&
>> + IS_ALIGNED(cmds[i].p_vaddr, size) &&
>> + IS_ALIGNED(cmds[i].p_offset, size))
>> + alignment = max(alignment, size);
>
> In my patch [1], by aligning eligible segments to PMD_SIZE, THP can quickly
> collapse them into large mappings with minimal warmup. That doesn’t happen
> with the current behavior. I think allowing a reasonably sized PMD (say <= 32M)
> is worth considering. All we really need here is to ensure virtual address
> alignment. The rest can be left to THP under always, which can decide whether
> to collapse or not based on memory pressure and other factors.
>
> [1] https://lore.kernel.org/linux-fsdevel/20260313005211.882831-1-r@hev.cc
>
>> }
>> }
>>
>> @@ -1104,7 +1137,8 @@ static int load_elf_binary(struct linux_binprm *bprm)
>> }
>>
>> /* Calculate any requested alignment. */
>> - alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum);
>> + alignment = maximum_alignment(elf_phdata, elf_ex->e_phnum,
>> + bprm->file);
>>
>> /**
>> * DOC: PIE handling
>> --
>> 2.52.0
>>
>
> Thanks,
> Rui
^ permalink raw reply
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Frank Li @ 2026-03-27 16:54 UTC (permalink / raw)
To: Conor Dooley
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <20260327-overdrawn-stretch-2311ec39aa58@spud>
On Fri, Mar 27, 2026 at 12:09:32AM +0000, Conor Dooley wrote:
> On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
> > Refactor pinctrl_generic_pins_function_dt_subnode_to_map() by separating DT
> > parsing logic from map creation. Introduce a new helper
> > pinctrl_generic_to_map() to handle mapping to kernel data structures, while
> > keeping DT property parsing in the subnode function.
> >
> > Improve code structure and enables easier reuse for platforms using
> > different DT properties (e.g. pinmux) without modifying the
> > dt_node_to_map-style callback API. Avoid unnecessary coupling to
> > pinctrl_generic_pins_function_dt_node_to_map(), which provides
> > functionality not needed when the phandle target is unambiguous.
> >
> > Maximize code reuse and provide a cleaner extension point for future
> > pinctrl drivers.
> >
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > ---
> > change in v4
> > - new patch
> > ---
> > drivers/pinctrl/pinconf.h | 18 ++++++++
> > drivers/pinctrl/pinctrl-generic.c | 91 ++++++++++++++++++++++++---------------
> > 2 files changed, 74 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h
> > index 2880adef476e68950ffdd540ea42cdee6a16ec27..ffdabddb9660324ed8886a2e8dcacff7e1c6c529 100644
> > --- a/drivers/pinctrl/pinconf.h
> > +++ b/drivers/pinctrl/pinconf.h
> > @@ -166,6 +166,13 @@ int pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> > struct device_node *np,
> > struct pinctrl_map **maps,
> > unsigned int *num_maps);
> > +
> > +int
> > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> > + struct device_node *np, struct pinctrl_map **maps,
> > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > + const char **group_name, unsigned int ngroups,
> > + const char **functions, unsigned int *pins);
> > #else
> > static inline int
> > pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> > @@ -175,4 +182,15 @@ pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> > {
> > return -ENOTSUPP;
> > }
> > +
> > +static inline int
> > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> > + struct device_node *np, struct pinctrl_map **maps,
> > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > + const char **group_name, unsigned int ngroups,
> > + const char **functions, unsigned int *pins,
> > + void *function_data)
> > +{
> > + return -ENOTSUPP;
> > +}
> > #endif
> > diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> > index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> > --- a/drivers/pinctrl/pinctrl-generic.c
> > +++ b/drivers/pinctrl/pinctrl-generic.c
> > @@ -17,29 +17,18 @@
> > #include "pinctrl-utils.h"
> > #include "pinmux.h"
> >
> > -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> > - struct device_node *parent,
> > - struct device_node *np,
> > - struct pinctrl_map **maps,
> > - unsigned int *num_maps,
> > - unsigned int *num_reserved_maps,
> > - const char **group_names,
> > - unsigned int ngroups)
> > +int
> > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> > + struct device_node *np, struct pinctrl_map **maps,
> > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > + const char **group_names, unsigned int ngroups,
> > + const char **functions, unsigned int *pins)
>
> npins needs to be an argument to this function also, otherwise
> pinctrl_generic_add_group() uses it uninitialised...
Is this one the root cause of then broken? I am not sure why compiler have
not report waring for it.
Frank
> >
^ permalink raw reply
* Re: [RFT PATCH v3] ARM: omap1: enable real software node lookup of GPIOs on Nokia 770
From: Aaro Koskinen @ 2026-03-27 16:59 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Janusz Krzysztofik, Arnd Bergmann, Bartosz Golaszewski,
Tony Lindgren, Russell King, Dmitry Torokhov, Hans de Goede,
Linux-OMAP, linux-arm-kernel, linux-kernel, Kevin Hilman
In-Reply-To: <CAMRc=McDdK8Y7wtG8WObjD6WF-2ftKBDwKbvj=xL-NMfeV=bPQ@mail.gmail.com>
Hi,
On Fri, Mar 27, 2026 at 03:22:12PM +0100, Bartosz Golaszewski wrote:
> Hmm, I'm wondering if there's a race with consumers already requesting
> the GPIOs after the controller device is registered but before the
> software node is added. I'll send a version with software nodes being
> registered first, then passes as firmware nodes to the platform device
> API before the device is registered.
It crashes early, I was able to get an UART log from OSK (another
16xx board):
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 7.0.0-rc5-osk-00010-g9a0a87d27dc0 (aakoskin@lonestar) (arm-linux-gnueabi-gcc (GCC) 13.4.0, GNU ld (GNU Binutils) 2.45) #1 2026-03-26
[ 0.000000] CPU: ARM926EJ-S [41069263] revision 3 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine: TI-OSK
[ 0.000000] Ignoring tag cmdline (using the default kernel command line)
[ 0.000000] printk: legacy bootconsole [earlycon0] enabled
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] OMAP1611b revision 2 handled as 16xx id: 8d058f7948920905
[ 0.000000] Zone ranges:
[ 0.000000] Normal [mem 0x0000000010000000-0x0000000011ffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x0000000011ffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x0000000011ffffff]
[ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Kernel command line: mem=32M console=ttyS0,115200 earlyprintk initcall_debug loglevel=9
[ 0.000000] printk: log buffer data + meta data: 131072 + 409600 = 540672 bytes
[ 0.000000] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes, linear)
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 8192
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] Total of 128 interrupts in 4 interrupt banks
[ 0.000000] Clocks: ARM_SYSST: 0x1000 DPLL_CTL: 0x2833 ARM_CKCTL: 0x2000
[ 0.000000] Clocking rate (xtal/DPLL1/MPU): 12.0/96.0/96.0 MHz
[ 0.000000] clocksource: 32k_counter: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 58327039986419 ns
[ 0.000030] sched_clock: 32 bits at 33kHz, resolution 30517ns, wraps every 65535999984741ns
[ 0.008880] OMAP clocksource: 32k_counter at 32768 Hz
[ 0.015106] Calibrating delay loop... 47.51 BogoMIPS (lpj=237568)
[ 0.130798] CPU: Testing write buffer coherency: ok
[ 0.137451] pid_max: default: 32768 minimum: 301
[ 0.144683] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.152648] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes, linear)
[ 0.166381] VFS: Finished mounting rootfs on nullfs
[ 0.197753] entering initcall level: early
[ 0.202270] calling allocate_overflow_stacks+0x0/0x50 @ 1
[ 0.209045] initcall allocate_overflow_stacks+0x0/0x50 returned 0 after 0 usecs
[ 0.217315] calling init_static_idmap+0x0/0x118 @ 1
[ 0.223144] Setting up static identity map for 0x10008400 - 0x1000843c
[ 0.230438] initcall init_static_idmap+0x0/0x118 returned 0 after 10000 usecs
[ 0.238555] calling spawn_ksoftirqd+0x0/0x70 @ 1
[ 0.246643] initcall spawn_ksoftirqd+0x0/0x70 returned 0 after 10000 usecs
[ 0.254516] calling init_signal_sysctls+0x0/0x4c @ 1
[ 0.260589] initcall init_signal_sysctls+0x0/0x4c returned 0 after 0 usecs
[ 0.268432] calling init_umh_sysctls+0x0/0x2c @ 1
[ 0.274139] initcall init_umh_sysctls+0x0/0x2c returned 0 after 10000 usecs
[ 0.281799] calling kthreads_init+0x0/0x34 @ 1
[ 0.287139] initcall kthreads_init+0x0/0x34 returned 0 after 0 usecs
[ 0.294372] calling migration_init+0x0/0x2c @ 1
[ 0.299560] initcall migration_init+0x0/0x2c returned 0 after 0 usecs
[ 0.306823] calling printk_set_kthreads_ready+0x0/0x34 @ 1
[ 0.312957] initcall printk_set_kthreads_ready+0x0/0x34 returned 0 after 0 usecs
[ 0.321105] calling irq_work_init_threads+0x0/0x8 @ 1
[ 0.326995] initcall irq_work_init_threads+0x0/0x8 returned 0 after 0 usecs
[ 0.334777] calling init_zero_pfn+0x0/0x2c @ 1
[ 0.339813] initcall init_zero_pfn+0x0/0x2c returned 0 after 0 usecs
[ 0.346954] calling init_fs_inode_sysctls+0x0/0x2c @ 1
[ 0.352874] initcall init_fs_inode_sysctls+0x0/0x2c returned 0 after 0 usecs
[ 0.360809] calling init_fs_locks_sysctls+0x0/0x2c @ 1
[ 0.366943] initcall init_fs_locks_sysctls+0x0/0x2c returned 0 after 0 usecs
[ 0.374938] calling init_fs_sysctls+0x0/0x2c @ 1
[ 0.380310] initcall init_fs_sysctls+0x0/0x2c returned 0 after 0 usecs
[ 0.389282] Memory: 24296K/32768K available (4054K kernel code, 525K rwdata, 888K rodata, 1688K init, 197K bss, 7868K reserved, 0K cma-reserved)
[ 0.408447] devtmpfs: initialized
[ 0.428741] entering initcall level: pure
[ 0.433135] calling ipc_ns_init+0x0/0x40 @ 1
[ 0.438537] initcall ipc_ns_init+0x0/0x40 returned 0 after 0 usecs
[ 0.445617] calling mmap_min_addr_init+0x0/0x44 @ 1
[ 0.451202] initcall mmap_min_addr_init+0x0/0x44 returned 0 after 0 usecs
[ 0.458801] calling pci_realloc_setup_params+0x0/0x48 @ 1
[ 0.465057] initcall pci_realloc_setup_params+0x0/0x48 returned 0 after 0 usecs
[ 0.472991] calling inet_frag_wq_init+0x0/0x4c @ 1
[ 0.480957] initcall inet_frag_wq_init+0x0/0x4c returned 0 after 0 usecs
[ 0.489318] entering initcall level: core
[ 0.493927] calling ptrace_break_init+0x0/0x2c @ 1
[ 0.499328] initcall ptrace_break_init+0x0/0x2c returned 0 after 0 usecs
[ 0.506805] calling omap1_pm_runtime_init+0x0/0x20 @ 1
[ 0.513122] initcall omap1_pm_runtime_init+0x0/0x20 returned 0 after 0 usecs
[ 0.521118] calling wq_sysfs_init+0x0/0x14 @ 1
[ 0.527404] initcall wq_sysfs_init+0x0/0x14 returned 0 after 0 usecs
[ 0.534698] calling ksysfs_init+0x0/0x9c @ 1
[ 0.540008] initcall ksysfs_init+0x0/0x9c returned 0 after 0 usecs
[ 0.547088] calling init_jiffies_clocksource+0x0/0x14 @ 1
[ 0.553131] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.564086] initcall init_jiffies_clocksource+0x0/0x14 returned 0 after 20000 usecs
[ 0.572387] calling posixtimer_init+0x0/0xd4 @ 1
[ 0.578155] posixtimers hash table entries: 512 (order: 0, 2048 bytes, linear)
[ 0.586212] initcall posixtimer_init+0x0/0xd4 returned 0 after 10000 usecs
[ 0.593994] calling futex_init+0x0/0xa0 @ 1
[ 0.598876] futex hash table entries: 256 (4096 bytes on 1 NUMA nodes, total 4 KiB, linear).
[ 0.608123] initcall futex_init+0x0/0xa0 returned 0 after 10000 usecs
[ 0.615386] calling cgroup_wq_init+0x0/0x78 @ 1
[ 0.620819] initcall cgroup_wq_init+0x0/0x78 returned 0 after 0 usecs
[ 0.628112] calling cgroup1_wq_init+0x0/0x38 @ 1
[ 0.633758] initcall cgroup1_wq_init+0x0/0x38 returned 0 after 0 usecs
[ 0.640899] calling fsnotify_init+0x0/0x30 @ 1
[ 0.646606] initcall fsnotify_init+0x0/0x30 returned 0 after 0 usecs
[ 0.653961] calling filelock_init+0x0/0xf8 @ 1
[ 0.659484] initcall filelock_init+0x0/0xf8 returned 0 after 0 usecs
[ 0.666839] calling init_script_binfmt+0x0/0x1c @ 1
[ 0.672393] initcall init_script_binfmt+0x0/0x1c returned 0 after 0 usecs
[ 0.680114] calling init_elf_binfmt+0x0/0x1c @ 1
[ 0.685699] initcall init_elf_binfmt+0x0/0x1c returned 0 after 0 usecs
[ 0.692901] calling gpiolib_dev_init+0x0/0x110 @ 1
[ 0.699584] initcall gpiolib_dev_init+0x0/0x110 returned 0 after 0 usecs
[ 0.707244] calling sock_init+0x0/0x108 @ 1
[ 0.714630] initcall sock_init+0x0/0x108 returned 0 after 10000 usecs
[ 0.721862] calling sock_struct_check+0x0/0x8 @ 1
[ 0.727539] initcall sock_struct_check+0x0/0x8 returned 0 after 0 usecs
[ 0.735107] calling net_inuse_init+0x0/0x24 @ 1
[ 0.740417] initcall net_inuse_init+0x0/0x24 returned 0 after 0 usecs
[ 0.747802] calling init_default_flow_dissectors+0x0/0x4c @ 1
[ 0.754577] initcall init_default_flow_dissectors+0x0/0x4c returned 0 after 0 usecs
[ 0.763244] calling netlink_proto_init+0x0/0xf8 @ 1
[ 0.774932] NET: Registered PF_NETLINK/PF_ROUTE protocol family
[ 0.781799] initcall netlink_proto_init+0x0/0xf8 returned 0 after 10000 usecs
[ 0.789947] calling genl_init+0x0/0x38 @ 1
[ 0.795166] initcall genl_init+0x0/0x38 returned 0 after 0 usecs
[ 0.802490] entering initcall level: postcore
[ 0.807495] calling atomic_pool_init+0x0/0x134 @ 1
[ 0.816711] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.824401] initcall atomic_pool_init+0x0/0x134 returned 0 after 10000 usecs
[ 0.832092] calling omap16xx_gpio_init+0x0/0xe4 @ 1
[ 0.838867] 8<--- cut here ---
[ 0.842224] Unable to handle kernel NULL pointer dereference at virtual address 00000000 when read
[ 0.851989] [00000000] *pgd=00000000
[ 0.856262] Internal error: Oops: 5 [#1] ARM
[ 0.860931] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5-osk-00010-g9a0a87d27dc0 #1 VOLUNTARY
[ 0.871368] Hardware name: TI-OSK
[ 0.874938] PC is at software_node_to_swnode+0x10/0x48
[ 0.880554] LR is at device_add_software_node+0x20/0x80
[ 0.886230] pc : [<c0273f10>] lr : [<c0274f20>] psr: a0000053
[ 0.892883] sp : c2809ed0 ip : c2809d94 fp : c052e6ec
[ 0.898437] r10: 00000000 r9 : 00000014 r8 : c052bae8
[ 0.903991] r7 : 00000005 r6 : c03fe9d4 r5 : c06b3ab0 r4 : c072d000
[ 0.910919] r3 : c0759b10 r2 : 00000000 r1 : c03fe9d4 r0 : c03fe9d4
[ 0.917846] Flags: NzCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none
[ 0.925506] Control: 0005317f Table: 10004000 DAC: 00000053
[ 0.931579] Register r0 information: non-slab/vmalloc memory
[ 0.937713] Register r1 information: non-slab/vmalloc memory
[ 0.943786] Register r2 information: NULL pointer
[ 0.948883] Register r3 information: non-slab/vmalloc memory
[ 0.954956] Register r4 information: non-slab/vmalloc memory
[ 0.961029] Register r5 information: non-slab/vmalloc memory
[ 0.967132] Register r6 information: non-slab/vmalloc memory
[ 0.973205] Register r7 information: non-paged memory
[ 0.978637] Register r8 information: non-slab/vmalloc memory
[ 0.984710] Register r9 information: non-paged memory
[ 0.990173] Register r10 information: NULL pointer
[ 0.995330] Register r11 information: non-slab/vmalloc memory
[ 1.001525] Register r12 information: 2-page vmalloc region starting at 0xc2808000 allocated at kernel_clone+0xa4/0x20c
[ 1.013092] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
[ 1.019500] Stack: (0xc2809ed0 to 0xc280a000)
[ 1.024230] 9ec0: c072d000 c0529474 c06b3aa0 c050a3cc
[ 1.032958] 9ee0: c072d000 c085c000 00000002 c052582c c050a324 c072d000 00000000 c0503160
[ 1.041687] 9f00: 00002710 00000000 c04da8f8 c0060900 c2809f64 ffffffff 00010000 946f70b5
[ 1.050384] 9f20: 00000062 c0816120 00000002 c052582c c0525848 c072d000 c04da8f8 c0060a18
[ 1.059112] 9f40: c2809f64 c2809f64 00000000 946f70b5 00000062 c0816120 00000002 c052582c
[ 1.067810] 9f60: c052584c c072d000 c04da8f8 c050352c 00000002 00000002 00000000 c0502400
[ 1.076507] 9f80: c2809f7c 00000000 c03f86f4 00000000 00000000 00000000 00000000 00000000
[ 1.085205] 9fa0: 00000000 c03f8704 00000000 c000850c 00000000 00000000 00000000 00000000
[ 1.093902] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.102600] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[ 1.111206] Call trace:
[ 1.111328] software_node_to_swnode from device_add_software_node+0x20/0x80
[ 1.121704] device_add_software_node from omap16xx_gpio_init+0xa8/0xe4
[ 1.128997] omap16xx_gpio_init from do_one_initcall+0x68/0x1f4
[ 1.135620] do_one_initcall from kernel_init_freeable+0x1ec/0x240
[ 1.142517] kernel_init_freeable from kernel_init+0x10/0x108
[ 1.148864] kernel_init from ret_from_fork+0x14/0x28
[ 1.154357] Exception stack(0xc2809fb0 to 0xc2809ff8)
[ 1.159820] 9fa0: 00000000 00000000 00000000 00000000
[ 1.168518] 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.177185] 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1.184295] Code: e3500000 012fff1e e59f3034 e5932000 (e5923000)
[ 1.191040] ---[ end trace 0000000000000000 ]---
[ 1.196350] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 1.204559] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]---
A.
^ permalink raw reply
* [PATCH RFC net-next] net: stmmac: qcom-ethqos: set clk_csr
From: Russell King (Oracle) @ 2026-03-27 17:02 UTC (permalink / raw)
To: Mohd Ayaan Anwar
Cc: Alexandre Torgue, Andrew Lunn, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, linux-arm-kernel, linux-arm-msm,
linux-stm32, netdev, Paolo Abeni
The clocks for qcom-ethqos return a rate of zero as firmware manages
their rate. According to hardware documentation, the clock which is
fed to the slave AHB interface can crange between 50 and 100MHz.
Currently, stmmac uses an undefined divisor value. Instead, use
STMMAC_CSR_60_100M which will mean we meet IEEE 802.3 specification
since this will generate between a 1.19MHz and 2.38MHz MDC clock for
this range. Add a comment describing this.
Link: https://lore.kernel.org/r/acGhQ0oui+dVRdLY@oss.qualcomm.com
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
---
This likely needs the qcom-ethqos 15 patch cleanup series.
I think this is what's needed to fix the MDC clocking issue. Please
review and test. Thanks.
drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
index ad3a983d2a08..ac7d6d3e205a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
@@ -764,6 +764,12 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
qcom_ethqos_set_sgmii_loopback(ethqos, true);
ethqos_set_func_clk_en(ethqos);
+ /* The clocks are controlled by firmware, so we don't know for certain
+ * what clock rate is being used. Hardware documentation mentions that
+ * the AHB slave clock will be in the range of 50 to 100MHz, which
+ * equates to a MDC between 1.19 and 2.38MHz.
+ */
+ plat_dat->clk_csr = STMMAC_CSR_60_100M;
plat_dat->bsp_priv = ethqos;
plat_dat->set_clk_tx_rate = ethqos_set_clk_tx_rate;
plat_dat->dump_debug_regs = rgmii_dump;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v4] crypto: testmgr - Add test vectors for authenc(hmac(md5),cbc(aes))
From: Aleksander Jan Bajkowski @ 2026-03-27 17:03 UTC (permalink / raw)
To: Herbert Xu
Cc: davem, mcoquelin.stm32, alexandre.torgue, linux-crypto,
linux-stm32, linux-arm-kernel, linux-kernel
In-Reply-To: <abToanZh-mkEjmJ-@gondor.apana.org.au>
Hi Herbert,
On 14/03/2026 05:47, Herbert Xu wrote:
> On Tue, Mar 03, 2026 at 07:48:44PM +0100, Aleksander Jan Bajkowski wrote:
>> Test vectors were generated starting from existing CBC(AES) test vectors
>> (RFC3602, NIST SP800-38A) and adding HMAC(MD5) computed with Python
>> script. Then, the results were double-checked on Mediatek MT7981 (safexcel)
>> and NXP P2020 (talitos). Both platforms pass self-tests.
>>
>> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
>> ---
>> v4:
>> - rename aes-generic -> aes-lib
>> v3:
>> - correct sha384 -> md5 in description
>> v2:
>> - rebase and resolve conflicts
>> ---
>> crypto/testmgr.c | 7 ++
>> crypto/testmgr.h | 255 +++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 262 insertions(+)
> The previous patch has already been applied. Please redo this
> as an incremental patch.
Checked the crypto tree, and this patch still isn't applied. I've sent
multiple test vectors, and you're probably referring to a another patch.
Should I send it again, or will you accept it as is?
By the way, that's the last one. As of now, all my routers have the
missing vectors added :)
Regards, Aleksander
^ permalink raw reply
* Re: Warning from free_reserved_area() in next-20260325+
From: Mike Rapoport @ 2026-03-27 17:12 UTC (permalink / raw)
To: Bert Karwatzki
Cc: linux-kernel, Liam.Howlett, akpm, andreas, ardb, bp, brauner,
catalin.marinas, chleroy, dave.hansen, davem, david, devicetree,
dvyukov, elver, glider, hannes, hpa, ilias.apalodimas, iommu,
jack, jackmanb, kasan-dev, linux-arm-kernel, linux-efi,
linux-fsdevel, linux-mm, linux-trace-kernel, linuxppc-dev,
lorenzo.stoakes, m.szyprowski, maddy, mhiramat, mhocko, mingo,
mpe, npiggin, robh, robin.murphy, saravanak, sparclinux, surenb,
tglx, vbabka, viro, will, x86, ziy
In-Reply-To: <20260327140109.7561-1-spasswolf@web.de>
Hi Bert,
On Fri, Mar 27, 2026 at 03:01:08PM +0100, Bert Karwatzki wrote:
> Starting with linux next-20260325 I see the following warning early in the
> boot process of a machine running debian stable (trixie) (except for the kernel):
Thanks for the report!
> [ 0.027118] [ T0] ------------[ cut here ]------------
> [ 0.027118] [ T0] Cannot free reserved memory because of deferred initialization of the memory map
> [ 0.027119] [ T0] WARNING: mm/memblock.c:904 at __free_reserved_area+0xa9/0xc0, CPU#0: swapper/0/0
> [ 0.027122] [ T0] Modules linked in:
> [ 0.027123] [ T0] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 7.0.0-rc5-next-20260326-master #385 PREEMPT_RT
> [ 0.027125] [ T0] Hardware name: ASUS System Product Name/ROG STRIX B850-F GAMING WIFI, BIOS 1627 02/05/2026
> [ 0.027125] [ T0] RIP: 0010:__free_reserved_area+0xa9/0xc0
> [ 0.027126] [ T0] Code: 48 89 df 48 89 ee e8 06 fe ff ff 48 89 c3 48 39 e8 72 a0 5b 4c 89 e8 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 48 8d 3d 97 c2 c6 00 <67> 48 0f b9 3a 45 31 ed eb df 66 66 2e 0f 1f 84 00 00 00 00 00 66
> [ 0.027127] [ T0] RSP: 0000:ffffffff9b203e98 EFLAGS: 00010202
> [ 0.027128] [ T0] RAX: 0000000e91c00001 RBX: ffffffff9b100c0f RCX: 0000000080000001
> [ 0.027128] [ T0] RDX: 00000000000000cc RSI: 0000000e2d42d000 RDI: ffffffff9b32ef60
> [ 0.027128] [ T0] RBP: ffff9eeafdd6fbc0 R08: 0000000000000000 R09: 0000000000000001
> [ 0.027129] [ T0] R10: 0000000000001000 R11: 8000000000000163 R12: 000000000000006f
> [ 0.027129] [ T0] R13: 0000000000000000 R14: 0000000000000045 R15: 000000005c8a1000
> [ 0.027129] [ T0] FS: 0000000000000000(0000) GS:ffff9eeb21c05000(0000) knlGS:0000000000000000
> [ 0.027130] [ T0] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 0.027130] [ T0] CR2: ffff9ee8ad801000 CR3: 0000000e2ce1e000 CR4: 0000000000f50ef0
> [ 0.027131] [ T0] PKRU: 55555554
> [ 0.027131] [ T0] Call Trace:
> [ 0.027132] [ T0] <TASK>
> [ 0.027132] [ T0] free_reserved_area+0x89/0xd0
> [ 0.027133] [ T0] alternative_instructions+0xee/0x110
> [ 0.027136] [ T0] arch_cpu_finalize_init+0x10f/0x160
> [ 0.027138] [ T0] start_kernel+0x686/0x710
> [ 0.027140] [ T0] x86_64_start_reservations+0x24/0x30
> [ 0.027141] [ T0] x86_64_start_kernel+0xd4/0xe0
> [ 0.027142] [ T0] common_startup_64+0x13e/0x141
> [ 0.027143] [ T0] </TASK>
> [ 0.027144] [ T0] ---[ end trace 0000000000000000 ]---
Does this patch fix it for you?
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index e87da25d1236..62936a3bde19 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -2448,19 +2448,31 @@ void __init alternative_instructions(void)
__smp_locks, __smp_locks_end,
_text, _etext);
}
+#endif
+ restart_nmi();
+ alternatives_patched = 1;
+
+ alt_reloc_selftest();
+}
+
+#ifdef CONFIG_SMP
+/*
+ * With CONFIG_DEFERRED_STRUCT_PAGE_INIT enabled we can free_init_pages() only
+ * after the deferred initialization of the memory map is complete.
+ */
+static int __init free_smp_locks(void)
+{
if (!uniproc_patched || num_possible_cpus() == 1) {
free_init_pages("SMP alternatives",
(unsigned long)__smp_locks,
(unsigned long)__smp_locks_end);
}
-#endif
- restart_nmi();
- alternatives_patched = 1;
-
- alt_reloc_selftest();
+ return 0;
}
+arch_initcall(free_smp_locks);
+#endif
/**
* text_poke_early - Update instructions on a live kernel at boot time
> Bert Karwatzki
--
Sincerely yours,
Mike.
^ permalink raw reply related
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-27 17:14 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <aca2UquiW9lFikhR@lizhi-Precision-Tower-5810>
[-- Attachment #1: Type: text/plain, Size: 4641 bytes --]
On Fri, Mar 27, 2026 at 12:54:42PM -0400, Frank Li wrote:
> On Fri, Mar 27, 2026 at 12:09:32AM +0000, Conor Dooley wrote:
> > On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
> > > Refactor pinctrl_generic_pins_function_dt_subnode_to_map() by separating DT
> > > parsing logic from map creation. Introduce a new helper
> > > pinctrl_generic_to_map() to handle mapping to kernel data structures, while
> > > keeping DT property parsing in the subnode function.
> > >
> > > Improve code structure and enables easier reuse for platforms using
> > > different DT properties (e.g. pinmux) without modifying the
> > > dt_node_to_map-style callback API. Avoid unnecessary coupling to
> > > pinctrl_generic_pins_function_dt_node_to_map(), which provides
> > > functionality not needed when the phandle target is unambiguous.
> > >
> > > Maximize code reuse and provide a cleaner extension point for future
> > > pinctrl drivers.
> > >
> > > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > > ---
> > > change in v4
> > > - new patch
> > > ---
> > > drivers/pinctrl/pinconf.h | 18 ++++++++
> > > drivers/pinctrl/pinctrl-generic.c | 91 ++++++++++++++++++++++++---------------
> > > 2 files changed, 74 insertions(+), 35 deletions(-)
> > >
> > > diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h
> > > index 2880adef476e68950ffdd540ea42cdee6a16ec27..ffdabddb9660324ed8886a2e8dcacff7e1c6c529 100644
> > > --- a/drivers/pinctrl/pinconf.h
> > > +++ b/drivers/pinctrl/pinconf.h
> > > @@ -166,6 +166,13 @@ int pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> > > struct device_node *np,
> > > struct pinctrl_map **maps,
> > > unsigned int *num_maps);
> > > +
> > > +int
> > > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> > > + struct device_node *np, struct pinctrl_map **maps,
> > > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > > + const char **group_name, unsigned int ngroups,
> > > + const char **functions, unsigned int *pins);
> > > #else
> > > static inline int
> > > pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> > > @@ -175,4 +182,15 @@ pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> > > {
> > > return -ENOTSUPP;
> > > }
> > > +
> > > +static inline int
> > > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> > > + struct device_node *np, struct pinctrl_map **maps,
> > > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > > + const char **group_name, unsigned int ngroups,
> > > + const char **functions, unsigned int *pins,
> > > + void *function_data)
> > > +{
> > > + return -ENOTSUPP;
> > > +}
> > > #endif
> > > diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> > > index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> > > --- a/drivers/pinctrl/pinctrl-generic.c
> > > +++ b/drivers/pinctrl/pinctrl-generic.c
> > > @@ -17,29 +17,18 @@
> > > #include "pinctrl-utils.h"
> > > #include "pinmux.h"
> > >
> > > -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> > > - struct device_node *parent,
> > > - struct device_node *np,
> > > - struct pinctrl_map **maps,
> > > - unsigned int *num_maps,
> > > - unsigned int *num_reserved_maps,
> > > - const char **group_names,
> > > - unsigned int ngroups)
> > > +int
> > > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> > > + struct device_node *np, struct pinctrl_map **maps,
> > > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > > + const char **group_names, unsigned int ngroups,
> > > + const char **functions, unsigned int *pins)
> >
> > npins needs to be an argument to this function also, otherwise
> > pinctrl_generic_add_group() uses it uninitialised...
>
> Is this one the root cause of then broken?
No, this is not the cause of the breakage. I can't believe I still have
to say that. Go read the code and you'll see why that allocation thing
is problematic.
> I am not sure why compiler have not report waring for it.
It did, that's how I found it. Used uninitialised warnings are normally
from clang, so your toolchain might not have seen it. clangd integration
with my editor is how I saw it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH] ARM: OMAP1: Fix DEBUG_LL and earlyprintk on OMAP16XX
From: Aaro Koskinen @ 2026-03-27 17:15 UTC (permalink / raw)
To: Janusz Krzysztofik, Tony Lindgren, Kevin Hilman, linux-omap
Cc: linux-arm-kernel, linux-kernel
On OMAP16XX, the UART enable bit shifts are written instead of the actual
bits. This breaks the boot when DEBUG_LL and earlyprintk is enabled;
the UART gets disabled and some random bits get enabled. Fix that.
Fixes: 34c86239b184 ("ARM: OMAP1: clock: Fix early UART rate issues")
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
arch/arm/mach-omap1/clock_data.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap1/clock_data.c b/arch/arm/mach-omap1/clock_data.c
index c58d200e4816..5203b047deac 100644
--- a/arch/arm/mach-omap1/clock_data.c
+++ b/arch/arm/mach-omap1/clock_data.c
@@ -700,8 +700,8 @@ int __init omap1_clk_init(void)
/* Make sure UART clocks are enabled early */
if (cpu_is_omap16xx())
omap_writel(omap_readl(MOD_CONF_CTRL_0) |
- CONF_MOD_UART1_CLK_MODE_R |
- CONF_MOD_UART3_CLK_MODE_R, MOD_CONF_CTRL_0);
+ (1 << CONF_MOD_UART1_CLK_MODE_R) |
+ (1 << CONF_MOD_UART3_CLK_MODE_R), MOD_CONF_CTRL_0);
#endif
/* USB_REQ_EN will be disabled later if necessary (usb_dc_ck) */
--
2.39.2
^ permalink raw reply related
* Re: [PATCH v1 1/1] arm64: dts: imx91-var-dart-sonata: add RGB select supply for PCA6408
From: Stefano Radaelli @ 2026-03-27 17:16 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam
In-Reply-To: <aca1jdx0DjmmHqFk@lizhi-Precision-Tower-5810>
Hi Frank,
On Fri, Mar 27, 2026 at 12:51:25PM -0400, Frank Li wrote:
> On Fri, Mar 27, 2026 at 05:32:43PM +0100, Stefano Radaelli wrote:
> > From: Stefano Radaelli <stefano.r@variscite.com>
> >
> > RGB_SEL controls the routing of some carrier board lines on the Sonata
> > board. The two PCA6408 GPIO expanders depend on that path being enabled,
> > so describe the selector as a fixed regulator and use it as their
> > vcc-supply.
>
> Does below resolve your problem?
> https://lore.kernel.org/imx/20260325-pinctrl-mux-v4-0-043c2c82e623@nxp.com/
>
> So needn't hack select as regualtor
>
Thanks for pointing me your patch, interesting improvement!
Actually, in this case RGB_SEL is not meant to model a selectable mux
on the Sonata carrier.
On this board it must stay asserted permanently, otherwise the
downstream path to the two PCA6408 expanders is not accessible.
Modeling it as a mux might be confusing for users of the DART-MX91, as
as it would suggest that the routing is configurable, while on this
board it is actually fixed.
Best Regards,
Stefano
^ permalink raw reply
* Re: (subset) [PATCH v17 0/8] support FEAT_LSUI
From: Catalin Marinas @ 2026-03-27 17:18 UTC (permalink / raw)
To: Yeoreum Yun
Cc: linux-arm-kernel, linux-kernel, kvmarm, kvm, linux-kselftest,
will, maz, oupton, miko.lenczewski, kevin.brodsky, broonie, ardb,
suzuki.poulose, lpieralisi, joey.gouly, yuzenghui
In-Reply-To: <acaMex3Pq13njdRt@e129823.arm.com>
On Fri, Mar 27, 2026 at 01:56:11PM +0000, Yeoreum Yun wrote:
> > I decided to drop patch [6/8] (arm64: armv8_deprecated: disable swp
> > emulation when FEAT_LSUI present). The way FEAT_LSUI support looks now,
> > we still have uaccess_enable_privileged() working properly and we could
> > even support SWP emulation using exclusives. While it's highly unlikely
> > to see both 32-bit EL0 and FEAT_LSUI in practice,
>
> This is one of decisive reason to drop the swp emulation with LSUI
> (https://lore.kernel.org/all/aXDbBKhE1SdCW6q4@willie-the-truck/)
Ah, I forgot about this discussion. It's a valid point, I just thought
it's unnecessary given that __uaccess_disable_hw_pan() still works.
If we want strict no PAN, I can add it back (really small patch). I
wonder whether we should also add a
WARN_ON_ONCE(cpus_have_final_cap(ARM64_HAS_LSUI)) to the pan disabling
function. Not urgent though.
--
Catalin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox