* Re: [PATCH 1/7] x86/vdso: Respect COMPAT_32BIT_TIME
From: Arnd Bergmann @ 2026-04-13 15:59 UTC (permalink / raw)
To: Thomas Weißschuh
Cc: H. Peter Anvin, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, Russell King, Catalin Marinas,
Will Deacon, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, Christophe Leroy, Thomas Bogendoerfer,
Vincenzo Frascino, linux-kernel, linux-arm-kernel, linuxppc-dev,
linux-mips
In-Reply-To: <20260410091131-46b6354c-9d06-4e47-9345-ee224d8528f7@linutronix.de>
On Fri, Apr 10, 2026, at 09:24, Thomas Weißschuh wrote:
> On Tue, Mar 03, 2026 at 09:50:33PM +0100, Arnd Bergmann wrote:
>> On Tue, Mar 3, 2026, at 19:11, H. Peter Anvin wrote:
>> >
>> > The time zone in the kernel has never worked anyway, as it would require the
>> > kernel to contain at least the forward portion of the zoneinfo/tzdata table in
>> > order to actually work correctly. The only plausible use of it would be for
>> > local time-based filesystems like FAT, but I don't think we bother.
>> >
>> > A bigger question is whether or not we should omit these from the vDSO
>> > completely (potentially causing link failures) or replace them with stubs
>> > returning -ENOSYS.
>>
>> I see no harm in keeping gettimeofday() in the vdso when
>> COMPAT_32BIT_TIME is turned on, as existing code will call it
>> no matter whether it's in the vdso or the syscall.
>
> We would still always keep them for 64-bit ABIs, right?
Yes, I think we can't easily change that now. It was probably
a mistake to keep them in the generic syscall table after
we dropped them for 32-bit non-time32 targets, so riscv64
and loongarch should have not had these in the first place.
>> Equally, I see no point in having either version of
>> gettimeofday() or settimeofday() when COMPAT_32BIT_TIME is
>> disabled, as clearly anything calling it would pass incorrect
>> data for times past 2038.
>
> Should we also drop the syscalls in these cases?
> We will need to keep settimeofday() in some form to support the
> timewarping call done by init.
>
> Recap/Proposal:
>
> * Keep the gettimeofday()/time() syscalls when they are y2038 safe or
> CONFIG_COMPAT_32BIT_TIME is set.
> * The vDSO functions always mirror the systemcall availability.
These sound good.
> * Always provide settimeofday(). If CONFIG_COMPAT_32BIT_TIME is *not*
> set, reject passing any 'tv' argument where it may not be y2038 safe.
This sounds wrong to me now: the case I'm worried about is a 32-bit
system calling settimeofday() based on the value of an RTC or NTP.
The idea of CONFIG_COMPAT_32BIT_TIME=n is to catch this by causing
an intentional ENOSYS error even for valid times, so it doesn't
suddenly start breaking in 2038.
Arnd
^ permalink raw reply
* Re: [PATCH v4 2/4] pwm: sun50i: Add H616 PWM support
From: Paul Kocialkowski @ 2026-04-13 15:58 UTC (permalink / raw)
To: bigunclemax
Cc: richard.genoud, conor+dt, devicetree, jernej.skrabec, joao,
jstultz, krzk+dt, linux-arm-kernel, linux-kernel, linux-pwm,
linux-sunxi, p.zabel, robh, samuel, thomas.petazzoni,
u.kleine-koenig, wens
In-Reply-To: <20260413123920.2459916-1-bigunclemax@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
Hi Maksim,
On Mon 13 Apr 26, 15:39, bigunclemax@gmail.com wrote:
> > +
> > +/* PWM Capture Fall Lock Register */
> > +#define H616_PWM_CFLR(x) (0x74 + (x) * 0x20)
> > +
> > +#define H616_PWM_PAIR_IDX(chan) ((chan) >> 2)
> > +
>
> It looks like there's a typo or a mistake in the PAIR_IDX calculation.
> It should be like ((chan) >> 1).
> For example, for the 5th channel the result will be 1, but it should be 2.
Had a quick look at it too and I agree with you. A right shift by 2 essentially
groups pwms by 4, not 2. So pwms 2 and 3 would also be reported as part of
index 0.
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* RE: [PATCH 06/11] Drivers: hv: Make sint vector architecture neutral in MSHV_VTL
From: Michael Kelley @ 2026-04-13 15:49 UTC (permalink / raw)
To: Naman Jain, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <b5125f61-173f-45d0-a6dc-d795ba0f8693@linux.microsoft.com>
From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, April 13, 2026 4:48 AM
>
> On 4/1/2026 10:27 PM, Michael Kelley wrote:
> > From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026 5:13 AM
> >>
> >> Generalize Synthetic interrupt source vector (sint) to use
> >> vmbus_interrupt variable instead, which automatically takes care of
> >> architectures where HYPERVISOR_CALLBACK_VECTOR is not present (arm64).
> >
> > Sashiko AI raised an interesting question about the startup timing --
> > whether the vmbus_platform_driver_probe() is guaranteed to have
> > set vmbus_interrupt before the VTL functions below run and use it.
> > What causes the mshv_vtl.ko module to be loaded, and hence run
> > mshv_vtl_init()?
>
> There is no race condition here. The init ordering guarantees that
> vmbus_interrupt is always set before mshv_vtl_synic_enable_regs()
> reads it.
>
> The call chain for setting vmbus_interrupt:
>
> subsys_initcall(hv_acpi_init) [level 4]
> -> platform_driver_register(&vmbus_platform_driver) and so on.
>
>
> The call chain for reading vmbus_interrupt:
>
> module_init(mshv_vtl_init) [level 6]
> -> hv_vtl_setup_synic()
> -> cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, ..., mshv_vtl_alloc_context, ...)
> -> mshv_vtl_alloc_context()
> -> mshv_vtl_synic_enable_regs()
> -> sint.vector = vmbus_interrupt
>
> do_initcalls() processes sections in order 0 through 7, so
> hv_acpi_init() (level 4) is guaranteed to complete before
> mshv_vtl_init() (level 6) runs.
>
I think the situation is more complex than what you describe, depending
on whether the VMBus driver and/or MSHV_VTL are built as modules vs.
being built-in to the kernel image. In include/linux/module.h, see the
comment for module_init() and how subsys_initcall() is mapped
to module_init() when built as a module.
If both are built-in, then what you describe is correct. But if either or
both are modules, then the respective init functions (hv_acpi_init
and mshv_vtl_init) get called at the time the module is loaded, and
not by do_initcalls(). I think hv_vmbus.ko gets loaded when an attempt
is first made to access a disk, but I would need to look more closely to
be sure. I don't have any understanding of what causes mshv_vtl.ko
to be loaded. And what is the ordering if MSHV_VTL is built-in while
VMBus is built as a module, or vice versa?
Michael
^ permalink raw reply
* [PATCH] watchdog: ixp4xx: fix reference leak on platform_device_register() failure
From: Guangshuo Li @ 2026-04-13 15:47 UTC (permalink / raw)
To: Linus Walleij, Imre Kaloz, Daniel Lezcano, Thomas Gleixner,
Guenter Roeck, linux-arm-kernel, linux-kernel
Cc: Guangshuo Li, stable
ixp4xx_timer_probe() directly returns the result of
platform_device_register(&ixp4xx_watchdog_device). When registration
fails, the embedded struct device in ixp4xx_watchdog_device has already
been initialized by device_initialize(), but the failure path does not
drop the device reference, leading to a reference leak.
The issue was identified by a static analysis tool I developed and
confirmed by manual review. Fix this by calling platform_device_put()
when platform_device_register() fails.
Fixes: 21a0a29d16c67 ("watchdog: ixp4xx: Rewrite driver to use core")
Cc: stable@vger.kernel.org
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/clocksource/timer-ixp4xx.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/clocksource/timer-ixp4xx.c b/drivers/clocksource/timer-ixp4xx.c
index 720ed70a2964..924dbd58c4da 100644
--- a/drivers/clocksource/timer-ixp4xx.c
+++ b/drivers/clocksource/timer-ixp4xx.c
@@ -239,11 +239,16 @@ static struct platform_device ixp4xx_watchdog_device = {
static int ixp4xx_timer_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
+ int ret;
/* Pass the base address as platform data and nothing else */
ixp4xx_watchdog_device.dev.platform_data = local_ixp4xx_timer->base;
ixp4xx_watchdog_device.dev.parent = dev;
- return platform_device_register(&ixp4xx_watchdog_device);
+ ret = platform_device_register(&ixp4xx_watchdog_device);
+ if (ret)
+ platform_device_put(&ixp4xx_watchdog_device);
+
+ return ret;
}
static const struct of_device_id ixp4xx_timer_dt_id[] = {
--
2.43.0
^ permalink raw reply related
* [PATCH] arm64/hwcap: Include kernel-hwcap.h in list of generated files
From: Mark Brown @ 2026-04-13 15:44 UTC (permalink / raw)
To: Catalin Marinas, Will Deacon
Cc: Marek Vasut, linux-arm-kernel, linux-kernel, Mark Brown
When adding generation for the kernel internal constants for hwcaps the
generated file was not explicitly flagged as such in the build system,
causing it to be regenerated on each build. This wasn't obvious when the
series the change was included in was developed since it was all about
changes that trigger rebuilds anyway.
Fixes: abed23c3c44f5 (arm64/hwcap: Generate the KERNEL_HWCAP_ definitions for the hwcaps)
Reported-by: Marek Vasut <marex@nabladev.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
arch/arm64/include/asm/Kbuild | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index d2ff8f6c3231..31441790b808 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -17,4 +17,5 @@ generic-y += parport.h
generic-y += user.h
generated-y += cpucap-defs.h
+generated-y += kernel-hwcap.h
generated-y += sysreg-defs.h
---
base-commit: abed23c3c44f565dc812563ac015be70dd61e97b
change-id: 20260413-arm64-hwcap-gen-fix-ecb4bb6dbb91
Best regards,
--
Mark Brown <broonie@kernel.org>
^ permalink raw reply related
* Re: [PATCH v2 1/8] dt-bindings: thermal: amlogic: Add support for T7
From: Conor Dooley @ 2026-04-13 15:42 UTC (permalink / raw)
To: Ronald Claveau
Cc: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-pm, linux-amlogic, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260413-add-thermal-t7-vim4-v2-1-1002d90a0602@aliel.fr>
[-- Attachment #1: Type: text/plain, Size: 3361 bytes --]
On Mon, Apr 13, 2026 at 12:52:42PM +0200, Ronald Claveau wrote:
> Add the amlogic,t7-thermal compatible for the Amlogic T7 thermal sensor.
>
> Unlike existing variants which use a phandle to the ao-secure syscon,
> the T7 relies on a secure monitor interface described by a phandle and
> a sensor index argument.
>
> The T7 integrates multiple thermal sensors, all accessed through the
> same SMC call. The sensor index argument is required to identify which
> sensor's calibration data the secure monitor should return, as a single
> SM_THERMAL_CALIB_READ command serves all of them.
>
> Introduce the amlogic,secure-monitor property as a phandle-array and
> make amlogic,ao-secure or amlogic,secure-monitor conditionally required
> depending on the compatible.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> .../bindings/thermal/amlogic,thermal.yaml | 42 ++++++++++++++++++++--
> 1 file changed, 40 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> index 70b273271754b..1c096116b2dda 100644
> --- a/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> +++ b/Documentation/devicetree/bindings/thermal/amlogic,thermal.yaml
> @@ -21,7 +21,9 @@ properties:
> - amlogic,g12a-cpu-thermal
> - amlogic,g12a-ddr-thermal
> - const: amlogic,g12a-thermal
> - - const: amlogic,a1-cpu-thermal
> + - enum:
> + - amlogic,a1-cpu-thermal
> + - amlogic,t7-thermal
>
> reg:
> maxItems: 1
> @@ -42,12 +44,39 @@ properties:
> '#thermal-sensor-cells':
> const: 0
>
> + amlogic,secure-monitor:
> + description: phandle to the secure monitor
> + $ref: /schemas/types.yaml#/definitions/phandle-array
> + items:
> + - items:
> + - description: phandle to the secure monitor
> + - description: sensor index to get specific calibration data
> +
> required:
> - compatible
> - reg
> - interrupts
> - clocks
> - - amlogic,ao-secure
> +
> +allOf:
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - amlogic,a1-cpu-thermal
> + - amlogic,g12a-thermal
> + then:
> + required:
> + - amlogic,ao-secure
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: amlogic,t7-thermal
This can just be replaced by a else I think.
> + then:
> + required:
> + - amlogic,secure-monitor
>
> unevaluatedProperties: false
>
> @@ -62,4 +91,13 @@ examples:
> #thermal-sensor-cells = <0>;
> amlogic,ao-secure = <&sec_AO>;
> };
> + - |
> + a73_tsensor: temperature-sensor@20000 {
Can drop the label here, it has no users.
Otherwise, seems fine.
Cheers,
Conor.
pw-bot: changes-requested
> + compatible = "amlogic,t7-thermal";
> + reg = <0x0 0x20000 0x0 0x50>;
> + interrupts = <GIC_SPI 31 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clkc_periphs CLKID_TS>;
> + #thermal-sensor-cells = <0>;
> + amlogic,secure-monitor = <&sm 1>;
> + };
> ...
>
> --
> 2.49.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 RESEND 1/2] dt-bindings: phy: mediatek,xsphy: add property to set disconnect threshold
From: Conor Dooley @ 2026-04-13 15:40 UTC (permalink / raw)
To: Chunfeng Yun
Cc: Vinod Koul, AngeloGioacchino Del Regno, Neil Armstrong,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
linux-arm-kernel, linux-mediatek, linux-phy, devicetree,
linux-kernel
In-Reply-To: <20260413122836.4848-1-chunfeng.yun@mediatek.com>
[-- Attachment #1: Type: text/plain, Size: 1572 bytes --]
On Mon, Apr 13, 2026 at 08:28:35PM +0800, Chunfeng Yun wrote:
> Add a property to tune usb2 phy's disconnect threshold.
> And add a compatible for mt8196.
>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com>
> ---
> v2: change property name
> ---
> Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml
> index 0bed847bb4ad..9017a9c93eb9 100644
> --- a/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/mediatek,xsphy.yaml
> @@ -50,6 +50,7 @@ properties:
> - mediatek,mt3611-xsphy
> - mediatek,mt3612-xsphy
> - mediatek,mt7988-xsphy
> + - mediatek,mt8196-xsphy
> - const: mediatek,xsphy
>
> reg:
> @@ -130,6 +131,13 @@ patternProperties:
> minimum: 1
> maximum: 7
>
> + mediatek,disconnect-threshold:
> + description:
> + The selection of disconnect threshold (U2 phy)
Why is this unitless? What does the threshold represent? Time? Voltage?
Something else?
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 1
> + maximum: 15
> +
> mediatek,efuse-intr:
> description:
> The selection of Internal Resistor (U2/U3 phy)
> --
> 2.45.2
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] mm: split the file's i_mmap tree for NUMA
From: Mateusz Guzik @ 2026-04-13 15:33 UTC (permalink / raw)
To: Huang Shijie
Cc: akpm, viro, brauner, linux-mm, linux-kernel, linux-arm-kernel,
linux-fsdevel, muchun.song, osalvador, linux-trace-kernel,
linux-perf-users, linux-parisc, nvdimm, zhongyuan, fangbaoshun,
yingzhiwei
In-Reply-To: <20260413062042.804-1-huangsj@hygon.cn>
On Mon, Apr 13, 2026 at 02:20:39PM +0800, Huang Shijie wrote:
> In NUMA, there are maybe many NUMA nodes and many CPUs.
> For example, a Hygon's server has 12 NUMA nodes, and 384 CPUs.
> In the UnixBench tests, there is a test "execl" which tests
> the execve system call.
>
> When we test our server with "./Run -c 384 execl",
> the test result is not good enough. The i_mmap locks contended heavily on
> "libc.so" and "ld.so". For example, the i_mmap tree for "libc.so" can have
> over 6000 VMAs, all the VMAs can be in different NUMA mode.
> The insert/remove operations do not run quickly enough.
>
> patch 1 & patch 2 are try to hide the direct access of i_mmap.
> patch 3 splits the i_mmap into sibling trees, and we can get better
> performance with this patch set:
> we can get 77% performance improvement(10 times average)
>
To my reading you kept the lock as-is and only distributed the protected
state.
While I don't doubt the improvement, I'm confident should you take a
look at the profile you are going to find this still does not scale with
rwsem being one of the problems (there are other global locks, some of
which have experimental patches for).
Apart from that this does nothing to help high core systems which are
all one node, which imo puts another question mark on this specific
proposal.
Of course one may question whether a RB tree is the right choice here,
it may be the lock-protected cost can go way down with merely a better
data structure.
Regardless of that, for actual scalability, there will be no way around
decentralazing locking around this and partitioning per some core count
(not just by numa awareness).
Decentralizing locking is definitely possible, but I have not looked
into specifics of how problematic it is. Best case scenario it will
merely with separate locks. Worst case scenario something needs a fully
stabilized state for traversal, in that case another rw lock can be
slapped around this, creating locking order read lock -> per-subset
write lock -- this will suffer scalability due to the read locking, but
it will still scale drastically better as apart from that there will be
no serialization. In this setting the problematic consumer will write
lock the new thing to stabilize the state.
So my non-maintainer opinion is that the patchset is not worth it as it
fails to address anything for significantly more common and already
affected setups.
Have you looked into splitting the lock?
^ permalink raw reply
* Re: [patch 15/38] ptp: ptp_vmclock: Replace get_cycles() usage
From: David Woodhouse @ 2026-04-13 15:33 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik, netdev,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S. Miller, sparclinux
In-Reply-To: <20260410120318.592237447@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Fri, 2026-04-10 at 14:19 +0200, Thomas Gleixner wrote:
> get_cycles() is not really well defined and similar to other usaage of the
> underlying hardware CPU counters the PTP vmclock should use an explicit
> interface as well.
>
> Implement ptp_vmclock_read_cpu_counter() in arm64 and x86 and simplify the
> Kconfig selection while at it.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: David Woodhouse <dwmw2@infradead.org>
Acked-by: David Woodhouse <dwmw@amazon.co.uk>
Although I might follow up with a change to make this...
> +static inline u64 ptp_vmclock_read_cpu_counter(void)
> +{
> + return cpu_feature_enabled(X86_FEATURE_TSC) ? rdtsc() : 0;
> +}
> +
... depend on TSC_RELIABLE¹, since if the guest doesn't believe that it
is, then the guest shouldn't be trying to use it as the basis for
precise timing.
¹ (Or... one of the other zoo of TSC flags for the gradually reducing
brokenness over the years...)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH RFC 09/12] drm: Introduce drmm_connector_dp_init() with link training state properties
From: Kory Maincent @ 2026-04-13 15:30 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
David Airlie, Simona Vetter, Dave Airlie, Jesse Barnes,
Eric Anholt, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Chun-Kuang Hu, Philipp Zabel,
Matthias Brugger, AngeloGioacchino Del Regno, Chris Wilson,
Thomas Petazzoni, Mark Yacoub, Sean Paul, Louis Chauvet,
intel-gfx, intel-xe, dri-devel, linux-kernel, linux-mediatek,
linux-arm-kernel, Simona Vetter
In-Reply-To: <bwgzwwlmvlbtnl7qnmnjrkzjaifeyrhllnbjxh7txrd2o24aqi@2ykn2gwyatcx>
On Mon, 13 Apr 2026 16:59:43 +0300
Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> On Mon, Apr 13, 2026 at 02:59:30PM +0200, Kory Maincent wrote:
> > On Fri, 10 Apr 2026 00:53:08 +0300
> > Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> wrote:
> >
> > > On Thu, Apr 09, 2026 at 07:08:25PM +0200, Kory Maincent wrote:
> > > > Add a managed DisplayPort connector initialization helper,
> > > > drmm_connector_dp_init(), modeled after the existing HDMI counterpart
> > > > drmm_connector_hdmi_init(). Cleanup is handled automatically via a
> > > > DRM-managed action.
> > > >
> > > > The helper creates the following immutable connector properties to
> > > > expose DP link training capabilities and state to userspace:
> > > >
> > > > - num_lanes: bitmask of supported lane counts (1, 2, 4)
> > > > - link_rate: Array of supported link rates.
> > > > - dsc_en: Display Stream Compression supported
> > > > - voltage_swingN: per-lane voltage swing level bitmask
> > > > - pre-emphasisN: per-lane pre-emphasis level bitmask
> > > >
> > > > Link rates are passed by the driver in deca-kbps, following the DRM
> > > > convention, but exposed to userspace in kbps for clarity.
> > > >
> > > > Two additional helpers are provided to update and reset those properties
> > > > at runtime:
> > > > - drm_connector_dp_set_link_train_properties()
> > > > - drm_connector_dp_reset_link_train_properties()
> > > >
> >
> > ...
> >
> > > > +/**
> > > > + * struct drm_connector_dp_link_train - DRM DisplayPort link training
> > > > + * information report
> > > > + */
> > > > +struct drm_connector_dp_link_train {
> > >
> > > THese define the current DP state. As such, they definitely make sense
> > > to be a part of the drm_connector.
> > > > + /**
> > > > + * @nlanes: The number of lanes used
> > > > + */
> > > > + u8 nlanes;
> > > > +
> > > > + /**
> > > > + * @rates: Link rate value selected in deca-kbps
> > > > + */
> > > > + u32 rate;
> > > > +
> > > > + /**
> > > > + * @dsc: Display Stream Compression enabled
> > > > + */
> > > > + bool dsc_en;
> > > > +
> > > > + /**
> > > > + * @v_swings: Array listing the bitmask voltage swing level per
> > > > lanes
> > > > + */
> > > > + u8 v_swing[4];
> > > > +
> > > > + /**
> > > > + * @pre_emph: Array listing the bitmask pre-emphasis level per
> > > > lanes
> > > > + */
> > > > + u8 pre_emph[4];
> > >
> > > Please consider following struct phy_configure_opts_dp (or using it as
> > > is). Overall, please refer the talk and (more important) the lightning
> > > resumee at this XDC. I have some bits and pieces ready in spite of that
> > > proposal, but I didn't have time to finish it.
> >
> > I didn't know this phy_configure_opts_dp struct. This indeed could make
> > sense to reuse and modify that structure for our needs.
>
> Why would you want to modify it? It is an interface for the PHY drivers.
> Is there anything that you miss there?
I was thinking of the DSC, but after a quick look it is not done at the PHY
level therefore it won't land here.
> > About your XDC talk. What were the developments you were talking about?
> > Could I have a look at them?
>
> I've posted an RFC just before the XDC. Currently I'm looking at the
> link training generification. Overall, you don't have to wait for that
> job to be completed, just take some of the notes in account (like reuse
> of the PHY config structures).
Ok, have you a link? I can't find the related series.
Regards,
--
Köry Maincent, Bootlin
Embedded Linux and kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [patch 10/38] arcnet: Remove function timing code
From: David Woodhouse @ 2026-04-13 15:29 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Michael Grzeschik, netdev, Arnd Bergmann, x86, Lu Baolu, iommu,
linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S. Miller, sparclinux
In-Reply-To: <20260410120318.253872322@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 778 bytes --]
On Fri, 2026-04-10 at 14:19 +0200, Thomas Gleixner wrote:
> ARCNET is a museums piece and the function timing can be done with
> ftrace. Remove the cruft.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Michael Grzeschik <m.grzeschik@pengutronix.de>
> Cc: netdev@vger.kernel.org
> ---
> drivers/net/arcnet/arc-rimi.c | 4 ++--
> drivers/net/arcnet/arcdevice.h | 20 +-------------------
> drivers/net/arcnet/com20020.c | 6 ++----
> drivers/net/arcnet/com90io.c | 6 ++----
> drivers/net/arcnet/com90xx.c | 4 ++--
> 5 files changed, 9 insertions(+), 31 deletions(-)
Acked-by: David Woodhouse <dwmw2@infradead.org>
By coincidence, I took the last of my ARCNET cards to the tip just this
morning...
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH] mm/arm: pgtable: remove young bit check for pte_valid_user
From: Brian Ruley @ 2026-04-13 15:24 UTC (permalink / raw)
To: Will Deacon
Cc: Russell King (Oracle), Steve Capper, linux-arm-kernel,
linux-kernel, catalin.marinas
In-Reply-To: <adzMOdySgMIePcue@willie-the-truck>
On Apr 13, Will Deacon wrote:
>
> Brian, can you try something like 588a513d3425?
>
> Will
>
> [1] https://lore.kernel.org/all/YJGHApOCXl811VK3@arm.com/
Applied the fix and so far so good. We're going to run `stress-ng'
tests overnight to be sure. In the meanwhile, I'll see if I can add
some instrumentation to verify this is the bug we're seeing.
BR,
Brian
^ permalink raw reply
* Re: [PATCH] arm64: dts: exynos850: Add SRAM node
From: Krzysztof Kozlowski @ 2026-04-13 15:23 UTC (permalink / raw)
To: Alexey Klimov, Sam Protsenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alim Akhtar
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260413-exynos850_sram-v1-1-7fda5b7fb7d4@linaro.org>
On 13/04/2026 16:52, Alexey Klimov wrote:
> SRAM is used by the ACPM protocol to retrieve the ACPM channels
> information and configuration data. Add the SRAM node.
>
> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
> ---
> arch/arm64/boot/dts/exynos/exynos850.dtsi | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> index cb55015c8dce..cf4a6168846c 100644
> --- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
> +++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
> @@ -910,6 +910,14 @@ spi_2: spi@11d20000 {
> };
> };
> };
> +
> + apm_sram: sram@2039000 {
> + compatible = "mmio-sram";
> + reg = <0x0 0x2039000 0x40000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0x0 0x2039000 0x40000>;
You miss here children.
Also, 'ranges' should be after 'reg'.
Best regards,
Krzysztof
^ permalink raw reply
* RE: [PATCH 04/11] Drivers: hv: Refactor mshv_vtl for ARM64 support to be added
From: Michael Kelley @ 2026-04-13 15:19 UTC (permalink / raw)
To: Naman Jain, Michael Kelley, K . Y . Srinivasan, Haiyang Zhang,
Wei Liu, Dexuan Cui, Long Li, Catalin Marinas, Will Deacon,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
x86@kernel.org, H . Peter Anvin, Arnd Bergmann, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: Marc Zyngier, Timothy Hayes, Lorenzo Pieralisi, mrigendrachaubey,
ssengar@linux.microsoft.com, linux-hyperv@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <fe4c0663-4ece-439c-bcb6-cd5780c15ed9@linux.microsoft.com>
From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, April 13, 2026 4:46 AM
>
> On 4/1/2026 10:26 PM, Michael Kelley wrote:
> > From: Naman Jain <namjain@linux.microsoft.com> Sent: Monday, March 16, 2026
> 5:13 AM
> >>
> >> Refactor MSHV_VTL driver to move some of the x86 specific code to arch
> >> specific files, and add corresponding functions for arm64.
> >>
> >> Signed-off-by: Roman Kisel <romank@linux.microsoft.com>
> >> Signed-off-by: Naman Jain <namjain@linux.microsoft.com>
> >> ---
> >> arch/arm64/include/asm/mshyperv.h | 10 +++
> >> arch/x86/hyperv/hv_vtl.c | 98 ++++++++++++++++++++++++++++
> >> arch/x86/include/asm/mshyperv.h | 1 +
> >> drivers/hv/mshv_vtl_main.c | 102 +-----------------------------
> >> 4 files changed, 111 insertions(+), 100 deletions(-)
> >>
> >> diff --git a/arch/arm64/include/asm/mshyperv.h
> >> b/arch/arm64/include/asm/mshyperv.h
> >> index b721d3134ab6..804068e0941b 100644
> >> --- a/arch/arm64/include/asm/mshyperv.h
> >> +++ b/arch/arm64/include/asm/mshyperv.h
> >> @@ -60,6 +60,16 @@ static inline u64 hv_get_non_nested_msr(unsigned int reg)
> >> ARM_SMCCC_SMC_64, \
> >> ARM_SMCCC_OWNER_VENDOR_HYP, \
> >> HV_SMCCC_FUNC_NUMBER)
> >> +#ifdef CONFIG_HYPERV_VTL_MODE
> >> +/*
> >> + * Get/Set the register. If the function returns `1`, that must be done via
> >> + * a hypercall. Returning `0` means success.
> >> + */
> >> +static inline int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, u64 shared)
> >> +{
> >> + return 1;
> >> +}
> >> +#endif
> >>
> >> #include <asm-generic/mshyperv.h>
> >>
> >> diff --git a/arch/x86/hyperv/hv_vtl.c b/arch/x86/hyperv/hv_vtl.c
> >> index 9b6a9bc4ab76..72a0bb4ae0c7 100644
> >> --- a/arch/x86/hyperv/hv_vtl.c
> >> +++ b/arch/x86/hyperv/hv_vtl.c
> >> @@ -17,6 +17,8 @@
> >> #include <asm/realmode.h>
> >> #include <asm/reboot.h>
> >> #include <asm/smap.h>
> >> +#include <uapi/asm/mtrr.h>
> >> +#include <asm/debugreg.h>
> >> #include <linux/export.h>
> >> #include <../kernel/smpboot.h>
> >> #include "../../kernel/fpu/legacy.h"
> >> @@ -281,3 +283,99 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0)
> >> kernel_fpu_end();
> >> }
> >> EXPORT_SYMBOL(mshv_vtl_return_call);
> >> +
> >> +/* Static table mapping register names to their corresponding actions */
> >> +static const struct {
> >> + enum hv_register_name reg_name;
> >> + int debug_reg_num; /* -1 if not a debug register */
> >> + u32 msr_addr; /* 0 if not an MSR */
> >> +} reg_table[] = {
> >> + /* Debug registers */
> >> + {HV_X64_REGISTER_DR0, 0, 0},
> >> + {HV_X64_REGISTER_DR1, 1, 0},
> >> + {HV_X64_REGISTER_DR2, 2, 0},
> >> + {HV_X64_REGISTER_DR3, 3, 0},
> >> + {HV_X64_REGISTER_DR6, 6, 0},
> >> + /* MTRR MSRs */
> >> + {HV_X64_REGISTER_MSR_MTRR_CAP, -1, MSR_MTRRcap},
> >> + {HV_X64_REGISTER_MSR_MTRR_DEF_TYPE, -1, MSR_MTRRdefType},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE0, -1, MTRRphysBase_MSR(0)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE1, -1, MTRRphysBase_MSR(1)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE2, -1, MTRRphysBase_MSR(2)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE3, -1, MTRRphysBase_MSR(3)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE4, -1, MTRRphysBase_MSR(4)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE5, -1, MTRRphysBase_MSR(5)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE6, -1, MTRRphysBase_MSR(6)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE7, -1, MTRRphysBase_MSR(7)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE8, -1, MTRRphysBase_MSR(8)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASE9, -1, MTRRphysBase_MSR(9)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEA, -1, MTRRphysBase_MSR(0xa)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEB, -1, MTRRphysBase_MSR(0xb)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEC, -1, MTRRphysBase_MSR(0xc)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASED, -1, MTRRphysBase_MSR(0xd)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEE, -1, MTRRphysBase_MSR(0xe)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_BASEF, -1, MTRRphysBase_MSR(0xf)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK0, -1, MTRRphysMask_MSR(0)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK1, -1, MTRRphysMask_MSR(1)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK2, -1, MTRRphysMask_MSR(2)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK3, -1, MTRRphysMask_MSR(3)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK4, -1, MTRRphysMask_MSR(4)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK5, -1, MTRRphysMask_MSR(5)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK6, -1, MTRRphysMask_MSR(6)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK7, -1, MTRRphysMask_MSR(7)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK8, -1, MTRRphysMask_MSR(8)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASK9, -1, MTRRphysMask_MSR(9)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKA, -1, MTRRphysMask_MSR(0xa)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKB, -1, MTRRphysMask_MSR(0xb)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKC, -1, MTRRphysMask_MSR(0xc)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKD, -1, MTRRphysMask_MSR(0xd)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKE, -1, MTRRphysMask_MSR(0xe)},
> >> + {HV_X64_REGISTER_MSR_MTRR_PHYS_MASKF, -1, MTRRphysMask_MSR(0xf)},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX64K00000, -1, MSR_MTRRfix64K_00000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX16K80000, -1, MSR_MTRRfix16K_80000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX16KA0000, -1, MSR_MTRRfix16K_A0000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX4KC0000, -1, MSR_MTRRfix4K_C0000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX4KC8000, -1, MSR_MTRRfix4K_C8000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX4KD0000, -1, MSR_MTRRfix4K_D0000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX4KD8000, -1, MSR_MTRRfix4K_D8000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX4KE0000, -1, MSR_MTRRfix4K_E0000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX4KE8000, -1, MSR_MTRRfix4K_E8000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX4KF0000, -1, MSR_MTRRfix4K_F0000},
> >> + {HV_X64_REGISTER_MSR_MTRR_FIX4KF8000, -1, MSR_MTRRfix4K_F8000},
> >> +};
> >> +
> >> +int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, u64 shared)
> >> +{
> >> + u64 *reg64;
> >> + enum hv_register_name gpr_name;
> >> + int i;
> >> +
> >> + gpr_name = regs->name;
> >> + reg64 = ®s->value.reg64;
> >> +
> >> + /* Search for the register in the table */
> >> + for (i = 0; i < ARRAY_SIZE(reg_table); i++) {
> >> + if (reg_table[i].reg_name != gpr_name)
> >> + continue;
> >> + if (reg_table[i].debug_reg_num != -1) {
> >> + /* Handle debug registers */
> >> + if (gpr_name == HV_X64_REGISTER_DR6 && !shared)
> >> + goto hypercall;
> >> + if (set)
> >> + native_set_debugreg(reg_table[i].debug_reg_num, *reg64);
> >> + else
> >> + *reg64 = native_get_debugreg(reg_table[i].debug_reg_num);
> >> + } else {
> >> + /* Handle MSRs */
> >> + if (set)
> >> + wrmsrl(reg_table[i].msr_addr, *reg64);
> >> + else
> >> + rdmsrl(reg_table[i].msr_addr, *reg64);
> >> + }
> >> + return 0;
> >> + }
> >> +
> >> +hypercall:
> >> + return 1;
> >> +}
> >> +EXPORT_SYMBOL(hv_vtl_get_set_reg);
> >> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> >> index f64393e853ee..d5355a5b7517 100644
> >> --- a/arch/x86/include/asm/mshyperv.h
> >> +++ b/arch/x86/include/asm/mshyperv.h
> >> @@ -304,6 +304,7 @@ void mshv_vtl_return_call(struct mshv_vtl_cpu_context
> *vtl0);
> >> void mshv_vtl_return_call_init(u64 vtl_return_offset);
> >> void mshv_vtl_return_hypercall(void);
> >> void __mshv_vtl_return_call(struct mshv_vtl_cpu_context *vtl0);
> >> +int hv_vtl_get_set_reg(struct hv_register_assoc *regs, bool set, u64 shared);
> >
> > Can this move to asm-generic/mshyperv.h? The function is no longer specific
> > to x86/x64, so one would want to not declare it in the arch/x86 version
> > of mshyperv.h. But maybe moving it to asm-generic/mshyperv.h breaks
> > compilation on arm64 because there's also the static inline stub there.
>
> This is still arch specific (x86 to be precise). For ARM64, we always
> want to return 1, which is to tell the client to use hypercall as a
> fallback option. Moving this x86 specific implementation (X64 registers,
> MTRR etc) to a common code, would not be right. One thing that could be
> done here was to move the "return 1" stub code from arm64 to asm-generic
> mshyperv.h, but that would not provide much benefit.
>
> I am currently not planning to make any changes here. If I misunderstood
> your comment, please let me know.
>
Yes, the implementation of hv_vtl_get_set_reg() is arch-specific. But the
one-line declaration is not. If there was a full implementation on arm64
like with x86, then the declaration could move to asm-generic/mshyperv.h.
But the arm64 side is a "static inline" function, and I'm pretty sure the
above declaration would cause a compiler conflict. So not making any
changes is appropriate. If the arm64 side should ever change to a full
implementation that isn't static inline, then the one-line declaration
should move to asm-generic/mshyperv.h.
I probably should have omitted my comment entirely as it was just
musing about a situation that doesn't actually exist at the moment. :-(
Michael
^ permalink raw reply
* Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to SM CPU/LMM reset vector
From: Mathieu Poirier @ 2026-04-13 15:10 UTC (permalink / raw)
To: Peng Fan
Cc: Peng Fan (OSS), Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Daniel Baluta, linux-remoteproc@vger.kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <PAXPR04MB84591BCD80728EE880CA2AD888262@PAXPR04MB8459.eurprd04.prod.outlook.com>
On Fri, 10 Apr 2026 at 21:01, Peng Fan <peng.fan@nxp.com> wrote:
>
> > Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass bootaddr to
> > SM CPU/LMM reset vector
> >
> > On Thu, Apr 09, 2026 at 08:30:54AM +0800, Peng Fan wrote:
> > > On Wed, Apr 08, 2026 at 09:46:32AM -0600, Mathieu Poirier wrote:
> > > >On Wed, Apr 08, 2026 at 01:30:16AM +0000, Peng Fan wrote:
> > > >> > Subject: Re: [PATCH v2 2/3] remoteproc: imx_rproc: Pass
> > bootaddr
> > > >> > to SM CPU/LMM reset vector
> > > >> >
> > > >> [...]
> > > >> >
> > > >> > >
> > > >> > > Aligning the ELF entry point with the hardware reset base on
> > > >> > Cortex‑M
> > > >> > > systems is possible, but it comes with several risks.
> > > >> >
> > > >> > I'm not asking to align the ELF entry point with the hardware
> > reset base.
> > > >> > All I want is to have the correct start address embedded in the
> > > >> > ELF file to avoid having to use a mask.
> > > >>
> > > >> I see, per my understanding:
> > > >> FreeRTOS typically exposes __isr_vector, which corresponds to the
> > > >> hardware reset / vector table base.
> > > >> Zephyr (Cortex‑M) exposes _vector_table, which serves the same
> > purpose.
> > > >> I am not certain about other RTOSes, but the pattern seems
> > consistent:
> > > >> the vector table base is already available as a named ELF symbol.
> > > >>
> > > >> Given that, if the preferred approach is to parse the ELF and
> > > >> explicitly retrieve the hardware reset base, I can update the
> > implementation accordingly.
> > > >> If you prefer to parse the elf file to get the hardware reset base,
> > > >> I could update to use them.
> > > >>
> > > >> Options1: Something as below:
> > > >> 1. Include rproc_elf_find_symbol in remoteproc_elf_loader.c 2.
> > Use
> > > >> below in imx_rproc.c ret = rproc_elf_find_symbol(rproc, fw,
> > > >> "__isr_vector", &vector_base); if (ret)
> > > >> ret = rproc_elf_find_symbol(rproc, fw, "__vector_table",
> > > >> &vector_base);
> > > >>
> > > >> if (!ret)
> > > >> rproc->bootaddr = vector_base
> > > >> else
> > > >> dev_info(dev, "no __isr_vector or __vector_table\n")
> > > >
> > > >No
> > >
> > > If your concern is about rproc->bootaddr, I could introduce
> > > imx_rproc->vector_base for i.MX. Please help detail a bit.
> > >
> > > >
> > > >>
> > > >> This makes the hardware reset base explicit, avoids masking
> > e_entry.
> > > >>
> > > >> Option 2: User‑provided reset symbol via sysfs As an alternative,
> > > >> we could expose a sysfs attribute, e.g. reset_symbol, allowing
> > > >> users to specify the symbol name to be used as the reset base:
> > > >>
> > > >> echo __isr_vector >
> > /sys/class/remoteproc/remoteprocX/reset_symbol
> > > >>
> > > >
> > > >Definitely not.
> > > >
> > > >The definition of e_entry in the specification is clear, i.e "the
> > > >address of the entry point from where the process starts executing".
> > > >If masking is required because the tool that puts the image together
> > > >gets the wrong address, then it should be fixed.
> > >
> > > The hardware reset base is the address from which the hardware
> > fetches
> > > the initial stack pointer and program counter values and loads them
> > > into the SP and PC registers. In contrast, bootaddr (i.e. e_entry)
> > > represents the address at which the CPU starts executing code (the
> > PC
> > > value after reset). As you pointed out earlier, this distinction is clear.
> > >
> > > In our case, we need to obtain the hardware reset base and pass that
> > > value to the system firmware. However, e_entry should not be set to
> > > the hardware reset base. Doing so would introduce the issues I
> > > described in [1]. This means we should not modify the Zephyr or
> > > FreeRTOS build outputs to make e_entry equal to the hardware reset
> > base.
> >
> >
> > As I said earlier, I am _not_ suggesting to make e_entry equal to the
> > hardware reset base.
>
> Let me try to restate my understanding more precisely and please
> correct me if I am still missing the point.
>
> From your comment:
> "
> If masking is required because the tool that puts the image together gets the
> wrong address, then it should be fixed.
> "
>
> I understand this as saying that masking e_entry is not acceptable, because
> e_entry already has a clear and correct meaning: it is the execution entry
> address, and the kernel should not reinterpret or “fix up” that value.
> At the same time, we still need to provide the hardware reset vector base
> to the system firmware, and that value is distinct from e_entry.
>
> On i.MX94/5 platforms the reset base is software‑programmable, but that
> information is not represented by e_entry, nor is there currently a
> separate place in the remoteproc framework to convey a reset‑vector
> base independent of the execution entry point.
>
> Given these constraints, I see limited options on the kernel side.
>
> One conservative approach would be to rely on a fixed, platform‑defined
> reset base for the affected SoCs. And update RTOS linking script to put
> the vector to the location of fixed hardware reset base.
>
The problem with the current patchset is the overloading of
rproc->bootaddr in function rproc_fw_boot() [1]. After that point
rproc->bootaddr holds the hardware reset address communicated to the
remote processor's firmware and not the beginning of execution as
intended by the definition of e_entry. This is very confusing to
anyone reviewing the code without a clear understanding of the
context.
To fix this I suggest masking rproc->bootaddr in
imx_rproc_sm_cpu_start() and imx_rproc_sm_lmm_start() with a copious
amount of in-lined documentation.
[1]. https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/remoteproc/remoteproc_core.c#L1401
> Thanks,
> Peng
>
> >
> > We are going in circles here.
> >
> > >
> > > Given these constraints, the feasible solutions I can see are either:
> > > - option 1 (explicitly retrieving the hardware reset base), or
> > > - continuing to use masking.
> > >
> > > Please suggest.
> > >
> > > [1]
> > >
> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > lore
> > > .kernel.org%2Fall%2Facs2PAZq2k3zjmDW%40shlinux89%2F&data=0
> > 5%7C02%7Cpen
> > >
> > g.fan%40nxp.com%7C8a5ce35d492b4adb2d3b08de97192cbb%7C686
> > ea1d3bc2b4c6fa
> > >
> > 92cd99c5c301635%7C0%7C0%7C639114331565834960%7CUnknow
> > n%7CTWFpbGZsb3d8e
> > >
> > yJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsI
> > kFOIjoiTWF
> > >
> > pbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=Pnkirz3BMEuLsJU9
> > MHQNon84HIyMX
> > > 08x1wCK04dS7VU%3D&reserved=0
> > >
> > > Thanks,
> > > Peng
> > >
> > > >
> > > >> The remoteproc core would then resolve that symbol from the ELF
> > and
> > > >> set rproc->bootaddr accordingly.
> > > >> This provides maximum flexibility but does introduce a new
> > > >> user‑visible ABI, so I see it more as an opt‑in or fallback
> > mechanism.
> > > >>
> > > >> Please let me know which approach you prefer, and I will update
> > > >> this series accordingly in v3..
> > > >>
> > > >> Thanks,
> > > >> Peng.
> > > >>
> > > >>
> > > >> >
> > > >> > > 1, Semantic mismatch (ELF vs. hardware behavior) 2,
> > Debuggers
> > > >> > > may attempt to set breakpoints or start execution at the entry
> > > >> > > symbol
> > > >> > >
^ permalink raw reply
* Re: [Question mpam mpam/snapshot+extras/v6.18-rc1] Question with Configuring iommu_group in 'task'
From: Ben Horgan @ 2026-04-13 15:02 UTC (permalink / raw)
To: Qinxin Xia
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, gshan, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, xhao, zengheng4, Linuxarm
In-Reply-To: <7b2681c3-9ef7-4882-ba57-2503934e2759@huawei.com>
Hi Qinxin,
On 4/3/26 03:44, Qinxin Xia wrote:
>
>
> On 2026/3/27 18:47:49, Ben Horgan <ben.horgan@arm.com> wrote:
>> Hi Qinxin,
>>
>> On 3/27/26 10:21, Qinxin Xia wrote:
>>>
>>> Hello everyone!
>>>
>>> In earlier versions, mpam supports the configuration of iommu_groups.
>>>
>>> 823 static ssize_t rdtgroup_tasks_write(struct kernfs_open_file *of,
>>> 824 char *buf, size_t nbytes,
>>> loff_t off)
>>> 825 {
>>> 826 struct rdtgroup *rdtgrp;
>>> 827 int iommu_group_id;
>>> 828 bool is_iommu;
>>> 829 char *pid_str;
>>> 830 int ret = 0;
>>> 831 pid_t pid;
>>> 832
>>> 833 rdtgrp = rdtgroup_kn_lock_live(of->kn);
>>> 834 if (!rdtgrp) {
>>> 835 rdtgroup_kn_unlock(of->kn);
>>> 836 return -ENOENT;
>>> 837 }
>>> 838 rdt_last_cmd_clear();
>>> 839
>>> 840 if (rdtgrp->mode == RDT_MODE_PSEUDO_LOCKED ||
>>> 841 rdtgrp->mode == RDT_MODE_PSEUDO_LOCKSETUP) {
>>> 842 ret = -EINVAL;
>>> 843 rdt_last_cmd_puts("Pseudo-locking in progress\n");
>>> 844 goto unlock;
>>> 845 }
>>> 846
>>> 847 while (buf && buf[0] != '\0' && buf[0] != '\n') {
>>> 848 pid_str = strim(strsep(&buf, ","));
>>> 849
>>> 850 is_iommu = string_is_iommu_group(pid_str, &iommu_group_id);
>>>
>>> What puzzles me is why we would put it under 'task'—this seems a little
>>> strange to users.It seems they are not related.Why don't we add a new
>>> interface like 'iommu'?
>>
>> I think it is likely that this interface would change if upstream support is added.
>>
>
> I have done some work in this direction before, and I will release an
> RFC later for further discussion.:-)
Looking forward to seeing it.
Ben
>
>>>
>>> 851 if (is_iommu)
>>> 852 ret = rdtgroup_move_iommu(iommu_group_id, rdtgrp, of);
>>> 853 else if (kstrtoint(pid_str, 0, &pid)) {
>>> 854 rdt_last_cmd_printf("Task list parsing error pid %s\n", pid_str);
>>> 855 ret = -EINVAL;
>>> 856 break;
>>> 857 }
>>> 858
>>> 859 if (pid < 0) {
>>> 860 rdt_last_cmd_printf("Invalid pid %d\n", pid);
>>> 861 ret = -EINVAL;
>>> 862 break;
>>> 863 }
>>> 864
>>>
>>> In future glue versions, will you re-enable support for iommu_group, and
>>> if so, will the configuration scheme be changed?
>>
>> Please can you let us know about your usecase so that we can get more information to decide
>> what the best interface would be?
>>
>> Thanks,
>>
>> Ben
>>
>>
>>
>
> We want to use the iommu mpam to implement stream control for different
> PCIe devices. By limiting the access bandwidth of some PCIe devices, the
> high-priority service devices can obtain more resources.
>
^ permalink raw reply
* Re: [PATCH 01/10] drm/bridge: add of_drm_get_bridge_by_endpoint()
From: Dmitry Baryshkov @ 2026-04-13 14:58 UTC (permalink / raw)
To: Luca Ceresoli
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Xinliang Liu, Tian Tao,
Xinwei Kong, Sumit Semwal, Yongqin Liu, John Stultz,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Tomi Valkeinen, Michal Simek,
Hui Pu, Ian Ray, Thomas Petazzoni, dri-devel, linux-kernel,
linux-arm-msm, freedreno, linux-arm-kernel
In-Reply-To: <20260413-drm-bridge-alloc-getput-panel_or_bridge-v1-1-acd01cd79a1f@bootlin.com>
On Mon, Apr 13, 2026 at 03:58:33PM +0200, Luca Ceresoli wrote:
> drm_of_find_panel_or_bridge() is widely used, but many callers pass NULL
> into the @panel or the @bridge arguments, thus making a very partial usage
> of this rather complex function.
>
> Besides, the bridge returned in @bridge is not refcounted, thus making this
> API unsafe when DRM bridge hotplug will be introduced.
>
> Solve both issues for the cases of calls to drm_of_find_panel_or_bridge()
> with a NULL @panel pointer by adding a new function that only looks for
> bridges (and is thus much simpler) and increments the refcount of the
> returned bridge.
>
> The new function is identical to drm_of_find_panel_or_bridge() except it:
>
> - handles bridge refcounting: uses of_drm_find_and_get_bridge() instead of
> of_drm_find_bridge() internally to return a refcounted bridge
> - is slightly simpler to use: just takes no @panel parameter
> - has a simpler implementation: it is equal to
> drm_of_find_panel_or_bridge() after removing the code that becomes dead
> when @panel == NULL
>
> Also add this function to drm_bridge.c and not drm_of.c because it returns
> bridges only.
>
> Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
> ---
> drivers/gpu/drm/drm_bridge.c | 46 ++++++++++++++++++++++++++++++++++++++++++++
> include/drm/drm_bridge.h | 9 +++++++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index ba80bebb5685..e51990b74417 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -1581,6 +1581,52 @@ struct drm_bridge *of_drm_find_bridge(struct device_node *np)
> return bridge;
> }
> EXPORT_SYMBOL(of_drm_find_bridge);
> +
> +/**
> + * of_drm_get_bridge_by_endpoint - return DRM bridge connected to a port/endpoint
> + * @np: device tree node containing output ports
> + * @port: port in the device tree node, or -1 for the first port found
> + * @endpoint: endpoint in the device tree node, or -1 for the first endpoint found
> + * @bridge: pointer to hold returned drm_bridge, must not be NULL
> + *
> + * Given a DT node's port and endpoint number, find the connected node and
> + * return the associated drm_bridge device.
> + *
> + * The refcount of the returned bridge is incremented. Use drm_bridge_put()
> + * when done with it.
> + *
> + * Returns zero (and sets *bridge to a valid bridge pointer) if successful,
> + * or one of the standard error codes (and the value in *bridge is
> + * unspecified) if it fails.
Can we return drm_bridge or error cookie instead?
> + */
> +int of_drm_get_bridge_by_endpoint(const struct device_node *np,
> + int port, int endpoint,
> + struct drm_bridge **bridge)
Nit: can it be drm_of_get_bridge_by_endpoint?
> +{
> + if (!bridge)
> + return -EINVAL;
> +
> + /*
> + * of_graph_get_remote_node() produces a noisy error message if port
> + * node isn't found and the absence of the port is a legit case here,
> + * so at first we silently check whether graph presents in the
> + * device-tree node.
> + */
> + if (!of_graph_is_present(np))
> + return -ENODEV;
> +
> + struct device_node *remote __free(device_node) =
> + of_graph_get_remote_node(np, port, endpoint);
> + if (!remote)
> + return -ENODEV;
> +
> + *bridge = of_drm_find_and_get_bridge(remote);
> + if (*bridge)
> + return 0;
> +
> + return -EPROBE_DEFER;
> +}
> +EXPORT_SYMBOL_GPL(of_drm_get_bridge_by_endpoint);
> #endif
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 4/7] arm64: dts: ti: k3-am62a7-sk: Split r5f memory region
From: Markus Schneider-Pargmann @ 2026-04-13 14:58 UTC (permalink / raw)
To: Vignesh Raghavendra, Markus Schneider-Pargmann, Bjorn Andersson,
Mathieu Poirier, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Suman Anna, Nishanth Menon, Tero Kristo
Cc: Vishal Mahaveer, Kevin Hilman, Dhruva Gole, Sebin Francis,
Kendall Willis, Akashdeep Kaur, linux-remoteproc, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <c35fea4e-dc22-4314-9c5c-bfa5b880864d@ti.com>
[-- Attachment #1: Type: text/plain, Size: 3256 bytes --]
Hi Vignesh,
On Sat Apr 11, 2026 at 4:47 PM CEST, Vignesh Raghavendra wrote:
>
>
> On 10/04/26 19:12, Markus Schneider-Pargmann wrote:
>> Hi Vignesh,
>>
>> On Fri Apr 10, 2026 at 6:30 AM CEST, Vignesh Raghavendra wrote:
>>> Hi Markus
>>>
>>> On 18/03/26 20:43, Markus Schneider-Pargmann (TI) wrote:
>>>> Split the firmware memory region in more specific parts so it is better
>>>> described where to find which information. Specifically the LPM metadata
>>>> region is important as bootloader software like U-Boot has to know where
>>>> that data is to be able to read that data.
>>>>
>>>> Signed-off-by: Markus Schneider-Pargmann (TI) <msp@baylibre.com>
>>>> ---
>>>> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 40 +++++++++++++++++++++++++++++++--
>>>> 1 file changed, 38 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> index e99bdbc2e0cbdf858f1631096f9c2a086191bab3..c381cc33064ec427751a9ac5bcdff745a9559a89 100644
>>>> --- a/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> +++ b/arch/arm64/boot/dts/ti/k3-am62a7-sk.dts
>>>> @@ -59,9 +59,33 @@ wkup_r5fss0_core0_dma_memory_region: memory@9c800000 {
>>>> no-map;
>>>> };
>>>>
>>>> - wkup_r5fss0_core0_memory_region: memory@9c900000 {
>>>> + wkup_r5fss0_core0_ipc_region: memory@9c900000 {
>>>
>>> There are still references to wkup_r5fss0_core0_memory_region in
>>> k3-am62a-ti-ipc-firmware.dtsi (same comment applies to next 2 patches as
>>> well)
>>>
>>> Dont those need to be updated too?
>>
>> I only updated the sk boards as these are the only ones that have IO+DDR
>> support that I know works and need the new memory region layout. But
>> thinking about this, updating the memory region structure shouldn't be a
>> problem for the other boards either, of course I can't tell if IO+DDR
>> would work on them, but the new memory region layout shouldn't break
>> anything.
>
> I am not talking about updating other boards, but specifically about
> k3-am62*-ti-ipc-firmware.dtsi which have a phandle reference to
> wkup_r5fss0_core0_memory_region. Therefore any dts trying to include
> this dtsi would fail to compile post this series.
I am not sure I understand why they would fail?
The current design is to have the k3-am62*-ti-ipc-firmware.dtsi files
reference the memory regions in the r5fss node, for example:
&wkup_r5fss0_core0 {
mboxes = <&mailbox0_cluster0>, <&mbox_r5_0>;
memory-region = <&wkup_r5fss0_core0_dma_memory_region>,
<&wkup_r5fss0_core0_memory_region>;
memory-region-names = "dma", "firmware";
status = "okay";
};
But k3-am62*-ti-ipc-firmware.dtsi do not define these memory regions.
Instead it relies on the dts files to define them. That is done for
example in k3-am62a7-sk.dts and others.
This patch now changes the memory regions being used by r5fss0 as well
as the memory regions being defined but only in k3-am62a7-sk.dts. It
does not change the references or definitions in
k3-am62*-ti-ipc-firmware.dtsi.
So I think including the k3-am62*-ti-ipc-firmware.dtsi file should still
work as long as you have the memory regions defined in the dts file.
Best
Markus
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 289 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] ARM: configs: Drop redundant I2C_DESIGNWARE_PLATFORM
From: Dinh Nguyen @ 2026-04-13 14:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, Nicolas Ferre, Alexandre Belloni,
Claudiu Beznea, Bjorn Andersson, Dmitry Baryshkov,
Krzysztof Kozlowski
Cc: Arnd Bergmann, Linus Walleij, Drew Fustini, soc, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260412-b4-defconfig-multi-v7-v1-2-e76de035c2df@oss.qualcomm.com>
On 4/12/26 12:12, Krzysztof Kozlowski wrote:
> I2C_DESIGNWARE_PLATFORM is default=y via I2C_DESIGNWARE_CORE, which is
> enabled. No impact on include/generated/autoconf.h.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> arch/arm/configs/hisi_defconfig | 1 -
> arch/arm/configs/multi_v7_defconfig | 1 -
> arch/arm/configs/pxa_defconfig | 1 -
> arch/arm/configs/socfpga_defconfig | 1 -
...
> diff --git a/arch/arm/configs/socfpga_defconfig b/arch/arm/configs/socfpga_defconfig
> index f2e42846b116..19a8e30a7b22 100644
> --- a/arch/arm/configs/socfpga_defconfig
> +++ b/arch/arm/configs/socfpga_defconfig
Acked-by: Dinh Nguyen <dinguyen@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 1/3] arm64: mm: Fix rodata=full block mapping support for realm guests
From: Kevin Brodsky @ 2026-04-13 14:57 UTC (permalink / raw)
To: Yang Shi, Catalin Marinas
Cc: Ryan Roberts, Will Deacon, David Hildenbrand (Arm), Dev Jain,
Suzuki K Poulose, Jinjiang Tu, linux-arm-kernel, linux-kernel,
stable, Kalyazin, Nikita
In-Reply-To: <e4682b9a-9c18-44c5-a892-b12ce4745474@os.amperecomputing.com>
On 10/04/2026 01:08, Yang Shi wrote:
> On 4/9/26 11:33 AM, Catalin Marinas wrote:
>> On Thu, Apr 09, 2026 at 09:48:58AM -0700, Yang Shi wrote:
>>> On 4/9/26 8:20 AM, Catalin Marinas wrote:
>>>> On Thu, Apr 09, 2026 at 11:53:41AM +0200, Kevin Brodsky wrote:
>>>>> What would make more sense to me is to enable the use of
>>>>> BBML2-noabort
>>>>> unconditionally if !force_pte_mapping(). We can then have
>>>>> can_set_direct_map() return true if we have BBML2-noabort, and we no
>>>>> longer need to check it in map_mem().
>>>> Indeed.
>>> I'm trying to wrap up my head for this discussion. IIUC, if none of the
>>> features is enabled, it means we don't need do anything because the
>>> direct
>>> map is not changed. For example, if vmalloc doesn't change direct map
>>> permission when rodata != full, there is no need to call
>>> set_direct_map_*_noflush(). So unconditionally checking
>>> BBML2_NOABORT will
>>> change the behavior unnecessarily. Did I miss something?
>>>
>>> I think the only exception is secretmem if I don't miss something.
>>> Currently, secretmem is actually not supported if none of the
>>> features is
>>> enabled. But BBML2_NOABORT allows to lift the restriction.
>> Yes, it's secretmem only AFAICT. I think execmem will only change the
>> linear map if rodata_full anyway.
>
> Yes, execmem calls set_memory_rox(), which won't change linear map
> permission if rodata_full is not enabled.
That is a good point, AFAICT set_direct_map_*_noflush() are only used by
execmem and secretmem. excmem only modifies the direct map if
rodata=full, so the proposed change would only be useful for secretmem.
The current situation with execmem is pretty strange: if rodata!=full,
but another feature is enabled (say kfence), then set_memory_rox() won't
touch the direct map but we will still use set_direct_map_*_noflush() to
reset it (directly or via VM_FLUSH_RESET_PERMS). Checking BBML2-noabort
in can_set_direct_map() would make these unnecessary calls more likely,
but it doesn't fundamentally change the situation.
It's also worth considering the series unmapping parts of the direct map
for guest_memfd [1], since it gates the use of
set_direct_map_*_noflush() on can_set_direct_map().
I think it makes complete sense to enable secretmem and the guest_memfd
use-case if BBML2-noabort is available, regardless of the other
features. The question is: are we worried about the overhead of
needlessly calling set_direct_map_*_noflush() for execmem mappings? If
so, it seems that the right solution is to introduce a new API to check
whether set_memory_ro() and friends actually modify the direct map or not.
- Kevin
[1] https://lore.kernel.org/lkml/20260317141031.514-1-kalyazin@amazon.com/
^ permalink raw reply
* [PATCH] arm64: dts: exynos850: Add SRAM node
From: Alexey Klimov @ 2026-04-13 14:52 UTC (permalink / raw)
To: Sam Protsenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alim Akhtar
Cc: linux-samsung-soc, linux-arm-kernel, devicetree, linux-kernel,
Alexey Klimov
SRAM is used by the ACPM protocol to retrieve the ACPM channels
information and configuration data. Add the SRAM node.
Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
---
arch/arm64/boot/dts/exynos/exynos850.dtsi | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos850.dtsi b/arch/arm64/boot/dts/exynos/exynos850.dtsi
index cb55015c8dce..cf4a6168846c 100644
--- a/arch/arm64/boot/dts/exynos/exynos850.dtsi
+++ b/arch/arm64/boot/dts/exynos/exynos850.dtsi
@@ -910,6 +910,14 @@ spi_2: spi@11d20000 {
};
};
};
+
+ apm_sram: sram@2039000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x2039000 0x40000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x2039000 0x40000>;
+ };
};
#include "exynos850-pinctrl.dtsi"
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260413-exynos850_sram-ca1200b99e82
Best regards,
--
Alexey Klimov <alexey.klimov@linaro.org>
^ permalink raw reply related
* Re: [patch 17/38] ext4: Replace get_cycles() usage with ktime_get()
From: Arnd Bergmann @ 2026-04-13 14:46 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Theodore Ts'o, linux-ext4, x86, Baolu Lu, iommu,
Michael Grzeschik, Netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka (SUSE), linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Andrew Morton,
Uladzislau Rezki (Sony), Marco Elver, Dmitry Vyukov, kasan-dev,
Andrey Ryabinin, Thomas Sailer, linux-hams, Jason A . Donenfeld,
Richard Henderson, linux-alpha, Russell King, linux-arm-kernel,
Catalin Marinas, Huacai Chen, loongarch, Geert Uytterhoeven,
linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc@vger.kernel.org, Helge Deller, linux-parisc,
Michael Ellerman, linuxppc-dev, Paul Walmsley, linux-riscv,
Heiko Carstens, linux-s390, David S . Miller, sparclinux
In-Reply-To: <20260410120318.727211419@kernel.org>
On Fri, Apr 10, 2026, at 14:19, Thomas Gleixner wrote:
> get_cycles() is not guaranteed to be functional on all systems/platforms
> and the values returned are unitless and not easy to map to something
> useful.
>
> Use ktime_get() instead, which provides nanosecond timestamps and is
> functional everywhere.
>
> This is part of a larger effort to limit get_cycles() usage to low level
> architecture code.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: "Theodore Ts'o" <tytso@mit.edu>
> Cc: linux-ext4@vger.kernel.org
I think this is technically an ABI chance, since the time
difference gets exported through procfs, but the new version
is clearly the right thing to do since it replaces a hardware
specific value with a portable one.
Arnd
^ permalink raw reply
* Re: [patch 38/38] treewide: Remove asm/timex.h includes from generic code
From: Arnd Bergmann @ 2026-04-13 14:45 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: x86, Baolu Lu, iommu, Michael Grzeschik, Netdev, linux-wireless,
Herbert Xu, linux-crypto, Vlastimil Babka (SUSE), linux-mm,
David Woodhouse, Bernie Thompson, linux-fbdev, Theodore Ts'o,
linux-ext4, Andrew Morton, Uladzislau Rezki (Sony), Marco Elver,
Dmitry Vyukov, kasan-dev, Andrey Ryabinin, Thomas Sailer,
linux-hams, Jason A . Donenfeld, Richard Henderson, linux-alpha,
Russell King, linux-arm-kernel, Catalin Marinas, Huacai Chen,
loongarch, Geert Uytterhoeven, linux-m68k, Dinh Nguyen,
Jonas Bonn, linux-openrisc@vger.kernel.org, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S . Miller,
sparclinux
In-Reply-To: <20260410120320.163559629@kernel.org>
On Fri, Apr 10, 2026, at 14:21, Thomas Gleixner wrote:
> asm/timex.h does not provide any functionality for non-architecture code
> anymore.
>
> Remove the asm-generic fallback and all references in include and source
> files along with the random_get_entropy() #ifdeffery in timex.h.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> ---
> include/asm-generic/Kbuild | 1 -
> include/asm-generic/timex.h | 15 ---------------
> include/linux/random.h | 3 +++
> include/linux/timex.h | 26 --------------------------
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [patch 32/38] powerpc/spufs: Use mftb() directly
From: Arnd Bergmann @ 2026-04-13 14:43 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: Michael Ellerman, linuxppc-dev, x86, Baolu Lu, iommu,
Michael Grzeschik, Netdev, linux-wireless, Herbert Xu,
linux-crypto, Vlastimil Babka (SUSE), linux-mm, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Ts'o, linux-ext4,
Andrew Morton, Uladzislau Rezki (Sony), Marco Elver,
Dmitry Vyukov, kasan-dev, Andrey Ryabinin, Thomas Sailer,
linux-hams, Jason A . Donenfeld, Richard Henderson, linux-alpha,
Russell King, linux-arm-kernel, Catalin Marinas, Huacai Chen,
loongarch, Geert Uytterhoeven, linux-m68k, Dinh Nguyen,
Jonas Bonn, linux-openrisc@vger.kernel.org, Helge Deller,
linux-parisc, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S . Miller, sparclinux
In-Reply-To: <20260410120319.723429844@kernel.org>
On Fri, Apr 10, 2026, at 14:21, Thomas Gleixner wrote:
> There is no reason to indirect via get_cycles(), which is about to be
> removed.
>
> Use mftb() directly.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: linuxppc-dev@lists.ozlabs.org
Acked-by: Arnd Bergmann <arnd@arndb.de>
^ permalink raw reply
* Re: [PATCH] mm/arm: pgtable: remove young bit check for pte_valid_user
From: Russell King (Oracle) @ 2026-04-13 14:42 UTC (permalink / raw)
To: Will Deacon
Cc: Brian Ruley, Steve Capper, linux-arm-kernel, linux-kernel,
catalin.marinas
In-Reply-To: <adzMOdySgMIePcue@willie-the-truck>
On Mon, Apr 13, 2026 at 11:58:01AM +0100, Will Deacon wrote:
> On Fri, Apr 10, 2026 at 02:01:41PM +0300, Brian Ruley wrote:
> > On Apr 09, Russell King (Oracle) wrote:
> > >
> > > On Thu, Apr 09, 2026 at 06:17:36PM +0300, Brian Ruley wrote:
> > > > However, in the case I describe, if VA_B is mapped immediately to pfn_q
> > > > after it been has unmapped and freed for VA_A, then it's quite possible
> > > > that the page is still indexed in the cache.
> > >
> > > True.
> > >
> > > > The hypothesis is that if
> > > > VA_A and VA_B land in the same I-cache set and VA_A old cache entry
> > > > still exists (tagged with pfn_q), then the CPU can fetch stale
> > > > instructions because the tag will match. That's one reason why we need
> > > > to invalidate the cache, but that will be skipped in the path:
> > > >
> > > > migrate_pages
> > > > migrate_pages_batch
> > > > migrate_folio_move
> > > > remove_migration_ptes
> > > > remove_migration_pte
> > > > set_pte_at
> > > > set_ptes
> > > > __sync_icache_dcache (skipped if !young)
> > > > set_pte_ext
> > >
> > > In this case, if the old PTE was marked !young, then the new PTE will
> > > have:
> > > pte = pte_mkold(pte);
> > >
> > > on it, which marks it !young. As you say, __sync_icache_dcache() will
> > > be skipped. While a PTE entry will be set for the kernel, the code in
> > > set_pte_ext() will *not* establish a hardware PTE entry. For the
> > > 2-level pte code:
> > >
> > > tst r1, #L_PTE_YOUNG @ <- results in Z being set
> > > tstne r1, #L_PTE_VALID @ <- not executed
> > > eorne r1, r1, #L_PTE_NONE @ <- not executed
> > > tstne r1, #L_PTE_NONE @ <- not executed
> > > moveq r3, #0 @ <- hardware PTE value
> > > ARM( str r3, [r0, #2048]! ) @ <- writes hardware PTE
> > >
> > > So, for a !young PTE, the hardware PTE entry is written as zero,
> > > which means accesses should fault, which will then cause the PTE to
> > > be marked young.
> > >
> > > For the 3-level case, the L_PTE_YOUNG bit corresponds with the AF bit
> > > in the PTE, and there aren't split Linux / hardware PTE entries. AF
> > > being clear should result in a page fault being generated for the
> > > kernel to handle making the PTE young.
> > >
> > > In both of these cases, set_ptes() will need to be called with the
> > > updated PTE which will now be marked young, and that will result in
> > > the I-cache being flushed.
> >
> > Hi Russell,
> >
> > Thank you for the clarification, this is very educational for me.
> > I understand your scepticism, and I can't explain what's going on based
> > on what you replied. However, I do honestly believe there is a problem
> > here. I'll share the exact testing details and the instrumentation
> > we added that convinced us to reach out at the end. One idea we also
> > had was that could cache aliasing be happening here.
>
> I thought a bit more about this over the weekend and started to wonder
> if there's a potential race where multiple CPUs try to write the same
> PTE and don't synchronise properly on the cache-maintenance.
>
> In particular, PG_dcache_clean is manipulated with a test_and_set_bit()
> operation _before_ the cache maintenance is performed, so there's a
> small window where the flag is set but the page is _not_ clean. I don't
> think that matters with regards to invalid migration entries, but
> perhaps the migration just means that we end up putting down a bunch of
> 'old' entries and are then more likely to see concurrent faults trying
> to make the thing young again, potentially hitting this race.
>
> Looking at arm64 this morning, I noticed that we split the flag
> manipulation so that it's set with a set_bit() after the maintenance has
> been performed. Git then points to 588a513d3425 ("arm64: Fix race
> condition on PG_dcache_clean in __sync_icache_dcache()") which seems to
> talk about the same race. In fact, the mailing list posting:
>
> https://lore.kernel.org/all/20210514095001.13236-1-catalin.marinas@arm.com/
>
> points out that arch/arm/ is also affected but we forgot to CC Russell
> because I think this all came out of the MTE-enablement work [1] and it
If this is the problem, then I'll point out that this is the problem
with *not* sharing even a base level of code between arm64 and arm,
resulting in the same bugs being present in both, needing two separate
fixes, but only one fix happens.
Catalin was dead against any kind of code sharing though, so I suspect
we're going to be forever fixing the same bugs in two separate chunks
of code.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ 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