* Re: Stop false review statements
From: Greg KH @ 2026-05-18 5:31 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Roman Gushchin, Krzysztof Kozlowski, debarbos,
Arnaldo Carvalho de Melo, Konstantin Ryabitsev, Guenter Roeck,
sashiko-bot, sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree, kfree
In-Reply-To: <20260517205606.3b035316@foz.lan>
On Sun, May 17, 2026 at 08:56:06PM +0200, Mauro Carvalho Chehab wrote:
> By "reproduce locally", I didn't mean in strict sense. Sure, LLM answers
> won't be identical, but I suspect that at least most of the major issues
> on a patch series would be reported by any decent model.
>
> So, if we have something that one can locally run using its GPU, being
> able to get an answer in the range of a couple of minutes per patch
> should be enough to catch most of the issues.
That should be possible now, you can submit a patch locally to the
system. I have a "cheat-sheet" around here somewhere that explains how
to do that, no idea why it's not part of the documentation. I can dig
it up after breakfast...
greg k-h
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Uwe Kleine-König @ 2026-05-18 6:55 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-doc, devicetree, workflows, linux-arch, dmaengine,
linux-i2c, linux-iio, netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky, Jonathan Corbet,
Shuah Khan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Lezcano, Thomas Gleixner, Alex Shi, Yanteng Si,
Dongliang Mu, Hu Haowen, Dinh Nguyen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V, Andrew Morton, Nick Piggin,
Peter Zijlstra, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof Wilczyński
In-Reply-To: <20260518042833.272221-1-enelsonmoore@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
Hello,
On Sun, May 17, 2026 at 09:28:33PM -0700, Ethan Nelson-Moore wrote:
> diff --git a/drivers/pwm/Kconfig b/drivers/pwm/Kconfig
> index 6f3147518376..d8145f369ec3 100644
> --- a/drivers/pwm/Kconfig
> +++ b/drivers/pwm/Kconfig
> @@ -131,7 +131,7 @@ config PWM_ATMEL_TCB
>
> config PWM_AXI_PWMGEN
> tristate "Analog Devices AXI PWM generator"
> - depends on MICROBLAZE || NIOS2 || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_INTEL_SOCFPGA || COMPILE_TEST
> + depends on MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_INTEL_SOCFPGA || COMPILE_TEST
> select REGMAP_MMIO
> help
> This enables support for the Analog Devices AXI PWM generator.
> diff --git a/include/linux/seqlock.h b/include/linux/seqlock.h
> index 5a40252b8334..edc8c96d91b6 100644
Acked-by: Uwe Kleine-König <ukleinek@kernel.org> # for pwm
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] Doc: deprecated.rst: add strlcat()
From: Geert Uytterhoeven @ 2026-05-18 7:11 UTC (permalink / raw)
To: David Laight
Cc: Heiko Carstens, Kees Cook, Manuel Ebner, Andy Shevchenko,
Jonathan Corbet, Shuah Khan, Andy Whitcroft, Joe Perches,
Dwaipayan Ray, Lukas Bulwahn, Randy Dunlap, Jani Nikula,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
In-Reply-To: <20260516173524.498984d0@pumpkin>
Hi David,
On Sat, 16 May 2026 at 18:35, David Laight <david.laight.linux@gmail.com> wrote:
> On Sat, 16 May 2026 17:28:19 +0200
> Heiko Carstens <hca@linux.ibm.com> wrote:
>
> > On Thu, May 14, 2026 at 09:31:46AM -0700, Kees Cook wrote:
> > > On Thu, May 14, 2026 at 06:26:53PM +0200, Manuel Ebner wrote:
> > > > add strlcat and alternatives
> > > >
> > > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > > > ---
> > > > Documentation/process/deprecated.rst | 7 +++++++
> > > > 1 file changed, 7 insertions(+)
> > > >
> > > > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> > > > index fed56864d036..06e802f4bbfd 100644
> > > > --- a/Documentation/process/deprecated.rst
> > > > +++ b/Documentation/process/deprecated.rst
> > > > @@ -153,6 +153,13 @@ used, and the destinations should be marked with the `__nonstring
> > > > attribute to avoid future compiler warnings. For cases still needing
> > > > NUL-padding, strtomem_pad() can be used.
> > > >
> > > > +strlcat()
> > > > +---------
> > > > +strlcat() must re-scan the destination string from the beginning on each
> > > > +call (O(n^2) behavior). Alternatives are seq_buf_puts() and seq_buf_printf().
> > > > +snprintf(), scnprintf() and sysfs_emit() are possible aswell, but the adoption
> > > > +of the arguments needs to be taken care off.
> > > > +
> > >
> > > How about just:
> > >
> > > strlcat() must re-scan the destination string from the beginning on each
> > > call (O(n^2) behavior). Use the seq_buf API or similar instead.
> >
> > seq_buf API for appending something to e.g. boot_command_line seems to be odd,
> > since boot_command_line is usually "just there" (depending on architecture and
> > boot loader).
>
> Indeed, but ISTR that code uses strcat() a lot of the time.
> The lengths are all known, so memcpy() can be used.
>
> I don't really see why strlcat() should be deprecated.
> Clearly there are many cases where there are better ways to do things.
https://elixir.bootlin.com/linux/v7.0.8/source/include/linux/fortify-string.h#L346
already says "Do not use this function. [...] Prefer building the
* string with formatting, via scnprintf(), seq_buf, or similar.".
> The only problem with strlcat() is that it returns the 'required length'.
> So there are some broken uses.
> - fs/nfs/flexfilelayout/flexfilelayout.c
> - lib/kunit/string-stream.c (although the preceding vsnprintf() looks like the actual bug).
> There is also some very strange code in security/selinus/ima.c - but it may be ok.
>
> In reality the return value of strlcat() isn't really much worse that that
> of snprintf().
So we need strscat()? ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: Stop false review statements
From: Jani Nikula @ 2026-05-18 8:04 UTC (permalink / raw)
To: Roman Gushchin, Krzysztof Kozlowski
Cc: debarbos, Arnaldo Carvalho de Melo, Greg KH, Konstantin Ryabitsev,
Guenter Roeck, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <07602616-412B-4ED8-95D7-588C0D077EE3@linux.dev>
On Sat, 16 May 2026, Roman Gushchin <roman.gushchin@linux.dev> wrote:
>> On May 16, 2026, at 2:33 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>
>> I find it opposite: clogging commits with useless information, because
>> some arbitrary and completely closed-source tool did analysis means
>> nothing to me one year later when I look at the commit in the Git history.
>
> This is simple not true: Sashiko is fully open-source, under Apache 2.0 license
> and the code belongs to LF. Yes, the instance behind sashiko.dev is using
> Gemini 3.1 Pro LLM, which is not open-source, but it’s not a fundamental limitation -
> Sashiko is supporting various LLMs, including open models - it’s just a practical
> choice: to my knowledge the quality of open models is not on par with frontier closed
> models and it would require a non-trivial amount of hardware and infrastructure to run
> an open model at the required scale.
In the context of the "Reviewed-by: Sashiko" discussion, this actually
makes it really hard to assess the quality of those reviews. It is
*currently* using a boatload of tokens with a specific LLM, and I find
it's often asking pretty good questions.
People build their reviewer track record and gain trust over time, but
the reviews from what is portrayed as "Sashiko" heavily depend on the
models and resources spent in the background. As a maintainer, it's far
easier (though still laborous) to deal with the negative feedback from
LLMs than the positive, because you won't really know how rigorous the
review was when the response is just "LGTM".
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply
* Re: Stop false review statements
From: Krzysztof Kozlowski @ 2026-05-18 8:12 UTC (permalink / raw)
To: Jani Nikula, Roman Gushchin
Cc: debarbos, Arnaldo Carvalho de Melo, Greg KH, Konstantin Ryabitsev,
Guenter Roeck, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <2e20badf27b6910d619329841e37d2961556056f@intel.com>
On 18/05/2026 10:04, Jani Nikula wrote:
> On Sat, 16 May 2026, Roman Gushchin <roman.gushchin@linux.dev> wrote:
>>> On May 16, 2026, at 2:33 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>>>
>>> I find it opposite: clogging commits with useless information, because
>>> some arbitrary and completely closed-source tool did analysis means
>>> nothing to me one year later when I look at the commit in the Git history.
>>
>> This is simple not true: Sashiko is fully open-source, under Apache 2.0 license
>> and the code belongs to LF. Yes, the instance behind sashiko.dev is using
>> Gemini 3.1 Pro LLM, which is not open-source, but it’s not a fundamental limitation -
>> Sashiko is supporting various LLMs, including open models - it’s just a practical
>> choice: to my knowledge the quality of open models is not on par with frontier closed
>> models and it would require a non-trivial amount of hardware and infrastructure to run
>> an open model at the required scale.
>
> In the context of the "Reviewed-by: Sashiko" discussion, this actually
> makes it really hard to assess the quality of those reviews. It is
> *currently* using a boatload of tokens with a specific LLM, and I find
> it's often asking pretty good questions.
>
> People build their reviewer track record and gain trust over time, but
> the reviews from what is portrayed as "Sashiko" heavily depend on the
> models and resources spent in the background. As a maintainer, it's far
> easier (though still laborous) to deal with the negative feedback from
> LLMs than the positive, because you won't really know how rigorous the
> review was when the response is just "LGTM".
And this already happened with reviewed-by statement given to one-liner
patch which still was not good enough for the maintainer:
https://lore.kernel.org/all/ce11a8ba-8ebc-4c09-b6d0-7e98febeae6b@roeck-us.net/
Obviously same applies to humans - they also give Rb which misses some
aspects - but I hope a person would not review such one-liner. Sashiko
did and as well can provide such "review tags" for every little patch,
which is not helping us really.
Best regards,
Krzysztof
^ permalink raw reply
* Re: Stop false review statements
From: Jani Nikula @ 2026-05-18 8:22 UTC (permalink / raw)
To: Jonathan Corbet, Guenter Roeck, Krzysztof Kozlowski
Cc: sashiko-bot, sashiko-reviews, sashiko, Linux Kernel Workflows,
Linux Kernel Mailing List, devicetree@vger.kernel.org, kfree,
Dave Airlie, Simona Vetter
In-Reply-To: <877bp2m586.fsf@trenco.lwn.net>
On Sun, 17 May 2026, Jonathan Corbet <corbet@lwn.net> wrote:
> That said, I was certainly considering *human* reviewers at the time,
> and all of the people who agreed with the suggested policy were too.
> Adding bots seems like a stretch to me.
>
> I can't speak for subsystems that require Reviewed-by tags on their
> commits, but I'm not sure that their maintainers would accept an
> automated review as satisfying that requirement.
For the parts of the drm subsystem that have a committer/maintainer
model, one of the requirements for pushing is that at least two people
have been involved. Reviewed-by is one of the ways to record this is
indeed the case.
I can't speak for the entire subsystem either, but to me it was always
about people, trust, and the community.
We may add ways to record that an LLM has reviewed a patch, but I think
the fundamental requirement that two human beings have been involved is
going to remain.
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH] docs: submitting-patches: Clarify that in English "reviewer" is a person
From: David Hildenbrand (Arm) @ 2026-05-18 8:31 UTC (permalink / raw)
To: Vlastimil Babka (SUSE), Krzysztof Kozlowski, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
Cc: Greg Kroah-Hartman, Andrew Morton, Linus Torvalds, Guenter Roeck
In-Reply-To: <ce1e5e9b-83d0-4971-aee3-dc5a8f85ce22@kernel.org>
On 5/16/26 16:39, Vlastimil Babka (SUSE) wrote:
> On 5/16/26 14:38, Krzysztof Kozlowski wrote:
>> Common understanding of word "Reviewer" is: a person performing a review
>> work [1]. Tools are not persons, thus cannot be reviewers in this term.
>> Also tools cannot make statements ("A Reviewed-by tag is a statement of
>> opinion"), since making a statement needs some sort of conscious mind.
>>
>> Our docs already clearly mark that "Reviewed-by" must come from a
>> person:
>>
>> - "By offering my Reviewed-by: tag, I state that:"
>>
>> Usage of first person "I" and word "state"
>>
>> - "A Reviewed-by tag is *a statement of opinion* that the patch is an
>> appropriate modification of the kernel without any remaining serious"
>>
>> Only a person can make a statement of opinion.
>>
>> - "Any interested reviewer (who has done the work) can offer a
>> Reviewed-by"
>>
>> A person can offer a tag thus above does not grant the tool
>> permission to offer a tag.
>>
>> However this is not enough and apparently English is not that precise,
>> so let's clarify that only a person can state the "Reviewer's statement
>> of oversight".
>>
>> Link: https://en.wiktionary.org/wiki/reviewer [1]
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Vlastimil Babka <vbabka@kernel.org>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: David Hildenbrand <david@kernel.org>
>> Cc: Linus Torvalds <torvalds@linux-foundation.org>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> I agree with the intent that the tag is for people (whether they use a tool
> or not to help them). We also don't put "Tested-by: kernel test robot" or
> syzkaller on every commit that they test and find no bugs. Review is also
> not just about absence of bugs, but agreeing with the larger design and
> whether the change makes sense to do in the first place.
I'd assume that SOB/RB/ACK would all be real persons, not tools.
For SOB we term it as "known identity". I'd assume that a tool is not an
identity ...
So maybe we should also talk about "know identity" here?
In any case, bots providing RB tags is stupid
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
--
Cheers,
David
^ permalink raw reply
* Re: [PATCH] docs: submitting-patches: Clarify that in English "reviewer" is a person
From: Mark Brown @ 2026-05-18 8:33 UTC (permalink / raw)
To: Vlastimil Babka (SUSE)
Cc: Krzysztof Kozlowski, Jonathan Corbet, Shuah Khan, workflows,
linux-doc, linux-kernel, Greg Kroah-Hartman, Andrew Morton,
David Hildenbrand, Linus Torvalds, Guenter Roeck
In-Reply-To: <ce1e5e9b-83d0-4971-aee3-dc5a8f85ce22@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 788 bytes --]
On Sat, May 16, 2026 at 04:39:45PM +0200, Vlastimil Babka (SUSE) wrote:
> On 5/16/26 14:38, Krzysztof Kozlowski wrote:
> > Our docs already clearly mark that "Reviewed-by" must come from a
> > person:
...
> > However this is not enough and apparently English is not that precise,
> > so let's clarify that only a person can state the "Reviewer's statement
> > of oversight".
> I agree with the intent that the tag is for people (whether they use a tool
> or not to help them). We also don't put "Tested-by: kernel test robot" or
> syzkaller on every commit that they test and find no bugs. Review is also
> not just about absence of bugs, but agreeing with the larger design and
> whether the change makes sense to do in the first place.
Reviewed-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH] docs: dt: maintainer: Add Devicetree and OF maintainer profile document
From: Krzysztof Kozlowski @ 2026-05-18 9:19 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski, Rob Herring, Conor Dooley, Saravana Kannan,
devicetree
Document how Devicetree and Open Firmware maintainers handle their
subsystem, especially focusing on two caveats:
Devicetree subsystem handles patches with a minor difference comparing
to other subsystems: while DT maintainers pick up OF code, they only
provide review of DT bindings without applying these.
All three DT bindings maintainers rely currently on Patchwork and due to
enormous amount of emails per day, regardless how much DT maintainers
try, they cannot read all the emails.
Cc: Rob Herring <robh@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Saravana Kannan <saravanak@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I expect patch to be picked up by Rob, after review.
---
.../process/maintainer-devicetree.rst | 70 +++++++++++++++++++
MAINTAINERS | 2 +
2 files changed, 72 insertions(+)
create mode 100644 Documentation/process/maintainer-devicetree.rst
diff --git a/Documentation/process/maintainer-devicetree.rst b/Documentation/process/maintainer-devicetree.rst
new file mode 100644
index 000000000000..331701bb2282
--- /dev/null
+++ b/Documentation/process/maintainer-devicetree.rst
@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+Devicetree and Open Firmware Subsystem
+======================================
+
+Other Process Documents
+-----------------------
+
+Please see the documents in Documentation/devicetree/bindings/ for information
+on how to write proper Devicetree bindings and how to submit patches.
+
+Patch Review and Handling
+-------------------------
+
+Patches handled by Devicetree maintainers are processed differently depending
+on the patch type:
+
+1. Core OF driver code, e.g. drivers/of/:
+ patches are reviewed and applied by DT maintainers.
+
+2. Devicetree bindings:
+ patches are reviewed by DT maintainers but, except in certain cases, should
+ be applied by subsystem maintainers. See also *For kernel maintainers* in
+ Documentation/devicetree/bindings/submitting-patches.rst.
+
+3. DTS and drivers:
+ DT maintainers might provide comments, but review is generally not expected.
+
+Pachwork
+~~~~~~~~
+
+Devicetree maintainers review patches using Patchwork, so the current status of
+a patch can be checked there. For typical driver submissions, Patchwork
+receives the entire patch set, but only a few patches are usually Devicetree
+bindings that are reviewed by DT maintainers.
+
+Explanation of Patchwork statutes:
+
+ - **New**: Not yet processed by the automation toolset.
+ - **Needs ACK**: Waiting for review by DT maintainers.
+ - **Handled Elsewhere**: Non-DT patch; not being reviewed here.
+ - **RFC**: Patch was likely ignored because it was an incomplete RFC.
+ - **Changes Requested**: Patch was reviewed and DT maintainers expect changes.
+ - **Accepted**: Patch was reviewed and applied by DT maintainers to their tree.
+ - **Not Applicable**: Patch was reviewed and is likely in good shape, with a
+ *Reviewed-by* or *Acked-by* tag provided, but DT maintainers expect someone
+ else to apply it.
+
+Patch Re-review and Pinging
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Due to the high volume of email traffic, Devicetree maintainers do not read
+every email they receive and instead rely on Patchwork during the review
+process. They also often skip patches that have already been reviewed.
+
+As a result, maintainers might miss:
+
+1. Questions about already reviewed patches.
+2. Pings, for example when a patch has been reviewed by DT maintainers but has
+ not been picked up by subsystem maintainers.
+
+Such cases can be addressed by:
+
+1. Pinging DT maintainers on the IRC channel.
+2. Dropping the DT maintainer’s *Acked-by* or *Reviewed-by* tag when sending a new
+ version of the patch set, together with an explanation in the patch
+ changelog describing why the tag was removed and what is expected from DT
+ maintainers.
+
diff --git a/MAINTAINERS b/MAINTAINERS
index f877e5aaf2c7..c4929de50ab7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20050,6 +20050,7 @@ S: Maintained
Q: http://patchwork.kernel.org/project/devicetree/list/
W: http://www.devicetree.org/
C: irc://irc.libera.chat/devicetree
+P: Documentation/process/maintainer-devicetree.rst
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
F: Documentation/ABI/testing/sysfs-firmware-ofw
F: drivers/of/
@@ -20070,6 +20071,7 @@ M: Conor Dooley <conor+dt@kernel.org>
L: devicetree@vger.kernel.org
S: Maintained
Q: http://patchwork.kernel.org/project/devicetree/list/
+P: Documentation/process/maintainer-devicetree.rst
C: irc://irc.libera.chat/devicetree
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
F: Documentation/devicetree/
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] nios2: remove the architecture
From: Arnd Bergmann @ 2026-05-18 9:29 UTC (permalink / raw)
To: Ethan Nelson-Moore, linux-doc, devicetree, workflows, Linux-Arch,
dmaengine, linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org
Cc: Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Dinh Nguyen, Kees Cook,
Oleg Nesterov, Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Peter Zijlstra, Vinod Koul, Frank Li,
Dave Penkler, Andi Shyti, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Andrew Lunn, David S . Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Lorenzo Pieralisi,
Krzysztof Wilczyński, Simon Schuster, Andreas Oetken
In-Reply-To: <20260518042833.272221-1-enelsonmoore@gmail.com>
On Mon, May 18, 2026, at 06:28, Ethan Nelson-Moore wrote:
> The Nios II architecture is a soft-core architecture developed by
> Altera (since acquired by Intel) and intended to run on their FPGAs.
>
> Licenses for the architecture have not been available for purchase
> since 2024 [1], and support for it has been removed from GCC 15 [2],
> Buildroot [3], and QEMU [4].
>
> Given all of these factors, it is time to remove Nios II support from
> the kernel. The maintainer stated in 2024 that they were planning to do
> so soon [5], but this did not come to pass.
>
> Remove Nios II support from the kernel and move the former maintainer
> to CREDITS. Thank you, Dinh Nguyen, for maintaining Nios II support!
Hi Ethan,
We last discussed this a year ago when Simon Schuster mentioned[1]
that Siemens Energy is still using NIOS-2 in production and would
prefer to have this still included in Linux for at least another
few years until the obligation for kernel updates ends.
My feeling is that the maintenance burden of keeping nios2 is
relatively low. On the other hand, maintaining it out of tree
as a patch set is also something that should not be all that
hard if it does get removed.
Simon mentioned that he expected others to also use nios2 with
new kernels, but I have not heard from anyone else actually
doing it.
I've added Simon and Andreas to Cc here to let them comment
more here.
Arnd
[1] https://sourceware.org/pipermail/binutils/2025-March/140140.html
^ permalink raw reply
* [PATCH v2] docs: dt: maintainer: Add Devicetree and OF maintainer profile document
From: Krzysztof Kozlowski @ 2026-05-18 10:12 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski, Rob Herring, Conor Dooley, Saravana Kannan,
devicetree
Document how Devicetree and Open Firmware maintainers handle their
subsystem, especially focusing on two caveats:
Devicetree subsystem handles patches with a minor difference comparing
to other subsystems: while DT maintainers pick up OF code, they only
provide review of DT bindings without applying these.
All three DT bindings maintainers rely currently on Patchwork and due to
enormous amount of emails per day, regardless how much DT maintainers
try, they cannot read all the emails.
Cc: Rob Herring <robh@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Saravana Kannan <saravanak@kernel.org>
Cc: devicetree@vger.kernel.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
I expect patch to be picked up by Rob, after review.
Changes in v2:
1. Correct typos and trailing white spaces.
2. Fix order of P: after C: in maintainers.
---
.../process/maintainer-devicetree.rst | 70 +++++++++++++++++++
MAINTAINERS | 2 +
2 files changed, 72 insertions(+)
create mode 100644 Documentation/process/maintainer-devicetree.rst
diff --git a/Documentation/process/maintainer-devicetree.rst b/Documentation/process/maintainer-devicetree.rst
new file mode 100644
index 000000000000..d8ffe752bf5d
--- /dev/null
+++ b/Documentation/process/maintainer-devicetree.rst
@@ -0,0 +1,70 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+Devicetree and Open Firmware Subsystem
+======================================
+
+Other Process Documents
+-----------------------
+
+Please see the documents in Documentation/devicetree/bindings/ for information
+on how to write proper Devicetree bindings and how to submit patches.
+
+Patch Review and Handling
+-------------------------
+
+Patches handled by Devicetree maintainers are processed differently depending
+on the patch type:
+
+1. Core OF driver code, e.g. drivers/of/:
+ patches are reviewed and applied by DT maintainers.
+
+2. Devicetree bindings:
+ patches are reviewed by DT maintainers but, except in certain cases, should
+ be applied by subsystem maintainers. See also *For kernel maintainers* in
+ Documentation/devicetree/bindings/submitting-patches.rst.
+
+3. DTS and drivers:
+ DT maintainers might provide comments, but review is generally not expected.
+
+Patchwork
+~~~~~~~~~
+
+Devicetree maintainers review patches using Patchwork, so the current status of
+a patch can be checked there. For typical driver submissions, Patchwork
+receives the entire patch set, but only a few patches are usually Devicetree
+bindings that are reviewed by DT maintainers.
+
+Explanation of Patchwork statuses:
+
+ - **New**: Not yet processed by the automation toolset.
+ - **Needs ACK**: Waiting for review by DT maintainers.
+ - **Handled Elsewhere**: Non-DT patch; not being reviewed here.
+ - **RFC**: Patch was likely ignored because it was an incomplete RFC.
+ - **Changes Requested**: Patch was reviewed and DT maintainers expect changes.
+ - **Accepted**: Patch was reviewed and applied by DT maintainers to their tree.
+ - **Not Applicable**: Patch was reviewed and is likely in good shape, with a
+ *Reviewed-by* or *Acked-by* tag provided, but DT maintainers expect someone
+ else to apply it.
+
+Patch Re-review and Pinging
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Due to the high volume of email traffic, Devicetree maintainers do not read
+every email they receive and instead rely on Patchwork during the review
+process. They also often skip patches that have already been reviewed.
+
+As a result, maintainers might miss:
+
+1. Questions about already reviewed patches.
+2. Pings, for example when a patch has been reviewed by DT maintainers but has
+ not been picked up by subsystem maintainers.
+
+Such cases can be addressed by:
+
+1. Pinging DT maintainers on the IRC channel.
+2. Dropping the DT maintainer’s *Acked-by* or *Reviewed-by* tag when sending a new
+ version of the patch set, together with an explanation in the patch
+ changelog describing why the tag was removed and what is expected from DT
+ maintainers.
+
diff --git a/MAINTAINERS b/MAINTAINERS
index f877e5aaf2c7..843f1d124446 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -20050,6 +20050,7 @@ S: Maintained
Q: http://patchwork.kernel.org/project/devicetree/list/
W: http://www.devicetree.org/
C: irc://irc.libera.chat/devicetree
+P: Documentation/process/maintainer-devicetree.rst
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
F: Documentation/ABI/testing/sysfs-firmware-ofw
F: drivers/of/
@@ -20071,6 +20072,7 @@ L: devicetree@vger.kernel.org
S: Maintained
Q: http://patchwork.kernel.org/project/devicetree/list/
C: irc://irc.libera.chat/devicetree
+P: Documentation/process/maintainer-devicetree.rst
T: git git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git
F: Documentation/devicetree/
F: arch/*/boot/dts/
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] docs: submitting-patches: Clarify that in English "reviewer" is a person
From: Krzysztof Kozlowski @ 2026-05-18 10:16 UTC (permalink / raw)
To: David Hildenbrand (Arm), Vlastimil Babka (SUSE), Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
Cc: Greg Kroah-Hartman, Andrew Morton, Linus Torvalds, Guenter Roeck,
Mark Brown
In-Reply-To: <1d350564-0127-48c1-8988-54245fdb9b23@kernel.org>
On 18/05/2026 10:31, David Hildenbrand (Arm) wrote:
> On 5/16/26 16:39, Vlastimil Babka (SUSE) wrote:
>> On 5/16/26 14:38, Krzysztof Kozlowski wrote:
>>> Common understanding of word "Reviewer" is: a person performing a review
>>> work [1]. Tools are not persons, thus cannot be reviewers in this term.
>>> Also tools cannot make statements ("A Reviewed-by tag is a statement of
>>> opinion"), since making a statement needs some sort of conscious mind.
>>>
>>> Our docs already clearly mark that "Reviewed-by" must come from a
>>> person:
>>>
>>> - "By offering my Reviewed-by: tag, I state that:"
>>>
>>> Usage of first person "I" and word "state"
>>>
>>> - "A Reviewed-by tag is *a statement of opinion* that the patch is an
>>> appropriate modification of the kernel without any remaining serious"
>>>
>>> Only a person can make a statement of opinion.
>>>
>>> - "Any interested reviewer (who has done the work) can offer a
>>> Reviewed-by"
>>>
>>> A person can offer a tag thus above does not grant the tool
>>> permission to offer a tag.
>>>
>>> However this is not enough and apparently English is not that precise,
>>> so let's clarify that only a person can state the "Reviewer's statement
>>> of oversight".
>>>
>>> Link: https://en.wiktionary.org/wiki/reviewer [1]
>>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>> Cc: Vlastimil Babka <vbabka@kernel.org>
>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>> Cc: David Hildenbrand <david@kernel.org>
>>> Cc: Linus Torvalds <torvalds@linux-foundation.org>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>
>> I agree with the intent that the tag is for people (whether they use a tool
>> or not to help them). We also don't put "Tested-by: kernel test robot" or
>> syzkaller on every commit that they test and find no bugs. Review is also
>> not just about absence of bugs, but agreeing with the larger design and
>> whether the change makes sense to do in the first place.
>
> I'd assume that SOB/RB/ACK would all be real persons, not tools.
>
> For SOB we term it as "known identity". I'd assume that a tool is not an
> identity ...
>
> So maybe we should also talk about "know identity" here?
I think this - s/person/known identity/ - is a good idea. We should not
have aliases and anonymous reviews because these are not accountable.
I got few acks already and I plan to retain them in v2, so please let me
know if you disagree with keeping Ack/Reviewed-by while replacing this
to known identity.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] MAINTAINERS: tip: Include maintainer profile
From: Krzysztof Kozlowski @ 2026-05-18 10:40 UTC (permalink / raw)
To: Thomas Gleixner, Ingo Molnar, Peter Zijlstra, Darren Hart,
Davidlohr Bueso, André Almeida, Jonathan Corbet, Shuah Khan,
linux-kernel, workflows, linux-doc
Cc: Krzysztof Kozlowski
No dedicated TIP maintainers are returned by get_maintainers.pl for the
subsystem maintainer profile, thus patches changing that file miss
the actual owners of the file.
This maintainer profile appears in a few entries, but place it one
matching the most of TIP names.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 843f1d124446..a6553271e19a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10658,6 +10658,7 @@ S: Maintained
P: Documentation/process/maintainer-tip.rst
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core
F: Documentation/locking/*futex*
+F: Documentation/process/maintainer-tip.rst
F: include/asm-generic/futex.h
F: include/linux/futex.h
F: include/uapi/linux/futex.h
--
2.51.0
^ permalink raw reply related
* [PATCH] MAINTAINERS: KVM: Include maintainer profile
From: Krzysztof Kozlowski @ 2026-05-18 10:41 UTC (permalink / raw)
To: Sean Christopherson, Paolo Bonzini, Jonathan Corbet, Shuah Khan,
kvm, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski
No dedicated KVM maintainers are returned by get_maintainers.pl for the
subsystem maintainer profile, thus patches changing that file miss
the actual owners of the file.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index a6553271e19a..7a65b220d93f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14205,6 +14205,7 @@ L: kvm@vger.kernel.org
S: Supported
P: Documentation/process/maintainer-kvm-x86.rst
T: git git://git.kernel.org/pub/scm/virt/kvm/kvm.git
+F: Documentation/process/maintainer-kvm-x86.rst
F: arch/x86/include/asm/kvm*
F: arch/x86/include/asm/svm.h
F: arch/x86/include/asm/vmx*.h
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] nios2: remove the architecture
From: Peter Zijlstra @ 2026-05-18 10:57 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Ethan Nelson-Moore, linux-doc, devicetree, workflows, Linux-Arch,
dmaengine, linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org,
Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Dinh Nguyen, Kees Cook,
Oleg Nesterov, Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof Wilczyński,
Simon Schuster, Andreas Oetken
In-Reply-To: <d40b1e80-37fc-4c88-9d7f-dae6458efe6c@app.fastmail.com>
On Mon, May 18, 2026 at 11:29:48AM +0200, Arnd Bergmann wrote:
> On Mon, May 18, 2026, at 06:28, Ethan Nelson-Moore wrote:
> > The Nios II architecture is a soft-core architecture developed by
> > Altera (since acquired by Intel) and intended to run on their FPGAs.
> >
> > Licenses for the architecture have not been available for purchase
> > since 2024 [1], and support for it has been removed from GCC 15 [2],
> > Buildroot [3], and QEMU [4].
> >
> > Given all of these factors, it is time to remove Nios II support from
> > the kernel. The maintainer stated in 2024 that they were planning to do
> > so soon [5], but this did not come to pass.
> >
> > Remove Nios II support from the kernel and move the former maintainer
> > to CREDITS. Thank you, Dinh Nguyen, for maintaining Nios II support!
>
> Hi Ethan,
>
> We last discussed this a year ago when Simon Schuster mentioned[1]
> that Siemens Energy is still using NIOS-2 in production and would
> prefer to have this still included in Linux for at least another
> few years until the obligation for kernel updates ends.
Isn't that what we have LTS branches for?
^ permalink raw reply
* Re: Stop false review statements
From: Theodore Tso @ 2026-05-18 12:16 UTC (permalink / raw)
To: Jani Nikula
Cc: Roman Gushchin, Krzysztof Kozlowski, debarbos,
Arnaldo Carvalho de Melo, Greg KH, Konstantin Ryabitsev,
Guenter Roeck, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <2e20badf27b6910d619329841e37d2961556056f@intel.com>
On Mon, May 18, 2026 at 11:04:29AM +0300, Jani Nikula wrote:
> > Sashiko is supporting various LLMs, including open models - it’s just a practical
> > choice: to my knowledge the quality of open models is not on par with frontier closed
> > models and it would require a non-trivial amount of hardware and infrastructure to run
> > an open model at the required scale.
>
> In the context of the "Reviewed-by: Sashiko" discussion, this actually
> makes it really hard to assess the quality of those reviews.
Agreed. There's a reason why the coding-assistants.rst specifies the
model which is used:
Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
The problem is that (as Jon has pointed out) coding-assistants.rst was
intended for use when the tool was beging used to help create the code
--- that is, "Coding Assistants". What we're doing here is more of a
reviewer assistance. Something like:
Scanned-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
Would be more interesting, but it doesn't actually tell us anything
about what the results were of the scan.
One of the problems here is that there is a distinction between the
infrastructure and review prompts in the Sashiko github repository,
and the reviews that are being published by Sashiko the web service
being run by Google that is being lost by some folks. So I wonder if
for now, we should just do something like:
Link: https://sashiko.dev/#/patchset/20260515091829.194810-1-me%40linux.beauty
Or just have a link to lore where the review has responded to the
Sashiko review stating where the Sashiko review reported a
pre-existing condition (perhaps one that we don't care about because
races in readahead logic is really Not A Big Deal, etc.) We go for
this strategy, it would actually be better for the Shashiko.dev review
to get cc'ed to the mailing list.
Personally, I think that's probably be best way to go. We already
don't insert into the git commit an explanation of why some bullsh*t
review by some wannabe human reviewer should be ignored, or why a
discussion of some problem discovered by a human review in the source
of the review would be handled in a future patch set. That's what the
discussion on lore.kernel.org is for. And we shouldn't treat AI
reviews any different from how we deal with human reviews. So if we
want to give credit to an AI review, then let's go with the
Scanned-by. Or we can just let people look at the mailing list, and
if people want to have statistics, we can ask people to use a script
running against public inbox to figure things out.
- Ted
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Krzysztof Kozlowski @ 2026-05-18 12:50 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-doc, devicetree, workflows, linux-arch, dmaengine,
linux-i2c, linux-iio, netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky, Jonathan Corbet,
Shuah Khan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Lezcano, Thomas Gleixner, Alex Shi, Yanteng Si,
Dongliang Mu, Hu Haowen, Dinh Nguyen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V, Andrew Morton, Nick Piggin,
Peter Zijlstra, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof Wilczyński
In-Reply-To: <20260518042833.272221-1-enelsonmoore@gmail.com>
On Sun, May 17, 2026 at 09:28:33PM -0700, Ethan Nelson-Moore wrote:
> The Nios II architecture is a soft-core architecture developed by
> Altera (since acquired by Intel) and intended to run on their FPGAs.
>
> Licenses for the architecture have not been available for purchase
> since 2024 [1], and support for it has been removed from GCC 15 [2],
> Buildroot [3], and QEMU [4].
>
> Given all of these factors, it is time to remove Nios II support from
> the kernel. The maintainer stated in 2024 that they were planning to do
> so soon [5], but this did not come to pass.
>
> Remove Nios II support from the kernel and move the former maintainer
> to CREDITS. Thank you, Dinh Nguyen, for maintaining Nios II support!
>
> References:
> [1] https://docs.altera.com/v/u/docs/781327/is-discontinuing-ip-ordering-codes-listed-in-pdn2312-for-nios-ii-ip
> [2] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e876acab6cdd84bb2b32c98fc69fb0ba29c81153
> [3] https://github.com/buildroot/buildroot/commit/6775ccc5a199d574ad70b5f79ec58cce97a07c6f
> [4] https://github.com/qemu/qemu/commit/6c3014858c4c0024dd0560f08a6eda0f92f658d6
> [5] https://sourceware.org/pipermail/newlib/2024/021083.html
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
Wearing DT hat:
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: Stop false review statements
From: Geert Uytterhoeven @ 2026-05-18 12:54 UTC (permalink / raw)
To: Theodore Tso
Cc: Jani Nikula, Roman Gushchin, Krzysztof Kozlowski, debarbos,
Arnaldo Carvalho de Melo, Greg KH, Konstantin Ryabitsev,
Guenter Roeck, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <20260518121601.GA87957@macsyma-wired.lan>
Hi Ted,
On Mon, 18 May 2026 at 14:26, Theodore Tso <tytso@mit.edu> wrote:
> On Mon, May 18, 2026 at 11:04:29AM +0300, Jani Nikula wrote:
> > > Sashiko is supporting various LLMs, including open models - it’s just a practical
> > > choice: to my knowledge the quality of open models is not on par with frontier closed
> > > models and it would require a non-trivial amount of hardware and infrastructure to run
> > > an open model at the required scale.
> >
> > In the context of the "Reviewed-by: Sashiko" discussion, this actually
> > makes it really hard to assess the quality of those reviews.
>
> Agreed. There's a reason why the coding-assistants.rst specifies the
> model which is used:
>
> Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
>
> The problem is that (as Jon has pointed out) coding-assistants.rst was
> intended for use when the tool was beging used to help create the code
> --- that is, "Coding Assistants". What we're doing here is more of a
> reviewer assistance. Something like:
>
> Scanned-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
>
> Would be more interesting, but it doesn't actually tell us anything
> about what the results were of the scan.
Indeed.
Scanned-by: Geert Uytterhoeven <geert@linux-m68k.org>
Doesn't say much more than the RFC2822 "Receved:"-header,
and thus not meant to be saved for posterity in git history ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH v2 1/3] Doc: deprecated.rst: add strlcat()
From: David Laight @ 2026-05-18 12:59 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Heiko Carstens, Kees Cook, Manuel Ebner, Andy Shevchenko,
Jonathan Corbet, Shuah Khan, Andy Whitcroft, Joe Perches,
Dwaipayan Ray, Lukas Bulwahn, Randy Dunlap, Jani Nikula,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
In-Reply-To: <CAMuHMdXEezxGi1d=BCiQ57cbnG4D2PPXvt_FAHcyT5mgR7md3g@mail.gmail.com>
On Mon, 18 May 2026 09:11:04 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi David,
...
> > I don't really see why strlcat() should be deprecated.
> > Clearly there are many cases where there are better ways to do things.
>
> https://elixir.bootlin.com/linux/v7.0.8/source/include/linux/fortify-string.h#L346
> already says "Do not use this function. [...] Prefer building the
> * string with formatting, via scnprintf(), seq_buf, or similar.".
Trouble is that all requires a lot more rework.
I might try changing the type of the 'buffer' to sysfs_emit()
from 'char *' to 'sysfs_buf *'.
Initially the types will have to be the same, but propagating it through
will show where it can be used.
But last I looked I failed to even find the associated kmalloc().
Eventually it could be changed to a different type.
> > The only problem with strlcat() is that it returns the 'required length'.
> > So there are some broken uses.
> > - fs/nfs/flexfilelayout/flexfilelayout.c
> > - lib/kunit/string-stream.c (although the preceding vsnprintf() looks like the actual bug).
> > There is also some very strange code in security/selinus/ima.c - but it may be ok.
> >
> > In reality the return value of strlcat() isn't really much worse that that
> > of snprintf().
>
> So we need strscat()? ;-)
Indeed...
-- David
>
> Gr{oetje,eeting}s,
>
> Geert
>
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Jonathan Cameron @ 2026-05-18 15:29 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: linux-doc, devicetree, workflows, linux-arch, dmaengine,
linux-i2c, linux-iio, netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky, Jonathan Corbet,
Shuah Khan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Daniel Lezcano, Thomas Gleixner, Alex Shi, Yanteng Si,
Dongliang Mu, Hu Haowen, Dinh Nguyen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V, Andrew Morton, Nick Piggin,
Peter Zijlstra, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
David Lechner, Nuno Sá, Andy Shevchenko, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Lorenzo Pieralisi, Krzysztof Wilczyński
In-Reply-To: <20260518042833.272221-1-enelsonmoore@gmail.com>
On Sun, 17 May 2026 21:28:33 -0700
Ethan Nelson-Moore <enelsonmoore@gmail.com> wrote:
> The Nios II architecture is a soft-core architecture developed by
> Altera (since acquired by Intel) and intended to run on their FPGAs.
>
> Licenses for the architecture have not been available for purchase
> since 2024 [1], and support for it has been removed from GCC 15 [2],
> Buildroot [3], and QEMU [4].
>
> Given all of these factors, it is time to remove Nios II support from
> the kernel. The maintainer stated in 2024 that they were planning to do
> so soon [5], but this did not come to pass.
>
> Remove Nios II support from the kernel and move the former maintainer
> to CREDITS. Thank you, Dinh Nguyen, for maintaining Nios II support!
>
> References:
> [1] https://docs.altera.com/v/u/docs/781327/is-discontinuing-ip-ordering-codes-listed-in-pdn2312-for-nios-ii-ip
> [2] https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e876acab6cdd84bb2b32c98fc69fb0ba29c81153
> [3] https://github.com/buildroot/buildroot/commit/6775ccc5a199d574ad70b5f79ec58cce97a07c6f
> [4] https://github.com/qemu/qemu/commit/6c3014858c4c0024dd0560f08a6eda0f92f658d6
> [5] https://sourceware.org/pipermail/newlib/2024/021083.html
>
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
If it goes for IIO trivial changes.
Acked-by: Jonathan Cameron <jic23@kernel.org>
^ permalink raw reply
* Re: [PATCH] docs: submitting-patches: Clarify that in English "reviewer" is a person
From: Randy Dunlap @ 2026-05-18 16:25 UTC (permalink / raw)
To: Vlastimil Babka (SUSE), Krzysztof Kozlowski, Jonathan Corbet,
Shuah Khan, workflows, linux-doc, linux-kernel
Cc: Greg Kroah-Hartman, Andrew Morton, David Hildenbrand,
Linus Torvalds, Guenter Roeck
In-Reply-To: <ce1e5e9b-83d0-4971-aee3-dc5a8f85ce22@kernel.org>
On 5/16/26 7:39 AM, Vlastimil Babka (SUSE) wrote:
> On 5/16/26 14:38, Krzysztof Kozlowski wrote:
>> Common understanding of word "Reviewer" is: a person performing a review
>> work [1]. Tools are not persons, thus cannot be reviewers in this term.
>> Also tools cannot make statements ("A Reviewed-by tag is a statement of
>> opinion"), since making a statement needs some sort of conscious mind.
>>
>> Our docs already clearly mark that "Reviewed-by" must come from a
>> person:
>>
>> - "By offering my Reviewed-by: tag, I state that:"
>>
>> Usage of first person "I" and word "state"
>>
>> - "A Reviewed-by tag is *a statement of opinion* that the patch is an
>> appropriate modification of the kernel without any remaining serious"
>>
>> Only a person can make a statement of opinion.
>>
>> - "Any interested reviewer (who has done the work) can offer a
>> Reviewed-by"
>>
>> A person can offer a tag thus above does not grant the tool
>> permission to offer a tag.
>>
>> However this is not enough and apparently English is not that precise,
>> so let's clarify that only a person can state the "Reviewer's statement
>> of oversight".
>>
>> Link: https://en.wiktionary.org/wiki/reviewer [1]
>> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>> Cc: Vlastimil Babka <vbabka@kernel.org>
>> Cc: Andrew Morton <akpm@linux-foundation.org>
>> Cc: David Hildenbrand <david@kernel.org>
>> Cc: Linus Torvalds <torvalds@linux-foundation.org>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> I agree with the intent that the tag is for people (whether they use a tool
> or not to help them). We also don't put "Tested-by: kernel test robot" or
> syzkaller on every commit that they test and find no bugs. Review is also
> not just about absence of bugs, but agreeing with the larger design and
> whether the change makes sense to do in the first place.
Ack that also.
> So whether that's achieved with this particular wording or differently,
>
> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.
>
>>
>> ---
>>
>> I find it silly to need to describe English, but it seems it is needed.
>>
>> https://lore.kernel.org/all/fd3b2ca7-4d64-4c4b-98a3-7d3285fa6826@roeck-us.net/
>> ---
>> Documentation/process/submitting-patches.rst | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
>> index d7290e208e72..a989de43f3db 100644
>> --- a/Documentation/process/submitting-patches.rst
>> +++ b/Documentation/process/submitting-patches.rst
>> @@ -581,10 +581,10 @@ By offering my Reviewed-by: tag, I state that:
>>
>> A Reviewed-by tag is a statement of opinion that the patch is an
>> appropriate modification of the kernel without any remaining serious
>> -technical issues. Any interested reviewer (who has done the work) can
>> -offer a Reviewed-by tag for a patch. This tag serves to give credit to
>> -reviewers and to inform maintainers of the degree of review which has been
>> -done on the patch. Reviewed-by: tags, when supplied by reviewers known to
>> +technical issues. Any interested reviewer (who has done the work and is a
>> +person) can offer a Reviewed-by tag for a patch. This tag serves to give
>> +credit to reviewers and to inform maintainers of the degree of review which has
>> +been done on the patch. Reviewed-by: tags, when supplied by reviewers known to
>> understand the subject area and to perform thorough reviews, will normally
>> increase the likelihood of your patch getting into the kernel.
>>
>
>
--
~Randy
^ permalink raw reply
* Re: Stop false review statements
From: Roman Gushchin @ 2026-05-18 17:19 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Krzysztof Kozlowski, Greg KH, Konstantin Ryabitsev, Guenter Roeck,
Miguel Ojeda, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <DIL2P8CHKVZD.2WVQQRN0FM28N@kernel.org>
> On May 17, 2026, at 8:56 AM, Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Sat May 16, 2026 at 9:15 PM CEST, Roman Gushchin wrote:
>> I agree, it’s sometimes gets tricky when a patchset is sent to multiple
>> mailing lists, which policy to apply. I have some improvements in my plans,
>> but it’s not always possible to say how it should be handled.
>
> Which improvements do you have in mind?
If a patchset is sent to multiple mailing lists now Sashiko is using the superset of
email policies. But in many cases it’s possible to determine the “main” mailing list/subsystem
and prefer it’s configuration. Not always.
>
>> It’s not fundamentally new: landing changes touching multiple subsystems is
>> always harder exactly because maintainers might have different and sometimes
>> conflicting views.
>
> It can also be relevant in cases where only a single subsystem is touched.
>
> For instance, in the case of Rust, the rust-for-linux list serves two purposes
> -- when it is a Rust subsystem change and when Rust code of any other subsystem
> is touched, i.e. the rust-for-linux list has more of a LKML character and also
> receives patches for subsystems whose maintainers may not have opted in to
> sashiko email delivery.
>
> That said, I personally don't mind too much, I really like sashiko, which is
> also why I asked for adding the driver-core list. My experience has been that it
> does a very decent job in providing feedback for C code; my feeling is that
> feedback for Rust code is not quite on par yet, but of course it also highly
> depends on the complexity and scope of the corresponding changes.
This is super interesting. An obvious idea is that the training set is relatively limited,
if we’re talking rust for kernel code. Did you notice any common topics or patterns?
Does it produce more false positives or worse in finding actual bugs in comparison
to the c code?
> However, I still have the same concern I raised previously when it comes to
> email delivery: I think that when sashiko sends feedback to contributors
> (without Cc'ing the mailing list and all other recipients), it should actively
> ask the contributor to raise things on the list with all other recipients,
> reviewers and maintainers before acting on them, such that changes subsequent to
> the first submission on the list are aligned.
I personally think that it’s always better to cc some mailing list and/or maintainers,
so there is a second pair of eyes. I totally agree that replying just to the author is less effective.
Of course, we can add the text you’re proposing, but why not simply configure sashiko
to cc the mailing list?
Thanks!
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Simon Schuster @ 2026-05-18 17:24 UTC (permalink / raw)
To: Peter Zijlstra, Arnd Bergmann, Ethan Nelson-Moore, Dinh Nguyen
Cc: linux-doc, devicetree, workflows, Linux-Arch, dmaengine,
linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org,
Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof WilczyDski,
Andreas Oetken
In-Reply-To: <20260518105735.GW3126523@noisy.programming.kicks-ass.net>
Hi Ethan, Arnd, Peter and Dinh,
On Mon, May 18, 2026 at 11:29:48AM +0200, Arnd Bergmann wrote:
> We last discussed this a year ago when Simon Schuster mentioned[1]
> that Siemens Energy is still using NIOS-2 in production and would
> prefer to have this still included in Linux for at least another
> few years until the obligation for kernel updates ends.
First off, thank you, Arnd, for remembering us as this patch series came
up and also to Dinh for his maintenance of the architecture!
Regarding our status in relation to nios2, Arnd's response already gives
you the gist:
We are well aware that the architecture was deprecated by Intel and are
therefore phasing it out in favour of more contemporary hardware.
I'm also fully aware of the uncertain future of 32-bit architectures as
a whole [0] and that this fate will come to nios2 sooner or later.
But as of now, the mainline support is still in very good shape.
On Mon, May 18, 2026 at 12:57:35PM +0200, Peter Zijlstra wrote:
> Isn't that what we have LTS branches for?
Unfortunately, as we are an infrastructure provider for civil energy
infrastructure, the refurbishment cycle is a bit slower than for
traditional consumer systems. This implies that the traditional LTS
support duration (max. Dec 2028 as of writing [1]) is rather short, and
we would be glad if we could keep the architecture in mainline for at
least 5 years and only then "decay" to LTS.
On Mon, May 18, 2026 at 11:29:48AM +0200, Arnd Bergmann wrote:
> My feeling is that the maintenance burden of keeping nios2 is
> relatively low. On the other hand, maintaining it out of tree
> as a patch set is also something that should not be all that
> hard if it does get removed.
Judging from the architecture's git history, it seems that it's
currently mainly touched by treewide refactors, which are extremely
helpful as we therefore do not have to piece these changes together
downstream. In other respects, we try to be good citizens and contribute
bugfixes as well as required cleanups (such as implementing clone3 [2]
and fixing its flag behaviour on 32-bit architectures) as they come up.
If desired, we also would be happy to intensify our support regarding
reviews or testing to share the maintnance burden if it helps to keep
nios2 in mainline a bit longer.
Best regards,
Simon
0: https://lwn.net/Articles/1035727/
1: https://www.kernel.org/category/releases.html
2: https://lore.kernel.org/lkml/20250821-nios2-implement-clone3-v1-0-1bb24017376a@siemens-energy.com/
^ permalink raw reply
* Re: Stop false review statements
From: Mauro Carvalho Chehab @ 2026-05-18 19:40 UTC (permalink / raw)
To: Theodore Tso
Cc: Jani Nikula, Roman Gushchin, Krzysztof Kozlowski, debarbos,
Arnaldo Carvalho de Melo, Greg KH, Konstantin Ryabitsev,
Guenter Roeck, sashiko-bot, sashiko-reviews, sashiko,
Linux Kernel Workflows, Linux Kernel Mailing List, devicetree,
kfree
In-Reply-To: <20260518121601.GA87957@macsyma-wired.lan>
On Mon, 18 May 2026 08:16:01 -0400
"Theodore Tso" <tytso@mit.edu> wrote:
> On Mon, May 18, 2026 at 11:04:29AM +0300, Jani Nikula wrote:
> > > Sashiko is supporting various LLMs, including open models - it’s just a practical
> > > choice: to my knowledge the quality of open models is not on par with frontier closed
> > > models and it would require a non-trivial amount of hardware and infrastructure to run
> > > an open model at the required scale.
> >
> > In the context of the "Reviewed-by: Sashiko" discussion, this actually
> > makes it really hard to assess the quality of those reviews.
>
> Agreed. There's a reason why the coding-assistants.rst specifies the
> model which is used:
>
> Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
>
> The problem is that (as Jon has pointed out) coding-assistants.rst was
> intended for use when the tool was beging used to help create the code
> --- that is, "Coding Assistants". What we're doing here is more of a
> reviewer assistance. Something like:
>
> Scanned-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]
>
> Would be more interesting, but it doesn't actually tell us anything
> about what the results were of the scan.
I don't like scanned-by, even for a tool that would always get the
same results like checkpatch. For LLM, this is even worse, as two runs
may give different results for the same code.
IMO what makes much more sense is to add information there when
a change was done due avoid a problem detected by sashiko, and what
was the fixed issue, e.g. a textual description like:
Changed locking schema after Sashiko's report report about
XXX race condition.
Also, except if 100% of the
> One of the problems here is that there is a distinction between the
> infrastructure and review prompts in the Sashiko github repository,
> and the reviews that are being published by Sashiko the web service
> being run by Google that is being lost by some folks. So I wonder if
> for now, we should just do something like:
>
> Link: https://sashiko.dev/#/patchset/20260515091829.194810-1-me%40linux.beauty
Adding a link makes sense to me. It doesn't need to be to the
sashiko's email though: it can be to the entire thread.
> Or just have a link to lore where the review has responded to the
> Sashiko review stating where the Sashiko review reported a
> pre-existing condition (perhaps one that we don't care about because
> races in readahead logic is really Not A Big Deal, etc.) We go for
> this strategy, it would actually be better for the Shashiko.dev review
> to get cc'ed to the mailing list.
>
> Personally, I think that's probably be best way to go. We already
> don't insert into the git commit an explanation of why some bullsh*t
> review by some wannabe human reviewer should be ignored, or why a
> discussion of some problem discovered by a human review in the source
> of the review would be handled in a future patch set. That's what the
> discussion on lore.kernel.org is for. And we shouldn't treat AI
> reviews any different from how we deal with human reviews. So if we
> want to give credit to an AI review, then let's go with the
> Scanned-by.
If the entire content of a Sashiko review is ignored, I don't think
it is worth adding anything. Just like we do with humans, IMO the
best is to just mention what changed due to some feedback received
by a human or by a bot, mentioning who/what bot helped to identify
the issue.
> Or we can just let people look at the mailing list, and
> if people want to have statistics, we can ask people to use a script
> running against public inbox to figure things out.
>
> - Ted
>
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH] nios2: remove the architecture
From: Wolfram Sang @ 2026-05-18 20:46 UTC (permalink / raw)
To: Simon Schuster
Cc: Peter Zijlstra, Arnd Bergmann, Ethan Nelson-Moore, Dinh Nguyen,
linux-doc, devicetree, workflows, Linux-Arch, dmaengine,
linux-i2c, linux-iio, Netdev, linux-pci, linux-pwm,
linux-hardening, linux-kbuild, linux-csky@vger.kernel.org,
Jonathan Corbet, Shuah Khan, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Daniel Lezcano, Thomas Gleixner, Alex Shi,
Yanteng Si, Dongliang Mu, Hu Haowen, Kees Cook, Oleg Nesterov,
Will Deacon, Aneesh Kumar K.V (Arm), Andrew Morton,
Nicholas Piggin, Vinod Koul, Frank Li, Dave Penkler, Andi Shyti,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Pieralisi, Krzysztof WilczyDski,
Andreas Oetken
In-Reply-To: <20260518172444.zyd47mcagrcwu7wt@dev-vm-schuster>
Hi Simon,
> downstream. In other respects, we try to be good citizens and contribute
> bugfixes as well as required cleanups (such as implementing clone3 [2]
> and fixing its flag behaviour on 32-bit architectures) as they come up.
Well, this is definitely 'good citizen'...
> If desired, we also would be happy to intensify our support regarding
> reviews or testing to share the maintnance burden if it helps to keep
> nios2 in mainline a bit longer.
... but given this, you might want to get added in MAINTAINERS as
reviewer (or even maintainer) for nios2? Besides that your efforts are
already worth it in my book, it would also ensure you get CCed on
patches like this. Then, you are not depending on people like Arnd
putting you in the loop manually.
Happy hacking,
Wolfram
^ 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