* Re: [PATCH ipsec-next v8 01/14] xfrm: remove redundant assignments
From: Sabrina Dubroca @ 2026-05-07 10:37 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-1-4578fb016965@secunet.com>
2026-05-05, 06:31:28 +0200, Antony Antony wrote:
> These assignments are overwritten within the same function further down
>
> commit e8961c50ee9cc ("xfrm: Refactor migration setup
> during the cloning process")
> x->props.family = m->new_family;
>
> Which actually moved it in the
> commit e03c3bba351f9 ("xfrm: Fix xfrm migrate issues when address family changes")
>
> And the initial
> commit 80c9abaabf428 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
>
> added x->props.saddr = orig->props.saddr; and
> memcpy(&xc->props.saddr, &m->new_saddr, sizeof(xc->props.saddr));
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
>
> ---
> v1->v2: remove extra saddr copy, previous line
> ---
> net/xfrm/xfrm_state.c | 2 --
> 1 file changed, 2 deletions(-)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
--
Sabrina
^ permalink raw reply
* Re: [PATCH ipsec-next v8 07/14] xfrm: check family before comparing addresses in migrate
From: Sabrina Dubroca @ 2026-05-07 10:35 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-7-4578fb016965@secunet.com>
2026-05-05, 06:33:18 +0200, Antony Antony wrote:
> When migrating between different address families, xfrm_addr_equal()
> cannot meaningfully compare addresses, different lengths.
> Only call xfrm_addr_equal() when families match, and take
> the xfrm_state_insert() path when addresses are equal.
>
> Fixes: 80c9abaabf42 ("[XFRM]: Extension for dynamic update of endpoint address(es)")
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
This fix doesn't simply cherry-pick on top of net, I don't know if the
stable maintainers will handle the (pretty trivial in the context of
reviewing this patch series, but maybe not for them) conflict.
I think xfrm_migrate_state_find, and probably xfrm_alloc_userspi, need
the same kind of check.
> ---
> v5->v6: added this patch
> ---
> net/xfrm/xfrm_state.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/net/xfrm/xfrm_state.c b/net/xfrm/xfrm_state.c
> index 85fd80520184..327a855253e6 100644
> --- a/net/xfrm/xfrm_state.c
> +++ b/net/xfrm/xfrm_state.c
> @@ -2159,10 +2159,11 @@ int xfrm_state_migrate_install(const struct xfrm_state *x,
> struct xfrm_user_offload *xuo,
> struct netlink_ext_ack *extack)
> {
> - if (xfrm_addr_equal(&x->id.daddr, &m->new_daddr, m->new_family)) {
> + if (m->new_family == m->old_family &&
> + xfrm_addr_equal(&x->id.daddr, &m->new_daddr, m->new_family)) {
> /*
> - * Care is needed when the destination address
> - * of the state is to be updated as it is a part of triplet.
> + * Care is needed when the destination address of the state is
> + * to be updated as it is a part of triplet.
nit: the previous patch rewords this comment, and now you're
reindenting it. it would be a bit nicer to do both in the previous
patch, and only add the family check in this patch.
> */
> xfrm_state_insert(xc);
> } else {
>
> --
> 2.47.3
>
--
Sabrina
^ permalink raw reply
* Re: [PATCH ipsec-next v8 04/14] xfrm: fix NAT-related field inheritance in SA migration
From: Sabrina Dubroca @ 2026-05-07 10:13 UTC (permalink / raw)
To: Steffen Klassert
Cc: Antony Antony, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <afxh6tZDV7RwXQ_a@secunet.com>
2026-05-07, 11:56:58 +0200, Steffen Klassert wrote:
> On Thu, May 07, 2026 at 11:33:09AM +0200, Sabrina Dubroca wrote:
> > 2026-05-05, 06:32:43 +0200, Antony Antony wrote:
> > > During SA migration via xfrm_state_clone_and_setup(),
> > > nat_keepalive_interval was silently dropped and never copied to the new
> > > SA. mapping_maxage was unconditionally copied even when migrating to a
> > > non-encapsulated SA.
> >
> > mapping_maxage should be harmless (0/unused on non-encap), but I think
> > migrating nat_keepalive_interval should be considered a fix:
> >
> > Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states")
> >
> > (maybe even split out of this series, but that would cause a conflict
> > with the previous patch)
>
> Can this be backported without the previous patches?
> If not, we might need to split it out.
git cherry-pick managed to handle the small context change, so it's
probably fine like this.
--
Sabrina
^ permalink raw reply
* Re: [PATCH ipsec-next v8 06/14] xfrm: split xfrm_state_migrate into create and install functions
From: Sabrina Dubroca @ 2026-05-07 10:11 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-6-4578fb016965@secunet.com>
2026-05-05, 06:33:07 +0200, Antony Antony wrote:
> To prepare for subsequent patches, split
> xfrm_state_migrate() into two functions:
> - xfrm_state_migrate_create(): creates the migrated state
> - xfrm_state_migrate_install(): installs it into the state table
>
> splitting will help to avoid SN/IV reuse when migrating AEAD SA.
>
> And add const whenever possible.
> No functional change.
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
(I was going to mention xuo, but I see it's handled later on)
--
Sabrina
^ permalink raw reply
* Re: [PATCH ipsec-next v8 04/14] xfrm: fix NAT-related field inheritance in SA migration
From: Steffen Klassert @ 2026-05-07 9:56 UTC (permalink / raw)
To: Sabrina Dubroca
Cc: Antony Antony, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <afxcVV83k7CxImwC@krikkit>
On Thu, May 07, 2026 at 11:33:09AM +0200, Sabrina Dubroca wrote:
> 2026-05-05, 06:32:43 +0200, Antony Antony wrote:
> > During SA migration via xfrm_state_clone_and_setup(),
> > nat_keepalive_interval was silently dropped and never copied to the new
> > SA. mapping_maxage was unconditionally copied even when migrating to a
> > non-encapsulated SA.
>
> mapping_maxage should be harmless (0/unused on non-encap), but I think
> migrating nat_keepalive_interval should be considered a fix:
>
> Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states")
>
> (maybe even split out of this series, but that would cause a conflict
> with the previous patch)
Can this be backported without the previous patches?
If not, we might need to split it out.
^ permalink raw reply
* Re: [PATCH v16 00/12] crypto/dmaengine: qce: introduce BAM locking and use DMA for register I/O
From: Manivannan Sadhasivam @ 2026-05-07 9:55 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Stephan Gerhold, Bjorn Andersson, Peter Ujfalusi, Michal Simek,
Frank Li, dmaengine, linux-doc, linux-kernel, linux-arm-msm,
linux-crypto, linux-arm-kernel, brgl, Bartosz Golaszewski,
Dmitry Baryshkov, Konrad Dybcio
In-Reply-To: <20260427-qcom-qce-cmd-descr-v16-0-945fd1cafbbc@oss.qualcomm.com>
On Mon, Apr 27, 2026 at 11:15:33AM +0200, Bartosz Golaszewski wrote:
> This missed the v7.1 cycle so let's try to get it in for v7.2.
>
> Merging strategy: there are build-time dependencies between the crypto
> and DMA patches so the best approach is for Vinod to create an immutable
> branch with the DMA part pulled in by the crypto tree.
>
> This iteration continues to build on top of v12 but uses the BAM's NWD
> bit on data descriptors as suggested by Stephan. To that end, there are
> some more changes like reversing the order of command and data
> descriptors queuedy by the QCE driver.
>
> Currently the QCE crypto driver accesses the crypto engine registers
> directly via CPU. Trust Zone may perform crypto operations simultaneously
> resulting in a race condition. To remedy that, let's introduce support
> for BAM locking/unlocking to the driver. The BAM driver will now wrap
> any existing issued descriptor chains with additional descriptors
> performing the locking when the client starts the transaction
> (dmaengine_issue_pending()). The client wanting to profit from locking
> needs to switch to performing register I/O over DMA and communicate the
> address to which to perform the dummy writes via a call to
> dmaengine_desc_attach_metadata().
>
> In the specific case of the BAM DMA this translates to sending command
> descriptors performing dummy writes with the relevant flags set. The BAM
> will then lock all other pipes not related to the current pipe group, and
> keep handling the current pipe only until it sees the the unlock bit.
>
> In order for the locking to work correctly, we also need to switch to
> using DMA for all register I/O.
>
> On top of this, the series contains some additional tweaks and
> refactoring.
>
> The goal of this is not to improve the performance but to prepare the
> driver for supporting decryption into secure buffers in the future.
>
> Tested with tcrypt.ko, kcapi and cryptsetup.
>
> Shout out to Daniel and Udit from Qualcomm for helping me out with some
> DMA issues we encountered.
>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
For the whole series,
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Thanks for incorporating all the comments, Bart!
- Mani
> ---
> Changes in v16:
> - Fix a reported race between dma_map_sg() called with spinlock taken
> and the corresponding dma_unmap_sg() called without it by moving the
> descriptor locking data into the descriptor struct
> - Also queue the TX data descriptors before the command descriptors to
> match what downstream is doing
> - Tweak commit messages
> - Rebase on top of v7.1-rc1
> - Link to v15: https://patch.msgid.link/20260402-qcom-qce-cmd-descr-v15-0-98b5361f7ed7@oss.qualcomm.com
>
> Changes in v15:
> - Extend the descriptor metadata struct to also carry the channel's
> transfer direction and stop using dmaengine_slave_config() for that
> - Link to v14: https://patch.msgid.link/20260323-qcom-qce-cmd-descr-v14-0-f323af411274@oss.qualcomm.com
>
> Changes in v14:
> - Don't return an error to a client which wants to use locking on BAM
> that doesn't support it
> - Add a comment describing the DMA descriptor metadata structure
> - Fix memory leaks
> - Remove leftovers from previous iterations
> - Propagate errors from dma_cookie_assign() when setting up lock
> descriptors
> - Link to v13: https://patch.msgid.link/20260317-qcom-qce-cmd-descr-v13-0-0968eb4f8c40@oss.qualcomm.com
>
> Changes in v13:
> - As part of the DMA changes in the QCE driver: reverse the order of
> queueing the descriptors in the QCE driver: queue command descriptors
> with all the register writes first, followed by all the data descriptors,
> this is in line with the recommandations from the BAM HPG
> - Set the NWD (notify-when-done) bit (DMA_PREP_FENCE in dmaengine
> parlance) on the data descriptors to ensure that the UNLOCK descriptor
> will not be processed until after they have been processed by the
> engine. While technically the NWD bit is only needed on the final data
> descriptor, it's hard to tell which one *will* be the last from the
> driver's point-of-view and both the downstream driver as well as
> the Qualcomm TZ against which we want to synchronize sets NWD on every
> data descriptor,
> - Revert to creating the LOCK/UNLOCK command descriptor pair in one
> place now that the NWD bit is in place,
> - Link to v12: https://patch.msgid.link/20260310-qcom-qce-cmd-descr-v12-0-398f37f26ef0@oss.qualcomm.com
>
> Changes in v12:
> - Wait until the transaction is done before queueing the UNLOCK command
> descriptor
> - Use descriptor metadata for communicating the scratchpad address to
> the BAM driver
> - To that end: reverse the order of the series (first BAM, then QCE) to
> maintain bisectability
> - Unmap buffers used for dummy writes after the transaction
> - Link to v11: https://patch.msgid.link/20260302-qcom-qce-cmd-descr-v11-0-4bf1f5db4802@oss.qualcomm.com
>
> Changes in v11:
> - Use new approach, not requiring the client to be involved in locking.
> - Add a patch constifying dma_descriptor_metadata_ops
> - Rebase on top of v7.0-rc1
> - Link to v10: https://lore.kernel.org/r/20251219-qcom-qce-cmd-descr-v10-0-ff7e4bf7dad4@oss.qualcomm.com
>
> Changes in v10:
> - Move DESC_FLAG_(UN)LOCK BIT definitions from patch 2 to 3
> - Add a patch constifying the dma engine metadata as the first in the
> series
> - Use the VERSION register for dummy lock/unlock writes
> - Link to v9: https://lore.kernel.org/r/20251128-qcom-qce-cmd-descr-v9-0-9a5f72b89722@linaro.org
>
> Changes in v9:
> - Drop the global, generic LOCK/UNLOCK flags and instead use DMA
> descriptor metadata ops to pass BAM-specific information from the QCE
> to the DMA engine
> - Link to v8: https://lore.kernel.org/r/20251106-qcom-qce-cmd-descr-v8-0-ecddca23ca26@linaro.org
>
> Changes in v8:
> - Rework the command descriptor logic and drop a lot of unneeded code
> - Use the physical address for BAM command descriptor access, not the
> mapped DMA address
> - Fix the problems with iommu faults on newer platforms
> - Generalize the LOCK/UNLOCK flags in dmaengine and reword the docs and
> commit messages
> - Make the BAM locking logic stricter in the DMA engine driver
> - Add some additional minor QCE driver refactoring changes to the series
> - Lots of small reworks and tweaks to rebase on current mainline and fix
> previous issues
> - Link to v7: https://lore.kernel.org/all/20250311-qce-cmd-descr-v7-0-db613f5d9c9f@linaro.org/
>
> Changes in v7:
> - remove unused code: writing to multiple registers was not used in v6,
> neither were the functions for reading registers over BAM DMA-
> - remove
> - don't read the SW_VERSION register needlessly in the BAM driver,
> instead: encode the information on whether the IP supports BAM locking
> in device match data
> - shrink code where possible with logic modifications (for instance:
> change the implementation of qce_write() instead of replacing it
> everywhere with a new symbol)
> - remove duplicated error messages
> - rework commit messages
> - a lot of shuffling code around for easier review and a more
> streamlined series
> - Link to v6: https://lore.kernel.org/all/20250115103004.3350561-1-quic_mdalam@quicinc.com/
>
> Changes in v6:
> - change "BAM" to "DMA"
> - Ensured this series is compilable with the current Linux-next tip of
> the tree (TOT).
>
> Changes in v5:
> - Added DMA_PREP_LOCK and DMA_PREP_UNLOCK flag support in separate patch
> - Removed DMA_PREP_LOCK & DMA_PREP_UNLOCK flag
> - Added FIELD_GET and GENMASK macro to extract major and minor version
>
> Changes in v4:
> - Added feature description and test hardware
> with test command
> - Fixed patch version numbering
> - Dropped dt-binding patch
> - Dropped device tree changes
> - Added BAM_SW_VERSION register read
> - Handled the error path for the api dma_map_resource()
> in probe
> - updated the commit messages for batter redability
> - Squash the change where qce_bam_acquire_lock() and
> qce_bam_release_lock() api got introduce to the change where
> the lock/unlock flag get introced
> - changed cover letter subject heading to
> "dmaengine: qcom: bam_dma: add cmd descriptor support"
> - Added the very initial post for BAM lock/unlock patch link
> as v1 to track this feature
>
> Changes in v3:
> - https://lore.kernel.org/lkml/183d4f5e-e00a-8ef6-a589-f5704bc83d4a@quicinc.com/
> - Addressed all the comments from v2
> - Added the dt-binding
> - Fix alignment issue
> - Removed type casting from qce_write_reg_dma()
> and qce_read_reg_dma()
> - Removed qce_bam_txn = dma->qce_bam_txn; line from
> qce_alloc_bam_txn() api and directly returning
> dma->qce_bam_txn
>
> Changes in v2:
> - https://lore.kernel.org/lkml/20231214114239.2635325-1-quic_mdalam@quicinc.com/
> - Initial set of patches for cmd descriptor support
> - Add client driver to use BAM lock/unlock feature
> - Added register read/write via BAM in QCE Crypto driver
> to use BAM lock/unlock feature
>
> ---
> Bartosz Golaszewski (12):
> dmaengine: constify struct dma_descriptor_metadata_ops
> dmaengine: qcom: bam_dma: convert tasklet to a BH workqueue
> dmaengine: qcom: bam_dma: Extend the driver's device match data
> dmaengine: qcom: bam_dma: Add pipe_lock_supported flag support
> dmaengine: qcom: bam_dma: add support for BAM locking
> crypto: qce - Include algapi.h in the core.h header
> crypto: qce - Remove unused ignore_buf
> crypto: qce - Simplify arguments of devm_qce_dma_request()
> crypto: qce - Use existing devres APIs in devm_qce_dma_request()
> crypto: qce - Map crypto memory for DMA
> crypto: qce - Add BAM DMA support for crypto register I/O
> crypto: qce - Communicate the base physical address to the dmaengine
>
> drivers/crypto/qce/aead.c | 8 +-
> drivers/crypto/qce/common.c | 20 ++--
> drivers/crypto/qce/core.c | 28 ++++-
> drivers/crypto/qce/core.h | 11 ++
> drivers/crypto/qce/dma.c | 163 +++++++++++++++++++++++------
> drivers/crypto/qce/dma.h | 11 +-
> drivers/crypto/qce/sha.c | 8 +-
> drivers/crypto/qce/skcipher.c | 8 +-
> drivers/dma/qcom/bam_dma.c | 217 ++++++++++++++++++++++++++++++++++-----
> drivers/dma/ti/k3-udma.c | 2 +-
> drivers/dma/xilinx/xilinx_dma.c | 2 +-
> include/linux/dma/qcom_bam_dma.h | 14 +++
> include/linux/dmaengine.h | 2 +-
> 13 files changed, 404 insertions(+), 90 deletions(-)
> ---
> base-commit: 06ae5ec2a5f35da6b24d404d16310ee3553dba6f
> change-id: 20251103-qcom-qce-cmd-descr-c5e9b11fe609
>
> Best regards,
> --
> Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
>
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply
* [PATCH v3 2/2] cred: delete task_euid()
From: Alice Ryhl @ 2026-05-07 9:48 UTC (permalink / raw)
To: Paul Moore, Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman,
Shuah Khan, Alex Shi, Yanteng Si, Dongliang Mu
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Jann Horn, linux-security-module, linux-doc, linux-kernel,
rust-for-linux, Alice Ryhl
In-Reply-To: <20260507-remove-task-euid-v3-0-27f22f335c2c@google.com>
task_euid() is a very weird operation. You can see how weird it is by
grepping for task_euid() - binder is its only user. task_euid() obtains
the objective effective UID - it looks at the credentials of the task
for purposes of acting on it as an object, but then accesses the
effective UID (which the credentials.7 man page describes as "[...] used
by the kernel to determine the permissions that the process will have
when accessing shared resources [...]").
Since usage in Binder has now been removed, get rid of the resulting
dead code.
Changes to the zh_CN translation was carried out with the help of
Gemini and Google Translate, and since adjusted as per Alex Shi's
feedback.
Suggested-by: Jann Horn <jannh@google.com>
Reviewed-by: Gary Guo <gary@garyguo.net>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Documentation/security/credentials.rst | 6 ++----
Documentation/translations/zh_CN/security/credentials.rst | 4 +---
include/linux/cred.h | 1 -
rust/helpers/task.c | 5 -----
rust/kernel/task.rs | 10 ----------
5 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/Documentation/security/credentials.rst b/Documentation/security/credentials.rst
index d0191c8b8060..81d3b5737d85 100644
--- a/Documentation/security/credentials.rst
+++ b/Documentation/security/credentials.rst
@@ -393,16 +393,14 @@ the credentials so obtained when they're finished with.
The result of ``__task_cred()`` should not be passed directly to
``get_cred()`` as this may race with ``commit_cred()``.
-There are a couple of convenience functions to access bits of another task's
-credentials, hiding the RCU magic from the caller::
+There is a convenience function to access bits of another task's credentials,
+hiding the RCU magic from the caller::
uid_t task_uid(task) Task's real UID
- uid_t task_euid(task) Task's effective UID
If the caller is holding the RCU read lock at the time anyway, then::
__task_cred(task)->uid
- __task_cred(task)->euid
should be used instead. Similarly, if multiple aspects of a task's credentials
need to be accessed, RCU read lock should be used, ``__task_cred()`` called,
diff --git a/Documentation/translations/zh_CN/security/credentials.rst b/Documentation/translations/zh_CN/security/credentials.rst
index 88fcd9152ffe..20c8696f8198 100644
--- a/Documentation/translations/zh_CN/security/credentials.rst
+++ b/Documentation/translations/zh_CN/security/credentials.rst
@@ -337,15 +337,13 @@ const指针上操作，因此不需要进行类型转换，但需要临时放弃
``__task_cred()`` 的结果不应直接传递给 ``get_cred()`` ，
因为这可能与 ``commit_cred()`` 发生竞争条件。
-还有一些方便的函数可以访问另一个任务凭据的特定部分，将RCU操作对调用方隐藏起来::
+有一个方便的函数可用于访问另一个任务凭据的特定部分，从而对调用方隐藏RCU机制::
uid_t task_uid(task) Task's real UID
- uid_t task_euid(task) Task's effective UID
如果调用方在此时已经持有RCU读锁，则应使用::
__task_cred(task)->uid
- __task_cred(task)->euid
类似地，如果需要访问任务凭据的多个方面，应使用RCU读锁，调用 ``__task_cred()``
函数，将结果存储在临时指针中，然后从临时指针中调用凭据的各个方面，最后释放锁。
diff --git a/include/linux/cred.h b/include/linux/cred.h
index c6676265a985..6ef1750c93e2 100644
--- a/include/linux/cred.h
+++ b/include/linux/cred.h
@@ -371,7 +371,6 @@ DEFINE_FREE(put_cred, struct cred *, if (!IS_ERR_OR_NULL(_T)) put_cred(_T))
})
#define task_uid(task) (task_cred_xxx((task), uid))
-#define task_euid(task) (task_cred_xxx((task), euid))
#define task_ucounts(task) (task_cred_xxx((task), ucounts))
#define current_cred_xxx(xxx) \
diff --git a/rust/helpers/task.c b/rust/helpers/task.c
index c0e1a06ede78..b46b1433a67e 100644
--- a/rust/helpers/task.c
+++ b/rust/helpers/task.c
@@ -28,11 +28,6 @@ __rust_helper kuid_t rust_helper_task_uid(struct task_struct *task)
return task_uid(task);
}
-__rust_helper kuid_t rust_helper_task_euid(struct task_struct *task)
-{
- return task_euid(task);
-}
-
#ifndef CONFIG_USER_NS
__rust_helper uid_t rust_helper_from_kuid(struct user_namespace *to, kuid_t uid)
{
diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
index 7950c3a3950d..e568dfab93c4 100644
--- a/rust/kernel/task.rs
+++ b/rust/kernel/task.rs
@@ -217,16 +217,6 @@ pub fn uid(&self) -> Kuid {
Kuid::from_raw(unsafe { bindings::task_uid(self.as_ptr()) })
}
- /// Returns the objective effective UID of the given task.
- ///
- /// You should probably not be using this; the effective UID is normally
- /// only relevant in subjective credentials.
- #[inline]
- pub fn euid(&self) -> Kuid {
- // SAFETY: It's always safe to call `task_euid` on a valid task.
- Kuid::from_raw(unsafe { bindings::task_euid(self.as_ptr()) })
- }
-
/// Determines whether the given task has pending signals.
#[inline]
pub fn signal_pending(&self) -> bool {
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v3 1/2] rust: task: clarify comments on task UID accessors
From: Alice Ryhl @ 2026-05-07 9:48 UTC (permalink / raw)
To: Paul Moore, Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman,
Shuah Khan, Alex Shi, Yanteng Si, Dongliang Mu
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Jann Horn, linux-security-module, linux-doc, linux-kernel,
rust-for-linux, Alice Ryhl
In-Reply-To: <20260507-remove-task-euid-v3-0-27f22f335c2c@google.com>
From: Jann Horn <jannh@google.com>
Linux has separate subjective and objective task credentials, see the
comment above `struct cred`. Clarify which accessor functions operate on
which set of credentials.
Also document that Task::euid() is a very weird operation. You can see how
weird it is by grepping for task_euid() - binder is its only user.
Task::euid() obtains the objective effective UID - it looks at the
credentials of the task for purposes of acting on it as an object, but then
accesses the effective UID (which the credentials.7 man page describes as
"[...] used by the kernel to determine the permissions that the process
will have when accessing shared resources [...]").
For context:
Arguably, binder's use of task_euid() is a theoretical security problem,
which only has no impact on Android because Android has no setuid binaries
executable by apps.
commit 29bc22ac5e5b ("binder: use euid from cred instead of using task")
fixed that by removing that only user of task_euid(), but the fix got
reverted in commit c21a80ca0684 ("binder: fix test regression due to
sender_euid change") because some Android test started failing.
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Originally sent as:
https://lore.kernel.org/r/20260212-rust-uid-v1-1-deff4214c766@google.com
---
rust/kernel/task.rs | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/rust/kernel/task.rs b/rust/kernel/task.rs
index 38273f4eedb5..7950c3a3950d 100644
--- a/rust/kernel/task.rs
+++ b/rust/kernel/task.rs
@@ -210,14 +210,17 @@ pub fn pid(&self) -> Pid {
unsafe { *ptr::addr_of!((*self.as_ptr()).pid) }
}
- /// Returns the UID of the given task.
+ /// Returns the objective real UID of the given task.
#[inline]
pub fn uid(&self) -> Kuid {
// SAFETY: It's always safe to call `task_uid` on a valid task.
Kuid::from_raw(unsafe { bindings::task_uid(self.as_ptr()) })
}
- /// Returns the effective UID of the given task.
+ /// Returns the objective effective UID of the given task.
+ ///
+ /// You should probably not be using this; the effective UID is normally
+ /// only relevant in subjective credentials.
#[inline]
pub fn euid(&self) -> Kuid {
// SAFETY: It's always safe to call `task_euid` on a valid task.
@@ -371,7 +374,7 @@ fn eq(&self, other: &Self) -> bool {
impl Eq for Task {}
impl Kuid {
- /// Get the current euid.
+ /// Get the current subjective euid.
#[inline]
pub fn current_euid() -> Kuid {
// SAFETY: Just an FFI call.
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v3 0/2] Delete task_euid()
From: Alice Ryhl @ 2026-05-07 9:48 UTC (permalink / raw)
To: Paul Moore, Serge Hallyn, Jonathan Corbet, Greg Kroah-Hartman,
Shuah Khan, Alex Shi, Yanteng Si, Dongliang Mu
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Trevor Gross, Danilo Krummrich,
Jann Horn, linux-security-module, linux-doc, linux-kernel,
rust-for-linux, Alice Ryhl
The task_euid() method is a very weird method, and Binder was the only
user. As of commit 65b672152289 ("binder: use current_euid() for
transaction sender identity") Binder doesn't use task_euid() anymore,
so we can delete this method.
My suggestion would be to merge this through the LSM tree.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
---
Changes in v3:
- Include 'task' clarification commit in series.
- Rebase and resend.
- Link to v2: https://lore.kernel.org/r/20260227-remove-task-euid-v2-1-9a9c80a82eb6@google.com
Changes in v2:
- Update translation as per Alex Shi.
- Pick up Reviewed-by Gary.
- Update commit title to use cred: prefix.
- Link to v1: https://lore.kernel.org/r/20260219-remove-task-euid-v1-1-904060826e07@google.com
---
Alice Ryhl (1):
cred: delete task_euid()
Jann Horn (1):
rust: task: clarify comments on task UID accessors
Documentation/security/credentials.rst | 6 ++----
Documentation/translations/zh_CN/security/credentials.rst | 4 +---
include/linux/cred.h | 1 -
rust/helpers/task.c | 5 -----
rust/kernel/task.rs | 11 ++---------
5 files changed, 5 insertions(+), 22 deletions(-)
---
base-commit: 7fd2df204f342fc17d1a0bfcd474b24232fb0f32
change-id: 20260219-remove-task-euid-19e4b00beebe
Best regards,
--
Alice Ryhl <aliceryhl@google.com>
^ permalink raw reply
* Re: [PATCH 05/11] of: reserved_mem: add linux,no-dump property support for reserved memory regions
From: Wandun @ 2026-05-07 9:41 UTC (permalink / raw)
To: Rob Herring
Cc: kexec, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linux-riscv, devicetree, akpm, bhe, rppt, pasha.tatashin,
pratyush, ruirui.yang, corbet, skhan, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, saravanak, chenwandun,
zhaomeijing, everyzhao
In-Reply-To: <20260506144542.GA2072596-robh@kernel.org>
On 5/6/26 22:45, Rob Herring wrote:
> On Wed, Apr 29, 2026 at 02:58:25PM +0800, Chen Wandun wrote:
>> Add a 'no_dump' field to struct reserved_mem and parse the
>> 'linux,no-dump' device tree property during reserved memory node
>> initialization. This property allows device tree authors to mark
>> specific reserved memory regions that should be excluded from kdump
>> vmcore dumps.
>>
>> Reserved memory regions used by device firmware (e.g., GPU, DSP, modem)
>> typically contain data that is not useful for kernel crash analysis and
>> can significantly increase vmcore size. The 'linux,no-dump' property
>> provides a declarative way to indicate these regions should be filtered
>> out when constructing the elfcorehdr for kdump.
>>
>> The property is named with a 'linux,' prefix because kdump/vmcore is
>> Linux-specific and the property is an OS hint rather than a hardware
>> description, matching existing properties such as 'linux,cma-default'
>> and 'linux,usable-memory-range'.
>>
>> The 'linux,no-dump' property is only effective when the region:
>> - Does not have 'no-map': these regions are already excluded from
>> vmcore since they are removed from the linear mapping (MEMBLOCK_NOMAP).
>> - Does not have 'reusable': CMA reusable regions are actively used by
>> the kernel for movable page allocations, and their contents are
>> valuable for crash analysis.
>>
>> The no-dump status is also printed in the boot log alongside the
>> existing nomap and reusable flags for diagnostic purposes.
> I think this property is the wrong way around and probably not needed.
> The default should be exclude the regions, but if Linux is using the
> regions (like CMA) then it can decide on its own to include them.
>
> With the restructuring that went into 7.1, it should be possible for the
> CMA code (and code for any other regions) to set some flag for the
> region.
Agree that the property direction is wrong. Rework in v2:
- Default: exclude reserved regions from vmcore
- CMA (reusable) setup path marks regions as kernel-managed general
memory → include
- No DT binding needed; linux,no-dump proposal withdrawn
Thanks.
>
> Rob
^ permalink raw reply
* Re: [PATCH 02/11] of: reserved_mem: reject reserved memory outside physical address range
From: Wandun @ 2026-05-07 9:35 UTC (permalink / raw)
To: Rob Herring
Cc: kexec, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linux-riscv, devicetree, akpm, bhe, rppt, pasha.tatashin,
pratyush, ruirui.yang, corbet, skhan, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, saravanak, chenwandun,
zhaomeijing, everyzhao
In-Reply-To: <20260506015112.GA286568-robh@kernel.org>
On 5/6/26 09:51, Rob Herring wrote:
> On Wed, Apr 29, 2026 at 02:58:22PM +0800, Chen Wandun wrote:
>> early_init_dt_reserve_memory() does not validate whether the region
>> falls within physical memory. If a device tree incorrectly specifies a
>> reserved memory region outside the physical address range:
>>
>> - For the non-nomap path, memblock_reserve() blindly adds the region
>> to memblock.reserved, creating a stale entry that refers to
>> non-existent memory.
>>
>> - For the nomap path, memblock_mark_nomap() silently fails to match
>> any region in memblock.memory, but still returns success.
>>
>> Add a memblock_overlaps_region() check at the entry of
>> early_init_dt_reserve_memory() to reject such regions before any
>> memblock operation takes place. This also simplifies the existing nomap
>> guard: the original "overlaps && is_reserved" condition reduces to just
>> "is_reserved", since the overlap with physical memory is already
>> guaranteed by the new check.
> While I agree, I suspect we already have cases abusing reserved-memory
> like this.
Sashiko reviewed this patch and told me:
"Historically, the reserved-memory binding is often used to describe
hardware
SRAM, DSP memory, or IOMEM carveouts that reside outside of system RAM."
IIUC, nowdays using mmio-sram DT binding is more appropriate for SRAM or
IOMEM carveouts.
Should I drop this patch or keep it ?
Thanks.
>
>> Signed-off-by: Chen Wandun <chenwandun@lixiang.com>
>> Tested-by: Zhao Meijing <zhaomeijing@lixiang.com>
>> ---
>> drivers/of/of_reserved_mem.c | 15 +++++++++++----
>> 1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>> index 9d1b0193864c..03c676052dab 100644
>> --- a/drivers/of/of_reserved_mem.c
>> +++ b/drivers/of/of_reserved_mem.c
>> @@ -112,14 +112,21 @@ static int fdt_fixup_reserved_mem_node(unsigned long node,
>> static int __init early_init_dt_reserve_memory(phys_addr_t base,
>> phys_addr_t size, bool nomap)
>> {
>> + if (!memblock_overlaps_region(&memblock.memory, base, size)) {
>> + phys_addr_t end = base + size - 1;
>> +
>> + pr_warn("Reserved memory region %pa..%pa is outside of physical memory\n",
>> + &base, &end);
>> + return -EINVAL;
>> + }
>> +
>> if (nomap) {
>> /*
>> * If the memory is already reserved (by another region), we
>> - * should not allow it to be marked nomap, but don't worry
>> - * if the region isn't memory as it won't be mapped.
>> + * should not allow it to be marked nomap. The region being
>> + * physical memory is guaranteed by the overlap check above.
>> */
>> - if (memblock_overlaps_region(&memblock.memory, base, size) &&
>> - memblock_is_region_reserved(base, size))
>> + if (memblock_is_region_reserved(base, size))
>> return -EBUSY;
>>
>> return memblock_mark_nomap(base, size);
>> --
>> 2.43.0
>>
^ permalink raw reply
* Re: [PATCH ipsec-next v8 04/14] xfrm: fix NAT-related field inheritance in SA migration
From: Sabrina Dubroca @ 2026-05-07 9:33 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-4-4578fb016965@secunet.com>
2026-05-05, 06:32:43 +0200, Antony Antony wrote:
> During SA migration via xfrm_state_clone_and_setup(),
> nat_keepalive_interval was silently dropped and never copied to the new
> SA. mapping_maxage was unconditionally copied even when migrating to a
> non-encapsulated SA.
mapping_maxage should be harmless (0/unused on non-encap), but I think
migrating nat_keepalive_interval should be considered a fix:
Fixes: f531d13bdfe3 ("xfrm: support sending NAT keepalives in ESP in UDP states")
(maybe even split out of this series, but that would cause a conflict
with the previous patch)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
--
Sabrina
^ permalink raw reply
* Re: [PATCH v3 1/2] usb: xhci-pci: add generic auxiliary device interface
From: Mathias Nyman @ 2026-05-07 9:31 UTC (permalink / raw)
To: Jihong Min, Greg Kroah-Hartman, Mathias Nyman
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan, Mario Limonciello,
Basavaraj Natikar, linux-usb, linux-hwmon, linux-doc, linux-pci,
linux-kernel
In-Reply-To: <effa7bd7bef8a8ea28b9e28fe47af6a58e39edf2.1778123510.git.hurryman2212@gmail.com>
On 5/7/26 06:31, Jihong Min wrote:
> Some xHCI PCI controllers expose controller-specific functionality that is
> not part of generic xHCI operation and is better handled by optional child
> drivers in other subsystems. Add a small auxiliary device registration path
> for selected xHCI PCI controllers.
>
> The initial PCI ID match table lists AMD Promontory 21 (PROM21) 1022:43fd
> controllers. For matching controllers, xhci-pci creates an auxiliary
> device and stores it in devres so the remove path destroys it before HCD
> teardown.
>
> Subsystem-specific child drivers can then bind to those devices through
> the auxiliary bus and keep their hardware-specific logic outside xhci-pci.
>
> Assisted-by: Codex:gpt-5.5
> Signed-off-by: Jihong Min <hurryman2212@gmail.com>
> ---
> drivers/usb/host/Kconfig | 10 +++++
> drivers/usb/host/xhci-pci.c | 83 +++++++++++++++++++++++++++++++++++++
> 2 files changed, 93 insertions(+)
>
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index 0a277a07cf70..e0c2c7ac5c97 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -42,6 +42,16 @@ config USB_XHCI_PCI
> depends on USB_PCI
> default y
>
> +config USB_XHCI_PCI_AUXDEV
> + bool "xHCI PCI auxiliary device support"
> + depends on USB_XHCI_PCI
> + select AUXILIARY_BUS
> + help
> + This enables xHCI PCI support for registering auxiliary devices
> + for selected controllers. It is used by optional child drivers
> + that bind to xHCI PCI controller-specific functionality through
> + the auxiliary bus.
> +
> config USB_XHCI_PCI_RENESAS
> tristate "Support for additional Renesas xHCI controller with firmware"
> depends on USB_XHCI_PCI
> diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
> index 585b2f3117b0..618d6840e108 100644
> --- a/drivers/usb/host/xhci-pci.c
> +++ b/drivers/usb/host/xhci-pci.c
> @@ -8,6 +8,8 @@
> * Some code borrowed from the Linux EHCI driver.
> */
>
> +#include <linux/auxiliary_bus.h>
> +#include <linux/device/devres.h>
> #include <linux/pci.h>
> #include <linux/slab.h>
> #include <linux/module.h>
> @@ -80,6 +82,7 @@
> #define PCI_DEVICE_ID_AMD_RAVEN_15E1_XHCI 0x15e1
> #define PCI_DEVICE_ID_AMD_RAVEN2_XHCI 0x15e5
> #define PCI_DEVICE_ID_AMD_RENOIR_XHCI 0x1639
> +#define PCI_DEVICE_ID_AMD_PROM21_XHCI 0x43fd
> #define PCI_DEVICE_ID_AMD_PROMONTORYA_4 0x43b9
> #define PCI_DEVICE_ID_AMD_PROMONTORYA_3 0x43ba
> #define PCI_DEVICE_ID_AMD_PROMONTORYA_2 0x43bb
> @@ -103,6 +106,80 @@ static int xhci_pci_run(struct usb_hcd *hcd);
> static int xhci_pci_update_hub_device(struct usb_hcd *hcd, struct usb_device *hdev,
> struct usb_tt *tt, gfp_t mem_flags);
>
> +static const struct pci_device_id pci_ids_have_aux[] = {
> + { PCI_DEVICE_DATA(AMD, PROM21_XHCI, "prom21_hwmon") },
> + { /* end: all zeroes */ }
> +};
> +
> +struct xhci_pci_aux_devres {
> + struct auxiliary_device *auxdev;
> +};
> +
> +static const char *xhci_pci_aux_dev_name(struct pci_dev *pdev)
> +{
> + const struct pci_device_id *id;
> +
> + id = pci_match_id(pci_ids_have_aux, pdev);
> + if (!id)
> + return NULL;
> +
> + return (const char *)id->driver_data;
> +}
> +
> +static void xhci_pci_aux_devres_release(struct device *dev, void *res)
> +{
> + struct xhci_pci_aux_devres *devres = res;
> +
> + if (devres->auxdev)
> + auxiliary_device_destroy(devres->auxdev);
> +}
> +
> +static void xhci_pci_try_add_aux_device(struct pci_dev *pdev)
> +{
> + struct xhci_pci_aux_devres *devres;
> + struct auxiliary_device *auxdev;
> + const char *aux_dev_name;
> +
> + aux_dev_name = xhci_pci_aux_dev_name(pdev);
> + if (!aux_dev_name)
> + return;
> +
> + devres = devres_alloc(xhci_pci_aux_devres_release, sizeof(*devres),
> + GFP_KERNEL);
> + if (!devres) {
> + dev_warn(&pdev->dev,
> + "failed to allocate auxiliary device state\n");
> + return;
> + }
> +
> + auxdev = auxiliary_device_create(&pdev->dev, KBUILD_MODNAME,
> + aux_dev_name, NULL,
> + (pci_domain_nr(pdev->bus) << 16) |
> + pci_dev_id(pdev));
> + if (!auxdev) {
> + devres_free(devres);
> + dev_warn(&pdev->dev, "failed to add %s auxiliary device\n",
> + aux_dev_name);
> + return;
> + }
> +
> + devres->auxdev = auxdev;
> + devres_add(&pdev->dev, devres);
> +}
> +
> +static void xhci_pci_try_remove_aux_device(struct pci_dev *pdev)
> +{
> + struct xhci_pci_aux_devres *devres;
> +
> + devres = devres_find(&pdev->dev, xhci_pci_aux_devres_release, NULL,
> + NULL);
> + if (!devres || !devres->auxdev)
> + return;
> +
> + auxiliary_device_destroy(devres->auxdev);
> + devres->auxdev = NULL;
> +}
> +
> static const struct xhci_driver_overrides xhci_pci_overrides __initconst = {
> .reset = xhci_pci_setup,
> .start = xhci_pci_run,
> @@ -677,6 +754,9 @@ int xhci_pci_common_probe(struct pci_dev *dev, const struct pci_device_id *id)
> if (device_property_read_bool(&dev->dev, "ti,pwron-active-high"))
> pci_clear_and_set_config_dword(dev, 0xE0, 0, 1 << 22);
>
> + if (IS_ENABLED(CONFIG_USB_XHCI_PCI_AUXDEV))
> + xhci_pci_try_add_aux_device(dev);
> +
> return 0;
I think this should be turned around so that the vendor specific code calls the common code.
xhci-pci-renesas.c does this nicely.
In your case it would be adding something like a xhci-pci-prom21.c pci driver:
xhci_pci_prom21_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
crate_auxiliary_device(dev);
return xhci_pci_common_probe(dev, id);
}
xhci_pci_prom21_remove(struct pci_dev *dev)
{
destroy_auxiliary_device(dev);
xhci_pci_remove(dev);
}
static const struct pci_device_id pci_ids[] = {
{ PCI_DEVICE(YOUR_AMD_PCI_VENDOR_ID, YOUR_PROM21_DEVICE_ID) },
{ /* end: all zeroes */ }
};
MODULE_DEVICE_TABLE(pci, pci_ids);
static struct pci_driver xhci_prom21_pci_driver = {
.name = "xhci-pci-prom21",
.id_table = pci_ids,
.probe = xhci_pci_prom21_probe,
.remove = xhci_pci_prom21_remove,
.shutdown = usb_hcd_pci_shutdown,
.driver = {
.pm = pm_ptr(&usb_hcd_pci_pm_ops),
},
};
module_pci_driver(xhci_prom21_pci_driver);
MODULE_DESCRIPTION("AMD Promontory 21 xHCI PCI Host Controller Driver");
MODULE_IMPORT_NS("xhci");
MODULE_LICENSE("GPL v2");
-Mathias
^ permalink raw reply
* Re: [PATCH ipsec-next v8 03/14] xfrm: allow migration from UDP encapsulated to non-encapsulated ESP
From: Sabrina Dubroca @ 2026-05-07 9:26 UTC (permalink / raw)
To: Antony Antony
Cc: Steffen Klassert, Herbert Xu, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
Masahide NAKAMURA, Paul Moore, Stephen Smalley, Ondrej Mosnacek,
Jonathan Corbet, Shuah Khan, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-3-4578fb016965@secunet.com>
2026-05-05, 06:32:30 +0200, Antony Antony wrote:
> The current code prevents migrating an SA from UDP encapsulation to
> plain ESP. This is needed when moving from a NATed path to a non-NATed
> one, for example when switching from IPv4+NAT to IPv6.
>
> Only copy the existing encapsulation during migration if the encap
> attribute is explicitly provided.
>
> Note: PF_KEY's SADB_X_MIGRATE always passes encap=NULL and never
> supported encapsulation in migration. PF_KEY is deprecated and was
> in feature freeze when UDP encapsulation was added to xfrm.
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
> Tested-by: Yan Yan <evitayan@google.com>
> ---
> net/xfrm/xfrm_state.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
If someone complains about this we can add a sysctl
"preserve_old_encap_on_migrate".
--
Sabrina
^ permalink raw reply
* RE: [PATCH v9 2/6] iio: adc: ad4691: add initial driver for AD4691 family
From: Sabau, Radu bogdan @ 2026-05-07 9:26 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Liam Girdwood, Mark Brown, Linus Walleij,
Bartosz Golaszewski, Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <20260430-ad4692-multichannel-sar-adc-driver-v9-2-33e439e4fb87@analog.com>
Addressing Sashiko's review for initial driver's patch.
> -----Original Message-----
> From: Radu Sabau via B4 Relay <devnull+radu.sabau.analog.com@kernel.org>
> Sent: Thursday, April 30, 2026 1:17 PM
...
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 60038ae8dfc4..3685a03aa8dc 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -139,6 +139,17 @@ config AD4170_4
> To compile this driver as a module, choose M here: the module will be
> called ad4170-4.
>
> +config AD4691
> + tristate "Analog Devices AD4691 Family ADC Driver"
> + depends on SPI
"Should this driver also depend on REGULATOR? In ad4691_regulator_setup(),
it relies on devm_regulator_get_enable_read_voltage() to obtain its reference
voltage. If the kernel is compiled without CONFIG_REGULATOR, this function
is stubbed to return -ENODEV, causing probe to fail unconditionally."
Will add "depends on REGULATOR". Without it,
devm_regulator_get_enable_read_voltage() can be stubbed and
return -ENODEV, making the driver unusable regardless of hardware.
> + select REGMAP
> + help
> + Say yes here to build support for Analog Devices AD4691 Family
...
> +};
> +
> +#define AD4691_CHANNEL(ch)
> \
> + { \
> + .type = IIO_VOLTAGE, \
> + .indexed = 1, \
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW)
> \
> + | BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .info_mask_separate_available =
> \
> + BIT(IIO_CHAN_INFO_SAMP_FREQ), \
> + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> \
"Since ad4691_set_sampling_freq() modifies the AD4691_OSC_FREQ_REG register
which controls the global internal oscillator frequency for the entire ADC,
should IIO_CHAN_INFO_SAMP_FREQ be exposed as info_mask_shared_by_all
instead of info_mask_separate? Changing the frequency for one channel
currently seems to silently alter it for all channels."
Agreed for this commit. With no per-channel OSR in the base driver
all channels share a single oscillator register, so info_mask_shared_by_all
is the correct annotation. Changing accordingly. The OSR commit switches it
back to info_mask_separate because at that point the effective rate is
genuinely per-channel (osc_freq / osr[N]).
> + .channel = ch, \
> + .scan_index = ch, \
> + .scan_type = { \
> + .sign = 'u', \
> + .realbits = 16, \
> + .storagebits = 16, \
> + }, \
> + }
> +
...
> +};
> +
> +static int ad4691_reg_read(void *context, unsigned int reg, unsigned int
> *val)
> +{
> + struct spi_device *spi = context;
> + u8 tx[2], rx[4];
> + int ret;
> +
> + /* Set bit 15 to mark the operation as READ. */
> + put_unaligned_be16(0x8000 | reg, tx);
> +
> + switch (reg) {
> + case 0 ... AD4691_OSC_FREQ_REG:
> + case AD4691_SPARE_CONTROL ... AD4691_ACC_SAT_OVR_REG(15):
> + ret = spi_write_then_read(spi, tx, sizeof(tx), rx, 1);
"Will this result in a truncated 1-byte read for AD4691_ACC_MASK_REG (0x185)?
AD4691_ACC_MASK_REG falls into the range between AD4691_SPARE_CONTROL and
AD4691_ACC_SAT_OVR_REG(15). In ad4691_reg_write(), AD4691_ACC_MASK_REG is
handled explicitly alongside AD4691_STD_SEQ_CONFIG to perform a 16-bit
write, but it seems missing from the 2-byte read block here."
Valid bug. The write path already splits the range around ACC_MASK_REG;
the read path was missing the same split. Fixed: ACC_MASK_REG now gets
a 2-byte read alongside STD_SEQ_CONFIG.
> + if (ret)
> + return ret;
...
> +
> +static int ad4691_reset(struct ad4691_state *st)
> +{
> + struct device *dev = regmap_get_device(st->regmap);
> + struct reset_control *rst;
> +
> + rst = devm_reset_control_get_optional_exclusive(dev, NULL);
> + if (IS_ERR(rst))
> + return dev_err_probe(dev, PTR_ERR(rst), "Failed to get
> reset\n");
> +
> + if (rst) {
> + /*
> + * reset_gpio_probe() already drives the pin asserted, so the
> + * device is held in reset before we get here.
> + * devm_reset_control_get_optional_exclusive_deasserted()
> cannot
> + * be used because it deasserts immediately without delay; the
> + * datasheet (Table 5) requires a ≥300 µs reset pulse width
> + * before deassertion.
> + */
> + fsleep(300);
> + return reset_control_deassert(rst);
"Could this sequence break on driver reload?
When the driver is unloaded, the reset line remains in its deasserted state
because there is no cleanup action to re-assert it. Upon reloading, the 300
microsecond sleep will occur while the pin is already deasserted, meaning
the hardware might not receive the required reset pulse.
Should reset_control_assert() be called explicitly prior to the delay?"
Valid. reset_control_put() does not re-assert the line at unload, so
on reload the pin is already deasserted when we enter the 300 µs sleep.
Adding reset_control_assert(rst) before fsleep(300) to guarantee a proper
reset pulse on every probe including reloads.
> + }
> +
...
> +
> + st = iio_priv(indio_dev);
> + st->info = spi_get_device_match_data(spi);
"Is it possible for st->info to be NULL here?
If the driver is manually bound to a device with a non-matching name using
the sysfs bind interface in combination with driver_override,
spi_get_device_match_data() could return NULL, which would cause a NULL
pointer dereference later in the probe sequence."
Agreed, will add the NULL check with -ENODEV immediately after
spi_get_device_match_data().
> +
> + ret = devm_mutex_init(dev, &st->lock);
> + if (ret)
> + return ret;
^ permalink raw reply
* Re: [PATCH ipsec-next v8 12/14] xfrm: add XFRM_MSG_MIGRATE_STATE for single SA migration
From: Steffen Klassert @ 2026-05-07 9:12 UTC (permalink / raw)
To: Antony Antony
Cc: Herbert Xu, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, David Ahern, Masahide NAKAMURA,
Paul Moore, Stephen Smalley, Ondrej Mosnacek, Jonathan Corbet,
Shuah Khan, Sabrina Dubroca, netdev, linux-kernel, selinux,
linux-doc, Chiachang Wang, Yan Yan, devel
In-Reply-To: <migrate-state-v8-12-4578fb016965@secunet.com>
On Tue, May 05, 2026 at 06:34:29AM +0200, Antony Antony wrote:
> Add a new netlink method to migrate a single xfrm_state.
> Unlike the existing migration mechanism (SA + policy), this
> supports migrating only the SA and allows changing the reqid.
>
> The SA is looked up via xfrm_usersa_id, which uniquely
> identifies it, so old_saddr is not needed. old_daddr is carried in
> xfrm_usersa_id.daddr.
>
> The reqid is invariant in the old migration.
>
> Signed-off-by: Antony Antony <antony.antony@secunet.com>
>
> ---
> v7->v8: - removed the unknown-flags validation block
> v6->v7: - add flags field to xfrm_user_migrate_state (based on Sabrina's feedback)
> - add XFRM_MIGRATE_STATE_NO_OFFLOAD (bit 0): suppresses offload
> - omit-to-inherit; mutually exclusive with XFRMA_OFFLOAD_DEV
> - zero-initialize struct xfrm_migrate m[XFRM_MAX_DEPTH]
> - add struct xfrm_selector new_sel to xfrm_user_migrate_state
> - add XFRM_MIGRATE_STATE_UPDATE_SEL: derive new selector
> from SA addresses when old selector is a single-host match
> v5->v6: - (Feedback from Sabrina's review)
> - reqid change: use xfrm_state_add, not xfrm_state_insert
> - encap and xuo: use nla_data() directly, no kmemdup needed
> - notification failure is non-fatal: set extack warning, return 0
> - drop state direction, x->dir, check, not required
> - reverse xmas tree local variable ordering
> - use NL_SET_ERR_MSG_WEAK for clone failure message
> - fix implicit padding in xfrm_user_migrate_state uapi struct
> - support XFRMA_SET_MARK/XFRMA_SET_MARK_MASK in XFRM_MSG_MIGRATE_STATE
> v4->v5: - set portid, seq in XFRM_MSG_MIGRATE_STATE netlink notification
> - rename error label to out for clarity
> - add locking and synchronize after cloning
> - change some if(x) to if(!x) for clarity
> - call __xfrm_state_delete() inside the lock
> - return error from xfrm_send_migrate_state() instead of always returning 0
> v3->v4: preserve reqid invariant for each state migrated
> v2->v3: free the skb on the error path
> v1->v2: merged next patch here to fix use uninitialized value
> - removed unnecessary inline
> - added const when possible
> ---
> include/net/xfrm.h | 16 ++-
> include/uapi/linux/xfrm.h | 21 ++++
> net/xfrm/xfrm_device.c | 2 +-
> net/xfrm/xfrm_policy.c | 19 +++
> net/xfrm/xfrm_state.c | 29 +++--
> net/xfrm/xfrm_user.c | 281 +++++++++++++++++++++++++++++++++++++++++++-
> security/selinux/nlmsgtab.c | 3 +-
> 7 files changed, 357 insertions(+), 14 deletions(-)
...
> +static unsigned int xfrm_migrate_state_msgsize(const struct xfrm_migrate *m,
> + u8 dir)
> +{
> + return NLMSG_ALIGN(sizeof(struct xfrm_user_migrate_state)) +
> + (m->encap ? nla_total_size(sizeof(struct xfrm_encap_tmpl)) : 0) +
> + (m->xuo ? nla_total_size(sizeof(struct xfrm_user_offload)) : 0) +
> + (m->new_mark ? nla_total_size(sizeof(struct xfrm_mark)) : 0) +
> + (m->smark.v ? nla_total_size(sizeof(u32)) * 2 : 0) + /* SET_MARK + SET_MARK_MASK */
xfrm_smark_put() checks (m->v | m->m), maybe you should
do (m->smark.v | m->smark.m) here.
> + (m->mapping_maxage ? nla_total_size(sizeof(u32)) : 0) +
> + (m->nat_keepalive_interval ? nla_total_size(sizeof(u32)) : 0) +
> + (dir ? nla_total_size(sizeof(u8)) : 0); /* XFRMA_SA_DIR */
> +}
Also, the function is not really readable.
> +
> +static int xfrm_send_migrate_state(const struct xfrm_user_migrate_state *um,
> + const struct xfrm_migrate *m,
> + u8 dir, u32 portid, u32 seq)
> +{
> + int err;
> + struct sk_buff *skb;
> + struct net *net = &init_net;
This is wrong. I know we had this in the tree for ages, but I now have
a fix in ipsec/testing for it. We need to make this namespace aware.
^ permalink raw reply
* Re: [PATCH v2 2/2] hwmon: add initial support for AMD PROM21 xHCI temperature sensor
From: Michal Pecio @ 2026-05-07 9:08 UTC (permalink / raw)
To: Mario Limonciello
Cc: Jihong Min, Greg Kroah-Hartman, Mathias Nyman, Guenter Roeck,
Jonathan Corbet, Shuah Khan, Basavaraj Natikar, linux-usb,
linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <424c4dc4-1810-4ffb-ae93-7ec9f880ec1e@amd.com>
On Wed, 6 May 2026 16:36:49 -0500, Mario Limonciello wrote:
> > > The temperature register did not return a valid value while the
> > > xHCI PCI function was suspended in testing. Keep the existing
> > > behavior by default and allow temperature reads to wake the xHCI
> > > PCI device. Add an allow_pm_switch module parameter so users can
> > > disable that behavior; when disabled, reads do not wake the
> > > device and return -EAGAIN if it is suspended.
> >
> > Is such behavior useful?
> >
> > Maybe the driver could just disable runtime PM while it's loaded.
>
> I'd encourage what we do in amdgpu for dGPUs. The hwmon files will
> return an error code (I forget which code) when the device is in
> runtime PM when called. Don't explicitly wake it otherwise.
>
> This prevents someone installing a sensor monitoring application and
> that application "being the only thing" keeping the dGPU awake. If
> it's awake already for other reasons (like being used) then return
> valid data to the applications
Well, that's not a dGPU but an xHCI controller embedded in the chipset,
which chipset is more or less active all the time (includes bridges to
PCIe ports, some SATA controllers and mabe other things I forgot).
Is the saving from disabling xHCI significant for a desktop system?
Users may be interested in monitoring chipset temperature even while
not actively using USB.
I don't know what are the conditions to put GPUs into runtime suspend,
but a USB HC will be going in and out quite randomly, depending on
connected devices and their workload. You may end up needing to answer
people why their sensor only works when they turn on a webcam :)
Alternatively, would it be possible to bring a suspendend HC into D0,
read the temperature register and then put it back into D3hot without
bothering the USB layer to fully resume and suspend xHCI logic?
Regards,
Michal
^ permalink raw reply
* Re: [PATCH 4/8] drm/panthor: Add support for protected memory allocation in panthor
From: Marcin Ślusarz @ 2026-05-07 9:02 UTC (permalink / raw)
To: Boris Brezillon
Cc: Ketil Johnsen, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jonathan Corbet, Shuah Khan,
Sumit Semwal, Benjamin Gaignard, Brian Starkey, John Stultz,
T.J. Mercier, Christian König, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek,
Florent Tomasin, nd
In-Reply-To: <20260505181523.49a3d85c@fedora>
On Tue, May 05, 2026 at 06:15:23PM +0200, Boris Brezillon wrote:
> > @@ -277,9 +286,21 @@ int panthor_device_init(struct panthor_device *ptdev)
> > return ret;
> > }
> >
> > + /* If a protected heap name is specified but not found, defer the probe until created */
> > + if (protected_heap_name && strlen(protected_heap_name)) {
>
> Do we really need this strlen() > 0? Won't dma_heap_find() fail is the
> name is "" already?
If dma_heap_find() will fail, then the whole probe with fail too.
This check prevents that. I'm not sure why it's needed at all, but if
it is really needed, then s/strlen(protected_heap_name)/protected_heap_name[0]/
would simplify this.
> > + ptdev->protm.heap = dma_heap_find(protected_heap_name);
> > + if (!ptdev->protm.heap) {
> > + drm_warn(&ptdev->base,
> > + "Protected heap \'%s\' not (yet) available - deferring probe",
> > + protected_heap_name);
> > + ret = -EPROBE_DEFER;
> > + goto err_rpm_put;
>
> If you move the heap retrieval before the rpm enablement, you can get
> rid of this goto err_rpm_put.
>
> > + }
> > + }
> > +
> > ret = panthor_hw_init(ptdev);
> > if (ret)
> > - goto err_rpm_put;
> > + goto err_dma_heap_put;
> >
> > ret = panthor_pwr_init(ptdev);
> > if (ret)
^ permalink raw reply
* [PATCH v2] cpufreq: elanfreq: Drop support for AMD Elan SC4*
From: Sean Young @ 2026-05-07 9:01 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Rafael J. Wysocki, Viresh Kumar
Cc: Zhongqiu Han, linux-doc, linux-kernel, linux-pm
Since commit 8b793a92d862 ("x86/cpu: Remove M486/M486SX/ELAN support"),
the AMD Elan SC4* is no longer supported, so the cpu frequency
driver is no longer needed.
Signed-off-by: Sean Young <sean@mess.org>
---
Changes since v1:
- Also removes elanfreq= entry from kernel-parameters.txt
.../admin-guide/kernel-parameters.txt | 4 -
drivers/cpufreq/Kconfig.x86 | 15 --
drivers/cpufreq/Makefile | 1 -
drivers/cpufreq/elanfreq.c | 226 ------------------
4 files changed, 246 deletions(-)
delete mode 100644 drivers/cpufreq/elanfreq.c
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 4d0f545fb3ec..7ab0e58c4aa9 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1669,10 +1669,6 @@ Kernel parameters
very early in the boot process. For early debugging
via a serial port see kgdboc_earlycon instead.
- elanfreq= [X86-32]
- See comment before function elanfreq_setup() in
- arch/x86/kernel/cpu/cpufreq/elanfreq.c.
-
elfcorehdr=[size[KMG]@]offset[KMG] [PPC,SH,X86,S390,EARLY]
Specifies physical address of start of kernel core
image elf header and optionally the size. Generally
diff --git a/drivers/cpufreq/Kconfig.x86 b/drivers/cpufreq/Kconfig.x86
index 865b290b01ff..c42dd39e0b2a 100644
--- a/drivers/cpufreq/Kconfig.x86
+++ b/drivers/cpufreq/Kconfig.x86
@@ -126,21 +126,6 @@ config X86_ACPI_CPUFREQ_CPB
By enabling this option the acpi_cpufreq driver provides the old
entry in addition to the new boost ones, for compatibility reasons.
-config ELAN_CPUFREQ
- tristate "AMD Elan SC400 and SC410"
- depends on MELAN
- help
- This adds the CPUFreq driver for AMD Elan SC400 and SC410
- processors.
-
- You need to specify the processor maximum speed as boot
- parameter: elanfreq=maxspeed (in kHz) or as module
- parameter "max_freq".
-
- For details, take a look at <file:Documentation/cpu-freq/>.
-
- If in doubt, say N.
-
config X86_POWERNOW_K6
tristate "AMD Mobile K6-2/K6-3 PowerNow!"
depends on X86_32
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 96196edf79d5..6c7a39b7f8d2 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -40,7 +40,6 @@ obj-$(CONFIG_X86_POWERNOW_K6) += powernow-k6.o
obj-$(CONFIG_X86_POWERNOW_K7) += powernow-k7.o
obj-$(CONFIG_X86_LONGHAUL) += longhaul.o
obj-$(CONFIG_X86_E_POWERSAVER) += e_powersaver.o
-obj-$(CONFIG_ELAN_CPUFREQ) += elanfreq.o
obj-$(CONFIG_X86_LONGRUN) += longrun.o
obj-$(CONFIG_X86_GX_SUSPMOD) += gx-suspmod.o
obj-$(CONFIG_X86_SPEEDSTEP_ICH) += speedstep-ich.o
diff --git a/drivers/cpufreq/elanfreq.c b/drivers/cpufreq/elanfreq.c
deleted file mode 100644
index fc5a58088b35..000000000000
--- a/drivers/cpufreq/elanfreq.c
+++ /dev/null
@@ -1,226 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-or-later
-/*
- * elanfreq: cpufreq driver for the AMD ELAN family
- *
- * (c) Copyright 2002 Robert Schwebel <r.schwebel@pengutronix.de>
- *
- * Parts of this code are (c) Sven Geggus <sven@geggus.net>
- *
- * All Rights Reserved.
- *
- * 2002-02-13: - initial revision for 2.4.18-pre9 by Robert Schwebel
- */
-
-#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-
-#include <linux/kernel.h>
-#include <linux/module.h>
-#include <linux/init.h>
-
-#include <linux/delay.h>
-#include <linux/cpufreq.h>
-
-#include <asm/cpu_device_id.h>
-#include <linux/timex.h>
-#include <linux/io.h>
-
-#define REG_CSCIR 0x22 /* Chip Setup and Control Index Register */
-#define REG_CSCDR 0x23 /* Chip Setup and Control Data Register */
-
-/* Module parameter */
-static int max_freq;
-
-struct s_elan_multiplier {
- int clock; /* frequency in kHz */
- int val40h; /* PMU Force Mode register */
- int val80h; /* CPU Clock Speed Register */
-};
-
-/*
- * It is important that the frequencies
- * are listed in ascending order here!
- */
-static struct s_elan_multiplier elan_multiplier[] = {
- {1000, 0x02, 0x18},
- {2000, 0x02, 0x10},
- {4000, 0x02, 0x08},
- {8000, 0x00, 0x00},
- {16000, 0x00, 0x02},
- {33000, 0x00, 0x04},
- {66000, 0x01, 0x04},
- {99000, 0x01, 0x05}
-};
-
-static struct cpufreq_frequency_table elanfreq_table[] = {
- {0, 0, 1000},
- {0, 1, 2000},
- {0, 2, 4000},
- {0, 3, 8000},
- {0, 4, 16000},
- {0, 5, 33000},
- {0, 6, 66000},
- {0, 7, 99000},
- {0, 0, CPUFREQ_TABLE_END},
-};
-
-
-/**
- * elanfreq_get_cpu_frequency: determine current cpu speed
- *
- * Finds out at which frequency the CPU of the Elan SOC runs
- * at the moment. Frequencies from 1 to 33 MHz are generated
- * the normal way, 66 and 99 MHz are called "Hyperspeed Mode"
- * and have the rest of the chip running with 33 MHz.
- */
-
-static unsigned int elanfreq_get_cpu_frequency(unsigned int cpu)
-{
- u8 clockspeed_reg; /* Clock Speed Register */
-
- local_irq_disable();
- outb_p(0x80, REG_CSCIR);
- clockspeed_reg = inb_p(REG_CSCDR);
- local_irq_enable();
-
- if ((clockspeed_reg & 0xE0) == 0xE0)
- return 0;
-
- /* Are we in CPU clock multiplied mode (66/99 MHz)? */
- if ((clockspeed_reg & 0xE0) == 0xC0) {
- if ((clockspeed_reg & 0x01) == 0)
- return 66000;
- else
- return 99000;
- }
-
- /* 33 MHz is not 32 MHz... */
- if ((clockspeed_reg & 0xE0) == 0xA0)
- return 33000;
-
- return (1<<((clockspeed_reg & 0xE0) >> 5)) * 1000;
-}
-
-
-static int elanfreq_target(struct cpufreq_policy *policy,
- unsigned int state)
-{
- /*
- * Access to the Elan's internal registers is indexed via
- * 0x22: Chip Setup & Control Register Index Register (CSCI)
- * 0x23: Chip Setup & Control Register Data Register (CSCD)
- *
- */
-
- /*
- * 0x40 is the Power Management Unit's Force Mode Register.
- * Bit 6 enables Hyperspeed Mode (66/100 MHz core frequency)
- */
-
- local_irq_disable();
- outb_p(0x40, REG_CSCIR); /* Disable hyperspeed mode */
- outb_p(0x00, REG_CSCDR);
- local_irq_enable(); /* wait till internal pipelines and */
- udelay(1000); /* buffers have cleaned up */
-
- local_irq_disable();
-
- /* now, set the CPU clock speed register (0x80) */
- outb_p(0x80, REG_CSCIR);
- outb_p(elan_multiplier[state].val80h, REG_CSCDR);
-
- /* now, the hyperspeed bit in PMU Force Mode Register (0x40) */
- outb_p(0x40, REG_CSCIR);
- outb_p(elan_multiplier[state].val40h, REG_CSCDR);
- udelay(10000);
- local_irq_enable();
-
- return 0;
-}
-/*
- * Module init and exit code
- */
-
-static int elanfreq_cpu_init(struct cpufreq_policy *policy)
-{
- struct cpuinfo_x86 *c = &cpu_data(0);
- struct cpufreq_frequency_table *pos;
-
- /* capability check */
- if ((c->x86_vendor != X86_VENDOR_AMD) ||
- (c->x86 != 4) || (c->x86_model != 10))
- return -ENODEV;
-
- /* max freq */
- if (!max_freq)
- max_freq = elanfreq_get_cpu_frequency(0);
-
- /* table init */
- cpufreq_for_each_entry(pos, elanfreq_table)
- if (pos->frequency > max_freq)
- pos->frequency = CPUFREQ_ENTRY_INVALID;
-
- policy->freq_table = elanfreq_table;
- return 0;
-}
-
-
-#ifndef MODULE
-/**
- * elanfreq_setup - elanfreq command line parameter parsing
- *
- * elanfreq command line parameter. Use:
- * elanfreq=66000
- * to set the maximum CPU frequency to 66 MHz. Note that in
- * case you do not give this boot parameter, the maximum
- * frequency will fall back to _current_ CPU frequency which
- * might be lower. If you build this as a module, use the
- * max_freq module parameter instead.
- */
-static int __init elanfreq_setup(char *str)
-{
- max_freq = simple_strtoul(str, &str, 0);
- pr_warn("You're using the deprecated elanfreq command line option. Use elanfreq.max_freq instead, please!\n");
- return 1;
-}
-__setup("elanfreq=", elanfreq_setup);
-#endif
-
-
-static struct cpufreq_driver elanfreq_driver = {
- .get = elanfreq_get_cpu_frequency,
- .flags = CPUFREQ_NO_AUTO_DYNAMIC_SWITCHING,
- .verify = cpufreq_generic_frequency_table_verify,
- .target_index = elanfreq_target,
- .init = elanfreq_cpu_init,
- .name = "elanfreq",
-};
-
-static const struct x86_cpu_id elan_id[] = {
- X86_MATCH_VENDOR_FAM_MODEL(AMD, 4, 10, NULL),
- {}
-};
-MODULE_DEVICE_TABLE(x86cpu, elan_id);
-
-static int __init elanfreq_init(void)
-{
- if (!x86_match_cpu(elan_id))
- return -ENODEV;
- return cpufreq_register_driver(&elanfreq_driver);
-}
-
-
-static void __exit elanfreq_exit(void)
-{
- cpufreq_unregister_driver(&elanfreq_driver);
-}
-
-
-module_param(max_freq, int, 0444);
-
-MODULE_LICENSE("GPL");
-MODULE_AUTHOR("Robert Schwebel <r.schwebel@pengutronix.de>, "
- "Sven Geggus <sven@geggus.net>");
-MODULE_DESCRIPTION("cpufreq driver for AMD's Elan CPUs");
-
-module_init(elanfreq_init);
-module_exit(elanfreq_exit);
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] hwmon: add initial support for AMD PROM21 xHCI temperature sensor
From: Michal Pecio @ 2026-05-07 8:51 UTC (permalink / raw)
To: Jihong Min
Cc: Jihong Min, Mario Limonciello, Greg Kroah-Hartman, Mathias Nyman,
Guenter Roeck, Jonathan Corbet, Shuah Khan, Basavaraj Natikar,
linux-usb, linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <c7d0e6c4-1c6c-432e-90ed-f0604401d691@icloud.com>
On Thu, 7 May 2026 07:41:28 +0900, Jihong Min wrote:
> > I think this commit message and certainly the Kconfig help text
> > should include full name of the chip and perhaps its official
> > marketing names too, so that people better understand what hardware
> > is supported.
> >
> > So: "AMD Promontory 21 chipset" and "AM5 6xx/8xx series chipsets",
> > or whatever they are called by AMD and motherboard vendors.
>
> Addressed locally for v3. I changed the commit message, Kconfig
> prompt/help text, and hwmon documentation to use the full name, "AMD
> Promontory 21 (PROM21)".
>
> I avoided putting chipset marketing names directly into the Kconfig
> text and commit subject because some AMD 6xx/8xx series chipsets can
> be built from more than one PROM21 IP in a daisy-chained
> configuration, including more than one PROM21 xHCI controller.
Not sure how is this a problem?
The driver is still applicable to those daisy-chained chipsets.
Configuring the kernel is tedious enough already, the help text should
ideally tell me whether I need this driver or not without searching
for obscure code names.
I would even go as far as to mention that it's for AM5 chipsets,
because AMD recycles chipset numbers every few generations.
> > Is there any documentation of the index/data registers themselves?
>
> I am not aware of public AMD documentation for the PROM21 vendor
> index/data registers or the temperature selector.
>
> For my initial validation on an X870E system with two decade or
> so.PROM21 xHCI controllers, I passed one PROM21 xHCI controller
> through to a Windows VM, left USB traffic idle, and let a Windows
> monitoring utility poll the controller temperature. From the Linux
> host I monitored that controller's PCI MMIO BAR with read-only
> accesses.
>
> The vendor index register repeatedly held the same selector value,
> and the adjacent data register exposed a stable low 8-bit value.
> [...]
>
> After identifying the register pair, I used the same validation setup
> to derive the conversion formula by comparing the observed raw MMIO
> register value against HWiNFO64's reported PROM21 xHCI temperature on
> Windows.
Looks good, unless there are gotchas like the actual formula being
dependent on other factors you haven't noticed HWiNFO reading.
It would be good idea to record this methodology in the commit message
or docs so that others can repeat your experiment in case of issues.
Regards,
Michal
^ permalink raw reply
* Re: [PATCH 8/8] drm/panthor: Expose protected rendering features
From: Marcin Ślusarz @ 2026-05-07 8:47 UTC (permalink / raw)
To: Ketil Johnsen
Cc: David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jonathan Corbet, Shuah Khan, Sumit Semwal,
Benjamin Gaignard, Brian Starkey, John Stultz, T.J. Mercier,
Christian König, Boris Brezillon, Steven Price, Liviu Dudau,
Daniel Almeida, Alice Ryhl, Matthias Brugger,
AngeloGioacchino Del Regno, dri-devel, linux-doc, linux-kernel,
linux-media, linaro-mm-sig, linux-arm-kernel, linux-mediatek, nd
In-Reply-To: <20260505140516.1372388-9-ketil.johnsen@arm.com>
On Tue, May 05, 2026 at 04:05:14PM +0200, Ketil Johnsen wrote:
> @@ -504,6 +509,28 @@ struct drm_panthor_group_priorities_info {
> __u8 pad[3];
> };
>
> +/**
> + * enum drm_panthor_protected_feature_flags - Supported protected rendering features
> + *
> + * Place new types at the end, don't re-order, don't remove or replace.
I think this note about modification doesn't make much sense as UAPI
documenation, and for driver developers it should implicit, but if you
really want this then I'd change this to:
Place new *flags* at ...
> + */
> +enum drm_panthor_protected_feature_flags {
> + /** @DRM_PANTHOR_PROTECTED_FEATURE_BASIC: Protected rendering available */
> + DRM_PANTHOR_PROTECTED_FEATURE_BASIC = 1 << 0,
> +};
> +
> +/**
> + * struct drm_panthor_protected_info - protected support information
> + *
> + * Structure grouping all queryable information relating to the allowed group priorities.
Looks like description was copied from struct drm_panthor_group_priorities_info.
> + */
> +struct drm_panthor_protected_info {
> + /**
> + * @features: Combination of enum drm_panthor_protected_feature_flags flags.
> + */
> + __u32 features;
> +};
> +
> /**
> * struct drm_panthor_dev_query - Arguments passed to DRM_PANTHOR_IOCTL_DEV_QUERY
> */
^ permalink raw reply
* Re: [PATCH 07/11] of: reserved_mem: add no-dump crash_mem exclusion helpers
From: Wandun @ 2026-05-07 8:48 UTC (permalink / raw)
To: Rob Herring
Cc: kexec, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linux-riscv, devicetree, akpm, bhe, rppt, pasha.tatashin,
pratyush, ruirui.yang, corbet, skhan, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, saravanak, chenwandun,
zhaomeijing, everyzhao
In-Reply-To: <20260506145022.GA2084721-robh@kernel.org>
On 5/6/26 22:50, Rob Herring wrote:
> On Wed, Apr 29, 2026 at 02:58:27PM +0800, Chen Wandun wrote:
>> Provide two kdump-oriented helpers so that arch kexec_file code does
>> not have to open-code the no-dump filtering loop:
>>
>> - of_reserved_mem_no_dump_nr_ranges() returns the number of reserved
>> regions flagged with linux,no-dump. Each exclusion may split one
>> existing crash_mem range into two, so callers use this count to
>> pre-size their crash_mem allocation.
>>
>> - of_reserved_mem_exclude_no_dump() walks the reserved_mem[] array
>> and calls crash_exclude_mem_range() for each no-dump region.
>>
>> Both helpers are guarded by CONFIG_KEXEC_FILE; empty inline stubs are
>> provided for the !KEXEC_FILE case so architecture code can call them
>> unconditionally.
>>
>> The consumers are added in the following arm64, riscv and loongarch
>> patches in this series.
>>
>> Signed-off-by: Chen Wandun <chenwandun@lixiang.com>
>> Tested-by: Zhao Meijing <zhaomeijing@lixiang.com>
>> ---
>> drivers/of/of_reserved_mem.c | 54 +++++++++++++++++++++++++++++++++
>> include/linux/of_reserved_mem.h | 15 +++++++++
>> 2 files changed, 69 insertions(+)
>>
>> diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
>> index 4b80420da2d2..038056a6408a 100644
>> --- a/drivers/of/of_reserved_mem.c
>> +++ b/drivers/of/of_reserved_mem.c
>> @@ -27,6 +27,10 @@
>>
>> #include "of_private.h"
>>
>> +#ifdef CONFIG_KEXEC_FILE
>> +#include <linux/crash_core.h>
>> +#endif
> You shouldn't need ifdef around includes.
>
>> +
>> static struct reserved_mem reserved_mem_array[MAX_RESERVED_REGIONS] __initdata;
>> static struct reserved_mem *reserved_mem __refdata = reserved_mem_array;
>> static int total_reserved_mem_cnt = MAX_RESERVED_REGIONS;
>> @@ -916,6 +920,56 @@ struct reserved_mem *of_reserved_mem_lookup(struct device_node *np)
>> }
>> EXPORT_SYMBOL_GPL(of_reserved_mem_lookup);
>>
>> +#ifdef CONFIG_KEXEC_FILE
> Use 'if (IS_ENABLED())' within the function.
Get it, thanks.
>
>> +/**
>> + * of_reserved_mem_no_dump_nr_ranges() - count reserved regions flagged
>> + * with the linux,no-dump property.
>> + *
>> + * Each such region may split an existing crash_mem range into two when
>> + * it is excluded, so callers can use this count to pre-size their
>> + * crash_mem allocation.
>> + */
>> +unsigned int of_reserved_mem_no_dump_nr_ranges(void)
>> +{
>> + unsigned int i, n = 0;
>> +
>> + for (i = 0; i < reserved_mem_count; i++)
>> + if (reserved_mem[i].no_dump)
>> + n++;
>> + return n;
>> +}
>> +
>> +/**
>> + * of_reserved_mem_exclude_no_dump() - exclude no-dump reserved regions
>> + * from a crash_mem list.
>> + * @cmem: crash memory list to modify
>> + *
>> + * Walks the reserved_mem[] array and calls crash_exclude_mem_range() for
>> + * every region with no_dump set. Intended to be called from arch kdump
>> + * code when constructing the elfcorehdr.
>> + *
>> + * Returns 0 on success, or a negative error returned by
>> + * crash_exclude_mem_range() on the first failure.
>> + */
>> +int of_reserved_mem_exclude_no_dump(struct crash_mem *cmem)
>> +{
>> + unsigned int i;
>> + int ret;
>> +
>> + for (i = 0; i < reserved_mem_count; i++) {
>> + struct reserved_mem *r = &reserved_mem[i];
>> +
>> + if (!r->no_dump || !r->size)
>> + continue;
>> + ret = crash_exclude_mem_range(cmem, r->base,
>> + r->base + r->size - 1);
>> + if (ret)
>> + return ret;
>> + }
>> + return 0;
>> +}
>> +#endif /* CONFIG_KEXEC_FILE */
^ permalink raw reply
* Re: [PATCH v11 01/11] dt-bindings: iio: frequency: add adf41513
From: Rodrigo Alencar @ 2026-05-07 8:41 UTC (permalink / raw)
To: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc
Cc: Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan, Krzysztof Kozlowski
In-Reply-To: <20260506-adf41513-iio-driver-v11-1-2b7e99cfe8f2@analog.com>
On 26/05/06 03:08PM, Rodrigo Alencar via B4 Relay wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> DT-bindings for ADF41513, an ultralow noise PLL frequency synthesizer that
> can be used to implement local oscillators (LOs) as high as 26.5 GHz.
> Some properties are based upon an existing PLL device properties
> (e.g. ADF4350).
...
> +properties:
> + compatible:
> + enum:
> + - adi,adf41510
> + - adi,adf41513
...
> + adi,power-up-frequency-mhz:
> + minimum: 1000
> + maximum: 26500
> + default: 10000
> + description:
> + The PLL tunes to this frequency during the initialization sequence.
> + This property should be set to a frequency supported by the loop filter
> + and VCO used in the design. Range is 1 GHz to 26.5 GHz for ADF41513,
> + and 1 GHz to 10 GHz for ADF41510.
Sashiko's feedback:
https://sashiko.dev/#/patchset/20260506-adf41513-iio-driver-v11-0-2b7e99cfe8f2%40analog.com?part=1
Does the schema allow an ADF41510 device to be configured with frequencies
exceeding its physical hardware capabilities?
The global maximum for adi,power-up-frequency-mhz is set to 26500, but the
description notes that the ADF41510 variant only supports up to 10 GHz.
Should there be an allOf conditional block that restricts the maximum value
to 10000 when the adi,adf41510 compatible string is used?
That makes sense and will address this in a v12.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH 01/11] of: reserved_mem: fix region count for nodes with multiple reg entries
From: Wandun @ 2026-05-07 8:41 UTC (permalink / raw)
To: Rob Herring
Cc: kexec, linux-doc, linux-kernel, linux-arm-kernel, loongarch,
linux-riscv, devicetree, akpm, bhe, rppt, pasha.tatashin,
pratyush, ruirui.yang, corbet, skhan, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, saravanak, chenwandun,
zhaomeijing, everyzhao
In-Reply-To: <20260506014752.GA280279-robh@kernel.org>
在 2026/5/6 09:47, Rob Herring 写道:
> On Wed, Apr 29, 2026 at 02:58:21PM +0800, Chen Wandun wrote:
>> When a reserved-memory node contains multiple reg entries (e.g.,
>> reg = <base1 size1>, <base2 size2>), the count used for
>> total_reserved_mem_cnt is wrong in two places:
>>
>> 1) __reserved_mem_reserve_reg() returns 0 on success regardless of how
>> many regions it reserved in memblock. The caller in
>> fdt_scan_reserved_mem() then increments count by just 1.
> Just to make sure, more than 1 worked before the referenced commits? It
> would be easier to just define we only expect/support 1 entry.
Looking at the pre-8a6e02d0c00e code, __reserved_mem_reserve_reg()
reserved memblock memory for all reg entries, but only called
fdt_reserved_mem_save_node() for the first one (guarded by an 'if
(first)' flag).
So multiple reg entries were never fully supported: subsequent entries
got their memory reserved in memblock, but their metadata was lost
and driver-specific init callbacks were never invoked for them.
The referenced commits made this worse by also breaking the count
tracking, but the root limitation predates them.
I support documenting "only 1 entry supported" based on the
following reasons:
- of_reserved_mem_lookup() does a name-based linear scan and returns
the *first* matching entry. A node with N reg entries would create
N entries with identical names; entries [1..N-1] are permanently
unreachable via lookup.
- Drivers like CMA and DMA coherent are designed to initialize a
single contiguous pool per node_init call. Calling node_init
multiple times with the same FDT node is not a supported usage.
>
>> 2) fdt_scan_reserved_mem_late() uses of_flat_dt_get_addr_size() which
>> only reads the first reg entry. Subsequent entries are never
>> initialized via fdt_init_reserved_mem_node(), so their metadata is
>> lost.
>>
>> Fix both issues:
>> - Make __reserved_mem_reserve_reg() return the actual number of
>> regions successfully reserved. Update the caller to accumulate
>> the returned count.
>> - Rewrite fdt_scan_reserved_mem_late() to use
>> of_flat_dt_get_addr_size_prop() and iterate all reg entries,
>> initializing each one via fdt_init_reserved_mem_node().
>>
>> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved memory regions are processed")
>> Fixes: 00c9a452a235 ("of: reserved_mem: Add code to dynamically allocate reserved_mem array")
^ permalink raw reply
* Re: [PATCH v9 00/22] Enable FRED with KVM VMX
From: David Woodhouse @ 2026-05-07 7:49 UTC (permalink / raw)
To: Maciej Wieczor-Retman, Andrew Cooper
Cc: Xin Li, linux-kernel, kvm, linux-doc, Saenz Julienne, Nicolas,
pbonzini, seanjc, corbet, tglx, mingo, bp, dave.hansen, x86, hpa,
luto, peterz, chao.gao, hch, sohil.mehta
In-Reply-To: <afpPt7gObsyFkPRy@wieczorr-mobl1.localdomain>
[-- Attachment #1: Type: text/plain, Size: 611 bytes --]
On Tue, 2026-05-05 at 22:20 +0200, Maciej Wieczor-Retman wrote:
>
> I take it you mean dropping the ICEBP selftest test case and just checking INT3
> and INT $0x20? In that case the other two tests pass after a minor change -
> namely in guest_code() the expected_rip needs to be volatile as well. Otherwise
> there is a RIP mismatch.
I don't understand the part about making expected_rip volatile. Are the
asm constraints there not correct? If not I'd rather *fix* them than
use 'volatile' to paper over it. I can't see the issue though.
Can you show the generated asm both with and without it?
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ 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