* Re: [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marc Zyngier @ 2026-06-22 6:55 UTC (permalink / raw)
To: Marek Vasut
Cc: Thomas Gleixner, linux-pci, Yoshihiro Shimoda,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring, devicetree,
linux-arm-kernel, linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <d6fce333-4353-4e49-873f-eb3187a631e4@mailbox.org>
On Sun, 21 Jun 2026 23:46:25 +0100,
Marek Vasut <marek.vasut@mailbox.org> wrote:
>
> On 6/21/26 12:59 PM, Thomas Gleixner wrote:
> > On Fri, Jun 19 2026 at 00:02, Marek Vasut wrote:
> >> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> >> or APB interface configured to 32 bit, it can therefore access only
> >> the first 4 GiB of physical address space. This information comes from
> >> R-Car V4H Interface Specification sheet, there is currently no technical
> >> update number assigned to this limitation. Further input from hardware
> >> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> >> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> >> limitation.
> >>
> >> The quirk is keyed on the combination of the GIC implementation
> >> and the platform identification in the device tree.
> >>
> >> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> >> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> >
> > This SOB chain is broken.
>
> Broken ? I don't understand , could you please elaborate ?
Either Shimoda-san is the sole author of the change and you are
posting their work, then the first line of the patch should say:
From: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
with your own SoB immediately following their SoB (see [1]).
Or this has been co-developed, and both of you should be credited as
authors. then Shimoda-san's SoB should be preceded by their
Co-developed-by: tag (see [2]).
Co-developed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This shows exactly who did what, who forwarded whose patch, and forms
the base of the DCO which is documented at [3].
Thanks,
M.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n449
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n503
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst#n396
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v4 0/5] mm/zswap: Implement per-cgroup proactive writeback
From: Hao Jia @ 2026-06-22 6:08 UTC (permalink / raw)
To: Muchun Song, youngjun.park, yosry
Cc: akpm, tj, hannes, shakeel.butt, mhocko, mkoutny, nphamcs,
chengming.zhou, roman.gushchin, linux-mm, linux-kernel, linux-doc,
Hao Jia
In-Reply-To: <CAAAF57B-7DE9-45EA-8AB6-DE6CFAF60F47@linux.dev>
On 2026/6/21 12:20, Muchun Song wrote:
>
>
>> On Jun 18, 2026, at 12:48, Hao Jia <jiahao.kernel@gmail.com> wrote:
>>
>> From: Hao Jia <jiahao1@lixiang.com>
>>
>> Zswap currently writes back pages to backing swap reactively, triggered
>> either by the shrinker or by the pool reaching its size limit. Although
>> proactive memory reclaim can automatically write back a portion of zswap
>> pages via the shrinker, it cannot explicitly control the amount of
>> writeback for a specific memory cgroup. Moreover, proactive memory reclaim
>> may not always be triggered during a steady state.
>>
>> In certain scenarios, it is desirable to trigger writeback in advance to
>> free up memory. For example, users may want to prepare for an upcoming
>> memory-intensive workload by flushing cold memory to the backing storage
>> when the system is relatively idle.
>>
>> This patch series introduces a "zswap_writeback_only" key to memory.reclaim
>> cgroup interface, allowing users to proactively write back cold compressed
>> data from zswap to the backing swap device. When specified, this key
>> bypasses standard memory reclaim and exclusively performs proactive zswap
>> writeback up to the requested budget. If omitted, the default reclaim
>> behavior remains unchanged.
>>
>> Example usage:
>> # Write back 10MB of compressed data from zswap to the backing swap
>> echo "10M zswap_writeback_only" > memory.reclaim
>
> I’m not entirely sure if other candidate names were already brought up
> in previous discussions, so my apologies if I'm repeating something here!
> I do think expanding memory.reclaim is a great approach. That said, I
> was wondering if we could make the interface a bit more concise while
> keeping it flexible for future extensions.
>
> Essentially, what we want is to control the specific targets of the reclaim
> process—such as file, anon, or zswap. What do you think about using
> something like "source=zswap"? For instance, if we want to reclaim 10M from
> zswap, the command would look like this:
>
> echo "10M source=zswap" > memory.reclaim
>
Thanks for the suggestion. TBH, I personally think your approach makes
more sense than "zswap_writeback_only".
Hi YoungJun and Yosry,
I am not sure if this suggestion from Muchun could decouple zswap
proactive writeback from the swap tiers, or make it easier to migrate to
swap tiers in the future:
echo "10M source=zswap" > memory.reclaim
For now, we only specify the source. Later on, the swap tiers feature
could extend this to control whether to demote to SSD swap, HDD swap, or
other tiers.
Thanks,
Hao
> If we only want to reclaim 10M from file pages, we could easily extend the
> syntax:
>
> echo "10M source=file" > memory.reclaim
>
> And of course, we could even combine them down the road:
>
> echo "10M source=anon,file" > memory.reclaim
>
> to only reclaim anon and file but bypass zswap.
>
> Just some thoughts of mine.
>
> Muchun,
> Thanks
^ permalink raw reply
* Re: [PATCH v8 24/46] KVM: guest_memfd: Make in-place conversion the default
From: Yan Zhao @ 2026-06-22 4:53 UTC (permalink / raw)
To: ackerleytng
Cc: aik, andrew.jones, binbin.wu, brauner, chao.p.peng, david,
jmattson, jthoughton, michael.roth, oupton, pankaj.gupta, qperret,
rick.p.edgecombe, rientjes, shivankg, steven.price, tabba, willy,
wyihan, forkloop, pratyush, suzuki.poulose, aneesh.kumar, liam,
Paolo Bonzini, Sean Christopherson, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, x86, H. Peter Anvin, Steven Rostedt,
Masami Hiramatsu, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
Shuah Khan, Vishal Annapurve, Andrew Morton, Chris Li,
Kairui Song, Kemeng Shi, Nhat Pham, Barry Song, Axel Rasmussen,
Yuanchu Xie, Wei Xu, Youngjun Park, Qi Zheng, Shakeel Butt,
Kiryl Shutsemau, Baoquan He, Jason Gunthorpe, Vlastimil Babka,
kvm, linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest,
linux-mm, linux-coco
In-Reply-To: <20260618-gmem-inplace-conversion-v8-24-9d2959357853@google.com>
On Thu, Jun 18, 2026 at 05:32:01PM -0700, Ackerley Tng via B4 Relay wrote:
> From: Ackerley Tng <ackerleytng@google.com>
>
> Make in-place conversion the default if the arch has private mem.
>
> The default can be overridden at compile type by enabling
> CONFIG_KVM_VM_MEMORY_ATTRIBUTES, or at KVM load time through a module
> parameter.
>
> In-place conversion also implies tracking a guest's private/shared state in
> guest_memfd. To avoid inconsistencies in the way memory attributes are
> tracked between the per-VM or by guest_memfd, make the module_param
> read-only (0444).
>
> Document that using per-VM attributes for tracking private/shared state of
> guest memory is deprecated in favor of tracking in guest_memfd.
>
> Warn if the admin sets gmem_in_place_conversion as false when
> CONFIG_KVM_VM_MEMORY_ATTRIBUTES is not enabled. Add warning in the code
> path where guest memory is populated for a CoCo VM, since that's the
> earliest point in a CoCo VM's lifecycle where memory attributes are
> queried. Unlike other query sites, this site is exclusively used by CoCo
> VMs.
>
> Signed-off-by: Sean Christopherson <seanjc@google.com>
> ---
> arch/x86/kvm/Kconfig | 7 ++++++-
> virt/kvm/guest_memfd.c | 5 +++++
> virt/kvm/kvm_main.c | 3 ++-
> 3 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index c28393dc664eb..a3c189d765150 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -85,7 +85,12 @@ config KVM_VM_MEMORY_ATTRIBUTES
> bool "Enable per-VM PRIVATE vs. SHARED attributes (for CoCo VMs)"
> help
> Enable support for tracking PRIVATE vs. SHARED memory using per-VM
> - memory attributes.
> + memory attributes. Using per-VM attributes are deprecated in favor
> + of tracking PRIVATE state in guest_memfd. Select this if you need
> + to run CoCo VMs using a VMM that doesn't support guest_memfd memory
> + attributes.
> +
> + If unsure, say N.
>
> config KVM_SW_PROTECTED_VM
> bool "Enable support for KVM software-protected VMs"
> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> index 86c9f5b0863cb..5cb73543c03c8 100644
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
> @@ -1193,10 +1193,15 @@ static bool kvm_gmem_range_is_private(struct file *file, pgoff_t index,
> {
> struct maple_tree *mt = &GMEM_I(file_inode(file))->attributes;
>
> +#ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> if (!gmem_in_place_conversion)
> return kvm_range_has_vm_memory_attributes(kvm, gfn, gfn + nr_pages,
> KVM_MEMORY_ATTRIBUTE_PRIVATE,
> KVM_MEMORY_ATTRIBUTE_PRIVATE);
> +#else
> + if (WARN_ON_ONCE(!gmem_in_place_conversion))
> + return false;
> +#endif
>
> return kvm_gmem_range_has_attributes(mt, index, nr_pages,
> KVM_MEMORY_ATTRIBUTE_PRIVATE);
> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c
> index dd1d18a1d2f68..46e92b5dc3804 100644
> --- a/virt/kvm/kvm_main.c
> +++ b/virt/kvm/kvm_main.c
> @@ -102,7 +102,8 @@ static bool __ro_after_init allow_unsafe_mappings;
> module_param(allow_unsafe_mappings, bool, 0444);
>
> #ifdef kvm_arch_has_private_mem
> -bool __ro_after_init gmem_in_place_conversion = false;
> +bool __ro_after_init gmem_in_place_conversion = !IS_ENABLED(CONFIG_KVM_VM_MEMORY_ATTRIBUTES);
> +module_param(gmem_in_place_conversion, bool, 0444);
With gmem_in_place_conversion=true, userspace can create guest_memfd without the
MMAP flag. In such cases, shared memory is allocated from different backends.
This means this module parameter only enables per-gmem memory attribute and does
not guarantee that gmem in-place conversion will actually occur.
To avoid confusion, could we rename this module parameter to something more
accurate, such as gmem_memory_attribute?
> EXPORT_SYMBOL_FOR_KVM_INTERNAL(gmem_in_place_conversion);
> #endif
>
>
> --
> 2.55.0.rc0.738.g0c8ab3ebcc-goog
>
>
^ permalink raw reply
* Re: [RFC PATCH 0/2] kasan: hw_tags: Add option to tag only at allocation time
From: Dev Jain @ 2026-06-22 4:21 UTC (permalink / raw)
To: Isaac Manjarres
Cc: ryabinin.a.a, akpm, corbet, glider, andreyknvl, dvyukov,
vincenzo.frascino, kasan-dev, linux-mm, linux-kernel, skhan,
workflows, linux-doc, linux-arm-kernel, ryan.roberts,
anshuman.khandual, kaleshsingh, 21cnbao, david, will,
catalin.marinas
In-Reply-To: <aiyhb2XwMMJE3st7@google.com>
On 13/06/26 5:46 am, Isaac Manjarres wrote:
> On Fri, Jun 12, 2026 at 04:44:22AM +0000, Dev Jain wrote:
>> Introduce a boot option to tag only at allocation time of the objects. This
>> reduces KASAN MTE overhead, the tradeoff being reduced ability of
>> catching bugs.
>>
>> Now, when a memory object will be freed, it will retain the random tag it
>> had at allocation time. This compromises on catching UAF bugs, till the
>> time the object is not reallocated, at which point it will have a new
>> random tag.
>>
>> Hence, not catching "use-after-free-before-reallocation" and not catching
>> "double-free" will be the compromise for reduced KASAN overhead.
>>
>> This is an RFC because we are not clear about the performance benefit.
>>
>> Android folks, please help with testing!
>>
>> ---
>> Applies on Linus master (9716c086c8e8).
>>
>> Dev Jain (2):
>> kasan: hw_tags: Use KASAN_PAGE_REDZONE for vmalloc redzoning
>> kasan: hw_tags: Add boot option to elide free time poisoning
>>
>> Documentation/dev-tools/kasan.rst | 4 +++
>> mm/kasan/hw_tags.c | 45 +++++++++++++++++++++++++++++--
>> mm/kasan/kasan.h | 23 +++++++++++++++-
>> 3 files changed, 69 insertions(+), 3 deletions(-)
>>
>> --
>> 2.43.0
>
> I tested out this series on one of our devices that has MTE support,
> and didn't see any functional issues.
Thanks for testing Isaac! Do you have the bandwidth to carry out some
performance tests? We want to see whether this patchset gets perf boost
on some HW.
>
> One thing I did notice though, and it's independent of this patch, is
> that the vmalloc_oob is failing, but that happens even if these patches
> aren't present.
>
> Thanks,
> Isaac
^ permalink raw reply
* Re: [PATCH v6 5/6] kselftest: alloc_tag: add kselftest for ioctl interface
From: Hao Ge @ 2026-06-22 3:20 UTC (permalink / raw)
To: Suren Baghdasaryan, Abhishek Bapat
Cc: Andrew Morton, Kent Overstreet, Shuah Khan, Jonathan Corbet,
linux-doc, linux-kernel, linux-mm, Sourav Panda
In-Reply-To: <CAJuCfpHPBq7TiD1wfvMyVWbBOw9prEY7LvoLveeoYQOuEEJabg@mail.gmail.com>
On 2026/6/21 08:10, Suren Baghdasaryan wrote:
> On Thu, Jun 18, 2026 at 10:36 AM Abhishek Bapat
> <abhishekbapat@google.com> wrote:
>> Introduce a kselftest to verify the new IOCTL-based interface for
>> /proc/allocinfo. The test covers:
>>
>> 1. Validation of the filename filter.
>> 2. Validation of the function filter.
>>
>> The first test validates the functionality of the filename filter. Using
>> "mm/memory.c" as the candidate filename filter, it retrieves filtered
>> entries from both procfs and ioctl and matches the first VEC_MAX_ENTRIES
>> entries.
>>
>> The second test validates the functionality of the function filter.
>> It uses "dup_mm" as the candidate function as we do not expect this
>> function name to change frequently and hence won't be needing to modify
>> this test often.
>>
>> Note that both the tests match line no, function name and file name
>> fields. Bytes allocated and calls are not matched as those values may
>> change in the time when the data is being read from procfs and ioctl and
>> hence can lead to false negatives.
>>
>> Signed-off-by: Abhishek Bapat <abhishekbapat@google.com>
>> ---
>> MAINTAINERS | 1 +
>> tools/testing/selftests/Makefile | 1 +
>> tools/testing/selftests/alloc_tag/Makefile | 9 +
>> .../alloc_tag/allocinfo_ioctl_test.c | 335 ++++++++++++++++++
>> 4 files changed, 346 insertions(+)
>> create mode 100644 tools/testing/selftests/alloc_tag/Makefile
>> create mode 100644 tools/testing/selftests/alloc_tag/allocinfo_ioctl_test.c
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 019cc4c285a3..6610dd42e484 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -16715,6 +16715,7 @@ F: include/linux/alloc_tag.h
>> F: include/linux/pgalloc_tag.h
>> F: include/uapi/linux/alloc_tag.h
>> F: lib/alloc_tag.c
>> +F: tools/testing/selftests/alloc_tag/
>>
>> MEMORY CONTROLLER DRIVERS
>> M: Krzysztof Kozlowski <krzk@kernel.org>
>> diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
>> index 6e59b8f63e41..276a78c64736 100644
>> --- a/tools/testing/selftests/Makefile
>> +++ b/tools/testing/selftests/Makefile
>> @@ -1,5 +1,6 @@
>> # SPDX-License-Identifier: GPL-2.0
>> TARGETS += acct
>> +TARGETS += alloc_tag
>> TARGETS += alsa
>> TARGETS += amd-pstate
>> TARGETS += arm64
>> diff --git a/tools/testing/selftests/alloc_tag/Makefile b/tools/testing/selftests/alloc_tag/Makefile
>> new file mode 100644
>> index 000000000000..f2b8fc022c3b
>> --- /dev/null
>> +++ b/tools/testing/selftests/alloc_tag/Makefile
>> @@ -0,0 +1,9 @@
>> +# SPDX-License-Identifier: GPL-2.0
>> +
>> +TEST_GEN_PROGS := allocinfo_ioctl_test
>> +
>> +CFLAGS += -Wall
>> +CFLAGS += -I../../../../usr/include
> I recall Hao suggested replacing this path with $(KHDR_INCLUDES). Have
> you tried that?
Hi Suren and Abhishek
Yes, I suggested this in my previous email.
Using CFLAGS += -I../../../../usr/include fails to support out-of-tree
build workflows.
I ran the following command:
make O=/home alldebug_defconfig
make O=/home -j8
make O=/home headers_install
make -C tools/testing/selftests/ TARGETS=alloc_tag O=/home/
[root@localhost linux]# make -C tools/testing/selftests
TARGETS=alloc_tag O=/home/
make: Entering directory '/home/linux/tools/testing/selftests'
CC allocinfo_ioctl_test
allocinfo_ioctl_test.c:16:10: fatal error: linux/alloc_tag.h: No such
file or directory
16 | #include <linux/alloc_tag.h>
| ^~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [allocinfo_ioctl_test] Error 1
Therefore, using $(KHDR_INCLUDES) here is more appropriate. The
corresponding build flow is as follows:
https://elixir.bootlin.com/linux/v7.1/source/tools/testing/selftests/Makefile#L198
After modification, the compilation output is shown below:
[root@localhost linux]# make -C tools/testing/selftests
TARGETS=alloc_tag O=/home/
make: Entering directory '/home/linux/tools/testing/selftests'
CC allocinfo_ioctl_test
make: Leaving directory '/home/linux/tools/testing/selftests'
[root@localhost linux]# ls /home/kselftest/alloc_tag/allocinfo_ioctl_test
/home/kselftest/alloc_tag/allocinfo_ioctl_test
[root@localhost linux]#
Thanks
Best Regards
Hao
>
>> +
>> +include ../lib.mk
>> +
>> diff --git a/tools/testing/selftests/alloc_tag/allocinfo_ioctl_test.c b/tools/testing/selftests/alloc_tag/allocinfo_ioctl_test.c
>> new file mode 100644
>> index 000000000000..1ae0291f2245
>> --- /dev/null
>> +++ b/tools/testing/selftests/alloc_tag/allocinfo_ioctl_test.c
>> @@ -0,0 +1,335 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +
>> +/* kselftest for allocinfo ioctl
>> + * allocinfo ioctl retrives allocinfo data through ioctl
>> + * Copyright (C) 2026 Google, Inc.
>> + */
>> +
>> +#include <fcntl.h>
>> +#include <stdio.h>
>> +#include <stdlib.h>
>> +#include <string.h>
>> +#include <stdbool.h>
>> +#include <unistd.h>
>> +#include <sys/ioctl.h>
>> +#include <linux/types.h>
>> +#include <linux/alloc_tag.h>
>> +#include "../kselftest.h"
>> +
>> +#define MAX_LINE_LEN 512
>> +#define ALLOCINFO_PROC "/proc/allocinfo"
>> +
>> +enum ioctl_ret {
>> + IOCTL_SUCCESS = 0,
>> + IOCTL_FAILURE = 1,
>> + IOCTL_INVALID_DATA = 2,
>> +};
>> +
>> +#define VEC_MAX_ENTRIES 32
>> +
>> +struct allocinfo_tag_data_vec {
>> + struct allocinfo_tag_data tag[VEC_MAX_ENTRIES];
>> + __u64 count;
>> +};
>> +
>> +static inline int __allocinfo_get_content_id(int dev_fd, struct allocinfo_content_id *params)
>> +{
>> + return ioctl(dev_fd, ALLOCINFO_IOC_CONTENT_ID, params);
>> +}
>> +
>> +static inline int __allocinfo_get_at(int dev_fd, struct allocinfo_get_at *params)
>> +{
>> + return ioctl(dev_fd, ALLOCINFO_IOC_GET_AT, params);
>> +}
>> +
>> +static inline int __allocinfo_get_next(int dev_fd, struct allocinfo_tag_data *params)
>> +{
>> + return ioctl(dev_fd, ALLOCINFO_IOC_GET_NEXT, params);
>> +}
>> +
>> +static bool match_entry(const struct allocinfo_tag_data *procfs_entry,
>> + const struct allocinfo_tag_data *tag_data,
>> + bool match_bytes, bool match_calls, bool match_lineno,
>> + bool match_function, bool match_filename)
>> +{
>> + if (match_bytes && tag_data->counter.bytes != procfs_entry->counter.bytes) {
>> + ksft_print_msg("size retrieved through ioctl does not match procfs\n");
>> + return false;
>> + }
>> +
>> + if (match_calls && tag_data->counter.calls != procfs_entry->counter.calls) {
>> + ksft_print_msg("call count retrieved through ioctl does not match procfs\n");
>> + return false;
>> + }
>> +
>> + if (match_lineno && tag_data->tag.lineno != procfs_entry->tag.lineno) {
>> + ksft_print_msg("lineno retrieved through ioctl does not match procfs\n");
>> + return false;
>> + }
>> +
>> + if (match_function &&
>> + strncmp(tag_data->tag.function, procfs_entry->tag.function, ALLOCINFO_STR_SIZE)) {
>> + ksft_print_msg("function retrieved through ioctl does not match procfs\n");
>> + return false;
>> + }
>> +
>> + if (match_filename &&
>> + strncmp(tag_data->tag.filename, procfs_entry->tag.filename, ALLOCINFO_STR_SIZE)) {
>> + ksft_print_msg("filename retrieved through ioctl does not match procfs\n");
>> + return false;
>> + }
>> + return true;
>> +}
>> +
>> +static bool match_entries(const struct allocinfo_tag_data_vec *procfs_entries,
>> + const struct allocinfo_tag_data_vec *tags,
>> + bool match_bytes, bool match_calls, bool match_lineno,
>> + bool match_function, bool match_filename)
>> +{
>> + __u64 i;
>> +
>> + if (procfs_entries->count != tags->count) {
>> + ksft_print_msg("Entry count mismatch. ioctl entries: %llu, proc entries: %llu\n",
>> + tags->count, procfs_entries->count);
>> + return false;
>> + }
>> + for (i = 0; i < procfs_entries->count; i++) {
>> + if (!match_entry(&procfs_entries->tag[i], &tags->tag[i],
>> + match_bytes, match_calls, match_lineno,
>> + match_function, match_filename)) {
>> + ksft_print_msg("%lluth entry does not match.\n", i);
>> + return false;
>> + }
>> + }
>> + return true;
>> +}
>> +
>> +static const char *allocinfo_str(const char *str)
>> +{
>> + size_t len = strlen(str);
>> +
>> + if (len >= ALLOCINFO_STR_SIZE)
>> + str += (len - ALLOCINFO_STR_SIZE) + 1;
>> + return str;
>> +}
>> +
>> +static void allocinfo_copy_str(char *dest, const char *src)
>> +{
>> + strncpy(dest, allocinfo_str(src), ALLOCINFO_STR_SIZE - 1);
>> + dest[ALLOCINFO_STR_SIZE - 1] = '\0';
>> +}
>> +
>> +static int get_filtered_procfs_entries(struct allocinfo_tag_data_vec *procfs_entries,
>> + const struct allocinfo_filter *filter)
>> +{
>> + FILE *fp = fopen(ALLOCINFO_PROC, "r");
>> + char line[MAX_LINE_LEN];
>> + int matches;
>> + struct allocinfo_tag_data procfs_entry;
>> +
>> + if (!fp) {
>> + ksft_print_msg("Failed to open " ALLOCINFO_PROC " for reading\n");
>> + return 1;
>> + }
>> + memset(procfs_entries, 0, sizeof(*procfs_entries));
>> + while (fgets(line, sizeof(line), fp) && procfs_entries->count < VEC_MAX_ENTRIES) {
>> + char filename[MAX_LINE_LEN];
>> + char function[MAX_LINE_LEN];
>> +
>> + memset(&procfs_entry, 0, sizeof(procfs_entry));
>> + matches = sscanf(line, "%llu %llu %[^:]:%llu func:%s",
>> + &procfs_entry.counter.bytes,
>> + &procfs_entry.counter.calls,
>> + filename,
>> + &procfs_entry.tag.lineno,
>> + function);
>> +
>> + if (matches != 5)
>> + continue;
>> +
>> + allocinfo_copy_str(procfs_entry.tag.filename, filename);
>> + allocinfo_copy_str(procfs_entry.tag.function, function);
>> +
>> + if (filter->mask & ALLOCINFO_FILTER_MASK_FILENAME) {
>> + if (strncmp(procfs_entry.tag.filename,
>> + filter->fields.filename, ALLOCINFO_STR_SIZE))
>> + continue;
>> + }
>> + if (filter->mask & ALLOCINFO_FILTER_MASK_FUNCTION) {
>> + if (strncmp(procfs_entry.tag.function,
>> + filter->fields.function, ALLOCINFO_STR_SIZE))
>> + continue;
>> + }
>> + if (filter->mask & ALLOCINFO_FILTER_MASK_LINENO) {
>> + if (procfs_entry.tag.lineno != filter->fields.lineno)
>> + continue;
>> + }
>> + if (filter->mask & ALLOCINFO_FILTER_MASK_MIN_SIZE) {
>> + if (procfs_entry.counter.bytes < filter->min_size)
>> + continue;
>> + }
>> + if (filter->mask & ALLOCINFO_FILTER_MASK_MAX_SIZE) {
>> + if (procfs_entry.counter.bytes > filter->max_size)
>> + continue;
>> + }
>> +
>> + memcpy(&procfs_entries->tag[procfs_entries->count++], &procfs_entry,
>> + sizeof(procfs_entry));
>> + }
>> + fclose(fp);
>> + return 0;
>> +}
>> +
>> +static enum ioctl_ret get_filtered_ioctl_entries(struct allocinfo_tag_data_vec *tags,
>> + const struct allocinfo_filter *filter,
>> + __u64 start_pos)
>> +{
>> + int fd = open(ALLOCINFO_PROC, O_RDONLY);
>> +
>> + if (fd < 0) {
>> + ksft_print_msg("Failed to open " ALLOCINFO_PROC " for IOCTL\n");
>> + return IOCTL_FAILURE;
>> + }
>> +
>> + struct allocinfo_content_id start_cont_id, end_cont_id;
>> + struct allocinfo_get_at get_at_params;
>> + const int max_retries = 10;
>> + int retry_count = 0;
>> + int status;
>> +
>> + /*
>> + * __allocinfo_get_content_id may return different values if a kernel module was loaded
>> + * between the two calls. If that happens, the data gathered cannot be considered consistent
>> + * and hence needs to be fetched again to avoid flakiness.
>> + */
>> + do {
>> + if (__allocinfo_get_content_id(fd, &start_cont_id)) {
>> + ksft_print_msg("allocinfo_get_content_id failed\n");
>> + status = IOCTL_FAILURE;
>> + goto exit;
> nit: I would prefer a "break" instead of these "goto exit" statements
> for exiting this loop. Makes the code flow more readable IMHO.
>
>> + }
>> +
>> + memset(tags, 0, sizeof(*tags));
>> + memset(&get_at_params, 0, sizeof(get_at_params));
>> + memcpy(&get_at_params.filter, filter, sizeof(*filter));
>> + get_at_params.pos = start_pos;
>> + if (__allocinfo_get_at(fd, &get_at_params)) {
>> + ksft_print_msg("allocinfo_get_at failed\n");
>> + status = IOCTL_FAILURE;
>> + goto exit;
>> + }
>> + memcpy(&tags->tag[tags->count++], &get_at_params.data, sizeof(get_at_params.data));
>> +
>> + while (tags->count < VEC_MAX_ENTRIES &&
>> + __allocinfo_get_next(fd, &tags->tag[tags->count]) == 0)
>> + tags->count++;
>> +
>> + if (__allocinfo_get_content_id(fd, &end_cont_id)) {
>> + ksft_print_msg("allocinfo_get_content_id failed\n");
>> + status = IOCTL_FAILURE;
>> + goto exit;
>> + }
>> +
>> + if (start_cont_id.id == end_cont_id.id) {
>> + status = IOCTL_SUCCESS;
>> + } else {
>> + ksft_print_msg("allocinfo_get_content_id mismatch, retrying...\n");
>> + status = IOCTL_INVALID_DATA;
>> + }
>> + } while (status == IOCTL_INVALID_DATA && retry_count++ < max_retries);
>> +
>> +exit:
>> + close(fd);
>> + return status;
>> +}
>> +
>> +static int run_filter_test(const struct allocinfo_filter *filter)
>> +{
>> + struct allocinfo_tag_data_vec *tags = malloc(sizeof(*tags));
>> + struct allocinfo_tag_data_vec *procfs_entries = malloc(sizeof(*procfs_entries));
>> + int ioctl_status;
>> + int ret = KSFT_PASS;
>> +
>> + if (!tags || !procfs_entries) {
>> + ksft_print_msg("Memory allocation failed.\n");
>> + ret = KSFT_FAIL;
>> + goto exit;
>> + }
>> +
>> + if (get_filtered_procfs_entries(procfs_entries, filter)) {
>> + ksft_print_msg("Error retrieving entries from " ALLOCINFO_PROC "\n");
>> + ret = KSFT_SKIP;
>> + goto exit;
>> + }
>> +
>> + if (procfs_entries->count == 0) {
>> + ksft_print_msg("No entries found in " ALLOCINFO_PROC ", skipping test\n");
>> + ret = KSFT_SKIP;
>> + goto exit;
>> + }
>> +
>> + ioctl_status = get_filtered_ioctl_entries(tags, filter, 0);
>> + if (ioctl_status == IOCTL_INVALID_DATA) {
>> + ksft_print_msg("Trouble retrieving valid IOCTL entries, skipping.\n");
>> + ret = KSFT_SKIP;
>> + goto exit;
>> + }
>> + if (ioctl_status == IOCTL_FAILURE) {
>> + ksft_print_msg("Error retrieving IOCTL entries.\n");
>> + ret = KSFT_FAIL;
>> + goto exit;
>> + }
>> +
>> + if (!match_entries(procfs_entries, tags, false, false, true, true, true))
>> + ret = KSFT_FAIL;
>> +
>> +exit:
>> + free(tags);
>> + free(procfs_entries);
>> + return ret;
>> +}
>> +
>> +static int test_filename_filter(void)
>> +{
>> + struct allocinfo_filter filter;
>> + const char *target_filename = "mm/memory.c";
>> +
>> + memset(&filter, 0, sizeof(filter));
>> + filter.mask |= ALLOCINFO_FILTER_MASK_FILENAME;
>> + strncpy(filter.fields.filename, target_filename, ALLOCINFO_STR_SIZE);
>> +
>> + return run_filter_test(&filter);
>> +}
>> +
>> +static int test_function_filter(void)
>> +{
>> + struct allocinfo_filter filter;
>> + const char *target_function = "dup_mm";
>> +
>> + memset(&filter, 0, sizeof(filter));
>> + filter.mask |= ALLOCINFO_FILTER_MASK_FUNCTION;
>> + strncpy(filter.fields.function, target_function, ALLOCINFO_STR_SIZE);
>> +
>> + return run_filter_test(&filter);
>> +}
>> +
>> +int main(int argc, char *argv[])
>> +{
>> + int ret;
>> +
>> + ksft_set_plan(2);
>> +
>> + ret = test_filename_filter();
>> + if (ret == KSFT_SKIP)
>> + ksft_test_result_skip("Skipping test_filename_filter\n");
>> + else
>> + ksft_test_result(ret == KSFT_PASS, "test_filename_filter\n");
>> +
>> + ret = test_function_filter();
>> + if (ret == KSFT_SKIP)
>> + ksft_test_result_skip("Skipping test_function_filter\n");
>> + else
>> + ksft_test_result(ret == KSFT_PASS, "test_function_filter\n");
>> +
>> + ksft_finished();
>> +}
>> --
>> 2.55.0.rc0.786.g65d90a0328-goog
>>
^ permalink raw reply
* Re: [PATCH v6 1/8] tracing/probes: Support dumping fetcharg program for debugging dynamic events
From: Masami Hiramatsu @ 2026-06-22 0:01 UTC (permalink / raw)
To: Masami Hiramatsu (Google)
Cc: Steven Rostedt, Mathieu Desnoyers, Jonathan Corbet, Shuah Khan,
linux-kernel, linux-trace-kernel, linux-doc, linux-kselftest
In-Reply-To: <178196863297.560995.16891637449659873905.stgit@devnote2>
Hi
Sashiko found another bug about FETCH_OP_TP_ARG. which seems using
fetch_insn parameter wrongly (using different parameters).
I need to fix it first.
We also may need to rename FETCH_OP_DATA to FETCH_OP_IMMSTR.
Thanks,
On Sun, 21 Jun 2026 00:17:13 +0900
"Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
> From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
>
> For debugging probe events, it is helpful to verify the compiled
> fetch instructions for each probe argument. This introduces a new
> kernel config CONFIG_PROBE_EVENTS_DUMP_FETCHARG to decode the
> instruction sequence of each argument and display it under a
> commented line starting with '#' immediately following the dynamic
> event definition (such as in dynamic_events, kprobe_events,
> uprobe_events, etc.).
>
> For example:
> /sys/kernel/tracing # cat dynamic_events
> p:kprobes/p_vfs_read_0 vfs_read arg1=+0(file):ustring arg2=%ax:x16
> # arg1: ARG(0) -> ST_USTRING(offset=0,size=4) -> END
> # arg2: REG(80) -> ST_RAW(size=2) -> END
>
> Assisted-by: Antigravity:gemini-3.5-flash
> Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
> ---
> Changes in v6:
> - Newly added.
> ---
> kernel/trace/Kconfig | 11 +++++
> kernel/trace/trace_eprobe.c | 2 +
> kernel/trace/trace_fprobe.c | 2 +
> kernel/trace/trace_kprobe.c | 2 +
> kernel/trace/trace_probe.c | 90 +++++++++++++++++++++++++++++++++++++++++++
> kernel/trace/trace_probe.h | 77 ++++++++++++++++++++++---------------
> kernel/trace/trace_uprobe.c | 3 +
> 7 files changed, 157 insertions(+), 30 deletions(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index e130da35808f..ed83fbfb4b7c 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -779,6 +779,17 @@ config PROBE_EVENTS_BTF_ARGS
> kernel function entry or a tracepoint.
> This is available only if BTF (BPF Type Format) support is enabled.
>
> +config PROBE_EVENTS_DUMP_FETCHARG
> + depends on PROBE_EVENTS
> + bool "Dump of dynamic probe event fetch-arguments"
> + default n
> + help
> + This shows the dump of fetch-arguments of dynamic probe events
> + alongside their event definitions in the dynamic_events file
> + as comment lines. This is useful to debug the probe events.
> +
> + If unsure, say N.
> +
> config KPROBE_EVENTS
> depends on KPROBES
> depends on HAVE_REGS_AND_STACK_ACCESS_API
> diff --git a/kernel/trace/trace_eprobe.c b/kernel/trace/trace_eprobe.c
> index b66d6196338d..fdb4ce993cad 100644
> --- a/kernel/trace/trace_eprobe.c
> +++ b/kernel/trace/trace_eprobe.c
> @@ -87,6 +87,8 @@ static int eprobe_dyn_event_show(struct seq_file *m, struct dyn_event *ev)
> seq_printf(m, " %s=%s", ep->tp.args[i].name, ep->tp.args[i].comm);
> seq_putc(m, '\n');
>
> + trace_probe_dump_args(m, &ep->tp);
> +
> return 0;
> }
>
> diff --git a/kernel/trace/trace_fprobe.c b/kernel/trace/trace_fprobe.c
> index 4d1abbf66229..536781cd4c47 100644
> --- a/kernel/trace/trace_fprobe.c
> +++ b/kernel/trace/trace_fprobe.c
> @@ -1449,6 +1449,8 @@ static int trace_fprobe_show(struct seq_file *m, struct dyn_event *ev)
> seq_printf(m, " %s=%s", tf->tp.args[i].name, tf->tp.args[i].comm);
> seq_putc(m, '\n');
>
> + trace_probe_dump_args(m, &tf->tp);
> +
> return 0;
> }
>
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index a8420e6abb56..cfa807d8e760 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -1320,6 +1320,8 @@ static int trace_kprobe_show(struct seq_file *m, struct dyn_event *ev)
> seq_printf(m, " %s=%s", tk->tp.args[i].name, tk->tp.args[i].comm);
> seq_putc(m, '\n');
>
> + trace_probe_dump_args(m, &tk->tp);
> +
> return 0;
> }
>
> diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
> index 98532c503d02..9d174cd1fb1c 100644
> --- a/kernel/trace/trace_probe.c
> +++ b/kernel/trace/trace_probe.c
> @@ -2393,3 +2393,93 @@ int trace_probe_print_args(struct trace_seq *s, struct probe_arg *args, int nr_a
> }
> return 0;
> }
> +
> +#ifdef CONFIG_PROBE_EVENTS_DUMP_FETCHARG
> +
> +struct fetch_op_decode {
> + const char *name;
> + void (*decode)(struct seq_file *m, struct fetch_insn *insn);
> +};
> +
> +static const struct fetch_op_decode fetch_op_decode[];
> +
> +static void fetcharg_decode_none(struct seq_file *m, struct fetch_insn *insn)
> +{
> + seq_puts(m, fetch_op_decode[insn->op].name);
> +}
> +
> +static void fetcharg_decode_param(struct seq_file *m, struct fetch_insn *insn)
> +{
> + seq_printf(m, "%s(%u)", fetch_op_decode[insn->op].name, insn->param);
> +}
> +
> +static void fetcharg_decode_imm(struct seq_file *m, struct fetch_insn *insn)
> +{
> + seq_printf(m, "%s(0x%lx)", fetch_op_decode[insn->op].name, insn->immediate);
> +}
> +
> +static void fetcharg_decode_ptr(struct seq_file *m, struct fetch_insn *insn)
> +{
> + seq_printf(m, "%s(%p)", fetch_op_decode[insn->op].name, insn->data);
> +}
> +
> +static void fetcharg_decode_symbol(struct seq_file *m, struct fetch_insn *insn)
> +{
> + seq_printf(m, "%s(%s)", fetch_op_decode[insn->op].name, (char *)insn->data);
> +}
> +
> +static void fetcharg_decode_offset(struct seq_file *m, struct fetch_insn *insn)
> +{
> + seq_printf(m, "%s(offset=%d)", fetch_op_decode[insn->op].name, insn->offset);
> +}
> +
> +static void fetcharg_decode_store(struct seq_file *m, struct fetch_insn *insn)
> +{
> + if (insn->op == FETCH_OP_ST_RAW)
> + seq_printf(m, "%s(size=%u)", fetch_op_decode[insn->op].name, insn->size);
> + else
> + seq_printf(m, "%s(offset=%d,size=%u)", fetch_op_decode[insn->op].name, insn->offset, insn->size);
> +}
> +
> +static void fetcharg_decode_bf(struct seq_file *m, struct fetch_insn *insn)
> +{
> + seq_printf(m, "%s(basesize=%u,lshift=%u,rshift=%u)",
> + fetch_op_decode[insn->op].name, insn->basesize, insn->lshift, insn->rshift);
> +}
> +
> +#define FETCH_OP(opname, decode_fn) \
> + [FETCH_OP_##opname] = { .name = #opname, .decode = fetcharg_decode_##decode_fn },
> +
> +static const struct fetch_op_decode fetch_op_decode[] = {
> + FETCH_OP_LIST
> +};
> +#undef FETCH_OP
> +
> +static void trace_probe_dump_arg(struct seq_file *m, struct probe_arg *parg)
> +{
> + int i;
> +
> + seq_printf(m, "# %s: ", parg->name);
> + for (i = 0; i < FETCH_INSN_MAX; i++) {
> + struct fetch_insn *insn = parg->code + i;
> +
> + if (insn->op >= ARRAY_SIZE(fetch_op_decode) || !fetch_op_decode[insn->op].decode)
> + seq_printf(m, "unknown(%d)", insn->op);
> + else
> + fetch_op_decode[insn->op].decode(m, insn);
> +
> + if (insn->op == FETCH_OP_END)
> + break;
> + seq_puts(m, " -> ");
> + }
> + seq_putc(m, '\n');
> +}
> +
> +void trace_probe_dump_args(struct seq_file *m, struct trace_probe *tp)
> +{
> + int i;
> +
> + for (i = 0; i < tp->nr_args; i++)
> + trace_probe_dump_arg(m, &tp->args[i]);
> +}
> +#endif /* CONFIG_PROBE_EVENTS_DUMP_FETCHARG */
> diff --git a/kernel/trace/trace_probe.h b/kernel/trace/trace_probe.h
> index 0f09f7aaf93f..b428ef42b229 100644
> --- a/kernel/trace/trace_probe.h
> +++ b/kernel/trace/trace_probe.h
> @@ -83,38 +83,47 @@ static nokprobe_inline u32 update_data_loc(u32 loc, int consumed)
> /* Printing function type */
> typedef int (*print_type_func_t)(struct trace_seq *, void *, void *);
>
> +#define FETCH_OP_LIST \
> + /* Stage 1 (load) ops */ \
> + FETCH_OP(NOP, none) /* NOP */ \
> + FETCH_OP(REG, param) /* Register: .param = offset */ \
> + FETCH_OP(STACK, param) /* Stack: .param = index */ \
> + FETCH_OP(STACKP, none) /* Stack pointer */ \
> + FETCH_OP(RETVAL, none) /* Return value */ \
> + FETCH_OP(IMM, imm) /* Immediate: .immediate */ \
> + FETCH_OP(COMM, none) /* Current comm */ \
> + FETCH_OP(ARG, param) /* Argument: .param = index */ \
> + FETCH_OP(FOFFS, imm) /* File offset: .immediate */ \
> + FETCH_OP(DATA, ptr) /* Allocated data: .data */ \
> + FETCH_OP(EDATA, offset) /* Entry data: .offset */ \
> + FETCH_OP(TP_ARG, param) /* Tracepoint argument: .data */\
> + /* Stage 2 (dereference) ops */ \
> + FETCH_OP(DEREF, offset) /* Dereference: .offset */ \
> + FETCH_OP(UDEREF, offset) /* User-space dereference: .offset */\
> + /* Stage 3 (store) ops */ \
> + FETCH_OP(ST_RAW, store) /* Raw value: .size */ \
> + FETCH_OP(ST_MEM, store) /* Memory: .offset, .size */ \
> + FETCH_OP(ST_UMEM, store) /* User memory: .offset, .size */\
> + FETCH_OP(ST_STRING, store) /* String: .offset, .size */ \
> + FETCH_OP(ST_USTRING, store) /* User string: .offset, .size */\
> + FETCH_OP(ST_SYMSTR, store) /* Symbol name: .offset, .size */\
> + FETCH_OP(ST_EDATA, offset) /* Entry data: .offset */ \
> + /* Stage 4 (modify) op */ \
> + FETCH_OP(MOD_BF, bf) /* Bitfield: .basesize, .lshift, .rshift*/\
> + /* Stage 5 (loop) op */ \
> + FETCH_OP(LP_ARRAY, param) /* Loop array: .param = count */\
> + /* End */ \
> + FETCH_OP(END, none) \
> + /* Unresolved Symbol holder */ \
> + FETCH_OP(NOP_SYMBOL, symbol) /* Non loaded symbol: .data = symbol name */
> +
> +#define FETCH_OP(opname, decode_fn) FETCH_OP_##opname,
> enum fetch_op {
> - FETCH_OP_NOP = 0,
> - // Stage 1 (load) ops
> - FETCH_OP_REG, /* Register : .param = offset */
> - FETCH_OP_STACK, /* Stack : .param = index */
> - FETCH_OP_STACKP, /* Stack pointer */
> - FETCH_OP_RETVAL, /* Return value */
> - FETCH_OP_IMM, /* Immediate : .immediate */
> - FETCH_OP_COMM, /* Current comm */
> - FETCH_OP_ARG, /* Function argument : .param */
> - FETCH_OP_FOFFS, /* File offset: .immediate */
> - FETCH_OP_DATA, /* Allocated data: .data */
> - FETCH_OP_EDATA, /* Entry data: .offset */
> - // Stage 2 (dereference) op
> - FETCH_OP_DEREF, /* Dereference: .offset */
> - FETCH_OP_UDEREF, /* User-space Dereference: .offset */
> - // Stage 3 (store) ops
> - FETCH_OP_ST_RAW, /* Raw: .size */
> - FETCH_OP_ST_MEM, /* Mem: .offset, .size */
> - FETCH_OP_ST_UMEM, /* Mem: .offset, .size */
> - FETCH_OP_ST_STRING, /* String: .offset, .size */
> - FETCH_OP_ST_USTRING, /* User String: .offset, .size */
> - FETCH_OP_ST_SYMSTR, /* Kernel Symbol String: .offset, .size */
> - FETCH_OP_ST_EDATA, /* Store Entry Data: .offset */
> - // Stage 4 (modify) op
> - FETCH_OP_MOD_BF, /* Bitfield: .basesize, .lshift, .rshift */
> - // Stage 5 (loop) op
> - FETCH_OP_LP_ARRAY, /* Array: .param = loop count */
> - FETCH_OP_TP_ARG, /* Trace Point argument */
> - FETCH_OP_END,
> - FETCH_NOP_SYMBOL, /* Unresolved Symbol holder */
> + FETCH_OP_LIST
> };
> +#undef FETCH_OP
> +
> +#define FETCH_NOP_SYMBOL FETCH_OP_NOP_SYMBOL
>
> struct fetch_insn {
> enum fetch_op op;
> @@ -370,6 +379,14 @@ bool trace_probe_match_command_args(struct trace_probe *tp,
> int trace_probe_create(const char *raw_command, int (*createfn)(int, const char **));
> int trace_probe_print_args(struct trace_seq *s, struct probe_arg *args, int nr_args,
> u8 *data, void *field);
> +#ifdef CONFIG_PROBE_EVENTS_DUMP_FETCHARG
> +void trace_probe_dump_args(struct seq_file *m, struct trace_probe *tp);
> +#else
> +static inline void trace_probe_dump_args(struct seq_file *m, struct trace_probe *tp)
> +{
> + return;
> +}
> +#endif
>
> #ifdef CONFIG_HAVE_FUNCTION_ARG_ACCESS_API
> int traceprobe_get_entry_data_size(struct trace_probe *tp);
> diff --git a/kernel/trace/trace_uprobe.c b/kernel/trace/trace_uprobe.c
> index c274346853d1..b2e264a4b96c 100644
> --- a/kernel/trace/trace_uprobe.c
> +++ b/kernel/trace/trace_uprobe.c
> @@ -765,6 +765,9 @@ static int trace_uprobe_show(struct seq_file *m, struct dyn_event *ev)
> seq_printf(m, " %s=%s", tu->tp.args[i].name, tu->tp.args[i].comm);
>
> seq_putc(m, '\n');
> +
> + trace_probe_dump_args(m, &tu->tp);
> +
> return 0;
> }
>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marek Vasut @ 2026-06-21 22:46 UTC (permalink / raw)
To: Thomas Gleixner, linux-pci
Cc: Yoshihiro Shimoda, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <87cxxkma5p.ffs@fw13>
On 6/21/26 12:59 PM, Thomas Gleixner wrote:
> On Fri, Jun 19 2026 at 00:02, Marek Vasut wrote:
>> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
>> or APB interface configured to 32 bit, it can therefore access only
>> the first 4 GiB of physical address space. This information comes from
>> R-Car V4H Interface Specification sheet, there is currently no technical
>> update number assigned to this limitation. Further input from hardware
>> engineer indicates that this limitation also applies to R-Car S4 and V4M.
>> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
>> limitation.
>>
>> The quirk is keyed on the combination of the GIC implementation
>> and the platform identification in the device tree.
>>
>> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
>> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
>
> This SOB chain is broken.
Broken ? I don't understand , could you please elaborate ?
Should I sort this alphabetically or is that something else ?
Thank you for your help !
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Conor Dooley @ 2026-06-21 18:35 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Nuno Sá, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <20260621153330.79b6600c@jic23-huawei>
[-- Attachment #1: Type: text/plain, Size: 15710 bytes --]
On Sun, Jun 21, 2026 at 03:33:40PM +0100, Jonathan Cameron wrote:
> On Fri, 19 Jun 2026 16:54:11 +0100
> Nuno Sá <noname.nuno@gmail.com> wrote:
>
> > On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > > >
> > > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > > >
> > > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > > integrated precision reference.
> > > > > > > > > > ...
> > > > > > > > > > Probably others may comment on that, but...
> > > > > > > > > >
> > > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > > >
> > > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > > +
> > > > > > > > > > > +patternProperties:
> > > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > > + type: object
> > > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > > +
> > > > > > > > > > > + properties:
> > > > > > > > > > > + reg:
> > > > > > > > > > > + description: Channel number.
> > > > > > > > > > > + minimum: 0
> > > > > > > > > > > + maximum: 15
> > > > > > > > > > > +
> > > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > > + description: |
> > > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > > + oneOf:
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: 0
> > > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -5000000
> > > > > > > > > > > + - const: 5000000
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -10000000
> > > > > > > > > > > + - const: 10000000
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -15000000
> > > > > > > > > > > + - const: 15000000
> > > > > > > > > > > + - items:
> > > > > > > > > > > + - const: -20000000
> > > > > > > > > > > + - const: 20000000
> > > > > > > > > > > +
> > > > > > > > > > > + required:
> > > > > > > > > > > + - reg
> > > > > > > > > > > +
> > > > > > > > > > > + additionalProperties: false
> > > > > > > > > > > +
> > > > > > > > > > > +required:
> > > > > > > > > > > + - compatible
> > > > > > > > > > > + - reg
> > > > > > > > > > > + - vdd-supply
> > > > > > > > > > > + - avdd-supply
> > > > > > > > > > > + - hvdd-supply
> > > > > > > > > > > +
> > > > > > > > > > > +dependencies:
> > > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > > +
> > > > > > > > > > > +allOf:
> > > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > > +
> > > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > > +
> > > > > > > > > > > +examples:
> > > > > > > > > > > + - |
> > > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > > +
> > > > > > > > > > > + spi {
> > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > +
> > > > > > > > > > > + dac@0 {
> > > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > > +
> > > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > > +
> > > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > > +
> > > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > > +
> > > > > > > > > > > + channel@0 {
> > > > > > > > > > > + reg = <0>;
> > > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > > + };
> > > > > > > > > > > +
> > > > > > > > > > > + channel@1 {
> > > > > > > > > > > + reg = <1>;
> > > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > > + };
> > > > > > > > > > > +
> > > > > > > > > > > + channel@2 {
> > > > > > > > > > > + reg = <2>;
> > > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > > + };
> > > > > > > > > > > + };
> > > > > > > > > > > + };
> > > > > > > > > > ...
> > > > > > > > > >
> > > > > > > > > > spi {
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > multi-dac@0 {
> > > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > > reg = <0>;
> > > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > > >
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > dac@0 {
> > > > > > > > > > reg = <0>;
> > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > >
> > > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > >
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > channel@0 {
> > > > > > > > > > reg = <0>;
> > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > channel@1 {
> > > > > > > > > > reg = <1>;
> > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > channel@2 {
> > > > > > > > > > reg = <2>;
> > > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > };
> > > > > > > > > > }
> > > > > > > > > >
> > > > > > > > > > dac@1 {
> > > > > > > > > > reg = <1>;
> > > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > > >
> > > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > > >
> > > > > > > > > > #address-cells = <1>;
> > > > > > > > > > #size-cells = <0>;
> > > > > > > > > >
> > > > > > > > > > channel@0 {
> > > > > > > > > > reg = <0>;
> > > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > channel@1 {
> > > > > > > > > > reg = <1>;
> > > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > };
> > > > > > > > > > }
> > > > > > > > > > };
> > > > > > > > > > };
> > > > > > > > > >
> > > > > > > > > > then you might need something like:
> > > > > > > > > >
> > > > > > > > > > patternProperties:
> > > > > > > > > > "^dac@[0-3]$":
> > > > > > > > > >
> > > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > > >
> > > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > > >
> > > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > > Hi Rodrigo,
> > > > > > > > >
> > > > > > > > > Thank you for looking at this.
> > > > > > > > >
> > > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > > speculatively without a validating use case.
> > > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > > >
> > > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > > in all devices in the chain as one big SPI message.
> > > > > > > >
> > > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > > longer term how to support it cleanly in SPI.
> > > > > >
> > > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > > see if I can find what I am thinking of...
> > > > >
> > > > >
> > > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > > slightly different properties.
> > > > >
> > > > > microchip,device-addr:
> > > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > enum: [0, 1, 2, 3]
> > > > > default: 0
> > > > >
> > > > > and
> > > > >
> > > > >
> > > > > microchip,hw-device-address:
> > > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > > minimum: 0
> > > > > maximum: 3
> > > > > description:
> > > > > The address is set on a per-device basis by fuses in the factory,
> > > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > > The device address is part of the device markings to avoid
> > > > > potential confusion. This address is coded on two bits, so four possible
> > > > > addresses are available when multiple devices are present on the same
> > > > > SPI bus with only one Chip Select line for all devices.
> > > > > Each device communication starts by a CS falling edge, followed by the
> > > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > > which is first one on the wire).
> > > > >
> > > > > This sounds exactly like the sort of feature that you're dealing with
> > > > > here?
> > > > >
> > > >
> > > > The core idea yes but for this chip, things are a bit more annoying (but
> > > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > > have it's own supplies, pins and at the very least, channels with maybe
> > > > different scales. That is why Janani is proposing dac nodes. Given I
> > > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > > about solving this at the spi level.
> > > >
> > > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > > together in the same bus.
> > >
> > > I'm definitely missing something, because that property for the
> > > microchip devices is not impacted what else is on the bus. AFAICT, you
> > > could have an mcp3911 and an mcp3564 on the same bus even though both
> > > are completely different devices with different drivers. They have
> > > individual device nodes and their own supplies etc etc. These aren't
> > > per-channel properties on an adc or dac, they're per child device on a
> > > spi bus.
> >
> > Maybe I'm the one missing something :). IIRC, spi would not allow two
> > devices on the same CS right? Because for this chip we would need
> > something like:
> >
> > spi {
> > dac@0 {
> > reg = <0>;
> > adi,pin-id = <0>;
> > };
> >
> > dac@1 {
> > reg = <0>; // which seems already problematic?
> > adi,pin-id <1>;
> > };
> >
> > ...
> >
> > //up to 4
> > };
> Yeah. It's not clear to me how that works for the microchip devices
> (I suspect it doesn't!)
>
> Just thinking as I type, but could we do something a bit nasty with
> a gpio mux that doesn't actually switch but represents the GPIO being
> shared? Given this is all tied to the spi bus that should all happen
> under serializing locks.
>
> Agreed though that this would be nicer as an SPI thing that let
> us specify that a single CS is share by multiple devices and their
> is some other signal acting to select which one we are talking to.
Whether it works or not, I think it is the more correct approach. Messing
with gpio muxes seems completely wrong, given the chip select may not be
a gpio at all.
Why do you think the microchip devices won't work? Does the spi core
reject multiple devices with the same chip select being registered or
something like that?
Certainly seems like an opportunity though to do something common
property wise, if both ADI and Microchip are trying to do the same thing
here with multiple users of the same chip select.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Marc Zyngier @ 2026-06-21 17:00 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-4-marek.vasut+renesas@mailbox.org>
On Thu, 18 Jun 2026 23:02:01 +0100,
Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>
> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> or APB interface configured to 32 bit, it can therefore access only
> the first 4 GiB of physical address space. This information comes from
> R-Car V4H Interface Specification sheet, there is currently no technical
> update number assigned to this limitation. Further input from hardware
> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> limitation.
>
> The quirk is keyed on the combination of the GIC implementation
> and the platform identification in the device tree.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
With the SoB chain issue addressed:
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v2 2/4] irqchip/gic-v3: Refactor GIC600 limited to 32bit PA erratum handling
From: Marc Zyngier @ 2026-06-21 16:59 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-pci, Krzysztof Wilczyński, Bjorn Helgaas,
Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Rob Herring, Yoshihiro Shimoda, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-3-marek.vasut+renesas@mailbox.org>
On Thu, 18 Jun 2026 23:02:00 +0100,
Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
>
> The GIC600 implementation is now known to be used on multiple 64-bit
> SoCs, where it has address width for AXI or APB interface configured
> to 32 bit, and it can access only the first 4GiB of physical address
> space.
>
> Rework the handling of the quirk to work around this limitation such
> that new entries can be added purely as new compatible strings, with
> no need to add additional functions or new its_quirk array entries.
>
> Suggested-by: Marc Zyngier <maz@kernel.org>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Acked-by: Marc Zyngier <maz@kernel.org>
M.
--
Without deviation from the norm, progress is not possible.
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Jonathan Cameron @ 2026-06-21 14:33 UTC (permalink / raw)
To: Nuno Sá
Cc: Conor Dooley, Janani Sunil, Rodrigo Alencar, Janani Sunil,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
linux-iio, devicetree, linux-kernel, linux-doc, Mark Brown
In-Reply-To: <ajVlD-j0nIGrRVow@nsa>
On Fri, 19 Jun 2026 16:54:11 +0100
Nuno Sá <noname.nuno@gmail.com> wrote:
> On Fri, Jun 19, 2026 at 03:12:07PM +0100, Conor Dooley wrote:
> > On Fri, Jun 19, 2026 at 02:01:08PM +0100, Nuno Sá wrote:
> > > On Fri, Jun 19, 2026 at 12:40:54PM +0100, Conor Dooley wrote:
> > > > On Fri, Jun 19, 2026 at 12:36:55PM +0100, Conor Dooley wrote:
> > > > > On Fri, Jun 19, 2026 at 12:33:11PM +0200, Janani Sunil wrote:
> > > > > >
> > > > > > On 6/14/26 21:44, Jonathan Cameron wrote:
> > > > > > > On Tue, 9 Jun 2026 16:47:23 +0200
> > > > > > > Janani Sunil <jan.sun97@gmail.com> wrote:
> > > > > > >
> > > > > > > > On 5/26/26 15:11, Rodrigo Alencar wrote:
> > > > > > > > > On 26/05/19 05:42PM, Janani Sunil wrote:
> > > > > > > > > > Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
> > > > > > > > > > buffered voltage output digital-to-analog converter (DAC) with an
> > > > > > > > > > integrated precision reference.
> > > > > > > > > ...
> > > > > > > > > Probably others may comment on that, but...
> > > > > > > > >
> > > > > > > > > This parent node may support device addressing for multi-device support through
> > > > > > > > > those ID pins. I suppose that each device may have its own power supplies or
> > > > > > > > > other resources like the toggle pins or reset and enable.
> > > > > > > > >
> > > > > > > > > That way I suppose that an example would look like...
> > > > > > > > > > +
> > > > > > > > > > +patternProperties:
> > > > > > > > > > + "^channel@([0-9]|1[0-5])$":
> > > > > > > > > > + type: object
> > > > > > > > > > + description: Child nodes for individual channel configuration
> > > > > > > > > > +
> > > > > > > > > > + properties:
> > > > > > > > > > + reg:
> > > > > > > > > > + description: Channel number.
> > > > > > > > > > + minimum: 0
> > > > > > > > > > + maximum: 15
> > > > > > > > > > +
> > > > > > > > > > + adi,output-range-microvolt:
> > > > > > > > > > + description: |
> > > > > > > > > > + Output voltage range for this channel as [min, max] in microvolts.
> > > > > > > > > > + If not specified, defaults to 0V to 5V range.
> > > > > > > > > > + oneOf:
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: 0
> > > > > > > > > > + - enum: [5000000, 10000000, 20000000, 40000000]
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: -5000000
> > > > > > > > > > + - const: 5000000
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: -10000000
> > > > > > > > > > + - const: 10000000
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: -15000000
> > > > > > > > > > + - const: 15000000
> > > > > > > > > > + - items:
> > > > > > > > > > + - const: -20000000
> > > > > > > > > > + - const: 20000000
> > > > > > > > > > +
> > > > > > > > > > + required:
> > > > > > > > > > + - reg
> > > > > > > > > > +
> > > > > > > > > > + additionalProperties: false
> > > > > > > > > > +
> > > > > > > > > > +required:
> > > > > > > > > > + - compatible
> > > > > > > > > > + - reg
> > > > > > > > > > + - vdd-supply
> > > > > > > > > > + - avdd-supply
> > > > > > > > > > + - hvdd-supply
> > > > > > > > > > +
> > > > > > > > > > +dependencies:
> > > > > > > > > > + spi-cpha: [ spi-cpol ]
> > > > > > > > > > + spi-cpol: [ spi-cpha ]
> > > > > > > > > > +
> > > > > > > > > > +allOf:
> > > > > > > > > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > > > > > > > > +
> > > > > > > > > > +unevaluatedProperties: false
> > > > > > > > > > +
> > > > > > > > > > +examples:
> > > > > > > > > > + - |
> > > > > > > > > > + #include <dt-bindings/gpio/gpio.h>
> > > > > > > > > > +
> > > > > > > > > > + spi {
> > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > +
> > > > > > > > > > + dac@0 {
> > > > > > > > > > + compatible = "adi,ad5529r-16";
> > > > > > > > > > + reg = <0>;
> > > > > > > > > > + spi-max-frequency = <25000000>;
> > > > > > > > > > +
> > > > > > > > > > + vdd-supply = <&vdd_regulator>;
> > > > > > > > > > + avdd-supply = <&avdd_regulator>;
> > > > > > > > > > + hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > > + hvss-supply = <&hvss_regulator>;
> > > > > > > > > > +
> > > > > > > > > > + reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > > > +
> > > > > > > > > > + #address-cells = <1>;
> > > > > > > > > > + #size-cells = <0>;
> > > > > > > > > > +
> > > > > > > > > > + channel@0 {
> > > > > > > > > > + reg = <0>;
> > > > > > > > > > + adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > > + };
> > > > > > > > > > +
> > > > > > > > > > + channel@1 {
> > > > > > > > > > + reg = <1>;
> > > > > > > > > > + adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > > + };
> > > > > > > > > > +
> > > > > > > > > > + channel@2 {
> > > > > > > > > > + reg = <2>;
> > > > > > > > > > + adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > > + };
> > > > > > > > > > + };
> > > > > > > > > > + };
> > > > > > > > > ...
> > > > > > > > >
> > > > > > > > > spi {
> > > > > > > > > #address-cells = <1>;
> > > > > > > > > #size-cells = <0>;
> > > > > > > > >
> > > > > > > > > multi-dac@0 {
> > > > > > > > > compatible = "adi,ad5529r-16";
> > > > > > > > > reg = <0>;
> > > > > > > > > spi-max-frequency = <25000000>;
> > > > > > > > >
> > > > > > > > > #address-cells = <1>;
> > > > > > > > > #size-cells = <0>;
> > > > > > > > >
> > > > > > > > > dac@0 {
> > > > > > > > > reg = <0>;
> > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > >
> > > > > > > > > reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
> > > > > > > > >
> > > > > > > > > #address-cells = <1>;
> > > > > > > > > #size-cells = <0>;
> > > > > > > > >
> > > > > > > > > channel@0 {
> > > > > > > > > reg = <0>;
> > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > channel@1 {
> > > > > > > > > reg = <1>;
> > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > channel@2 {
> > > > > > > > > reg = <2>;
> > > > > > > > > adi,output-range-microvolt = <0 40000000>;
> > > > > > > > > };
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > dac@1 {
> > > > > > > > > reg = <1>;
> > > > > > > > > vdd-supply = <&vdd_regulator>;
> > > > > > > > > avdd-supply = <&avdd_regulator>;
> > > > > > > > > hvdd-supply = <&hvdd_regulator>;
> > > > > > > > > hvss-supply = <&hvss_regulator>;
> > > > > > > > >
> > > > > > > > > reset-gpios = <&gpio0 88 GPIO_ACTIVE_LOW>;
> > > > > > > > >
> > > > > > > > > #address-cells = <1>;
> > > > > > > > > #size-cells = <0>;
> > > > > > > > >
> > > > > > > > > channel@0 {
> > > > > > > > > reg = <0>;
> > > > > > > > > adi,output-range-microvolt = <0 5000000>;
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > channel@1 {
> > > > > > > > > reg = <1>;
> > > > > > > > > adi,output-range-microvolt = <(-10000000) 10000000>;
> > > > > > > > > };
> > > > > > > > > }
> > > > > > > > > };
> > > > > > > > > };
> > > > > > > > >
> > > > > > > > > then you might need something like:
> > > > > > > > >
> > > > > > > > > patternProperties:
> > > > > > > > > "^dac@[0-3]$":
> > > > > > > > >
> > > > > > > > > and put most of the things under this node pattern.
> > > > > > > > >
> > > > > > > > > So the main driver that you're putting together might need to handle up to four instances.
> > > > > > > > > Even if your current driver cannot handle this, the dt-bindings might need cover that.
> > > > > > > > >
> > > > > > > > > Need to double check if each dac node needs a separate compatible, so you would maybe populate
> > > > > > > > > a platform data to be shared with the child nodes, which would be a separate driver.
> > > > > > > > > (not sure if it would make sense to mix and match ad5529r-16 and ad5529r-12).
> > > > > > > > Hi Rodrigo,
> > > > > > > >
> > > > > > > > Thank you for looking at this.
> > > > > > > >
> > > > > > > > For now, I would prefer to keep the binding scoped to a single AD5529R device instance. The current
> > > > > > > > hardware/use case we have only needs one device node and the driver is written around that model as well.
> > > > > > > > While the device addressing pins could allow multi-device topology, we do not have an actual platform using
> > > > > > > > that configuration at the moment, so I would prefer not to introduce an extra parent/child binding structure
> > > > > > > > speculatively without a validating use case.
> > > > > > > Interesting feature - kind of similar to address control on a typical i2c bus device, or
> > > > > > > looking at it another way a kind of distributed SPI mux.
> > > > > > >
> > > > > > > Challenge of a binding is we need to anticipate the future. So I think we do need something
> > > > > > > like Rodrigo is suggesting even if we only (for now) support a single instance in the driver.
> > > > > > > That would leave the path open to supporting the addressing at a later date.
> > > > > > > An alternative might be to look at it like a chained device setup. In those we pretend there
> > > > > > > is just one device with a lot of channels etc. The snag is that here things are more loosely
> > > > > > > coupled whereas for those devices it tends to be you have to read / write the same register
> > > > > > > in all devices in the chain as one big SPI message.
> > > > > > >
> > > > > > > +CC Mark Brown as he may know of some precedence for this feature. For his reference..
> > > > > > > - Each of these device has 2 ID pins. The SPI transfers have to contain the 2 bit
> > > > > > > value that matches that or they are ignored. Thus a single bus + 1 chip select can
> > > > > > > be used to talk to 4 devices. Question is what that looks like in device tree + I guess
> > > > > > > longer term how to support it cleanly in SPI.
> > > > >
> > > > > I'd swear I have seen this before, from some Microchip devices. Let me
> > > > > see if I can find what I am thinking of...
> > > >
> > > >
> > > > microchip,mcp3911 and microchip,mcp3564 both seem to do this with
> > > > slightly different properties.
> > > >
> > > > microchip,device-addr:
> > > > description: Device address when multiple MCP3911 chips are present on the same SPI bus.
> > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > enum: [0, 1, 2, 3]
> > > > default: 0
> > > >
> > > > and
> > > >
> > > >
> > > > microchip,hw-device-address:
> > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > minimum: 0
> > > > maximum: 3
> > > > description:
> > > > The address is set on a per-device basis by fuses in the factory,
> > > > configured on request. If not requested, the fuses are set for 0x1.
> > > > The device address is part of the device markings to avoid
> > > > potential confusion. This address is coded on two bits, so four possible
> > > > addresses are available when multiple devices are present on the same
> > > > SPI bus with only one Chip Select line for all devices.
> > > > Each device communication starts by a CS falling edge, followed by the
> > > > clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
> > > > which is first one on the wire).
> > > >
> > > > This sounds exactly like the sort of feature that you're dealing with
> > > > here?
> > > >
> > >
> > > The core idea yes but for this chip, things are a bit more annoying (but
> > > Janani can correct me if I'm wrong). Here, each device can, in theory,
> > > have it's own supplies, pins and at the very least, channels with maybe
> > > different scales. That is why Janani is proposing dac nodes. Given I
> > > honestly don't like much of that "adi,ad5529r-bus" compatible I wondered
> > > about solving this at the spi level.
> > >
> > > Ah and to make it more annoying, we can also mix 12 and 16 bits variants
> > > together in the same bus.
> >
> > I'm definitely missing something, because that property for the
> > microchip devices is not impacted what else is on the bus. AFAICT, you
> > could have an mcp3911 and an mcp3564 on the same bus even though both
> > are completely different devices with different drivers. They have
> > individual device nodes and their own supplies etc etc. These aren't
> > per-channel properties on an adc or dac, they're per child device on a
> > spi bus.
>
> Maybe I'm the one missing something :). IIRC, spi would not allow two
> devices on the same CS right? Because for this chip we would need
> something like:
>
> spi {
> dac@0 {
> reg = <0>;
> adi,pin-id = <0>;
> };
>
> dac@1 {
> reg = <0>; // which seems already problematic?
> adi,pin-id <1>;
> };
>
> ...
>
> //up to 4
> };
Yeah. It's not clear to me how that works for the microchip devices
(I suspect it doesn't!)
Just thinking as I type, but could we do something a bit nasty with
a gpio mux that doesn't actually switch but represents the GPIO being
shared? Given this is all tied to the spi bus that should all happen
under serializing locks.
Agreed though that this would be nicer as an SPI thing that let
us specify that a single CS is share by multiple devices and their
is some other signal acting to select which one we are talking to.
Jonathan
>
> - Nuno Sá
>
>
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Move non-trace_printk prototypes back to kernel.h
From: Steven Rostedt @ 2026-06-21 13:24 UTC (permalink / raw)
To: Yury Norov, Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <ajfiVTlCIVlqW3sh@yury>
On June 21, 2026 2:08:37 PM GMT+01:00, Yury Norov <yury.norov@gmail.com> wrote:
>On Sun, Jun 21, 2026 at 05:34:31AM -0400, Steven Rostedt wrote:
>> From: Steven Rostedt <rostedt@goodmis.org>
>>
>> In order to remove the include to trace_printk.h from kernel.h the tracing
>> control prototypes need to be moved back into kernel.h. That's because
>
>Please don't. Instead, you can split them out to trace_control.h, and
>include where needed. I actually have a prototype for it, FYI:
>
>https://github.com/norov/linux/tree/trace_pritk3
>
Sure, I have no problem adding another header for this.
>> they are used in other common header files like rcu.h. There's no point in
>> removing trace_printk.h from kernel.h if it just gets added back to other
>> common headers.
>>
>> Prototypes are very cheap for the compiler and should not be an issue.
>
>It's not about cost, it's about mess. kernel.h is included everywhere.
>Is that API needed everywhere? No, it's needed in literally 10 files.
>So, no place in kernel.h.
>
Well one of those files is rcu.h which is also pretty much included everywhere. But OK.
-- Steve
>>
>> 2.53.0
>>
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Yury Norov @ 2026-06-21 13:57 UTC (permalink / raw)
To: Yury Norov
Cc: Steven Rostedt, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, linux-doc,
linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <ajfphe4Z8BrfYoUX@yury>
On Sun, Jun 21, 2026 at 09:39:17AM -0400, Yury Norov wrote:
> On Sun, Jun 21, 2026 at 05:47:21AM -0400, Steven Rostedt wrote:
> > On Sun, 21 Jun 2026 05:34:32 -0400
> > Steven Rostedt <rostedt@kernel.org> wrote:
> >
> > > Instead of having trace_printk.h included in kernel.h, create a config
> > > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> > > Makefile to allow developers to add trace_printk() without the need to add
> > > the include for it. Having it included in the Makefile keeps it from being
> > > in the dependency chain and it will not waste extra CPU cycles for those
> > > building the kernel without using trace_printk.
> >
> > Bah, I only tested with the config option enabled, and missed some
> > dependencies with it disabled.
>
> Yes you did.
>
> > For instance, rcu.h also uses ftrace_dump() so that too needs to go
> > into kernel.h.
>
> No, it shouldn't.
>
> > I also need to add a few more includes to trace_printk.h.
>
> > OK, I need to run this through all my tests to find where else I missed
> > adding the includes. But the idea should hopefully satisfy everyone.
>
> If you include it under config in kernel.h, to make the kernel buildable,
I mean: in kernel.h or in Makefile.
> you need to include trace_printk.h explicitly where it's actually used.
> IOW, apply my patch v4-7.
>
> Then, developers who use trace_printk() on their development machine,
> will be really frustrated when their debugging code will break client
> build just because CONFIG_TRACE_PRINTK_DEBUGGING is disabled there.
> They will spend a day, at best, communicating with remote managers,
> and end up with adding #include <linux/trace_printk.h> in the files
> they touch. Is that your plan?
>
> If I was one of those developers, the solution would be simple for me:
> don't use trace_printk() at all.
>
> Thanks,
> Yury
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Yury Norov @ 2026-06-21 13:39 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621054721.7cde38f0@fedora>
On Sun, Jun 21, 2026 at 05:47:21AM -0400, Steven Rostedt wrote:
> On Sun, 21 Jun 2026 05:34:32 -0400
> Steven Rostedt <rostedt@kernel.org> wrote:
>
> > Instead of having trace_printk.h included in kernel.h, create a config
> > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> > Makefile to allow developers to add trace_printk() without the need to add
> > the include for it. Having it included in the Makefile keeps it from being
> > in the dependency chain and it will not waste extra CPU cycles for those
> > building the kernel without using trace_printk.
>
> Bah, I only tested with the config option enabled, and missed some
> dependencies with it disabled.
Yes you did.
> For instance, rcu.h also uses ftrace_dump() so that too needs to go
> into kernel.h.
No, it shouldn't.
> I also need to add a few more includes to trace_printk.h.
> OK, I need to run this through all my tests to find where else I missed
> adding the includes. But the idea should hopefully satisfy everyone.
If you include it under config in kernel.h, to make the kernel buildable,
you need to include trace_printk.h explicitly where it's actually used.
IOW, apply my patch v4-7.
Then, developers who use trace_printk() on their development machine,
will be really frustrated when their debugging code will break client
build just because CONFIG_TRACE_PRINTK_DEBUGGING is disabled there.
They will spend a day, at best, communicating with remote managers,
and end up with adding #include <linux/trace_printk.h> in the files
they touch. Is that your plan?
If I was one of those developers, the solution would be simple for me:
don't use trace_printk() at all.
Thanks,
Yury
^ permalink raw reply
* [PATCH v2 2/2] docs/zh_CN: update sphinx.rst translation
From: Jiandong Qiu @ 2026-06-21 13:12 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260621131215.1303439-1-qiujiandong1998@gmail.com>
Update the zh_CN translation of doc-guide/sphinx.rst.
Update this translation through commit f1c2db1f145b
("docs: move test_doc_build.py to tools/docs")
- clean up the file header anchor `_sphinxdoc_zh`
- sync the Chinese translation with the current Sphinx build requirements
- add sections on HTML math rendering and minimum-version testing
- refresh guidance for tables, cross-references, and commit references
Assisted-by: Codex:GPT-5.4
Signed-off-by: Jiandong Qiu <qiujiandong1998@gmail.com>
---
.../translations/zh_CN/doc-guide/sphinx.rst | 167 ++++++++++++++----
1 file changed, 133 insertions(+), 34 deletions(-)
diff --git a/Documentation/translations/zh_CN/doc-guide/sphinx.rst b/Documentation/translations/zh_CN/doc-guide/sphinx.rst
index 3375c6f3a811..11e846fc97e4 100644
--- a/Documentation/translations/zh_CN/doc-guide/sphinx.rst
+++ b/Documentation/translations/zh_CN/doc-guide/sphinx.rst
@@ -1,10 +1,11 @@
+.. SPDX-License-Identifier: GPL-2.0
.. include:: ../disclaimer-zh_CN.rst
:Original: Documentation/doc-guide/sphinx.rst
-:译者: 吴想成 Wu XiangCheng <bobwxc@email.cn>
-
-.. _sphinxdoc_zh:
+:译者:
+ - 吴想成 Wu XiangCheng <bobwxc@email.cn>
+ - 裘剑东 Jiandong Qiu <qiujiandong1998@gmail.com>
简介
====
@@ -14,7 +15,7 @@ Linux内核使用 `Sphinx <http://www.sphinx-doc.org/>`_ 来把 ``Documentation`
换成漂亮的文档。使用 ``make htmldocs`` 或 ``make pdfdocs`` 命令即可构建HTML
或PDF格式的文档。生成的文档放在 ``Documentation/output`` 文件夹中。
-reStructuredText文件可能包含包含来自源文件的结构化文档注释或kernel-doc注释。
+reStructuredText文件可能包含来自源文件的结构化文档注释或kernel-doc注释。
通常它们用于描述代码的功能、类型和设计。kernel-doc注释有一些特殊的结构和
格式，但除此之外，它们还被作为reStructuredText处理。
@@ -26,7 +27,7 @@ reStructuredText文件可能包含包含来自源文件的结构化文档注释
安装Sphinx
==========
-Documentation/ 下的ReST文件现在使用sphinx1.7或更高版本构建。
+Documentation/ 下的ReST文件现在使用 ``sphinx`` 3.4.3 或更高版本构建。
这有一个脚本可以检查Sphinx的依赖项。更多详细信息见
:ref:`sphinx-pre-install_zh` 。
@@ -38,21 +39,13 @@ Documentation/ 下的ReST文件现在使用sphinx1.7或更高版本构建。
``virtualenv-3`` 或 ``virtualenv`` 在虚拟环境中安装Sphinx，具体取决于发行版
如何打包Python3。
-.. note::
-
- #) html输出建议使用RTD主题。根据Sphinx版本的不同，它应该用
- ``pip install sphinx_rtd_theme`` 单独安装。
+总之，如您要安装最新版的Sphinx，应执行::
- #) 一些ReST页面包含数学表达式。由于Sphinx的工作方式，这些表达式是使用 LaTeX
- 编写的。它需要安装amsfonts和amsmath宏包，以便显示。
+ $ virtualenv sphinx_latest
+ $ . sphinx_latest/bin/activate
+ (sphinx_latest) $ pip install -r Documentation/sphinx/requirements.txt
-总之，如您要安装Sphinx 2.4.4版本，应执行::
-
- $ virtualenv sphinx_2.4.4
- $ . sphinx_2.4.4/bin/activate
- (sphinx_2.4.4) $ pip install -r Documentation/sphinx/requirements.txt
-
-在运行 ``. sphinx_2.4.4/bin/activate`` 之后，提示符将变化，以指示您正在使用新
+在运行 ``. sphinx_latest/bin/activate`` 之后，提示符将变化，以指示您正在使用新
环境。如果您打开了一个新的shell，那么在构建文档之前，您需要重新运行此命令以再
次进入虚拟环境中。
@@ -76,6 +69,23 @@ PDF和LaTeX构建
根据发行版的不同，您可能还需要安装一系列 ``texlive`` 软件包，这些软件包提供了
``XeLaTeX`` 工作所需的最小功能集。
+HTML中的数学表达式
+------------------
+
+有些ReST页面中包含数学表达式。由于Sphinx的工作方式，这些表达式使用LaTeX
+符号书写。Sphinx在HTML输出中渲染数学表达式有两种方式：一种是名为 `imgmath`_
+的扩展，它将数学表达式转换成图像并嵌入到HTML页面中。
+另一种是名为 `mathjax`_ 的扩展，它将数学表达式的渲染交由支持 JavaScript
+的浏览器处理。
+在6.1版内核文档之前，前者是唯一可用的方式，并且需要安装大量texlive软件包，
+其中包括amsfonts和amsmath等。
+
+自内核6.1版本起，无需安装任何texlive软件包即可构建包含数学表达式的HTML
+页面。更多信息请参阅 :ref:`choice_of_math_renderer_zh`。
+
+.. _imgmath: https://www.sphinx-doc.org/en/master/usage/extensions/math.html#module-sphinx.ext.imgmath
+.. _mathjax: https://www.sphinx-doc.org/en/master/usage/extensions/math.html#module-sphinx.ext.mathjax
+
.. _sphinx-pre-install_zh:
检查Sphinx依赖项
@@ -108,7 +118,29 @@ PDF和LaTeX构建
``--no-virtualenv``
- 使用Sphinx的系统打包，而不是Python虚拟环境。
+ 使用系统发行版提供的Sphinx软件包，而不是Python虚拟环境。
+
+安装最小版本的Sphinx
+--------------------
+
+在修改Sphinx构建系统时，确保其最小支持版本仍然可用非常重要。
+然而，在现代发行版上，这样做正变得越来越困难，因为在Python 3.13及以上版本
+环境下，已经无法安装该最小版本。
+
+要按照 Documentation/translations/zh_CN/process/changes.rst
+中定义的最低支持Python版本进行测试，可以使用该版本创建一个虚拟环境，
+并安装最小依赖::
+
+ /usr/bin/python3.9 -m venv sphinx_min
+ . sphinx_min/bin/activate
+ pip install -r Documentation/sphinx/min_requirements.txt
+
+更全面的测试可以使用以下脚本完成:
+
+ tools/docs/test_doc_build.py
+
+该脚本会为每个受支持的Python版本创建一个虚拟环境，并可选择针对一定范围内的
+Sphinx版本构建文档。
Sphinx构建
==========
@@ -117,17 +149,66 @@ Sphinx构建
的格式：请参阅 ``make help`` 的文档部分。生成的文档放在 ``Documentation/output``
下相应格式的子目录中。
-要生成文档，显然必须安装Sphinx（ ``sphinx-build`` ）。要让HTML输出更漂亮，可以
-使用Read the Docs Sphinx主题（ ``sphinx_rtd_theme`` ）。对于PDF输出，您还需要
-``XeLaTeX`` 和来自ImageMagick（https://www.imagemagick.org）的 ``convert(1)`` 。
-所有这些软件在大多发行版中都可用或已打包。
+要生成文档，显然必须安装Sphinx（ ``sphinx-build`` ）。对于PDF输出，您还需
+要 ``XeLaTeX`` 和来自 ImageMagick（https://www.imagemagick.org）的
+``convert(1)`` 。\ [#ink]_ 所有这些软件在各大发行版中都很常见，
+也都有对应的软件包。
要传递额外的选项给Sphinx，可以使用make变量 ``SPHINXOPTS`` 。例如，使用
``make SPHINXOPTS=-v htmldocs`` 获得更详细的输出。
+也可以通过make变量 ``DOCS_CSS`` 传入一个额外的DOCS_CSS覆盖文件，以自定义
+html布局。
+
+默认情况下，构建HTML文档时使用的是"Alabaster"主题；该主题随Sphinx一同提供，
+无需单独安装。也可以通过make变量 ``DOCS_THEME`` 覆盖Sphinx主题。
+
+.. note::
+
+ 有些人可能更喜欢在html输出中使用RTD主题。根据Sphinx版本的不同，它可能需要
+ 单独安装，可使用 ``pip install sphinx_rtd_theme`` 进行安装。
+
+还有一个make变量 ``SPHINXDIRS`` ，在测试构建某个文档子集时很有用。例如，您可
+以通过运行 ``make SPHINXDIRS=doc-guide htmldocs`` 构建
+``Documentation/doc-guide`` 下的文档。 ``make help`` 的文档部分会显示可指定的
+子目录列表。
要删除生成的文档，请运行 ``make cleandocs`` 。
+.. [#ink] 如果还安装了来自 Inkscape（https://inkscape.org）的 ``inkscape(1)`` ，
+ 则能够提升嵌入到PDF文档中的图像质量，尤其是在5.18及之后的内核版本中。
+
+.. _choice_of_math_renderer_zh:
+
+数学渲染器的选择
+----------------
+
+自内核 6.1 版本起， ``mathjax`` 可作为html输出中数学渲染器的后备方案。\ [#sph1_8_zh]_
+
+数学渲染器会根据可用命令按如下方式选择：
+
+.. table:: HTML 中数学渲染器的选择
+
+ ============ ================= ============
+ 数学渲染器 所需命令 图像格式
+ ============ ================= ============
+ imgmath latex, dvipng PNG（栅格）
+ mathjax
+ ============ ================= ============
+
+也可以通过设置环境变量 ``SPHINX_IMGMATH`` 来覆盖该选择，如下所示：
+
+.. table:: 设置 ``SPHINX_IMGMATH`` 的效果
+
+ ====================== ==========
+ 设置 渲染器
+ ====================== ==========
+ ``SPHINX_IMGMATH=yes`` imgmath
+ ``SPHINX_IMGMATH=no`` mathjax
+ ====================== ==========
+
+.. [#sph1_8_zh] 数学渲染器的后备机制要求Sphinx >= 1.8。
+
编写文档
========
@@ -187,7 +268,8 @@ Sphinx构建
~~~~~~~~
尽管RST没有规定具体的顺序（“没有强加一个固定数量和顺序的节标题装饰风格，最终
- 按照的顺序将是实际遇到的顺序。”），但是拥有一个通用级别的文档更容易遵循。
+ 按照的顺序将是实际遇到的顺序。”），但整体上让较高层级的标题样式保持一致，
+ 会更便于阅读和理解文档结构。
* 对于插入固定宽度的文本块（用于代码样例、用例等）： ``::`` 用于语法高亮意义不
大的内容，尤其是短代码段； ``.. code-block:: <language>`` 用于需要语法高亮的
@@ -218,15 +300,24 @@ C域
神奇力量，如果给定函数名的索引项存在，文档构建系统会自动将对 ``function()``
的引用转换为交叉引用。如果在内核文档中看到 ``c:func:`` 的用法，请删除它。
-
-列表
+表格
----
-我们建议使用 *列式表* 格式。 *列式表* 格式是二级列表。与ASCII艺术相比，它们对
-文本文件的读者来说可能没有那么舒适。但其优点是易于创建或修改，而且修改的差异
-（diff）更有意义，因为差异仅限于修改的内容。
+reStructuredText 为表格语法提供了多种选项。内核文档中的表格通常优先使用
+*simple table* 或 *grid table* 语法。更多细节请参阅
+`reStructuredText 用户参考中的表格语法`_ 。
+
+.. _reStructuredText 用户参考中的表格语法:
+ https://docutils.sourceforge.io/docs/user/rst/quickref.html#tables
-*平铺表* 也是一个二级列表，类似于 *列式表* ，但具有一些额外特性：
+列式表
+~~~~~~
+
+列式表（``list-table``）格式对于无法用常规Sphinx ASCII艺术格式轻松排版的表格来说
+可能很有用。然而，这种格式对于纯文本文档的读者来说几乎无法理解，因此，
+除非有充分的理由，否则应避免使用。
+
+``flat-table`` 也是一个二级列表，类似于 ``list-table`` ，但具有一些额外特性：
* 列范围：使用 ``cspan`` 修饰，可以通过其他列扩展单元格
@@ -302,15 +393,15 @@ C域
从一页文档到另一页文档的交叉引用可以通过简单地写出文件路径来完成，无特殊格式
要求。路径可以是绝对路径或相对路径。绝对路径从“Documentation/”开始。例如，要
-交叉引用此页，以下写法皆可，取决于具体的文档目录（注意 ``.rst`` 扩展名是可选
+交叉引用此页，以下写法皆可，取决于具体的文档目录（注意 ``.rst`` 扩展名是必需
的）::
参见 Documentation/doc-guide/sphinx.rst 。此法始终可用。
请查看 sphinx.rst ，仅在同级目录中有效。
请阅读 ../sphinx.rst ，上级目录中的文件。
-如果要使用相对路径，则需要使用Sphinx的 ``doc`` 修饰。例如，从同一目录引用此页
-的操作如下::
+如果希望链接显示的文本不同于文档标题，则需要使用 Sphinx 的 ``doc`` 修饰。例
+如::
参见 :doc:`sphinx文档的自定义链接文本 <sphinx>`.
@@ -318,7 +409,15 @@ C域
个没有任何特殊作用的 ``:doc:`` 用法，请将其转换为文档路径。
有关交叉引用kernel-doc函数或类型的信息，请参阅
-Documentation/doc-guide/kernel-doc.rst 。
+Documentation/translations/zh_CN/doc-guide/kernel-doc.rst 。
+
+引用提交
+~~~~~~~~
+
+对 git 提交的引用如果采用以下格式书写，会自动转换为超链接::
+
+ commit 72bf4f1767f0
+ commit 72bf4f1767f0 ("net: do not leave an empty skb in write queue")
.. _sphinx_kfigure_zh:
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply related
* [PATCH v2 1/2] docs/zh_CN: add process/changes.rst translation
From: Jiandong Qiu @ 2026-06-21 13:12 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
In-Reply-To: <20260621131215.1303439-1-qiujiandong1998@gmail.com>
Add the zh_CN translation of process/changes.rst.
Update this translation through commit ece7e57afd51
("docs: changes.rst and ver_linux: sort the lists")
Assisted-by: Codex:GPT-5.4
Signed-off-by: Jiandong Qiu <qiujiandong1998@gmail.com>
---
.../translations/zh_CN/process/changes.rst | 528 ++++++++++++++++++
1 file changed, 528 insertions(+)
create mode 100644 Documentation/translations/zh_CN/process/changes.rst
diff --git a/Documentation/translations/zh_CN/process/changes.rst b/Documentation/translations/zh_CN/process/changes.rst
new file mode 100644
index 000000000000..62ec7f0e3533
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/changes.rst
@@ -0,0 +1,528 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/process/changes.rst
+
+:翻译: 裘剑东 Jiandong Qiu <qiujiandong1998@gmail.com>
+
+==================
+编译内核的最小需求
+==================
+
+引言
+====
+
+本文旨在给出运行当前内核版本所需的最低软件版本列表。
+
+本文最初基于 Linus 为 2.0.x 内核编写的 “Changes” 文件，因此也应将功劳归于
+与该文件相关的同一批人（Jared Mauch、Axel Boldt、Alessandro Sigala，
+以及互联网上无数其他用户）。
+
+当前最低需求
+------------
+
+在认为自己碰到了一个bug之前，请先至少升级到以下软件版本。
+如果你不确定当前运行的版本，建议使用右侧命令进行检查。
+若要列出系统中的程序及其版本，请执行 ``./scripts/ver_linux``
+
+再次提醒，本列表假定你已经能够正常运行一个Linux内核。另外，
+并非所有工具在所有系统上都是必需的；例如，如果你的机器没有任何
+PC Card硬件，那么大概无需关心 pcmciautils。
+
+====================== =============== ========================================
+ 程序 最低版本 版本检查命令
+====================== =============== ========================================
+bash 4.2 bash --version
+bc 1.06.95 bc --version
+bindgen（可选） 0.65.1 bindgen --version
+binutils 2.30 ld -v
+bison 2.0 bison --version
+btrfs-progs 0.18 btrfs --version
+Clang/LLVM（可选） 15.0.0 clang --version
+e2fsprogs 1.41.4 e2fsck -V
+flex 2.5.35 flex --version
+gdb 7.2 gdb --version
+GNU awk（可选） 5.1.0 gawk --version
+GNU C 8.1 gcc --version
+GNU make 4.0 make --version
+GNU tar 1.28 tar --version
+GRUB 0.93 grub --version || grub-install --version
+gtags（可选） 6.6.5 gtags --version
+iptables 1.4.2 iptables -V
+jfsutils 1.1.3 fsck.jfs -V
+kmod 13 kmod -V
+mcelog 0.6 mcelog --version
+mkimage（可选） 2017.01 mkimage --version
+nfs-utils 1.0.5 showmount --version
+openssl & libcrypto 1.0.0 openssl version
+pahole 1.22 pahole --version
+pcmciautils 004 pccardctl -V
+PPP 2.4.0 pppd --version
+procps 3.2.0 ps --version
+Python 3.9.x python3 --version
+quota-tools 3.09 quota -V
+Rust（可选） 1.78.0 rustc --version
+Sphinx\ [#f1]_ 3.4.3 sphinx-build --version
+squashfs-tools 4.0 mksquashfs -version
+udev 081 udevadm --version
+util-linux 2.10o mount --version
+xfsprogs 2.6.0 xfs_db -V
+====================== =============== ========================================
+
+.. [#f1] Sphinx 仅在构建内核文档时需要
+
+内核编译
+--------
+
+GCC
+~~~
+
+gcc 的版本要求可能会因你计算机中CPU的类型不同而有所变化。
+
+Clang/LLVM（可选）
+~~~~~~~~~~~~~~~~~~
+
+clang和LLVM工具的最新正式发行版（依据
+`releases.llvm.org <https://releases.llvm.org>`_）支持用于构建内核。
+较旧版本并不保证可用，我们也可能移除内核中为支持旧版而加入的兼容性处理。
+更多信息请参阅 Documentation/translations/zh_CN/kbuild/llvm.rst
+
+Rust（可选）
+~~~~~~~~~~~~
+
+需要较新的 Rust 编译器版本。
+
+关于如何满足 Rust 支持的构建需求，请参阅
+Documentation/translations/zh_CN/rust/quick-start.rst。其中，``Makefile`` 目标
+``rustavailable`` 可用于检查 Rust 工具链为何未被检测到。
+
+bindgen（可选）
+~~~~~~~~~~~~~~~
+
+``bindgen`` 用于为内核的 C 侧生成Rust绑定。它依赖 ``libclang``。
+
+Make
+~~~~
+
+要构建内核，你需要 GNU make 4.0 或更高版本。
+
+Bash
+~~~~
+
+内核构建会使用一些 bash 脚本。需要 Bash 4.2 或更新版本。
+
+Binutils
+~~~~~~~~
+
+构建内核需要 Binutils 2.30 或更新版本。
+
+pkg-config
+~~~~~~~~~~
+
+从 Linux 4.18 起，构建系统需要 pkg-config 来检查已安装的 kconfig 工具，并确定用于
+'make {g,x}config' 的标志设置。此前虽然已经在使用 pkg-config，
+但并未进行检查或文档说明。
+
+Flex
+~~~~
+
+自 Linux 4.16 起，构建系统会在构建过程中生成词法分析器。这需要
+flex 2.5.35 或更高版本。
+
+
+Bison
+~~~~~
+
+自 Linux 4.16 起，构建系统会在构建过程中生成语法解析器。这需要 bison 2.0
+或更高版本。
+
+pahole
+~~~~~~
+
+自 Linux 5.2 起，如果选择了 CONFIG_DEBUG_INFO_BTF，构建系统会从 vmlinux 中的
+DWARF 生成 BTF（BPF Type Format），稍后也会为内核模块生成。这需要 pahole
+v1.22 或更高版本。
+
+它可从发行版中的 'dwarves' 或 'pahole' 软件包获得，或从
+https://fedorapeople.org/~acme/dwarves/ 获取。
+
+Perl
+~~~~
+
+要构建内核，你需要 perl 5 以及以下模块：``Getopt::Long``、
+``Getopt::Std``、``File::Basename`` 和 ``File::Find``。
+
+Python
+~~~~~~
+
+若干配置选项需要它：例如 arm/arm64 默认配置、CONFIG_LTO_CLANG、某些
+DRM 可选配置、kernel-doc 工具以及文档构建（Sphinx）等。
+
+BC
+~~
+
+构建 3.10 及以上版本内核时需要 bc。
+
+
+OpenSSL
+~~~~~~~
+
+模块签名和外部证书处理使用OpenSSL程序及其加密库来创建密钥并生成签名。
+
+如果启用了模块签名，那么构建 3.7 及以上版本内核时需要 openssl。构建
+4.3 及以上版本内核时，还需要 openssl 的开发包。
+
+Tar
+~~~
+
+如果你想通过 sysfs 启用对内核头文件的访问（CONFIG_IKHEADERS），则需要 GNU tar。
+
+gtags / GNU GLOBAL（可选）
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+内核构建要求 GNU GLOBAL 版本 6.6.5 或更高，以便通过 ``make gtags``
+生成标签文件。这是因为它使用了 gtags 的 ``-C (--directory)`` 选项。
+
+mkimage
+~~~~~~~
+
+该工具用于构建 Flat Image Tree（FIT），常见于 ARM 平台。该工具可通过
+``u-boot-tools`` 软件包获得，也可以从 U-Boot 源码构建。详见
+https://docs.u-boot.org/en/latest/build/tools.html#building-tools-for-linux
+
+GNU AWK
+~~~~~~~
+
+如果你希望内核构建为内建模块生成地址范围数据（CONFIG_BUILTIN_MODULE_RANGES），
+则需要GNU AWK。
+
+系统工具
+--------
+
+架构方面的变化
+~~~~~~~~~~~~~~
+
+DevFS 已被废弃，转而使用 udev
+（https://www.kernel.org/pub/linux/utils/kernel/hotplug/）
+
+现在已经支持 32 位 UID。尽情享用！
+
+Linux 中函数的文档正在转向以内联文档形式存在，即在源码定义附近使用特殊格式的
+注释。这些注释可以与 Documentation/ 目录中的 ReST 文件结合，生成更丰富的文档，
+随后可以再转换为 PostScript、HTML、LaTex、ePUB 和 PDF 文件。若要将 ReST
+格式转换为你所需的格式，需要Sphinx。
+
+Util-linux
+~~~~~~~~~~
+
+较新的 util-linux 版本为更大容量磁盘提供 ``fdisk`` 支持，支持更多的 mount 选项，
+识别更多分区类型，以及其他类似改进。你大概会想升级它。
+
+Ksymoops
+~~~~~~~~
+
+如果发生了最糟糕的情况，内核出现 oops，你可能需要 ksymoops 工具来解码它，
+但在大多数情况下并不需要。通常更推荐在构建内核时启用 ``CONFIG_KALLSYMS``，
+这样可以产生可直接使用的可读转储（而且输出比 ksymoops 更好）。
+如果由于某种原因你的内核不是以 ``CONFIG_KALLSYMS`` 构建的，
+并且你也没有办法重新构建并在启用该选项的情况下重新复现Oops，
+那么你仍然可以使用 ksymoops 对该 Oops 进行解码。
+
+Mkinitrd
+~~~~~~~~
+
+``/lib/modules`` 文件树布局的这些变化同样要求升级 mkinitrd。
+
+E2fsprogs
+~~~~~~~~~
+
+最新版 ``e2fsprogs`` 修复了 fsck 和 debugfs 中的若干bug。显然，升级它是个好主意。
+
+JFSutils
+~~~~~~~~
+
+``jfsutils`` 软件包包含该文件系统的工具。可用工具如下：
+
+ - ``fsck.jfs`` - 启动事务日志重放，并检查和修复 JFS 格式分区。
+ - ``mkfs.jfs`` - 创建 JFS 格式分区。
+ - 该软件包中还提供了其他文件系统工具。
+
+Xfsprogs
+~~~~~~~~
+
+最新版 ``xfsprogs`` 包含 ``mkfs.xfs``、``xfs_db`` 和 ``xfs_repair`` 等
+XFS文件系统工具。它与架构无关，2.0.0 及以上的任何版本都应能与当前版本的
+XFS内核代码正常配合使用（推荐 2.6.0 或更高版本，因为其包含一些重要改进）。
+
+PCMCIAutils
+~~~~~~~~~~~
+
+PCMCIAutils取代了 ``pcmcia-cs``。它会在系统启动时正确设置 PCMCIA插槽；
+如果内核采用模块化并使用了 hotplug 子系统，它还会为16位PCMCIA设备加载相应模块。
+
+Quota-tools
+~~~~~~~~~~~
+
+如果你想使用较新的 version 2 配额格式，就需要支持 32 位 uid 和 gid。
+Quota-tools 3.07 及更新版本提供了该支持。请使用上表中推荐版本或更新版本。
+
+Intel IA32 微码
+~~~~~~~~~~~~~~~
+
+新增了一个驱动，可用于更新 Intel IA32 微码，并以普通（misc）
+字符设备的形式提供访问。如果你没有使用udev，则在使用前可能需要以root身份执行::
+
+ mkdir /dev/cpu
+ mknod /dev/cpu/microcode c 10 184
+ chmod 0644 /dev/cpu/microcode
+
+你可能还会希望获取用户空间的 microcode_ctl 工具来配合使用。
+
+udev
+~~~~
+
+``udev`` 是一个用户空间程序，用于动态填充 ``/dev``，
+仅为实际存在的设备创建设备节点。``udev`` 替代了 devfs 的基本功能，
+同时允许为设备提供持久化命名。
+
+FUSE
+~~~~
+
+需要 libfuse 2.4.0 或更高版本。绝对最低要求是 2.3.0，但 mount 选项
+``direct_io`` 和 ``kernel_cache`` 将无法工作。
+
+网络
+----
+
+通用变化
+~~~~~~~~
+
+如果你有较复杂的网络配置需求，应该考虑使用 ip-route2 中的网络工具。
+
+包过滤 / NAT
+~~~~~~~~~~~~
+
+数据包过滤和 NAT 代码使用的工具与此前的 2.4.x 内核系列相同（iptables）。
+它仍然包含与 2.2.x 风格 ipchains 以及 2.0.x 风格ipfwadm 的向后兼容模块。
+
+PPP
+~~~
+
+PPP 驱动已经过重构，以支持 multilink 并使其能够运行在多种介质层之上。如
+果你使用 PPP，请将 pppd 至少升级到2.4.0。
+
+如果你没有使用 udev，则必须拥有设备文件 /dev/ppp，可以通过以下命令创建::
+
+ mknod /dev/ppp c 108 0
+
+需要以 root 身份执行。
+
+NFS-utils
+~~~~~~~~~
+
+在很早期的内核（2.4 及更早版本）中，nfs 服务器需要知道哪些客户端希望通
+过 NFS 访问文件。这些信息会在客户端挂载文件系统时由 ``mountd`` 提供
+给内核，或者在系统启动时由 ``exportfs`` 提供。exportfs 会从
+``/var/lib/nfs/rmtab`` 中获取活跃客户端信息。
+
+这种方法相当脆弱，因为它依赖于 rmtab 的正确性，而这并不总是容易保证，
+尤其是在尝试实现故障切换时。即便系统运行正常，``rmtab``
+也会积累大量从未被移除的旧条目。
+
+在现代内核中，我们可以选择让内核在收到未知主机请求时通知 mountd，
+再由 mountd 将合适的导出信息提供给内核。这样就不再依赖 ``rmtab``，
+并且内核只需要知道当前活跃的客户端。
+
+要启用这一新功能，你需要在运行 exportfs 或 mountd 之前执行::
+
+ mount -t nfsd nfsd /proc/fs/nfsd
+
+建议尽可能使用防火墙将所有NFS服务与公共互联网隔离。
+
+mcelog
+~~~~~~
+
+在x86内核上，如果启用了 ``CONFIG_X86_MCE``，则需要 mcelog 工具来处理和
+记录机器检查事件。机器检查事件是CPU报告的错误，强烈建议对其进行处理。
+
+内核文档
+--------
+
+Sphinx
+~~~~~~
+
+关于Sphinx需求的详细信息，请参阅
+Documentation/translations/zh_CN/doc-guide/sphinx.rst 中的 :ref:`sphinx_install_zh`。
+
+rustdoc
+~~~~~~~
+
+``rustdoc`` 用于为 Rust 代码生成文档。更多信息请参阅
+Documentation/translations/zh_CN/rust/general-information.rst。
+
+获取更新的软件
+==============
+
+内核编译
+--------
+
+gcc
+~~~
+
+- <ftp://ftp.gnu.org/gnu/gcc/>
+
+Clang/LLVM
+~~~~~~~~~~
+
+- :ref:`获取 LLVM <zh_cn_getting_llvm>`。
+
+Rust
+~~~~
+
+- Documentation/rust/quick-start.rst。
+
+bindgen
+~~~~~~~
+
+- Documentation/rust/quick-start.rst。
+
+Make
+~~~~
+
+- <ftp://ftp.gnu.org/gnu/make/>
+
+Bash
+~~~~
+
+- <ftp://ftp.gnu.org/gnu/bash/>
+
+Binutils
+~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/devel/binutils/>
+
+Flex
+~~~~
+
+- <https://github.com/westes/flex/releases>
+
+Bison
+~~~~~
+
+- <ftp://ftp.gnu.org/gnu/bison/>
+
+OpenSSL
+~~~~~~~
+
+- <https://www.openssl.org/>
+
+系统工具
+--------
+
+Util-linux
+~~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/util-linux/>
+
+Kmod
+~~~~
+
+- <https://www.kernel.org/pub/linux/utils/kernel/kmod/>
+- <https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git>
+
+Ksymoops
+~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/kernel/ksymoops/v2.4/>
+
+Mkinitrd
+~~~~~~~~
+
+- <https://code.launchpad.net/initrd-tools/main>
+
+E2fsprogs
+~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/>
+- <https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/>
+
+JFSutils
+~~~~~~~~
+
+- <https://jfs.sourceforge.net/>
+
+Xfsprogs
+~~~~~~~~
+
+- <https://git.kernel.org/pub/scm/fs/xfs/xfsprogs-dev.git>
+- <https://www.kernel.org/pub/linux/utils/fs/xfs/xfsprogs/>
+
+Pcmciautils
+~~~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/kernel/pcmcia/>
+
+Quota-tools
+~~~~~~~~~~~
+
+- <https://sourceforge.net/projects/linuxquota/>
+
+
+Intel P6 微码
+~~~~~~~~~~~~~
+
+- <https://downloadcenter.intel.com/>
+
+udev
+~~~~
+
+- <https://www.freedesktop.org/software/systemd/man/udev.html>
+
+FUSE
+~~~~
+
+- <https://github.com/libfuse/libfuse/releases>
+
+mcelog
+~~~~~~
+
+- <https://www.mcelog.org/>
+
+网络
+----
+
+PPP
+~~~
+
+- <https://download.samba.org/pub/ppp/>
+- <https://git.ozlabs.org/?p=ppp.git>
+- <https://github.com/paulusmack/ppp/>
+
+NFS-utils
+~~~~~~~~~
+
+- <https://sourceforge.net/project/showfiles.php?group_id=14>
+- <https://nfs.sourceforge.net/>
+
+Iptables
+~~~~~~~~
+
+- <https://netfilter.org/projects/iptables/index.html>
+
+Ip-route2
+~~~~~~~~~
+
+- <https://www.kernel.org/pub/linux/utils/net/iproute2/>
+
+OProfile
+~~~~~~~~
+
+- <https://oprofile.sf.net/download/>
+
+内核文档
+--------
+
+Sphinx
+~~~~~~
+
+- <https://www.sphinx-doc.org/>
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply related
* [PATCH v2 0/2] docs/zh_CN: update translations for process/changes.rst and sphinx.rst
From: Jiandong Qiu @ 2026-06-21 13:12 UTC (permalink / raw)
To: alexs, si.yanteng
Cc: dzm91, corbet, skhan, linux-doc, linux-kernel, Jiandong Qiu
Hi all,
This series refreshes the translation of doc-guide/sphinx.rst, I noticed
that it refers to process/changes.rst, which did not yet have a zh_CN
translation, so I added one as well.
Changes in v2:
Link: https://lore.kernel.org/linux-doc/20260619140245.1982921-1-qiujiandong1998@gmail.com/
- drop the separate llvm.rst anchor patch
- remove the `_sphinxdoc_zh` anchor from .../zh_CN/doc-guide/sphinx.rst
- add Assisted-by tags
Jiandong Qiu (2):
docs/zh_CN: add process/changes.rst translation
docs/zh_CN: update sphinx.rst translation
.../translations/zh_CN/doc-guide/sphinx.rst | 167 ++++--
.../translations/zh_CN/process/changes.rst | 528 ++++++++++++++++++
2 files changed, 661 insertions(+), 34 deletions(-)
create mode 100644 Documentation/translations/zh_CN/process/changes.rst
--
Jiandong Qiu <qiujiandong1998@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/2] tracing: Move non-trace_printk prototypes back to kernel.h
From: Yury Norov @ 2026-06-21 13:08 UTC (permalink / raw)
To: Steven Rostedt
Cc: linux-kernel, linux-trace-kernel, Masami Hiramatsu, Mark Rutland,
Mathieu Desnoyers, Andrew Morton, Linus Torvalds,
Sebastian Andrzej Siewior, John Ogness, Thomas Gleixner,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621093811.007634476@kernel.org>
On Sun, Jun 21, 2026 at 05:34:31AM -0400, Steven Rostedt wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
>
> In order to remove the include to trace_printk.h from kernel.h the tracing
> control prototypes need to be moved back into kernel.h. That's because
Please don't. Instead, you can split them out to trace_control.h, and
include where needed. I actually have a prototype for it, FYI:
https://github.com/norov/linux/tree/trace_pritk3
> they are used in other common header files like rcu.h. There's no point in
> removing trace_printk.h from kernel.h if it just gets added back to other
> common headers.
>
> Prototypes are very cheap for the compiler and should not be an issue.
It's not about cost, it's about mess. kernel.h is included everywhere.
Is that API needed everywhere? No, it's needed in literally 10 files.
So, no place in kernel.h.
> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
> ---
> include/linux/kernel.h | 18 ++++++++++++++++++
> include/linux/trace_printk.h | 17 -----------------
> 2 files changed, 18 insertions(+), 17 deletions(-)
>
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index e5570a16cbb1..c3c68128827c 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -194,4 +194,22 @@ extern enum system_states system_state;
> # define REBUILD_DUE_TO_DYNAMIC_FTRACE
> #endif
>
> +#ifdef CONFIG_TRACING
> +void tracing_on(void);
> +void tracing_off(void);
> +int tracing_is_on(void);
> +void tracing_snapshot(void);
> +void tracing_snapshot_alloc(void);
> +void tracing_start(void);
> +void tracing_stop(void);
> +#else
> +static inline void tracing_start(void) { }
> +static inline void tracing_stop(void) { }
> +static inline void tracing_on(void) { }
> +static inline void tracing_off(void) { }
> +static inline int tracing_is_on(void) { return 0; }
> +static inline void tracing_snapshot(void) { }
> +static inline void tracing_snapshot_alloc(void) { }
> +#endif
> +
> #endif
> diff --git a/include/linux/trace_printk.h b/include/linux/trace_printk.h
> index 3d54f440dccf..879fed0805fd 100644
> --- a/include/linux/trace_printk.h
> +++ b/include/linux/trace_printk.h
> @@ -35,15 +35,6 @@ enum ftrace_dump_mode {
> };
>
> #ifdef CONFIG_TRACING
> -void tracing_on(void);
> -void tracing_off(void);
> -int tracing_is_on(void);
> -void tracing_snapshot(void);
> -void tracing_snapshot_alloc(void);
> -
> -extern void tracing_start(void);
> -extern void tracing_stop(void);
> -
> static inline __printf(1, 2)
> void ____trace_printk_check_format(const char *fmt, ...)
> {
> @@ -176,16 +167,8 @@ __ftrace_vprintk(unsigned long ip, const char *fmt, va_list ap);
>
> extern void ftrace_dump(enum ftrace_dump_mode oops_dump_mode);
> #else
> -static inline void tracing_start(void) { }
> -static inline void tracing_stop(void) { }
> static inline void trace_dump_stack(int skip) { }
>
> -static inline void tracing_on(void) { }
> -static inline void tracing_off(void) { }
> -static inline int tracing_is_on(void) { return 0; }
> -static inline void tracing_snapshot(void) { }
> -static inline void tracing_snapshot_alloc(void) { }
> -
> static inline __printf(1, 2)
> int trace_printk(const char *fmt, ...)
> {
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 13:03 UTC (permalink / raw)
To: David Laight
Cc: Thomas Gleixner, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621135531.243375d9@pumpkin>
On Sun, 21 Jun 2026 13:55:31 +0100
David Laight <david.laight.linux@gmail.com> wrote:
> Indeed...
> Isn't trace_printk() just an extern?
> Having it defined somewhere isn't going to make any difference to build times.
No it is not. It is a macro to cut as many nanoseconds as possible as
trace_printk() was created to debug tight race conditions and any added
latency can make the race go away.
-- Steve
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: David Laight @ 2026-06-21 12:55 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Steven Rostedt, linux-kernel, linux-trace-kernel,
Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <87ik7cmcb7.ffs@fw13>
On Sun, 21 Jun 2026 12:13:00 +0200
Thomas Gleixner <tglx@kernel.org> wrote:
> On Sun, Jun 21 2026 at 05:34, Steven Rostedt wrote:
> > Instead of having trace_printk.h included in kernel.h, create a config
> > TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> > Makefile to allow developers to add trace_printk() without the need to add
> > the include for it. Having it included in the Makefile keeps it from being
> > in the dependency chain and it will not waste extra CPU cycles for those
> > building the kernel without using trace_printk.
>
> IOW, you make it worse just because.
>
> With the header being separate I add the three trace_printk()s and the
> include to the source file I'm investigating. The recompile will build
> exactly this source file.
>
> Having to enable the config knob will result in a full kernel rebuild
> for no value.
Indeed...
Isn't trace_printk() just an extern?
Having it defined somewhere isn't going to make any difference to build times.
David
>
> Seriously?
>
> Thanks,
>
> tglx
>
>
>
^ permalink raw reply
* Re: [PATCH v2 3/4] irqchip/gic-v3: Add Renesas R-Car Gen4 erratum workaround
From: Thomas Gleixner @ 2026-06-21 10:59 UTC (permalink / raw)
To: Marek Vasut, linux-pci
Cc: Marek Vasut, Yoshihiro Shimoda, Krzysztof Wilczyński,
Bjorn Helgaas, Catalin Marinas, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Lorenzo Pieralisi, Manivannan Sadhasivam,
Marc Zyngier, Rob Herring, devicetree, linux-arm-kernel,
linux-doc, linux-kernel, linux-renesas-soc
In-Reply-To: <20260618220427.14325-4-marek.vasut+renesas@mailbox.org>
On Fri, Jun 19 2026 at 00:02, Marek Vasut wrote:
> Renesas R-Car S4/V4H/V4M GIC600 integration has address width for AXI
> or APB interface configured to 32 bit, it can therefore access only
> the first 4 GiB of physical address space. This information comes from
> R-Car V4H Interface Specification sheet, there is currently no technical
> update number assigned to this limitation. Further input from hardware
> engineer indicates that this limitation also applies to R-Car S4 and V4M.
> Name the limitation GEN4GICITS1, and add a driver quirk to mitigate this
> limitation.
>
> The quirk is keyed on the combination of the GIC implementation
> and the platform identification in the device tree.
>
> Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
This SOB chain is broken.
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 10:38 UTC (permalink / raw)
To: Thomas Gleixner, Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <87ik7cmcb7.ffs@fw13>
On June 21, 2026 11:13:00 AM GMT+01:00, Thomas Gleixner <tglx@kernel.org> wrote:
>On Sun, Jun 21 2026 at 05:34, Steven Rostedt wrote:
>> Instead of having trace_printk.h included in kernel.h, create a config
>> TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
>> Makefile to allow developers to add trace_printk() without the need to add
>> the include for it. Having it included in the Makefile keeps it from being
>> in the dependency chain and it will not waste extra CPU cycles for those
>> building the kernel without using trace_printk.
>
>IOW, you make it worse just because.
>
>With the header being separate I add the three trace_printk()s and the
>include to the source file I'm investigating. The recompile will build
>exactly this source file.
>
>Having to enable the config knob will result in a full kernel rebuild
>for no value.
>
>Seriously?
Like having lockdep enabled, this would always be set in the development environment. It's not something to only enable when you need to add a trace_printk. If you don't want to rebuild everything, by all means add the include file by file. There's nothing preventing you to do that with this solution.
-- Steve
P.S. I'm replying on my phone as I'm in the London Tube. Thus why I'm not trimming my email.
>
>Thanks,
>
> tglx
>
^ permalink raw reply
* Re: [RFC v2 PATCH] reserve_mem: add support for static memory
From: Mike Rapoport @ 2026-06-21 10:36 UTC (permalink / raw)
To: Shyam Saini
Cc: linux-mm, linux-doc, linux-kernel, akpm, tgopinath, bboscaccy,
kees, tony.luck, gpiccoli, bp, rdunlap, peterz, feng.tang,
dapeng1.mi, elver, enelsonmoore, kuba, lirongqing, ebiggers
In-Reply-To: <20260619062331.348789-1-shyamsaini@linux.microsoft.com>
On Thu, Jun 18, 2026 at 11:23:31PM -0700, Shyam Saini wrote:
> reserve_mem relies on dynamic memory allocation, this limits the
> usecase where memory is required to be preserved across the boots.
> Eg: ramoops memory reservation on ACPI platforms
>
> So add support to pass a pre-determined static address and reserve
> memory at a specified location. This enables use case like ramoops
> on ACPI platforms to reliably access ramoops region with previous
> boot logs.
>
> Also skip the parsing of <align> when static address is passed.
>
> Example syntax for static address
> reserve_mem=4M@0x1E0000000:oops
reserve_mem is best effort by design because such hacks as well as memmap=
cannot guarantee this memory is actually free.
If you want to preserve ramoops reliably, use KHO with reserve_mem.
The first kernel will allocate memory, this memory will be preserved by KHO
and could be picked up by the second kernel.
> Signed-off-by: Shyam Saini <shyamsaini@linux.microsoft.com>
> ---
> v1: https://lore.kernel.org/lkml/0eaf3be2-5121-48b7-aeed-196405c0a480@infradead.org/
> v2: Fix code logic and incorporate Randy's suggestion
> ---
> .../admin-guide/kernel-parameters.txt | 15 ++++++
> mm/memblock.c | 47 +++++++++++++------
> 2 files changed, 47 insertions(+), 15 deletions(-)
--
Sincerely yours,
Mike.
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Thomas Gleixner @ 2026-06-21 10:13 UTC (permalink / raw)
To: Steven Rostedt, linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Peter Zijlstra, Julia Lawall, Yury Norov, linux-doc, linux-kbuild,
linuxppc-dev, dri-devel, linux-stm32, linux-arm-kernel,
linux-rdma, linux-usb, linux-ext4, linux-nfs, kvm, intel-gfx
In-Reply-To: <20260621093811.168514984@kernel.org>
On Sun, Jun 21 2026 at 05:34, Steven Rostedt wrote:
> Instead of having trace_printk.h included in kernel.h, create a config
> TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> Makefile to allow developers to add trace_printk() without the need to add
> the include for it. Having it included in the Makefile keeps it from being
> in the dependency chain and it will not waste extra CPU cycles for those
> building the kernel without using trace_printk.
IOW, you make it worse just because.
With the header being separate I add the three trace_printk()s and the
include to the source file I'm investigating. The recompile will build
exactly this source file.
Having to enable the config knob will result in a full kernel rebuild
for no value.
Seriously?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH 2/2] tracing: Add CONFIG_TRACE_PRINTK_DEBUGGING to clean up kernel.h
From: Steven Rostedt @ 2026-06-21 9:47 UTC (permalink / raw)
To: linux-kernel, linux-trace-kernel
Cc: Masami Hiramatsu, Mark Rutland, Mathieu Desnoyers, Andrew Morton,
Linus Torvalds, Sebastian Andrzej Siewior, John Ogness,
Thomas Gleixner, Peter Zijlstra, Julia Lawall, Yury Norov,
linux-doc, linux-kbuild, linuxppc-dev, dri-devel, linux-stm32,
linux-arm-kernel, linux-rdma, linux-usb, linux-ext4, linux-nfs,
kvm, intel-gfx
In-Reply-To: <20260621093811.168514984@kernel.org>
On Sun, 21 Jun 2026 05:34:32 -0400
Steven Rostedt <rostedt@kernel.org> wrote:
> Instead of having trace_printk.h included in kernel.h, create a config
> TRACE_PRINTK_DEBUGGING that when set will update the CFLAGS in the
> Makefile to allow developers to add trace_printk() without the need to add
> the include for it. Having it included in the Makefile keeps it from being
> in the dependency chain and it will not waste extra CPU cycles for those
> building the kernel without using trace_printk.
Bah, I only tested with the config option enabled, and missed some
dependencies with it disabled.
For instance, rcu.h also uses ftrace_dump() so that too needs to go
into kernel.h. I also need to add a few more includes to trace_printk.h.
OK, I need to run this through all my tests to find where else I missed
adding the includes. But the idea should hopefully satisfy everyone.
-- Steve
^ 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