* What's cooking in zh_CN (Jul 2026)
From: Weijie Yuan @ 2026-07-13 16:49 UTC (permalink / raw)
To: linux-doc
Cc: Alex Shi, Yanteng Si, Dongliang Mu, Ben Guo, Gary Guo, Yan Zhu,
Doehyun Baek, Jiandong Qiu, chengyaqiang
Hi all,
Since I made many noise these days on the list, which took up a lot of
maintainers' time. This email summarizes the patches for zh_CN that are
currently pending on the mailing list.
-----------------------------------------------------------------------
* Ben Guo (2026-07-13) 4 commits
[PATCH v2 0/4] docs/zh_CN: update rust documentation translations
[PATCH v2 1/4] docs/zh_CN: Update rust/quick-start.rst translation
[PATCH v2 2/4] docs/zh_CN: Update rust/general-information.rst translation
[PATCH v2 3/4] docs/zh_CN: Update rust/arch-support.rst translation
[PATCH v2 4/4] docs/zh_CN: Update rust/testing.rst translation
Reviewed by Dongliang, a part needs to be revised. Expecting a reroll.
cf. https://lore.kernel.org/linux-doc/17094968-1385-4dba-aae8-5d93a2aaf59e@hust.edu.cn/
source: https://lore.kernel.org/linux-doc/cover.1783905132.git.ben.guo@openatom.club/
* Doehyun Baek (2026-07-08) 7 commits
[PATCH v6 0/7] docs/zh_CN: update DAMON translations
[PATCH v6 1/7] docs/zh_CN: update DAMON design translation
[PATCH v6 2/7] docs/zh_CN: add DAMON_STAT usage translation
[PATCH v6 3/7] docs/zh_CN: update DAMON index translation
[PATCH v6 4/7] docs/zh_CN: update DAMON start translation
[PATCH v6 5/7] docs/zh_CN: update DAMON usage translation
[PATCH v6 6/7] docs/zh_CN: update DAMON reclaim translation
[PATCH v6 7/7] docs/zh_CN: update DAMON LRU sort translation
Needs review.
source: https://lore.kernel.org/linux-doc/20260708073246.1652828-1-doehyunbaek@gmail.com/
* Jiandong Qiu 2026-07-06 2 commits
[PATCH v3 0/2] docs/zh_CN: update translation of doc-guide/sphinx.rst
[PATCH v3 1/2] docs/zh_CN: add process/changes.rst translation
[PATCH v3 2/2] docs/zh_CN: update sphinx.rst translation
Waiting for response(s) to review comment(s). & Needs review.
cf. https://lore.kernel.org/linux-doc/ak1SG5mw7y2UZrvR@wyuan.org/
source: https://lore.kernel.org/linux-doc/20260706151358.2103703-1-qiujiandong1998@gmail.com/
* Yan Zhu (2026-06-12) 10 commits
[not found] <cover.1781105672.git.zhuyan2015@qq.com>
[PATCH 01/10] docs/zh_CN: add LSM/index Chinese translation
[PATCH 02/10] docs/zh_CN: add LSM/apparmor Chinese translation
[PATCH 03/10] docs/zh_CN: add LSM/LoadPin Chinese translation
[PATCH 04/10] docs/zh_CN: add LSM/SELinux Chinese translation
[PATCH 05/10] docs/zh_CN: add LSM/Smack Chinese translation
[PATCH 06/10] docs/zh_CN: add LSM/tomoyo Chinese translation
[PATCH 07/10] docs/zh_CN: add LSM/Yama Chinese translation
[PATCH 08/10] docs/zh_CN: add LSM/SafeSetID Chinese translation
[PATCH 09/10] docs/zh_CN: add LSM/ipe Chinese translation
[PATCH 10/10] docs/zh_CN: add LSM/landlock Chinese translation
Needs review.
source: https://lore.kernel.org/linux-doc/tencent_7080BF6BB8F05936649DDC091FFD8C45210A@qq.com/
Note: cover letter missing on lore archive.
* chengyaqiang (2026-05-22) 1 commit
[PATCH] docs/zh_CN: fix KASAN SW_TAGS mode description
Reviewed by Dongliang and Zenghui, will merge to docs-next @alex ?
source: https://lore.kernel.org/linux-doc/20260522075735.2022734-1-chengyaqiang@chengyaqiang.com/
* Haoyang Liu (2026-03-05) 1 commit
[PATCH] docs/zh_CN: fix an inconsistent statement in dev-tools/testing-overview
Expecting a reroll.
cf. https://lore.kernel.org/linux-doc/29bd0dbc-c6f9-43ce-b95f-4e787e3fe9c3@gmail.com/
source: https://lore.kernel.org/linux-doc/20260305192048.16405-1-tttturtleruss@gmail.com/
-----------------------------------------------------------------------
Okay, I have checked the 200 most recent messages on the mailing list,
going back to 15:09 UTC on February 25, 2026. If I have missed anything,
or I made a mistake somewhere, please let me know.
As you may have noticed, I borrowed (stole) this idea from Junio C
Hamano. Sending this kind of message, somewhat like a weekly status
report, not only helps maintainers keep track of outstanding work, but
also lets contributors know the current status of their patches.
More importantly, it gives newcomers an overview of the current state of
the project. New contributors can begin not only by submitting patches,
but also by reviewing patches already posted to the mailing list,
thereby learning how our workflow operates. This may also help reduce
the review burden on our friendly maintainers.
I would like to try this kind of periodic report as an experimental
effort, with its frequency adjusted according to the size of the patch
backlog and the level of activity on the mailing list. What do you
think? Please feel free to make comments.
By the way, I borrowed the subject line directly from Git's "What's
cooking in git.git". Does anyone have a better suggestion for the name? ;-)
Thanks,
Weijie
^ permalink raw reply
* Re: [PATCH v8 4/8] mshv: Use hmm_range_fault_unlocked_timeout() for region faults
From: Stanislav Kinsburskii @ 2026-07-13 16:56 UTC (permalink / raw)
To: Andrew Morton
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <20260710224606.69235ab5c49b5987fd33e924@linux-foundation.org>
On Fri, Jul 10, 2026 at 10:46:06PM -0700, Andrew Morton wrote:
> On Fri, 10 Jul 2026 20:14:47 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
>
> > > > + mutex_lock(®ion->mreg_mutex);
> > > > +
> > > > + if (mmu_interval_read_retry(range.notifier, range.notifier_seq)) {
> > > > + mutex_unlock(®ion->mreg_mutex);
> > > > + cond_resched();
> > > > + goto again;
> > > > + }
> > > > +
> > >
> > > If the calling process has realtime scheduling policy and either a)
> > > we're uniprocessor or b) this process and the holder of
> > > interval_sub->invalidate_seq are both pinned to the same CPU then
> > > cond_resched() won't do anything, and this might be an infinite loop?
> >
> > Yes, looks like it might.
> > What can be done to prevent this?
>
> Well the best way is remove the polling loop and use a proper sleep/wakeup
> mechanism - mutex_lock()/prepare_to_wait()/etc.
>
> If the polling loop is to be retained then maybe msleep(1) or
> usleep_range()?
Well, running MSHV - or, I suppose, any other VM - on a uniprocessor host
would not be very efficient.
I’m not sure whether this corner case needs to be handled explicitly.
But even if it does, supporting or explicitly forbidding it would be a
separate change. As Jason noted, this is not a regression introduced by
this series.
Thanks,
Stanislav
^ permalink raw reply
* Re: [PATCH v8 5/8] drm/nouveau: Use hmm_range_fault_unlocked_timeout() for SVM faults
From: Stanislav Kinsburskii @ 2026-07-13 16:59 UTC (permalink / raw)
To: Andrew Morton
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <20260710224833.9caf2a0a9906f0515e326a45@linux-foundation.org>
On Fri, Jul 10, 2026 at 10:48:33PM -0700, Andrew Morton wrote:
> On Fri, 10 Jul 2026 20:16:35 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
>
> > On Fri, Jul 10, 2026 at 03:12:22PM -0700, Andrew Morton wrote:
> > > On Fri, 10 Jul 2026 14:26:58 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > >
> > > > @@ -683,15 +683,11 @@ static int nouveau_range_fault(struct nouveau_svmm *svmm,
> > > > goto out;
> > > > }
> > > >
> > > > - range.notifier_seq = mmu_interval_read_begin(range.notifier);
> > > > - mmap_read_lock(mm);
> > > > - ret = hmm_range_fault(&range);
> > > > - mmap_read_unlock(mm);
> > > > - if (ret) {
> > > > - if (ret == -EBUSY)
> > > > - continue;
> > > > + ret = hmm_range_fault_unlocked_timeout(&range,
> > > > + max(timeout - jiffies,
> > > > + 1L));
> > >
> > > "1UL" here? I'd have expected min() to warn, as it likes to do.
> >
> > I'm not sure... The "timeout - jiffies" can become negative.
> > Won't 1UL convert both of them to "UL" and thus make the comparison
> > overflow?
>
> `timeout' and `jiffies' are both unsigned long.
Yeah, I’m sorry for the sloppy wording.
What I meant was: will "max(timeout - jiffies, 1UL)" correctly handle
the case where jiffies < timeout?
Thanks,
Stanislav
^ permalink raw reply
* Re: [PATCH v8 8/8] drm/gpusvm: Use hmm_range_fault_unlocked_timeout() for range faults
From: Stanislav Kinsburskii @ 2026-07-13 17:01 UTC (permalink / raw)
To: Matthew Brost
Cc: airlied, akhilesh, akpm, corbet, dakr, david, decui, haiyangz,
jgg, kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <alUSq0o7CC2Pnr+H@gsse-cloud1.jf.intel.com>
On Mon, Jul 13, 2026 at 09:30:35AM -0700, Matthew Brost wrote:
> On Fri, Jul 10, 2026 at 02:27:19PM -0700, Stanislav Kinsburskii wrote:
>
> Please send series like this to intel-xe@lists.freedesktop.org list too
> as this will trigger our CI which expercises the change paths changed in
> this series.
>
> > Several GPU SVM paths take mmap_read_lock() only to call hmm_range_fault(),
> > then retry -EBUSY until HMM_RANGE_DEFAULT_TIMEOUT expires. Those paths use
> > MMU interval notifiers whose mm matches the mm that was locked for the HMM
> > fault.
> >
> > Use hmm_range_fault_unlocked_timeout() for those faults and pass the
> > remaining retry budget to HMM. The helper owns mmap_lock acquisition and
> > refreshes range->notifier_seq internally for each retry, while GPU SVM
> > keeps its existing driver-lock validation with mmu_interval_read_retry()
> > after a successful fault.
> >
> > Leave drm_gpusvm_check_pages() on hmm_range_fault() because that path is
> > called with the mmap lock already held by its caller.
> >
> > Signed-off-by: Stanislav Kinsburskii <skinsburskii@gmail.com>
> > Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
> > ---
> > drivers/gpu/drm/drm_gpusvm.c | 52 ++++++------------------------------------
> > 1 file changed, 7 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_gpusvm.c b/drivers/gpu/drm/drm_gpusvm.c
> > index 958cb605aedd..6b7a6eaebcd9 100644
> > --- a/drivers/gpu/drm/drm_gpusvm.c
> > +++ b/drivers/gpu/drm/drm_gpusvm.c
> > @@ -788,22 +788,8 @@ enum drm_gpusvm_scan_result drm_gpusvm_scan_mm(struct drm_gpusvm_range *range,
> > hmm_range.hmm_pfns = pfns;
> >
> > retry:
> > - hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> > - mmap_read_lock(range->gpusvm->mm);
> > -
> > - while (true) {
> > - err = hmm_range_fault(&hmm_range);
> > - if (err == -EBUSY) {
> > - if (time_after(jiffies, timeout))
> > - break;
> > -
> > - hmm_range.notifier_seq =
> > - mmu_interval_read_begin(notifier);
> > - continue;
> > - }
> > - break;
> > - }
> > - mmap_read_unlock(range->gpusvm->mm);
> > + err = hmm_range_fault_unlocked_timeout(&hmm_range,
> > + max(timeout - jiffies, 1L));
> > if (err)
> > goto err_free;
> >
> > @@ -1439,21 +1425,8 @@ int drm_gpusvm_get_pages(struct drm_gpusvm *gpusvm,
> > }
> >
> > hmm_range.hmm_pfns = pfns;
> > - while (true) {
> > - mmap_read_lock(mm);
> > - err = hmm_range_fault(&hmm_range);
> > - mmap_read_unlock(mm);
> > -
> > - if (err == -EBUSY) {
> > - if (time_after(jiffies, timeout))
> > - break;
> > -
> > - hmm_range.notifier_seq =
> > - mmu_interval_read_begin(notifier);
> > - continue;
> > - }
> > - break;
> > - }
> > + err = hmm_range_fault_unlocked_timeout(&hmm_range,
> > + max_t(long, timeout - jiffies, 1));
>
> Unaligned indentation.
>
> So I'd write this like this to avoid weird wraps:
>
> ctimeout = max_t(long, timeout - jiffies, 1));
> err = hmm_range_fault_unlocked_timeout(&hmm_range, ctimeout);
>
> > mmput(mm);
> > if (err)
> > goto err_free;
> > @@ -1736,24 +1709,13 @@ int drm_gpusvm_range_evict(struct drm_gpusvm *gpusvm,
> > return -ENOMEM;
> >
> > hmm_range.hmm_pfns = pfns;
> > - while (!time_after(jiffies, timeout)) {
> > - hmm_range.notifier_seq = mmu_interval_read_begin(notifier);
> > - if (time_after(jiffies, timeout)) {
> > - err = -ETIME;
> > - break;
> > - }
> > -
> > - mmap_read_lock(mm);
> > - err = hmm_range_fault(&hmm_range);
> > - mmap_read_unlock(mm);
> > - if (err != -EBUSY)
> > - break;
> > - }
> > + err = hmm_range_fault_unlocked_timeout(&hmm_range,
> > + max_t(long, timeout - jiffies, 1));
> >
>
> Same here.
>
> Nits, aside LGTM.
>
Will change as requested and send to intel-xe@lists.freedesktop.org next time.
Thanks,
Stanislav
> Matt
>
> > kvfree(pfns);
> > mmput(mm);
> >
> > - return err;
> > + return err == -EBUSY ? -ETIME : err;
> > }
> > EXPORT_SYMBOL_GPL(drm_gpusvm_range_evict);
> >
> >
> >
^ permalink raw reply
* Re: [PATCH v6 7/7] bus: mhi: Expose DDR training data via controller sysfs
From: Manivannan Sadhasivam @ 2026-07-13 17:08 UTC (permalink / raw)
To: Kishore Batta
Cc: Jonathan Corbet, Shuah Khan, Jeff Hugo, Carl Vanderlip,
Oded Gabbay, linux-doc, linux-kernel, linux-arm-msm, dri-devel,
mhi
In-Reply-To: <fb34c262-5c91-4beb-a792-f00da203d1b6@oss.qualcomm.com>
On Mon, Jul 13, 2026 at 01:00:27PM +0530, Kishore Batta wrote:
>
> 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.
>
You need to mention the exact file name for the read data.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH net-next v4 04/15] libie: add control queue support
From: Larysa Zaremba @ 2026-07-13 17:10 UTC (permalink / raw)
To: Tony Nguyen
Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev,
Phani R Burra, przemyslaw.kitszel, aleksander.lobakin,
sridhar.samudrala, anjali.singhai, michal.swiatkowski,
maciej.fijalkowski, emil.s.tantilov, madhu.chittim, joshua.a.hay,
jacob.e.keller, jayaprakash.shanmugam, jiri, horms, corbet,
richardcochran, linux-doc, Samuel Salin, Bharath R
In-Reply-To: <20260710215313.1475803-5-anthony.l.nguyen@intel.com>
Sashiko has some concerns about this patch.
There are some improvements that I think are nice to have based on that:
commit 1da5bb5c7a7be66fc6226afa94c0f25bb52a57a0
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date: Mon Jul 13 15:59:55 2026 +0200
fixup! libie: add control queue support
diff --git a/drivers/net/ethernet/intel/libie/controlq.c b/drivers/net/ethernet/intel/libie/controlq.c
index 885b4437b4f0..c043c07dbb89 100644
--- a/drivers/net/ethernet/intel/libie/controlq.c
+++ b/drivers/net/ethernet/intel/libie/controlq.c
@@ -327,7 +327,8 @@ libie_ctlq_add(struct libie_ctlq_ctx *ctx,
{
struct libie_ctlq_info *ctlq;
- if (qinfo->id != LIBIE_CTLQ_MBX_ID)
+ if (qinfo->id != LIBIE_CTLQ_MBX_ID ||
+ qinfo->len > FIELD_MAX(LIBIE_CTLQ_MBX_ATQ_LEN))
return ERR_PTR(-EOPNOTSUPP);
/* libie_ctlq_init was not called */
@@ -493,8 +494,6 @@ EXPORT_SYMBOL_NS_GPL(libie_ctlq_send_desc_avail, "LIBIE_CP");
* The caller must hold ctlq->lock. The intended pattern is to first check
* the number of descriptors available, then fill in the messages and perform
* send within a single critical section.
- *
- * Return: %0 on success, -%errno on failure.
*/
void libie_ctlq_send(struct libie_ctlq_info *ctlq, u32 num_q_msg)
{
@@ -510,6 +509,7 @@ void libie_ctlq_send(struct libie_ctlq_info *ctlq, u32 num_q_msg)
if (unlikely(++ntu == ctlq->ring_len))
ntu = 0;
}
+ dma_wmb();
writel(ntu, ctlq->reg.tail);
ctlq->next_to_use = ntu;
}
Other than that, I would put feedback into the following categories:
* worrying about patterns not employed by idpf or ixd
> libie_ctlq_recv() only breaks the loop on DD=0, but DD is never
> cleared on consumption. It is cleared only when the slot is
> re-posted by libie_ctlq_post_rx_buffs(), and even there the zeroing
> happens for descriptors that get freshly filled:
> while (num_to_post--) {
> ...
> ctlq->descs[ntp] = (struct libie_ctlq_desc) {};
> ...
> libie_ctlq_prep_rx_desc(&ctlq->descs[ntp], addr, fq.truesize);
> if (unlikely(++ntp == ctlq->ring_len))
> ntp = 0;
> }
> The final barrier slot between next_to_clean and next_to_post is
> never zeroed, so it retains DD=1 from the previous rotation.
> With ring_len = 4, after one full cycle ntc=3 and ntp=3; post_rx_buffs
> refills slots 3, 0, 1 and leaves slot 2 (the new barrier) with stale
> DD=1. If a caller then calls libie_ctlq_recv() with
> num_q_msg >= ring_len, the loop can wrap and re-process the stale
> descriptor at slot 2.
>
If caller calls libie_ctlq_recv() with num_q_msg >= ring_len, this is caller's
programming error, direct ctlq APIs are not exactly safe, and queue cannot
contain more than ring_len - 1 messages. So maybe worth mentioning in the kdoc.
So the stale slot is not a valid concern.
[...]
> Can this returned pointer be freed concurrently by another thread?
> The pointer is returned without acquiring a reference, and the lock that
> protected it (ctlqs_lock) is released immediately before returning.
> If a concurrent thread initiates teardown via libie_ctlq_deinit(), it could
> remove and free the queue while the caller of libie_find_ctlq() is actively
> accessing it, causing a use-after-free.
>
idpf and ixd do not do that
* Worrying about impossible libeth configurations
> If the page pool uses compound pages and the offset places iov_base into a
> subsequent 4K frame, calling virt_to_netmem(rx_buf->iov_base) yields the tail
> page rather than the head page.
> Page pool metadata is only valid on the head page, so calling
> page_pool_put_full_netmem() on this tail page could read garbage data.
>
page_pool in libie_cp is created in a way that makes compound pages impossible
> If the page pool ever returns a smaller truesize (for example via
> libeth_rx_page_pool_params_zc), would a hardware-provided data_len
> up to 4K let iov_len point past the end of the actual buffer?
>
page_pool via libeth is configured exactly in a way that disables any headroom
or tailroom, so truesize will never be less than data_len.
* Some parts of code that I agree look semi-ugly (like defines vs virtchnl2
enums, limiting id to LIBIE_CTLQ_MBX_ID, and lack of low-level completion
function for Tx control queue), but those I think are best addressed withing
non-default-mailbox-ctlq development, as currently the best way is unclear, but
how is looks currently is perfectly acceptable.
* Concerns about HW doorbells and such. Same as with previous versions, the flow
is consistent with what was in idpf beforehand.
* This one is an outlier:
> if (unlikely(msg->data_len > LIBIE_CTLQ_MAX_BUF_LEN)) {
> msg->data_len = LIBIE_CTLQ_MAX_BUF_LEN;
> msg->chnl_retval = U32_MAX;
> }
> Can callers distinguish "hardware returned U32_MAX" from "libie
> truncated the buffer"?
>
Yes, U32_MAX was chosen, so that it never intersects with the valid HW codes
^ permalink raw reply related
* Re: [PATCH v6 4/7] bus: mhi: Add QDU100 Sahara variant and firmware fallback
From: Manivannan Sadhasivam @ 2026-07-13 17:11 UTC (permalink / raw)
To: Kishore Batta
Cc: Jonathan Corbet, Shuah Khan, Jeff Hugo, Carl Vanderlip,
Oded Gabbay, linux-doc, linux-kernel, linux-arm-msm, dri-devel,
mhi
In-Reply-To: <a05e7dcc-7d8b-4db0-bd51-754184afb7c1@oss.qualcomm.com>
On Mon, Jul 13, 2026 at 12:55:52PM +0530, Kishore Batta wrote:
>
> 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 ?
>
Since it is a new device support for Sahara, bisect is not really a problem. But
I do see a value in keeping everything in a single patch.
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* Re: [PATCH v14 1/5] docs: driver-api: gpio: rpmsg gpio driver over rpmsg bus
From: Mathieu Poirier @ 2026-07-13 17:16 UTC (permalink / raw)
To: Shenwei Wang
Cc: Linus Walleij, Bartosz Golaszewski, Jonathan Corbet, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Frank Li,
Sascha Hauer, Shuah Khan, linux-gpio, linux-doc, linux-kernel,
Pengutronix Kernel Team, Fabio Estevam, Shenwei Wang, Peng Fan,
devicetree, linux-remoteproc, imx, linux-arm-kernel, linux-imx,
Arnaud POULIQUEN, b-padhi, Andrew Lunn
In-Reply-To: <20260625155432.815185-2-shenwei.wang@oss.nxp.com>
On Thu, Jun 25, 2026 at 10:54:26AM -0500, Shenwei Wang wrote:
> From: Shenwei Wang <shenwei.wang@nxp.com>
>
> Describes the gpio rpmsg transport protocol over the rpmsg bus between
> the remote system and Linux.
>
> Signed-off-by: Shenwei Wang <shenwei.wang@nxp.com>
> ---
> Documentation/driver-api/gpio/gpio-rpmsg.rst | 271 +++++++++++++++++++
> Documentation/driver-api/gpio/index.rst | 1 +
> 2 files changed, 272 insertions(+)
> create mode 100644 Documentation/driver-api/gpio/gpio-rpmsg.rst
>
> diff --git a/Documentation/driver-api/gpio/gpio-rpmsg.rst b/Documentation/driver-api/gpio/gpio-rpmsg.rst
> new file mode 100644
> index 000000000000..7d351ff0adb0
> --- /dev/null
> +++ b/Documentation/driver-api/gpio/gpio-rpmsg.rst
> @@ -0,0 +1,271 @@
> +.. SPDX-License-Identifier: GPL-2.0-or-later
> +
> +GPIO RPMSG (Remote Processor Messaging) Protocol
> +================================================
> +
> +The GPIO RPMSG transport protocol is used for communication and interaction
> +with GPIO controllers on remote processors via the RPMSG bus.
> +
> +Message Format
> +--------------
> +
> +The RPMSG message consists of a 8-byte packet with the following layout:
> +
> +.. code-block:: none
> +
> + +------+------+------+------+------+------+------+------+
> + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> + | cmd | line | value |
> + +------+------+------+------+------+------+------+------+
> +
> +- **cmd**: Command code, used for GPIO_RPMSG_SEND messages.
> +
> +- **line**: The GPIO line (pin) index of the port.
Here and throughout, please remove any mention of 'port'. This is handled by
the endpoint device, i.e one GPIO controller (port) per endpoint.
> +
> +- **value**: See details in the command description below.
> +
> +
> +GPIO Commands
> +-------------
> +
> +Commands are specified in the **Cmd** field.
> +
> +The SEND message is always sent from Linux to the remote firmware. Each
> +SEND corresponds to a single REPLY message. The GPIO driver should
> +serialize messages and determine whether a REPLY message is required. If a
> +REPLY message is expected but not received within the specified timeout
> +period (currently 1 second in the Linux driver), the driver should return
> +-ETIMEOUT.
> +
> +GET_DIRECTION (Cmd=2)
> +~~~~~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> + +------+------+------+------+------+------+------+------+
> + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> + | 2 | line | 0 |
> + +------+------+------+------+------+------+------+------+
> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> + +------+--------+--------+
> + | 0x00 | 0x01 | 0x02 |
> + | 1 | status | value |
> + +------+--------+--------+
> +
> +- **status**:
> +
> + - 0: Ok
> + - 1: Error
> +
> +- **value**: Direction.
> +
> + - 0: None
> + - 1: Output
> + - 2: Input
> +
> +
> +SET_DIRECTION (Cmd=3)
> +~~~~~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> + +------+------+------+------+------+------+------+------+
> + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> + | 3 | line | value |
> + +------+------+------+------+------+------+------+------+
> +
> +- **value**: Direction.
> +
> + - 0: None
> + - 1: Output
> + - 2: Input
> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> + +------+--------+--------+
> + | 0x00 | 0x01 | 0x02 |
> + | 1 | status | 0 |
> + +------+--------+--------+
> +
> +- **status**:
> +
> + - 0: Ok
> + - 1: Error
> +
> +
> +GET_VALUE (Cmd=4)
> +~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> + +------+------+------+------+------+------+------+------+
> + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> + | 4 | line | 0 |
> + +------+------+------+------+------+------+------+------+
> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> + +------+--------+--------+
> + | 0x00 | 0x01 | 0x02 |
> + | 1 | status | value |
> + +------+--------+--------+
> +
> +- **status**:
> +
> + - 0: Ok
> + - 1: Error
> +
> +- **value**: Level.
> +
> + - 0: Low
> + - 1: High
> +
> +
> +SET_VALUE (Cmd=5)
> +~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> + +------+------+------+------+------+------+------+------+
> + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> + | 5 | line | value |
> + +------+------+------+------+------+------+------+------+
> +
> +- **value**: Output level.
> +
> + - 0: Low
> + - 1: High
> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> + +------+--------+--------+
> + | 0x00 | 0x01 | 0x02 |
> + | 1 | status | 0 |
> + +------+--------+--------+
> +
> +- **status**:
> +
> + - 0: Ok
> + - 1: Error
> +
> +
> +SET_IRQ_TYPE (Cmd=6)
> +~~~~~~~~~~~~~~~~~~~~
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> + +------+------+------+------+------+------+------+------+
> + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> + | 6 | line | value |
> + +------+------+------+------+------+------+------+------+
> +
> +- **value**: IRQ types.
> +
> + - 0: Interrupt disabled
> + - 1: Rising edge trigger
> + - 2: Falling edge trigger
> + - 3: Both edge trigger
> + - 4: High level trigger
> + - 8: Low level trigger
I'm in agreement with cmd 3, 4, 5 and 6.
> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> + +------+--------+--------+
> + | 0x00 | 0x01 | 0x02 |
> + | 1 | status | 0 |
> + +------+--------+--------+
> +
> +- **status**:
> +
> + - 0: Ok
> + - 1: Error
> +
> +SET_WAKEUP (Cmd=16)
> +~~~~~~~~~~~~~~~~~~~
I already commented on messages that are not part of the virtio-gpio
specification.
> +
> +**Request:**
> +
> +.. code-block:: none
> +
> + +------+------+------+------+------+------+------+------+
> + | 0x00 | 0x01 | 0x02 | 0x03 | 0x04 | 0x05 | 0x06 | 0x07 |
> + | 1 | line | value |
> + +------+------+------+------+------+------+------+------+
> +
> +- **value**: Wakeup enable.
> +
> + The remote system should always aim to stay in a power-efficient state by
> + shutting down or clock-gating the GPIO blocks that aren't in use. Since
> + the remoteproc driver is responsible for managing the power states of the
> + remote firmware, the GPIO driver does not require to know the firmware's
> + running states.
> +
> + When the wakeup bit is set, the remote firmware should configure the line
> + as a wakeup source. The firmware should send the notification message to
> + Linux after it is woken from the GPIO line.
> +
> + - 0: Disable wakeup from GPIO
> + - 1: Enable wakeup from GPIO
> +
> +**Reply:**
> +
> +.. code-block:: none
> +
> + +------+--------+--------+
> + | 0x00 | 0x01 | 0x02 |
> + | 1 | status | 0 |
> + +------+--------+--------+
> +
> +- **status**:
> +
> + - 0: Ok
> + - 1: Error
> +
> +Notification Message
> +--------------------
"Interrupt Messages"
> +
> +Notifications are sent by the remote core and they have
> +**Type=2 (GPIO_RPMSG_NOTIFY)**:
> +
> +When a GPIO line asserts an interrupt on the remote processor, the firmware
> +should immediately mask the corresponding interrupt source and send a
> +notification message to the Linux. Upon completion of the interrupt
> +handling on the Linux side, the driver should issue a
> +command **SET_IRQ_TYPE** to the firmware to unmask the interrupt.
> +
> +A Notification message can arrive between a SEND and its REPLY message,
> +and the driver is expected to handle this scenario.
> +
> +.. code-block:: none
> +
> + +------+------+--------+
> + | 0x00 | 0x01 | 0x02 |
> + | 2 | line | trigger|
> + +------+------+--------+
2 things here:
1) You did not include messages that mask and unmask interrupts at the driver
side.
2) We are carrying virtio-gpio messages on top of RPMSG and as such, this whole
protocol should be about thar:
+------+------+--------+--------
| 0x00 | payload |
| Q | |
+------+------+--------+--------
Q = 0 requestq
Q = 1 eventq
The "payload" part is simply the format of the messages as found in the
virtio-gpio specification. From there, the only thing left to mention is which
messages are not supported, i.e get line names.
> +
> +- **line**: The GPIO line (pin) index of the port.
> +
> +- **trigger**: Optional parameter to indicate the trigger event type.
Not part of the spec - remove.
Given the refactoring work that is still needed, I will not look at the
implementation.
Thanks,
Mathieu
> +
> diff --git a/Documentation/driver-api/gpio/index.rst b/Documentation/driver-api/gpio/index.rst
> index bee58f709b9a..e5eb1f82f01f 100644
> --- a/Documentation/driver-api/gpio/index.rst
> +++ b/Documentation/driver-api/gpio/index.rst
> @@ -16,6 +16,7 @@ Contents:
> drivers-on-gpio
> bt8xxgpio
> pca953x
> + gpio-rpmsg
>
> Core
> ====
> --
> 2.43.0
>
^ permalink raw reply
* RE: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device passthrough
From: Manish Honap @ 2026-07-13 17:40 UTC (permalink / raw)
To: Alex Williamson
Cc: djbw@kernel.org, jgg@ziepe.ca, jic23@kernel.org,
dave.jiang@intel.com, Ankit Agrawal,
alejandro.lucero-palau@amd.com, alison.schofield@intel.com,
dave@stgolabs.net, dmatlack@google.com, gourry@gourry.net,
ira.weiny@intel.com, Neo Jia, Krishnakant Jaju, Vikram Sethi,
Zhi Wang, kvm@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, Manish Honap
In-Reply-To: <IA1PR12MB9030E175587B09CEA7A4D90FBDFA2@IA1PR12MB9030.namprd12.prod.outlook.com>
> -----Original Message-----
> From: Manish Honap <mhonap@nvidia.com>
> Sent: 13 July 2026 22:15
> To: Alex Williamson <alex@shazbot.org>
> Cc: djbw@kernel.org; jgg@ziepe.ca; jic23@kernel.org;
> dave.jiang@intel.com; Ankit Agrawal <ankita@nvidia.com>;
> alejandro.lucero-palau@amd.com; alison.schofield@intel.com;
> dave@stgolabs.net; dmatlack@google.com; gourry@gourry.net;
> ira.weiny@intel.com; Neo Jia <cjia@nvidia.com>; Krishnakant Jaju
> <kjaju@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>; Zhi Wang
> <zhiw@nvidia.com>; kvm@vger.kernel.org; linux-cxl@vger.kernel.org;
> linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> kselftest@vger.kernel.org; Manish Honap <mhonap@nvidia.com>
> Subject: RE: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device
> passthrough
>
>
>
> > -----Original Message-----
> > From: Alex Williamson <alex@shazbot.org>
> > Sent: 11 July 2026 03:53
> > To: Manish Honap <mhonap@nvidia.com>
> > Cc: djbw@kernel.org; jgg@ziepe.ca; jic23@kernel.org;
> > dave.jiang@intel.com; Ankit Agrawal <ankita@nvidia.com>;
> > alejandro.lucero-palau@amd.com; alison.schofield@intel.com;
> > dave@stgolabs.net; dmatlack@google.com; gourry@gourry.net;
> > ira.weiny@intel.com; Neo Jia <cjia@nvidia.com>; Krishnakant Jaju
> > <kjaju@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>; Zhi Wang
> > <zhiw@nvidia.com>; kvm@vger.kernel.org; linux-cxl@vger.kernel.org;
> > linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> > kselftest@vger.kernel.org; alex@shazbot.org
> > Subject: Re: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device
> > passthrough
> >
> > External email: Use caution opening links or attachments
> >
> >
> > On Thu, 25 Jun 2026 22:24:01 +0530
> > <mhonap@nvidia.com> wrote:
> > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > index 5de618a3a5ee..3707d53c4de5 100644
> > > --- a/include/uapi/linux/vfio.h
> > > +++ b/include/uapi/linux/vfio.h
> > > @@ -215,6 +215,7 @@ struct vfio_device_info {
> > > #define VFIO_DEVICE_FLAGS_FSL_MC (1 << 6) /* vfio-fsl-mc device
> */
> > > #define VFIO_DEVICE_FLAGS_CAPS (1 << 7) /* Info
> supports
> > caps */
> > > #define VFIO_DEVICE_FLAGS_CDX (1 << 8) /* vfio-cdx
> > device */
> > > +#define VFIO_DEVICE_FLAGS_CXL (1 << 9) /* vfio-cxl
> > Type-2 device */
> >
> > Would we define a different flag for type-1/3 if we ever found a need
> > to expose them through vfio?
>
> Yes. The current flag is named VFIO_DEVICE_FLAGS_CXL and refers to
> Type-2 specifically. If Type-1 or Type-3 support is added later, a
> separate flag (or a VFIO_DEVICE_INFO_CAP sub-type field) would
> distinguish them. I can rename it VFIO_DEVICE_FLAGS_CXL_TYPE2 now if
> that is preferable; please advise.
For this patchseries, I think keeping name as VFIO_DEVICE_FLAGS_CXL_TYPE2
is a better choice since Type-2 is the only supported case now; a separate
flag can be added when Type-1/3 support arrives.
>
> >
> > > __u32 num_regions; /* Max region index + 1 */
> > > __u32 num_irqs; /* Max IRQ index + 1 */
> > > __u32 cap_offset; /* Offset within info struct of first
> > cap */
> > > @@ -257,6 +258,36 @@ struct vfio_device_info_cap_pci_atomic_comp {
> > > __u32 reserved;
> > > };
> > >
> > > +/*
> > > + * VFIO_DEVICE_INFO capability for CXL Type-2 passthrough devices.
> > > + * Present when VFIO_DEVICE_FLAGS_CXL is set on
> > vfio_device_info::flags.
> > > + *
> > > + * @flags: VFIO_CXL_CAP_HOST_FIRMWARE_COMMITTED indicates the host
> > CXL
> > > + * subsystem committed the endpoint HDM decoder.
> > > + * @hdm_region_idx: VFIO region index for the HDM memory region
> > > + * (subtype VFIO_REGION_SUBTYPE_CXL).
> > > + * @comp_reg_region_idx: VFIO region index for the CXL Component
> > > + * Register shadow (subtype VFIO_REGION_SUBTYPE_CXL_COMP_REGS).
> >
> > These regions are self describing via the noted CXL subtypes, what's
> > the purpose of double reporting them here?
>
> Agreed; I will try to minimize the noise here.
>
> >
> > > + * @comp_reg_bar: PCI BAR index that contains the CXL component
> > > + * register block. Get-region-info on this BAR returns a
> > > + * VFIO_REGION_INFO_CAP_SPARSE_MMAP that excludes the CXL block.
> > > + * @comp_reg_offset: byte offset of the CXL component register
> block
> > > + * within @comp_reg_bar.
> > > + * @comp_reg_size: byte size of the CXL component register block.
> >
> > Why don't we describe all of these via a capability on the relevant
> > region info?
>
> okay, I will have v4 to remove hdm_region_idx, comp_reg_region_idx,
> comp_reg_bar, comp_reg_offset, and comp_reg_size from
> vfio_device_info_cap_cxl. The device-level cap will only have flags.
>
> This will also result in component register details to move to a new
> VFIO_REGION_INFO_CAP_CXL_COMP_REGS capability on the comp-reg region
> info, carrying comp_reg_bar, comp_reg_offset, and comp_reg_size.
>
> Regions will remain self-describing via VFIO_REGION_SUBTYPE_CXL and
> VFIO_REGION_SUBTYPE_CXL_COMP_REGS.
>
> >
> > Does that leave this device level capability describing the device as
> > type-2 (by existence), with only a flags field to declare HDM as
> > firmware committed, for future compatibility should we support non-fw
> > committed? Thanks,
> >
> > Alex
>
> Yes, I will shape the v4 in this direction. The device-level CAP_CXL
> shrinks to "this is a CXL device" (by existence) plus a flags field
> whose only defined bit today is HOST_FIRMWARE_COMMITTED, leaving room
> for a future non-fw-committed mode. Everything else moves to region
> caps. Thanks for this suggestion.
^ permalink raw reply
* Re: [PATCH net-next v4 05/15] libie: add bookkeeping support for control queue messages
From: Larysa Zaremba @ 2026-07-13 17:42 UTC (permalink / raw)
To: Tony Nguyen
Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev,
Phani R Burra, przemyslaw.kitszel, aleksander.lobakin,
sridhar.samudrala, anjali.singhai, michal.swiatkowski,
maciej.fijalkowski, emil.s.tantilov, madhu.chittim, joshua.a.hay,
jacob.e.keller, jayaprakash.shanmugam, jiri, horms, corbet,
richardcochran, linux-doc, Bharath R, Samuel Salin
In-Reply-To: <20260710215313.1475803-6-anthony.l.nguyen@intel.com>
Sashiko has some concerns about this patch.
I have found one (very) valid concern there, and concerns memory usage.
commit d7a772efb77228a1b12558dced6b1fdfeef123c4
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date: Mon Jul 13 17:02:01 2026 +0200
fixup! libie: add bookkeeping support for control queue messages
diff --git a/drivers/net/ethernet/intel/libie/controlq.c b/drivers/net/ethernet/intel/libie/controlq.c
index c043c07dbb89..8e7b2783b86b 100644
--- a/drivers/net/ethernet/intel/libie/controlq.c
+++ b/drivers/net/ethernet/intel/libie/controlq.c
@@ -720,7 +720,7 @@ static int libie_ctlq_xn_init_dma(struct device *dev,
goto dealloc_dma;
dma_mem->va = libie_cp_alloc_dma_mem(dev, dma_mem,
- LIBIE_CTLQ_MAX_BUF_LEN);
+ LIBIE_CP_TX_COPYBREAK);
if (!dma_mem->va) {
kfree(dma_mem);
goto dealloc_dma;
Now regarding other concerns:
* xn cookie overflow. The flow is consistent with what was in idpf beforehand,
lengthy testing also did not detect any problems
* Compromised CP accessing other CP message
> Regarding cross-transaction disclosure in the pre-allocated small-send
> buffer: in libie_ctlq_xn_process_send() the small path memcpys only
> buf_len bytes into a LIBIE_CTLQ_MAX_BUF_LEN buffer, leaving prior
> transaction data in the tail. The descriptor advertises
> data_len = buf_len so a well-behaved device only reads that many bytes,
> but could a compromised or buggy CP firmware read past data_len and
> observe prior control-plane message content?
> Would a memset of the unused tail (or of the whole buffer before
> memcpy) close this at negligible cost?
>
I think zeroing would be excessive
* Both Sashikos reported this one:
> Regarding bitmap access without the bitmap lock: this iterates
> xnm->free_xns_bm via for_each_clear_bit() without holding
> xnm->free_xns_bm_lock, while __set_bit()/__clear_bit() elsewhere
> (non-atomic RMW) mutate the same bitmap under that lock.
> Is that intentional? The comment on free_xns_bm_lock says it protects
> get/check entries, so reading the bitmap outside the lock appears to
> break the invariant even if the subsequent xn_lock re-check masks the
> functional impact today.
>
If the xn becomes free in the meantime, we catch that under xn->xn_lock
If the xn becomes taken in the meantime, we just check it next time
* Also reported by both:
> Regarding async timeout enforcement: libie_xn_check_async_timeout()
> runs only from libie_ctlq_xn_recv(). If the driver stops polling recv
> (link down, reset, NAPI suspended, interrupts masked, no incoming
> ctlq traffic, budget exhausted repeatedly), do async transactions
> ever fire their -ETIMEDOUT callback?
>
This is intended
>
> There is no independent watchdog inside the xnm (delayed_work,
> hrtimer, etc.), while the sync path is self-contained via
> wait_for_completion_timeout(). Is timeout_ms meant to be a hard
> guarantee, or caller-responsibility to keep recv polling? Either the
> kerneldoc should say so, or an independent timer inside the xnm would
> back the guarantee.
>
Caller's responsibility, timer would be excessive
* BH-related concern
> If a driver invokes xn_recv from NAPI/softirq on the same CPU that
> another thread has entered xn_send in process context and grabbed one
> of these locks, can the softirq spin-deadlock trying to reacquire the
> lock?
> Should these paths use spin_lock_bh() (or spin_lock_irqsave() if the
> recv side may run from hardirq)?
>
Both send and receive are in non-BH and non-IRQ context
* DMA direction
> For the small-message path here, direction is not set on xn->dma_mem,
> so it stays at whatever kzalloc left it (DMA_BIDIRECTIONAL). The copy
> of dma_mem into ctlq_msg->send_mem then carries that value. Today
> libie_ctlq_xn_send_clean() only calls dma_unmap_single on the
> non-onstack path, so this is not consumed, but should direction be
> set consistently to avoid a future consumer of msg->send_mem.direction
> misbehaving?
dma->direction is not expected to be access by users outside of libeth.
Library uses the field correctly
* "For the NULL-iov_base large-buffer case" - I think this can be considered a
driver's programming error, if this happens
* XN_SHUTDOWN
> The SHUTDOWN early-exit here jumps to unlock_xn, bypassing release_xn
> which is the only place that resets state to IDLE and calls
> reinit_completion(). So the xn is pushed back to free with
> state == SHUTDOWN and a stale completion count.
XN_SHUTDOWN means shutdown has already reclaimed the transaction and it cannot
be reused, hence can be dirty.
* 0-data messages
> The kerneldoc says "if force is set, then clear all the outstanding
> send messages irrespective their send status", but the loop breaks
> early on the first slot with data_len == 0. Should the wording be
> adjusted to reflect the actual behavior?
>
The only data_len = 0 message is VF reset, which can only be sent
as the last message, so we can safely assume no further buffers
need cleaning, if we encounter that
* dma_wmb() + dma_rmb() = dma_mb()
> Would dma_wmb() suffice here instead of dma_mb()? Only a write-side
> ordering constraint is needed for the desc->qword0 = 0 store, and
> dma_mb() is significantly more expensive on weakly-ordered
> architectures.
> libie_ctlq_recv() pairs its DD check with dma_rmb() before consuming
> the rest of the descriptor. Here, DD is read via le64_to_cpu() with
> no dma_rmb() before any further use. Today nothing device-updated is
> read after the DD check, so this is safe, but should the same barrier
> pattern be used for symmetry so a future descriptor field consumed
> after DD is not silently unordered?
>
Both read and write berriers are needed, therefore I have dma_mb().
* Same answer as for the previous version:
> Async callers of xn_send() typically pass a send_ctx that owns
> resources released only by resp_cb. When shutdown races with in-flight
> async transactions, does send_ctx (and anything it owns) leak?
> Would calling xn->resp_cb(xn->send_ctx, NULL, -ESHUTDOWN) (or
> -ECANCELED / -ETIMEDOUT) here, matching the timeout path, close this?
>
Callers currently do not rely on those callbacks for cleanup,
and they certainly should not do whatever handling they do,
if we are shutting down
* Clearing the queue before shutdown
> Regarding TX cleanup on deinit: libie_ctlq_xn_deinit() calls
> xn_shutdown() then xn_deinit_dma() then libie_ctlq_deinit(), none of
> which iterate the TX ring calling libie_cp_unmap_dma_mem() or
> rel_tx_buf() on outstanding sends.
Both callers force-clean the queue beforehand.
* Small return value concern:
> The ctlq_deinit label unconditionally returns -ENOMEM, discarding the
> ret from libie_ctlq_xn_init_dma() and papering over the kzalloc-failure
> path with the same constant. init_dma today only returns -ENOMEM so it
> works, but would "return ret;" (with ret set to -ENOMEM in the kzalloc
> branch) be more robust against a future error code addition?
>
Those are all memory-related functions, so this is very unlikely they return anything else.
* xn->send_ctx
> The send_ctx field here is never consumed by libie_ctlq_xn_send_clean()
> or by the rel_tx_buf callback signature (which only takes buf_va).
> Should send_ctx be removed, or should rel_tx_buf's signature be
> updated to receive it?
>
This field is used for async transactions and is usually
a rather persistent object, like HW structure.
xn->resp_cb(xn->send_ctx, response, status);
* Slightly outdated commit message
> Is this accurate? Only messages up to LIBIE_CP_TX_COPYBREAK (128 bytes)
> use libie's pre-allocated per-slot DMA buffers via
> libie_cp_can_send_onstack(); larger messages are caller-allocated and
> freed via the caller-supplied rel_tx_buf callback. Could the wording
> be tightened to describe this mixed ownership model?2
>
This is correct interpretation, but the kdoc is outdated
* Calling resp_cb() under xn_lock
> Is it safe to invoke the opaque resp_cb() while holding xn->xn_lock?
> If the caller attempts to submit another message from within the callback via
> libie_ctlq_xn_send(), it will attempt to acquire free_xns_bm_lock and another
> xn->xn_lock. Could this cause recursive locking or deadlocks?
>
idpf and ixd do not behave that way
* "memory leaks" for small buffers
> > + bool free_send = !libie_cp_can_send_onstack(params->send_buf.iov_len);
> Does this logic cause memory leaks for dynamically allocated small buffers?
> If the message size is <= 128 bytes (LIBIE_CP_TX_COPYBREAK), the data is
> copied to the pre-allocated DMA buffer, and free_send is set to false. If the
> caller provided a dynamically allocated buffer and passed a rel_tx_buf
> callback to free it, the callback is never executed because of this flag.
This is by design
* transaction reuse
> Can a timed-out transaction overwrite active DMA memory?
> If a message <= 128 bytes times out, it breaks out of the switch here and is
> pushed back to the free list in release_xn below.
> However, the hardware descriptor in the transmit ring might still point to
> xn->dma_mem->pa. If a new caller allocates this transaction entry and writes
> its payload, it will overwrite the buffer while the hardware might still be
> processing the old descriptor. Could this lead to hardware data corruption
> or invalid firmware commands?
>
Highly unlikely
^ permalink raw reply related
* Re: [PATCH net-next v4 08/15] idpf: refactor idpf to use libie_pci APIs
From: Larysa Zaremba @ 2026-07-13 17:46 UTC (permalink / raw)
To: Tony Nguyen
Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev,
Pavan Kumar Linga, przemyslaw.kitszel, aleksander.lobakin,
sridhar.samudrala, michal.swiatkowski, maciej.fijalkowski,
emil.s.tantilov, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc, Samuel Salin
In-Reply-To: <20260710215313.1475803-9-anthony.l.nguyen@intel.com>
There is one nice-to-have change that came out of Sashiko's review:
commit 5238b5986775c0c76881ed594a7b09216ee20107
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date: Mon Jul 13 17:07:10 2026 +0200
fixup! idpf: refactor idpf to use libie_pci APIs
diff --git a/drivers/net/ethernet/intel/idpf/idpf_main.c b/drivers/net/ethernet/intel/idpf/idpf_main.c
index 5a191644b28e..184d30c12abb 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_main.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_main.c
@@ -265,8 +265,9 @@ static int idpf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = idpf_dev_init(adapter, ent);
if (err) {
- dev_err(&pdev->dev, "Unexpected dev ID 0x%x in idpf probe\n",
- ent->device);
+ dev_err(&pdev->dev,
+ "Failed to initialize device (ID 0x%x): %d\n",
+ ent->device, err);
goto err_free;
}
Everything else:
> commit 461758d19f17656a1ed2f88e0867b4610ec38b43
> Author: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> idpf: refactor idpf to use libie_pci APIs
> This patch converts the idpf driver over to the shared libie_pci init
> and MMIO helpers, routes mailbox and register accesses through
> libie_pci_get_mmio_addr(), and adds a struct libie_ctlq_ctx to the
> adapter for the mmio_info list. struct idpf_hw is kept around because
> it still houses the control queues.
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_controlq.h b/drivers/net/ethernet/intel/idpf/idpf_controlq.h
> > index de4ece40c2ff..acf595e9265f 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_controlq.h
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_controlq.h
> > @@ -109,8 +109,6 @@ struct idpf_mmio_reg {
> > * Align to ctlq_hw_info
> > */
> > struct idpf_hw {
> > - struct idpf_mmio_reg mbx;
> > - struct idpf_mmio_reg rstat;
> > /* Array of remaining LAN BAR regions */
> > int num_lan_regs;
> > struct idpf_mmio_reg *lan_regs;
> After this hunk, do num_lan_regs, lan_regs, struct idpf_mmio_reg, and
> IDPF_MMIO_MAP_FALLBACK_MAX_REMAINING still have any users? A grep of
> the tree shows only their own declarations in idpf_controlq.h with no
> readers or writers after this commit.
> The same question applies to the mailbox helper macros in
> drivers/net/ethernet/intel/idpf/idpf_mem.h, which are left in place
> but still reference the just-removed mbx field:
> #define idpf_mbx_wr32(a, reg, value) writel((value), ((a)->mbx.vaddr + (reg)))
> #define idpf_mbx_rd32(a, reg) readl((a)->mbx.vaddr + (reg))
> #define idpf_mbx_wr64(a, reg, value) writeq((value), ((a)->mbx.vaddr + (reg)))
> #define idpf_mbx_rd64(a, reg) readq((a)->mbx.vaddr + (reg))
> Would it make sense to drop these together with the field removal
> above so that any future accidental use fails at review rather than
> silently reintroducing dead paths?
>
struct idpf_hw and those macros are dropped completely in the next patch
>
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_idc.c b/drivers/net/ethernet/intel/idpf/idpf_idc.c
> > index b7d6b08fc89e..0a7edb783758 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_idc.c
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_idc.c
> > @@ -416,9 +416,12 @@ idpf_idc_init_msix_data(struct idpf_adapter *adapter)
> > int idpf_idc_init_aux_core_dev(struct idpf_adapter *adapter,
> > enum iidc_function_type ftype)
> > {
> > + struct libie_mmio_info *mmio = &adapter->ctlq_ctx.mmio_info;
> > struct iidc_rdma_core_dev_info *cdev_info;
> > struct iidc_rdma_priv_dev_info *privd;
> > - int err, i;
> > + struct libie_pci_mmio_region *mr;
> > + size_t num_mem_regions;
> > + int err, i = 0;
> >
> > adapter->cdev_info = kzalloc_obj(*cdev_info);
> > if (!adapter->cdev_info)
> > @@ -436,22 +439,37 @@ int idpf_idc_init_aux_core_dev(struct idpf_adapter *adapter,
> > cdev_info->rdma_protocol = IIDC_RDMA_PROTOCOL_ROCEV2;
> > privd->ftype = ftype;
> >
> > + num_mem_regions = list_count_nodes(&mmio->mmio_list);
> > + if (num_mem_regions <= IDPF_MMIO_REG_NUM_STATIC) {
> > + err = -EINVAL;
> > + goto err_plug_aux_dev;
> > + }
> > +
> > + num_mem_regions -= IDPF_MMIO_REG_NUM_STATIC;
> > privd->mapped_mem_regions =
> > kzalloc_objs(struct iidc_rdma_lan_mapped_mem_region,
> > - adapter->hw.num_lan_regs);
> > + num_mem_regions);
> > if (!privd->mapped_mem_regions) {
> > err = -ENOMEM;
> > goto err_plug_aux_dev;
> > }
> >
> > - privd->num_memory_regions = cpu_to_le16(adapter->hw.num_lan_regs);
> > - for (i = 0; i < adapter->hw.num_lan_regs; i++) {
> > - privd->mapped_mem_regions[i].region_addr =
> > - adapter->hw.lan_regs[i].vaddr;
> > - privd->mapped_mem_regions[i].size =
> > - cpu_to_le64(adapter->hw.lan_regs[i].addr_len);
> > - privd->mapped_mem_regions[i].start_offset =
> > - cpu_to_le64(adapter->hw.lan_regs[i].addr_start);
> > + privd->num_memory_regions = cpu_to_le16(num_mem_regions);
> > + list_for_each_entry(mr, &mmio->mmio_list, list) {
> > + struct resource *static_regs = adapter->dev_ops.static_reg_info;
> > + bool is_static = false;
> > +
> > + for (uint j = 0; j < IDPF_MMIO_REG_NUM_STATIC; j++)
> > + if (mr->offset == static_regs[j].start)
> > + is_static = true;
> > +
> > + if (is_static)
> > + continue;
> > +
> > + privd->mapped_mem_regions[i].region_addr = mr->addr;
> > + privd->mapped_mem_regions[i].size = cpu_to_le64(mr->size);
> > + privd->mapped_mem_regions[i++].start_offset =
> > + cpu_to_le64(mr->offset);
> > }
> Is a semantic change to what is reported to the IIDC RDMA aux device
> intended here?
> Previously idpf_calc_remaining_mmio_regs() always reported
> IDPF_MMIO_MAP_FALLBACK_MAX_REMAINING (3) regions, including any that
> happened to have addr_len == 0, and firmware-supplied regions with
> size == 0 were forwarded verbatim.
> After this patch:
> - idpf_map_remaining_mmio_regs() skips zero-sized regions via the
> !size || short-circuit before libie_pci_map_mmio_region().
> - idpf_cfg_lan_memory_regions() skips zero-sized firmware regions via
> if (len && !libie_pci_map_mmio_region(mmio, offset, len)).
> - idpf_idc_init_aux_core_dev() now fails outright with -EINVAL when
> list_count_nodes(&mmio->mmio_list) <= IDPF_MMIO_REG_NUM_STATIC.
> If a valid platform has, for example, the mailbox at BAR offset 0
> and rstat abutting the end of BAR0, are all three fallback regions
> zero-sized, and would that make the RDMA aux init unconditionally
> fail on that configuration? Would it be worth calling this ABI
> change out in the commit message?
> Separately, is the count/write-index invariant in this loop enforced
> anywhere?
> The code computes:
> num_mem_regions = list_count_nodes(&mmio->mmio_list);
> ...
> num_mem_regions -= IDPF_MMIO_REG_NUM_STATIC;
> privd->mapped_mem_regions =
> kzalloc_objs(struct iidc_rdma_lan_mapped_mem_region,
> num_mem_regions);
> ...
> privd->num_memory_regions = cpu_to_le16(num_mem_regions);
> list_for_each_entry(mr, &mmio->mmio_list, list) {
> ...
> privd->mapped_mem_regions[i++].start_offset =
> cpu_to_le64(mr->offset);
> }
> The loop increments i for every non-static entry, but there is no
> i < num_mem_regions guard. It relies on exactly
> IDPF_MMIO_REG_NUM_STATIC entries in the list having mr->offset equal
> to a static_reg_info[j].start. If, for any reason, fewer than
> IDPF_MMIO_REG_NUM_STATIC entries match (a future coalescing in
> libie_pci_map_mmio_region(), or a firmware-supplied region whose
> offset happens to coincide with a static offset without being added
> as a duplicate), does the loop overrun the mapped_mem_regions
> allocation?
> Would an explicit if (i >= num_mem_regions) break; inside the loop
> make this invariant local and enforceable?
>
Static regions are *static*, we can absolutely rely on at least
static regions to be valid
>
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_main.c b/drivers/net/ethernet/intel/idpf/idpf_main.c
> > index ab3c409e587b..93b11fb1609f 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_main.c
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_main.c
> > @@ -246,32 +265,21 @@ static int idpf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
> > adapter->req_rx_splitq = true;
> >
> > adapter->pdev = pdev;
> > - err = pcim_enable_device(pdev);
> > - if (err)
> > - goto err_free;
> >
> > - err = pcim_request_region(pdev, 0, pci_name(pdev));
> > + err = idpf_dev_init(adapter, ent);
> > if (err) {
> > - pci_err(pdev, "pcim_request_region failed %pe\n", ERR_PTR(err));
> > -
> > + dev_err(&pdev->dev, "Unexpected dev ID 0x%x in idpf probe\n",
> > + ent->device);
> > goto err_free;
> > }
> >
> > - err = pci_enable_ptm(pdev);
> > - if (err)
> > - pci_dbg(pdev, "PCIe PTM is not supported by PCIe bus/controller\n");
> > -
> > - /* set up for high or low dma */
> > - err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
> > + err = idpf_cfg_device(adapter);
> > if (err) {
> > - pci_err(pdev, "DMA configuration failed: %pe\n", ERR_PTR(err));
> > -
> > + pci_err(pdev, "Failed to configure device specific resources: %pe\n",
> > + ERR_PTR(err));
> > goto err_free;
> > }
> Does the "Unexpected dev ID" message still accurately describe every
> failure mode of idpf_dev_init() after this change?
> idpf_dev_init() now calls libie_pci_init_dev() first, which wraps
> pcim_enable_device(), pcim_request_region(), and
> dma_set_mask_and_coherent(). Failures in any of those (for example
> -EIO or -ENOMEM from BAR request, or DMA mask failures) will now be
> reported as "Unexpected dev ID 0x%x in idpf probe" instead of the
> prior specific messages ("pcim_request_region failed %pe", "DMA
> configuration failed: %pe"). Would it be worth propagating err via
> %pe alongside the device ID, or letting libie_pci_init_dev() log its
> own reason?
>
Valid, look at diff at the start.
>
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > index a3c17f0e14f3..357ff3e86b2e 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > @@ -3445,35 +3450,30 @@ int idpf_vc_core_init(struct idpf_adapter *adapter)
> > }
> >
> > if (idpf_is_cap_ena(adapter, IDPF_OTHER_CAPS, VIRTCHNL2_CAP_LAN_MEMORY_REGIONS)) {
> > - err = idpf_send_get_lan_memory_regions(adapter);
> > + err = idpf_cfg_lan_memory_regions(adapter);
> > if (err) {
> > - dev_err(&adapter->pdev->dev, "Failed to get LAN memory regions: %d\n",
> > + dev_err(&adapter->pdev->dev, "Failed to configure LAN memory regions: %d\n",
> > err);
> > return -EINVAL;
> > }
> > } else {
> > /* Fallback to mapping the remaining regions of the entire BAR */
> > - err = idpf_calc_remaining_mmio_regs(adapter);
> > + err = idpf_map_remaining_mmio_regs(adapter);
> > if (err) {
> > - dev_err(&adapter->pdev->dev, "Failed to allocate BAR0 region(s): %d\n",
> > + dev_err(&adapter->pdev->dev, "Failed to configure BAR0 region(s): %d\n",
> > err);
> > - return -ENOMEM;
> > + return err;
> > }
> > }
> Is the mmio_info->mmio_list traversed while it may be concurrently
> mutated?
> libie_pci_map_mmio_region() calls list_add_tail() and
> libie_pci_unmap_fltr_regs()/libie_pci_unmap_all_mmio_regions() call
> list_del() + kvfree(), while __libie_pci_get_mmio_addr() traverses
> the list with plain list_for_each_entry() (no lock, no RCU).
> In idpf_init_hard_reset() the mbx_task workqueue is kicked before
> idpf_vc_core_init() runs the memory-region setup:
> queue_delayed_work(adapter->mbx_wq, &adapter->mbx_task, 0);
> ...
> err = idpf_vc_core_init(adapter);
> And idpf_vc_core_init() then reaches idpf_cfg_lan_memory_regions()
> (which calls libie_pci_map_mmio_region() in a loop) or its error
> path decfg_regions: which calls idpf_decfg_lan_memory_regions() ->
> libie_pci_unmap_fltr_regs().
> Meanwhile mbx_task -> idpf_ctlq_post_rx_buffs()/idpf_ctlq_send() ends
> up in libie_pci_get_mmio_addr(&hw->back->ctlq_ctx.mmio_info,
> cq->reg.tail), which walks the same mmio_list.
> Under current code the mailbox entry is the first one added at probe
> time and is never removed until unmap-all, so iteration terminates
> before touching the tail being mutated. Is that invariant intended
> to be relied on going forward? Would an explicit lock or a comment
> documenting the read/write ordering constraint help protect against
> a future addition (for example a PTP or ITR register lookup from a
> work item) that would need to walk past the mailbox entry?
>
This is fine, we can rely on the mailbox register to be valid
while mailbox communication is going. MBX is a static region,
so it is expected to be unmapped only once we are shutting down for good
>
^ permalink raw reply related
* Re: [PATCH 10/10] perf hisi-ptt: Add decoder version compatibility
From: Bjorn Helgaas @ 2026-07-13 17:49 UTC (permalink / raw)
To: Sizhe Liu
Cc: rostedt, mhiramat, mathieu.desnoyers, corbet, skhan, bhelgaas,
yangyccccc, jic23, john.g.garry, will, james.clark, mike.leach,
leo.yan, peterz, mingo, acme, namhyung, mark.rutland,
alexander.shishkin, jolsa, irogers, adrian.hunter, wangyushan12,
shenyang39, gaozhihao6, yuzhichengcheng, liyihang9, linux-kernel,
linux-pci, linux-perf-users, linux-arm-kernel, linux-doc,
linuxarm, prime.zeng, fanghao11, wuyifan50
In-Reply-To: <20260604075005.2219785-11-liusizhe5@huawei.com>
On Thu, Jun 04, 2026 at 03:50:05PM +0800, Sizhe Liu wrote:
> The hisi_ptt packet decoder now performs detailed field-level parsing
> of TLP header DW2 and DW3 based on the message type classified from
> DW0 (added in the previous patches). However, trace data recorded
> with older versions of the tool does not contain the information
> needed for this detailed parsing, and should continue to use the
> generic field-name-only output.
Add blank line between paragraphs. Also applies to 05/10.
> Introduce a version field (V1/V2) in the auxtrace info record to
> distinguish between the two data formats:
IMO a blank line here would also improve readability. And consider
indenting bullet points a couple spaces. Also applies to other commit
logs in this series, including sample formats.
> - V1 (legacy): auxtrace priv contains only PMU type. DW2 and DW3
> are printed with generic field names only, no message-type-based
> field decoding.
> - V2 (current): auxtrace priv contains PMU type and version. DW2
> and DW3 are decoded according to the TLP message type (MWr, Msg,
> Atomic, IO, CPL, Cfg) with detailed field names.
Could use imperative mood, e.g.,
- V1 (legacy): auxtrace priv contains only PMU type. Print DW2 and
DW3 generic field names only, no message-type-based field
decoding.
- V2 (current): auxtrace priv contains PMU type and version. Decode
DW2 and DW3 according to the TLP message type (MWr, Msg, Atomic,
IO, CPL, Cfg) with detailed field names.
> At recording time, set the version to HISI_PTT_DECODER_V2 in the
> auxtrace info. At decoding time, determine the version from the
> priv data size and the version field:
> - If priv_size >= V2, read the version from priv[1].
> - If priv_size < V2, assume V1 for backward compatibility.
> - If version is unknown (future), warn and decode auxtrace as v2.
>
> Also add the version to the dump output alongside the PMU type.
> Adjust hisi_ptt_pkt_size position to adapt to compilation.
AFAICS this series adds new functionality and probably doesn't qualify
for "stable" tags, given the documented rules. But I think the
maintainers are pretty aggressive about backporting things anyway.
^ permalink raw reply
* Re: [PATCH] PCI: rcar-gen4: Inline GIC_TRANSLATER offset macro
From: Bjorn Helgaas @ 2026-07-13 17:54 UTC (permalink / raw)
To: Marek Vasut
Cc: Marc Zyngier, linux-pci, kernel test robot,
Krzysztof Wilczyński, Bjorn Helgaas, Catalin Marinas,
Conor Dooley, Geert Uytterhoeven, Krzysztof Kozlowski,
Lorenzo Pieralisi, Manivannan Sadhasivam, Rob Herring,
Yoshihiro Shimoda, devicetree, linux-arm-kernel, linux-doc,
linux-kernel, linux-renesas-soc
In-Reply-To: <2cb03029-0957-4ed8-98bd-9b3e0e0bce2d@mailbox.org>
On Fri, Jul 10, 2026 at 03:35:10PM +0200, Marek Vasut wrote:
> On 7/10/26 10:30 AM, Marc Zyngier wrote:
> > On Thu, 09 Jul 2026 21:10:03 +0100,
> > Marek Vasut <marek.vasut+renesas@mailbox.org> wrote:
> > >
> > > Instead of pulling in the whole linux/irqchip/arm-gic-v3.h ,
> > > copy the one GITS_TRANSLATER register offset macro directly into
> > > the driver. This repairs the ability to build the driver on
> > > non-ARM non-GIC targets the way it was possible until now, which
> > > retains good build test coverage.
> ...
> So in the end, it is either this patch or limit the build to
> arm/arm64 . At least this patch still allows building this driver
> with more compilers on the various build bots, so I would opt for
> this patch here.
I like the build coverage, but duplicating the #define doesn't really
seem good to me. It makes readability worse because cscope/tags now
sees two definitions without an obvious reason.
^ permalink raw reply
* Re: [PATCH net-next v4 09/15] idpf: refactor idpf to use libie control queues
From: Larysa Zaremba @ 2026-07-13 17:55 UTC (permalink / raw)
To: Tony Nguyen
Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev,
Pavan Kumar Linga, przemyslaw.kitszel, aleksander.lobakin,
sridhar.samudrala, michal.swiatkowski, maciej.fijalkowski,
emil.s.tantilov, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc, Aleksandr Loktionov, Samuel Salin
In-Reply-To: <20260710215313.1475803-10-anthony.l.nguyen@intel.com>
Here are some minor changes that came out of Sashiko's review.
The first one is not needed, but does make code more consistent and robust.
The second one is updating kdoc, where Sashiko was concerned about a functional
change. I have checked that the functional change itself does not affect
any callers.
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
index 04a0421c1b77..d768b63700c8 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
@@ -2931,6 +2931,8 @@ int idpf_init_dflt_mbx(struct idpf_adapter *adapter)
adapter->arq = libie_find_ctlq(ctx, LIBIE_CTLQ_TYPE_RX,
LIBIE_CTLQ_MBX_ID);
if (!adapter->asq || !adapter->arq) {
+ adapter->asq = NULL;
+ adapter->arq = NULL;
libie_ctlq_xn_deinit(params.xnm, ctx);
return -ENOENT;
}
@@ -3993,7 +3995,7 @@ int idpf_set_promiscuous(struct idpf_adapter *adapter,
* @send_msg: message to send
* @msg_size: size of message to send
* @recv_msg: message to populate on reception of response
- * @recv_len: length of message copied into recv_msg or 0 on error
+ * @recv_len: length of message copied into recv_msg
*
* Return: 0 on success or error code on failure.
*/
Everything else:
> commit 9ebd6c429379be8477841f5180023c78d16732d0
> Author: Pavan Kumar Linga <pavan.kumar.linga@intel.com>
> idpf: refactor idpf to use libie control queues
> This refactors idpf to use the libie control-queue API, removing the
> in-tree idpf_controlq.[ch] and idpf_controlq_setup.c and reworking every
> virtchnl send/receive path to use libie_ctlq_xn_send_params /
> libie_ctlq_release_rx_buf(). A few observations below.
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > index 357ff3e86b2e..388075a07af7 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
> [ ... ]
> > @@ -4128,9 +3731,9 @@ static void idpf_set_mac_type(const u8 *default_mac_addr,
> >
> > /**
> > * idpf_mac_filter_async_handler - Async callback for mac filters
> [ ... ]
> > - */
> > -static int idpf_mac_filter_async_handler(struct idpf_adapter *adapter,
> > - struct idpf_vc_xn *xn,
> > - const struct idpf_ctlq_msg *ctlq_msg)
> > +static void idpf_mac_filter_async_handler(void *ctx,
> > + struct kvec *buff,
> > + int status)
> > {
> > struct virtchnl2_mac_addr_list *ma_list;
> > struct idpf_vport_config *vport_config;
> > struct virtchnl2_mac_addr *mac_addr;
> > + struct idpf_adapter *adapter = ctx;
> > struct idpf_mac_filter *f, *tmp;
> > struct list_head *ma_list_head;
> > struct idpf_vport *vport;
> > @@ -4152,18 +3756,18 @@ static int idpf_mac_filter_async_handler(struct idpf_adapter *adapter,
> > int i;
> >
> > /* if success we're done, we're only here if something bad happened */
> > - if (!ctlq_msg->cookie.mbx.chnl_retval)
> > - return 0;
> > + if (!status || status == -ETIMEDOUT)
> > + return;
> Should -ETIMEDOUT really be treated the same as success here?
> In the old code the async handler only ran when a reply was received,
> so a timeout could not reach this callback. With libie the async path
> now delivers -ETIMEDOUT via libie_xn_check_async_timeout(), and this
> new short-circuit returns immediately without reconciling the driver's
> mac_filter_list with what the CP actually applied.
> Note that idpf_add_del_mac_filters() clears f->add / f->remove for each
> entry before sending:
> if (add && f->add) {
> ether_addr_copy(mac_addr[i].addr, f->macaddr);
> idpf_set_mac_type(default_mac_addr, &mac_addr[i]);
> i++;
> f->add = false;
> So on -ETIMEDOUT those entries look "applied" to the driver while the
> CP never acknowledged them. Would it be safer to only skip work when
> status == 0 and fall through to the list_del reconciliation on
> -ETIMEDOUT the same way as for any other error?
>
On -ETIMEDOUT we do not have any buffer to handle.
In this case it could be either added or not, we do not know.
Both options lead us into a suboptimal situation, but treating it
as a success is simpler. Also, 2 minute timeout probably means you
should reload something anyway.
[...]
> > int idpf_send_dealloc_vectors_msg(struct idpf_adapter *adapter)
> > {
> > struct virtchnl2_alloc_vectors *ac = adapter->req_vec_chunks;
> > - struct virtchnl2_vector_chunks *vcs = &ac->vchunks;
> > - struct idpf_vc_xn_params xn_params = {};
> > - ssize_t reply_sz;
> > - int buf_size;
> > + struct libie_ctlq_xn_send_params xn_params = {
> > + .timeout_ms = IDPF_VC_XN_DEFAULT_TIMEOUT_MSEC,
> > + .chnl_opcode = VIRTCHNL2_OP_DEALLOC_VECTORS,
> > + };
> > + struct virtchnl2_vector_chunks *vcs;
> > + int buf_size, err;
> >
> > - buf_size = struct_size(vcs, vchunks, le16_to_cpu(vcs->num_vchunks));
> > + buf_size = struct_size(&ac->vchunks, vchunks,
> > + le16_to_cpu(ac->vchunks.num_vchunks));
> > + vcs = kmemdup(&ac->vchunks, buf_size, GFP_KERNEL);
> > + if (!vcs)
> > + return -ENOMEM;
> >
> > - xn_params.vc_op = VIRTCHNL2_OP_DEALLOC_VECTORS;
> > - xn_params.send_buf.iov_base = vcs;
> > - xn_params.send_buf.iov_len = buf_size;
> > - xn_params.timeout_ms = IDPF_VC_XN_DEFAULT_TIMEOUT_MSEC;
> > - reply_sz = idpf_vc_xn_exec(adapter, &xn_params);
> > - if (reply_sz < 0)
> > - return reply_sz;
> > + err = idpf_send_mb_msg_kfree(adapter, &xn_params, vcs, buf_size);
> > + if (err)
> > + return err;
> >
> > kfree(adapter->req_vec_chunks);
> > adapter->req_vec_chunks = NULL;
> Does this code leak adapter->req_vec_chunks on the error path?
> On success the kfree()/NULL of adapter->req_vec_chunks runs after
> idpf_send_mb_msg_kfree(). On error the function returns err early
> while adapter->req_vec_chunks is still allocated.
> Its caller is idpf_intr_rel():
> void idpf_intr_rel(struct idpf_adapter *adapter)
> {
> ...
> idpf_send_dealloc_vectors_msg(adapter);
> idpf_deinit_vector_stack(adapter);
> kfree(adapter->msix_entries);
> adapter->msix_entries = NULL;
> kfree(adapter->rdma_msix_entries);
> adapter->rdma_msix_entries = NULL;
> }
> which does not free req_vec_chunks either. Is there another site
> that frees adapter->req_vec_chunks when the dealloc virtchnl fails
> (for example on a mailbox timeout during teardown), or does it
> accumulate across reset/unload attempts?
>
Seems so, but this is a preexistent issue
[...]
> > diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl_ptp.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl_ptp.c
> > index 8d8fb498e092..1d8dd67e299d 100644
> > --- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl_ptp.c
> > +++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl_ptp.c
> [ ... ]
> > @@ -234,23 +244,18 @@ int idpf_ptp_set_dev_clk_time(struct idpf_adapter *adapter, u64 time)
> > struct virtchnl2_ptp_set_dev_clk_time set_dev_clk_time_msg = {
> > .dev_time_ns = cpu_to_le64(time),
> > };
> > - struct idpf_vc_xn_params xn_params = {
> > - .vc_op = VIRTCHNL2_OP_PTP_SET_DEV_CLK_TIME,
> > - .send_buf.iov_base = &set_dev_clk_time_msg,
> > - .send_buf.iov_len = sizeof(set_dev_clk_time_msg),
> > - .recv_buf.iov_base = &set_dev_clk_time_msg,
> > - .recv_buf.iov_len = sizeof(set_dev_clk_time_msg),
> > + struct libie_ctlq_xn_send_params xn_params = {
> > + .chnl_opcode = VIRTCHNL2_OP_PTP_SET_DEV_CLK_TIME,
> > .timeout_ms = IDPF_VC_XN_DEFAULT_TIMEOUT_MSEC,
> > };
> > - int reply_sz;
> > + int err;
> >
> > - reply_sz = idpf_vc_xn_exec(adapter, &xn_params);
> > - if (reply_sz < 0)
> > - return reply_sz;
> > - if (reply_sz != sizeof(set_dev_clk_time_msg))
> > - return -EIO;
> > + err = idpf_send_mb_msg(adapter, &xn_params, &set_dev_clk_time_msg,
> > + sizeof(set_dev_clk_time_msg));
> > + if (!err)
> > + libie_ctlq_release_rx_buf(&xn_params.recv_mem);
> >
> > - return 0;
> > + return err;
> > }
> Is dropping the reply-size check here intentional?
> The pre-patch code explicitly rejected a malformed reply:
> if (reply_sz != sizeof(set_dev_clk_time_msg))
> return -EIO;
> The refactored helper only surfaces the return code of
> idpf_send_mb_msg() and unconditionally releases the Rx buffer, so a
> short/truncated payload from the CP is silently accepted as success.
> The same reply-size check has also been dropped in
> idpf_ptp_adj_dev_clk_time() and idpf_ptp_adj_dev_clk_fine():
> > @@ -267,23 +272,18 @@ int idpf_ptp_adj_dev_clk_time(struct idpf_adapter *adapter, s64 delta)
> > struct virtchnl2_ptp_adj_dev_clk_time adj_dev_clk_time_msg = {
> > .delta = cpu_to_le64(delta),
> > };
> [ ... ]
> > - reply_sz = idpf_vc_xn_exec(adapter, &xn_params);
> > - if (reply_sz < 0)
> > - return reply_sz;
> > - if (reply_sz != sizeof(adj_dev_clk_time_msg))
> > - return -EIO;
> > + err = idpf_send_mb_msg(adapter, &xn_params, &adj_dev_clk_time_msg,
> > + sizeof(adj_dev_clk_time_msg));
> > + if (!err)
> > + libie_ctlq_release_rx_buf(&xn_params.recv_mem);
> > @@ -301,23 +301,18 @@ int idpf_ptp_adj_dev_clk_fine(struct idpf_adapter *adapter, u64 incval)
> > struct virtchnl2_ptp_adj_dev_clk_fine adj_dev_clk_fine_msg = {
> > .incval = cpu_to_le64(incval),
> > };
> [ ... ]
> > - reply_sz = idpf_vc_xn_exec(adapter, &xn_params);
> > - if (reply_sz < 0)
> > - return reply_sz;
> > - if (reply_sz != sizeof(adj_dev_clk_fine_msg))
> > - return -EIO;
> > + err = idpf_send_mb_msg(adapter, &xn_params, &adj_dev_clk_fine_msg,
> > + sizeof(adj_dev_clk_fine_msg));
> > + if (!err)
> > + libie_ctlq_release_rx_buf(&xn_params.recv_mem);
> Should these three helpers keep validating that
> xn_params.recv_mem.iov_len matches the expected reply size, the way
> idpf_ptp_get_caps() and idpf_ptp_get_dev_clk_time() still do?
No need to validate size, if we do not use the buffer.
^ permalink raw reply related
* Re: [PATCH net-next v4 14/15] ixd: add the core initialization
From: Larysa Zaremba @ 2026-07-13 18:13 UTC (permalink / raw)
To: Tony Nguyen
Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev,
przemyslaw.kitszel, aleksander.lobakin, sridhar.samudrala,
michal.swiatkowski, maciej.fijalkowski, emil.s.tantilov,
madhu.chittim, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc, Bharath R
In-Reply-To: <20260710215313.1475803-15-anthony.l.nguyen@intel.com>
Sashiko expressed concerns with virtchnl version handling in ixd. I think it is
fine as-is, but here is how it can be addressed:
commit 736215457094a287aa8f40af322e0bc7ab94dddc
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date: Mon Jul 13 15:44:55 2026 +0200
fixup! ixd: add the core initialization
diff --git a/drivers/net/ethernet/intel/ixd/ixd_virtchnl.c b/drivers/net/ethernet/intel/ixd/ixd_virtchnl.c
index 66049d1b1d15..5b04769443b9 100644
--- a/drivers/net/ethernet/intel/ixd/ixd_virtchnl.c
+++ b/drivers/net/ethernet/intel/ixd/ixd_virtchnl.c
@@ -120,8 +120,11 @@ static int ixd_handle_vc_ver(struct ixd_adapter *adapter, void *recv_buff,
return -EBADMSG;
recv_ver = recv_buff;
- if (le32_to_cpu(need_ver.major) > le32_to_cpu(recv_ver->major))
+ if (le32_to_cpu(need_ver.major) != le32_to_cpu(recv_ver->major))
return -EOPNOTSUPP;
+ if (le32_to_cpu(recv_ver->minor) != le32_to_cpu(need_ver.minor))
+ dev_warn(ixd_to_dev(adapter),
+ "Virtchnl minor version does not match, proceed with caution\n");
adapter->vc_ver.major = le32_to_cpu(recv_ver->major);
adapter->vc_ver.minor = le32_to_cpu(recv_ver->minor);
Everything else:
[...]
> > + libie_ctlq_xn_shutdown(adapter->xnm);
> > + ixd_trigger_reset(adapter);
> > + ixd_deinit_dflt_mbx(adapter);
> Could this sequence trigger a race condition causing PCIe AER fatal errors?
> The hardware reset is triggered here before the mailbox polling task
> (mbx_task) is canceled inside ixd_deinit_dflt_mbx().
> If mbx_task runs concurrently with or immediately after the reset trigger,
> it might access MMIO doorbell registers while the device is actively in a
> global reset.
>
Not an issue with available HW
[...]
> > ixd_trigger_reset(adapter);
> > ixd_deinit_dflt_mbx(adapter);
> Similarly to ixd_init_task(), does triggering the reset before
> ixd_deinit_dflt_mbx() here risk the mbx_task touching MMIO during reset?
> Perhaps the newly added polling task should be canceled before the hardware
> reset is triggered?
>
This is not an issue with available HW, and consistent with existing idpf flow.
[...]
> > +static int ixd_req_vc_caps(struct ixd_adapter *adapter)
> > +{
> > + const struct ixd_ctlq_req req = {
> > + .opcode = VIRTCHNL2_OP_GET_CAPS,
> > + .send_size = sizeof(struct virtchnl2_get_capabilities),
> > + .ctx = NULL,
> > + .send_buff_init = NULL,
> > + .recv_process = ixd_handle_caps,
> > + };
> > +
> > + return ixd_ctlq_do_req(adapter, &req);
> > +}
> Because send_buff_init is NULL, will the driver send an all-zero request
> payload for capabilities and resources?
> Requesting 0 max vectors and 0 RX queues might cause the Control Plane to
> respond with only the default mailbox vector, starving the driver of
> interrupts for its networking queues.
>
We do not currently have any queues
[...]
^ permalink raw reply related
* Re: [PATCH v6 2/3] iommu/arm-smmu-v3: Introduce CFGI/TLBI-repeat workaround infrastructure
From: Nicolin Chen @ 2026-07-13 18:24 UTC (permalink / raw)
To: Ashish Mhetre
Cc: catalin.marinas, will, corbet, skhan, robin.murphy, joro, jgg,
linux-arm-kernel, linux-doc, linux-kernel, iommu, linux-tegra
In-Reply-To: <20260713111543.1462161-3-amhetre@nvidia.com>
On Mon, Jul 13, 2026 at 11:15:41AM +0000, Ashish Mhetre wrote:
> Tegra264 SMMU instances need every CFGI/TLBI command sequence issued
> twice, with the second issue executing only after the first issue's
> CMD_SYNC has completed:
>
> TLBI/CFGI ... CMD_SYNC TLBI/CFGI ... CMD_SYNC
>
> ATC_INV is not affected and must never be doubled.
>
> Add arm_smmu_erratum_repeat_tlbi_cfgi_key and an
> arm_smmu_erratum_cmd_needs_repeating() helper that gates on the static
> key first and then range-checks the opcode (CFGI_STE .. ATC_INV), so
> subsequent changes wiring the workaround into the CMDQ submission and
> iommufd batching paths can share a single predicate.
>
> Rename the existing arm_smmu_cmdq_issue_cmdlist() to
> __arm_smmu_cmdq_issue_cmdlist() and add a thin wrapper that re-issues
> the same cmdlist a second time when the predicate fires. Register the
> new condition with arm_smmu_cmdq_batch_force_sync() and add
> arm_vsmmu_can_batch_cmd() so iommufd batches split at every "needs
> repeating" transition.
>
> No callers enable the static key yet, so there is no functional change.
> A subsequent change will enable the key on affected instances.
Maybe add a small note (better in patch-3).
Note: since guest-level VCMDQs issue commands directly to the HW, a guest
kernel enabling the cmdqv feature on NVIDIA Tegra264 must apply this WAR.
> Suggested-by: Nicolin Chen <nicolinc@nvidia.com>
> Signed-off-by: Ashish Mhetre <amhetre@nvidia.com>
Reviewed-by: Nicolin Chen <nicolinc@nvidia.com>
Some small issues; please fix:
> +static bool arm_vsmmu_can_batch_cmd(struct arm_smmu_device *smmu,
> + struct arm_vsmmu_invalidation_cmd *last,
> + struct arm_vsmmu_invalidation_cmd *next)
@smmu is unused here.
> diff --git a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> index dd7475c50afc..eb8374cfce2a 100644
> --- a/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> +++ b/drivers/iommu/arm/arm-smmu-v3/arm-smmu-v3.c
> @@ -42,6 +42,14 @@ MODULE_PARM_DESC(disable_msipolling,
> static const struct iommu_ops arm_smmu_ops;
> static struct iommu_dirty_ops arm_smmu_dirty_ops;
>
> +/*
> + * Repeat every {CFGI,TLBI};CMD_SYNC command sequence so that the second
> + * issue executes only after the first issue's CMD_SYNC has completed.
> + * Does not apply to ATC_INV. The key is global and is enabled from DT
> + * probe on affected hardware (currently Tegra264 only).
> + */
> +static DEFINE_STATIC_KEY_FALSE(arm_smmu_erratum_repeat_tlbi_cfgi_key);
Since we defined a static key, it would be better explicitly add:
#include <linux/jump_label.h>
> @@ -860,6 +900,11 @@ static bool arm_smmu_cmdq_batch_force_sync(struct arm_smmu_device *smmu,
> (smmu->options & ARM_SMMU_OPT_CMDQ_FORCE_SYNC))
> return true;
>
> + /* See the description at arm_smmu_erratum_repeat_tlbi_cfgi_key */
> + if (cmds->num == CMDQ_BATCH_ENTRIES &&
> + arm_smmu_erratum_cmd_needs_repeating(&cmds->cmds[0]))
> + return true;
/*
* See the description at arm_smmu_erratum_repeat_tlbi_cfgi_key. Batches
* never mix CFGI/TLBI with others, so checking cmds[0] alone is enough.
*/
Nicolin
^ permalink raw reply
* Re: [PATCH v3] docs: pt_BR: process: Translate stable kernel rules guide
From: Daniel Pereira @ 2026-07-13 18:26 UTC (permalink / raw)
To: Matheus Patriota; +Cc: linux-doc
In-Reply-To: <20260713125113.20976-1-matheuslinuxdeb@gmail.com>
Em seg., 13 de jul. de 2026 às 09:51, Matheus Patriota
<matheuslinuxdeb@gmail.com> escreveu:
>
> Translates the documentation regarding stable kernel rules into
> Brazilian Portuguese, maintaining consistency with original
> formatting rules.
>
> Changes in v3:
> - Removed the Sphinx label to avoid conflict with the original
> documentation, as suggested by Daniel Pereira.
> - Removed duplicated/incorrectly named files from the commit.
>
> Changes in v2:
> - I changed the patch name to avoid conflicts with the original patch.
> - I adjusted the dashes by replacing them with commas.
> - Regarding the typo, I corrected "concluídasamp" to "concluídas".
>
> Signed-off-by: Matheus Patriota <matheuslinuxdeb@gmail.com>
Hi Matheus,
The grammar looks good, and I'm in agreement with these changes.
Acked-by: Daniel Pereira <danielmaraboo@gmail.com>
^ permalink raw reply
* Re: [PATCH net-next v4 00/15][pull request] Introduce iXD driver
From: Larysa Zaremba @ 2026-07-13 18:29 UTC (permalink / raw)
To: Tony Nguyen
Cc: davem, kuba, pabeni, edumazet, andrew+netdev, netdev,
przemyslaw.kitszel, aleksander.lobakin, sridhar.samudrala,
michal.swiatkowski, maciej.fijalkowski, emil.s.tantilov,
madhu.chittim, joshua.a.hay, jacob.e.keller,
jayaprakash.shanmugam, jiri, horms, corbet, richardcochran,
linux-doc
In-Reply-To: <20260710215313.1475803-1-anthony.l.nguyen@intel.com>
I have addressed Sashiko's feedback for each patch.
Those are the only 2 important changes that came out of that.
Please, notice that the first one is not a functional regression, but a memory
usage issue and I tested the change.
commit d7a772efb77228a1b12558dced6b1fdfeef123c4
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date: Mon Jul 13 17:02:01 2026 +0200
fixup! libie: add bookkeeping support for control queue messages
diff --git a/drivers/net/ethernet/intel/libie/controlq.c b/drivers/net/ethernet/intel/libie/controlq.c
index c043c07dbb89..8e7b2783b86b 100644
--- a/drivers/net/ethernet/intel/libie/controlq.c
+++ b/drivers/net/ethernet/intel/libie/controlq.c
@@ -720,7 +720,7 @@ static int libie_ctlq_xn_init_dma(struct device *dev,
goto dealloc_dma;
dma_mem->va = libie_cp_alloc_dma_mem(dev, dma_mem,
- LIBIE_CTLQ_MAX_BUF_LEN);
+ LIBIE_CP_TX_COPYBREAK);
if (!dma_mem->va) {
kfree(dma_mem);
goto dealloc_dma;
commit 740e3b2dc9fab1ad24ee7fa1420d0c7025bc89ac
Author: Larysa Zaremba <larysa.zaremba@intel.com>
Date: Mon Jul 13 20:25:21 2026 +0200
fixup! libie: add control queue support
diff --git a/drivers/net/ethernet/intel/libie/controlq.c b/drivers/net/ethernet/intel/libie/controlq.c
index 0392608856c8..c043c07dbb89 100644
--- a/drivers/net/ethernet/intel/libie/controlq.c
+++ b/drivers/net/ethernet/intel/libie/controlq.c
@@ -509,6 +509,7 @@ void libie_ctlq_send(struct libie_ctlq_info *ctlq, u32 num_q_msg)
if (unlikely(++ntu == ctlq->ring_len))
ntu = 0;
}
+ dma_wmb();
writel(ntu, ctlq->reg.tail);
ctlq->next_to_use = ntu;
}
Other changes are of much lesser importance. Look at particular patches for
details on nice-to-haves and false positives. Here is overall nice-to-have diff:
diff --git a/drivers/net/ethernet/intel/idpf/idpf_main.c b/drivers/net/ethernet/intel/idpf/idpf_main.c
index 5a191644b28e..184d30c12abb 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_main.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_main.c
@@ -265,8 +265,9 @@ static int idpf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
err = idpf_dev_init(adapter, ent);
if (err) {
- dev_err(&pdev->dev, "Unexpected dev ID 0x%x in idpf probe\n",
- ent->device);
+ dev_err(&pdev->dev,
+ "Failed to initialize device (ID 0x%x): %d\n",
+ ent->device, err);
goto err_free;
}
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
index 04a0421c1b77..d768b63700c8 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
@@ -2931,6 +2931,8 @@ int idpf_init_dflt_mbx(struct idpf_adapter *adapter)
adapter->arq = libie_find_ctlq(ctx, LIBIE_CTLQ_TYPE_RX,
LIBIE_CTLQ_MBX_ID);
if (!adapter->asq || !adapter->arq) {
+ adapter->asq = NULL;
+ adapter->arq = NULL;
libie_ctlq_xn_deinit(params.xnm, ctx);
return -ENOENT;
}
@@ -3993,7 +3995,7 @@ int idpf_set_promiscuous(struct idpf_adapter *adapter,
* @send_msg: message to send
* @msg_size: size of message to send
* @recv_msg: message to populate on reception of response
- * @recv_len: length of message copied into recv_msg or 0 on error
+ * @recv_len: length of message copied into recv_msg
*
* Return: 0 on success or error code on failure.
*/
diff --git a/drivers/net/ethernet/intel/ixd/ixd_virtchnl.c b/drivers/net/ethernet/intel/ixd/ixd_virtchnl.c
index 66049d1b1d15..5b04769443b9 100644
--- a/drivers/net/ethernet/intel/ixd/ixd_virtchnl.c
+++ b/drivers/net/ethernet/intel/ixd/ixd_virtchnl.c
@@ -120,8 +120,11 @@ static int ixd_handle_vc_ver(struct ixd_adapter *adapter, void *recv_buff,
return -EBADMSG;
recv_ver = recv_buff;
- if (le32_to_cpu(need_ver.major) > le32_to_cpu(recv_ver->major))
+ if (le32_to_cpu(need_ver.major) != le32_to_cpu(recv_ver->major))
return -EOPNOTSUPP;
+ if (le32_to_cpu(recv_ver->minor) != le32_to_cpu(need_ver.minor))
+ dev_warn(ixd_to_dev(adapter),
+ "Virtchnl minor version does not match, proceed with caution\n");
adapter->vc_ver.major = le32_to_cpu(recv_ver->major);
adapter->vc_ver.minor = le32_to_cpu(recv_ver->minor);
diff --git a/drivers/net/ethernet/intel/libie/controlq.c b/drivers/net/ethernet/intel/libie/controlq.c
index 885b4437b4f0..8e7b2783b86b 100644
--- a/drivers/net/ethernet/intel/libie/controlq.c
+++ b/drivers/net/ethernet/intel/libie/controlq.c
@@ -327,7 +327,8 @@ libie_ctlq_add(struct libie_ctlq_ctx *ctx,
{
struct libie_ctlq_info *ctlq;
- if (qinfo->id != LIBIE_CTLQ_MBX_ID)
+ if (qinfo->id != LIBIE_CTLQ_MBX_ID ||
+ qinfo->len > FIELD_MAX(LIBIE_CTLQ_MBX_ATQ_LEN))
return ERR_PTR(-EOPNOTSUPP);
/* libie_ctlq_init was not called */
@@ -493,8 +494,6 @@ EXPORT_SYMBOL_NS_GPL(libie_ctlq_send_desc_avail, "LIBIE_CP");
* The caller must hold ctlq->lock. The intended pattern is to first check
* the number of descriptors available, then fill in the messages and perform
* send within a single critical section.
- *
- * Return: %0 on success, -%errno on failure.
*/
void libie_ctlq_send(struct libie_ctlq_info *ctlq, u32 num_q_msg)
{
^ permalink raw reply related
* Re: [PATCH v2] docs: pt_BR: process: Translate the kernel driver statement
From: Daniel Pereira @ 2026-07-13 18:32 UTC (permalink / raw)
To: Igor Giamoniano, Jonathan Corbet; +Cc: linux-doc
In-Reply-To: <20260709222953.9900-1-igorgphotoarte@gmail.com>
Em qui., 9 de jul. de 2026 às 19:29, Igor Giamoniano
<igorgphotoarte@gmail.com> escreveu:
>
> Translate Documentation/process/kernel-driver-statement.rst into Brazilian
> Portuguese, keeping the reStructuredText formatting and the list of
> signatories unchanged.
>
> Signed-off-by: Igor Giamoniano <igorgphotoarte@gmail.com>
Hi Igor,
Sorry for the delay in responding. For some reason, the v2 email got
bundled within the v1 thread in my email provider, so I had some
trouble locating it.
I have reviewed the changes, and everything looks correct. The grammar
is good, and the logic is sound.
Acked-by: Daniel Pereira <danielmaraboo@gmail.com>
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH v2] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: 葉宸佑 @ 2026-07-13 19:47 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: <alS8lLglyMqJEYZ4@wyuan.org>
Hi Dongliang, Weijie,
> For many files, the missing commits might not be needed as they might
> not affect the translation (such as typos in English).
Right -- which means the real workload is smaller than the raw numbers
suggest. For files where the pending commits turn out to be
English-only fixes, the update can be a trivial baseline bump
(an "update to commit HASH" commit with little or no content change),
so the tool's numbers stay meaningful without inventing work.
> Because this new commit style is developed recently by Yanteng and me,
> many translated documenation does not tranform to the corresponding styles.
Good to know the convention is recent -- zh_TW can simply adopt it
from the first series onward.
> For the todo list, you can check Jon's advice for new languages, e.g.,
> Spanish. Search it from LKML
Will do, thanks for the pointer.
> 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.
Weijie: agreed, a zh_TW how-to (mirroring the zh_CN one, with the
glossary referenced) looks like the natural follow-up once the first
series settles the terminology. Adding it to the list.
So, to keep everything in one place, my understanding of the plan:
- Chen-Yu: terminology series for process/ (14 files), folding in the
pending 8.Conclusion changes, glossary included; adopt the
"update to commit HASH" convention from now on
- Chen-Yu: read Jon's advice for new-language efforts (Spanish thread)
- later: a zh_TW how-to document
- Weijie: investigate which documents may not need translation;
monitor the CN/TW lists during the trial period
- Dongliang: review; patches routed through Alex's tree (pending
Alex's confirmation)
If I got anything wrong, please correct me -- otherwise I will get
started on the series.
Thanks,
Chen-Yu
Weijie Yuan <wy@wyuan.org> 於 2026年7月13日週一 下午6:23寫道：
>
> 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
* Re: [PATCH RFC v2 1/9] leds: Add callback offloaded() to query the state of hardware control trigger
From: Thomas Weißschuh @ 2026-07-13 20:27 UTC (permalink / raw)
To: Rong Zhang
Cc: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Benson Leung, Guenter Roeck, Marek Behún, Mark Pearson,
Derek J. Clark, Hans de Goede, Ilpo Järvinen, Ike Panhc,
Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86
In-Reply-To: <20260618-leds-trigger-hw-changed-v2-1-c28c44053cf3@rong.moe>
On 2026-06-18 00:47:55+0800, Rong Zhang wrote:
> There are multiple triggers implementing hardware control. However, the
> LED core doesn't really know the hardware control state since the
> coordination is done directly between the trigger and the LED device.
>
> Add an offloaded() callback so that the LED core can query the hardware
> control state.
For review it would be easier if the code using the new callback was
introduced *before* the driver implementation.
> Signed-off-by: Rong Zhang <i@rong.moe>
> ---
> Documentation/leds/leds-class.rst | 5 +++++
> include/linux/leds.h | 1 +
> 2 files changed, 6 insertions(+)
(...)
^ permalink raw reply
* Re: [PATCH RFC v2 2/9] leds: cros_ec: Implement offloaded() callback for trigger
From: Thomas Weißschuh @ 2026-07-13 20:28 UTC (permalink / raw)
To: Rong Zhang
Cc: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Benson Leung, Guenter Roeck, Marek Behún, Mark Pearson,
Derek J. Clark, Hans de Goede, Ilpo Järvinen, Ike Panhc,
Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86
In-Reply-To: <20260618-leds-trigger-hw-changed-v2-2-c28c44053cf3@rong.moe>
On 2026-06-18 00:47:56+0800, Rong Zhang wrote:
> "chromeos-auto" is a private hardware control trigger which always stays
> in hardware control. Implement offloaded() callback with its return
> value to be always true to reflect this.
>
> Signed-off-by: Rong Zhang <i@rong.moe>
Reviewed-by: Thomas Weißschuh <linux@weissschuh.net>
> ---
> drivers/leds/leds-cros_ec.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/leds/leds-cros_ec.c b/drivers/leds/leds-cros_ec.c
> index bea3cc3fbfd2..f48e3cf6ccf6 100644
> --- a/drivers/leds/leds-cros_ec.c
> +++ b/drivers/leds/leds-cros_ec.c
> @@ -86,12 +86,18 @@ static int cros_ec_led_trigger_activate(struct led_classdev *led_cdev)
> return cros_ec_led_send_cmd(priv->cros_ec, &arg);
> }
>
> +static bool cros_ec_led_trigger_offloaded(struct led_classdev *led_cdev)
> +{
> + return true;
> +}
> +
> static struct led_hw_trigger_type cros_ec_led_trigger_type;
>
> static struct led_trigger cros_ec_led_trigger = {
> .name = "chromeos-auto",
> .trigger_type = &cros_ec_led_trigger_type,
> .activate = cros_ec_led_trigger_activate,
> + .offloaded = cros_ec_led_trigger_offloaded,
> };
>
> static int cros_ec_led_brightness_set_blocking(struct led_classdev *led_cdev,
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH RFC v2 5/9] leds: Add trigger_may_offload attribute
From: Thomas Weißschuh @ 2026-07-13 20:36 UTC (permalink / raw)
To: Rong Zhang
Cc: Lee Jones, Pavel Machek, Jonathan Corbet, Shuah Khan,
Benson Leung, Guenter Roeck, Marek Behún, Mark Pearson,
Derek J. Clark, Hans de Goede, Ilpo Järvinen, Ike Panhc,
Andrew Lunn, Jakub Kicinski, Vishnu Sankar, Vishnu Sankar,
linux-leds, netdev, linux-doc, linux-kernel, chrome-platform,
platform-driver-x86
In-Reply-To: <20260618-leds-trigger-hw-changed-v2-5-c28c44053cf3@rong.moe>
On 2026-06-18 00:47:59+0800, Rong Zhang wrote:
> There are multiple triggers implementing hardware control. Only "netdev"
> provides a custom attribute to determine if it's offloaded to hardware
> (i.e., in hardware control). For other triggers, there is no obvious way
> for userspace to determine the trigger state programmatically. Moreover,
> userspace can't query if an LED device supports hardware control or
> identifies these triggers.
>
> Add a new attribute "trigger_may_offload" to the LED core, so that
> userspace can determine:
>
> - if the LED device supports hardware control (supported => visible)
> - which trigger is the hardware control trigger selected by the LED
> device
> - if the trigger is selected ("<foo_trigger>")
> - if the trigger is offloaded ("[foo_trigger]")
>
> Note: the documentation describes the attribute as "returning a list"
> despite the LED core currently only supports one hardware control
> trigger per LED device. This is intentional to make the attribute
> extensible in the future without breaking userspace.
Maybe also mention that the old 'offloaded' attribute is deprecated.
However, does it really need to be deprecated?
> Signed-off-by: Rong Zhang <i@rong.moe>
> ---
> .../ABI/obsolete/sysfs-class-led-trigger-netdev | 16 ++++++++
> Documentation/ABI/testing/sysfs-class-led | 22 +++++++++++
> .../ABI/testing/sysfs-class-led-trigger-netdev | 13 -------
> Documentation/leds/leds-class.rst | 8 ++++
> drivers/leds/led-class.c | 23 +++++++++++
> drivers/leds/led-triggers.c | 45 ++++++++++++++++++++++
> drivers/leds/leds.h | 2 +
> drivers/leds/trigger/ledtrig-netdev.c | 2 +
> 8 files changed, 118 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/ABI/obsolete/sysfs-class-led-trigger-netdev b/Documentation/ABI/obsolete/sysfs-class-led-trigger-netdev
> new file mode 100644
> index 000000000000..8d2fbfaf50c3
> --- /dev/null
> +++ b/Documentation/ABI/obsolete/sysfs-class-led-trigger-netdev
> @@ -0,0 +1,16 @@
> +What: /sys/class/leds/<led>/offloaded
> +Date: June 2026
> +KernelVersion: 7.3
> +Contact: linux-leds@vger.kernel.org
> +Description:
> + Communicate whether the LED trigger modes are offloaded to
> + hardware or whether software fallback is used.
> +
> + If 0, the LED is using software fallback to blink.
> +
> + If 1, the LED blinking in requested mode is offloaded to
> + hardware.
> +
> + /sys/class/leds/<led>/trigger_may_offload provides a generic
> + method to query the offloaded state of supported triggers,
> + superseding this attribute.
> diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led
> index 0313b82644f2..edd5a9a74dfd 100644
> --- a/Documentation/ABI/testing/sysfs-class-led
> +++ b/Documentation/ABI/testing/sysfs-class-led
> @@ -78,6 +78,28 @@ Description:
> (which would often be configured in the device tree for the
> hardware).
>
> +What: /sys/class/leds/<led>/trigger_may_offload
> +Date: June 2026
> +KernelVersion: 7.3
> +Contact: linux-leds@vger.kernel.org
> +Description:
> + Names and states of triggers that may be offloaded to hardware.
> + Such triggers are also called "hw control trigger" in some
> + context.
> +
> + Only exists when the LED supports trigger offload.
> +
> + Reading this file returns a list of triggers that are capable to
> + be offloaded. The optional brackets around the trigger name
> + indicate the state of the current trigger:
> +
> + - `foo_trigger`: the trigger is not selected.
> + - `<foo_trigger>`: the trigger is selected, but falls back to
> + software blink for some reason (e.g., incompatible trigger
> + parameters)
> + - `[foo_trigger]`: the trigger is selected and offloaded to
> + hardware.
> +
> What: /sys/class/leds/<led>/inverted
> Date: January 2011
> KernelVersion: 2.6.38
> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
> index ed46b37ab8a2..396d37a4b820 100644
> --- a/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-netdev
> @@ -62,19 +62,6 @@ Description:
> When offloaded is true, the blink interval is controlled by
> hardware and won't reflect the value set in interval.
>
> -What: /sys/class/leds/<led>/offloaded
> -Date: Jun 2023
> -KernelVersion: 6.5
> -Contact: linux-leds@vger.kernel.org
> -Description:
> - Communicate whether the LED trigger modes are offloaded to
> - hardware or whether software fallback is used.
> -
> - If 0, the LED is using software fallback to blink.
> -
> - If 1, the LED blinking in requested mode is offloaded to
> - hardware.
> -
> What: /sys/class/leds/<led>/link_10
> Date: Jun 2023
> KernelVersion: 6.5
> diff --git a/Documentation/leds/leds-class.rst b/Documentation/leds/leds-class.rst
> index 84665200a88d..41342ecb5f6b 100644
> --- a/Documentation/leds/leds-class.rst
> +++ b/Documentation/leds/leds-class.rst
> @@ -179,6 +179,9 @@ ops and needs to declare specific support for the supported triggers.
>
> With hw control we refer to the LED driven by hardware.
>
> +A sysfs attribute `trigger_may_offload` is provided for userspace to
> +query supported triggers and their states.
> +
> LED driver must define the following value to support hw control:
>
> - hw_control_trigger:
> @@ -240,6 +243,11 @@ LED trigger must implement the following API to support hw control:
> return a boolean indicating if the trigger is offloaded to
> hardware.
>
> + If an LED driver specifies a hw control trigger but the
> + latter doesn't implement this callback, a dev_err_once will
> + be emitted and the LED trigger will be assumed to be not
> + offloaded.
Not sure if this needs to be documented.
I would make this optional initally and enforce it after all the drivers
have been changed in the series.
> +
> LED driver can activate additional modes by default to workaround the
> impossibility of supporting each different mode on the supported trigger.
> Examples are hardcoding the blink speed to a set interval, enable special
> diff --git a/drivers/leds/led-class.c b/drivers/leds/led-class.c
> index 9e14ae588f78..0ac80b93b8b5 100644
> --- a/drivers/leds/led-class.c
> +++ b/drivers/leds/led-class.c
> @@ -90,8 +90,31 @@ static const struct bin_attribute *const led_trigger_bin_attrs[] = {
> &bin_attr_trigger,
> NULL,
> };
> +
> +static DEVICE_ATTR(trigger_may_offload, 0444, led_trigger_may_offload_show, NULL);
DEVICE_ATTR_RO()
> +static struct attribute *led_trigger_attrs[] = {
> + &dev_attr_trigger_may_offload.attr,
> + NULL,
No comma after the sentinel.
> +};
> +
> +static umode_t led_trigger_is_visible(struct kobject *kobj,
> + struct attribute *attr,
> + int idx)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> +
> + if (attr == &dev_attr_trigger_may_offload.attr &&
> + !led_cdev->hw_control_trigger)
Can be a single line.
> + return 0;
> +
> + return attr->mode;
> +}
> +
> static const struct attribute_group led_trigger_group = {
> .bin_attrs = led_trigger_bin_attrs,
> + .attrs = led_trigger_attrs,
> + .is_visible = led_trigger_is_visible,
> };
> #endif
>
> diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
> index b1223218bda1..c43229d9c4c1 100644
> --- a/drivers/leds/led-triggers.c
> +++ b/drivers/leds/led-triggers.c
> @@ -313,6 +313,51 @@ void led_trigger_set_default(struct led_classdev *led_cdev)
> }
> EXPORT_SYMBOL_GPL(led_trigger_set_default);
>
> +/*
> + * Caller must ensure led_cdev->trigger_lock held,
Use lockdep_assert_held() to document and validate locking invariants.
> + * and led_cdev->trigger->name must match led_cdev->hw_control_trigger.
> + */
> +static bool led_trigger_get_offloaded(struct led_classdev *led_cdev)
> +{
> + if (likely(led_cdev->trigger->offloaded))
> + return led_cdev->trigger->offloaded(led_cdev);
> +
> + dev_err_once(led_cdev->dev,
> + "hw control trigger %s doesn't implement offloaded(), this is a bug\n",
> + led_cdev->trigger->name);
> + return false;
> +}
> +
> +ssize_t led_trigger_may_offload_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct led_classdev *led_cdev = dev_get_drvdata(dev);
> + bool hit, offloaded = false;
> + struct led_trigger *trig;
> + int len;
> +
> + mutex_lock(&led_cdev->led_access);
> + down_read(&led_cdev->trigger_lock);
guard()?
> +
> + trig = led_cdev->trigger;
> +
> + hit = trig && !strcmp(led_cdev->hw_control_trigger, trig->name);
> + if (hit)
> + offloaded = led_trigger_get_offloaded(led_cdev);
> +
> + /* [offloaded] <active_but_not_offloaded> inactive */
> + len = sysfs_emit(buf, "%s%s%s\n",
> + offloaded ? "[" : (hit ? "<" : ""),
> + led_cdev->hw_control_trigger,
> + offloaded ? "]" : (hit ? ">" : ""));
> +
> + up_read(&led_cdev->trigger_lock);
> + mutex_unlock(&led_cdev->led_access);
> +
> + return len;
> +}
> +EXPORT_SYMBOL_GPL(led_trigger_may_offload_show);
> +
> /* LED Trigger Interface */
>
> int led_trigger_register(struct led_trigger *trig)
> diff --git a/drivers/leds/leds.h b/drivers/leds/leds.h
> index bee46651e068..9177e098989b 100644
> --- a/drivers/leds/leds.h
> +++ b/drivers/leds/leds.h
> @@ -27,6 +27,8 @@ ssize_t led_trigger_read(struct file *filp, struct kobject *kobj,
> ssize_t led_trigger_write(struct file *filp, struct kobject *kobj,
> const struct bin_attribute *bin_attr, char *buf,
> loff_t pos, size_t count);
> +ssize_t led_trigger_may_offload_show(struct device *dev,
> + struct device_attribute *attr, char *buf);
>
> extern struct rw_semaphore leds_list_lock;
> extern struct list_head leds_list;
> diff --git a/drivers/leds/trigger/ledtrig-netdev.c b/drivers/leds/trigger/ledtrig-netdev.c
> index a26109ca4b1c..21f22eea4ab8 100644
> --- a/drivers/leds/trigger/ledtrig-netdev.c
> +++ b/drivers/leds/trigger/ledtrig-netdev.c
> @@ -487,6 +487,8 @@ static ssize_t offloaded_show(struct device *dev,
> {
> struct led_netdev_data *trigger_data = led_trigger_get_drvdata(dev);
>
> + dev_warn_once(dev, "offloaded attribute has been deprecated, see trigger_may_offload.\n");
> +
> return sprintf(buf, "%d\n", trigger_data->hw_control);
> }
>
>
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH v8 0/8] mm/hmm: Add mmap lock-drop support for userfaultfd-backed mappings
From: Stanislav Kinsburskii @ 2026-07-13 20:57 UTC (permalink / raw)
To: Andrew Morton
Cc: airlied, akhilesh, corbet, dakr, david, decui, haiyangz, jgg,
kees, kys, leon, liam, lizhi.hou, ljs, longli, lyude,
maarten.lankhorst, mamin506, mhocko, mripard, nouveau, ogabbay,
oleg, rppt, shuah, simona, skhan, surenb, tzimmermann, vbabka,
wei.liu, dri-devel, linux-mm, linux-doc, linux-hyperv,
linux-kernel, linux-kselftest, linux-rdma
In-Reply-To: <20260710224950.53bcb43ce7e564f07a1f6a8c@linux-foundation.org>
On Fri, Jul 10, 2026 at 10:49:50PM -0700, Andrew Morton wrote:
> On Fri, 10 Jul 2026 20:22:33 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
>
> > On Fri, Jul 10, 2026 at 03:11:51PM -0700, Andrew Morton wrote:
> > > On Fri, 10 Jul 2026 14:26:20 -0700 Stanislav Kinsburskii <skinsburskii@gmail.com> wrote:
> > >
> > > > This series extends the HMM framework to support userfaultfd-backed memory
> > > > by allowing the mmap read lock to be dropped during hmm_range_fault().
> > >
> > > Thanks. This seems fairly mature and mostly-reviewed so I'll give it a
> > > spin in mm.git's mm-new branch.
> > >
> > > Unfortunately Sashiko wasn't able to apply this or v7. I'm not sure
> > > what base you were using. Hopefully there's a reason for a v9 so we
> > > can retry this.
> > >
> >
> > I rebased this series on top of mm-new right before sending it out.
> > Should I have used a different branch?
>
> mm-new is good - Sashiko attempts that. But it's changing rapidly at
> this point in the development cycle.
>
I’d like to send another revision addressing a few comments and also
replace the `max/max_t` check with something simpler.
Which branch should I base it on so that Sashiko can apply it
successfully?
Or would it be better to send fixups against `mm-new`?
Thanks, Stanislav
^ permalink raw reply
* RE: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device passthrough
From: Dan Williams (nvidia) @ 2026-07-13 21:14 UTC (permalink / raw)
To: Manish Honap, Alex Williamson
Cc: djbw@kernel.org, jgg@ziepe.ca, jic23@kernel.org,
dave.jiang@intel.com, Ankit Agrawal,
alejandro.lucero-palau@amd.com, alison.schofield@intel.com,
dave@stgolabs.net, dmatlack@google.com, gourry@gourry.net,
ira.weiny@intel.com, Neo Jia, Krishnakant Jaju, Vikram Sethi,
Zhi Wang, kvm@vger.kernel.org, linux-cxl@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, Manish Honap
In-Reply-To: <IA1PR12MB9030E175587B09CEA7A4D90FBDFA2@IA1PR12MB9030.namprd12.prod.outlook.com>
Manish Honap wrote:
> > -----Original Message-----
> > From: Alex Williamson <alex@shazbot.org>
> > Sent: 11 July 2026 03:53
> > To: Manish Honap <mhonap@nvidia.com>
> > Cc: djbw@kernel.org; jgg@ziepe.ca; jic23@kernel.org;
> > dave.jiang@intel.com; Ankit Agrawal <ankita@nvidia.com>;
> > alejandro.lucero-palau@amd.com; alison.schofield@intel.com;
> > dave@stgolabs.net; dmatlack@google.com; gourry@gourry.net;
> > ira.weiny@intel.com; Neo Jia <cjia@nvidia.com>; Krishnakant Jaju
> > <kjaju@nvidia.com>; Vikram Sethi <vsethi@nvidia.com>; Zhi Wang
> > <zhiw@nvidia.com>; kvm@vger.kernel.org; linux-cxl@vger.kernel.org;
> > linux-doc@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> > kselftest@vger.kernel.org; alex@shazbot.org
> > Subject: Re: [PATCH v3 05/11] vfio: UAPI for CXL Type-2 device
> > passthrough
> >
[..]
> >
> > On Thu, 25 Jun 2026 22:24:01 +0530
> > <mhonap@nvidia.com> wrote:
> > > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > > index 5de618a3a5ee..3707d53c4de5 100644
> > > --- a/include/uapi/linux/vfio.h
> > > +++ b/include/uapi/linux/vfio.h
> > > @@ -215,6 +215,7 @@ struct vfio_device_info {
> > > #define VFIO_DEVICE_FLAGS_FSL_MC (1 << 6) /* vfio-fsl-mc device */
> > > #define VFIO_DEVICE_FLAGS_CAPS (1 << 7) /* Info supports
> > caps */
> > > #define VFIO_DEVICE_FLAGS_CDX (1 << 8) /* vfio-cdx
> > device */
> > > +#define VFIO_DEVICE_FLAGS_CXL (1 << 9) /* vfio-cxl
> > Type-2 device */
> >
> > Would we define a different flag for type-1/3 if we ever found a need to
> > expose them through vfio?
>
> Yes. The current flag is named VFIO_DEVICE_FLAGS_CXL and refers to
> Type-2 specifically. If Type-1 or Type-3 support is added later, a
> separate flag (or a VFIO_DEVICE_INFO_CAP sub-type field) would
> distinguish them. I can rename it VFIO_DEVICE_FLAGS_CXL_TYPE2 now if
> that is preferable; please advise.
The CXL specification itself has deprecated the "Type" names because
they are ambiguous. For example, you can have a "Type-3" device that
supports "device memory (HDM-DB)", Type-2 is a superset of Type-1 in
many cases, etc.
This flag will never be able to capture a coherent / standard set of
device capabilities. It can really only be a plain "CXL" flag with
an implementation that is ready for the superset of capabilities:
CXL.cache, HDM-H (host-only memory expansion), HDM-D (legacy device
memory), HDM-DB (device memory via device cache management
back-invalidate).
I think the HDM-{H,D,DB} difference are not relevant to VFIO, it is all
just CXL HDM.
The capabilities that may need a different VFIO implementation model are
interleaved devices and maybe dynamic capacity devices, but that is not
a type designation.
[..]
> > Does that leave this device level capability describing the device as
> > type-2 (by existence), with only a flags field to declare HDM as
> > firmware committed, for future compatibility should we support non-fw
> > committed? Thanks,
> >
> > Alex
>
> Yes, I will shape the v4 in this direction. The device-level CAP_CXL
> shrinks to "this is a CXL device" (by existence) plus a flags field whose
> only defined bit today is HOST_FIRMWARE_COMMITTED, leaving
> room for a future non-fw-committed mode. Everything else moves to region
> caps. Thanks for this suggestion.
How can VFIO discern if the HDM is host firwmare committed? If
devm_cxl_probe_mem() grows to auto-activate unmapped capacity rather
than finds firmware committed decoders, can VFIO even tell the
difference?
^ 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