* Re: [PATCH v19 39/40] rust: completion: Add __rust_helper to rust_helper_wait_for_completion()
From: Byungchul Park @ 2026-07-13 3:36 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Gary Guo, linux-kernel, max.byungchul.park, kernel_team, torvalds,
damien.lemoal, linux-ide, adilger.kernel, linux-ext4, mingo,
peterz, will, tglx, rostedt, joel, sashal, daniel.vetter,
duyuyang, johannes.berg, tj, tytso, willy, david, amir73il,
gregkh, kernel-team, linux-mm, akpm, mhocko, minchan, hannes,
vdavydov.dev, sj, jglisse, dennis, cl, penberg, rientjes, vbabka,
ngupta, linux-block, josef, linux-fsdevel, jack, jlayton,
dan.j.williams, hch, djwong, dri-devel, rodrigosiqueiramelo,
melissa.srw, hamohammed.sa, harry.yoo, chris.p.wilson,
gwan-gyeong.mun, boqun.feng, longman, yunseong.kim, ysk,
yeoreum.yun, netdev, matthew.brost, her0gyugyu, corbet,
catalin.marinas, bp, x86, hpa, luto, sumit.semwal, gustavo,
christian.koenig, andi.shyti, arnd, lorenzo.stoakes, Liam.Howlett,
rppt, surenb, mcgrof, petr.pavlu, da.gomez, samitolvanen, paulmck,
frederic, neeraj.upadhyay, joelagnelf, josh, urezki,
mathieu.desnoyers, jiangshanlai, qiang.zhang, juri.lelli,
vincent.guittot, dietmar.eggemann, bsegall, mgorman, vschneid,
chuck.lever, neil, okorniev, Dai.Ngo, tom, trondmy, anna, kees,
bigeasy, clrkwllms, mark.rutland, ada.coupriediaz,
kristina.martsenko, wangkefeng.wang, broonie, kevin.brodsky, dwmw,
shakeel.butt, ast, ziy, yuzhao, baolin.wang, usamaarif642,
joel.granados, richard.weiyang, geert+renesas, tim.c.chen, linux,
alexander.shishkin, lillian, chenhuacai, francesco,
guoweikang.kernel, link, jpoimboe, masahiroy, brauner,
thomas.weissschuh, oleg, mjguzik, andrii, wangfushuai, linux-doc,
linux-arm-kernel, linux-media, linaro-mm-sig, linux-i2c,
linux-arch, linux-modules, rcu, linux-nfs, linux-rt-devel,
2407018371, dakr, neilb, bagasdotme, wsa+renesas, dave.hansen,
geert, ojeda, alex.gaynor, bjorn3_gh, lossin, a.hindborg,
aliceryhl, tmgross, rust-for-linux
In-Reply-To: <CANiq72kEo=bGcHNaSA9JZhv4iuE+YDvu0kN+Z7aopVp3=2C+Wg@mail.gmail.com>
On Sat, Jul 11, 2026 at 02:13:05PM +0200, Miguel Ojeda wrote:
> On Mon, Jul 6, 2026 at 8:22 AM Byungchul Park <byungchul@sk.com> wrote:
> >
> > This is needed to inline these helpers into Rust code, which is required
> > for DEPT to play with wait_for_completion().
> >
> > Signed-off-by: Byungchul Park <byungchul@sk.com>
>
> Apart from what Gary said -- why did you need to do this in a separate
> patch in the same series?
Not necessary. I will make them into one patch. Thanks.
Byungchul
>
> Cheers,
> Miguel
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Dongliang Mu @ 2026-07-13 3:49 UTC (permalink / raw)
To: 葉宸佑, Weijie Yuan
Cc: Alex Shi, Hu Haowen, Jonathan Corbet, Shuah Khan, Dongliang Mu,
linux-doc, linux-kernel, Yuchen Tian, Alex Shi, Yanteng Si
In-Reply-To: <CAKspUhJE-6NN7XnfG0iJAxEiV9PJx6pDbUEU5jgO__+qvuU5ug@mail.gmail.com>
On 7/13/26 10:44 AM, 葉宸佑 wrote:
> Hi Weijie,
>
>> I suspect that some contributors would run the get_maintainers.pl script
>> or b4 prep --auto-to-cc, so they did not cc Alex, as they didn't know
>> the current situation. Because I noticed that for both two versions,
>> Chen-yu didn't cc Alex or Dongliang or Yanteng. Am I right, @Chen-yu? ;-)
> Yes, exactly. For both v1 and v2 I ran get_maintainer.pl, which only
> lists Hu Haowen and the mailing lists for zh_TW files, so Alex and the
> zh_CN team were never on cc.
>
>> Given that this document has not been maintained for ~2 years and these
>> patches to the terminology actually don't have much significance, it
>> might be more appropriate to directly declare the status of Traditional
>> Chinese as "Orphan" provisionally for now, and remove it directly in the
>> near future, until Hao Wen's return and opinion. Or maybe, waiting for a
>> new good soul to take over, which is unpredictable.
> Before it comes to that: I would like to step up and help carry zh_TW
> forward. I am a native zh_TW speaker from Taiwan, and I understand
> this means staying with it, not a one-off effort.
>
> Dongliang, since you kindly offered to help review zh_TW patches:
> would you be open to doing this together -- either as co-maintainers,
> or with me listed as a reviewer (R:) first if that is a more
> reasonable starting point for a newcomer?
Chen-Yu,I would like to serve as co-maintainers to help maintain zh_TW. The
script - tools/docs/checktransupdate.py can seamlessly work on zh_TW.
This can help track the missing changes. But for the current situation
of zh_TW, re-translation may be more efficient.
As discussed with Alex before, maybe zh_TW patches can first go to
Alex's kernel tree and then push to Jon's tree. I am not sure if you are
familar with the maintainer workflow. If not, this solution may be
better for you to learn maintainer workflow.
Dongliang Mu
>
>>> To avoid scattering our efforts, I suggest we minimize fragmentation
>>> as much as possible. When it comes to technical documentation
>>> translation, not literary translation, a straightforward, unadorned,
>>> and free from misunderstandings is the best translation and easy to
>>> maintain. Let's keep thing simple, unless sth is really necessary.
> Alex, I think this concern is fair, and I have no intention of
> forking the translation effort. The scope I have in mind is
> deliberately narrow: keep zh_TW aligned with zh_CN in structure and
> coverage, and localize only where terminology genuinely differs
> (e.g. 軟體 vs 软件, 介面 vs 接口) -- exactly the kind of differences
> you mentioned. Plain, accurate technical translation, no literary
> rewriting.
>
> Weijie, as a first concrete step I will prepare a terminology series
> (rather than one-word-at-a-time patches, as you suggested) covering
> the existing process/ documents, and use it to build a small glossary
> that future patches and reviews can follow.
You can send a zh_TW tree-wide patchset to change them.
>
> Jon, if this direction sounds acceptable, I am happy to send a
> MAINTAINERS patch once the details are settled in this thread.
>
> Thanks,
> Chen-Yu
^ permalink raw reply
* Re: [PATCH v7 10/12] virt/steal_monitor: Provide functions for managing steal values
From: Shrikanth Hegde @ 2026-07-13 5:13 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, mingo, peterz, juri.lelli, vincent.guittot,
yury.norov, kprateek.nayak, iii, corbet, tglx, gregkh, pbonzini,
seanjc, vschneid, huschle, rostedt, dietmar.eggemann, maddy,
srikar, hdanton, chleroy, vineeth, frederic, arighi, pauld,
christian.loehle, tj, tommaso.cucinotta, maz, rafael, rdunlap,
kernellwp, linux-doc
In-Reply-To: <alFPb9lUKCGTN8Ky@yury>
Hi Yury,
On 7/11/26 1:30 AM, Yury Norov wrote:
> On Fri, Jul 10, 2026 at 03:26:46AM +0530, Shrikanth Hegde wrote:
>> Provide functions which is going to be used in the periodic work
>> function to calculate and handle steal time values.
>>
>> get_system_steal_time()
>> - steal monitor takes global view of steal time instead of individual
>> vCPU. For this collect overall steal values across all the vCPUs or
>> vCPUs of interest.
>> - Sum up steal time values across possible CPUs. This helps to keep it
>> a monotonically increasing number and avoids spikes due to CPU
>> hotplug.
>>
>> decrease_preferred_cpus()
>> - Called when there is high steal time. It needs to decide which CPUs to
>> mark as non-preferred and set that state.
>> - Get first housekeeping CPU and its core mask. Mark it as
>> protected core. This helps to keep at least one core as preferred.
>> kernel ensures at least one housekeeping CPU must stay active.
>> - Find the last CPU outside of this protected core mask. (target CPU)
>> - Based on that target CPU, get its sibling and mark them as
>> non-preferred.
>>
>> increase_preferred_cpus()
>> - Called when there is low steal time. It needs to decide which CPUs to
>> mark as preferred and set that state.
>> - Get the first active non-preferred CPUs. This likely is the last
>> set of CPUs being marked as non-preferred.
>> - get the siblings of that CPU and mark them as preferred.
>>
>> get_num_cpus_steal_ratio()
>> - This method informs the steal_monitor core, how many CPUs it needs to
>> consider for steal ratio calculations.
>> - Return number of possible CPUs as get_system_steal_time computes
>> steal values across possible CPUs.
>>
>> Notes:
>> 1. Using core instead of individual CPUs performs better as SMT is
>> quite common and some hypervisor such as powerVM does core scheduling.
>>
>> 2. This doesn't do any NUMA splicing to keep the code simpler and
>> minimal overhead. Current code expects CPUs spread uniformly
>> across NUMA nodes.
>>
>> Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
>> ---
>> v6->v7:
>> - Combined patches which added helper functions.
>> - Use possible CPUs for steal value calculations.
>>
>> drivers/virt/steal_monitor/Makefile | 2 +-
>> drivers/virt/steal_monitor/defaults.c | 100 ++++++++++++++++++++++++++
>> drivers/virt/steal_monitor/sm_core.h | 8 +++
>
> What for do you split functionality into sm_core and default? There's
> no non-default implementation, right?
>
> I'd just put everything in drivers/virt/steal_monitor.c. It would be
> ~300 LOCs file - quite bearable.
Ok. I will move it to sm_core.c
>
>> 3 files changed, 109 insertions(+), 1 deletion(-)
>> create mode 100644 drivers/virt/steal_monitor/defaults.c
>>
>> diff --git a/drivers/virt/steal_monitor/Makefile b/drivers/virt/steal_monitor/Makefile
>> index bd7d120a79b5..273a6dd59fea 100644
>> --- a/drivers/virt/steal_monitor/Makefile
>> +++ b/drivers/virt/steal_monitor/Makefile
>> @@ -3,4 +3,4 @@
>> # Steal time monitor to alter preferred CPU state.
>> obj-$(CONFIG_STEAL_MONITOR) += steal_monitor.o
>>
>> -steal_monitor-y := sm_core.o
>> +steal_monitor-y := sm_core.o defaults.o
>> diff --git a/drivers/virt/steal_monitor/defaults.c b/drivers/virt/steal_monitor/defaults.c
>> new file mode 100644
>> index 000000000000..d4b016317554
>> --- /dev/null
>> +++ b/drivers/virt/steal_monitor/defaults.c
>> @@ -0,0 +1,100 @@
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Base file contains the default implementations.
>> + *
>> + * Copyright (C) 2026 IBM
>> + * Author: Shrikanth Hegde <sshegde@linux.ibm.com>
>> + */
>> +#include "sm_core.h"
>> +
>> +/*
>> + * Returns steal time of the full system.
>> + * Compute collective steal time across all possible CPUs.
>> + */
>> +u64 get_system_steal_time(void)
>> +{
>> + int cpu;
>> + u64 total_steal = 0;
>> +
>> + for_each_possible_cpu(cpu)
>> + total_steal += kcpustat_cpu(cpu).cpustat[CPUTIME_STEAL];
>> +
>> + return total_steal;
>> +}
>> +
>> +/*
>> + * Returns number of CPUs to consider for steal ratio.
>> + * Return possible CPUs.
>> + */
>> +unsigned int get_num_cpus_steal_ratio(void)
>> +{
>> + return num_possible_cpus();
>> +}
>> +
>> +/*
>> + * Take action to decrease preferred CPUs.
>> + *
>> + * Decrease the preferred CPUs by 1 core.
>> + * Take out the last core in the active & preferred.
>> + *
>> + * Must ensure
>> + * - least one housekeeping core is always kept as preferred
>> + * - preferred is always subset of active.
>> + */
>> +void decrease_preferred_cpus(struct steal_monitor *ctx)
>> +{
>> + int tmp_cpu, first_hk_cpu, last_cpu;
>> + const struct cpumask *first_hk_core;
>> + int target_cpu = nr_cpu_ids;
>> +
>> + guard(cpus_read_lock)();
>> + first_hk_cpu = cpumask_first_and(housekeeping_cpumask(HK_TYPE_KERNEL_NOISE),
>> + cpu_preferred_mask);
>
> Nit: you can return here if nothing found, and save on the 2nd
> traverse.
Ok.
I thought about initially, but since this almost never
happens i thought i will combine both.
>
>> + last_cpu = cpumask_last(cpu_preferred_mask);
>> +
>> + if (first_hk_cpu >= nr_cpu_ids || last_cpu >= nr_cpu_ids)
>> + return;
>> +
>> + /* Always leave first housekeeping core as preferred. */
>> + first_hk_core = topology_sibling_cpumask(first_hk_cpu);
>> +
>> + /* Find the last CPU which doesn't belong to that first hk_core. */
>> + if (!cpumask_test_cpu(last_cpu, first_hk_core)) {
>> + target_cpu = last_cpu;
>> + } else {
>> + for_each_cpu_andnot(tmp_cpu, cpu_preferred_mask, first_hk_core)
>> + target_cpu = tmp_cpu;
>> + }
>> +
>> + /* Only the first housekeeping core remains */
>> + if (target_cpu >= nr_cpu_ids)
>> + return;
>> +
>> + for_each_cpu_and(tmp_cpu, topology_sibling_cpumask(target_cpu),
>> + cpu_preferred_mask)
>> + set_cpu_preferred(tmp_cpu, false);
>
> I think it should return status: if the function can't disable CPUs
> now, it would be a good hint for the caller that it would be useless
> to call it again.
>
> You may keep status in struct steal_monitor like:
>
> if (steal_ratio > sm_core_ctx.high_threshold) {
> if (sm_core_ctx->status | CANT_DECREASE) {
> pr_something();
> else
> sm_core_ctx->status = decrease();
>
> It would be a good hint to user that he has the driver misconfigured,
> and save the driver extra work. Same for increase().
>
I thought about the extra work in function, but doesn't happen too often IMO.
Also, it is specially not a misconfiguration for increase.
So i have kept it stateless for the below reason.
- Under typical operation of this driver, user will enable it once.
- Once enabled, user will use their VM as usual.
- Majority of the time the steal time will be less.
- workload are bursty in nature.
- Occasionally many VM will have high utilization and there will be steal time.
This lasts for sometime.
- After workload completes, steal time goes low again.
- Cycle could repeat after extended low steal time duration.
So when the steal time is low, though driver is enabled, doesn't mean it
is mis-configured. Just that there is contention and driver has nothing to
do. So, adding print there could easily consume the console.
Similarly, there could situations, where decrease cannot happen though there is
high steal time, Though they are corner cases.
For example,
- one small/few VMs have not enabled the driver. steal time could be high, but this
VM has already down to one core. It can't decrease any further.
- Though all VMs have enabled the feature, but task running is not FAIR class. Though
steal time shows high.
Hitting only one core or all cores isn't necessarily a misconfiguration.
It is a possible behavior during severe contention or complete idle system.
we need to continuously monitor steal time so that it can expand/contract the
based on current situation. If we stop calling the functions, natural expand/contract
will not happen. There is no interrupt which arrives due to high/low steal time where
we can kick start the driver again. Also it is a difficult ask for user to keep enabling
or disabling the driver.
Since this can be called at minimal once in 10ms, I guess we can incur the additional
overheads to keep the logic simple and stateless. What do you think?
PS: I will remove that additional SM_DIR as you suggested in other reply. That keeps
it all stateless.
>> +}
>> +
>> +/*
>> + * Take action to increase preferred CPUs.
>> + *
>> + * Increase the preferred CPUs by 1 core.
>> + * Add the first core in active & !preferred
>> + *
>> + * Must ensure preferred is subset of active.
>> + */
>> +void increase_preferred_cpus(struct steal_monitor *ctx)
>> +{
>> + int first_cpu, tmp_cpu;
>> +
>> + guard(cpus_read_lock)();
>> + first_cpu = cpumask_first_andnot(cpu_active_mask, cpu_preferred_mask);
>> +
>> + /* All CPUs are preferred. Nothing to increase further */
>> + if (first_cpu >= nr_cpu_ids)
>> + return;
>> +
>> + for_each_cpu_and(tmp_cpu, topology_sibling_cpumask(first_cpu),
>> + cpu_active_mask)
>> + set_cpu_preferred(tmp_cpu, true);
>> +}
>> diff --git a/drivers/virt/steal_monitor/sm_core.h b/drivers/virt/steal_monitor/sm_core.h
>> index 8bbb606add99..ee68cd8b1944 100644
>> --- a/drivers/virt/steal_monitor/sm_core.h
>> +++ b/drivers/virt/steal_monitor/sm_core.h
>> @@ -11,6 +11,9 @@
>> #include <linux/cpumask.h>
>> #include <linux/workqueue.h>
>> #include <linux/ktime.h>
>> +#include <linux/kernel_stat.h>
>> +#include <linux/topology.h>
>> +#include <linux/sched/isolation.h>
>>
>> struct steal_monitor {
>> struct delayed_work work;
>> @@ -24,4 +27,9 @@ struct steal_monitor {
>>
>> extern struct steal_monitor sm_core_ctx;
>>
>> +u64 get_system_steal_time(void);
>> +unsigned int get_num_cpus_steal_ratio(void);
>> +void increase_preferred_cpus(struct steal_monitor *ctx);
>> +void decrease_preferred_cpus(struct steal_monitor *ctx);
>> +
>> #endif /* __VIRT_STEAL_CORE_H */
>> --
>> 2.47.3
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Weijie Yuan @ 2026-07-13 5:33 UTC (permalink / raw)
To: 葉宸佑, Dongliang Mu
Cc: Alex Shi, Hu Haowen, Jonathan Corbet, Shuah Khan, Dongliang Mu,
linux-doc, linux-kernel, Yuchen Tian, Alex Shi, Yanteng Si
In-Reply-To: <CAKspUhJE-6NN7XnfG0iJAxEiV9PJx6pDbUEU5jgO__+qvuU5ug@mail.gmail.com>
On Mon, Jul 13, 2026 at 10:44:12AM +0800, 葉宸佑 wrote:
> Hi Weijie,
>
> > I suspect that some contributors would run the get_maintainers.pl script
> > or b4 prep --auto-to-cc, so they did not cc Alex, as they didn't know
> > the current situation. Because I noticed that for both two versions,
> > Chen-yu didn't cc Alex or Dongliang or Yanteng. Am I right, @Chen-yu? ;-)
>
> Yes, exactly. For both v1 and v2 I ran get_maintainer.pl, which only
> lists Hu Haowen and the mailing lists for zh_TW files, so Alex and the
> zh_CN team were never on cc.
Right, let's note this situation down. We'll deal with it after we come
up with the final solution.
>
> > Given that this document has not been maintained for ~2 years and these
> > patches to the terminology actually don't have much significance, it
> > might be more appropriate to directly declare the status of Traditional
> > Chinese as "Orphan" provisionally for now, and remove it directly in the
> > near future, until Hao Wen's return and opinion. Or maybe, waiting for a
> > new good soul to take over, which is unpredictable.
>
> Before it comes to that: I would like to step up and help carry zh_TW
> forward. I am a native zh_TW speaker from Taiwan, and I understand
> this means staying with it, not a one-off effort.
Nice and thanks. Frankly speaking, At the very beginning, I did consider
saying that I also wanted to take over, and I wished I could. However,
considering that I was certainly not familiar with the traditional
Chinese terms used in Taiwan (although I knew some, that was all), I
finally chose to be speak more conservatively.
> Dongliang, since you kindly offered to help review zh_TW patches:
> would you be open to doing this together -- either as co-maintainers,
> or with me listed as a reviewer (R:) first if that is a more
> reasonable starting point for a newcomer?
Since I was the one who shamelessly initiated this discussion, I
definitely have the obligation to do something. See below...
> > > To avoid scattering our efforts, I suggest we minimize fragmentation
> > > as much as possible. When it comes to technical documentation
> > > translation, not literary translation, a straightforward, unadorned,
> > > and free from misunderstandings is the best translation and easy to
> > > maintain. Let's keep thing simple, unless sth is really necessary.
>
> Alex, I think this concern is fair, and I have no intention of
> forking the translation effort. The scope I have in mind is
> deliberately narrow: keep zh_TW aligned with zh_CN in structure and
> coverage, and localize only where terminology genuinely differs
> (e.g. 軟體 vs 软件, 介面 vs 接口) -- exactly the kind of differences
> you mentioned. Plain, accurate technical translation, no literary
> rewriting.
Exactly, before sending my first email here, I had already thought about
the following approach, what do you think?
* Considering that English documents are changing so rapidly, and even
simplified Chinese cannot keep up with them immediately. I suggest
we start working on catching up with simplified Chinese right now,
which seems like a good place to begin. (ok... seems exactly what you said ;-)
> Weijie, as a first concrete step I will prepare a terminology series
> (rather than one-word-at-a-time patches, as you suggested) covering
> the existing process/ documents, and use it to build a small glossary
> that future patches and reviews can follow.
I used to read this:
https://zh.wikibooks.org/wiki/%E5%A4%A7%E9%99%86%E5%8F%B0%E6%B9%BE%E8%AE%A1%E7%AE%97%E6%9C%BA%E6%9C%AF%E8%AF%AD%E5%AF%B9%E7%85%A7%E8%A1%A8
Is it comprehensive? I don't know. Perhaps we could add some specific
reference tables related to the Linux Kernel on top of it.
On Mon, Jul 13, 2026 at 11:49:07AM +0800, Dongliang Mu wrote:
> Chen-Yu,I would like to serve as co-maintainers to help maintain zh_TW. The
> script - tools/docs/checktransupdate.py can seamlessly work on zh_TW. This
> can help track the missing changes.
I would also like to take a job ;-) while my current contributions are
not sufficient. And wish soon.
> As discussed with Alex before, maybe zh_TW patches can first go to Alex's
> kernel tree and then push to Jon's tree. I am not sure if you are familar
> with the maintainer workflow. If not, this solution may be better for you to
> learn maintainer workflow.
I suggest that we could try out the provisional plan for about one or
two months (depends), and then make a formal change.
Before we make a formal change, I will monitor the list (CN & TW), If
there is any situation like this patch which is not sent correctly, I
will handle it promptly.
OK, I consider myself quite familiar with the development process and
the maintenance process, mainly from Git (seems more complicated).
Perhaps I can handle most of the operation and maintenance tasks of
chore, giving Chen-yu more time and concentration to focus on the actual
translation work. But this can be further discussed.
Thanks,
Weijie
^ permalink raw reply
* Re: [PATCH v7 11/12] virt/steal_monitor: Act on steal time periodically and decide on preferred CPUs
From: Shrikanth Hegde @ 2026-07-13 5:48 UTC (permalink / raw)
To: Yury Norov
Cc: linux-kernel, mingo, peterz, juri.lelli, vincent.guittot,
yury.norov, kprateek.nayak, iii, corbet, tglx, gregkh, pbonzini,
seanjc, vschneid, huschle, rostedt, dietmar.eggemann, maddy,
srikar, hdanton, chleroy, vineeth, frederic, arighi, pauld,
christian.loehle, tj, tommaso.cucinotta, maz, rafael, rdunlap,
kernellwp, linux-doc
In-Reply-To: <alFX75dzgkMnDXAD@yury>
On 7/11/26 2:07 AM, Yury Norov wrote:
> On Fri, Jul 10, 2026 at 03:26:47AM +0530, Shrikanth Hegde wrote:
>> schedule work at regular intervals. Interval is determined by
>> interval_ms parameter. schedule_delayed_work is used since interval_ms
>> is usually in order of milliseconds. Work need not happen instantly.
>>
>> Periodic work function essentially does:
>> - Calculate the steal_ratio as below.
>>
>> steal_ratio = (delta_steal * 100*100)/(delta_ns * num_cpus())
>>
>> It is calculated to consider the fractional values of steal time.
>> I.e 10 means 0.1% steal time. A few tricks such as divide by 10,000
>> are used to avoid possible overflow.
>> - If steal value is higher than high threshold, call the method to reduce
>> the preferred CPUs.
>> - If steal value is lower or equal to low threshold, call the method to
>> increase the preferred CPUs.
>> - If the steal value is in between, no action is taken.
>> - Save the values for next delta calculations.
>> - Save the current direction of steal values to avoid oscillations.
>> So two consecutive values of high values or low values are taken for
>> decrease/increase of preferred CPUs.
>> - Ensure design checks are met.
>> 1. At least one core/CPU must be there in preferred mask.
>> 2. preferred CPUs is subset of active CPUs.
>>
>> Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com>
>> ---
>> v6->v7:
>> - Merge two patches which did periodic work function.
>> - Misc checks for early firing, requeue work, math safety.
>>
>> drivers/virt/steal_monitor/sm_core.c | 76 +++++++++++++++++++++++++++-
>> drivers/virt/steal_monitor/sm_core.h | 1 +
>> 2 files changed, 76 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/virt/steal_monitor/sm_core.c b/drivers/virt/steal_monitor/sm_core.c
>> index 4a03c14337be..09a5c3a299c3 100644
>> --- a/drivers/virt/steal_monitor/sm_core.c
>> +++ b/drivers/virt/steal_monitor/sm_core.c
>> @@ -20,6 +20,12 @@ struct steal_monitor sm_core_ctx = {
>> .low_threshold = 200, /* 2% */
>> };
>>
>> +enum sm_direction {
>> + SM_DIR_INCREASE = -1,
>> + SM_DIR_NONE = 0,
>> + SM_DIR_DECREASE = 1,
>> +};
>> +
>> static int param_set_interval_ms(const char *val, const struct kernel_param *kp)
>> {
>> unsigned int interval;
>> @@ -106,14 +112,82 @@ module_param_cb(low_threshold, &low_threshold_ops, &sm_core_ctx.low_threshold, 0
>> MODULE_PARM_DESC(low_threshold,
>> "Low steal threshold. default: 200 i.e 2%. Must be < high_threshold");
>>
>> +static void compute_preferred_cpus_work(struct work_struct *work)
>> +{
>> + u64 curr_steal, delta_steal, delta_ns, steal_ratio;
>> + ktime_t now;
>> +
>> + now = ktime_get();
>> + delta_ns = ktime_to_ns(ktime_sub(now, sm_core_ctx.prev_time));
>> +
>> + if (unlikely(delta_ns < NSEC_PER_MSEC)) {
>> + pr_err_ratelimited("steal_monitor: work scheduled too soon delta_ns: %llu\n",
>> + delta_ns);
>> + goto requeue_work;
>> + }
>> +
>> + curr_steal = get_system_steal_time();
>> + delta_steal = curr_steal > sm_core_ctx.prev_steal ?
>> + curr_steal - sm_core_ctx.prev_steal : 0;
>> +
>> + /* Update for next calculation */
>> + sm_core_ctx.prev_steal = curr_steal;
>> + sm_core_ctx.prev_time = now;
>> +
>> + /*
>> + * steal_ratio = (delta_steal * 100*100)/(delta_ns * num_cpus())
>> + * To avoid possible overflow, divide the denominator early.
>> + * Note minimum interval is 10ms.
>> + */
>> + delta_ns = div_u64(delta_ns * get_num_cpus_steal_ratio(), 100 * 100);
>> + steal_ratio = div64_u64(delta_steal, delta_ns);
>> +
>> + if (sm_core_ctx.prev_direction == SM_DIR_DECREASE &&
>> + steal_ratio > sm_core_ctx.high_threshold)
>> + decrease_preferred_cpus(&sm_core_ctx);
>> + if (sm_core_ctx.prev_direction == SM_DIR_INCREASE &&
>> + steal_ratio <= sm_core_ctx.low_threshold)
>> + increase_preferred_cpus(&sm_core_ctx);
>
> I already said, I don't like this SM_DIR approach. If you want to
> avoid oscillations, just increase the gap. If it doesn't work, then we
> need to understand why.
>
Ok. It was to avoid first simple, as it may have corner cases.
But yes, dropping it for now to keep things simple.
>> +
>> + /*
>> + * mark the direction. Increasing the gap between hi and lo_threshold
>> + * helps to avoid ping-pongs.
>> + */
>> + if (steal_ratio > sm_core_ctx.high_threshold)
>> + sm_core_ctx.prev_direction = SM_DIR_DECREASE;
>> + else if (steal_ratio <= sm_core_ctx.low_threshold)
>> + sm_core_ctx.prev_direction = SM_DIR_INCREASE;
>> + else
>> + sm_core_ctx.prev_direction = SM_DIR_NONE;
>> +
>> +requeue_work:
>> + /* maintain design constructs always */
>> + WARN_ON_ONCE(cpumask_empty(cpu_preferred_mask));
>> + WARN_ON_ONCE(!cpumask_subset(cpu_preferred_mask, cpu_active_mask));
>
> cpu_read_lock here? And again, you should do something to restore
> integrity. WARN_ON is not enough. The simplest and safest thing you
> can do is to unload the driver. You definitely shouldn't schedule a
> new work against the broken cpu_preferred_mask.
How about not requeue the work if it broken. Add a pr_err and return.
That makes driver pretty much nop until rmmod.
/* maintain design constructs always */
if (cpumask_empty(cpu_preferred_mask)) {
pr_err("empty cpu_preferred_mask, stop steal_monitor work");
return;
}
if (!cpumask_subset(cpu_preferred_mask, cpu_active_mask)) {
pr_err("preferred: %*pbl is not a subset of active: %*pbl, stop steal_monitor work\n",
pr_cpuamsk_args(cpu_preferred_mask), pr_cpuamsk_args(cpu_active_mask));
return;
}
(Ignore whitespace mangling)
>
>> +
>> + /* Trigger for next sampling */
>> + schedule_delayed_work(&sm_core_ctx.work,
>> + msecs_to_jiffies(sm_core_ctx.interval_ms));
>> +}
>> +
>> static int __init steal_monitor_init(void)
>> {
>> - pr_info("steal_monitor is enabled\n");
>> + pr_info("steal_monitor is enabled. interval: %ums, high_threshold: %u, low_threshold: %u\n",
>> + sm_core_ctx.interval_ms, sm_core_ctx.high_threshold, sm_core_ctx.low_threshold);
>> +
>> + INIT_DELAYED_WORK(&sm_core_ctx.work, compute_preferred_cpus_work);
>> + sm_core_ctx.prev_steal = get_system_steal_time();
>> + sm_core_ctx.prev_time = ktime_get();
>> +
>> + schedule_delayed_work(&sm_core_ctx.work,
>> + msecs_to_jiffies(sm_core_ctx.interval_ms));
>> +
>> return 0;
>> }
>>
>> static void __exit steal_monitor_exit(void)
>> {
>> + cancel_delayed_work_sync(&sm_core_ctx.work);
>
> cancel_delayed_work_sync() is not enough for a self-requeueing work.
> compute_preferred_cpus_work() always requeues itself. Module unload
> can return with delayed work armed against module text/data. Use
> disable_delayed_work_sync() or a stop flag checked before requeueing.
ok. I will make it disable_delayed_work_sync.
Thanks for catching that.
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: 葉宸佑 @ 2026-07-13 6:35 UTC (permalink / raw)
To: Weijie Yuan
Cc: Dongliang Mu, Alex Shi, Hu Haowen, Jonathan Corbet, Shuah Khan,
Dongliang Mu, linux-doc, linux-kernel, Yuchen Tian, Alex Shi,
Yanteng Si
In-Reply-To: <alR4jP1-qlcQNma1@wyuan.org>
Hi Dongliang, Weijie,
Thank you both -- this is more support than I expected, and I am glad
to do this together.
> Chen-Yu, I would like to serve as co-maintainers to help maintain zh_TW.
> [...]
> As discussed with Alex before, maybe zh_TW patches can first go to
> Alex's kernel tree and then push to Jon's tree. I am not sure if you are
> familar with the maintainer workflow. If not, this solution may be
> better for you to learn maintainer workflow.
To be honest: no, I am not familiar with the maintainer workflow yet --
so far I have only been on the contributor side. So routing zh_TW
patches through Alex's tree first sounds like the right arrangement to
me, both for reliability and so that I can learn the workflow properly
before taking on more. Alex, if you are fine with this, thank you in
advance.
> I suggest that we could try out the provisional plan for about one or
> two months (depends), and then make a formal change.
Agreed. A trial period before touching MAINTAINERS is fair -- it lets
the work speak first. I will send the MAINTAINERS patch when you both
feel the arrangement has proven itself.
> * Considering that English documents are changing so rapidly, and even
> simplified Chinese cannot keep up with them immediately. I suggest
> we start working on catching up with simplified Chinese right now,
> which seems like a good place to begin.
This matches what I had in mind, and it also answers Alex's concern:
zh_TW should track zh_CN in structure and coverage, and differ only in
terminology. I will start by running checktransupdate.py over zh_TW to
get a concrete inventory of what is stale and how far behind we are,
and share the result here so we can prioritize together.
> re-translation may be more efficient.
Agreed for the badly outdated files -- patching a two-year-old
translation line by line is likely more work than translating the
current text afresh. The inventory should tell us which files fall
into which category.
> https://zh.wikibooks.org/wiki/%E5%A4%A7%E9%99%86%E5%8F%B0%E6%B9%BE%E8%AE%A1%E7%AE%97%E6%9C%BA%E6%9C%AF%E8%AF%AD%E5%AF%B9%E7%85%A7%E8%A1%A8
>
> Is it comprehensive? I don't know. Perhaps we could add some specific
> reference tables related to the Linux Kernel on top of it.
As a native speaker: it is a reasonable general reference, but it is
not kernel-specific, and some entries are dated or not what people
actually write in Taiwan today. I would rather build the glossary
bottom-up from the terms that actually appear in the kernel docs
(軟體/軟件, 介面/接口, 記憶體, 行程, 核心, 佇列, ...), and use the
wikibooks table only as a cross-check. I will include the glossary as
part of the first terminology series so it can be reviewed like any
other patch.
> Perhaps I can handle most of the operation and maintenance tasks of
> chore, giving Chen-yu more time and concentration to focus on the actual
> translation work.
That would help a lot, thank you. It also sounds like a natural split:
you on process and monitoring, me on the translation and the zh_TW
terminology judgement.
One last thing about the patch that started all this: rather than
keeping the v2 for 8.Conclusion pending, I would suggest dropping it
and folding its changes into the terminology series, so the fixes
land in one consistent batch. Any objection?
Thanks,
Chen-Yu
Weijie Yuan <wy@wyuan.org> 於 2026年7月13日週一 下午1:33寫道：
>
> On Mon, Jul 13, 2026 at 10:44:12AM +0800, 葉宸佑 wrote:
> > Hi Weijie,
> >
> > > I suspect that some contributors would run the get_maintainers.pl script
> > > or b4 prep --auto-to-cc, so they did not cc Alex, as they didn't know
> > > the current situation. Because I noticed that for both two versions,
> > > Chen-yu didn't cc Alex or Dongliang or Yanteng. Am I right, @Chen-yu? ;-)
> >
> > Yes, exactly. For both v1 and v2 I ran get_maintainer.pl, which only
> > lists Hu Haowen and the mailing lists for zh_TW files, so Alex and the
> > zh_CN team were never on cc.
>
> Right, let's note this situation down. We'll deal with it after we come
> up with the final solution.
>
> >
> > > Given that this document has not been maintained for ~2 years and these
> > > patches to the terminology actually don't have much significance, it
> > > might be more appropriate to directly declare the status of Traditional
> > > Chinese as "Orphan" provisionally for now, and remove it directly in the
> > > near future, until Hao Wen's return and opinion. Or maybe, waiting for a
> > > new good soul to take over, which is unpredictable.
> >
> > Before it comes to that: I would like to step up and help carry zh_TW
> > forward. I am a native zh_TW speaker from Taiwan, and I understand
> > this means staying with it, not a one-off effort.
>
> Nice and thanks. Frankly speaking, At the very beginning, I did consider
> saying that I also wanted to take over, and I wished I could. However,
> considering that I was certainly not familiar with the traditional
> Chinese terms used in Taiwan (although I knew some, that was all), I
> finally chose to be speak more conservatively.
>
> > Dongliang, since you kindly offered to help review zh_TW patches:
> > would you be open to doing this together -- either as co-maintainers,
> > or with me listed as a reviewer (R:) first if that is a more
> > reasonable starting point for a newcomer?
>
> Since I was the one who shamelessly initiated this discussion, I
> definitely have the obligation to do something. See below...
>
> > > > To avoid scattering our efforts, I suggest we minimize fragmentation
> > > > as much as possible. When it comes to technical documentation
> > > > translation, not literary translation, a straightforward, unadorned,
> > > > and free from misunderstandings is the best translation and easy to
> > > > maintain. Let's keep thing simple, unless sth is really necessary.
> >
> > Alex, I think this concern is fair, and I have no intention of
> > forking the translation effort. The scope I have in mind is
> > deliberately narrow: keep zh_TW aligned with zh_CN in structure and
> > coverage, and localize only where terminology genuinely differs
> > (e.g. 軟體 vs 软件, 介面 vs 接口) -- exactly the kind of differences
> > you mentioned. Plain, accurate technical translation, no literary
> > rewriting.
>
> Exactly, before sending my first email here, I had already thought about
> the following approach, what do you think?
>
> * Considering that English documents are changing so rapidly, and even
> simplified Chinese cannot keep up with them immediately. I suggest
> we start working on catching up with simplified Chinese right now,
> which seems like a good place to begin. (ok... seems exactly what you said ;-)
>
> > Weijie, as a first concrete step I will prepare a terminology series
> > (rather than one-word-at-a-time patches, as you suggested) covering
> > the existing process/ documents, and use it to build a small glossary
> > that future patches and reviews can follow.
>
> I used to read this:
>
> https://zh.wikibooks.org/wiki/%E5%A4%A7%E9%99%86%E5%8F%B0%E6%B9%BE%E8%AE%A1%E7%AE%97%E6%9C%BA%E6%9C%AF%E8%AF%AD%E5%AF%B9%E7%85%A7%E8%A1%A8
>
> Is it comprehensive? I don't know. Perhaps we could add some specific
> reference tables related to the Linux Kernel on top of it.
>
> On Mon, Jul 13, 2026 at 11:49:07AM +0800, Dongliang Mu wrote:
> > Chen-Yu,I would like to serve as co-maintainers to help maintain zh_TW. The
> > script - tools/docs/checktransupdate.py can seamlessly work on zh_TW. This
> > can help track the missing changes.
>
> I would also like to take a job ;-) while my current contributions are
> not sufficient. And wish soon.
>
> > As discussed with Alex before, maybe zh_TW patches can first go to Alex's
> > kernel tree and then push to Jon's tree. I am not sure if you are familar
> > with the maintainer workflow. If not, this solution may be better for you to
> > learn maintainer workflow.
>
> I suggest that we could try out the provisional plan for about one or
> two months (depends), and then make a formal change.
>
> Before we make a formal change, I will monitor the list (CN & TW), If
> there is any situation like this patch which is not sent correctly, I
> will handle it promptly.
>
> OK, I consider myself quite familiar with the development process and
> the maintenance process, mainly from Git (seems more complicated).
> Perhaps I can handle most of the operation and maintenance tasks of
> chore, giving Chen-yu more time and concentration to focus on the actual
> translation work. But this can be further discussed.
>
> Thanks,
> Weijie
^ permalink raw reply
* Re: [patch 06/18] riscv/syscall: Use syscall_enter_from_user_mode_randomize_stack()
From: Guo Ren @ 2026-07-13 7:06 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Peter Zijlstra, Paul Walmsley, Palmer Dabbelt, linux-riscv,
Michael Ellerman, Shrikanth Hegde, linuxppc-dev, Kees Cook,
Huacai Chen, loongarch, Sven Schnelle, linux-s390, x86,
Mark Rutland, Jinjie Ruan, Andy Lutomirski, Oleg Nesterov,
Richard Henderson, Russell King, Catalin Marinas,
Geert Uytterhoeven, Thomas Bogendoerfer, Helge Deller,
Yoshinori Sato, Richard Weinberger, Chris Zankel,
linux-arm-kernel, linux-alpha, linux-csky, linux-m68k, linux-mips,
linux-parisc, linux-sh, linux-um, Arnd Bergmann, Vineet Gupta,
Will Deacon, Brian Cain, Michal Simek, Dinh Nguyen,
David S. Miller, Andreas Larsson, linux-snps-arc, linux-hexagon,
linux-openrisc, sparclinux, linux-arch, Michal Suchánek,
Jonathan Corbet, linux-doc
In-Reply-To: <20260707190253.974626922@kernel.org>
On Wed, Jul 8, 2026 at 3:06 AM Thomas Gleixner <tglx@kernel.org> wrote:
>
> syscall_enter_from_user_mode_randomize_stack() replaces
> syscall_enter_from_user_mode() and the subsequent invocation of
> add_random_kstack_offset().
>
> The advantage is that it applies the stack randomization right after
> enter_from_user_mode() and thereby avoids the overhead of get/put_cpu_var()
> as that code is invoked with interrupts disabled.
>
> No functional change.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Paul Walmsley <pjw@kernel.org>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: linux-riscv@lists.infradead.org
> ---
> arch/riscv/kernel/traps.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> --- a/arch/riscv/kernel/traps.c
> +++ b/arch/riscv/kernel/traps.c
> @@ -7,7 +7,6 @@
> #include <linux/kernel.h>
> #include <linux/init.h>
> #include <linux/irqflags.h>
> -#include <linux/randomize_kstack.h>
> #include <linux/sched.h>
> #include <linux/sched/debug.h>
> #include <linux/sched/signal.h>
> @@ -333,9 +332,7 @@ void do_trap_ecall_u(struct pt_regs *reg
>
> riscv_v_vstate_discard(regs);
>
> - syscall = syscall_enter_from_user_mode(regs, syscall);
> -
> - add_random_kstack_offset();
> + syscall = syscall_enter_from_user_mode_randomize_stack(regs, syscall);
Reviewed-by: Guo Ren <guoren@kernel.org>
--
Best Regards
Guo Ren
^ permalink raw reply
* Re: [PATCH v6 1/7] Add documentation for Sahara protocol
From: Kishore Batta @ 2026-07-13 7:20 UTC (permalink / raw)
To: Randy Dunlap, Jonathan Corbet, Shuah Khan, Jeff Hugo,
Carl Vanderlip, Oded Gabbay, Manivannan Sadhasivam
Cc: linux-doc, linux-kernel, linux-arm-msm, dri-devel, mhi
In-Reply-To: <699644e7-2fc2-41b5-9e02-7f4dbc2aa3a7@infradead.org>
On 7/8/2026 10:16 AM, Randy Dunlap wrote:
> On 7/1/26 3:37 AM, Kishore Batta wrote:
>> +The packet flow sequence is as follows :
>> +
>> +1. The target sends the hello packet to the host to initiate the protocol
>> + with the mode set to image transfer pending.
>> +
>> +2. The host sends a hello response packet with a success status and sets the
>> + mode to image transfer pending after it receives the hello packet and
>> + validates the protocol version running on the target.
>> +
>> +3. After the target receives the hello response, it initiates the data
>> + transfer by requesting the size of DDR training/calibration data.
>> +
>> +4. The host sends back the DDR training/calibration data to the target.
>> +
>> +5. The target decodes the training data and does not find valid DDR
>> + calibration data, target sends END_IMAGE_TX to interrupt the transfer.
>> +
>> +6. The host sends DONE after receives END_IMAGE_TX.
>> +
>> +7. The target sends DONE_RESP with mode = IMAGE_TX_PENDING because it has
>> + not received all images.
>> +
>> +8. The target executes DDR training process to generate valid DDR calibration
>> + data and prepares to push back to host.
>> +
>> +9. The target initiates protocol by sending a hello packet with COMMAND_MODE
>> + to the host.
>> +
>> +10. The host sends a hello response packet with a success status and sets the
>> + mode to COMMAND_MODE.
>> +
>> +11. The target sends CMD_READY to the host.
>> +
>> +12. The host receives CMD_READY and starts to get command IDs to be executed.
>> +
>> +13. The target sends CMD_ID = 9 to push DDR calibration data to host.
>> +
>> +14. The host executes CMD_ID = 9 to get DDR calibration data from the target.
>> +
>> +15. The target sends RAW_DATA with the payload which contains DDR calibration
>> + data to host.
>> +
>> +16. The host saves training data in the kernel buffer and exposes to userspace
>> + via the sysfs entry. The host sends CMD_SWITCH_MODE with the mode set to
>> + IMAGE_TX_PENDING to continue booting.
>> +
>> +17. After the target receives the CMD_SWITCH_MODE command, it sends HELLO to
>> + the host with the mode set to IMAGE_TX_PENDING. The target and the host
>> + repeat the packet flow for image transfer to get all booting-required
>> + images.
>> +
>> +18. Upon successful transfer of all images, the target sends an END_IMAGE_TX
>> + packet with a success status to the host.
>> +
>> +19. The host sends DONE after it receives END_IMAGE_TX.
>> +
>> +20. The target sends DONE_RESP with the mode set to IMAGE_TX_COMPLETE because
>> + it has received all images. The process has been completed after the host
>> + receives DONE_RESP with the mode set to IMAGE_TX_COMPLETE.
>> +
>> +Subsequent boot scenario with valid DDR calibration data
>> +--------------------------------------------------------
>> +
>> +The below firgure shows the subsequent boot scenario with valid DDR calibration
>> +data process being loaded from host to target.
>> +
>> +.. code-block:: text
>> +
>> + Host Target
>> + | HELLO |
>> + | (mode = image transfer) |
>> + |<--------------------------|
>> + | |
>> + | HELLO RESP |
>> + | (mode = image transfer) |
>> + |-------------------------->|
>> + | |
>> + | READ_DATA |
>> + | (img ID:34, 0, offset, |
>> + | size of DDR training data)|
>> + |<--------------------------|
>> + | |
>> + | RAW_DATA |
>> + |(size of DDR training data)|
>> + |-------------------------->|
>> + | |
>> + | |
>> + | END_IMAGE_TX |
>> + |<--------------------------|
>> + | |
>> + | |
>> + | DONE |
>> + |-------------------------->|
>> + | |
>> + | |
>> + | DONE_RESP |
>> + | (mode = IMAGE_TX_PENDING) |
>> + |<--------------------------|
>> + | |
>> + | Subsequent boot scenario |
>> + | (valid calibration data) |
>> + | DDR driver configures DDR |
>> + | using valid calibration |
>> + | data |
>> + | |
>> + | |
>> + | HELLO |
>> + | (mode = IMAGE_TX_PENDING) |
>> + |<--------------------------|
>> + | |
>> + | HELLO RESP |
>> + | (mode = IMAGE_TX_PENDING) |
>> + |-------------------------->|
>> + | |
>> + | Boot/Load rest of the |
>> + | images.... |
>> + | |
>> + | END_IMAGE_TX |
>> + |<--------------------------|
>> + | |
>> + | |
>> + | DONE |
>> + |-------------------------->|
>> + | |
>> + | |
>> + | DONE_RESP |
>> + |(mode = IMAGE_TX_COMPLETE) |
>> + |<--------------------------|
>> + | |
>> +
>> +The packet flow is as follows :
>> +
> s/as follows :/as follows:/
> in 2 places.
ACK. I'll remove the extra space before the colon in both places in the
next version.
>
>> +1. The target sends the hello packet to the host to initiate the protocol
>> + with the mode set to image transfer pending.
^ permalink raw reply
* Re: [PATCH v6 4/7] bus: mhi: Add QDU100 Sahara variant and firmware fallback
From: Kishore Batta @ 2026-07-13 7:25 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Jonathan Corbet, Shuah Khan, Jeff Hugo, Carl Vanderlip,
Oded Gabbay, linux-doc, linux-kernel, linux-arm-msm, dri-devel,
mhi
In-Reply-To: <n45ii7ekxeefuxw2ydwzsx7lqlfczbgg6obrzmzpytl2fin7j5@vbhmrptcjvcb>
On 7/9/2026 11:49 AM, Manivannan Sadhasivam wrote:
> On Wed, Jul 01, 2026 at 04:07:38PM +0530, Kishore Batta wrote:
>> The Sahara driver currently selects a firmware image table based on the
>> attached device, but it does not recognize QDU100 devices that expose the
>> protocol on the SAHARA MHI channel. As a result, the host cannot associate
>> QDU100 devices with the correct firmware namespace during image transfer.
>>
>> Extend the probe time variant selection to match the SAHARA MHI channel and
>> associate it with the QDU100 firmware folder. Add a firmware lookup
>> fallback for cases where an image does not have an explicit entry in the
>> device's firmware table. This allows required images to be provisioned by
>> the platform.
>>
>> This change only affects devices matched on the SAHARA MHI channel and
>> does not change behavior for existing AIC100 and AIC200 devices.
>>
>> Signed-off-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
>> ---
>> drivers/bus/mhi/host/clients/sahara/sahara.c | 27 +++++++++++++++--
>> drivers/bus/mhi/host/pci_generic.c | 45 ++++++++++++++++++++++++++++
>> 2 files changed, 70 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/bus/mhi/host/clients/sahara/sahara.c b/drivers/bus/mhi/host/clients/sahara/sahara.c
>> index e339c67e236af271645ca81cc517efd9eead87e4..9adbd84859073d8024ba2a5fcfa33897439d6759 100644
>> --- a/drivers/bus/mhi/host/clients/sahara/sahara.c
>> +++ b/drivers/bus/mhi/host/clients/sahara/sahara.c
>> @@ -189,6 +189,7 @@ static bool is_streaming(struct sahara_context *context)
>>
>> static int sahara_find_image(struct sahara_context *context, u32 image_id)
>> {
>> + char *fw_path;
>> int ret;
>>
>> if (image_id == context->active_image_id)
>> @@ -201,8 +202,28 @@ static int sahara_find_image(struct sahara_context *context, u32 image_id)
>> }
>>
>> if (image_id >= context->table_size || !context->image_table[image_id]) {
>> - dev_err(&context->mhi_dev->dev, "request for unknown image: %d\n", image_id);
>> - return -EINVAL;
>> + if (!context->fw_folder) {
>> + dev_err(&context->mhi_dev->dev,
>> + "Request for unknown image: %u (no fw folder)\n", image_id);
>> + return -EINVAL;
>> + }
>> +
>> + fw_path = kasprintf(GFP_KERNEL, "qcom/%s/%u",
>> + context->fw_folder, image_id);
>> + if (!fw_path)
>> + return -ENOMEM;
>> +
>> + ret = firmware_request_nowarn(&context->firmware,
>> + fw_path,
>> + &context->mhi_dev->dev);
>> + kfree(fw_path);
>> + if (ret) {
>> + dev_err(&context->mhi_dev->dev,
>> + "request for unknown image: %d\n", image_id);
>> + return -EINVAL;
>> + }
>> + context->active_image_id = image_id;
>> + return 0;
>> }
>>
>> /*
>> @@ -870,8 +891,10 @@ static void sahara_mhi_dl_xfer_cb(struct mhi_device *mhi_dev, struct mhi_result
>>
>> static const struct mhi_device_id sahara_mhi_match_table[] = {
>> { .chan = "QAIC_SAHARA", },
>> + { .chan = "SAHARA"},
>> {},
>> };
>> +MODULE_DEVICE_TABLE(mhi, sahara_mhi_match_table);
>>
> This change should belong to a separate patch.
There was a review comment from Jeff(v4, patch 3) to move to this change
to the patch which adds QDU100 support so that it doesn't break bisect.
Please let me know if i need to move it to a separate patch altogether ?
>
>> static struct mhi_driver sahara_mhi_driver = {
>> .id_table = sahara_mhi_match_table,
>> diff --git a/drivers/bus/mhi/host/pci_generic.c b/drivers/bus/mhi/host/pci_generic.c
>> index 391ab146f501c6ce1c81f6138f7c491a49c2f264..82e41632afc555a53dec3d8395558ae039b33bbd 100644
>> --- a/drivers/bus/mhi/host/pci_generic.c
>> +++ b/drivers/bus/mhi/host/pci_generic.c
>> @@ -300,6 +300,43 @@ static const struct mhi_pci_dev_info mhi_qcom_qdu100_info = {
>> .reset_on_remove = true,
>> };
>>
>> +static const char * const qdu100_image_table[] = {
>> + [5] = "qcom/qdu100/uefi.elf",
>> + [8] = "qcom/qdu100/qdsp6sw.mbn",
>> + [16] = "qcom/qdu100/efs1.bin",
>> + [17] = "qcom/qdu100/efs2.bin",
>> + [20] = "qcom/qdu100/efs3.bin",
>> + [23] = "qcom/qdu100/aop.mbn",
>> + [25] = "qcom/qdu100/tz.mbn",
>> + [29] = "qcom/qdu100/zeros_1sector.bin",
>> + [33] = "qcom/qdu100/hypvm.mbn",
>> + [34] = "qcom/qdu100/mdmddr.mbn",
>> + [36] = "qcom/qdu100/multi_image_qti.mbn",
>> + [37] = "qcom/qdu100/multi_image.mbn",
>> + [38] = "qcom/qdu100/xbl_config.elf",
>> + [39] = "qcom/qdu100/abl_userdebug.elf",
>> + [40] = "qcom/qdu100/zeros_1sector.bin",
>> + [41] = "qcom/qdu100/devcfg.mbn",
>> + [42] = "qcom/qdu100/zeros_1sector.bin",
>> + [45] = "qcom/qdu100/tools_l.elf",
>> + [46] = "qcom/qdu100/Quantum.elf",
>> + [47] = "qcom/qdu100/quest.elf",
>> + [48] = "qcom/qdu100/xbl_ramdump.elf",
>> + [49] = "qcom/qdu100/shrm.elf",
>> + [50] = "qcom/qdu100/cpucp.elf",
>> + [51] = "qcom/qdu100/aop_devcfg.mbn",
>> + [52] = "qcom/qdu100/fw_csm_gsi_3.0.elf",
>> + [53] = "qcom/qdu100/qdsp6sw_dtbs.elf",
>> + [54] = "qcom/qdu100/qupv3fw.elf",
>> +};
>> +
>> +static const struct mhi_sahara_fw_table qdu100_sahara_fw = {
>> + .image_table = qdu100_image_table,
>> + .table_size = ARRAY_SIZE(qdu100_image_table),
>> + .fw_folder = "qdu100",
>> + .non_streaming = false,
>> +};
>> +
>> static const struct mhi_channel_config mhi_qcom_sa8775p_channels[] = {
>> MHI_CHANNEL_CONFIG_UL(46, "IP_SW0", 2048, 1),
>> MHI_CHANNEL_CONFIG_DL(47, "IP_SW0", 2048, 2),
>> @@ -1399,6 +1436,14 @@ static int mhi_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
>>
>> pci_set_drvdata(pdev, mhi_pdev);
>>
>> + /*
>> + * Provide Sahara firmware mapping. Sahara consumes it via
>> + * mhi_dev->mhi_cntrl->sahara_fw at probe time.
>> + */
>> + if (info == &mhi_qcom_qdu100_info ||
>> + (info->name && !strcmp(info->name, "qcom-qdu100")))
>> + mhi_cntrl->sahara_fw = &qdu100_sahara_fw;
>> +
> Why are you adding QAIC MHI controller config in pci_generic driver? This driver
> only handles Modem devices.
>
> - Mani
>
^ permalink raw reply
* Re: [PATCH v6 5/7] bus: mhi: Load DDR training data using device serial number
From: Kishore Batta @ 2026-07-13 7:27 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Jonathan Corbet, Shuah Khan, Jeff Hugo, Carl Vanderlip,
Oded Gabbay, linux-doc, linux-kernel, linux-arm-msm, dri-devel,
mhi
In-Reply-To: <ysumvduurfx5jq7r2eaa4ik24eqk5at24frvjl3zyif4wc4ojj@2bhq4vzuqlnw>
On 7/9/2026 11:51 AM, Manivannan Sadhasivam wrote:
> On Wed, Jul 01, 2026 at 04:07:39PM +0530, Kishore Batta wrote:
>> Devices may provide device specific DDR training data that can be reused
>> across boot to avoid retraining and reduce boot time. The Sahara driver
>> currently always falls back to the default DDR training image, even when
>> serial specific training data is available.
>>
>> Extend the firmware loading logic for the DDR training image to first
>> attempt loading a per-device image dervied from the device serial number.
>> If the serial-specific image is not present, fall back to the existing
>> default image, preserving current behavior.
>>
>> This allows reuse of previously generated DDR training data when available,
>> while keeping the existing training flow unchanged for devices without
>> saved data or for all other firmware images.
>>
>> Signed-off-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
>> ---
>> drivers/bus/mhi/host/clients/sahara/sahara.c | 25 ++++++++++++++++++++++++-
>> 1 file changed, 24 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/bus/mhi/host/clients/sahara/sahara.c b/drivers/bus/mhi/host/clients/sahara/sahara.c
>> index 9adbd84859073d8024ba2a5fcfa33897439d6759..b5ca6353540dc3815db6539e7424afdb749fd3f6 100644
>> --- a/drivers/bus/mhi/host/clients/sahara/sahara.c
>> +++ b/drivers/bus/mhi/host/clients/sahara/sahara.c
>> @@ -59,6 +59,7 @@
>> #define SAHARA_RESET_LENGTH 0x8
>> #define SAHARA_MEM_DEBUG64_LENGTH 0x18
>> #define SAHARA_MEM_READ64_LENGTH 0x18
>> +#define SAHARA_DDR_TRAINING_IMG_ID 34
>>
>> struct sahara_packet {
>> __le32 cmd;
>> @@ -226,6 +227,27 @@ static int sahara_find_image(struct sahara_context *context, u32 image_id)
>> return 0;
>> }
>>
>> + /* DDR training special case: Try per-serial number file first */
>> + if (image_id == SAHARA_DDR_TRAINING_IMG_ID && context->fw_folder) {
>> + u32 serial_num = context->mhi_dev->mhi_cntrl->serial_number;
>> +
>> + fw_path = kasprintf(GFP_KERNEL,
>> + "qcom/%s/mdmddr_0x%x.mbn",
>> + context->fw_folder, serial_num);
>> + if (!fw_path)
>> + return -ENOMEM;
>> +
>> + ret = firmware_request_nowarn(&context->firmware,
>> + fw_path,
>> + &context->mhi_dev->dev);
>> + kfree(fw_path);
>> +
>> + if (!ret) {
>> + context->active_image_id = image_id;
>> + return 0;
>> + }
>> + }
>> +
>> /*
>> * This image might be optional. The device may continue without it.
>> * Only the device knows. Suppress error messages that could suggest an
>> @@ -235,7 +257,8 @@ static int sahara_find_image(struct sahara_context *context, u32 image_id)
>> context->image_table[image_id],
>> &context->mhi_dev->dev);
>> if (ret) {
>> - dev_dbg(&context->mhi_dev->dev, "request for image id %d / file %s failed %d\n",
>> + dev_dbg(&context->mhi_dev->dev,
>> + "request for image id %d / file %s failed %d\n",
> Spurious change.
>
> - Mani
ACK. Will remove it in next version.
^ permalink raw reply
* Re: [PATCH v6 7/7] bus: mhi: Expose DDR training data via controller sysfs
From: Kishore Batta @ 2026-07-13 7:30 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Jonathan Corbet, Shuah Khan, Jeff Hugo, Carl Vanderlip,
Oded Gabbay, linux-doc, linux-kernel, linux-arm-msm, dri-devel,
mhi
In-Reply-To: <n35ouuyvy25ocbfaedksryoz5d53cylk2pcsxz7f25us444gh7@7ybkifq3fbae>
On 7/9/2026 12:27 PM, Manivannan Sadhasivam wrote:
> On Wed, Jul 01, 2026 at 04:07:41PM +0530, Kishore Batta wrote:
>> DDR training data captured during Sahara command mode needs to be
>> accessible to userspace so it can be persisted and reused on subsequent
>> boots. Currently, the training data is stored internally in the driver
>> but has no external visibility once the Sahara channel is torn down.
>>
>> Expose the captured DDR training data via a read-only binary sysfs
>> attribute on the MHI controller device:
>>
>> /sys/bus/mhi/devices/<mhi_cntrl>/ddr_training_data
>>
>> The sysfs read callback serves data directly from controller scoped storage
>> and protects access with the controller training data lock. The attribute
>> lifetime is tied to the controller device via devres, allowing the data to
>> remain readable after Sahara channel teardown and ensuring automatic
>> cleanup when controller device is removed.
>>
> If this training data is RO, then what is the use of exposing it to userspace?
>
> - Mani
The userspace component will read this from sysfs and save it to a file
named mdmddr_0x<serial_no>.mbn.
On the device's next boot, Sahara will read the training data file and
send it to the device. The DDR driver on the device validates the
training data and restores it without running DDR training again.
>> Userspace flow:
>> 1. For each controller device, userspace reads the ddr_training_data sysfs
>> attribute.
>> 2. If the read returns non-zero data, userspace persists it using a
>> serial specific filename (for example, mdmddr_0x<serial_no>.mbn).
>> 3. On subsequent boots, the Sahara driver attempts to load this serial
>> specific DDR training image before falling back to the default
>> training image, restoring DDR calibration data and avoiding retraining.
>>
>> Add ABI documentation for the DDR training data sysfs attribute exposed by
>> Sahara MHI driver.
>>
>> Signed-off-by: Kishore Batta <kishore.batta@oss.qualcomm.com>
>> ---
>> .../ABI/testing/sysfs-bus-mhi-ddr_training_data | 19 +++++++
>> drivers/bus/mhi/host/clients/sahara/sahara.c | 62 ++++++++++++++++++++++
>> 2 files changed, 81 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-mhi-ddr_training_data b/Documentation/ABI/testing/sysfs-bus-mhi-ddr_training_data
>> new file mode 100644
>> index 0000000000000000000000000000000000000000..810b487b5a5fdba133d81255f9879844e3938a10
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-bus-mhi-ddr_training_data
>> @@ -0,0 +1,19 @@
>> +What: /sys/bus/mhi/devices/<mhi-cntrl>/ddr_training_data
>> +
>> +Date: March 2026
>> +
>> +Contact: Kishore Batta <kishore.batta@oss.qualcomm.com>
>> +
>> +Description: Contains the DDR training data for the Qualcomm device
>> + connected. MHI driver populates different controller
>> + nodes for each device. The DDR training data is exposed
>> + to userspace to read and save the training data file to
>> + the filesystem. In the subsequent boot up of the device,
>> + the training data is restored from host to device
>> + optimizing the boot up time of the device.
>> +
>> +Usage: Example for reading DDR training data:
>> + cat /sys/bus/mhi/devices/mhi0/ddr_training_data
>> +
>> +Permissions: The file permissions are set to 0444 allowing read
>> + access.
>> diff --git a/drivers/bus/mhi/host/clients/sahara/sahara.c b/drivers/bus/mhi/host/clients/sahara/sahara.c
>> index 07bc743aa061dd2fa85638067d494562152474e3..72ac751c302a98448b5756c9feb438647bd0ce4b 100644
>> --- a/drivers/bus/mhi/host/clients/sahara/sahara.c
>> +++ b/drivers/bus/mhi/host/clients/sahara/sahara.c
>> @@ -273,6 +273,66 @@ static struct sahara_cntrl_training_data *sahara_cntrl_training_get(struct devic
>> return ct;
>> }
>>
>> +static ssize_t ddr_training_data_read(struct file *filp, struct kobject *kobj,
>> + const struct bin_attribute *attr, char *buf,
>> + loff_t offset, size_t count)
>> +{
>> + struct device *dev = kobj_to_dev(kobj);
>> + struct sahara_cntrl_training_data *ct;
>> + size_t available;
>> +
>> + ct = sahara_cntrl_training_get(dev);
>> + if (!ct)
>> + return -ENODEV;
>> +
>> + mutex_lock(&ct->lock);
>> +
>> + /* No data yet or offset past end */
>> + if (!ct->data || offset >= ct->size) {
>> + mutex_unlock(&ct->lock);
>> + return 0;
>> + }
>> +
>> + available = ct->size - offset;
>> + count = min(count, available);
>> + memcpy(buf, (u8 *)ct->data + offset, count);
>> +
>> + mutex_unlock(&ct->lock);
>> +
>> + return count;
>> +}
>> +static BIN_ATTR_RO(ddr_training_data, 0);
>> +
>> +static void sahara_sysfs_devres_release(struct device *dev, void *res)
>> +{
>> + device_remove_bin_file(dev, &bin_attr_ddr_training_data);
>> +}
>> +
>> +static void sahara_sysfs_create(struct mhi_device *mhi_dev)
>> +{
>> + struct device *dev = &mhi_dev->mhi_cntrl->mhi_dev->dev;
>> + void *cookie;
>> + int ret;
>> +
>> + if (devres_find(dev, sahara_sysfs_devres_release, NULL, NULL))
>> + return;
>> +
>> + ret = device_create_bin_file(dev, &bin_attr_ddr_training_data);
>> + if (ret) {
>> + dev_warn(&mhi_dev->dev,
>> + "Failed to create DDR training sysfs node (%d)\n", ret);
>> + return;
>> + }
>> +
>> + cookie = devres_alloc(sahara_sysfs_devres_release, 1, GFP_KERNEL);
>> + if (!cookie) {
>> + device_remove_bin_file(dev, &bin_attr_ddr_training_data);
>> + return;
>> + }
>> +
>> + devres_add(dev, cookie);
>> +}
>> +
>> static int sahara_find_image(struct sahara_context *context, u32 image_id)
>> {
>> char *fw_path;
>> @@ -1131,6 +1191,8 @@ static int sahara_mhi_probe(struct mhi_device *mhi_dev, const struct mhi_device_
>> return ret;
>> }
>>
>> + sahara_sysfs_create(mhi_dev);
>> +
>> return 0;
>> }
>>
>>
>> --
>> 2.34.1
>>
^ permalink raw reply
* Re: [PATCH v4 3/4] swap: apply new pw_queue_on() interface
From: Sebastian Andrzej Siewior @ 2026-07-13 7:31 UTC (permalink / raw)
To: Leonardo Bras
Cc: Jonathan Corbet, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
Nathan Chancellor, Nicolas Schier, Miguel Ojeda,
Thomas Weißschuh, Thomas Gleixner, Douglas Anderson,
Gary Guo, Christian Brauner, Pasha Tatashin, Coiby Xu,
Masahiro Yamada, Frederic Weisbecker, linux-doc, linux-kernel,
linux-mm, linux-rt-devel, Marcelo Tosatti
In-Reply-To: <alQKlBaKIOAxMzc2@WindFlash>
On 2026-07-12 18:43:48 [-0300], Leonardo Bras wrote:
> > I thought that this improved since commit
> > ff042f4a9b050 ("mm: lru_cache_disable: replace work queue synchronization with synchronize_rcu")
> >
> > Did it get worse or was it not entirely gone?
> >
>
> I worked in this patchset majorly after that commit date, and it was still
> an issue up to last time Marcelo tested. Not sure of the impact of above
> commit, but I suppose it may have brought some improvements without fully
> fixing it.
It would be good to know what is still missing and maybe it can be
addressed without introducing this remote locking.
> Thanks!
> Leo
Sebastian
^ permalink raw reply
* Re: [PATCH v8 01/11] KVM: arm64: Serialize userspace MDCR_EL2 access
From: Oliver Upton @ 2026-07-13 7:33 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, Shuah Khan,
Yury Norov, Rasmus Villemoes, linux-arm-kernel, kvmarm,
linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <20260710-hybrid-v8-1-621409f3a592@rsg.ci.i.u-tokyo.ac.jp>
Hi,
On Fri, Jul 10, 2026 at 08:14:55PM +0900, Akihiko Odaki wrote:
> kvm_arm_set_nr_counters() updates MDCR_EL2.HPMN for every vCPU while
> holding kvm->arch.config_lock. However, KVM_SET_ONE_REG currently writes
> MDCR_EL2 through the generic sysreg path without taking the same lock.
> Concurrent PMU configuration and register restore can therefore race and
> lose updates to unrelated MDCR_EL2 bits.
Ugh, we should just stop updating MDCR_EL2.HPMN altogether. Since this
overwrites the previous value (rather than clamping it) we could discard
a legal value set by userspace.
From the UAPI POV all we need to do is ensure the reset value is sane.
The documentation says that system registers are reset to their warm
reset values when KVM_ARM_VCPU_INIT is called. Which in this would mean
HPMN is reset to the number of implemented counters at the time of the
ioctl.
If userspace changes the number of counters afterwards, that's their
problem.
> Add explicit userspace accessors for MDCR_EL2. Serialize them with
> config_lock so whole-register userspace writes cannot race with HPMN
> rewrites, reject HPMN values above the configured PMU counter count, and
> request a PMU reload when HPME changes to match guest trap behavior.
>
> Fixes: c8823e51b534 ("KVM: arm64: Fix MDCR_EL2.HPMN reset value")
> Closes: https://sashiko.dev/#/patchset/20260706-hybrid-v8-0-de459617b59d%40rsg.ci.i.u-tokyo.ac.jp?part=6
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp>
> ---
> arch/arm64/kvm/sys_regs.c | 39 ++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
> index d217530359ba..2b2ea33159e9 100644
> --- a/arch/arm64/kvm/sys_regs.c
> +++ b/arch/arm64/kvm/sys_regs.c
> @@ -2949,6 +2949,42 @@ static bool access_mdcr(struct kvm_vcpu *vcpu,
> return true;
> }
>
> +static int get_mdcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
> + u64 *val)
> +{
> + struct kvm *kvm = vcpu->kvm;
> +
> + guard(mutex)(&kvm->arch.config_lock);
Hrm... I would strongly prefer that we *not* take the config_lock for
this register since there's no way for userspace to avoid lock
contention. ID registers are special and documented as VM-scoped, so an
aware VMM could potentially set these once (avoiding the lock).
> + *val = __vcpu_sys_reg(vcpu, MDCR_EL2);
> +
> + return 0;
> +}
> +
> +static int set_mdcr(struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd,
> + u64 val)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + u64 old, hpmn = FIELD_GET(MDCR_EL2_HPMN, val);
> +
> + guard(mutex)(&kvm->arch.config_lock);
> +
> + if (hpmn > vcpu->kvm->arch.nr_pmu_counters)
> + return -EINVAL;
KVM allows userspace to write whatever it wants right now, we can't
start rejecting values that were previously valid. The architecture also
allows anything to be written to the field, just that unimplemented
values have UNKNOWN behavior.
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH 2/2] hwmon: (pmbus) Add driver for Analog Devices MAX20912 and MAX20916
From: Nuno Sá @ 2026-07-13 7:35 UTC (permalink / raw)
To: Guenter Roeck
Cc: Fred Chen, Torreno, Alexis Czezar, Krzysztof Kozlowski,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Jonathan Cameron, Wensheng Wang, Frank Li,
Brian Chiang, Cosmo Chou, Dixit Parmar, Eddie James,
Antoni Pokusinski, Thorsten Blum, Ashish Yadav, Syed Arif,
ChiShih Tsai, Abdurrahman Hussain, Paller, Kim Seer, Colin Huang,
Yuxi Wang, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-hwmon@vger.kernel.org,
linux-doc@vger.kernel.org
In-Reply-To: <94010bec-7921-4fac-ba48-755e51c59bcb@roeck-us.net>
On Thu, Jul 09, 2026 at 04:39:36PM -0700, Guenter Roeck wrote:
> On 7/9/26 09:09, Nuno Sá wrote:
> > On Thu, Jul 09, 2026 at 08:54:09AM -0700, Guenter Roeck wrote:
> > > On Thu, Jul 09, 2026 at 09:54:22AM +0100, Nuno Sá wrote:
> > > > >
> > > > > Based on the MAX20912/16 specs on my hand, these chips do not support
> > > > > PMBUS_PHASE (0x04). Furthermore, the spec only indicates support for VID mode
> > > > > and does not provide m/b/r. Therefore, some of the features you mentioned might
> > > > > be specific to the MAX20826 series.
> > > >
> > > > I see, phases are not supported using standard PMBUS.
> > > >
> > >
> > > As mentioned in my other e-mail, it can still be supported by the driver.
> > > That is what the chip drivers are for, after all.
> > >
> > > > >
> > > > > Regarding enabling VOUT via GPIO, our platform handles this via the CPLD as
> > > > > part of the hardware power sequencing. Managing this pin through the driver is
> > > > > not a requirement for our system.
> > > >
> > > > But we cannot assume all systems will behave like the above. But now i
> > > > do wonder about controlling the GPIOs in the driver. In your system you
> > > > clearly did not need to do it. In mine (testing with a rpi) I had to
> > > > use a GPIO (well I could have used hogs or pinctrl). But if you control the pin
> > > > you do gain the ability to turn off the regulator. If you don't it's always on
> > > > (which might be indeed the bulk of the real usecases for these systems).
> > > >
> > > Agreed. I don't really like it, but if the chip and some specific hardware
> > > mandate it, it should be supported. However, that code also needs to be
> > > tested - an untested implementation would be worse than no implementation.
> >
> > That's how I tested it :). So from what I understand the preferred way
> > is to support these pins as optional? If they are not there we just
> > assume the pins are always enabled by some other means? In contrast to
> > what I have today which makes these pins mandatory!
> >
>
> I had to go back a bit in mental history .... actually, the regulator code
> in the PMBus core doesn't touch the ON_OFF_CONFIG register. It uses the
> OPERATION command to enable/disable outputs. The reason is that the enable
> pin and ON_OFF_CONFIG typically affect the entire chip, while the OPERATION
> command only affects a single channel.
>
Yes. The only thing I do is to read the ON_OFF_CONFIG register at probe
to check if I need to check the enable bit in OPERATION. So that
vout state becomes gpio && OPERATION.
> So far PMBus drivers typically don't touch ON_OFF_CONFIG. The ibm-cffps
> driver supports writing it, but only through a debugfs file. The tda38640
> driver supports writing it, but only because it does not (or not correctly)
> support the OPERATION command. ON_OFF_CONFIG (if it is modified at all)
> is normally set by the firmware or even in production (if the chip supports
> non-volatile configuration). It is one of the "hairy" PMBus commands
> which should be left alone if at all possible.
>
> You can not make the property mandatory since most systems will neither
> support nor need it since it is handled by hardware/firmware.
> In many if not almost all cases there won't even _be_ a GPIO pin that
> can be set by software.
Understood.
- Nuno Sá
>
> Guenter
>
^ permalink raw reply
* Re: [PATCH v4 4/4] slub: apply new pw_queue_on() interface
From: Sebastian Andrzej Siewior @ 2026-07-13 7:36 UTC (permalink / raw)
To: Leonardo Bras
Cc: Jonathan Corbet, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Feng Tang, Dapeng Mi, Kees Cook, Marco Elver,
Jakub Kicinski, Li RongQing, Eric Biggers, Paul E. McKenney,
Nathan Chancellor, Nicolas Schier, Miguel Ojeda,
Thomas Weißschuh, Thomas Gleixner, Douglas Anderson,
Gary Guo, Christian Brauner, Pasha Tatashin, Coiby Xu,
Masahiro Yamada, Frederic Weisbecker, linux-doc, linux-kernel,
linux-mm, linux-rt-devel, Marcelo Tosatti
In-Reply-To: <alQWr2L_Kn23pxd9@WindFlash>
On 2026-07-12 19:35:28 [-0300], Leonardo Bras wrote:
> On Wed, May 20, 2026 at 04:53:08PM +0200, Sebastian Andrzej Siewior wrote:
> > On 2026-05-18 22:27:50 [-0300], Leonardo Bras wrote:
> > > @@ -4733,121 +4735,121 @@ void *alloc_from_pcs(struct kmem_cache *s, gfp_t gfp, int node)
> > >
> > > /*
> > > * We assume the percpu sheaves contain only local objects although it's
> > > * not completely guaranteed, so we verify later.
> > > */
> > > if (unlikely(node_requested && node != numa_mem_id())) {
> > > stat(s, ALLOC_NODE_MISMATCH);
> > > return NULL;
> > > }
> > >
> > > - if (!local_trylock(&s->cpu_sheaves->lock))
> > > + if (!pw_trylock_local(&s->cpu_sheaves->lock))
> > > return NULL;
> >
> > alloc_from_pcs() can be called from kmalloc_nolock()/ NMI context.
> > I don't remember why exactly local_trylock_t was introduced here instead
> > of a per-CPU spinlock_t.
>
> Probably to save the cost of using atomic operations on locking, and having
> about the same restrictions that would allow using local_locks
>
> > But there should be nothing wrong with a
> > trylock on it from NMI as you do here.
>
> Awesome!
The problem is always the unlock which requires full locking and is
usually the problem from NMI.
> >
> > One thing worth noting, on !PREEMPT_RT, spin_trylock() always succeeds
> > on UP. kmalloc_nolock() checks for it, not sure about other callers.
>
>
> Sorry, I did not sure I understand that part.
> You mean we have since it always returns true, we may be in NMI context,
> after it was interrupted holding this lock, and it will return true which
> will use the protected area even though the lock should avoid it?
from include/linux/spinlock_api_up.h:
| static __always_inline int _raw_spin_trylock(raw_spinlock_t *lock)
| __cond_acquires(true, lock)
| {
| __LOCK(lock);
| return 1;
| }
on UP a spin_trylock() always succeeds.
> Humm, but if that scenario exist, then is it actually ok to return true on
> trylock() in that scenario?
>
> Thanks!
> Leo
Sebastian
^ permalink raw reply
* Re: [Resend PATCH] dt-bindings: fix typos and brackets
From: Krzysztof Kozlowski @ 2026-07-13 7:41 UTC (permalink / raw)
To: Manuel Ebner
Cc: Conor Dooley, Krzysztof Kozlowski, Rob Herring, devicetree,
Jonathan Corbet, linux-doc, linux-kernel, Liam Girdwood,
Mark Brown, Randy Dunlap
In-Reply-To: <802ebebbf204cbcec5cd73b6b0f19fc8ed10e86e.camel@mailbox.org>
On Sat, Jul 11, 2026 at 03:38:43PM +0200, Manuel Ebner wrote:
> Add missing '(', ')', '}'
> Remove needless '(', ')', '{', '}'
> 'lover voltage' -> 'lower voltage'
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> Sorry for the resend - e-mail clients ...
> Sorry for the noise the last days. When sending Documentation/ABI/ patches I got
> the advice to send each change in a seperate patch. For ABI it worked very
> well. That's why I did it.
Checkpatch points to errors. As expected, patch does not apply, because
it is corrupted.
Please carefully follow beginners guide for sending a patch:
https://www.linaro.org/blog/becoming-a-kernel-developer-part1-posting-your-first-patch/
(all series of above blog)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 09/11] KVM: arm64: PMU: Implement fixed-counters-only emulation
From: Oliver Upton @ 2026-07-13 7:41 UTC (permalink / raw)
To: Akihiko Odaki
Cc: Marc Zyngier, Joey Gouly, Suzuki K Poulose, Zenghui Yu,
Catalin Marinas, Will Deacon, Kees Cook, Gustavo A. R. Silva,
Paolo Bonzini, Jonathan Corbet, Shuah Khan, Shuah Khan,
Yury Norov, Rasmus Villemoes, linux-arm-kernel, kvmarm,
linux-kernel, linux-hardening, devel, kvm, linux-doc,
linux-kselftest
In-Reply-To: <20260710-hybrid-v8-9-621409f3a592@rsg.ci.i.u-tokyo.ac.jp>
On Fri, Jul 10, 2026 at 08:15:03PM +0900, Akihiko Odaki wrote:
> @@ -813,6 +842,15 @@ void kvm_host_pmu_init(struct arm_pmu *pmu)
> if (!pmuv3_implemented(kvm_arm_pmu_get_pmuver_limit()))
> return;
>
> + /*
> + * IMPDEF PMUv3 traps are non-architectural, and KVM cannot assume a
> + * uniform PMUv3-compatible arm_pmu is available on all CPUs.
> + */
> + if (cpus_have_final_cap(ARM64_WORKAROUND_PMUV3_IMPDEF_TRAPS)) {
> + kvm_info("Non-architectural PMU, tainting kernel\n");
> + add_taint(TAINT_CPU_OUT_OF_SPEC, LOCKDEP_STILL_OK);
> + }
> +
This is an unrelated change, and really the taint should be added with the
.cpu_enable() for this capability. That's the point where we flip the
magic bit.
> +void kvm_vcpu_load_pmu(struct kvm_vcpu *vcpu, int last_cpu)
> +{
> + if (!kvm_pmu_fixed_counters_only(vcpu->kvm) || vcpu->cpu == last_cpu || last_cpu == -1)
^~~~~~~~~~~~~~
Does this do anything other than avoid a spurious reload on the first KVM_RUN?
Thanks,
Oliver
^ permalink raw reply
* Re: [PATCH v4 0/4] Introduce Per-CPU Work helpers (was QPW)
From: Sebastian Andrzej Siewior @ 2026-07-13 8:07 UTC (permalink / raw)
To: Leonardo Bras
Cc: Jonathan Corbet, Shuah Khan, Peter Zijlstra, Ingo Molnar,
Will Deacon, Boqun Feng, Waiman Long, Andrew Morton,
David Hildenbrand, Lorenzo Stoakes, Liam R. Howlett,
Vlastimil Babka, Mike Rapoport, Suren Baghdasaryan, Michal Hocko,
Jann Horn, Pedro Falcato, Brendan Jackman, Johannes Weiner,
Zi Yan, Harry Yoo, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Youngjun Park, Qi Zheng, Shakeel Butt,
Axel Rasmussen, Yuanchu Xie, Wei Xu, Borislav Petkov (AMD),
Randy Dunlap, Thomas Gleixner, Feng Tang, Dapeng Mi, Kees Cook,
Marco Elver, Jakub Kicinski, Li RongQing, Eric Biggers,
Paul E. McKenney, Nathan Chancellor, Miguel Ojeda, Nicolas Schier,
Thomas Weißschuh, Douglas Anderson, Gary Guo,
Christian Brauner, Pasha Tatashin, Masahiro Yamada, Coiby Xu,
Frederic Weisbecker, linux-doc, linux-kernel, linux-mm,
linux-rt-devel
In-Reply-To: <alP58SgTc2_8OFPc@WindFlash>
On 2026-07-12 17:32:49 [-0300], Leonardo Bras wrote:
> > > The idea:
> > > Currently with PREEMPT_RT=y, local_locks() become per-cpu spinlocks.
>
> Hi Sebastian, thank you for reviewing!
> (Sorry for the delay)
>
> > It does not become a _spin_lock because it does not spin. It sleeps.
>
> Right, it's a per-cpu mutex.
> My point is that it's a full lock, and we could use it instead of doing the
> whole scheduling thing, since we are already paying the 'atomic overhead'
> to get the lock here.
The whole lock is a spinlock_t. There is also raw_spinlock_t and
bit_spin_lock(). All three are considered spinlocks.
> > > In this case, instead of scheduling work on a remote cpu, it should
> > > be safe to grab that remote cpu's per-cpu spinlock and run the required
> > > work locally. That major cost, which is un/locking in every local function,
> > > already happens in PREEMPT_RT.
> >
> > We did have this before but only in the RT tree. It was a bit messy from
> > the naming because it started with local_ but then it was a remote CPU.
>
> Had the same naming issue here. This idea was initially a expansion to
> local_lock() mechanism, about the same way you were planning in the past.
>
> > The main issue was the different code path which led to a few deadlocks
> > back then.
> > By the time local_lock_t went upstream, the cross-CPU locking was
> > removed. As far as I remember, the cross-CPU user which did schedule
> > work on a remote CPU and annoyed NOHZ folks were replaced.
>
> I understand this could be a big issue if used in a generic way.
>
> What I am proposing here a mechanism that standardizes those
> local_lock()+IPI strategies based on how they are done today, so we are
> only explected to get 'remote-cpu' pwlocks in the 'IPI replacement'
> operations.
>
> The idea is pwlock_local* in every local function, and pwlock*(,cpu) in
> operations that can be remote.
>
> Maybe being used in a more constrained way, it has less chance of being an
> issue. Also, the whole idea is to improve CPU isolation numbers by
> reducing IPIs, so maybe NOHZ people will be happier with that :)
I get that part. The local_lock_t part is cheap on !RT and becomes a
full lock on RT. While the lock details change the overall expectation
remain the same. With this change it is possible to acquire the lock
cross-CPU but this depends on the config/ setup. This might not be easy
in terms of testing and maintenance.
The more potential users you have, the better it might become in terms
of a selling argument. If you have just (say) two users it might be
simpler to address just those.
> Thanks again!
> Leo
Sebastian
^ permalink raw reply
* Re: [PATCH v2 0/5] binfmt_misc: bpf-backed binary type handlers
From: Christian Brauner @ 2026-07-13 8:20 UTC (permalink / raw)
To: Farid Zakaria
Cc: Christian Brauner, Alexei Starovoitov, Daniel Borkmann,
Martin KaFai Lau, Shuah Khan, Andrii Nakryiko, Kees Cook,
Alexander Viro, Jan Kara, Jonathan Corbet, Jann Horn,
John Ericson, linux-fsdevel, linux-mm, linux-kernel, bpf,
linux-doc, linux-kselftest
In-Reply-To: <DJX4IFO55D9S.3IV3K5XICJAEV@gmail.com>
> > - The single sleepable load op is split into two ops:
> >
> > struct binfmt_misc_ops {
> > bool (*match)(struct linux_binprm *bprm);
> > int (*load)(struct linux_binprm *bprm);
> > char name[BINFMT_MISC_OPS_NAME_MAX];
> > };
> >
> > The non-sleepable match program runs from the RCU entry lookup
> > walk itself, exactly like magic and extension matching: same
> > registration order, same first-match-wins semantics, and it can
> > only rely on the prefetched bprm->buf. It must be free of side
> > effects since the walk may be restarted.
> >
>
> Is relying on brpm->buf enough?
> Right now that's only 256 bytes I think, which is not enough to read
> segments we might care about. That worked fine when it was just a magic
> number but the idea with the eBPF program is to make decisions based on
> more data.
>
> In the selftest I provided, the `PT_INTERP` segment is already at file
> offset 0x318 (792). I was imaginging NixOS having to support
> `PT_INTERP_NIX` in order for the produced binaries to be backwards
> compatible with older kernels.
>
> The other idea would be to make the `match()` broad and select
> everything but then nearly all ELF64 binaries would match and then pay
> the price to `load()` and ultimately `-ENOEXEC`. Seems like it would
> make multiple BPF binfmt programs less useful.
Ok, so your idea is to have multiple bpf programs that look for
different interpreters. Yeah, then you have to be able to sleep because
you need to be able to fault. It makes the code uglier but I can see how
that's useful. I'll see how nice I can make that.
> > The sleepable load program runs once the walk has committed to the
> > entry and does the file reading and the interpreter selection. Both
> > ops are mandatory, the struct_ops plumbing enforces the sleepability
> > of each, and since bpf_binprm_set_interp() is KF_SLEEPABLE a match
> > program cannot select an interpreter by construction.
> >
> > - A match is a commitment. A failing load program fails the exec instead
> > of falling through to later entries. -ENOEXEC keeps its usual meaning
> > and hands the binary to the remaining binary formats, for a handler
> > that discovers it cannot serve the binary after all.
> >
> > This kills the part of v1 I disliked the most: the skip cursor and the
> > leave-and-rescan loop in load_misc_binary() are gone. The walk is
> > never left and re-entered, and 'B' entries need no special semantics
> > against concurrent (un)registration anymore.
> >
> > Your v2 changelog note about keeping the bpf retry loop in the
> > __free() style is moot as a consequence. The loop no longer exists.
> >
> > - The load return convention flipped: 0 now means success after the
> > program called bpf_binprm_set_interp(). Returning 0 without having
> > selected an interpreter or returning a positive value is treated as
> > -ENOEXEC, other negative errnos fail the exec.
> >
> > So the "return bpf_binprm_set_interp(...) ?: 1" idiom from the v1-era
> > programs becomes plain "return bpf_binprm_set_interp(...)".
> >
> > - The handler name moved from the offset field to the interpreter field
> > that field consistently names whoever supplies the interpreter, a path
> > for static entries, a handler for 'B' entries. Offset, magic, and mask
> > must be empty:
> >
> > echo ':nix-origin:B::::nix_origin:' > register
> >
> > - 'C' is allowed now, v1 rejected it. It behaves exactly as for a static
> > entry. The setuid transition stays gated by vfsuid_has_mapping() in
> > the caller's user namespace. Which makes 'B' handlers usable for a
> > per-binary loader over setuid binaries. 'F' stays rejected as there
> > is no fixed interpreter to pre-open (I have other ideas how we'll do
> > something like it later.).
> >
> > Nothing changed in the exec patch, the fs kfuncs patch, the kfunc
> > itself, or the registry/namespacing model.
> >
> > I can send v3 in a bit if that's ok.
>
> I don't mind at all you sending v3 and in fact I've been enjoying your
> involvement. I didn't know what to expect when I offered this idea up to
> the community.
>
> I'm happy to keep co-developing this with you within a design you feel
> acceptable with. Please let me know how I can remain engaged and
> helpful.
>
> One last thing I was thinking about is that we will also need to support
> $ORIGIN in the shebang path, however I just tested it and this current broad
> BPF solution can largely handle it [1], with a small wrinkle.
>
> $ printf '#!$ORIGIN/interp\n' > /opt/app/greet
> $ cp ./interp /opt/app/interp # any interpreter/loader
> $ chmod +x /opt/app/greet /opt/app/interp
>
> # stock kernel: binfmt_script opens the literal "$ORIGIN/interp"
> $ /opt/app/greet
> bash: /opt/app/greet: $ORIGIN/interp: bad interpreter: No such file or directory
>
> # with the handler registered, $ORIGIN resolves to the script's dir
> $ bpftool struct_ops register shebang_origin.bpf.o /sys/fs/bpf
> $ echo ':shebang-origin:B:shebang_origin::::' > /proc/sys/fs/binfmt_misc/register
> $ /opt/app/greet
> <runs /opt/app/interp, the loader found next to the script>
>
> The wrinkle is that it can't express today is the single optional argument.
> (i.e. `#!interp arg" -> argv[1]=arg`). We might ned a way to express
> that in the load.
Ah, fun. binfmt_misc wasn't able to express this at all. It's good to
close that gap. This can just be done by adding
bpf_binprm_set_interp_arg().
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: 葉宸佑 @ 2026-07-13 9:03 UTC (permalink / raw)
To: Weijie Yuan
Cc: Dongliang Mu, Alex Shi, Hu Haowen, Jonathan Corbet, Shuah Khan,
Dongliang Mu, linux-doc, linux-kernel, Yuchen Tian, Alex Shi,
Yanteng Si
In-Reply-To: <CAKspUhLGq_Hz-EM+Jc9ga=ih_0Ui7WzHZt+uKxMvuERsYB93Bg@mail.gmail.com>
Here is the inventory I promised, from checktransupdate.py on mainline:
zh_TW: 51 translated files, all out of date
221 distinct English commits to catch up with
process/ 14 files
admin-guide/ 15
arch/ 12
dev-tools/ 5
filesystems/ 3
cpu-freq/ 1
index.rst 1
For calibration I ran the same tool on zh_CN: 178 translated files,
also all out of date, 639 distinct commits behind. So in terms of
drift from the English originals, zh_TW is not in a categorically
different state from zh_CN -- the real gap is coverage (51 vs 178
files), not decay. That makes me more optimistic than the "two years
of stagnation" framing suggests: many zh_TW files are only behind by
a typo fix or two.
(The ~3300 documents with no Chinese translation at all are out of
scope for both locales, so I do not think that is the problem to
solve first.)
One thing I noticed while reading the script: checktransupdate.py
tracks the base commit accurately only when the translation commit
message contains "update to commit HASH" (or "Update the translation
through commit HASH"); otherwise it falls back to guessing from author
dates. Adopting that convention for zh_TW commits from now on would
make the tool's numbers reliable, and it costs nothing. Perhaps that
could be part of the "more reasonable workflow" Weijie mentioned.
My suggestion for the first step is process/ (14 files): it is where
new contributors land first, it is small enough to finish as one
series, and it is where the terminology differences are most visible.
I would fold the pending 8.Conclusion patch into that series and build
the glossary from it.
葉宸佑 <chenyou910331@gmail.com> 於 2026年7月13日週一 下午2:35寫道：
>
> Hi Dongliang, Weijie,
>
> Thank you both -- this is more support than I expected, and I am glad
> to do this together.
>
> > Chen-Yu, I would like to serve as co-maintainers to help maintain zh_TW.
> > [...]
> > As discussed with Alex before, maybe zh_TW patches can first go to
> > Alex's kernel tree and then push to Jon's tree. I am not sure if you are
> > familar with the maintainer workflow. If not, this solution may be
> > better for you to learn maintainer workflow.
>
> To be honest: no, I am not familiar with the maintainer workflow yet --
> so far I have only been on the contributor side. So routing zh_TW
> patches through Alex's tree first sounds like the right arrangement to
> me, both for reliability and so that I can learn the workflow properly
> before taking on more. Alex, if you are fine with this, thank you in
> advance.
>
> > I suggest that we could try out the provisional plan for about one or
> > two months (depends), and then make a formal change.
>
> Agreed. A trial period before touching MAINTAINERS is fair -- it lets
> the work speak first. I will send the MAINTAINERS patch when you both
> feel the arrangement has proven itself.
>
> > * Considering that English documents are changing so rapidly, and even
> > simplified Chinese cannot keep up with them immediately. I suggest
> > we start working on catching up with simplified Chinese right now,
> > which seems like a good place to begin.
>
> This matches what I had in mind, and it also answers Alex's concern:
> zh_TW should track zh_CN in structure and coverage, and differ only in
> terminology. I will start by running checktransupdate.py over zh_TW to
> get a concrete inventory of what is stale and how far behind we are,
> and share the result here so we can prioritize together.
>
> > re-translation may be more efficient.
>
> Agreed for the badly outdated files -- patching a two-year-old
> translation line by line is likely more work than translating the
> current text afresh. The inventory should tell us which files fall
> into which category.
>
> > https://zh.wikibooks.org/wiki/%E5%A4%A7%E9%99%86%E5%8F%B0%E6%B9%BE%E8%AE%A1%E7%AE%97%E6%9C%BA%E6%9C%AF%E8%AF%AD%E5%AF%B9%E7%85%A7%E8%A1%A8
> >
> > Is it comprehensive? I don't know. Perhaps we could add some specific
> > reference tables related to the Linux Kernel on top of it.
>
> As a native speaker: it is a reasonable general reference, but it is
> not kernel-specific, and some entries are dated or not what people
> actually write in Taiwan today. I would rather build the glossary
> bottom-up from the terms that actually appear in the kernel docs
> (軟體/軟件, 介面/接口, 記憶體, 行程, 核心, 佇列, ...), and use the
> wikibooks table only as a cross-check. I will include the glossary as
> part of the first terminology series so it can be reviewed like any
> other patch.
>
> > Perhaps I can handle most of the operation and maintenance tasks of
> > chore, giving Chen-yu more time and concentration to focus on the actual
> > translation work.
>
> That would help a lot, thank you. It also sounds like a natural split:
> you on process and monitoring, me on the translation and the zh_TW
> terminology judgement.
>
> One last thing about the patch that started all this: rather than
> keeping the v2 for 8.Conclusion pending, I would suggest dropping it
> and folding its changes into the terminology series, so the fixes
> land in one consistent batch. Any objection?
>
> Thanks,
> Chen-Yu
>
> Weijie Yuan <wy@wyuan.org> 於 2026年7月13日週一 下午1:33寫道：
> >
> > On Mon, Jul 13, 2026 at 10:44:12AM +0800, 葉宸佑 wrote:
> > > Hi Weijie,
> > >
> > > > I suspect that some contributors would run the get_maintainers.pl script
> > > > or b4 prep --auto-to-cc, so they did not cc Alex, as they didn't know
> > > > the current situation. Because I noticed that for both two versions,
> > > > Chen-yu didn't cc Alex or Dongliang or Yanteng. Am I right, @Chen-yu? ;-)
> > >
> > > Yes, exactly. For both v1 and v2 I ran get_maintainer.pl, which only
> > > lists Hu Haowen and the mailing lists for zh_TW files, so Alex and the
> > > zh_CN team were never on cc.
> >
> > Right, let's note this situation down. We'll deal with it after we come
> > up with the final solution.
> >
> > >
> > > > Given that this document has not been maintained for ~2 years and these
> > > > patches to the terminology actually don't have much significance, it
> > > > might be more appropriate to directly declare the status of Traditional
> > > > Chinese as "Orphan" provisionally for now, and remove it directly in the
> > > > near future, until Hao Wen's return and opinion. Or maybe, waiting for a
> > > > new good soul to take over, which is unpredictable.
> > >
> > > Before it comes to that: I would like to step up and help carry zh_TW
> > > forward. I am a native zh_TW speaker from Taiwan, and I understand
> > > this means staying with it, not a one-off effort.
> >
> > Nice and thanks. Frankly speaking, At the very beginning, I did consider
> > saying that I also wanted to take over, and I wished I could. However,
> > considering that I was certainly not familiar with the traditional
> > Chinese terms used in Taiwan (although I knew some, that was all), I
> > finally chose to be speak more conservatively.
> >
> > > Dongliang, since you kindly offered to help review zh_TW patches:
> > > would you be open to doing this together -- either as co-maintainers,
> > > or with me listed as a reviewer (R:) first if that is a more
> > > reasonable starting point for a newcomer?
> >
> > Since I was the one who shamelessly initiated this discussion, I
> > definitely have the obligation to do something. See below...
> >
> > > > > To avoid scattering our efforts, I suggest we minimize fragmentation
> > > > > as much as possible. When it comes to technical documentation
> > > > > translation, not literary translation, a straightforward, unadorned,
> > > > > and free from misunderstandings is the best translation and easy to
> > > > > maintain. Let's keep thing simple, unless sth is really necessary.
> > >
> > > Alex, I think this concern is fair, and I have no intention of
> > > forking the translation effort. The scope I have in mind is
> > > deliberately narrow: keep zh_TW aligned with zh_CN in structure and
> > > coverage, and localize only where terminology genuinely differs
> > > (e.g. 軟體 vs 软件, 介面 vs 接口) -- exactly the kind of differences
> > > you mentioned. Plain, accurate technical translation, no literary
> > > rewriting.
> >
> > Exactly, before sending my first email here, I had already thought about
> > the following approach, what do you think?
> >
> > * Considering that English documents are changing so rapidly, and even
> > simplified Chinese cannot keep up with them immediately. I suggest
> > we start working on catching up with simplified Chinese right now,
> > which seems like a good place to begin. (ok... seems exactly what you said ;-)
> >
> > > Weijie, as a first concrete step I will prepare a terminology series
> > > (rather than one-word-at-a-time patches, as you suggested) covering
> > > the existing process/ documents, and use it to build a small glossary
> > > that future patches and reviews can follow.
> >
> > I used to read this:
> >
> > https://zh.wikibooks.org/wiki/%E5%A4%A7%E9%99%86%E5%8F%B0%E6%B9%BE%E8%AE%A1%E7%AE%97%E6%9C%BA%E6%9C%AF%E8%AF%AD%E5%AF%B9%E7%85%A7%E8%A1%A8
> >
> > Is it comprehensive? I don't know. Perhaps we could add some specific
> > reference tables related to the Linux Kernel on top of it.
> >
> > On Mon, Jul 13, 2026 at 11:49:07AM +0800, Dongliang Mu wrote:
> > > Chen-Yu,I would like to serve as co-maintainers to help maintain zh_TW. The
> > > script - tools/docs/checktransupdate.py can seamlessly work on zh_TW. This
> > > can help track the missing changes.
> >
> > I would also like to take a job ;-) while my current contributions are
> > not sufficient. And wish soon.
> >
> > > As discussed with Alex before, maybe zh_TW patches can first go to Alex's
> > > kernel tree and then push to Jon's tree. I am not sure if you are familar
> > > with the maintainer workflow. If not, this solution may be better for you to
> > > learn maintainer workflow.
> >
> > I suggest that we could try out the provisional plan for about one or
> > two months (depends), and then make a formal change.
> >
> > Before we make a formal change, I will monitor the list (CN & TW), If
> > there is any situation like this patch which is not sent correctly, I
> > will handle it promptly.
> >
> > OK, I consider myself quite familiar with the development process and
> > the maintenance process, mainly from Git (seems more complicated).
> > Perhaps I can handle most of the operation and maintenance tasks of
> > chore, giving Chen-yu more time and concentration to focus on the actual
> > translation work. But this can be further discussed.
> >
> > Thanks,
> > Weijie
^ permalink raw reply
* Re: [PATCH RESEND] riscv: enable HAVE_CMPXCHG_{DOUBLE,LOCAL}
From: Miquel Sabaté Solà @ 2026-07-13 9:09 UTC (permalink / raw)
To: Paul Walmsley
Cc: linux-riscv, corbet, skhan, palmer, alex, linux-doc, linux-kernel
In-Reply-To: <87ldc12wo0.fsf@mssola.com>
[-- Attachment #1: Type: text/plain, Size: 8195 bytes --]
Miquel Sabaté Solà @ 2026-06-26 16:39 +02:
> Hello,
>
> Miquel Sabaté Solà @ 2026-06-07 22:38 +02:
>
>> Hi,
>>
>> Paul Walmsley @ 2026-06-06 18:50 -06:
>>
>>> Hi,
>>>
>>> On Fri, 5 Jun 2026, Miquel Sabaté Solà wrote:
>>>
>>>> Support for atomic Compare-And-Swap instructions has been in the RISC-V
>>>> port of the Linux kernel for a long time. That being said, we apparently
>>>> never bothered to set HAVE_CMPXCHG_DOUBLE and HAVE_CMPXCHG_LOCAL in the
>>>> Kconfig, despite having all the framework to support them.
>>>>
>>>> Signed-off-by: Miquel Sabaté Solà <mssola@mssola.com>
>>>> ---
>>>> This is a resend of [1], rebased on top of the latest commit from the
>>>> for-next branch.
>>>>
>>>> I have built this patch with multiple configurations and ran it with KVM
>>>> (the VisionFive2 board that I have lacks the needed extensions). All seems
>>>> to work, but I do wonder if we did not enable these for a reason or this
>>>> just slipped through. So far in the code I believe everything is in place,
>>>> and I haven't seen any commit in the git log stating otherwise.
>>>>
>>>> [1] https://lore.kernel.org/all/20260220074449.8526-1-mssola@mssola.com/
>>>
>>> Thanks for the patch. Your comments above are why I've been hesitant to
>>> merge it. I'm not aware of any publicly available hardware that supports
>>> Zacas/Zabha. No one has stepped forward to provide any Tested-by:s on
>>> hardware that hasn't been released yet. You mention that you tested on
>>> your VisionFive2 board, but it would not have exercised those code paths.
>>
>> No, I mention that I ran it _only_ on KVM, as my VisionFive2 board lacks
>> these extensions and hence I couldn't possible have tested this there :)
>>
>>>
>>> Of course, we already have Zacas/Zabha support, merged back in 2024, in
>>> cmpxchg.h. I assume (?) that it was tested in QEMU, but I don't see any
>>> comments about that in the patch series. No one sent any Tested-by:s
>>> then, either.
>>>
>>> It would be good if you (and ideally others) could put this patch through
>>> some testing on QEMU with Zacas and Zabha enabled, before we merge it.
>>> The affected code paths for HAVE_CMPXCHG_LOCAL seem to primarily involve
>>> per-CPU counters and MM zone counters, so those would be the areas to
>>> focus. HAVE_CMPXCHG_DOUBLE seems to do nothing useful other than
>>> preventing the AMD IOMMU driver from being selected if it's not present,
>>> so that part of the patch seems fairly useless. In fact I'd suggest
>>> dropping that from the patch and just sending a separate patch to remove
>>> HAVE_CMPXCHG_DOUBLE from the kernel completely.
>>
>> To be fair, on QEMU I only "tested" it by booting it, running a few
>> things for some time and ensuring that nothing got totally broken in the
>> process while taking a look at the kernel logs.
>>
>> In any case, let me double check with QEMU with these extensions enabled
>> and I'll try to be more thorough about it. I'll do just that whenever I
>> have some spare time during the following week :)
>
> So much for "the following week" :) Sorry for being a bit late.
>
> I have finally taken a deeper look at this, and I have the following
> comments that I hope you can further clarify so we can land a more
> precise patch.
>
> First of all, HAVE_CMPXCHG_LOCAL is fundamentally used in two places: in
> mm/vmstat.c and in lib/percpu_counter.c. In the latter it is used in the
> percpu_counter_add_batch() function, which is used tree-wide. Hence,
> selecting this config option has a wide effect.
>
> As far as I can tell, both HAVE_CMPXCHG_LOCAL and HAVE_CMPXCHG_DOUBLE
> could have been added in this patch series [1] by Alexandre Ghiti, but
> I've been unable to tell how it was actually tested (no mentions on that
> on no Tested-by either). On my side, the board I have doesn't have
> neither Zacas nor the Zabha extensions so, as I mentioned on my previous
> email, I have to test everything via KVM.
>
> Having that into account, if I build the kernel with or without the
> patch applied, functions like percpu_counter_add_batch() have a
> different implementation, as expected (good ol' objdump -d vmlinux
> --disassemble=percpu_counter_add_batch confirmed as much); and from a
> general outlook, the given assembly code is what I'd expect. In order to
> test it, I have to say that I've relied on checking that selftests and
> similar continue to pass before/after the patch. In particular, I've run
> the selftests from btrfs, and they seem just fine (and toggling a
> breakpoint inside of percpu_counter_add_batch() confirms that it's being
> constantly called, so we are definitely calling the "new" code).
>
>>
>> As for HAVE_CMPXCHG_DOUBLE, removing it makes sense. Let me just take
>> another look and I will send a separate patch whenever I'm ready for it.
>
> Here I'm a bit conflicted, because you mentioned that it's only used for the AMD
> IOMMU driver, but support on different architectures like 5284e1b4bc8a ("arm64:
> xchg: Implement cmpxchg_double") or f0e4b1b6e295 ("LoongArch: Add 128-bit atomic
> cmpxchg support") hint into other places where this is needed. In fact, for
> loongarch, it's apparently needed to fix multiple tests on sched_ext. Thus, I
> believe that sending a patch to drop it from the kernel would be misguided.
>
> As for RISC-V, first of all I believe that my patch should've also included that
> HAVE_CMPXCHG_DOUBLE can only be selected on CONFIG_64BIT. In fact, commit
> f7bd2be7663c ("riscv: Implement arch_cmpxchg128() using Zacas"), which brings
> support for this (again, from the same series [1]), also requires this
> configuration option. That being said, this commit doesn't say how it was
> tested, and there are not Tested-by either. On my end, so far I got no luck
> trying the sched_ext route mentioned in the loongarch support, which is a bit of
> a hussle in KVM with cross-compilation and the library requirements.
>
> But as a final note, I have used hackbench on this. I have statically compiled
> hackbench from source [2] at commit e6fb0b2c8ad1 ("rt-tests: Add AGENTS.md guide
> for AI coding assistants") (i.e. current master). This binary has been deployed
> in three iterations where the kernel was built as:
>
> 1. Before the patch.
> 2. With the patch (both HAVE_CMPXCHG_LOCAL and HAVE_CMPXCHG_DOUBLE selected).
> 3. With only HAVE_CMPXCHG_LOCAL selected.
>
> Again, given that I can only test this on QEMU, this whole thing is tested on
> virtualized environments, so take it with a grain of salt :)
>
> In any case, I got the following results:
>
> | | Mainline | Both selected | Only _LOCAL selected |
> |--------+----------+---------------+----------------------|
> | Mean | 50.9966 | 54.2076 | 51.6488 |
> | StdDev | 0.1508 | 0.1097 | 0.7051 |
>
> As you can see, the results on Mainline and "only _LOCAL selected" are more or
> less the same, but not so much whenever _DOUBLE is also selected. I figure that
> that these instructions are not as fast as expected on my virtualized
> environment.
>
> With all of this, I'm torned on whether we should include HAVE_CMPXCHG_DOUBLE,
> as code-wise is pretty much the same as HAVE_CMPXCHG_LOCAL, but I can also see
> how it can be removed as I cannot properly test it. As a middle ground, maybe we
> can leave a TODO in __arch_cmpxchg128() asking to introduce HAVE_CMPXCHG_DOUBLE
> whenever someone can actually test it and guarantee that there are no
> performance penalties as I saw on my virtualized environment.
>
> And that's enough of my rumblings :) I'd appreciate any comments on this.
>
> Thanks,
> Miquel
>
> [1] https://lore.kernel.org/all/20241103145153.105097-1-alexghiti@rivosinc.com/
> [2] https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git
>
>>
>>>
>>>
>>> - Paul
>>
>> Thanks for your input!
>> Miquel
>>
>> _______________________________________________
>> linux-riscv mailing list
>> linux-riscv@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-riscv
Gently ping :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 897 bytes --]
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Dongliang Mu @ 2026-07-13 9:41 UTC (permalink / raw)
To: 葉宸佑, Weijie Yuan
Cc: Alex Shi, Hu Haowen, Jonathan Corbet, Shuah Khan, Dongliang Mu,
linux-doc, linux-kernel, Yuchen Tian, Alex Shi, Yanteng Si
In-Reply-To: <CAKspUhLaCuBOHy9L5DMYBUq4kk_8hgFXfGHzhGXjvS_9iqNFUg@mail.gmail.com>
On 7/13/26 5:03 PM, 葉宸佑 wrote:
> Here is the inventory I promised, from checktransupdate.py on mainline:
>
> zh_TW: 51 translated files, all out of date
> 221 distinct English commits to catch up with
>
> process/ 14 files
> admin-guide/ 15
> arch/ 12
> dev-tools/ 5
> filesystems/ 3
> cpu-freq/ 1
> index.rst 1
>
> For calibration I ran the same tool on zh_CN: 178 translated files,
> also all out of date, 639 distinct commits behind. So in terms of
For many files, the missing commits might not be needed as they might
not affect the translation (such as typos in English).
Because this new commit style is developed recently by Yanteng and me,
many translated documenation does not tranform to the corresponding styles.
> drift from the English originals, zh_TW is not in a categorically
> different state from zh_CN -- the real gap is coverage (51 vs 178
> files), not decay. That makes me more optimistic than the "two years
> of stagnation" framing suggests: many zh_TW files are only behind by
> a typo fix or two.
>
> (The ~3300 documents with no Chinese translation at all are out of
> scope for both locales, so I do not think that is the problem to
> solve first.)
Yes, we need more volunteers to translate English documents. However,
translation is not attractive in the LLM era. :(
>
> One thing I noticed while reading the script: checktransupdate.py
> tracks the base commit accurately only when the translation commit
> message contains "update to commit HASH" (or "Update the translation
> through commit HASH"); otherwise it falls back to guessing from author
> dates. Adopting that convention for zh_TW commits from now on would
> make the tool's numbers reliable, and it costs nothing. Perhaps that
> could be part of the "more reasonable workflow" Weijie mentioned.
Yes, if zh_TW can apply this convention the workflow would be more
reasonable.
>
> My suggestion for the first step is process/ (14 files): it is where
> new contributors land first, it is small enough to finish as one
> series, and it is where the terminology differences are most visible.
> I would fold the pending 8.Conclusion patch into that series and build
> the glossary from it.
For the todo list, you can check Jon's advice for new languages, e.g.,
Spanish. Search it from LKML
Dongliang Mu
>
> 葉宸佑 <chenyou910331@gmail.com> 於 2026年7月13日週一 下午2:35寫道：
>> Hi Dongliang, Weijie,
>>
>> Thank you both -- this is more support than I expected, and I am glad
>> to do this together.
>>
>>> Chen-Yu, I would like to serve as co-maintainers to help maintain zh_TW.
>>> [...]
>>> As discussed with Alex before, maybe zh_TW patches can first go to
>>> Alex's kernel tree and then push to Jon's tree. I am not sure if you are
>>> familar with the maintainer workflow. If not, this solution may be
>>> better for you to learn maintainer workflow.
>> To be honest: no, I am not familiar with the maintainer workflow yet --
>> so far I have only been on the contributor side. So routing zh_TW
>> patches through Alex's tree first sounds like the right arrangement to
>> me, both for reliability and so that I can learn the workflow properly
>> before taking on more. Alex, if you are fine with this, thank you in
>> advance.
>>
>>> I suggest that we could try out the provisional plan for about one or
>>> two months (depends), and then make a formal change.
>> Agreed. A trial period before touching MAINTAINERS is fair -- it lets
>> the work speak first. I will send the MAINTAINERS patch when you both
>> feel the arrangement has proven itself.
>>
>>> * Considering that English documents are changing so rapidly, and even
>>> simplified Chinese cannot keep up with them immediately. I suggest
>>> we start working on catching up with simplified Chinese right now,
>>> which seems like a good place to begin.
>> This matches what I had in mind, and it also answers Alex's concern:
>> zh_TW should track zh_CN in structure and coverage, and differ only in
>> terminology. I will start by running checktransupdate.py over zh_TW to
>> get a concrete inventory of what is stale and how far behind we are,
>> and share the result here so we can prioritize together.
>>
>>> re-translation may be more efficient.
>> Agreed for the badly outdated files -- patching a two-year-old
>> translation line by line is likely more work than translating the
>> current text afresh. The inventory should tell us which files fall
>> into which category.
>>
>>> https://zh.wikibooks.org/wiki/%E5%A4%A7%E9%99%86%E5%8F%B0%E6%B9%BE%E8%AE%A1%E7%AE%97%E6%9C%BA%E6%9C%AF%E8%AF%AD%E5%AF%B9%E7%85%A7%E8%A1%A8
>>>
>>> Is it comprehensive? I don't know. Perhaps we could add some specific
>>> reference tables related to the Linux Kernel on top of it.
>> As a native speaker: it is a reasonable general reference, but it is
>> not kernel-specific, and some entries are dated or not what people
>> actually write in Taiwan today. I would rather build the glossary
>> bottom-up from the terms that actually appear in the kernel docs
>> (軟體/軟件, 介面/接口, 記憶體, 行程, 核心, 佇列, ...), and use the
>> wikibooks table only as a cross-check. I will include the glossary as
>> part of the first terminology series so it can be reviewed like any
>> other patch.
>>
>>> Perhaps I can handle most of the operation and maintenance tasks of
>>> chore, giving Chen-yu more time and concentration to focus on the actual
>>> translation work.
>> That would help a lot, thank you. It also sounds like a natural split:
>> you on process and monitoring, me on the translation and the zh_TW
>> terminology judgement.
>>
>> One last thing about the patch that started all this: rather than
>> keeping the v2 for 8.Conclusion pending, I would suggest dropping it
>> and folding its changes into the terminology series, so the fixes
>> land in one consistent batch. Any objection?
>>
>> Thanks,
>> Chen-Yu
>>
>> Weijie Yuan <wy@wyuan.org> 於 2026年7月13日週一 下午1:33寫道：
>>> On Mon, Jul 13, 2026 at 10:44:12AM +0800, 葉宸佑 wrote:
>>>> Hi Weijie,
>>>>
>>>>> I suspect that some contributors would run the get_maintainers.pl script
>>>>> or b4 prep --auto-to-cc, so they did not cc Alex, as they didn't know
>>>>> the current situation. Because I noticed that for both two versions,
>>>>> Chen-yu didn't cc Alex or Dongliang or Yanteng. Am I right, @Chen-yu? ;-)
>>>> Yes, exactly. For both v1 and v2 I ran get_maintainer.pl, which only
>>>> lists Hu Haowen and the mailing lists for zh_TW files, so Alex and the
>>>> zh_CN team were never on cc.
>>> Right, let's note this situation down. We'll deal with it after we come
>>> up with the final solution.
>>>
>>>>> Given that this document has not been maintained for ~2 years and these
>>>>> patches to the terminology actually don't have much significance, it
>>>>> might be more appropriate to directly declare the status of Traditional
>>>>> Chinese as "Orphan" provisionally for now, and remove it directly in the
>>>>> near future, until Hao Wen's return and opinion. Or maybe, waiting for a
>>>>> new good soul to take over, which is unpredictable.
>>>> Before it comes to that: I would like to step up and help carry zh_TW
>>>> forward. I am a native zh_TW speaker from Taiwan, and I understand
>>>> this means staying with it, not a one-off effort.
>>> Nice and thanks. Frankly speaking, At the very beginning, I did consider
>>> saying that I also wanted to take over, and I wished I could. However,
>>> considering that I was certainly not familiar with the traditional
>>> Chinese terms used in Taiwan (although I knew some, that was all), I
>>> finally chose to be speak more conservatively.
>>>
>>>> Dongliang, since you kindly offered to help review zh_TW patches:
>>>> would you be open to doing this together -- either as co-maintainers,
>>>> or with me listed as a reviewer (R:) first if that is a more
>>>> reasonable starting point for a newcomer?
>>> Since I was the one who shamelessly initiated this discussion, I
>>> definitely have the obligation to do something. See below...
>>>
>>>>>> To avoid scattering our efforts, I suggest we minimize fragmentation
>>>>>> as much as possible. When it comes to technical documentation
>>>>>> translation, not literary translation, a straightforward, unadorned,
>>>>>> and free from misunderstandings is the best translation and easy to
>>>>>> maintain. Let's keep thing simple, unless sth is really necessary.
>>>> Alex, I think this concern is fair, and I have no intention of
>>>> forking the translation effort. The scope I have in mind is
>>>> deliberately narrow: keep zh_TW aligned with zh_CN in structure and
>>>> coverage, and localize only where terminology genuinely differs
>>>> (e.g. 軟體 vs 软件, 介面 vs 接口) -- exactly the kind of differences
>>>> you mentioned. Plain, accurate technical translation, no literary
>>>> rewriting.
>>> Exactly, before sending my first email here, I had already thought about
>>> the following approach, what do you think?
>>>
>>> * Considering that English documents are changing so rapidly, and even
>>> simplified Chinese cannot keep up with them immediately. I suggest
>>> we start working on catching up with simplified Chinese right now,
>>> which seems like a good place to begin. (ok... seems exactly what you said ;-)
>>>
>>>> Weijie, as a first concrete step I will prepare a terminology series
>>>> (rather than one-word-at-a-time patches, as you suggested) covering
>>>> the existing process/ documents, and use it to build a small glossary
>>>> that future patches and reviews can follow.
>>> I used to read this:
>>>
>>> https://zh.wikibooks.org/wiki/%E5%A4%A7%E9%99%86%E5%8F%B0%E6%B9%BE%E8%AE%A1%E7%AE%97%E6%9C%BA%E6%9C%AF%E8%AF%AD%E5%AF%B9%E7%85%A7%E8%A1%A8
>>>
>>> Is it comprehensive? I don't know. Perhaps we could add some specific
>>> reference tables related to the Linux Kernel on top of it.
>>>
>>> On Mon, Jul 13, 2026 at 11:49:07AM +0800, Dongliang Mu wrote:
>>>> Chen-Yu,I would like to serve as co-maintainers to help maintain zh_TW. The
>>>> script - tools/docs/checktransupdate.py can seamlessly work on zh_TW. This
>>>> can help track the missing changes.
>>> I would also like to take a job ;-) while my current contributions are
>>> not sufficient. And wish soon.
>>>
>>>> As discussed with Alex before, maybe zh_TW patches can first go to Alex's
>>>> kernel tree and then push to Jon's tree. I am not sure if you are familar
>>>> with the maintainer workflow. If not, this solution may be better for you to
>>>> learn maintainer workflow.
>>> I suggest that we could try out the provisional plan for about one or
>>> two months (depends), and then make a formal change.
>>>
>>> Before we make a formal change, I will monitor the list (CN & TW), If
>>> there is any situation like this patch which is not sent correctly, I
>>> will handle it promptly.
>>>
>>> OK, I consider myself quite familiar with the development process and
>>> the maintenance process, mainly from Git (seems more complicated).
>>> Perhaps I can handle most of the operation and maintenance tasks of
>>> chore, giving Chen-yu more time and concentration to focus on the actual
>>> translation work. But this can be further discussed.
>>>
>>> Thanks,
>>> Weijie
^ permalink raw reply
* Re: [PATCH v7 07/17] iio: test: add kunit tests for channel prefix naming generation
From: Rodrigo Alencar @ 2026-07-13 9:52 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar via B4 Relay
Cc: linux-iio, devicetree, linux-kernel, linux-doc, linux-hardening,
Lars-Peter Clausen, Michael Hennerich, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <20260712020928.2c8d1667@jic23-huawei>
On 12/07/26 02:09, Jonathan Cameron wrote:
> On Tue, 07 Jul 2026 15:04:28 +0100
> Rodrigo Alencar via B4 Relay <devnull+rodrigo.alencar.analog.com@kernel.org> wrote:
>
> > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> >
> > Add a KUnit test suite covering __iio_chan_prefix_emit(), the helper
> > that builds IIO sysfs attribute name prefixes from an iio_chan_spec.
> > The suite groups cases by the enum iio_shared_by mode it exercises:
> >
> > - IIO_SHARED_BY_ALL: produces an empty prefix.
> > - IIO_SHARED_BY_DIR: emits direction only ("in" / "out").
> > - IIO_SHARED_BY_TYPE: emits "<dir>_<type>" and the differential
> > "<dir>_<type>-<type>" variant.
> > - IIO_SEPARATE: covers the full matrix of indexed, differential,
> > modified, output and extend_name combinations, plus the two
> > documented error paths (differential without indexed, differential
> > with modifier).
> >
> > A final case exercises the seq_buf overflow path by passing an
> > undersized buffer and expects -EOVERFLOW.
> >
> > Because __iio_chan_prefix_emit() is static, the test translation unit
> > is pulled into industrialio-core.c.
>
> Isn't there some magic route cases like this that makes it non static
> only when self tests are enabled?
> Claude tells me to look at include/kunit/visibility.h
There is, Although I think that using
#if IS_ENABLED(CONFIG_IIO_CHANNEL_PREFIX_KUNIT_TEST)
#include "test/iio-test-channel-prefix.c"
#endif
was more straight forward, less invasive and easier to change than..
/* In "drivers/iio/industrialio-core.c" */
#include <kunit/visibility.h>
...
VISIBLE_IF_KUNIT ssize_t __iio_chan_prefix_emit(...)
{
...
}
EXPORT_SYMBOL_IF_KUNIT(__iio_chan_prefix_emit);
/* In "iio_core.h" */
#if IS_ENABLED(CONFIG_KUNIT)
ssize_t __iio_chan_prefix_emit(...);
#endif
/* In "drivers/iio/test/iio-test-channel-prefix.c" */
#include <kunit/visibility.h>
#include <iio_core.h>
...
MODULE_IMPORT_NS("EXPORTED_FOR_KUNIT_TESTING");
...
// Use __iio_chan_prefix_emit() in tests
>
> Very nice. A couple of really small additions requested inline.
> I might well have missed where you exercised the corners requested though!
> + I'll need an Ack from Lars for that maintainers entry. I'll guess that
> Lars won't give one as not very active at the moment in this area.
>
> Jonathan
>
> >
> > Also, an entry is created under MAINTAINERS dedicated to tests for IIO
> > core helpers.
> >
> > Signed-off-by: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > ---
> > MAINTAINERS | 8 +
> > drivers/iio/industrialio-core.c | 4 +
> > drivers/iio/test/Kconfig | 14 ++
> > drivers/iio/test/iio-test-channel-prefix.c | 246 +++++++++++++++++++++++++++++
> > 4 files changed, 272 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 2b1ec46c5919..57ffc0dcfdb6 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -12634,6 +12634,14 @@ F: include/dt-bindings/iio/
> > F: include/linux/iio/
> > F: tools/iio/
> >
> > +IIO CORE KUNIT TESTS
> > +M: Lars-Peter Clausen <lars@metafoo.de>
>
> I'd need an Ack from Lars for this entry. If we don't get one are you
> fine looking after this without Lars listed?
That is fine, will drop his name.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v2] arch: arm64: add early_param idle=<wfi|yield|nop>
From: Sudeep Holla @ 2026-07-13 9:57 UTC (permalink / raw)
To: Yureka Lilian
Cc: Jonathan Corbet, Sudeep Holla, Shuah Khan, Catalin Marinas,
Will Deacon, Anshuman Khandual, linux-doc, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260711-arm64-idle-param-v2-1-0ab67652a435@cyberchaos.dev>
On Sat, Jul 11, 2026 at 09:35:25AM +0200, Yureka Lilian wrote:
> Overriding the idle mechanism might be useful for debugging and performance
> testing. Add a cmdline parameter for it, similar to the existing idle=
> parameter already present for the x86 and ppc architectures.
>
> It is also useful on platforms where the WFI instruction misbehaves,
> such as Apple Silicon SoCs. Generally, a misbehaving instruction should
> be treated as an erratum and patched using the alternatives framework.
> However, in the Apple Silicon case we need more flexibility because it is
> difficult to detect whether the erratum applies. For example, Linux VMs
> inside macOS have the same MIDR and may even seem like they're running
> in EL2 in the case of NV, but should continue using WFI (it's trapped and
> handled correctly by the hypervisor there). Thus, we prefer to
> let the m1n1 bootloader add the idle=nop parameter[1].
>
> Link[1]: https://lore.kernel.org/all/99b69262-e54b-424e-baa2-96ef7013b87a@kernel.org/
> Suggested-by: Will Deacon <will@kernel.org>
> Signed-off-by: Yureka Lilian <yureka@cyberchaos.dev>
> ---
> Changes in v2:
> - Applied suggestions by Anshuman Khandual (Thanks!)
> - Link to v1: https://patch.msgid.link/20260705-arm64-idle-param-v1-1-7454249f473f@cyberchaos.dev
> ---
> Documentation/admin-guide/kernel-parameters.txt | 23 +++++++++++++++++++
> arch/arm64/kernel/idle.c | 30 +++++++++++++++++++++++--
> arch/arm64/kernel/idle.h | 13 +++++++++++
> arch/arm64/lib/delay.c | 5 ++++-
> 4 files changed, 68 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index b2d7d3540ded..d7f5471edf8f 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2239,6 +2239,29 @@ Kernel parameters
>
> idle=nomwait: Disable mwait for CPU C-states
>
> + [ARM64,EARLY]
> + Format: idle=wfi, idle=yield, idle=nop
> +
> + idle=wfi: Use the WFI (Wait For Interrupt) hint
> + instruction in the idle loop. This is the default and
> + allows the CPU to enter a low-power state until an
> + interrupt arrives.
Just curious as when and why one would need to use idle=wfi if that is the
default behaviour. I am missing the need to have it.
> +
> + idle=yield: Use the YIELD hint instruction instead of
> + WFI. CPUs supporting simultaneous multi-threading (SMT),
> + can continue executing another thread when the current
> + thread reaches the idle loop. This will make the CPUs
> + eat more power, but may be useful to get slightly better
> + performance in some applications, since the CPUs will
> + not enter a low-power state.
> +
> + idle=nop: Do not execute any idle instruction in the
> + idle loop. This is useful on platforms where WFI
> + misbehaves, leading to system instability or loss of CPU
> + state. This will make the CPUs eat more power, but may
> + give slightly better performance in some applications,
> + since the CPUs will not enter a low-power state.
> +
> idxd.sva= [HW]
> Format: <bool>
> Allow force disabling of Shared Virtual Memory (SVA)
> diff --git a/arch/arm64/kernel/idle.c b/arch/arm64/kernel/idle.c
> index 05cfb347ec26..f161711a9954 100644
> --- a/arch/arm64/kernel/idle.c
> +++ b/arch/arm64/kernel/idle.c
> @@ -11,6 +11,27 @@
> #include <asm/cpufeature.h>
> #include <asm/sysreg.h>
>
> +#include "idle.h"
> +
> +enum arm64_idle_mode idle = ARM64_IDLE_WFI;
> +
> +static int __init setup_idle(char *arg)
> +{
> + if (!arg)
> + return -1;
> + else if (!strcmp(arg, "wfi"))
> + idle = ARM64_IDLE_WFI;
> + else if (!strcmp(arg, "yield"))
> + idle = ARM64_IDLE_YIELD;
> + else if (!strcmp(arg, "nop"))
> + idle = ARM64_IDLE_NOP;
> + else
> + return -1;
> +
> + return 0;
> +}
> +early_param("idle", setup_idle);
> +
> /*
> * cpu_do_idle()
> *
> @@ -26,8 +47,13 @@ void __cpuidle cpu_do_idle(void)
>
> arm_cpuidle_save_irq_context(&context);
>
> - dsb(sy);
> - wfi();
> + if (likely(idle == ARM64_IDLE_WFI)) {
> + dsb(sy);
> + wfi();
> + } else if (idle == ARM64_IDLE_YIELD) {
> + dsb(sy);
> + asm volatile("yield" ::: "memory");
> + }
>
> arm_cpuidle_restore_irq_context(&context);
If WFI is replaced by NOP or YIELD, do we really need to save/restore
IRQ context used for pseudo-NMIs which may add some overhead ?
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Weijie Yuan @ 2026-07-13 10:23 UTC (permalink / raw)
To: 葉宸佑, Dongliang Mu
Cc: Alex Shi, Hu Haowen, Jonathan Corbet, Shuah Khan, Dongliang Mu,
linux-doc, linux-kernel, Yuchen Tian, Alex Shi, Yanteng Si
In-Reply-To: <21179a3c-60d6-40b0-a5b1-594e989ef508@hust.edu.cn>
On Mon, Jul 13, 2026 at 02:35:22PM +0800, 葉宸佑 wrote:
> Hi Dongliang, Weijie,
>
> Thank you both -- this is more support than I expected, and I am glad
> to do this together.
>
> > Chen-Yu, I would like to serve as co-maintainers to help maintain zh_TW.
> > [...]
> > As discussed with Alex before, maybe zh_TW patches can first go to
> > Alex's kernel tree and then push to Jon's tree. I am not sure if you are
> > familar with the maintainer workflow. If not, this solution may be
> > better for you to learn maintainer workflow.
>
> To be honest: no, I am not familiar with the maintainer workflow yet --
> so far I have only been on the contributor side. So routing zh_TW
> patches through Alex's tree first sounds like the right arrangement to
> me, both for reliability and so that I can learn the workflow properly
> before taking on more. Alex, if you are fine with this, thank you in
> advance.
>
> > I suggest that we could try out the provisional plan for about one or
> > two months (depends), and then make a formal change.
>
> Agreed. A trial period before touching MAINTAINERS is fair -- it lets
> the work speak first. I will send the MAINTAINERS patch when you both
> feel the arrangement has proven itself.
Yeah, of course, this is not questioning your abilities at all. Winning
the trust of the community step by step in a gradual manner is
definitely better. This is something I have once again realized while
going through the lore archives of how the Git localization was done. By
reading their historical exchanges (between Junio C Hamano and Jiang
Xin), we might be able to obtain some practical experience and
precautions regarding the process. But this is not something that needs
to be considered at present.
> > https://zh.wikibooks.org/wiki/%E5%A4%A7%E9%99%86%E5%8F%B0%E6%B9%BE%E8%AE%A1%E7%AE%97%E6%9C%BA%E6%9C%AF%E8%AF%AD%E5%AF%B9%E7%85%A7%E8%A1%A8
> >
> > Is it comprehensive? I don't know. Perhaps we could add some specific
> > reference tables related to the Linux Kernel on top of it.
>
> As a native speaker: it is a reasonable general reference, but it is
> not kernel-specific, and some entries are dated or not what people
> actually write in Taiwan today. I would rather build the glossary
> bottom-up from the terms that actually appear in the kernel docs
> (軟體/軟件, 介面/接口, 記憶體, 行程, 核心, 佇列, ...), and use the
> wikibooks table only as a cross-check.
Ah got it, so this is why we need a local to guard a pass ;-)
> I will include the glossary as part of the first terminology series so
> it can be reviewed like any other patch.
Very much appreciated.
> > Perhaps I can handle most of the operation and maintenance tasks of
> > chore, giving Chen-yu more time and concentration to focus on the actual
> > translation work.
>
> That would help a lot, thank you. It also sounds like a natural split:
> you on process and monitoring, me on the translation and the zh_TW
> terminology judgement.
>
> One last thing about the patch that started all this: rather than
> keeping the v2 for 8.Conclusion pending, I would suggest dropping it
> and folding its changes into the terminology series, so the fixes
> land in one consistent batch. Any objection?
I definitely agree. Batching them would be easier to review and
retrospect, and it's better to track on the list.
On Mon, Jul 13, 2026 at 05:03:12PM +0800, 葉宸佑 wrote:
> Here is the inventory I promised, from checktransupdate.py on mainline:
>
> zh_TW: 51 translated files, all out of date
> 221 distinct English commits to catch up with
>
> process/ 14 files
> admin-guide/ 15
> arch/ 12
> dev-tools/ 5
> filesystems/ 3
> cpu-freq/ 1
> index.rst 1
>
> For calibration I ran the same tool on zh_CN: 178 translated files,
> also all out of date, 639 distinct commits behind. So in terms of
> drift from the English originals, zh_TW is not in a categorically
> different state from zh_CN -- the real gap is coverage (51 vs 178
> files), not decay.
> That makes me more optimistic than the "two years of stagnation"
> framing suggests: many zh_TW files are only behind by a typo fix or
> two.
Then I'm exaggerating, oops.
> (The ~3300 documents with no Chinese translation at all are out of
> scope for both locales, so I do not think that is the problem to
> solve first.)
Yes, and I suspect that some of the documents might not actually need to
be translated? I will conduct some more investigations.
> One thing I noticed while reading the script: checktransupdate.py
> tracks the base commit accurately only when the translation commit
> message contains "update to commit HASH" (or "Update the translation
> through commit HASH"); otherwise it falls back to guessing from author
> dates. Adopting that convention for zh_TW commits from now on would
> make the tool's numbers reliable, and it costs nothing. Perhaps that
> could be part of the "more reasonable workflow" Weijie mentioned.
Yes, and that's documented in here,
https://docs.kernel.org/translations/zh_CN/how-to.html
so later zh_TW could consider making one.
> My suggestion for the first step is process/ (14 files): it is where
> new contributors land first, it is small enough to finish as one
> series, and it is where the terminology differences are most visible.
> I would fold the pending 8.Conclusion patch into that series and build
> the glossary from it.
Agreed. The significance of the initial stage for newcomers is
self-evident. Of course, the English documents have undoubtedly been
constantly revised over time. So for these two Chinese documents, this
part is of crucial importance. After all, this is where almost everyone
begins to read, including me. So when I found that there was a Chinese
translation here, I was very happy ;-)
--------------------------------------------------------------------------
On Mon, Jul 13, 2026 at 05:41:31PM +0800, Dongliang Mu wrote:
>
> On 7/13/26 5:03 PM, 葉宸佑 wrote:
> > Here is the inventory I promised, from checktransupdate.py on mainline:
> >
> > zh_TW: 51 translated files, all out of date
> > 221 distinct English commits to catch up with
> >
> > process/ 14 files
> > admin-guide/ 15
> > arch/ 12
> > dev-tools/ 5
> > filesystems/ 3
> > cpu-freq/ 1
> > index.rst 1
> >
> > For calibration I ran the same tool on zh_CN: 178 translated files,
> > also all out of date, 639 distinct commits behind. So in terms of
>
> For many files, the missing commits might not be needed as they might not
> affect the translation (such as typos in English).
>
> Because this new commit style is developed recently by Yanteng and me, many
> translated documenation does not tranform to the corresponding styles.
>
> > drift from the English originals, zh_TW is not in a categorically
> > different state from zh_CN -- the real gap is coverage (51 vs 178
> > files), not decay. That makes me more optimistic than the "two years
> > of stagnation" framing suggests: many zh_TW files are only behind by
> > a typo fix or two.
> >
> > (The ~3300 documents with no Chinese translation at all are out of
> > scope for both locales, so I do not think that is the problem to
> > solve first.)
>
> Yes, we need more volunteers to translate English documents. However,
> translation is not attractive in the LLM era. :(
OK, the AI thing has still inevitably come up ;-)
I can spend an entire afternoon reading the discussion emails and
articles about AI/LLM in the community ;-)
Sidenote:
I noticed that there seems to be renewed discussion in the English
document section about removing the "assisted-by" trailer. It would be
a good idea to make a note of this and see if we need to update any
relevant sections.
However, personally speaking, I still prefer to read the official
website's documents. It was written by the developers, and of course it
is more authoritative than the content produced by AI/LLM. And sometimes
the information provided by the AI/LLM is a bit behind the information
on the official website kernel.org.
> For the todo list, you can check Jon's advice for new languages, e.g.,
> Spanish. Search it from LKML
Thanks, I'll learn about it too.
^ 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