* Re: [PATCH 04/12] dt-bindings: soc: fsl: qe: Add support of IRQ in QE GPIO
From: Paul Louvel @ 2026-07-06 8:48 UTC (permalink / raw)
To: Krzysztof Kozlowski, Paul Louvel
Cc: Qiang Zhao, Christophe Leroy (CS GROUP), Thomas Gleixner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, linuxppc-dev, linux-arm-kernel, linux-kernel,
devicetree, linux-gpio, Thomas Petazzoni
In-Reply-To: <20260706-elfish-cornflower-bullfinch-604e0a@quoll>
On Mon Jul 6, 2026 at 8:52 AM CEST, Krzysztof Kozlowski wrote:
> On Fri, Jul 03, 2026 at 03:30:12PM +0200, Paul Louvel wrote:
>> Some QE GPIO pins have an associated interrupt line in the QE PIC to
>> signal state changes on the pin. Add the corresponding
>> interrupt-controller / nexus properties to the QE GPIO binding.
>>
>> Because the GPIO controller does not perform any interrupt handling
>> itself, a nexus node (interrupt-map) is used to map each GPIO line
>> supporting IRQ to the parent QE PIC interrupt domain.
>>
>> As the QE PIC can be configured to generate an interrupt on either a
>> high-to-low transition or any change in signal state, three
>> interrupt-map entries are needed per GPIO pin that can yield an
>> interrupt (falling, both, and the "none" case which defaults to both in
>> QE PIC). This overhead is necessary because the interrupt-map-pass-thru
>> property is not part of the DT specification.
>>
>> The interrupt-map property is optional: it is not required for GPIO
>> banks that have no interrupt capable GPIO line (e.g. port D on MPC8323),
>> or when interrupt functionality is not used.
>>
>> Update the example to show a scenario where each bank supports a
>> different numbers of IRQs, or no IRQs at all.
>>
>> Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
>> ---
>> .../bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml | 69 +++++++++++++++++++++-
>> 1 file changed, 66 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml b/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml
>> index 1af99339ff40..0c849a5698f4 100644
>> --- a/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml
>> +++ b/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml
>> @@ -27,6 +27,17 @@ properties:
>> "#gpio-cells":
>> const: 2
>>
>> + "#address-cells":
>> + const: 0
>> +
>> + "#interrupt-cells":
>> + const: 2
>> +
>
> If this has interrupt-cells, then it is a nexus, thus why isn't this
> also a "interrupt-controller"?
Because these these banks are not interrupt controllers.
Interrupts are handled by the QE PIC, and the GPIO controller does not do any
interrupt handling itself.
In this setup, does it really needs an "interrupt-controller" property?
>
>> + interrupt-map:
>> + description: |
>> + Specifies the mapping of GPIO lines to the parent interrupt controller, as the
>> + GPIO controller does not do interrupt handling itself.
>> +
>> required:
>> - compatible
>> - reg
>> @@ -37,9 +48,61 @@ additionalProperties: false
>>
>> examples:
>> - |
>> - gpio-controller@1400 {
>> - compatible = "fsl,mpc8360-qe-pario-bank", "fsl,mpc8323-qe-pario-bank";
>> - reg = <0x1400 0x18>;
>
> I don't get why you rewrite existing example instead of adding new one.
I could yes.
>
>> + #include <dt-bindings/interrupt-controller/irq.h>
>> +
>> + pic: interrupt-controller {
>> + interrupt-controller;
>> + #address-cells = <0>;
>> + #interrupt-cells = <2>;
>> + };
>
> Drop node, irrelevant.
>
>> +
>> + gpio-controller@1418 {
>> + #gpio-cells = <2>;
>> + #address-cells = <0>;
>> + #interrupt-cells = <2>;
>> + compatible = "fsl,mpc8323-qe-pario-bank";
>> + reg = <0x1418 0x18>;
>
> And now you are not following DTS coding style.
>
>> gpio-controller;
>> + interrupt-map = <
>> + 7 IRQ_TYPE_EDGE_FALLING &pic 4 IRQ_TYPE_EDGE_FALLING
>> + 7 IRQ_TYPE_EDGE_BOTH &pic 4 IRQ_TYPE_EDGE_BOTH
>> + 7 0 &pic 4 IRQ_TYPE_NONE
>> +
>> + 9 IRQ_TYPE_EDGE_FALLING &pic 5 IRQ_TYPE_EDGE_FALLING
>> + 9 IRQ_TYPE_EDGE_BOTH &pic 5 IRQ_TYPE_EDGE_BOTH
>> + 9 0 &pic 5 IRQ_TYPE_NONE
>> +
>> + 25 IRQ_TYPE_EDGE_FALLING &pic 6 IRQ_TYPE_EDGE_FALLING
>> + 25 IRQ_TYPE_EDGE_BOTH &pic 6 IRQ_TYPE_EDGE_BOTH
>> + 25 0 &pic 6 IRQ_TYPE_NONE
>> +
>> + 27 IRQ_TYPE_EDGE_FALLING &pic 7 IRQ_TYPE_EDGE_FALLING
>> + 27 IRQ_TYPE_EDGE_BOTH &pic 7 IRQ_TYPE_EDGE_BOTH
>> + 27 0 &pic 7 IRQ_TYPE_NONE
>> + >;
>> + };
>> +
>> + gpio-controller@1430 {
>> #gpio-cells = <2>;
>
> So two new examples? But old one was wrong?
>
>> + #address-cells = <0>;
>> + #interrupt-cells = <2>;
>> + compatible = "fsl,mpc8323-qe-pario-bank";
>> + reg = <0x1430 0x18>;
>> + gpio-controller;
>> + interrupt-map = <
>> + 24 IRQ_TYPE_EDGE_FALLING &pic 8 IRQ_TYPE_EDGE_FALLING
>> + 24 IRQ_TYPE_EDGE_BOTH &pic 8 IRQ_TYPE_EDGE_BOTH
>> + 24 0 &pic 8 IRQ_TYPE_NONE
>> +
>> + 29 IRQ_TYPE_EDGE_FALLING &pic 9 IRQ_TYPE_EDGE_FALLING
>> + 29 IRQ_TYPE_EDGE_BOTH &pic 9 IRQ_TYPE_EDGE_BOTH
>> + 29 0 &pic 9 IRQ_TYPE_NONE
>> + >;
>> + };
>> +
>> + gpio-controller@1448 {
>> + #gpio-cells = <2>;
>> + compatible = "fsl,mpc8323-qe-pario-bank";
>
> Wait, three examples? But isn't this the same as previous one?
I wanted to outline that each bank do not have the same number of GPIO lines
that support interrupts.
>
>> + reg = <0x1448 0x18>;
>> + gpio-controller;
>> };
>>
>> --
>> 2.55.0
>>
Thanks,
Paul.
--
Paul Louvel, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Venkat Rao Bagalkote @ 2026-07-06 8:29 UTC (permalink / raw)
To: Ricardo Robaina, Paul Moore, Christophe Leroy (CS GROUP),
Madhavan Srinivasan
Cc: Christophe Leroy (CS GROUP), Madhavan Srinivasan,
Harsh Prateek Bora, Michael Ellerman, Nicholas Piggin, Eric Paris,
linux-kernel, linuxppc-dev, audit, Thomas Weissschuh,
Cédric Le Goater, ritesh.list
In-Reply-To: <CAABTaaC_vQTM8B0wLqfHuv-S9JDzXeuDeLd0Sh3M21pO+=Zg2Q@mail.gmail.com>
On 03/07/26 4:19 am, Ricardo Robaina wrote:
> On Thu, Jul 2, 2026 at 3:19 PM Ricardo Robaina <rrobaina@redhat.com> wrote:
>> On Thu, Jul 2, 2026 at 10:28 AM Paul Moore <paul@paul-moore.com> wrote:
>>> On Thu, Jul 2, 2026 at 8:50 AM Venkat Rao Bagalkote
>>> <venkat88@linux.ibm.com> wrote:
>>>> Current remaining issue:
>>>>
>>>> 1. amcast_joinpart
>>>> ------------------
>>>> Still fails due to a missing Perl dependency:
>>>>
>>>> Can't locate Socket/Netlink.pm in @INC
>>>>
>>>> I searched the configured repositories and could not find a package
>>>> providing Socket::Netlink / Socket/Netlink.pm on this EL10 ppc64le system.
>>>>
>>>> Latest run summary:
>>>>
>>>> amcast_joinpart/test ................. Can't locate Socket/Netlink.pm in
>>>> @INC (you may need to install the Socket::Netlink module) (@INC entries
>>>> checked: /usr/local/lib64/perl5/5.40 /usr/local/share/perl5/5.40
>>>> /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
>>>> /usr/lib64/perl5 /usr/share/perl5 .) at amcast_joinpart/test line 10.
>>>> BEGIN failed--compilation aborted at amcast_joinpart/test line 10.
>>>> amcast_joinpart/test ................. Dubious, test returned 2 (wstat
>>>> 512, 0x200)
>>>> Failed 7/7 subtests
>>>> backlog_wait_time_actual_reset/test .. ok
>>>> bpf/test ............................. ok
>>>> exec_execve/test ..................... ok
>>>> exec_name/test ....................... ok
>>>> fanotify/test ........................ ok
>>>> field_compare/test ................... ok
>>>> file_create/test ..................... ok
>>>> file_delete/test ..................... ok
>>>> file_permission/test ................. ok
>>>> file_rename/test ..................... ok
>>>> filter_exclude/test .................. ok
>>>> filter_exit/test ..................... ok
>>>> filter_saddr_fam/test ................ ok
>>>> filter_sessionid/test ................ ok
>>>> io_uring/test ........................ ok
>>>> login_tty/test ....................... ok
>>>> lost_reset/test ...................... ok
>>>> netfilter_pkt/test ................... ok
>>>> signal/test .......................... ok
>>>> syscalls_file/test ................... ok
>>>> syscall_module/test .................. ok
>>>> time_change/test ..................... ok
>>>> user_msg/test ........................ ok
>>>>
>>>> All tests now pass except amcast_joinpart, which is blocked by the
>>>> missing Socket::Netlink Perl module.
>>>>
>>>> Please let me know if there is a recommended package source for
>>>> Socket::Netlink on EL10 ppc64le.
>>> Thanks for following up on this Venkat.
>>>
>>> I'm adding your colleague Ricardo from the RH side of the house.
>>> Ricardo is very familiar with audit and should be able to help you
>>> with missing RHEL packages.
>> Thanks for looping me in, Paul!
>>
>> Venkat, unfortunately, perl-Socket-Netlink is not packaged for RHEL-10
>> ppc64le. An alternative is to use CPAN[1] to install the
>> Socket::Netlink Perl module.
>>
>> # dnf install cpan
>> # cpan App::cpanminus
>> # cpanm Socket::Netlink
>>
>> I'll reserve a ppc64le machine and run the tests locally as well. I'll
>> share the results shortly.
>>
>> [1] https://www.cpan.org/modules/INSTALL.html
>>
Thanks for the RPM's Ricardo.
I installed the missing dependencies (netcat, iptables, ip6tables) and
rebuilt the kernel with arp_tables available as a module. I also
installed Socket::Netlink using:
cpanm --mirror https://cpan.metacpan.org --mirror-only Socket::Netlink
After these changes, I reran audit-testsuite and all tests are now passing:
Files=24, Tests=279
Result: PASS
amcast_joinpart/test ................. ok
backlog_wait_time_actual_reset/test .. ok
bpf/test ............................. ok
exec_execve/test ..................... ok
exec_name/test ....................... ok
fanotify/test ........................ ok
field_compare/test ................... ok
file_create/test ..................... ok
file_delete/test ..................... ok
file_permission/test ................. ok
file_rename/test ..................... ok
filter_exclude/test .................. ok
filter_exit/test ..................... ok
filter_saddr_fam/test ................ ok
filter_sessionid/test ................ ok
io_uring/test ........................ ok
login_tty/test ....................... ok
lost_reset/test ...................... ok
netfilter_pkt/test ................... ok
signal/test .......................... ok
syscalls_file/test ................... ok
syscall_module/test .................. ok
time_change/test ..................... ok
user_msg/test ........................ ok
Paul/Christophe/Maddy,
Hope we are good now. Please let me know, if anything else needs to be done.
Regards,
Venkat.
>>> --
>>> paul-moore.com
>>>
> Hello everyone,
>
> I built an RHEL-10 kernel with the patch applied and verified that
> audit-testsuite passes successfully on a ppc64le machine. Please find
> the logs below:
>
> Tested-by: Ricardo Robaina <rrobaina@redhat.com>
>
> ---
> # uname -m
> ppc64le
>
> # uname -r
> 6.12.0-245.test.el10.ppc64le
>
> # make test
> ...
> chmod +x */test
> Running as user root
> with context unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> on system RHEL10
>
> amcast_joinpart/test ................. ok
> backlog_wait_time_actual_reset/test .. ok
> bpf/test ............................. ok
> coredump/test ........................ ok
> exec_execve/test ..................... ok
> exec_name/test ....................... ok
> fanotify/test ........................ ok
> field_compare/test ................... ok
> file_create/test ..................... ok
> file_delete/test ..................... ok
> file_permission/test ................. ok
> file_rename/test ..................... ok
> filter_device/test ................... ok
> filter_exclude/test .................. ok
> filter_exit/test ..................... ok
> filter_inode/test .................... ok
> filter_saddr_fam/test ................ ok
> filter_sessionid/test ................ ok
> io_uring/test ........................ ok
> login_tty/test ....................... ok
> lost_reset/test ...................... ok
> netfilter_pkt/test ................... ok
> signal/test .......................... ok
> syscalls_file/test ................... ok
> syscall_module/test .................. ok
> time_change/test ..................... ok
> user_msg/test ........................ ok
> All tests successful.
> Files=27, Tests=300, 252 wallclock secs ( 0.12 usr 0.01 sys + 54.34
> cusr 1.38 csys = 55.85 CPU)
> Result: PASS
> make[1]: Leaving directory '/root/rrobaina/audit-testsuite/tests'
> ---
>
> I hope it helps!
> -Ricardo
>
>
^ permalink raw reply
* [PATCH v2] powerpc/64s: Clarify copy_and_flush() cache sync loop comment
From: Nikhil Kumar Singh @ 2026-07-06 8:27 UTC (permalink / raw)
To: linuxppc-dev, mkchauras
Cc: linux-kernel, maddy, mpe, npiggin, chleroy, adityag, mahesh,
Nikhil Kumar Singh
In-Reply-To: <20260701182756.273019-1-nikhilks@linux.ibm.com>
The value loaded into r0 in copy_and_flush() represents the number of
8-byte words processed between cache synchronization operations.
The existing comment refers to cache line size, which can make it appear
that the value is a cache line size in bytes rather than a loop count.
Clarify the comment to explain that the loop processes 8 words (64 bytes)
per cache synchronization iteration, and that increasing the value would
skip cache maintenance for intermediate cache lines.
This is a comment-only change with no functional impact.
Signed-off-by: Nikhil Kumar Singh <nikhilks@linux.ibm.com>
---
arch/powerpc/kernel/head_64.S | 20 ++++++++++++--------
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S
index 63432a33ec49..a54f6f979173 100644
--- a/arch/powerpc/kernel/head_64.S
+++ b/arch/powerpc/kernel/head_64.S
@@ -713,14 +713,18 @@ p_end: .8byte _end - copy_to_here
_GLOBAL(copy_and_flush)
addi r5,r5,-8
addi r6,r6,-8
-4: li r0,8 /* Use the smallest common */
- /* denominator cache line */
- /* size. This results in */
- /* extra cache line flushes */
- /* but operation is correct. */
- /* Can't get cache line size */
- /* from NACA as it is being */
- /* moved too. */
+4: li r0,8 /* r0 is the number of 8-byte words */
+ /* to copy per cache sync iteration. */
+ /* 8 words * 8 bytes = 64 bytes. 64B is */
+ /* the current default cache line size. */
+ /* This is a loop count, not a byte */
+ /* count. Increasing it may skip */
+ /* dcbst/icbi for lines in between and */
+ /* leave stale instructions in icache. */
+ /* This results in extra cache line */
+ /* flushes but operation is correct. */
+ /* Can't get cache line size from NACA */
+ /* as it is being moved too. */
mtctr r0 /* put # words/line in ctr */
3: addi r6,r6,8 /* copy a cache line */
--
2.43.5
^ permalink raw reply related
* Re: [RFC] entry: Untangle the return value of syscall_enter_from_user_mode from syscall NR
From: Thomas Gleixner @ 2026-07-06 8:16 UTC (permalink / raw)
To: Michal Suchánek, Peter Zijlstra
Cc: Jonathan Corbet, Shuah Khan, Huacai Chen, WANG Xuerui,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Sven Schnelle,
Andy Lutomirski, Ingo Molnar, Borislav Petkov, Dave Hansen, x86,
H. Peter Anvin, Andrew Donnellan, Mark Rutland,
Michal Suchánek, Arnd Bergmann, Jiaxun Yang, Ryan Roberts,
Greg Kroah-Hartman, Mukesh Kumar Chaurasiya, Shrikanth Hegde,
Zong Li, Nam Cao, Deepak Gupta, Lukas Gerlach, Rui Qi, Kees Cook,
linux-doc, linux-kernel, loongarch, linuxppc-dev, linux-riscv,
linux-s390
In-Reply-To: <akVRcPsD_R_CE1qW@kunlun.suse.cz>
On Wed, Jul 01 2026 at 19:42, Michal Suchánek wrote:
>
> if (unlikely(work & SYSCALL_WORK_SYSCALL_TRACEPOINT))
> - syscall = trace_syscall_enter(regs, syscall);
> + *syscall = trace_syscall_enter(regs, *syscall);
>
> - syscall_enter_audit(regs, syscall);
> + syscall_enter_audit(regs, *syscall);
>
> - return ret ? : syscall;
> + return 0;
That breaks trace_syscall_enter() because the probes/BPF muck attached
ot that can:
1) set the return code
2) set syscall to -1L
That works correctly today, but with your sloppy hackery the low level
x86 code falls into sys_ni_syscall() which sets the return code to
-ENOSYS.
^ permalink raw reply
* Re: [PATCH 08/12] soc: fsl: qe: Convert to generic IRQ chip
From: Christophe Leroy (CS GROUP) @ 2026-07-06 7:29 UTC (permalink / raw)
To: Paul Louvel, Qiang Zhao, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin
Cc: linuxppc-dev, linux-arm-kernel, linux-kernel, devicetree,
linux-gpio, Thomas Petazzoni
In-Reply-To: <20260703-qe-pic-gpios-v1-8-6c3e706e27dc@bootlin.com>
Hi Paul,
Le 03/07/2026 à 15:30, Paul Louvel a écrit :
> The generic IRQ chip framework is available to handle IRQ chips. Using
> this framework for the QE interrupt controller allows to simplify the
> driver. Indeed, the framework internally handles operations coded
> directly in the driver.
>
> Add a select dependency to GENERIC_IRQ_CHIP in the PPC platform Kconfig.
>
> Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
> ---
> arch/powerpc/platforms/Kconfig | 1 +
> drivers/soc/fsl/qe/qe_ports_ic.c | 103 ++++++++++++++++++++++++++-------------
> 2 files changed, 70 insertions(+), 34 deletions(-)
>
> diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig
> index c4e61843d9d9..b0b3a80f8cde 100644
> --- a/arch/powerpc/platforms/Kconfig
> +++ b/arch/powerpc/platforms/Kconfig
> @@ -232,6 +232,7 @@ config QE_GPIO
> bool "QE GPIO support"
> depends on QUICC_ENGINE
> select GPIOLIB
> + select GENERIC_IRQ_CHIP
> help
> Say Y here if you're going to use hardware that connects to the
> QE GPIOs.
> diff --git a/drivers/soc/fsl/qe/qe_ports_ic.c b/drivers/soc/fsl/qe/qe_ports_ic.c
> index c8b73b0aa233..d022aa224f6d 100644
> --- a/drivers/soc/fsl/qe/qe_ports_ic.c
> +++ b/drivers/soc/fsl/qe/qe_ports_ic.c
> @@ -20,63 +20,65 @@ struct qepic_data {
> void __iomem *reg;
> struct irq_domain *host;
> int irq;
> + struct irq_chip_generic *gc;
> };
>
> static void qepic_mask(struct irq_data *d)
> {
> - struct qepic_data *data = irq_data_get_irq_chip_data(d);
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> + struct irq_chip_type *ct = irq_data_get_chip_type(d);
>
> - clrbits32(data->reg + CEPIMR, 1 << (31 - irqd_to_hwirq(d)));
> + clrbits32(gc->reg_base + ct->regs.mask, d->mask);
Is there a real added value with this change ?
Previously we had:
00000000 <qepic_mask>:
0: 81 03 00 18 lwz r8,24(r3)
4: 81 28 00 00 lwz r9,0(r8)
8: 7c 00 04 ac hwsync
c: 81 29 00 10 lwz r9,16(r9)
10: 0c 09 00 00 twi 0,r9,0
14: 4c 00 01 2c isync
18: 80 e3 00 08 lwz r7,8(r3)
1c: 3d 40 80 00 lis r10,-32768
20: 81 08 00 00 lwz r8,0(r8)
24: 7d 4a 3c 30 srw r10,r10,r7
28: 7d 29 50 78 andc r9,r9,r10
2c: 7c 00 04 ac hwsync
30: 91 28 00 10 stw r9,16(r8)
34: 4e 80 00 20 blr
Now we have:
00000000 <qepic_mask>:
0: 80 e3 00 18 lwz r7,24(r3)
4: 81 03 00 10 lwz r8,16(r3)
8: 81 27 00 00 lwz r9,0(r7)
c: 81 48 00 94 lwz r10,148(r8)
10: 7d 29 52 14 add r9,r9,r10
14: 7c 00 04 ac hwsync
18: 81 49 00 00 lwz r10,0(r9)
1c: 0c 0a 00 00 twi 0,r10,0
20: 4c 00 01 2c isync
24: 80 c3 00 00 lwz r6,0(r3)
28: 81 27 00 00 lwz r9,0(r7)
2c: 81 08 00 94 lwz r8,148(r8)
30: 7d 4a 30 78 andc r10,r10,r6
34: 7d 29 42 14 add r9,r9,r8
38: 7c 00 04 ac hwsync
3c: 91 49 00 00 stw r10,0(r9)
40: 4e 80 00 20 blr
We now have three more indirect loads (8x lwz instead of 5x), for
loading some value which is already known at compile time.
> }
>
> static void qepic_unmask(struct irq_data *d)
> {
> - struct qepic_data *data = irq_data_get_irq_chip_data(d);
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> + struct irq_chip_type *ct = irq_data_get_chip_type(d);
>
> - setbits32(data->reg + CEPIMR, 1 << (31 - irqd_to_hwirq(d)));
> + setbits32(gc->reg_base + ct->regs.mask, d->mask);
> }
>
> static void qepic_end(struct irq_data *d)
> {
> - struct qepic_data *data = irq_data_get_irq_chip_data(d);
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> + struct irq_chip_type *ct = irq_data_get_chip_type(d);
>
> - out_be32(data->reg + CEPIER, 1 << (31 - irqd_to_hwirq(d)));
> + out_be32(gc->reg_base + ct->regs.eoi, d->mask);
> +}
> +
> +static void qepic_calc_mask(struct irq_data *d)
> +{
> + d->mask = 1 << (31 - irqd_to_hwirq(d));
> }
>
> static int qepic_set_type(struct irq_data *d, unsigned int flow_type)
> {
> - struct qepic_data *data = irq_data_get_irq_chip_data(d);
> - unsigned int vec = (unsigned int)irqd_to_hwirq(d);
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> + struct irq_chip_type *ct = irq_data_get_chip_type(d);
>
> switch (flow_type & IRQ_TYPE_SENSE_MASK) {
> case IRQ_TYPE_EDGE_FALLING:
> - setbits32(data->reg + CEPICR, 1 << (31 - vec));
> + setbits32(gc->reg_base + ct->regs.type, d->mask);
> return 0;
> case IRQ_TYPE_EDGE_BOTH:
> case IRQ_TYPE_NONE:
> - clrbits32(data->reg + CEPICR, 1 << (31 - vec));
> + clrbits32(gc->reg_base + ct->regs.type, d->mask);
> return 0;
> }
> return -EINVAL;
> }
>
> -static struct irq_chip qepic = {
> - .name = "QEPIC",
> - .irq_mask = qepic_mask,
> - .irq_unmask = qepic_unmask,
> - .irq_eoi = qepic_end,
> - .irq_set_type = qepic_set_type,
> -};
> -
> static void qepic_cascade(struct irq_desc *desc)
> {
> struct qepic_data *data = irq_desc_get_handler_data(desc);
> + struct irq_chip_type *ct = data->gc->chip_types;
> struct irq_chip *chip = irq_desc_get_chip(desc);
> unsigned long event, bit;
>
> chained_irq_enter(chip, desc);
>
> - event = in_be32(data->reg + CEPIER);
> + event = in_be32(data->gc->reg_base + ct->regs.eoi);
> if (!event) {
> handle_bad_irq(desc);
> goto out;
> @@ -89,33 +91,64 @@ static void qepic_cascade(struct irq_desc *desc)
> chained_irq_exit(chip, desc);
> }
>
> -static int qepic_host_map(struct irq_domain *h, unsigned int virq, irq_hw_number_t hw)
> +static int qepic_chip_init(struct irq_chip_generic *gc)
> {
> - irq_set_chip_data(virq, h->host_data);
> - irq_set_chip_and_handler(virq, &qepic, handle_fasteoi_irq);
> + struct irq_chip_type *ct = gc->chip_types;
> +
> + ct->regs.mask = CEPIMR;
> + ct->chip.irq_mask = qepic_mask;
> + ct->chip.irq_unmask = qepic_unmask;
> + ct->regs.eoi = CEPIER;
> + ct->chip.irq_eoi = qepic_end;
> + ct->regs.type = CEPICR;
> + ct->chip.irq_set_type = qepic_set_type;
> + ct->chip.irq_calc_mask = qepic_calc_mask;
Are ct->regs.mask, ct->regs.eoi and ct->regs.type used anywhere else
than locally in qepic_{mask/unmask/end/set_type} ?
Christophe
> +
> return 0;
> }
>
> -static const struct irq_domain_ops qepic_host_ops = {
> - .map = qepic_host_map,
> -};
> +static int qepic_domain_init(struct irq_domain *d)
> +{
> + struct qepic_data *data = d->host_data;
>
> -static void qepic_remove(void *res)
> + irq_set_chained_handler_and_data(data->irq, qepic_cascade, data);
> +
> + return 0;
> +}
> +
> +static void qepic_domain_exit(struct irq_domain *d)
> {
> - struct qepic_data *data = res;
> + struct qepic_data *data = d->host_data;
>
> irq_set_chained_handler_and_data(data->irq, NULL, NULL);
> - irq_domain_remove(data->host);
> }
>
> static int qepic_probe(struct platform_device *pdev)
> {
> + struct irq_domain_chip_generic_info dgc_info = {
> + .name = "QEPIC",
> + .handler = handle_fasteoi_irq,
> + .irqs_per_chip = 32,
> + .num_ct = 1,
> + .init = qepic_chip_init,
> + };
> + struct irq_domain_info d_info = {
> + .fwnode = of_fwnode_handle(pdev->dev.of_node),
> + .domain_flags = IRQ_DOMAIN_FLAG_DESTROY_GC,
> + .size = 32,
> + .hwirq_max = 32,
> + .ops = &irq_generic_chip_ops,
> + .dgc_info = &dgc_info,
> + .init = qepic_domain_init,
> + .exit = qepic_domain_exit,
> + };
> struct device *dev = &pdev->dev;
> struct qepic_data *data;
>
> data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
> if (!data)
> return -ENOMEM;
> + d_info.host_data = data;
>
> data->reg = devm_platform_ioremap_resource(pdev, 0);
> if (IS_ERR(data->reg))
> @@ -125,14 +158,16 @@ static int qepic_probe(struct platform_device *pdev)
> if (data->irq < 0)
> return data->irq;
>
> - data->host = irq_domain_create_linear(dev_fwnode(dev), 32, &qepic_host_ops, data);
> - if (!data->host)
> - return -ENODEV;
> + data->host = devm_irq_domain_instantiate(dev, &d_info);
> + if (IS_ERR(data->host))
> + return PTR_ERR(data->host);
>
> - irq_set_chained_handler_and_data(data->irq, qepic_cascade, data);
> -
> - return devm_add_action_or_reset(dev, qepic_remove, data);
> + data->gc = irq_get_domain_generic_chip(data->host, 0);
> + if (!data->gc)
> + return -ENODEV;
> + data->gc->reg_base = data->reg;
>
> + return 0;
> }
>
> static const struct of_device_id qepic_match[] = {
>
^ permalink raw reply
* Re: [PATCH 04/12] dt-bindings: soc: fsl: qe: Add support of IRQ in QE GPIO
From: Krzysztof Kozlowski @ 2026-07-06 6:52 UTC (permalink / raw)
To: Paul Louvel
Cc: Qiang Zhao, Christophe Leroy (CS GROUP), Thomas Gleixner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, linuxppc-dev, linux-arm-kernel, linux-kernel,
devicetree, linux-gpio, Thomas Petazzoni
In-Reply-To: <20260703-qe-pic-gpios-v1-4-6c3e706e27dc@bootlin.com>
On Fri, Jul 03, 2026 at 03:30:12PM +0200, Paul Louvel wrote:
> Some QE GPIO pins have an associated interrupt line in the QE PIC to
> signal state changes on the pin. Add the corresponding
> interrupt-controller / nexus properties to the QE GPIO binding.
>
> Because the GPIO controller does not perform any interrupt handling
> itself, a nexus node (interrupt-map) is used to map each GPIO line
> supporting IRQ to the parent QE PIC interrupt domain.
>
> As the QE PIC can be configured to generate an interrupt on either a
> high-to-low transition or any change in signal state, three
> interrupt-map entries are needed per GPIO pin that can yield an
> interrupt (falling, both, and the "none" case which defaults to both in
> QE PIC). This overhead is necessary because the interrupt-map-pass-thru
> property is not part of the DT specification.
>
> The interrupt-map property is optional: it is not required for GPIO
> banks that have no interrupt capable GPIO line (e.g. port D on MPC8323),
> or when interrupt functionality is not used.
>
> Update the example to show a scenario where each bank supports a
> different numbers of IRQs, or no IRQs at all.
>
> Signed-off-by: Paul Louvel <paul.louvel@bootlin.com>
> ---
> .../bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml | 69 +++++++++++++++++++++-
> 1 file changed, 66 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml b/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml
> index 1af99339ff40..0c849a5698f4 100644
> --- a/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml
> +++ b/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml
> @@ -27,6 +27,17 @@ properties:
> "#gpio-cells":
> const: 2
>
> + "#address-cells":
> + const: 0
> +
> + "#interrupt-cells":
> + const: 2
> +
If this has interrupt-cells, then it is a nexus, thus why isn't this
also a "interrupt-controller"?
> + interrupt-map:
> + description: |
> + Specifies the mapping of GPIO lines to the parent interrupt controller, as the
> + GPIO controller does not do interrupt handling itself.
> +
> required:
> - compatible
> - reg
> @@ -37,9 +48,61 @@ additionalProperties: false
>
> examples:
> - |
> - gpio-controller@1400 {
> - compatible = "fsl,mpc8360-qe-pario-bank", "fsl,mpc8323-qe-pario-bank";
> - reg = <0x1400 0x18>;
I don't get why you rewrite existing example instead of adding new one.
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + pic: interrupt-controller {
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + };
Drop node, irrelevant.
> +
> + gpio-controller@1418 {
> + #gpio-cells = <2>;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + compatible = "fsl,mpc8323-qe-pario-bank";
> + reg = <0x1418 0x18>;
And now you are not following DTS coding style.
> gpio-controller;
> + interrupt-map = <
> + 7 IRQ_TYPE_EDGE_FALLING &pic 4 IRQ_TYPE_EDGE_FALLING
> + 7 IRQ_TYPE_EDGE_BOTH &pic 4 IRQ_TYPE_EDGE_BOTH
> + 7 0 &pic 4 IRQ_TYPE_NONE
> +
> + 9 IRQ_TYPE_EDGE_FALLING &pic 5 IRQ_TYPE_EDGE_FALLING
> + 9 IRQ_TYPE_EDGE_BOTH &pic 5 IRQ_TYPE_EDGE_BOTH
> + 9 0 &pic 5 IRQ_TYPE_NONE
> +
> + 25 IRQ_TYPE_EDGE_FALLING &pic 6 IRQ_TYPE_EDGE_FALLING
> + 25 IRQ_TYPE_EDGE_BOTH &pic 6 IRQ_TYPE_EDGE_BOTH
> + 25 0 &pic 6 IRQ_TYPE_NONE
> +
> + 27 IRQ_TYPE_EDGE_FALLING &pic 7 IRQ_TYPE_EDGE_FALLING
> + 27 IRQ_TYPE_EDGE_BOTH &pic 7 IRQ_TYPE_EDGE_BOTH
> + 27 0 &pic 7 IRQ_TYPE_NONE
> + >;
> + };
> +
> + gpio-controller@1430 {
> #gpio-cells = <2>;
So two new examples? But old one was wrong?
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + compatible = "fsl,mpc8323-qe-pario-bank";
> + reg = <0x1430 0x18>;
> + gpio-controller;
> + interrupt-map = <
> + 24 IRQ_TYPE_EDGE_FALLING &pic 8 IRQ_TYPE_EDGE_FALLING
> + 24 IRQ_TYPE_EDGE_BOTH &pic 8 IRQ_TYPE_EDGE_BOTH
> + 24 0 &pic 8 IRQ_TYPE_NONE
> +
> + 29 IRQ_TYPE_EDGE_FALLING &pic 9 IRQ_TYPE_EDGE_FALLING
> + 29 IRQ_TYPE_EDGE_BOTH &pic 9 IRQ_TYPE_EDGE_BOTH
> + 29 0 &pic 9 IRQ_TYPE_NONE
> + >;
> + };
> +
> + gpio-controller@1448 {
> + #gpio-cells = <2>;
> + compatible = "fsl,mpc8323-qe-pario-bank";
Wait, three examples? But isn't this the same as previous one?
> + reg = <0x1448 0x18>;
> + gpio-controller;
> };
>
> --
> 2.55.0
>
^ permalink raw reply
* Re: [PATCH 03/12] dt-bindings: soc: fsl: qe: Convert QE GPIO to DT schema
From: Krzysztof Kozlowski @ 2026-07-06 6:48 UTC (permalink / raw)
To: Paul Louvel
Cc: Qiang Zhao, Christophe Leroy (CS GROUP), Thomas Gleixner,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
Bartosz Golaszewski, Madhavan Srinivasan, Michael Ellerman,
Nicholas Piggin, linuxppc-dev, linux-arm-kernel, linux-kernel,
devicetree, linux-gpio, Thomas Petazzoni
In-Reply-To: <20260703-qe-pic-gpios-v1-3-6c3e706e27dc@bootlin.com>
On Fri, Jul 03, 2026 at 03:30:11PM +0200, Paul Louvel wrote:
> diff --git a/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml b/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml
> new file mode 100644
> index 000000000000..1af99339ff40
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/fsl,mpc8323-qe-pario-bank.yaml
> @@ -0,0 +1,45 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/gpio/fsl,mpc8323-qe-pario-bank.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Freescale QUICC Engine Parallel I/O (QE PARIO) GPIO Bank
> +
> +maintainers:
> + - Christophe Leroy <christophe.leroy@csgroup.eu>
> +
> +properties:
> + compatible:
> + oneOf:
> + - items:
> + - enum:
> + - fsl,mpc8360-qe-pario-bank
> + - fsl,mpc8569-qe-pario-bank
None of these were in the old binding. You need to mention and
explain (WHY) the changes you are doing to the binding during the
conversion.
> + - const: fsl,mpc8323-qe-pario-bank
> + - const: fsl,mpc8323-qe-pario-bank
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 0/8] Generic IRQ entry/exit support for powerpc
From: Shrikanth Hegde @ 2026-07-06 6:02 UTC (permalink / raw)
To: Andreas Schwab, Christophe Leroy (CS GROUP)
Cc: Mukesh Kumar Chaurasiya (IBM), maddy, mpe, npiggin, ryabinin.a.a,
glider, andreyknvl, dvyukov, vincenzo.frascino, oleg, kees, luto,
wad, mchauras, thuth, ruanjinjie, akpm, macro, ldv, charlie,
deller, kevin.brodsky, ritesh.list, yeoreum.yun, agordeev, segher,
mark.rutland, ryan.roberts, pmladek, feng.tang, peterz, kan.liang,
linuxppc-dev, linux-kernel, kasan-dev
In-Reply-To: <8733xxve3h.fsf@igel.home>
Hi Andreas.
On 7/5/26 5:32 PM, Andreas Schwab wrote:
> BUG: Unable to handle kernel data access at 0x30af548c0000028
> Faulting instruction address: 0xc0000000000af47c
>
> c0000000000aee6c <.sched_balance_find_src_group>:
>
> c0000000000af474: e9 3f 00 18 ld r9,24(r31)
> c0000000000af478: e9 29 0d 48 ld r9,3400(r9)
> c0000000000af47c: 89 49 00 28 lbz r10,40(r9)
> c0000000000af480: 7c 0a e0 40 cmplw r10,r28
>
Does the stack-trace change every time?
There were couple more fixes on top of it. Is it included in your kernel already?
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next&id=334f3f6d7a1660fd65597bad9960bfa33a716d35
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git/commit/?h=next&id=4e1187e12de40b5301977b2476d21b569358dafb
^ permalink raw reply
* Re: [PATCH v4] riscv: mm: Avoid spurious fault after hotplugging vmemmap
From: Vivian Wang @ 2026-07-06 5:48 UTC (permalink / raw)
To: Muchun Song
Cc: linuxppc-dev, Paul Walmsley, Palmer Dabbelt, Alexandre Ghiti,
Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, linux-riscv, linux-kernel,
linux-mm, Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP)
In-Reply-To: <214FC970-465A-4E45-98C0-17978D63DE89@linux.dev>
On 7/6/26 13:38, Muchun Song wrote:
>
>> On Jul 6, 2026, at 13:04, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>>
>> [ powerpc maintainers: Thoughts on replacing the ptesync in
>> vmemmap_set_pmd() with a flush_cache_vmap() post-vmemmap-hotplug in the
>> generic code? ]
>>
>> On 7/6/26 11:00, Muchun Song wrote:
>>>> On Jun 30, 2026, at 15:51, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>>>>
>>>> section_activate() does not flush TLB after populating new vmemmap
>>>> pages. On most architectures, this is okay. However it is a problem on
>>>> RISC-V since there the TLB caching non-present entries is permitted,
>>>> which causes spurious faults on some hardwares.
>>>>
>>>> This seems to be most easily reproduced with DEBUG_VM=y and
>>>> PAGE_POISONING=y, which causes these newly mapped struct pages to be
>>>> poisoned i.e. written to immediately after mapping.
>>>>
>>>> Add a hook vmemmap_populate_finalize() in __populate_section_memmap()
>>>> after population, to allow architectures to handle such situations as
>>>> needed. Then implement it on RISC-V to arrange for the existing
>>>> exception handler code to deal with these faults if they happen.
>>>>
>>>> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
>>>> ---
>>>> Changes in v4:
>>>> - Rebase on v7.2-rc1, drop dependencies
>>>> - (No code changes otherwise)
>>>> - (A concurrency fix for mark_new_valid_map was sent independently)
>>>> https://lore.kernel.org/linux-riscv/20260629-riscv-mm-new-valid-map-ordering-v1-1-60d8c10c6292@iscas.ac.cn/
>>>> - Link to v3: https://patch.msgid.link/20260605-mark-after-vmemmap-populate-v3-1-a06001ac9264@iscas.ac.cn
>>>>
>>>> Changes in v3:
>>>> - Merged back into one patch (Mike)
>>>> - (No code changes otherwise.)
>>>> - Link to v2: https://patch.msgid.link/20260604-mark-after-vmemmap-populate-v2-0-ab6a7d03b434@iscas.ac.cn
>>>>
>>>> Changes in v2:
>>>> - Split patch in two, hook point and riscv hook
>>>> - Explain hook necessity in patch 1 message (Mike)
>>>> - Make hook #define based (Mike)
>>>> - Call finalize hook only on populate success
>>>> - Link to v1: https://patch.msgid.link/20260525-mark-after-vmemmap-populate-v1-1-e698d859ba16@iscas.ac.cn
>>>> ---
>>>> arch/riscv/include/asm/pgtable.h | 4 ++++
>>>> arch/riscv/mm/init.c | 6 ++++++
>>>> mm/sparse-vmemmap.c | 8 ++++++++
>>>> 3 files changed, 18 insertions(+)
>>>>
>>>> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
>>>> index 5d5756bda82e..6b000c990ba7 100644
>>>> --- a/arch/riscv/include/asm/pgtable.h
>>>> +++ b/arch/riscv/include/asm/pgtable.h
>>>> @@ -1253,6 +1253,10 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>>>> #define TASK_SIZE FIXADDR_START
>>>> #endif
>>>>
>>>> +/* Needed on SPARSEMEM_VMEMMAP */
>>>> +#define vmemmap_populate_finalize vmemmap_populate_finalize
>>>> +void __meminit vmemmap_populate_finalize(void);
>>>> +
>>>> #else /* CONFIG_MMU */
>>>>
>>>> #define PAGE_SHARED __pgprot(0)
>>>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>>>> index 5b1b3c88b4d1..800cb5c007d1 100644
>>>> --- a/arch/riscv/mm/init.c
>>>> +++ b/arch/riscv/mm/init.c
>>>> @@ -1372,6 +1372,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>>>> */
>>>> return vmemmap_populate_hugepages(start, end, node, altmap);
>>>> }
>>>> +
>>>> +void __meminit vmemmap_populate_finalize(void)
>>>> +{
>>>> + /* Avoid faults on cached non-present TLB entries. */
>>>> + mark_new_valid_map();
>>>> +}
>>>> #endif
>>>>
>>>> #if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
>>>> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
>>>> index 99e2be39671b..290cafcfd723 100644
>>>> --- a/mm/sparse-vmemmap.c
>>>> +++ b/mm/sparse-vmemmap.c
>>>> @@ -544,6 +544,12 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
>>>>
>>>> #endif
>>>>
>>>> +#ifndef vmemmap_populate_finalize
>>>> +static void __meminit vmemmap_populate_finalize(void)
>>>> +{
>>>> +}
>>>> +#endif
>>>> +
>>>> struct page * __meminit __populate_section_memmap(unsigned long pfn,
>>>> unsigned long nr_pages, int nid, struct vmem_altmap *altmap,
>>>> struct dev_pagemap *pgmap)
>>>> @@ -564,6 +570,8 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn,
>>>> if (r < 0)
>>>> return NULL;
>>>>
>>>> + vmemmap_populate_finalize();
>>> Does the hook of flush_cache_vmap() work for you? From the document of
>>> cachetlb.rst, it said:
>>>
>>> 6) ``void flush_cache_vmap(unsigned long start, unsigned long end)``
>>> ``void flush_cache_vunmap(unsigned long start, unsigned long end)``
>>>
>>> Here in these two interfaces we are flushing a specific range
>>> of (kernel) virtual addresses from the cache. After running,
>>> there will be no entries in the cache for the kernel address
>>> space for virtual addresses in the range 'start' to 'end-1'.
>>>
>>> It seems that flush_cache_vmap() is supposed to be called after a new kernel
>>> mapping has been installed, but before this address range is accessed.
>> Good point. I had initially avoided flush_cache_vmap() because, to be
>> honest, it looked scary. But the combination of "have vmemmap" and "have
>> flush_cache_vmap()" is much less scary.
>>
>> I'd need to drop the address range check in RISC-V's flush_cache_vmap(),
>> but might as well.
> No. Please a new check for vmemmap address range.
Okay, I'll do that in v5.
>
>>> Therefore, invoking flush_cache_vmap() here aligns perfectly with its interface
>>> definition. But how would this change impact other architectures? Currently,
>>> among architectures where CONFIG_SPARSEMEM=y, only RISC-V and PowerPC provide
>>> a concrete implementation for flush_cache_vmap().
>>>
>>> For PowerPC, the implementation is as follows:
>>>
>>> static inline void flush_cache_vmap(unsigned long start, unsigned long end)
>>> {
>>> asm volatile("ptesync" ::: "memory");
>>> }
>>>
>>> Here, flush_cache_vmap() is also intended to supply the ptesync instruction
>>> that the kernel address mapping lacks. However, flush_cache_vmap() is not
>>> called in the __populate_section_memmap() path. So, how does PowerPC ensure
>>> ptesync is executed there? The answer lies in the architecture-specific
>>> vmemmap_set_pmd(), which injects the necessary ptesync.
>>>
>>> If we choose to reuse flush_cache_vmap() in the generic path, it yields the
>>> following benefits:
>>>
>>> - Avoids architectural churn: We do not need to introduce a new hook
>>> like vmemmap_populate_finalize().
>>> - Cleans up arch code: PowerPC can deprecate its custom vmemmap_set_pmd()
>>> and migrate to the generic implementation.
>>>
>>> Let me know if this rationale makes sense, or if there are any hidden edge
>>> cases I might have overlooked regarding other architectures.
>>>
>>> Thanks,
>>> Muchun
>> At least on the face of it, it makes sense. The main thing is I don't
>> know much about powerpc. So I'm also hoping powerpc maintainers could
>> chime in.
> You do not need to know about powerpc since the change of powerpc is not
> a part of this patch. It should be a separate code clean up for powerpc.
Ah, good point. I'll just use flush_cache_vmap() in v5, and, as you
said, the powerpc stuff can come later.
Thanks,
Vivian "dramforever" Wang
^ permalink raw reply
* Re: [PATCH v4] riscv: mm: Avoid spurious fault after hotplugging vmemmap
From: Muchun Song @ 2026-07-06 5:38 UTC (permalink / raw)
To: Vivian Wang
Cc: linuxppc-dev, Paul Walmsley, Palmer Dabbelt, Alexandre Ghiti,
Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, linux-riscv, linux-kernel,
linux-mm, Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP)
In-Reply-To: <5fac578c-ff97-4721-96f3-8ba495f0556a@iscas.ac.cn>
> On Jul 6, 2026, at 13:04, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>
> [ powerpc maintainers: Thoughts on replacing the ptesync in
> vmemmap_set_pmd() with a flush_cache_vmap() post-vmemmap-hotplug in the
> generic code? ]
>
> On 7/6/26 11:00, Muchun Song wrote:
>>> On Jun 30, 2026, at 15:51, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>>>
>>> section_activate() does not flush TLB after populating new vmemmap
>>> pages. On most architectures, this is okay. However it is a problem on
>>> RISC-V since there the TLB caching non-present entries is permitted,
>>> which causes spurious faults on some hardwares.
>>>
>>> This seems to be most easily reproduced with DEBUG_VM=y and
>>> PAGE_POISONING=y, which causes these newly mapped struct pages to be
>>> poisoned i.e. written to immediately after mapping.
>>>
>>> Add a hook vmemmap_populate_finalize() in __populate_section_memmap()
>>> after population, to allow architectures to handle such situations as
>>> needed. Then implement it on RISC-V to arrange for the existing
>>> exception handler code to deal with these faults if they happen.
>>>
>>> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
>>> ---
>>> Changes in v4:
>>> - Rebase on v7.2-rc1, drop dependencies
>>> - (No code changes otherwise)
>>> - (A concurrency fix for mark_new_valid_map was sent independently)
>>> https://lore.kernel.org/linux-riscv/20260629-riscv-mm-new-valid-map-ordering-v1-1-60d8c10c6292@iscas.ac.cn/
>>> - Link to v3: https://patch.msgid.link/20260605-mark-after-vmemmap-populate-v3-1-a06001ac9264@iscas.ac.cn
>>>
>>> Changes in v3:
>>> - Merged back into one patch (Mike)
>>> - (No code changes otherwise.)
>>> - Link to v2: https://patch.msgid.link/20260604-mark-after-vmemmap-populate-v2-0-ab6a7d03b434@iscas.ac.cn
>>>
>>> Changes in v2:
>>> - Split patch in two, hook point and riscv hook
>>> - Explain hook necessity in patch 1 message (Mike)
>>> - Make hook #define based (Mike)
>>> - Call finalize hook only on populate success
>>> - Link to v1: https://patch.msgid.link/20260525-mark-after-vmemmap-populate-v1-1-e698d859ba16@iscas.ac.cn
>>> ---
>>> arch/riscv/include/asm/pgtable.h | 4 ++++
>>> arch/riscv/mm/init.c | 6 ++++++
>>> mm/sparse-vmemmap.c | 8 ++++++++
>>> 3 files changed, 18 insertions(+)
>>>
>>> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
>>> index 5d5756bda82e..6b000c990ba7 100644
>>> --- a/arch/riscv/include/asm/pgtable.h
>>> +++ b/arch/riscv/include/asm/pgtable.h
>>> @@ -1253,6 +1253,10 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>>> #define TASK_SIZE FIXADDR_START
>>> #endif
>>>
>>> +/* Needed on SPARSEMEM_VMEMMAP */
>>> +#define vmemmap_populate_finalize vmemmap_populate_finalize
>>> +void __meminit vmemmap_populate_finalize(void);
>>> +
>>> #else /* CONFIG_MMU */
>>>
>>> #define PAGE_SHARED __pgprot(0)
>>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>>> index 5b1b3c88b4d1..800cb5c007d1 100644
>>> --- a/arch/riscv/mm/init.c
>>> +++ b/arch/riscv/mm/init.c
>>> @@ -1372,6 +1372,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>>> */
>>> return vmemmap_populate_hugepages(start, end, node, altmap);
>>> }
>>> +
>>> +void __meminit vmemmap_populate_finalize(void)
>>> +{
>>> + /* Avoid faults on cached non-present TLB entries. */
>>> + mark_new_valid_map();
>>> +}
>>> #endif
>>>
>>> #if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
>>> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
>>> index 99e2be39671b..290cafcfd723 100644
>>> --- a/mm/sparse-vmemmap.c
>>> +++ b/mm/sparse-vmemmap.c
>>> @@ -544,6 +544,12 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
>>>
>>> #endif
>>>
>>> +#ifndef vmemmap_populate_finalize
>>> +static void __meminit vmemmap_populate_finalize(void)
>>> +{
>>> +}
>>> +#endif
>>> +
>>> struct page * __meminit __populate_section_memmap(unsigned long pfn,
>>> unsigned long nr_pages, int nid, struct vmem_altmap *altmap,
>>> struct dev_pagemap *pgmap)
>>> @@ -564,6 +570,8 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn,
>>> if (r < 0)
>>> return NULL;
>>>
>>> + vmemmap_populate_finalize();
>> Does the hook of flush_cache_vmap() work for you? From the document of
>> cachetlb.rst, it said:
>>
>> 6) ``void flush_cache_vmap(unsigned long start, unsigned long end)``
>> ``void flush_cache_vunmap(unsigned long start, unsigned long end)``
>>
>> Here in these two interfaces we are flushing a specific range
>> of (kernel) virtual addresses from the cache. After running,
>> there will be no entries in the cache for the kernel address
>> space for virtual addresses in the range 'start' to 'end-1'.
>>
>> It seems that flush_cache_vmap() is supposed to be called after a new kernel
>> mapping has been installed, but before this address range is accessed.
>
> Good point. I had initially avoided flush_cache_vmap() because, to be
> honest, it looked scary. But the combination of "have vmemmap" and "have
> flush_cache_vmap()" is much less scary.
>
> I'd need to drop the address range check in RISC-V's flush_cache_vmap(),
> but might as well.
No. Please a new check for vmemmap address range.
>
>> Therefore, invoking flush_cache_vmap() here aligns perfectly with its interface
>> definition. But how would this change impact other architectures? Currently,
>> among architectures where CONFIG_SPARSEMEM=y, only RISC-V and PowerPC provide
>> a concrete implementation for flush_cache_vmap().
>>
>> For PowerPC, the implementation is as follows:
>>
>> static inline void flush_cache_vmap(unsigned long start, unsigned long end)
>> {
>> asm volatile("ptesync" ::: "memory");
>> }
>>
>> Here, flush_cache_vmap() is also intended to supply the ptesync instruction
>> that the kernel address mapping lacks. However, flush_cache_vmap() is not
>> called in the __populate_section_memmap() path. So, how does PowerPC ensure
>> ptesync is executed there? The answer lies in the architecture-specific
>> vmemmap_set_pmd(), which injects the necessary ptesync.
>>
>> If we choose to reuse flush_cache_vmap() in the generic path, it yields the
>> following benefits:
>>
>> - Avoids architectural churn: We do not need to introduce a new hook
>> like vmemmap_populate_finalize().
>> - Cleans up arch code: PowerPC can deprecate its custom vmemmap_set_pmd()
>> and migrate to the generic implementation.
>>
>> Let me know if this rationale makes sense, or if there are any hidden edge
>> cases I might have overlooked regarding other architectures.
>>
>> Thanks,
>> Muchun
>
> At least on the face of it, it makes sense. The main thing is I don't
> know much about powerpc. So I'm also hoping powerpc maintainers could
> chime in.
You do not need to know about powerpc since the change of powerpc is not
a part of this patch. It should be a separate code clean up for powerpc.
>
> I also don't know how this would affect new archs, but if they need
> flush_cache_vmap() they *probably* also want this treatment for vmemmap
> hotplug? I guess we can deal with that when it happens.
>
> Thanks,
> Vivian "dramforever" Wang
^ permalink raw reply
* Re: [RFC] entry: Untangle the return value of syscall_enter_from_user_mode from syscall NR
From: Sven Schnelle @ 2026-07-06 5:27 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Michal Suchánek, Peter Zijlstra, Thomas Gleixner,
Jonathan Corbet, Shuah Khan, Huacai Chen, WANG Xuerui,
Madhavan Srinivasan, Michael Ellerman, Nicholas Piggin,
Christophe Leroy (CS GROUP), Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Heiko Carstens, Vasily Gorbik,
Alexander Gordeev, Christian Borntraeger, Andy Lutomirski,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, Andrew Donnellan,
Mark Rutland, Arnd Bergmann, Jiaxun Yang, Ryan Roberts,
Greg Kroah-Hartman, Mukesh Kumar Chaurasiya, Shrikanth Hegde,
Zong Li, Nam Cao, Deepak Gupta, Lukas Gerlach, Rui Qi, Kees Cook,
linux-doc, linux-kernel, loongarch, linuxppc-dev, linux-riscv,
linux-s390
In-Reply-To: <69ACC6A7-7845-41B4-B0D0-2E6FCDA7443D@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> On July 3, 2026 4:39:18 AM PDT, Sven Schnelle <svens@linux.ibm.com>
> wrote:
>>Michal Suchánek <msuchanek@suse.de> writes:
>>
>>> The same could be asked of syscall_enter_from_user_mode. I find it
> very
>>> odd. Why does it conflate the syscall number with its return value?
>>>
>>> It never uses the syscall number passed in except when returning it
>>> unchanged. When it pokes the registers it reads the syscall number
> from
>>> them.
>>>
>>> If the caller of syscall_enter_from_user_mode only read the syscall
>>> number from the registers when syscall_enter_from_user_mode returns
> and
>>> indicates the syscall should be still executed this whole shenigan
> would
>>
>>I agree. The fact that if (nr < NR_syscall) just works because -1
> gets
>>casted to 0xffffffff and is therefore out of bounds is very odd.
>>
>
> Not at all strange. It is an *extremely* common construct in C,
> especially for range checking values into [0, n).
A clear indication that this is not as common as you think is that
there's an extra comment in arch/x86/entry/syscall_64.c:
/*
* Convert negative numbers to very high and thus out of range
* numbers for comparisons.
*/
If everyone knows what this is the comment wouldn't be necessary. But
that cast is not the thing i'm really interested in - if it stays
that way, fine with me. But I would like to see the change from Michal
going in which untangles the secure_computing() return value from the
syscall number. Because this behaviour is very subtle and removing that
would make things easier. (And also easier to read/audit, which is
always importand with security related code, which seccomp/syscall
clearly is).
> In addition to being idiomatic, keep in mind that this is one of the
> absolutely most performance critical paths in the entire kernel. One
> of the fundamental cornerstones behind Unix is to keep system calls
> cheap so that they can be simple building blocks for more complex
> operations. It is not the only possible design philosophy, but it is
> the one we chose to adopt, quite successfully.
>
> The downside? Squeezing every possible cycle out of the system call
> path becomes one of the most essential tuning tasks. The good part is
> that keeping the system call path clean also makes it maintainable,
> even when there are quirks.
I haven't measured it, but I doubt that the unsigned vs signed syscall
bounds check makes a difference in real world scenarios. Even for
ni_syscall cases it would be small. With the C entry code we have
nowadays such optimizations should be left to the compiler. I wouldn't
be surprised if the generated code is even the same.
But as written above, I don't really care about this.
^ permalink raw reply
* Re: [PATCH v4] riscv: mm: Avoid spurious fault after hotplugging vmemmap
From: Vivian Wang @ 2026-07-06 5:04 UTC (permalink / raw)
To: Muchun Song, linuxppc-dev
Cc: Paul Walmsley, Palmer Dabbelt, Alexandre Ghiti, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
linux-riscv, linux-kernel, linux-mm, Madhavan Srinivasan,
Michael Ellerman, Nicholas Piggin, Christophe Leroy (CS GROUP)
In-Reply-To: <7B0CB4ED-C190-4F49-97EE-E1F14F08DED2@linux.dev>
[ powerpc maintainers: Thoughts on replacing the ptesync in
vmemmap_set_pmd() with a flush_cache_vmap() post-vmemmap-hotplug in the
generic code? ]
On 7/6/26 11:00, Muchun Song wrote:
>> On Jun 30, 2026, at 15:51, Vivian Wang <wangruikang@iscas.ac.cn> wrote:
>>
>> section_activate() does not flush TLB after populating new vmemmap
>> pages. On most architectures, this is okay. However it is a problem on
>> RISC-V since there the TLB caching non-present entries is permitted,
>> which causes spurious faults on some hardwares.
>>
>> This seems to be most easily reproduced with DEBUG_VM=y and
>> PAGE_POISONING=y, which causes these newly mapped struct pages to be
>> poisoned i.e. written to immediately after mapping.
>>
>> Add a hook vmemmap_populate_finalize() in __populate_section_memmap()
>> after population, to allow architectures to handle such situations as
>> needed. Then implement it on RISC-V to arrange for the existing
>> exception handler code to deal with these faults if they happen.
>>
>> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn>
>> ---
>> Changes in v4:
>> - Rebase on v7.2-rc1, drop dependencies
>> - (No code changes otherwise)
>> - (A concurrency fix for mark_new_valid_map was sent independently)
>> https://lore.kernel.org/linux-riscv/20260629-riscv-mm-new-valid-map-ordering-v1-1-60d8c10c6292@iscas.ac.cn/
>> - Link to v3: https://patch.msgid.link/20260605-mark-after-vmemmap-populate-v3-1-a06001ac9264@iscas.ac.cn
>>
>> Changes in v3:
>> - Merged back into one patch (Mike)
>> - (No code changes otherwise.)
>> - Link to v2: https://patch.msgid.link/20260604-mark-after-vmemmap-populate-v2-0-ab6a7d03b434@iscas.ac.cn
>>
>> Changes in v2:
>> - Split patch in two, hook point and riscv hook
>> - Explain hook necessity in patch 1 message (Mike)
>> - Make hook #define based (Mike)
>> - Call finalize hook only on populate success
>> - Link to v1: https://patch.msgid.link/20260525-mark-after-vmemmap-populate-v1-1-e698d859ba16@iscas.ac.cn
>> ---
>> arch/riscv/include/asm/pgtable.h | 4 ++++
>> arch/riscv/mm/init.c | 6 ++++++
>> mm/sparse-vmemmap.c | 8 ++++++++
>> 3 files changed, 18 insertions(+)
>>
>> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
>> index 5d5756bda82e..6b000c990ba7 100644
>> --- a/arch/riscv/include/asm/pgtable.h
>> +++ b/arch/riscv/include/asm/pgtable.h
>> @@ -1253,6 +1253,10 @@ static inline pte_t pte_swp_clear_exclusive(pte_t pte)
>> #define TASK_SIZE FIXADDR_START
>> #endif
>>
>> +/* Needed on SPARSEMEM_VMEMMAP */
>> +#define vmemmap_populate_finalize vmemmap_populate_finalize
>> +void __meminit vmemmap_populate_finalize(void);
>> +
>> #else /* CONFIG_MMU */
>>
>> #define PAGE_SHARED __pgprot(0)
>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>> index 5b1b3c88b4d1..800cb5c007d1 100644
>> --- a/arch/riscv/mm/init.c
>> +++ b/arch/riscv/mm/init.c
>> @@ -1372,6 +1372,12 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
>> */
>> return vmemmap_populate_hugepages(start, end, node, altmap);
>> }
>> +
>> +void __meminit vmemmap_populate_finalize(void)
>> +{
>> + /* Avoid faults on cached non-present TLB entries. */
>> + mark_new_valid_map();
>> +}
>> #endif
>>
>> #if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
>> diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
>> index 99e2be39671b..290cafcfd723 100644
>> --- a/mm/sparse-vmemmap.c
>> +++ b/mm/sparse-vmemmap.c
>> @@ -544,6 +544,12 @@ static int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
>>
>> #endif
>>
>> +#ifndef vmemmap_populate_finalize
>> +static void __meminit vmemmap_populate_finalize(void)
>> +{
>> +}
>> +#endif
>> +
>> struct page * __meminit __populate_section_memmap(unsigned long pfn,
>> unsigned long nr_pages, int nid, struct vmem_altmap *altmap,
>> struct dev_pagemap *pgmap)
>> @@ -564,6 +570,8 @@ struct page * __meminit __populate_section_memmap(unsigned long pfn,
>> if (r < 0)
>> return NULL;
>>
>> + vmemmap_populate_finalize();
> Does the hook of flush_cache_vmap() work for you? From the document of
> cachetlb.rst, it said:
>
> 6) ``void flush_cache_vmap(unsigned long start, unsigned long end)``
> ``void flush_cache_vunmap(unsigned long start, unsigned long end)``
>
> Here in these two interfaces we are flushing a specific range
> of (kernel) virtual addresses from the cache. After running,
> there will be no entries in the cache for the kernel address
> space for virtual addresses in the range 'start' to 'end-1'.
>
> It seems that flush_cache_vmap() is supposed to be called after a new kernel
> mapping has been installed, but before this address range is accessed.
Good point. I had initially avoided flush_cache_vmap() because, to be
honest, it looked scary. But the combination of "have vmemmap" and "have
flush_cache_vmap()" is much less scary.
I'd need to drop the address range check in RISC-V's flush_cache_vmap(),
but might as well.
> Therefore, invoking flush_cache_vmap() here aligns perfectly with its interface
> definition. But how would this change impact other architectures? Currently,
> among architectures where CONFIG_SPARSEMEM=y, only RISC-V and PowerPC provide
> a concrete implementation for flush_cache_vmap().
>
> For PowerPC, the implementation is as follows:
>
> static inline void flush_cache_vmap(unsigned long start, unsigned long end)
> {
> asm volatile("ptesync" ::: "memory");
> }
>
> Here, flush_cache_vmap() is also intended to supply the ptesync instruction
> that the kernel address mapping lacks. However, flush_cache_vmap() is not
> called in the __populate_section_memmap() path. So, how does PowerPC ensure
> ptesync is executed there? The answer lies in the architecture-specific
> vmemmap_set_pmd(), which injects the necessary ptesync.
>
> If we choose to reuse flush_cache_vmap() in the generic path, it yields the
> following benefits:
>
> - Avoids architectural churn: We do not need to introduce a new hook
> like vmemmap_populate_finalize().
> - Cleans up arch code: PowerPC can deprecate its custom vmemmap_set_pmd()
> and migrate to the generic implementation.
>
> Let me know if this rationale makes sense, or if there are any hidden edge
> cases I might have overlooked regarding other architectures.
>
> Thanks,
> Muchun
At least on the face of it, it makes sense. The main thing is I don't
know much about powerpc. So I'm also hoping powerpc maintainers could
chime in.
I also don't know how this would affect new archs, but if they need
flush_cache_vmap() they *probably* also want this treatment for vmemmap
hotplug? I guess we can deal with that when it happens.
Thanks,
Vivian "dramforever" Wang
^ permalink raw reply
* Re: [PATCH v16 01/18] seccomp: Convert __secure_computing() to return boolean
From: Jinjie Ruan @ 2026-07-06 2:41 UTC (permalink / raw)
To: Ada Couprie Diaz
Cc: oleg, richard.henderson, mattst88, linmag7, linux,
catalin.marinas, will, kees, guoren, chenhuacai, kernel, geert,
tsbogend, James.Bottomley, deller, maddy, mpe, npiggin, chleroy,
pjw, palmer, aou, alex, hca, gor, agordeev, borntraeger, svens,
ysato, dalias, glaubitz, richard, anton.ivanov, johannes, luto,
tglx, mingo, bp, dave.hansen, hpa, chris, jcmvbkbc, peterz, wad,
thuth, mark.rutland, kevin.brodsky, linusw, yeoreum.yun, song,
james.morse, anshuman.khandual, broonie, liqiang01, pengcan,
ryan.roberts, yangtiezhu, sshegde, mchauras, austin.kim, jchrist,
arnd, thomas.weissschuh, sohil.mehta, andrew.cooper3, jgross, kas,
x86, linux-alpha, linux-kernel, linux-arm-kernel, linux-mm,
linux-csky, loongarch, linux-m68k, linux-mips, linux-parisc,
linuxppc-dev, linux-riscv, linux-s390, linux-sh, linux-um
In-Reply-To: <b8f3b5cd-8d8a-4396-ba0c-011a83234dd9@arm.com>
On 7/1/2026 12:37 AM, Ada Couprie Diaz wrote:
> Hi Jinjie,
>
> On 29/06/2026 14:05, Jinjie Ruan wrote:
>> The return value of __secure_computing() currently uses 0 to indicate
>> that a system call should be allowed, and -1 to indicate that it should
>> be blocked/killed. This 0/-1 pattern is non-intuitive for a security
>> check function and makes the control flow at the call sites less
>> readable.
>>
>> Furthermore, any potential future changes to these return values would
>> require a high-risk, error-prone audit of all its users across different
>> architectures.
>>
>> Sanitize this logic by converting the return type of __secure_computing()
>> to a proper boolean, where 'true' explicitly means 'allow' and 'false'
>> means 'fail/deny'.
>>
>> Update all the two dozen or so call sites across the tree to align with
>> this new boolean semantic. No functional changes are intended, as the
>> callers still return -1 to the lower-level assembly entry code upon
>> seccomp denial.
> Would it be relevant to mention that this fixes the unsound return value of
> `syscall_trace_enter()` in generic entry, which motivated the patch
> initially[0] ?
That's a very good point. It's definitely worth mentioning
>> Suggested-by: Thomas Gleixner <tglx@kernel.org>
>> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
>> ---
>> arch/alpha/kernel/ptrace.c | 2 +-
>> arch/arm/kernel/ptrace.c | 2 +-
>> arch/arm64/kernel/ptrace.c | 2 +-
>> arch/csky/kernel/ptrace.c | 2 +-
>> arch/m68k/kernel/ptrace.c | 2 +-
>> arch/mips/kernel/ptrace.c | 2 +-
>> arch/parisc/kernel/ptrace.c | 2 +-
>> arch/sh/kernel/ptrace_32.c | 2 +-
>> arch/um/kernel/skas/syscall.c | 2 +-
>> arch/x86/entry/vsyscall/vsyscall_64.c | 2 +-
>> arch/xtensa/kernel/ptrace.c | 3 +--
>> include/linux/entry-common.h | 7 +++---
>> include/linux/seccomp.h | 10 ++++----
>> kernel/seccomp.c | 34 +++++++++++++--------------
>> 14 files changed, 36 insertions(+), 38 deletions(-)
>
> This is missing an update to the Kconfig documentation, a possible
> suggestion :
Will update it.
>
> diff --git a/arch/Kconfig b/arch/Kconfig
> index fa7507ac8e13..9e3d40088afb 100644
> --- a/arch/Kconfig
> +++ b/arch/Kconfig
> @@ -637,7 +637,7 @@ config HAVE_ARCH_SECCOMP_FILTER
> - syscall_set_return_value()
> - SIGSYS siginfo_t support
> - secure_computing is called from a ptrace_event()-safe context
> - - secure_computing return value is checked and a return value
> of -1
> + - secure_computing return value is checked and if false
> results in the system call being skipped immediately.
> - seccomp syscall wired up
> - if !HAVE_SPARSE_SYSCALL_NR, have SECCOMP_ARCH_NATIVE,
>
>> [...]
>> diff --git a/include/linux/entry-common.h b/include/linux/entry-common.h
>> index 416a3352261f..3f66320e46d3 100644
>> --- a/include/linux/entry-common.h
>> +++ b/include/linux/entry-common.h
>> @@ -100,9 +100,8 @@ static __always_inline long
>> syscall_trace_enter(struct pt_regs *regs, unsigned l
>> /* Do seccomp after ptrace, to catch any tracer changes. */
>> if (work & SYSCALL_WORK_SECCOMP) {
>> - ret = __secure_computing();
>> - if (ret == -1L)
>> - return ret;
>> + if (!__secure_computing())
>> + return -1L;
>> }
>> /* Either of the above might have changed the syscall number */
>> @@ -113,7 +112,7 @@ static __always_inline long
>> syscall_trace_enter(struct pt_regs *regs, unsigned l
>> syscall_enter_audit(regs, syscall);
>> - return ret ? : syscall;
>> + return syscall;
>> }
>> [...]
>
> Otherwise this feels like a more appropriate change with regards to
> "safeguarding against new `secure_computing()` return value" !
>
> With the updated Kconfig :
> Reviewed-by: Ada Couprie Diaz <ada.coupriediaz@arm.com>
>
> Thanks,
> Ada
>
> [0]: https://lore.kernel.org/r/20260511092103.1974980-2-
> ruanjinjie@huawei.com
>
>
^ permalink raw reply
* [PATCH 42/42] ASoC: sprd: Use devm_of_reserved_mem_device_init()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init() to ensure
the reserved memory region is released on device removal, fixing a
missing cleanup — the driver has no remove function. Also drop the
now-unused local variable np.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
sound/soc/sprd/sprd-pcm-dma.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/sound/soc/sprd/sprd-pcm-dma.c b/sound/soc/sprd/sprd-pcm-dma.c
index cbf5bf82d96e..220f55d475af 100644
--- a/sound/soc/sprd/sprd-pcm-dma.c
+++ b/sound/soc/sprd/sprd-pcm-dma.c
@@ -459,10 +459,9 @@ static const struct snd_soc_component_driver sprd_soc_component = {
static int sprd_soc_platform_probe(struct platform_device *pdev)
{
- struct device_node *np = pdev->dev.of_node;
int ret;
- ret = of_reserved_mem_device_init_by_idx(&pdev->dev, np, 0);
+ ret = devm_of_reserved_mem_device_init(&pdev->dev);
if (ret)
dev_warn(&pdev->dev,
"no reserved DMA memory for audio platform device\n");
--
2.53.0
^ permalink raw reply related
* [PATCH 41/42] ASoC: fsl: imx-rpmsg: Use devm_of_reserved_mem_device_init_by_idx()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init_by_idx() to
ensure the reserved memory region is released on device removal, fixing
a missing cleanup — the driver has no remove function.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
sound/soc/fsl/imx-rpmsg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/fsl/imx-rpmsg.c b/sound/soc/fsl/imx-rpmsg.c
index 5f1af258caf2..f504d94c4f68 100644
--- a/sound/soc/fsl/imx-rpmsg.c
+++ b/sound/soc/fsl/imx-rpmsg.c
@@ -199,7 +199,7 @@ static int imx_rpmsg_probe(struct platform_device *pdev)
goto fail;
}
- ret = of_reserved_mem_device_init_by_idx(&pdev->dev, np, 0);
+ ret = devm_of_reserved_mem_device_init_by_idx(&pdev->dev, np, 0);
if (ret)
dev_warn(&pdev->dev, "no reserved DMA memory\n");
--
2.53.0
^ permalink raw reply related
* [PATCH 40/42] misc: fastrpc: Use devm_of_reserved_mem_device_init()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init() to ensure
the reserved memory region is released on device removal, fixing a
missing of_reserved_mem_device_release() in fastrpc_rpmsg_remove().
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/misc/fastrpc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/fastrpc.c b/drivers/misc/fastrpc.c
index d86e79134c68..c4e05b0db527 100644
--- a/drivers/misc/fastrpc.c
+++ b/drivers/misc/fastrpc.c
@@ -2396,7 +2396,7 @@ static int fastrpc_rpmsg_probe(struct rpmsg_device *rpdev)
return -EINVAL;
}
- if (of_reserved_mem_device_init_by_idx(rdev, rdev->of_node, 0))
+ if (devm_of_reserved_mem_device_init(rdev))
dev_info(rdev, "no reserved DMA memory for FASTRPC\n");
vmcount = of_property_read_variable_u32_array(rdev->of_node,
--
2.53.0
^ permalink raw reply related
* [PATCH 39/42] ASoC: SOF: mediatek: mt8195: Use devm_of_reserved_mem_device_init()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init() to ensure
the reserved memory region is released on device removal, fixing a
missing cleanup in the original code.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
sound/soc/sof/mediatek/mt8195/mt8195.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/mediatek/mt8195/mt8195.c b/sound/soc/sof/mediatek/mt8195/mt8195.c
index 4d6e9300a9c0..e4b6b6c18e02 100644
--- a/sound/soc/sof/mediatek/mt8195/mt8195.c
+++ b/sound/soc/sof/mediatek/mt8195/mt8195.c
@@ -49,7 +49,7 @@ static int platform_parse_resource(struct platform_device *pdev, void *data)
struct mtk_adsp_chip_info *adsp = data;
int ret;
- ret = of_reserved_mem_device_init(dev);
+ ret = devm_of_reserved_mem_device_init(dev);
if (ret) {
dev_err(dev, "of_reserved_mem_device_init failed\n");
return ret;
--
2.53.0
^ permalink raw reply related
* [PATCH 38/42] ASoC: SOF: mediatek: mt8186: Use devm_of_reserved_mem_device_init()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init() to ensure
the reserved memory region is released on device removal, fixing a
missing cleanup in the original code.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
sound/soc/sof/mediatek/mt8186/mt8186.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/sof/mediatek/mt8186/mt8186.c b/sound/soc/sof/mediatek/mt8186/mt8186.c
index c1bea967737d..a5ccee87e684 100644
--- a/sound/soc/sof/mediatek/mt8186/mt8186.c
+++ b/sound/soc/sof/mediatek/mt8186/mt8186.c
@@ -49,7 +49,7 @@ static int platform_parse_resource(struct platform_device *pdev, void *data)
struct mtk_adsp_chip_info *adsp = data;
int ret;
- ret = of_reserved_mem_device_init(dev);
+ ret = devm_of_reserved_mem_device_init(dev);
if (ret) {
dev_err(dev, "of_reserved_mem_device_init failed\n");
return ret;
--
2.53.0
^ permalink raw reply related
* [PATCH 37/42] ASoC: mediatek: mt8195: Use devm_of_reserved_mem_device_init()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init() to ensure
the reserved memory region is released on device removal, fixing a
missing cleanup in the original code.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
sound/soc/mediatek/mt8195/mt8195-afe-pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
index bc0a63457cd7..52c3381e6766 100644
--- a/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
+++ b/sound/soc/mediatek/mt8195/mt8195-afe-pcm.c
@@ -3013,7 +3013,7 @@ static int mt8195_afe_pcm_dev_probe(struct platform_device *pdev)
struct reset_control *rstc;
int i, irq_id, ret;
- ret = of_reserved_mem_device_init(dev);
+ ret = devm_of_reserved_mem_device_init(dev);
if (ret)
return dev_err_probe(dev, ret, "failed to assign memory region\n");
--
2.53.0
^ permalink raw reply related
* [PATCH 36/42] ASoC: mediatek: mt8188: Use devm_of_reserved_mem_device_init()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init() to ensure
the reserved memory region is released on device removal, fixing a
missing cleanup in the original code.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
sound/soc/mediatek/mt8188/mt8188-afe-pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c b/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c
index 7b1f5d05f4d6..ab4ce5e86b9d 100644
--- a/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c
+++ b/sound/soc/mediatek/mt8188/mt8188-afe-pcm.c
@@ -3199,7 +3199,7 @@ static int mt8188_afe_pcm_dev_probe(struct platform_device *pdev)
struct regmap *infra_ao;
int i, irq_id, ret;
- ret = of_reserved_mem_device_init(dev);
+ ret = devm_of_reserved_mem_device_init(dev);
if (ret)
dev_dbg(dev, "failed to assign memory region: %d\n", ret);
--
2.53.0
^ permalink raw reply related
* [PATCH 35/42] ASoC: mediatek: mt8186: Use devm_of_reserved_mem_device_init()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init() to ensure
the reserved memory region is released on device removal, fixing a
missing cleanup in the original code.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
sound/soc/mediatek/mt8186/mt8186-afe-pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt8186/mt8186-afe-pcm.c b/sound/soc/mediatek/mt8186/mt8186-afe-pcm.c
index 44a521c3a610..60576f885acd 100644
--- a/sound/soc/mediatek/mt8186/mt8186-afe-pcm.c
+++ b/sound/soc/mediatek/mt8186/mt8186-afe-pcm.c
@@ -2836,7 +2836,7 @@ static int mt8186_afe_pcm_dev_probe(struct platform_device *pdev)
afe_priv = afe->platform_priv;
afe->dev = &pdev->dev;
- ret = of_reserved_mem_device_init(dev);
+ ret = devm_of_reserved_mem_device_init(dev);
if (ret) {
dev_info(dev, "no reserved memory found, pre-allocating buffers instead\n");
afe->preallocate_buffers = true;
--
2.53.0
^ permalink raw reply related
* [PATCH 34/42] ASoC: mediatek: mt8173: Use devm_of_reserved_mem_device_init()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init() to ensure
the reserved memory region is released on device removal, fixing a
missing cleanup in the original code.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
sound/soc/mediatek/mt8173/mt8173-afe-pcm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
index 69cadc91c97f..0424d79bc9b0 100644
--- a/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
+++ b/sound/soc/mediatek/mt8173/mt8173-afe-pcm.c
@@ -1072,7 +1072,7 @@ static int mt8173_afe_pcm_dev_probe(struct platform_device *pdev)
afe->dev = dev;
- ret = of_reserved_mem_device_init(dev);
+ ret = devm_of_reserved_mem_device_init(dev);
if (ret) {
dev_info(dev, "no reserved memory found, pre-allocating buffers instead\n");
afe->preallocate_buffers = true;
--
2.53.0
^ permalink raw reply related
* [PATCH 33/42] drm: arcpgu: Use devm_of_reserved_mem_device_init()
From: Mukesh Ojha @ 2026-07-05 19:40 UTC (permalink / raw)
To: devicetree, dri-devel, imx, linux-arm-kernel, linux-arm-msm,
linux-aspeed, linux-kernel, linux-media, linux-mediatek,
linux-mmc, linux-remoteproc, linux-sound, linux-staging,
linux-sunxi, linux-tegra, linuxppc-dev, openbmc,
sound-open-firmware
Cc: Konrad Dybcio, Mukesh Ojha
In-Reply-To: <20260703193855.110619-1-mukesh.ojha@oss.qualcomm.com>
Use the devres-managed devm_of_reserved_mem_device_init() to ensure
the optional reserved memory region is released on device removal,
fixing a missing cleanup in the original code.
Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
---
drivers/gpu/drm/tiny/arcpgu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tiny/arcpgu.c b/drivers/gpu/drm/tiny/arcpgu.c
index c93d61ac0bb7..fa01407570a8 100644
--- a/drivers/gpu/drm/tiny/arcpgu.c
+++ b/drivers/gpu/drm/tiny/arcpgu.c
@@ -278,7 +278,7 @@ static int arcpgu_load(struct arcpgu_drm_private *arcpgu)
arc_pgu_read(arcpgu, ARCPGU_REG_ID));
/* Get the optional framebuffer memory resource */
- ret = of_reserved_mem_device_init(drm->dev);
+ ret = devm_of_reserved_mem_device_init(drm->dev);
if (ret && ret != -ENODEV)
return ret;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 0/8] Generic IRQ entry/exit support for powerpc
From: Andreas Schwab @ 2026-07-05 18:00 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Mukesh Kumar Chaurasiya (IBM), maddy, mpe, npiggin, ryabinin.a.a,
glider, andreyknvl, dvyukov, vincenzo.frascino, oleg, kees, luto,
wad, mchauras, sshegde, thuth, ruanjinjie, akpm, macro, ldv,
charlie, deller, kevin.brodsky, ritesh.list, yeoreum.yun,
agordeev, segher, mark.rutland, ryan.roberts, pmladek, feng.tang,
peterz, linuxppc-dev, linux-kernel, kasan-dev
In-Reply-To: <1693b268-ee26-4764-871a-5a067ae96080@kernel.org>
Most of the time it prints nothing, and when it prints something it is
mostly scrolled out.
.handle_softirqs+0xcc/0x264
.do_softirq_own_stack+0x30/0x38
.__irq_exit_rcu++0x7c/0x120
.timer_interrupt+90x1ß9/0x2c4
decrementer_common_virt+9x214/0x22ß
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH v5 0/8] Generic IRQ entry/exit support for powerpc
From: Andreas Schwab @ 2026-07-05 12:02 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Mukesh Kumar Chaurasiya (IBM), maddy, mpe, npiggin, ryabinin.a.a,
glider, andreyknvl, dvyukov, vincenzo.frascino, oleg, kees, luto,
wad, mchauras, sshegde, thuth, ruanjinjie, akpm, macro, ldv,
charlie, deller, kevin.brodsky, ritesh.list, yeoreum.yun,
agordeev, segher, mark.rutland, ryan.roberts, pmladek, feng.tang,
peterz, kan.liang, linuxppc-dev, linux-kernel, kasan-dev
In-Reply-To: <1693b268-ee26-4764-871a-5a067ae96080@kernel.org>
BUG: Unable to handle kernel data access at 0x30af548c0000028
Faulting instruction address: 0xc0000000000af47c
c0000000000aee6c <.sched_balance_find_src_group>:
c0000000000af474: e9 3f 00 18 ld r9,24(r31)
c0000000000af478: e9 29 0d 48 ld r9,3400(r9)
c0000000000af47c: 89 49 00 28 lbz r10,40(r9)
c0000000000af480: 7c 0a e0 40 cmplw r10,r28
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ 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