* Re: [PATCH v3 3/5] KVM: PPC: Book3S HV: Implement compat CPU capability retrieval for KVM on PowerVM
From: Amit Machhiwal @ 2026-06-10 15:51 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan,
Anushree Mathur, Paolo Bonzini, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), Jonathan Corbet, Shuah Khan, kvm,
linux-kernel, linux-doc, lkp
In-Reply-To: <87mrxcz300.fsf@vajain21.in.ibm.com>
Hi Vaibhav,
Thanks for taking a look at this patch. My response is inline.
On 2026/06/03 09:31 AM, Vaibhav Jain wrote:
> Hi Amit,
>
> Thanks for the patch. My review comments inline below:
>
> Amit Machhiwal <amachhiw@linux.ibm.com> writes:
>
> > On POWER systems, the host CPU may run in a compatibility mode (e.g., a
> > Power11 processor operating in Power10 compatibility mode). In such
> > cases, the effective CPU level exposed to guests differs from the
> > physical processor generation.
> >
> > When running nested KVM guests, QEMU derives the host CPU type using
> > mfpvr(), which reflects the physical processor version. This can result
> > in a mismatch between the CPU model selected by QEMU and the
> > compatibility mode enforced by the host, leading to guest boot failures.
> >
> > For example, booting a nested guest on a Power11 LPAR configured in
> > Power10 compatibility mode fails with:
> >
> > KVM-NESTEDv2: couldn't set guest wide elements
> > [..KVM reg dump..]
> >
> > This occurs because QEMU selects a CPU model corresponding to the
> > physical processor (via mfpvr()), while the host operates in a lower
> > compatibility mode. As a result, KVM rejects the requested compatibility
> > level during guest initialization.
> >
> > Add support for retrieving host CPU compatibility capabilities for
> > nested guests on PowerVM (PAPR nested API v2). The hypervisor provides
> > the effective compatibility levels via the H_GUEST_GET_CAPABILITIES
> > hcall, which reflects the processor modes negotiated between the Power
> > hypervisor (L0) and the host partition (L1).
> >
> > On pseries systems, obtain the capability bitmap using
> > plpar_guest_get_capabilities() and return it via struct
> > kvm_ppc_compat_caps. This information is then exposed to userspace
> > through the KVM_PPC_GET_COMPAT_CAPS ioctl.
> >
> > Hook the implementation into the Book3S HV kvmppc_ops so that it can be
> > invoked by the generic KVM ioctl handling code.
> >
> > Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> > Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
> > Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> > ---
> > arch/powerpc/kvm/book3s_hv.c | 16 ++++++++++++++++
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/arch/powerpc/kvm/book3s_hv.c b/arch/powerpc/kvm/book3s_hv.c
> > index 249d1f2e4e2c..38de7040e2b7 100644
> > --- a/arch/powerpc/kvm/book3s_hv.c
> > +++ b/arch/powerpc/kvm/book3s_hv.c
> > @@ -6522,6 +6522,21 @@ static bool kvmppc_hash_v3_possible(void)
> > return true;
> > }
> >
> > +
> > +static int kvmppc_get_compat_cpu_caps(struct kvm_ppc_compat_caps *host_caps)
> > +{
> > + unsigned long capabilities = 0;
> > + long rc = -EINVAL;
> > +
> > + if (kvmhv_on_pseries()) {
> > + if (kvmhv_is_nestedv2())
> > + rc = plpar_guest_get_capabilities(0,
> > &capabilities);
>
> since this value will trikle back to userspace please apply a mask on
> the hcall return value so that any reserved and non-PVR related bits
> doesnt leak back to userspace.
Though currently we only supply the bits corresponding to supported
processor versions, it makes sense to mask out unrelated bits so that
they don't unnecesarily passed on to the userspace. I'll make the
changes in v4.
Thanks,
Amit
>
> > + host_caps->compat_capabilities = capabilities;
> > + }
> > +
> > + return rc;
> > +}
> > +
> > static struct kvmppc_ops kvm_ops_hv = {
> > .get_sregs = kvm_arch_vcpu_ioctl_get_sregs_hv,
> > .set_sregs = kvm_arch_vcpu_ioctl_set_sregs_hv,
> > @@ -6564,6 +6579,7 @@ static struct kvmppc_ops kvm_ops_hv = {
> > .hash_v3_possible = kvmppc_hash_v3_possible,
> > .create_vcpu_debugfs = kvmppc_arch_create_vcpu_debugfs_hv,
> > .create_vm_debugfs = kvmppc_arch_create_vm_debugfs_hv,
> > + .get_compat_cpu_ver = kvmppc_get_compat_cpu_caps,
> > };
> >
> > static int kvm_init_subcore_bitmap(void)
> > --
> > 2.50.1 (Apple Git-155)
> >
> >
>
> --
> Cheers
> ~ Vaibhav
^ permalink raw reply
* Re: [PATCH v5 09/21] nfsd: add data structures for handling CB_NOTIFY
From: Jeff Layton @ 2026-06-10 15:51 UTC (permalink / raw)
To: Chuck Lever, Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo,
Tom Talpey, Trond Myklebust, Anna Schumaker, Jonathan Corbet,
Shuah Khan
Cc: Steven Rostedt, Alexander Aring, Amir Goldstein, Jan Kara,
Alexander Viro, Christian Brauner, Calum Mackay, linux-kernel,
linux-doc, linux-nfs
In-Reply-To: <566fd48c-bf10-4974-9ee4-1afc30b7a69c@app.fastmail.com>
On Mon, 2026-06-08 at 16:18 -0400, Chuck Lever wrote:
>
> On Fri, May 22, 2026, at 3:42 PM, Jeff Layton wrote:
> > Add the data structures, allocation helpers, and callback operations
> > needed for directory delegation CB_NOTIFY support:
>
> > diff --git a/fs/nfsd/state.h b/fs/nfsd/state.h
> > index 9c6e2e7abc82..505fabf8f1bf 100644
> > --- a/fs/nfsd/state.h
> > +++ b/fs/nfsd/state.h
> > @@ -197,6 +197,44 @@ struct nfs4_cb_fattr {
> > #define NOTIFY4_EVENT_QUEUE_SIZE 3
> > #define NOTIFY4_PAGE_ARRAY_SIZE 1
> >
> > +struct nfsd_notify_event {
> > + refcount_t ne_ref; // refcount
> > + u32 ne_mask; // FS_* mask from fsnotify callback
> > + struct dentry *ne_dentry; // dentry reference to target
> > + u32 ne_namelen; // length of ne_name
> > + char ne_name[]; // name of dentry being changed
>
> Nit: checkpatch doesn't like the C++ comment style.
>
>
> > +};
> > +
> > +static inline struct nfsd_notify_event *nfsd_notify_event_get(struct
> > nfsd_notify_event *ne)
> > +{
> > + refcount_inc(&ne->ne_ref);
> > + return ne;
> > +}
> > +
> > +static inline void nfsd_notify_event_put(struct nfsd_notify_event *ne)
> > +{
> > + if (refcount_dec_and_test(&ne->ne_ref)) {
> > + dput(ne->ne_dentry);
> > + kfree(ne);
> > + }
> > +}
> > +
> > +/*
> > + * Represents a directory delegation. The callback is for handling
> > CB_NOTIFYs.
> > + * As notifications from fsnotify come in, allocate a new event, take
> > the ncn_lock,
> > + * and add it to the ncn_evt queue. The CB_NOTIFY prepare handler will
> > take the
> > + * lock, clean out the list and process it.
> > + */
> > +struct nfsd4_cb_notify {
> > + spinlock_t ncn_lock; // protects the evt queue and count
> > + int ncn_evt_cnt; // count of events in ncn_evt
> > + int ncn_nf_cnt; // count of valid entries in ncn_nf
> > + struct nfsd_notify_event *ncn_evt[NOTIFY4_EVENT_QUEUE_SIZE]; // list
> > of events
> > + struct page *ncn_pages[NOTIFY4_PAGE_ARRAY_SIZE]; // for encoding
> > + struct notify4 *ncn_nf; // array of notify4's to be sent
> > + struct nfsd4_callback ncn_cb; // notify4 callback
> > +};
>
> Ditto.
>
I'll note that the code is littered with this comment style anyway,
including a bunch of the new // SPDX- header comments. Personally, I
find this more readable for documenting struct fields.
AFAICT, the checkpatch rule was manufactured out of thin air.
Documentation/dev-tools/checkpatch.rst says:
**C99_COMMENTS**
C99 style single line comments (//) should not be used.
Prefer the block comment style instead.
See:
https://www.kernel.org/doc/html/latest/process/coding-style.html#commenting
...but that coding-style document says nothing about C99 comments. I
move that we ignore checkpatch here.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 2/5] KVM: PPC: Introduce KVM_CAP_PPC_COMPAT_CAPS and wire up ioctl
From: Amit Machhiwal @ 2026-06-10 15:47 UTC (permalink / raw)
To: Vaibhav Jain
Cc: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan,
Anushree Mathur, Paolo Bonzini, Nicholas Piggin, Michael Ellerman,
Christophe Leroy (CS GROUP), Jonathan Corbet, Shuah Khan, kvm,
linux-kernel, linux-doc, lkp
In-Reply-To: <87pl28z3nx.fsf@vajain21.in.ibm.com>
Hi Vaibhav,
Thanks for reviewing the patches. Please find my response inline.
On 2026/06/03 09:16 AM, Vaibhav Jain wrote:
> Hi Amit,
>
> Thanks for this patch. Few review comments below:
>
> Amit Machhiwal <amachhiw@linux.ibm.com> writes:
>
> > Introduce a new capability and ioctl to expose CPU compatibility modes
> > supported by the host processor for nested guests.
> >
> > On IBM POWER systems, newer processor generations (N) can operate in
> > compatibility modes corresponding to earlier generations, like (N-1) and
> > (N-2). This is particularly relevant for nested virtualization, where
> > nested KVM guests may need to run with a specific processor compatibility
> > level.
> >
> > Introduce KVM_CAP_PPC_COMPAT_CAPS capability and the corresponding
> > KVM_PPC_GET_COMPAT_CAPS vm ioctl. The ioctl returns a bitmap describing
> > the compatibility modes supported by the host in respective bit numbers,
> > allowing userspace (e.g., QEMU) to select an appropriate compatibility
> > level when configuring nested KVM guests.
> >
> > The ioctl handling is added in kvm_arch_vm_ioctl() and retrieves host
> > CPU compatibility capabilities via a PowerPC-specific backend
> > implementation when available. If the capability is not supported, the
> > ioctl returns success with no capabilities set, allowing userspace to
> > fall back gracefully.
> >
> > Suggested-by: Vaibhav Jain <vaibhav@linux.ibm.com>
> > Tested-by: Anushree Mathur <anushree.mathur@linux.ibm.com>
> > Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> > ---
> > arch/powerpc/include/asm/kvm_ppc.h | 1 +
> > arch/powerpc/include/uapi/asm/kvm.h | 6 ++++++
> > arch/powerpc/kvm/powerpc.c | 21 +++++++++++++++++++++
> > include/uapi/linux/kvm.h | 4 ++++
> > 4 files changed, 32 insertions(+)
> >
> > diff --git a/arch/powerpc/include/asm/kvm_ppc.h b/arch/powerpc/include/asm/kvm_ppc.h
> > index 0953f2daa466..cadfb839e836 100644
> > --- a/arch/powerpc/include/asm/kvm_ppc.h
> > +++ b/arch/powerpc/include/asm/kvm_ppc.h
> > @@ -319,6 +319,7 @@ struct kvmppc_ops {
> > bool (*hash_v3_possible)(void);
> > int (*create_vm_debugfs)(struct kvm *kvm);
> > int (*create_vcpu_debugfs)(struct kvm_vcpu *vcpu, struct dentry *debugfs_dentry);
> > + int (*get_compat_cpu_ver)(struct kvm_ppc_compat_caps *host_caps);
> > };
> >
> > extern struct kvmppc_ops *kvmppc_hv_ops;
> > diff --git a/arch/powerpc/include/uapi/asm/kvm.h b/arch/powerpc/include/uapi/asm/kvm.h
> > index 077c5437f521..081d6c7f7f70 100644
> > --- a/arch/powerpc/include/uapi/asm/kvm.h
> > +++ b/arch/powerpc/include/uapi/asm/kvm.h
> > @@ -437,6 +437,12 @@ struct kvm_ppc_cpu_char {
> > __u64 behaviour_mask; /* valid bits in behaviour */
> > };
> >
> > +/* For KVM_PPC_GET_COMPAT_CAPS */
> > +struct kvm_ppc_compat_caps {
> > + __u64 flags; /* Reserved for future use */
> Please introduce a size field also for the UAPI so that in this
> structure can evolve in future without breaking kernel ABI.
Sure, adding a size field for validations and future extensibility makes
sense. I'll add it in the next version.
>
> > + __u64 compat_capabilities; /* Capabilities supported by the host */
> > +};
> > +
> > /*
> > * Values for character and character_mask.
> > * These are identical to the values used by H_GET_CPU_CHARACTERISTICS.
> > diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c
> > index 00302399fc37..02b834ebd8d3 100644
> > --- a/arch/powerpc/kvm/powerpc.c
> > +++ b/arch/powerpc/kvm/powerpc.c
> > @@ -697,6 +697,13 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> > }
> > }
> > break;
> > +#if defined(CONFIG_KVM_BOOK3S_HV_POSSIBLE)
> > + case KVM_CAP_PPC_COMPAT_CAPS:
> > + r = 0;
> > + if (kvmhv_on_pseries())
> > + r = 1;
> > + break;
> > +#endif /* CONFIG_KVM_BOOK3S_HV_POSSIBLE */
> > default:
> > r = 0;
> > break;
> > @@ -2463,6 +2470,20 @@ int kvm_arch_vm_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg)
> > r = kvm->arch.kvm_ops->svm_off(kvm);
> > break;
> > }
> > + case KVM_PPC_GET_COMPAT_CAPS: {
> > + struct kvm_ppc_compat_caps host_caps;
> > +
> > + r = -ENOTTY;
> > + memset(&host_caps, 0, sizeof(host_caps));
> > + if (!kvm->arch.kvm_ops->get_compat_cpu_ver)
> > + goto out;
> > +
> > + r = kvm->arch.kvm_ops->get_compat_cpu_ver(&host_caps);
> > + if (!r && copy_to_user(argp, &host_caps,
> > + sizeof(host_caps)))
> As mentioned above please introduce a size field in the structure thats
> being copied to the userspace and use the size field to copy the
> apporiate structure to the userspace. Otherwise a future kernel may
> unintentionally overwrite unintended userspace memory if it happens to
> be using a larger structure size then what VMM knows about.
Sure, I'll add a validation around the structure size.
>
> > + r = -EFAULT;
> > + break;
> > + }
> > default: {
> > struct kvm *kvm = filp->private_data;
> > r = kvm->arch.kvm_ops->arch_vm_ioctl(filp, ioctl, arg);
> > diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> > index 6c8afa2047bf..1788a0068662 100644
> > --- a/include/uapi/linux/kvm.h
> > +++ b/include/uapi/linux/kvm.h
> > @@ -996,6 +996,7 @@ struct kvm_enable_cap {
> > #define KVM_CAP_S390_USER_OPEREXEC 246
> > #define KVM_CAP_S390_KEYOP 247
> > #define KVM_CAP_S390_VSIE_ESAMODE 248
> > +#define KVM_CAP_PPC_COMPAT_CAPS 249
> >
> > struct kvm_irq_routing_irqchip {
> > __u32 irqchip;
> > @@ -1349,6 +1350,9 @@ struct kvm_s390_keyop {
> > #define KVM_GET_DEVICE_ATTR _IOW(KVMIO, 0xe2, struct kvm_device_attr)
> > #define KVM_HAS_DEVICE_ATTR _IOW(KVMIO, 0xe3, struct kvm_device_attr)
> >
> > +/* Available with KVM_CAP_PPC_COMPAT_CAPS */
> > +#define KVM_PPC_GET_COMPAT_CAPS _IOR(KVMIO, 0xe4, struct
> > kvm_ppc_compat_caps)
> Minor: you may want to align the name of the newly introduced kvmppc_ops
> to KVM CAP you are introducing here.
Will do.
Thanks,
Amit
>
> > +
> > /*
> > * ioctls for vcpu fds
> > */
> > --
> > 2.50.1 (Apple Git-155)
> >
> >
>
> --
> Cheers
> ~ Vaibhav
^ permalink raw reply
* Re: [PATCH v5 07/21] nfsd: add callback encoding and decoding linkages for CB_NOTIFY
From: Chuck Lever @ 2026-06-10 15:25 UTC (permalink / raw)
To: Jeff Layton, Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo,
Tom Talpey, Trond Myklebust, Anna Schumaker, Jonathan Corbet,
Shuah Khan
Cc: Steven Rostedt, Alexander Aring, Amir Goldstein, Jan Kara,
Alexander Viro, Christian Brauner, Calum Mackay, linux-kernel,
linux-doc, linux-nfs
In-Reply-To: <fc7d4edb03fbb359746d75942cc4867c280f8c39.camel@kernel.org>
On Wed, Jun 10, 2026, at 11:19 AM, Jeff Layton wrote:
> On Mon, 2026-06-08 at 12:52 -0400, Chuck Lever wrote:
>> > diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c
>> > index 25bbf5b8814d..ea3e7deb06fa 100644
>> > --- a/fs/nfsd/nfs4callback.c
>> > +++ b/fs/nfsd/nfs4callback.c
>> > @@ -865,6 +865,51 @@ static void encode_stateowner(struct xdr_stream
>> > *xdr, struct nfs4_stateowner *so
>> > xdr_encode_opaque(p, so->so_owner.data, so->so_owner.len);
>> > }
>> >
>> > +static void nfs4_xdr_enc_cb_notify(struct rpc_rqst *req,
>> > + struct xdr_stream *xdr,
>> > + const void *data)
>> > +{
>> > + const struct nfsd4_callback *cb = data;
>> > + struct nfs4_cb_compound_hdr hdr = {
>> > + .ident = 0,
>> > + .minorversion = cb->cb_clp->cl_minorversion,
>> > + };
>> > + struct CB_NOTIFY4args args = { };
>> > +
>> > + WARN_ON_ONCE(hdr.minorversion == 0);
>> > +
>> > + encode_cb_compound4args(xdr, &hdr);
>> > + encode_cb_sequence4args(xdr, cb, &hdr);
>> > +
>> > + /*
>> > + * FIXME: get stateid and fh from delegation. Inline the cna_changes
>> > + * buffer, and zero it.
>> > + */
>> > + WARN_ON_ONCE(!xdrgen_encode_CB_NOTIFY4args(xdr, &args));
>> > +
>> > + hdr.nops++;
>> > + encode_cb_nops(&hdr);
>> > +}
>>
>> There are a number of problems with this, but since there are no
>> callers yet, we can let some of those issues stand.
>>
>> What is problematic in the longer-term is that this is a client-side
>> encoder (since this is the server's NFSv4 callback client).
>>
>> xdrgen_encode_CB_NOTIFY4args() is an argument encoder, which is
>> client-side functionality, but it resides in fs/nfsd/nfs4xdr_gen.c,
>> which is server-side. Let's not mix these purposes.
>>
>> I replaced the comment and WARN_ON with this:
>>
>> + xdr_stream_encode_u32(xdr, OP_CB_NOTIFY);
>> +
>> + /* FIXME: encode stateid, fh, and cna_changes from delegation */
>>
>> You can use xdrgen functions for individual data items, but for
>> full argument and response structures, only server-side is supported
>> at the moment. In the later patch that completes this code, I'll cover
>> the other fields, which can be a mix of open code and xdrgen.
>>
>
> The full argument encoder and decoder works just fine. When you say
> "supported" what do you mean, specifically?
"encode argument" is a client-side mechanism
"decode argument" is a server-side mechanism
"encode result" is a server-side mechanism
"decode result" is a client-side mechanism
The reason that matters is that the client-side and server-side
XDR implementation for the top level arguments and results (not
the individual data items) in the kernel have different calling
conventions -- eg, server side wants to see a struct svc_rqst *
> I'd really rather not go back to open-coding the encoders and decoders,
> particularly since CB_NOTIFY has one of the most complex argument
> structures in the protocol.
Go look at how I implemented this in the subsequent patch. You can
use the xdrgen notify4 encoder, that's where all the complexity is.
--
Chuck Lever
^ permalink raw reply
* [PATCH v11 2/2] hwmon: temperature: add support for EMC1812
From: Marius Cristea @ 2026-06-10 15:19 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc, Marius Cristea
In-Reply-To: <20260610-hw_mon-emc1812-v11-0-cef809af5c19@microchip.com>
This is the hwmon driver for Microchip EMC1812/13/14/15/33
Multichannel Low-Voltage Remote Diode Sensor Family.
EMC1812 has one external remote temperature monitoring channel.
EMC1813 has two external remote temperature monitoring channels.
EMC1814 has three external remote temperature monitoring channels,
channels 2 and 3 support anti parallel diode.
EMC1815 has four external remote temperature monitoring channels and
channels 1/2 and 3/4 support anti parallel diode.
EMC1833 has two external remote temperature monitoring channels and
channels 1 and 2 support anti parallel diode.
Resistance Error Correction is supported on channels 1/2 and 3/4.
Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
---
Documentation/hwmon/emc1812.rst | 67 +++
Documentation/hwmon/index.rst | 1 +
MAINTAINERS | 2 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/emc1812.c | 965 ++++++++++++++++++++++++++++++++++++++++
6 files changed, 1047 insertions(+)
diff --git a/Documentation/hwmon/emc1812.rst b/Documentation/hwmon/emc1812.rst
new file mode 100644
index 000000000000..0b4fbcaaea71
--- /dev/null
+++ b/Documentation/hwmon/emc1812.rst
@@ -0,0 +1,67 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+Kernel driver emc1812
+=====================
+
+Supported chips:
+
+ * Microchip EMC1812, EMC1813, EMC1814, EMC1815, EMC1833
+
+ Prefix: 'emc1812'
+
+ Datasheets:
+
+ - https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/EMC1812-3-4-5-33-Data-Sheet-DS20005751.pdf
+
+Author:
+ Marius Cristea <marius.cristea@microchip.com>
+
+
+Description
+-----------
+
+The Microchip EMC181x/33 chips contain up to 4 remote temperature sensors
+and one internal.
+- The EMC1812 is a single channel remote temperature sensor.
+- The EMC1813 and EMC1833 are dual channel remote temperature sensor. The
+remote channels for this selection of devices can support substrate diodes,
+discrete diode-connected transistors or CPU/GPU thermal diodes.
+- The EMC1814 is a three channel remote temperature sensor that supports
+Anti-Parallel Diode (APD) only on one channel. For the channel that does not
+support APD functionality, substrate diodes, discrete diode-connected
+transistors or CPU/GPU thermal diodes are supported. For the channel that
+supports APD, only discrete diode-connected transistors may be implemented.
+However, if APD is disabled on the EMC1814, then the channel that supports
+APD will be functional with substrate diodes, discrete diode-connected
+transistors and CPU/GPU thermal diodes.
+- The EMC1815 is a four channel remote temperature sensor.
+
+The EMC1815 and EMC1833 support APD on all channels. When APD is enabled,
+the channels support only diode-connected transistors. If APD is disabled,
+then the channels will support substrate transistors, discrete diode-connected
+transistors and CPU/GPU thermal diodes.
+
+Note: Disabling APD functionality to implement substrate diodes on devices
+that support APD eliminates the benefit of APD (two diodes on one channel).
+
+The chips implement three limits for each sensor: low (tempX_min), high
+(tempX_max) and critical (tempX_crit). The chips also implement an
+hysteresis mechanism which applies to all limits. The relative difference
+is stored in a single register on the chip, which means that the relative
+difference between the limit and its hysteresis is always the same for
+all three limits.
+
+This implementation detail implies the following:
+
+* When setting a limit, its hysteresis will automatically follow, the
+ difference staying unchanged. For example, if the old critical limit was
+ 80 degrees C, and the hysteresis was 75 degrees C, and you change the
+ critical limit to 90 degrees C, then the hysteresis will automatically
+ change to 85 degrees C.
+* The hysteresis values can't be set independently. We decided to make
+ only tempX_crit_hyst writable, while all other hysteresis attributes
+ are read-only. Setting tempX_crit_hyst writes the difference between
+ tempX_crit_hyst and tempX_crit into the chip, and the same relative
+ hysteresis applies automatically to all other limits.
+* The limits should be set before the hysteresis. At power up the device
+ starts with 10 degree hysteresis.
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index 51a5bdf75b08..a03e97f9a97f 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -69,6 +69,7 @@ Hardware Monitoring Kernel Drivers
ds1621
ds620
emc1403
+ emc1812
emc2103
emc2305
emc6w201
diff --git a/MAINTAINERS b/MAINTAINERS
index 85c236df781e..fcb712549ea6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16651,6 +16651,8 @@ M: Marius Cristea <marius.cristea@microchip.com>
L: linux-hwmon@vger.kernel.org
S: Supported
F: Documentation/devicetree/bindings/hwmon/microchip,emc1812.yaml
+F: Documentation/hwmon/emc1812.rst
+F: drivers/hwmon/emc1812.c
MICROCHIP I2C DRIVER
M: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 2760feb9f83b..3b53572fd8bf 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -2042,6 +2042,17 @@ config SENSORS_EMC1403
Threshold values can be configured using sysfs.
Data from the different diodes are accessible via sysfs.
+config SENSORS_EMC1812
+ tristate "Microchip Technology EMC1812 driver"
+ depends on I2C
+ select REGMAP_I2C
+ help
+ If you say yes here to build support for Microchip Technology's
+ EMC181X/33 Multichannel Low-Voltage Remote Diode Sensor Family.
+
+ This driver can also be built as a module. If so, the module
+ will be called emc1812.
+
config SENSORS_EMC2103
tristate "SMSC EMC2103"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 73b2abdcc6dd..e93e4051e99d 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -73,6 +73,7 @@ obj-$(CONFIG_SENSORS_DRIVETEMP) += drivetemp.o
obj-$(CONFIG_SENSORS_DS620) += ds620.o
obj-$(CONFIG_SENSORS_DS1621) += ds1621.o
obj-$(CONFIG_SENSORS_EMC1403) += emc1403.o
+obj-$(CONFIG_SENSORS_EMC1812) += emc1812.o
obj-$(CONFIG_SENSORS_EMC2103) += emc2103.o
obj-$(CONFIG_SENSORS_EMC2305) += emc2305.o
obj-$(CONFIG_SENSORS_EMC6W201) += emc6w201.o
diff --git a/drivers/hwmon/emc1812.c b/drivers/hwmon/emc1812.c
new file mode 100644
index 000000000000..68575c27d090
--- /dev/null
+++ b/drivers/hwmon/emc1812.c
@@ -0,0 +1,965 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * HWMON driver for Microchip EMC1812/13/14/15/33 Multichannel high-accuracy
+ * 2-wire low-voltage remote diode temperature monitor family.
+ *
+ * Copyright (C) 2026 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Marius Cristea <marius.cristea@microchip.com>
+ *
+ * Datasheet can be found here:
+ * https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/EMC1812-3-4-5-33-Data-Sheet-DS20005751.pdf
+ */
+
+#include <linux/bitfield.h>
+#include <linux/bitops.h>
+#include <linux/bits.h>
+#include <linux/delay.h>
+#include <linux/err.h>
+#include <linux/hwmon.h>
+#include <linux/i2c.h>
+#include <linux/kernel.h>
+#include <linux/math64.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+#include <linux/string.h>
+#include <linux/units.h>
+#include <linux/util_macros.h>
+
+/* EMC1812 Registers Addresses */
+#define EMC1812_STATUS_ADDR 0x02
+#define EMC1812_CONFIG_LO_ADDR 0x03
+
+#define EMC1812_CFG_ADDR 0x09
+#define EMC1812_CONV_ADDR 0x0A
+#define EMC1812_INT_DIODE_HIGH_LIMIT_ADDR 0x0B
+#define EMC1812_INT_DIODE_LOW_LIMIT_ADDR 0x0C
+#define EMC1812_EXT1_HIGH_LIMIT_HIGH_BYTE_ADDR 0x0D
+#define EMC1812_EXT1_LOW_LIMIT_HIGH_BYTE_ADDR 0x0E
+#define EMC1812_ONE_SHOT_ADDR 0x0F
+
+#define EMC1812_EXT1_HIGH_LIMIT_LOW_BYTE_ADDR 0x13
+#define EMC1812_EXT1_LOW_LIMIT_LOW_BYTE_ADDR 0x14
+#define EMC1812_EXT2_HIGH_LIMIT_HIGH_BYTE_ADDR 0x15
+#define EMC1812_EXT2_LOW_LIMIT_HIGH_BYTE_ADDR 0x16
+#define EMC1812_EXT2_HIGH_LIMIT_LOW_BYTE_ADDR 0x17
+#define EMC1812_EXT2_LOW_LIMIT_LOW_BYTE_ADDR 0x18
+#define EMC1812_EXT1_THERM_LIMIT_ADDR 0x19
+#define EMC1812_EXT2_THERM_LIMIT_ADDR 0x1A
+#define EMC1812_EXT_DIODE_FAULT_STATUS_ADDR 0x1B
+
+#define EMC1812_DIODE_FAULT_MASK_ADDR 0x1F
+#define EMC1812_INT_DIODE_THERM_LIMIT_ADDR 0x20
+#define EMC1812_THRM_HYS_ADDR 0x21
+#define EMC1812_CONSEC_ALERT_ADDR 0x22
+
+#define EMC1812_EXT1_BETA_CONFIG_ADDR 0x25
+#define EMC1812_EXT2_BETA_CONFIG_ADDR 0x26
+#define EMC1812_EXT1_IDEALITY_FACTOR_ADDR 0x27
+#define EMC1812_EXT2_IDEALITY_FACTOR_ADDR 0x28
+
+#define EMC1812_EXT3_HIGH_LIMIT_HIGH_BYTE_ADDR 0x2C
+#define EMC1812_EXT3_LOW_LIMIT_HIGH_BYTE_ADDR 0x2D
+#define EMC1812_EXT3_HIGH_LIMIT_LOW_BYTE_ADDR 0x2E
+#define EMC1812_EXT3_LOW_LIMIT_LOW_BYTE_ADDR 0x2F
+#define EMC1812_EXT3_THERM_LIMIT_ADDR 0x30
+#define EMC1812_EXT3_IDEALITY_FACTOR_ADDR 0x31
+
+#define EMC1812_EXT4_HIGH_LIMIT_HIGH_BYTE_ADDR 0x34
+#define EMC1812_EXT4_LOW_LIMIT_HIGH_BYTE_ADDR 0x35
+#define EMC1812_EXT4_HIGH_LIMIT_LOW_BYTE_ADDR 0x36
+#define EMC1812_EXT4_LOW_LIMIT_LOW_BYTE_ADDR 0x37
+#define EMC1812_EXT4_THERM_LIMIT_ADDR 0x38
+#define EMC1812_EXT4_IDEALITY_FACTOR_ADDR 0x39
+#define EMC1812_HIGH_LIMIT_STATUS_ADDR 0x3A
+#define EMC1812_LOW_LIMIT_STATUS_ADDR 0x3B
+#define EMC1812_THERM_LIMIT_STATUS_ADDR 0x3C
+#define EMC1812_ROC_GAIN_ADDR 0x3D
+#define EMC1812_ROC_CONFIG_ADDR 0x3E
+#define EMC1812_ROC_STATUS_ADDR 0x3F
+#define EMC1812_R1_RESH_ADDR 0x40
+#define EMC1812_R1_LIMH_ADDR 0x41
+#define EMC1812_R1_LIML_ADDR 0x42
+#define EMC1812_R1_SMPL_ADDR 0x43
+#define EMC1812_R2_RESH_ADDR 0x44
+#define EMC1812_R2_3_RESL_ADDR 0x45
+#define EMC1812_R2_LIMH_ADDR 0x46
+#define EMC1812_R2_LIML_ADDR 0x47
+#define EMC1812_R2_SMPL_ADDR 0x48
+#define EMC1812_PER_MAXTH_1_ADDR 0x49
+#define EMC1812_PER_MAXT1L_ADDR 0x4A
+#define EMC1812_PER_MAXTH_2_ADDR 0x4B
+#define EMC1812_PER_MAXT2_3L_ADDR 0x4C
+#define EMC1812_GBL_MAXT1H_ADDR 0x4D
+#define EMC1812_GBL_MAXT1L_ADDR 0x4E
+#define EMC1812_GBL_MAXT2H_ADDR 0x4F
+#define EMC1812_GBL_MAXT2L_ADDR 0x50
+#define EMC1812_FILTER_SEL_ADDR 0x51
+
+#define EMC1812_INT_HIGH_BYTE_ADDR 0x60
+#define EMC1812_INT_LOW_BYTE_ADDR 0x61
+#define EMC1812_EXT1_HIGH_BYTE_ADDR 0x62
+#define EMC1812_EXT1_LOW_BYTE_ADDR 0x63
+#define EMC1812_EXT2_HIGH_BYTE_ADDR 0x64
+#define EMC1812_EXT2_LOW_BYTE_ADDR 0x65
+#define EMC1812_EXT3_HIGH_BYTE_ADDR 0x66
+#define EMC1812_EXT3_LOW_BYTE_ADDR 0x67
+#define EMC1812_EXT4_HIGH_BYTE_ADDR 0x68
+#define EMC1812_EXT4_LOW_BYTE_ADDR 0x69
+#define EMC1812_HOTTEST_DIODE_HIGH_BYTE_ADDR 0x6A
+#define EMC1812_HOTTEST_DIODE_LOW_BYTE_ADDR 0x6B
+#define EMC1812_HOTTEST_STATUS_ADDR 0x6C
+#define EMC1812_HOTTEST_CFG_ADDR 0x6D
+
+#define EMC1812_PRODUCT_ID_ADDR 0xFD
+#define EMC1812_MANUFACTURER_ID_ADDR 0xFE
+#define EMC1812_REVISION_ADDR 0xFF
+
+/* EMC1812 Config Bits */
+#define EMC1812_CFG_MSKAL BIT(7)
+#define EMC1812_CFG_RS BIT(6)
+#define EMC1812_CFG_ATTHM BIT(5)
+#define EMC1812_CFG_RECD12 BIT(4)
+#define EMC1812_CFG_RECD34 BIT(3)
+#define EMC1812_CFG_RANGE BIT(2)
+#define EMC1812_CFG_DA_ENA BIT(1)
+#define EMC1812_CFG_APDD BIT(0)
+
+/* EMC1812 Status Bits */
+#define EMC1812_STATUS_ROCF BIT(7)
+#define EMC1812_STATUS_HOTCHG BIT(6)
+#define EMC1812_STATUS_BUSY BIT(5)
+#define EMC1812_STATUS_HIGH BIT(4)
+#define EMC1812_STATUS_LOW BIT(3)
+#define EMC1812_STATUS_FAULT BIT(2)
+#define EMC1812_STATUS_ETHRM BIT(1)
+#define EMC1812_STATUS_ITHRM BIT(0)
+
+#define EMC1812_BETA_LOCK_VAL 0x0F
+
+#define EMC1812_TEMP_CH_ADDR(index) (EMC1812_INT_HIGH_BYTE_ADDR + 2 * (index))
+
+#define EMC1812_FILTER_MASK_LEN 2
+
+#define EMC1812_PID 0x81
+#define EMC1813_PID 0x87
+#define EMC1814_PID 0x84
+#define EMC1815_PID 0x85
+#define EMC1833_PID 0x83
+
+/* The maximum number of channels a member of the family can have */
+#define EMC1812_MAX_NUM_CHANNELS 5
+#define EMC1812_TEMP_OFFSET 64
+
+#define EMC1812_DEFAULT_IDEALITY_FACTOR 0x12
+
+/* Constants and default values */
+#define EMC1812_HIGH_LIMIT_DEFAULT (85 + EMC1812_TEMP_OFFSET)
+
+#define EMC1812_TEMP_MASK (HWMON_T_INPUT | HWMON_T_MIN | HWMON_T_MAX | \
+ HWMON_T_CRIT | HWMON_T_MAX_HYST | HWMON_T_CRIT_HYST | \
+ HWMON_T_MIN_ALARM | HWMON_T_MAX_ALARM | \
+ HWMON_T_CRIT_ALARM | HWMON_T_LABEL)
+
+static const struct hwmon_channel_info * const emc1812_info[] = {
+ HWMON_CHANNEL_INFO(chip, HWMON_C_UPDATE_INTERVAL),
+ HWMON_CHANNEL_INFO(temp,
+ EMC1812_TEMP_MASK,
+ EMC1812_TEMP_MASK | HWMON_T_FAULT,
+ EMC1812_TEMP_MASK | HWMON_T_FAULT,
+ EMC1812_TEMP_MASK | HWMON_T_FAULT,
+ EMC1812_TEMP_MASK | HWMON_T_FAULT),
+ NULL
+};
+
+/**
+ * struct emc1812_features - features of a emc1812 instance
+ * @name: chip's name
+ * @phys_channels: number of physical channels supported by the chip
+ * @has_ext2_beta_reg: the EXT2_BETA register is available on the chip
+ */
+struct emc1812_features {
+ const char *name;
+ u8 phys_channels;
+ bool has_ext2_beta_reg;
+};
+
+static const struct emc1812_features emc1833_chip_config = {
+ .name = "emc1833",
+ .phys_channels = 3,
+ .has_ext2_beta_reg = true,
+};
+
+static const struct emc1812_features emc1812_chip_config = {
+ .name = "emc1812",
+ .phys_channels = 2,
+ .has_ext2_beta_reg = false,
+};
+
+static const struct emc1812_features emc1813_chip_config = {
+ .name = "emc1813",
+ .phys_channels = 3,
+ .has_ext2_beta_reg = true,
+};
+
+static const struct emc1812_features emc1814_chip_config = {
+ .name = "emc1814",
+ .phys_channels = 4,
+ .has_ext2_beta_reg = false,
+};
+
+static const struct emc1812_features emc1815_chip_config = {
+ .name = "emc1815",
+ .phys_channels = 5,
+ .has_ext2_beta_reg = false,
+};
+
+enum emc1812_limit_type {temp_min, temp_max};
+
+static const u8 emc1812_temp_map[] = {
+ [hwmon_temp_min] = temp_min,
+ [hwmon_temp_max] = temp_max,
+};
+
+static const u8 emc1812_ideality_regs[] = {
+ [0] = 0xff,
+ [1] = EMC1812_EXT1_IDEALITY_FACTOR_ADDR,
+ [2] = EMC1812_EXT2_IDEALITY_FACTOR_ADDR,
+ [3] = EMC1812_EXT3_IDEALITY_FACTOR_ADDR,
+ [4] = EMC1812_EXT4_IDEALITY_FACTOR_ADDR,
+};
+
+static const u8 emc1812_temp_crit_regs[] = {
+ [0] = EMC1812_INT_DIODE_THERM_LIMIT_ADDR,
+ [1] = EMC1812_EXT1_THERM_LIMIT_ADDR,
+ [2] = EMC1812_EXT2_THERM_LIMIT_ADDR,
+ [3] = EMC1812_EXT3_THERM_LIMIT_ADDR,
+ [4] = EMC1812_EXT4_THERM_LIMIT_ADDR,
+};
+
+static const u8 emc1812_limit_regs[][2] = {
+ [0] = {
+ [temp_min] = EMC1812_INT_DIODE_LOW_LIMIT_ADDR,
+ [temp_max] = EMC1812_INT_DIODE_HIGH_LIMIT_ADDR,
+ },
+ [1] = {
+ [temp_min] = EMC1812_EXT1_LOW_LIMIT_HIGH_BYTE_ADDR,
+ [temp_max] = EMC1812_EXT1_HIGH_LIMIT_HIGH_BYTE_ADDR,
+ },
+ [2] = {
+ [temp_min] = EMC1812_EXT2_LOW_LIMIT_HIGH_BYTE_ADDR,
+ [temp_max] = EMC1812_EXT2_HIGH_LIMIT_HIGH_BYTE_ADDR,
+ },
+ [3] = {
+ [temp_min] = EMC1812_EXT3_LOW_LIMIT_HIGH_BYTE_ADDR,
+ [temp_max] = EMC1812_EXT3_HIGH_LIMIT_HIGH_BYTE_ADDR,
+ },
+ [4] = {
+ [temp_min] = EMC1812_EXT4_LOW_LIMIT_HIGH_BYTE_ADDR,
+ [temp_max] = EMC1812_EXT4_HIGH_LIMIT_HIGH_BYTE_ADDR,
+ },
+};
+
+static const u8 emc1812_limit_regs_low[][2] = {
+ [0] = {
+ [temp_min] = 0xff,
+ [temp_max] = 0xff,
+ },
+ [1] = {
+ [temp_min] = EMC1812_EXT1_LOW_LIMIT_LOW_BYTE_ADDR,
+ [temp_max] = EMC1812_EXT1_HIGH_LIMIT_LOW_BYTE_ADDR,
+ },
+ [2] = {
+ [temp_min] = EMC1812_EXT2_LOW_LIMIT_LOW_BYTE_ADDR,
+ [temp_max] = EMC1812_EXT2_HIGH_LIMIT_LOW_BYTE_ADDR,
+ },
+ [3] = {
+ [temp_min] = EMC1812_EXT3_LOW_LIMIT_LOW_BYTE_ADDR,
+ [temp_max] = EMC1812_EXT3_HIGH_LIMIT_LOW_BYTE_ADDR,
+ },
+ [4] = {
+ [temp_min] = EMC1812_EXT4_LOW_LIMIT_LOW_BYTE_ADDR,
+ [temp_max] = EMC1812_EXT4_HIGH_LIMIT_LOW_BYTE_ADDR,
+ },
+};
+
+/* Lookup table for temperature conversion times in msec */
+static const u16 emc1812_conv_time[] = {
+ 16000, 8000, 4000, 2000, 1000, 500, 250, 125, 62, 31, 16
+};
+
+/**
+ * struct emc1812_data - information about chip parameters
+ * @labels: labels of the channels
+ * @active_ch_mask: active channels
+ * @chip: pointer to structure holding chip features
+ * @regmap: device register map
+ * @recd34_en: state of Resistance Error Correction (REC) on channels 3 and 4
+ * @recd12_en: state of Resistance Error Correction (REC) on channels 1 and 2
+ * @apdd_en: state of anti-parallel diode mode
+ */
+struct emc1812_data {
+ const char *labels[EMC1812_MAX_NUM_CHANNELS];
+ unsigned long active_ch_mask;
+ const struct emc1812_features *chip;
+ struct regmap *regmap;
+ bool recd34_en;
+ bool recd12_en;
+ bool apdd_en;
+};
+
+/* emc1812 regmap configuration */
+static const struct regmap_range emc1812_regmap_writable_ranges[] = {
+ regmap_reg_range(EMC1812_CFG_ADDR, EMC1812_ONE_SHOT_ADDR),
+ regmap_reg_range(EMC1812_EXT1_HIGH_LIMIT_LOW_BYTE_ADDR, EMC1812_EXT2_THERM_LIMIT_ADDR),
+ regmap_reg_range(EMC1812_DIODE_FAULT_MASK_ADDR, EMC1812_CONSEC_ALERT_ADDR),
+ regmap_reg_range(EMC1812_EXT1_BETA_CONFIG_ADDR, EMC1812_EXT4_IDEALITY_FACTOR_ADDR),
+ regmap_reg_range(EMC1812_ROC_GAIN_ADDR, EMC1812_ROC_CONFIG_ADDR),
+ regmap_reg_range(EMC1812_R1_LIMH_ADDR, EMC1812_R1_SMPL_ADDR),
+ regmap_reg_range(EMC1812_R2_LIMH_ADDR, EMC1812_R2_SMPL_ADDR),
+ regmap_reg_range(EMC1812_FILTER_SEL_ADDR, EMC1812_FILTER_SEL_ADDR),
+ regmap_reg_range(EMC1812_HOTTEST_CFG_ADDR, EMC1812_HOTTEST_CFG_ADDR),
+};
+
+static const struct regmap_access_table emc1812_regmap_wr_table = {
+ .yes_ranges = emc1812_regmap_writable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(emc1812_regmap_writable_ranges),
+};
+
+static const struct regmap_range emc1812_regmap_rd_ranges[] = {
+ regmap_reg_range(EMC1812_STATUS_ADDR, EMC1812_CONFIG_LO_ADDR),
+ regmap_reg_range(EMC1812_CFG_ADDR, EMC1812_ONE_SHOT_ADDR),
+ regmap_reg_range(EMC1812_EXT1_HIGH_LIMIT_LOW_BYTE_ADDR,
+ EMC1812_EXT_DIODE_FAULT_STATUS_ADDR),
+ regmap_reg_range(EMC1812_DIODE_FAULT_MASK_ADDR, EMC1812_CONSEC_ALERT_ADDR),
+ regmap_reg_range(EMC1812_EXT1_BETA_CONFIG_ADDR, EMC1812_FILTER_SEL_ADDR),
+ regmap_reg_range(EMC1812_INT_HIGH_BYTE_ADDR, EMC1812_HOTTEST_CFG_ADDR),
+ regmap_reg_range(EMC1812_PRODUCT_ID_ADDR, EMC1812_REVISION_ADDR),
+};
+
+static const struct regmap_access_table emc1812_regmap_rd_table = {
+ .yes_ranges = emc1812_regmap_rd_ranges,
+ .n_yes_ranges = ARRAY_SIZE(emc1812_regmap_rd_ranges),
+};
+
+static bool emc1812_is_volatile_reg(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case EMC1812_STATUS_ADDR:
+ case EMC1812_EXT_DIODE_FAULT_STATUS_ADDR:
+ case EMC1812_DIODE_FAULT_MASK_ADDR:
+ case EMC1812_EXT1_BETA_CONFIG_ADDR:
+ case EMC1812_EXT2_BETA_CONFIG_ADDR:
+ case EMC1812_HIGH_LIMIT_STATUS_ADDR:
+ case EMC1812_LOW_LIMIT_STATUS_ADDR:
+ case EMC1812_THERM_LIMIT_STATUS_ADDR:
+ case EMC1812_ROC_STATUS_ADDR:
+ case EMC1812_PER_MAXTH_1_ADDR:
+ case EMC1812_PER_MAXT1L_ADDR:
+ case EMC1812_PER_MAXTH_2_ADDR:
+ case EMC1812_PER_MAXT2_3L_ADDR:
+ case EMC1812_GBL_MAXT1H_ADDR:
+ case EMC1812_GBL_MAXT1L_ADDR:
+ case EMC1812_GBL_MAXT2H_ADDR:
+ case EMC1812_GBL_MAXT2L_ADDR:
+ case EMC1812_INT_HIGH_BYTE_ADDR:
+ case EMC1812_INT_LOW_BYTE_ADDR:
+ case EMC1812_EXT1_HIGH_BYTE_ADDR:
+ case EMC1812_EXT1_LOW_BYTE_ADDR:
+ case EMC1812_EXT2_HIGH_BYTE_ADDR:
+ case EMC1812_EXT2_LOW_BYTE_ADDR:
+ case EMC1812_EXT3_HIGH_BYTE_ADDR:
+ case EMC1812_EXT3_LOW_BYTE_ADDR:
+ case EMC1812_EXT4_HIGH_BYTE_ADDR:
+ case EMC1812_EXT4_LOW_BYTE_ADDR:
+ case EMC1812_HOTTEST_DIODE_HIGH_BYTE_ADDR:
+ case EMC1812_HOTTEST_DIODE_LOW_BYTE_ADDR:
+ case EMC1812_HOTTEST_STATUS_ADDR:
+ return true;
+ default:
+ return false;
+ }
+}
+
+static const struct regmap_config emc1812_regmap_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .rd_table = &emc1812_regmap_rd_table,
+ .wr_table = &emc1812_regmap_wr_table,
+ .volatile_reg = emc1812_is_volatile_reg,
+ .max_register = EMC1812_REVISION_ADDR,
+ .cache_type = REGCACHE_MAPLE,
+};
+
+static umode_t emc1812_is_visible(const void *_data, enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct emc1812_data *data = _data;
+
+ switch (type) {
+ case hwmon_temp:
+ /* Don't show channels which are not enabled */
+ if (!(data->active_ch_mask & BIT(channel)))
+ return 0;
+
+ switch (attr) {
+ case hwmon_temp_min:
+ case hwmon_temp_max:
+ case hwmon_temp_crit:
+ case hwmon_temp_crit_hyst:
+ return 0644;
+ case hwmon_temp_crit_alarm:
+ case hwmon_temp_input:
+ case hwmon_temp_fault:
+ case hwmon_temp_max_alarm:
+ case hwmon_temp_max_hyst:
+ case hwmon_temp_min_alarm:
+ return 0444;
+ case hwmon_temp_label:
+ if (data->labels[channel])
+ return 0444;
+ return 0;
+ default:
+ return 0;
+ }
+ case hwmon_chip:
+ switch (attr) {
+ case hwmon_chip_update_interval:
+ return 0644;
+ default:
+ return 0;
+ }
+ default:
+ return 0;
+ }
+};
+
+static int emc1812_get_temp(struct emc1812_data *data, int channel, long *val)
+{
+ __be16 tmp_be16;
+ int ret;
+
+ ret = regmap_bulk_read(data->regmap, EMC1812_TEMP_CH_ADDR(channel),
+ &tmp_be16, sizeof(tmp_be16));
+ if (ret)
+ return ret;
+
+ /* Range is always -64 to 191.875°C */
+ *val = ((be16_to_cpu(tmp_be16) >> 5) - (EMC1812_TEMP_OFFSET << 3)) * 125;
+
+ return 0;
+}
+
+static int emc1812_get_crit_limit_temp(struct emc1812_data *data, int channel, long *val)
+{
+ unsigned int tmp;
+ int ret;
+
+ /* Critical register is 8bits long and keeps only integer part of temperature */
+ ret = regmap_read(data->regmap, emc1812_temp_crit_regs[channel], &tmp);
+ if (ret)
+ return ret;
+
+ *val = tmp;
+ /* Range is always -64 to 191°C */
+ *val = (*val - EMC1812_TEMP_OFFSET) * 1000;
+
+ return 0;
+}
+
+static int emc1812_get_limit_temp(struct emc1812_data *data, int ch,
+ enum emc1812_limit_type type, long *val)
+{
+ unsigned int regvalh;
+ unsigned int regvall = 0;
+ int ret;
+
+ ret = regmap_read(data->regmap, emc1812_limit_regs[ch][type], ®valh);
+ if (ret < 0)
+ return ret;
+
+ if (ch) {
+ ret = regmap_read(data->regmap, emc1812_limit_regs_low[ch][type], ®vall);
+ if (ret < 0)
+ return ret;
+ }
+
+ /* Range is always -64 to 191.875°C */
+ *val = ((regvalh << 3) | (regvall >> 5));
+ *val = (*val - (EMC1812_TEMP_OFFSET << 3)) * 125;
+
+ return 0;
+}
+
+static int emc1812_read_reg(struct device *dev, struct emc1812_data *data, u32 attr,
+ int channel, long *val)
+{
+ unsigned int hyst;
+ int ret;
+
+ switch (attr) {
+ case hwmon_temp_min:
+ case hwmon_temp_max:
+ return emc1812_get_limit_temp(data, channel, emc1812_temp_map[attr], val);
+ case hwmon_temp_crit:
+ return emc1812_get_crit_limit_temp(data, channel, val);
+ case hwmon_temp_input:
+ return emc1812_get_temp(data, channel, val);
+ case hwmon_temp_max_hyst:
+ ret = emc1812_get_limit_temp(data, channel, temp_max, val);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_read(data->regmap, EMC1812_THRM_HYS_ADDR, &hyst);
+ if (ret < 0)
+ return ret;
+
+ *val -= (long)hyst * 1000;
+
+ return 0;
+ case hwmon_temp_crit_hyst:
+ ret = emc1812_get_crit_limit_temp(data, channel, val);
+ if (ret < 0)
+ return ret;
+
+ ret = regmap_read(data->regmap, EMC1812_THRM_HYS_ADDR, &hyst);
+ if (ret < 0)
+ return ret;
+
+ *val -= (long)hyst * 1000;
+
+ return 0;
+ case hwmon_temp_min_alarm:
+ *val = regmap_test_bits(data->regmap, EMC1812_LOW_LIMIT_STATUS_ADDR,
+ BIT(channel));
+ if (*val < 0)
+ return *val;
+
+ return 0;
+ case hwmon_temp_max_alarm:
+ *val = regmap_test_bits(data->regmap, EMC1812_HIGH_LIMIT_STATUS_ADDR,
+ BIT(channel));
+ if (*val < 0)
+ return *val;
+
+ return 0;
+ case hwmon_temp_crit_alarm:
+ *val = regmap_test_bits(data->regmap, EMC1812_THERM_LIMIT_STATUS_ADDR,
+ BIT(channel));
+ if (*val < 0)
+ return *val;
+
+ return 0;
+ case hwmon_temp_fault:
+ *val = regmap_test_bits(data->regmap, EMC1812_EXT_DIODE_FAULT_STATUS_ADDR,
+ BIT(channel));
+ if (*val < 0)
+ return *val;
+
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int emc1812_read(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long *val)
+{
+ struct emc1812_data *data = dev_get_drvdata(dev);
+ unsigned int convrate;
+ int ret;
+
+ switch (type) {
+ case hwmon_temp:
+ return emc1812_read_reg(dev, data, attr, channel, val);
+ case hwmon_chip:
+ switch (attr) {
+ case hwmon_chip_update_interval:
+ ret = regmap_read(data->regmap, EMC1812_CONV_ADDR, &convrate);
+ if (ret < 0)
+ return ret;
+
+ if (convrate > 10)
+ convrate = 4;
+
+ *val = DIV_ROUND_CLOSEST(16000, 1 << convrate);
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int emc1812_read_string(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, const char **str)
+{
+ struct emc1812_data *data = dev_get_drvdata(dev);
+
+ if (channel >= data->chip->phys_channels)
+ return -EOPNOTSUPP;
+
+ switch (type) {
+ case hwmon_temp:
+ switch (attr) {
+ case hwmon_temp_label:
+ *str = data->labels[channel];
+ return 0;
+ default:
+ return -EOPNOTSUPP;
+ }
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int emc1812_set_hyst(struct emc1812_data *data, int channel, int val)
+{
+ unsigned int limit;
+ int hyst, ret;
+
+ /* Critical register is 8bits long and keeps only integer part of temperature */
+ ret = regmap_read(data->regmap, emc1812_temp_crit_regs[channel], &limit);
+ if (ret)
+ return ret;
+
+ hyst = clamp_val((int)limit - val, 0, 255);
+
+ ret = regmap_write(data->regmap, EMC1812_THRM_HYS_ADDR, hyst);
+
+ return ret;
+}
+
+static int emc1812_set_temp(struct emc1812_data *data, int channel,
+ enum emc1812_limit_type map, int val)
+{
+ unsigned int valh, vall;
+ u8 regh, regl;
+ int ret;
+
+ regh = emc1812_limit_regs[channel][map];
+ regl = emc1812_limit_regs_low[channel][map];
+
+ if (channel) {
+ val = DIV_ROUND_CLOSEST(val, 125);
+ valh = (val >> 3) & 0xff;
+ vall = (val & 0x07) << 5;
+ } else {
+ /* Temperature limit for internal channel is stored on 8bits */
+ valh = DIV_ROUND_CLOSEST(val, 1000);
+ valh = clamp_val(valh, 0, 255);
+ }
+
+ ret = regmap_write(data->regmap, regh, valh);
+ if (ret < 0)
+ return ret;
+
+ if (channel)
+ ret = regmap_write(data->regmap, regl, vall);
+
+ return ret;
+}
+
+static int emc1812_write(struct device *dev, enum hwmon_sensor_types type, u32 attr,
+ int channel, long val)
+{
+ struct emc1812_data *data = dev_get_drvdata(dev);
+ unsigned int interval, tmp;
+
+ switch (type) {
+ case hwmon_temp:
+ /* Range should be -64000 to 191875°C + (EMC1812_TEMP_OFFSET * 1000) */
+ val = clamp_val(val, -64000, 191875);
+ val = val + (EMC1812_TEMP_OFFSET * 1000);
+
+ switch (attr) {
+ case hwmon_temp_min:
+ case hwmon_temp_max:
+ return emc1812_set_temp(data, channel, emc1812_temp_map[attr], val);
+ case hwmon_temp_crit:
+ /* Critical temperature limit is stored on 8bits */
+ val = DIV_ROUND_CLOSEST(val, 1000);
+ tmp = clamp_val(val, 0, 255);
+ return regmap_write(data->regmap, emc1812_temp_crit_regs[channel], tmp);
+ case hwmon_temp_crit_hyst:
+ /* Critical temperature hysteresis is stored on 8bits */
+ val = DIV_ROUND_CLOSEST(val, 1000);
+ tmp = clamp_val(val, 0, 255);
+ return emc1812_set_hyst(data, channel, tmp);
+ default:
+ return -EOPNOTSUPP;
+ }
+ case hwmon_chip:
+ switch (attr) {
+ case hwmon_chip_update_interval:
+ interval = clamp_val(val, 0, 16000);
+ tmp = find_closest_descending(interval, emc1812_conv_time,
+ ARRAY_SIZE(emc1812_conv_time));
+ return regmap_write(data->regmap, EMC1812_CONV_ADDR, tmp);
+ default:
+ return -EOPNOTSUPP;
+ }
+ default:
+ return -EOPNOTSUPP;
+ }
+}
+
+static int emc1812_init(struct emc1812_data *priv)
+{
+ int i, ret;
+ u8 val;
+
+ ret = regmap_write(priv->regmap, EMC1812_THRM_HYS_ADDR, 0x0A);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(priv->regmap, EMC1812_CONSEC_ALERT_ADDR, 0x70);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(priv->regmap, EMC1812_FILTER_SEL_ADDR, 0);
+ if (ret)
+ return ret;
+
+ ret = regmap_write(priv->regmap, EMC1812_HOTTEST_CFG_ADDR, 0);
+ if (ret)
+ return ret;
+
+ /* Enables the beta compensation factor auto-detection function for beta1 and beta2 */
+ ret = regmap_write(priv->regmap, EMC1812_EXT1_BETA_CONFIG_ADDR,
+ EMC1812_BETA_LOCK_VAL);
+ if (ret)
+ return ret;
+
+ if (priv->chip->has_ext2_beta_reg) {
+ ret = regmap_write(priv->regmap, EMC1812_EXT2_BETA_CONFIG_ADDR,
+ EMC1812_BETA_LOCK_VAL);
+ if (ret)
+ return ret;
+ }
+
+ for (i = 0; i < priv->chip->phys_channels; i++) {
+ if (!test_bit(i, &priv->active_ch_mask))
+ continue;
+
+ /* Update the max temperature limit for extended temperature range. */
+ ret = emc1812_set_temp(priv, i, emc1812_temp_map[hwmon_temp_max],
+ EMC1812_HIGH_LIMIT_DEFAULT * 1000);
+ if (ret)
+ return ret;
+
+ /* Update the critical temperature limit for extended temperature range. */
+ ret = regmap_write(priv->regmap, emc1812_temp_crit_regs[i],
+ EMC1812_HIGH_LIMIT_DEFAULT);
+ if (ret)
+ return ret;
+
+ /* Set the ideality factor */
+ if (i > 0) {
+ ret = regmap_write(priv->regmap, emc1812_ideality_regs[i],
+ EMC1812_DEFAULT_IDEALITY_FACTOR);
+ if (ret)
+ return ret;
+ }
+ }
+
+ /*
+ * Set default values in registers. APDD, RECD12 and RECD34 are active on 0.
+ * Set the device to be in Run (Active) state and converting on all
+ * channels.
+ * Don't change conversion rate. After reset, default is 4 conversions/seconds.
+ * The temperature measurement range is -64°C to +191.875°C.
+ * Set ALERT/THERM2 pin to be in comparator mode (When the ALERT/THERM2 pin is
+ * asserted in comparator mode, the corresponding High Limit Status bits are set.
+ * Reading these bits does not clear them until the ALERT/THERM2 pin is deasserted.
+ * Once the ALERT/THERM2 pin is deasserted, the status bits are automatically
+ * cleared.).
+ */
+ val = FIELD_PREP(EMC1812_CFG_MSKAL, 0) |
+ FIELD_PREP(EMC1812_CFG_RS, 0) |
+ FIELD_PREP(EMC1812_CFG_ATTHM, 1) |
+ FIELD_PREP(EMC1812_CFG_RECD12, !priv->recd12_en) |
+ FIELD_PREP(EMC1812_CFG_RECD34, !priv->recd34_en) |
+ FIELD_PREP(EMC1812_CFG_RANGE, 1) |
+ FIELD_PREP(EMC1812_CFG_DA_ENA, 0) |
+ FIELD_PREP(EMC1812_CFG_APDD, !priv->apdd_en);
+
+ return regmap_write(priv->regmap, EMC1812_CFG_ADDR, val);
+}
+
+static int emc1812_parse_fw_config(struct emc1812_data *data, struct device *dev)
+{
+ unsigned int reg_nr = 0;
+ int ret;
+
+ /* To be able to load the driver in case we don't have device tree */
+ if (!dev_fwnode(dev)) {
+ data->active_ch_mask = BIT(data->chip->phys_channels) - 1;
+ return 0;
+ }
+
+ data->apdd_en = device_property_read_bool(dev, "microchip,enable-anti-parallel");
+ data->recd12_en = device_property_read_bool(dev, "microchip,parasitic-res-on-channel1-2");
+ data->recd34_en = device_property_read_bool(dev, "microchip,parasitic-res-on-channel3-4");
+
+ /* Internal temperature channel is always active */
+ data->labels[reg_nr] = "internal_diode";
+ set_bit(reg_nr, &data->active_ch_mask);
+
+ device_for_each_child_node_scoped(dev, child) {
+ ret = fwnode_property_read_u32(child, "reg", ®_nr);
+ if (ret || reg_nr >= data->chip->phys_channels)
+ return dev_err_probe(dev, -EINVAL,
+ "The index is higher then the chip supports\n");
+ /* Mark channel as active */
+ set_bit(reg_nr, &data->active_ch_mask);
+
+ fwnode_property_read_string(child, "label", &data->labels[reg_nr]);
+ }
+
+ return 0;
+}
+
+static int emc1812_chip_identify(struct emc1812_data *data, struct i2c_client *client)
+{
+ const struct emc1812_features *chip;
+ struct device *dev = &client->dev;
+ unsigned int tmp;
+ int ret;
+
+ ret = regmap_read(data->regmap, EMC1812_PRODUCT_ID_ADDR, &tmp);
+ if (ret)
+ return ret;
+
+ switch (tmp) {
+ case EMC1812_PID:
+ data->chip = &emc1812_chip_config;
+ break;
+ case EMC1813_PID:
+ data->chip = &emc1813_chip_config;
+ break;
+ case EMC1814_PID:
+ data->chip = &emc1814_chip_config;
+ break;
+ case EMC1815_PID:
+ data->chip = &emc1815_chip_config;
+ break;
+ case EMC1833_PID:
+ data->chip = &emc1833_chip_config;
+ break;
+ default:
+ /*
+ * If failed to identify the hardware based on internal registers,
+ * try using fallback compatible in device tree to deal with some
+ * newer part number.
+ */
+ chip = i2c_get_match_data(client);
+ if (!chip)
+ return -ENODEV;
+
+ dev_warn(dev, "Unrecognized hardware ID 0x%x, using %s from devicetree data\n",
+ tmp, chip->name);
+
+ data->chip = chip;
+
+ return 0;
+ }
+
+ return 0;
+}
+
+static const struct hwmon_ops emc1812_ops = {
+ .is_visible = emc1812_is_visible,
+ .read = emc1812_read,
+ .read_string = emc1812_read_string,
+ .write = emc1812_write,
+};
+
+static const struct hwmon_chip_info emc1812_chip_info = {
+ .ops = &emc1812_ops,
+ .info = emc1812_info,
+};
+
+static int emc1812_probe(struct i2c_client *client)
+{
+ struct device *dev = &client->dev;
+ struct emc1812_data *data;
+ struct device *hwmon_dev;
+ int ret;
+
+ data = devm_kzalloc(dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ data->regmap = devm_regmap_init_i2c(client, &emc1812_regmap_config);
+ if (IS_ERR(data->regmap))
+ return dev_err_probe(dev, PTR_ERR(data->regmap),
+ "Cannot initialize register map\n");
+
+ ret = emc1812_chip_identify(data, client);
+ if (ret)
+ return dev_err_probe(dev, ret, "Chip identification fails\n");
+
+ ret = emc1812_parse_fw_config(data, dev);
+ if (ret)
+ return ret;
+
+ ret = emc1812_init(data);
+ if (ret)
+ return dev_err_probe(dev, ret, "Cannot initialize device\n");
+
+ hwmon_dev = devm_hwmon_device_register_with_info(dev, client->name, data,
+ &emc1812_chip_info, NULL);
+
+ return PTR_ERR_OR_ZERO(hwmon_dev);
+}
+
+static const struct i2c_device_id emc1812_id[] = {
+ { .name = "emc1812", .driver_data = (kernel_ulong_t)&emc1812_chip_config },
+ { .name = "emc1813", .driver_data = (kernel_ulong_t)&emc1813_chip_config },
+ { .name = "emc1814", .driver_data = (kernel_ulong_t)&emc1814_chip_config },
+ { .name = "emc1815", .driver_data = (kernel_ulong_t)&emc1815_chip_config },
+ { .name = "emc1833", .driver_data = (kernel_ulong_t)&emc1833_chip_config },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, emc1812_id);
+
+static const struct of_device_id emc1812_of_match[] = {
+ {
+ .compatible = "microchip,emc1812",
+ .data = &emc1812_chip_config
+ },
+ {
+ .compatible = "microchip,emc1813",
+ .data = &emc1813_chip_config
+ },
+ {
+ .compatible = "microchip,emc1814",
+ .data = &emc1814_chip_config
+ },
+ {
+ .compatible = "microchip,emc1815",
+ .data = &emc1815_chip_config
+ },
+ {
+ .compatible = "microchip,emc1833",
+ .data = &emc1833_chip_config
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, emc1812_of_match);
+
+static struct i2c_driver emc1812_driver = {
+ .driver = {
+ .name = "emc1812",
+ .of_match_table = emc1812_of_match,
+ },
+ .probe = emc1812_probe,
+ .id_table = emc1812_id,
+};
+module_i2c_driver(emc1812_driver);
+
+MODULE_AUTHOR("Marius Cristea <marius.cristea@microchip.com>");
+MODULE_DESCRIPTION("EMC1812/13/14/15/33 high-accuracy remote diode temperature monitor Driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v11 1/2] dt-bindings: hwmon: temperature: add support for EMC1812
From: Marius Cristea @ 2026-06-10 15:19 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc, Marius Cristea
In-Reply-To: <20260610-hw_mon-emc1812-v11-0-cef809af5c19@microchip.com>
This is the devicetree schema for Microchip EMC1812/13/14/15/33
Multichannel Low-Voltage Remote Diode Sensor Family. It also
updates the MAINTAINERS file to include the new driver.
EMC1812 has one external remote temperature monitoring channel.
EMC1813 has two external remote temperature monitoring channels.
EMC1814 has three external remote temperature monitoring channels and
channels 2 and 3 support anti parallel diode.
EMC1815 has four external remote temperature monitoring channels and
channels 1/2 and 3/4 support anti parallel diode.
EMC1833 has two external remote temperature monitoring channels and
channels 1 and 2 support anti parallel diode.
Resistance Error Correction is supported on channels 1/2 and 3/4.
Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
---
.../bindings/hwmon/microchip,emc1812.yaml | 193 +++++++++++++++++++++
MAINTAINERS | 6 +
2 files changed, 199 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/microchip,emc1812.yaml b/Documentation/devicetree/bindings/hwmon/microchip,emc1812.yaml
new file mode 100644
index 000000000000..1a273621db82
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/microchip,emc1812.yaml
@@ -0,0 +1,193 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/microchip,emc1812.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip EMC1812/13/14/15/33 multichannel temperature sensor
+
+maintainers:
+ - Marius Cristea <marius.cristea@microchip.com>
+
+description: |
+ The Microchip EMC1812/13/14/15/33 is a high-accuracy 2-wire multichannel
+ low-voltage remote diode temperature monitor.
+
+ The datasheet can be found here:
+ https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/EMC1812-3-4-5-33-Data-Sheet-DS20005751.pdf
+
+ EMC1812 has one external remote temperature monitoring channel
+ EMC1813 has two external remote temperature monitoring channels
+ EMC1814 has three external remote temperature monitoring channels and
+ channels 2 and 3 support anti parallel diode
+ EMC1815 has four external remote temperature monitoring channels and
+ channels 1/2 and 3/4 support anti parallel diode
+ EMC1833 has two external remote temperature monitoring channels and
+ channels 1 and 2 support anti parallel diode
+
+properties:
+ compatible:
+ enum:
+ - microchip,emc1812
+ - microchip,emc1813
+ - microchip,emc1814
+ - microchip,emc1815
+ - microchip,emc1833
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ items:
+ - description: alert-therm2 asserts when the ALERT limit is exceeded.
+ - description: therm-addr asserts when the THERM limit is exceeded.
+ minItems: 1
+
+ interrupt-names:
+ items:
+ - const: alert-therm2
+ - const: therm-addr
+ minItems: 1
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ microchip,enable-anti-parallel:
+ description:
+ Enable anti-parallel diode mode operation. EMC1814, EMC1815 and EMC1833
+ support reading two external diodes in anti-parallel connection on the
+ same set of pins. Disabling APD functionality to implement substrate
+ diodes on devices that support APD eliminates the benefit of APD
+ (two diodes on one channel).
+ type: boolean
+
+ microchip,parasitic-res-on-channel1-2:
+ description:
+ Indicates that the chip and the diodes/transistors are sufficiently
+ far apart that a parasitic resistance is added to the wires, which can
+ affect the measurements. Due to the availability of only a single
+ configuration bit in hardware, channels 1 and 2 are affected together.
+ If channel 2 is not available in hardware, this setting affects only
+ channel 1.
+ type: boolean
+
+ microchip,parasitic-res-on-channel3-4:
+ description:
+ Indicates that the chip and the diodes/transistors are sufficiently
+ far apart that a parasitic resistance is added to the wires, which can
+ affect the measurements. Due to the availability of only a single
+ configuration bit in hardware, channels 3 and 4 are affected together.
+ If channel 4 is not available in hardware, this setting affects only
+ channel 3.
+ type: boolean
+
+ vdd-supply: true
+
+patternProperties:
+ "^channel@[0-4]$":
+ description: |
+ Represents the temperature channels.
+ 0: Internal sensor
+ 1-4: External remote diodes
+ type: object
+
+ properties:
+ reg:
+ maxItems: 1
+
+ label:
+ description: Unique name to identify which channel this is.
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+
+allOf:
+ # EMC1812: 1 Internal, 1 External Channels, No APD,
+ # parasitic-res-on-channel1-2: for channel 1
+ - if:
+ properties:
+ compatible:
+ const: microchip,emc1812
+ then:
+ properties:
+ microchip,enable-anti-parallel: false
+ microchip,parasitic-res-on-channel3-4: false
+ patternProperties:
+ "^channel@[2-4]$": false
+
+ # EMC1813: 1 Internal, 2 External Channels, No APD,
+ # parasitic-res-on-channel1-2: on both channel 1 & 2
+ - if:
+ properties:
+ compatible:
+ const: microchip,emc1813
+ then:
+ properties:
+ microchip,enable-anti-parallel: false
+ microchip,parasitic-res-on-channel3-4: false
+ patternProperties:
+ "^channel@[3-4]$": false
+
+ # EMC1833: 1 Internal, 2 External Channels, Supports APD,
+ # parasitic-res-on-channel1-2: on both channel 1 & 2
+ - if:
+ properties:
+ compatible:
+ const: microchip,emc1833
+ then:
+ properties:
+ microchip,parasitic-res-on-channel3-4: false
+ patternProperties:
+ "^channel@[3-4]$": false
+
+ # EMC1814: 1 Internal, 3 External Channels, Supports APD,
+ # parasitic-res-on-channel1-2: on both channel 1 & 2
+ # parasitic-res-on-channel3-4: for channel 3
+ - if:
+ properties:
+ compatible:
+ const: microchip,emc1814
+ then:
+ properties:
+ channel@4: false
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ temperature-sensor@4c {
+ compatible = "microchip,emc1813";
+ reg = <0x4c>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ microchip,parasitic-res-on-channel1-2;
+
+ vdd-supply = <&vdd>;
+
+ channel@1 {
+ reg = <1>;
+ label = "External CH1 Temperature";
+ };
+
+ channel@2 {
+ reg = <2>;
+ label = "External CH2 Temperature";
+ };
+ };
+ };
diff --git a/MAINTAINERS b/MAINTAINERS
index 6d7b697bfdba..85c236df781e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16646,6 +16646,12 @@ S: Supported
F: Documentation/devicetree/bindings/interrupt-controller/microchip,sama7g5-eic.yaml
F: drivers/irqchip/irq-mchp-eic.c
+MICROCHIP EMC1812 DRIVER
+M: Marius Cristea <marius.cristea@microchip.com>
+L: linux-hwmon@vger.kernel.org
+S: Supported
+F: Documentation/devicetree/bindings/hwmon/microchip,emc1812.yaml
+
MICROCHIP I2C DRIVER
M: Codrin Ciubotariu <codrin.ciubotariu@microchip.com>
L: linux-i2c@vger.kernel.org
--
2.53.0
^ permalink raw reply related
* [PATCH v11 0/2] Add support for Microchip EMC1812
From: Marius Cristea @ 2026-06-10 15:19 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet
Cc: linux-hwmon, devicetree, linux-kernel, linux-doc, Marius Cristea
This is the hwmon driver for EMC1812/13/14/15/33 multichannel Low-Voltage
Remote Diode Sensor Family. The chips in the family have one internal
and different numbers of external channels, ranging from 1 (EMC1812) to
4 channels (EMC1815).
Reading diodes in anti-parallel connection is supported by EMC1814, EMC1815
and EMC1833.
Signed-off-by: Marius Cristea <marius.cristea@microchip.com>
---
Changes in v11:
- remove unnecessary check for channels which are not physically available
- fix pointer signedness mismatch warning
- fix off-by-one misalignment when setting IDEALITY_FACTOR
- update the max temperature and critical temperature limit to match the
extended temperature range
- Link to v10: https://lore.kernel.org/r/20260429-hw_mon-emc1812-v10-0-a8ca1d779502@microchip.com
Changes in v10:
- made comments more clear into the devicetree binding
- allow channel 0 (internal channel) into devicetree binding
- allow the default name for Channel 0 to be overridden by the Device Tree property
- translate temperature limits to support the hardware's extended temperature range
- update channel count validation to properly account for the internal channel
- return -EOPNOTSUPP if channel is greater than or equal to phys_channels
- Link to v9: https://lore.kernel.org/r/20260403-hw_mon-emc1812-v9-0-1a798f31cf2e@microchip.com
Changes in v9:
- improve the wording in the Documentation/hwmon/emc1812.rst file
- add const to variables in the driver
- initialize the EXT2_BETA_CONFIG only for the pats that support it
- update the writeble regmap table to exclude read-only registers
- Link to v8: https://lore.kernel.org/r/20260310-hw_mon-emc1812-v8-0-bc155727e0d2@microchip.com
Changes in v8:
- remove "address scan" from emc1812.rst documentation
- change the second dimension of emc1812_limit_regs_low[][] to 2
- clamp input value before doing math on it to avoid overflow
- use rounding instead of truncation for 8 bits limit registers
- fix misleading comment when HW ID is not recognized
- Link to v7: https://lore.kernel.org/r/20260223-hw_mon-emc1812-v7-0-51e2676f4e20@microchip.com
Changes in v7:
- driver
- fix an overflow emc1812_set_hyst
- remove unused parameter in emc1812_set_temp
- devicetree binding:
- remove unneeded restrictions not to bloating the binding
- Link to v6: https://lore.kernel.org/r/20260212-hw_mon-emc1812-v6-0-e37e9b38d898@microchip.com
Changes in v6:
- driver
- fix an overflow when writing more then 191875 to limits stored on 8
bits register
- remove "i2c_set_clientdata" from probe
- fix discrepancy where writing 16ms and reading it back returns 15ms
at update interval
- skip setting the ideality factor for channels that are not available
on the device
- devicetree binding:
- change the way interrupts are described/used
- add "microchip,enable-anti-parallel"
- rewrite "allOf" section to be more clear
- Link to v5: https://lore.kernel.org/r/20260205-hw_mon-emc1812-v5-0-232835aefe8f@microchip.com
Changes in v5:
- fix calculation in emc1812_get_limit_temp
- use i2c_get_match_data cover the case when the driver is instantiated
via I2C ID table.
- replace dev_info with dev_warn
- remove some unnecessary truncation on 8 bits
- remove clamping when reading the temerature with hyst
- not change the conversion rate at probe time
- use a generic define to remove duplicate channel_info entries
- Link to v4: https://lore.kernel.org/r/20260127-hw_mon-emc1812-v4-0-6bf636b54847@microchip.com
Changes in v4:
- fix file permissions for read only properties
- fix calculation when the limits are written
- remove the temp_min_hyst because the part doesn't support it
- Link to v3: https://lore.kernel.org/r/20251218-hw_mon-emc1812-v3-0-a123ada7b859@microchip.com
Changes in v3:
- remove mesages that are not helpfull
- fix an issue related to NULL labels
- fix sign/unsign calculation
- replace E2BIG with EINVAL
- use BIT() to create mask
- Link to v2: https://lore.kernel.org/r/20251121-hw_mon-emc1812-v2-0-5b2070f8b778@microchip.com
Changes in v2:
- update the interrupt section from yaml file
- update index.rst
- remove fault condition from internal sensor
- remove unused members from structures
- update the driver to work on systems without device tree or
firmware nodes
- add missing include files
- make NULL labels to be not visible
- corect sign/unsign calculations
- corect possible underflow for limits
- Link to v1: https://lore.kernel.org/r/20251029-hw_mon-emc1812-v1-0-be4fd8af016a@microchip.com
---
Marius Cristea (2):
dt-bindings: hwmon: temperature: add support for EMC1812
hwmon: temperature: add support for EMC1812
.../bindings/hwmon/microchip,emc1812.yaml | 193 +++++
Documentation/hwmon/emc1812.rst | 67 ++
Documentation/hwmon/index.rst | 1 +
MAINTAINERS | 8 +
drivers/hwmon/Kconfig | 11 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/emc1812.c | 965 +++++++++++++++++++++
7 files changed, 1246 insertions(+)
---
base-commit: d2b2fea3503e5e12b2e28784152937e48bcca6ff
change-id: 20251002-hw_mon-emc1812-f1b806487d10
Best regards,
--
Marius Cristea <marius.cristea@microchip.com>
^ permalink raw reply
* Re: [PATCH v5 07/21] nfsd: add callback encoding and decoding linkages for CB_NOTIFY
From: Jeff Layton @ 2026-06-10 15:19 UTC (permalink / raw)
To: Chuck Lever, Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo,
Tom Talpey, Trond Myklebust, Anna Schumaker, Jonathan Corbet,
Shuah Khan
Cc: Steven Rostedt, Alexander Aring, Amir Goldstein, Jan Kara,
Alexander Viro, Christian Brauner, Calum Mackay, linux-kernel,
linux-doc, linux-nfs
In-Reply-To: <35918046-66e3-4361-adc3-bce328ce9821@app.fastmail.com>
On Mon, 2026-06-08 at 12:52 -0400, Chuck Lever wrote:
>
> On Fri, May 22, 2026, at 3:42 PM, Jeff Layton wrote:
> > Add routines for encoding and decoding CB_NOTIFY messages. These call
> > into the code generated by xdrgen to do the actual encoding and
> > decoding.
>
> The commit message needs to explain that the encoder is not yet functional.
> Something like: "The encoder is a stub; payload encoding (stateid, fh, and
> cna_changes) is deferred."
>
Ok.
>
> > diff --git a/fs/nfsd/nfs4callback.c b/fs/nfsd/nfs4callback.c
> > index 25bbf5b8814d..ea3e7deb06fa 100644
> > --- a/fs/nfsd/nfs4callback.c
> > +++ b/fs/nfsd/nfs4callback.c
> > @@ -865,6 +865,51 @@ static void encode_stateowner(struct xdr_stream
> > *xdr, struct nfs4_stateowner *so
> > xdr_encode_opaque(p, so->so_owner.data, so->so_owner.len);
> > }
> >
> > +static void nfs4_xdr_enc_cb_notify(struct rpc_rqst *req,
> > + struct xdr_stream *xdr,
> > + const void *data)
> > +{
> > + const struct nfsd4_callback *cb = data;
> > + struct nfs4_cb_compound_hdr hdr = {
> > + .ident = 0,
> > + .minorversion = cb->cb_clp->cl_minorversion,
> > + };
> > + struct CB_NOTIFY4args args = { };
> > +
> > + WARN_ON_ONCE(hdr.minorversion == 0);
> > +
> > + encode_cb_compound4args(xdr, &hdr);
> > + encode_cb_sequence4args(xdr, cb, &hdr);
> > +
> > + /*
> > + * FIXME: get stateid and fh from delegation. Inline the cna_changes
> > + * buffer, and zero it.
> > + */
> > + WARN_ON_ONCE(!xdrgen_encode_CB_NOTIFY4args(xdr, &args));
> > +
> > + hdr.nops++;
> > + encode_cb_nops(&hdr);
> > +}
>
> There are a number of problems with this, but since there are no
> callers yet, we can let some of those issues stand.
>
> What is problematic in the longer-term is that this is a client-side
> encoder (since this is the server's NFSv4 callback client).
>
> xdrgen_encode_CB_NOTIFY4args() is an argument encoder, which is
> client-side functionality, but it resides in fs/nfsd/nfs4xdr_gen.c,
> which is server-side. Let's not mix these purposes.
>
> I replaced the comment and WARN_ON with this:
>
> + xdr_stream_encode_u32(xdr, OP_CB_NOTIFY);
> +
> + /* FIXME: encode stateid, fh, and cna_changes from delegation */
>
> You can use xdrgen functions for individual data items, but for
> full argument and response structures, only server-side is supported
> at the moment. In the later patch that completes this code, I'll cover
> the other fields, which can be a mix of open code and xdrgen.
>
The full argument encoder and decoder works just fine. When you say
"supported" what do you mean, specifically?
I'd really rather not go back to open-coding the encoders and decoders,
particularly since CB_NOTIFY has one of the most complex argument
structures in the protocol.
>
> > diff --git a/fs/nfsd/state.h b/fs/nfsd/state.h
> > index e1c40f8b5d01..790282781243 100644
> > --- a/fs/nfsd/state.h
> > +++ b/fs/nfsd/state.h
> > @@ -190,6 +190,13 @@ struct nfs4_cb_fattr {
> > u64 ncf_cur_fsize;
> > };
> >
> > +/*
> > + * FIXME: the current backchannel encoder can't handle a send buffer longer
> > + * than a single page (see bc_alloc/bc_free).
> > + */
>
> Nit: The allocator function name is bc_malloc
>
Will fix.
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* [PATCH v3 net-next 1/1] dt-bindings: net: dsa: Convert lan9303.txt to yaml format
From: Frank.Li @ 2026-06-10 15:05 UTC (permalink / raw)
To: Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Simon Horman, Jonathan Corbet, Shuah Khan, Frank Li,
open list:NETWORKING DRIVERS,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list, open list:DOCUMENTATION
Cc: imx
From: Frank Li <Frank.Li@nxp.com>
Convert lan9303.txt to yaml format to fix below CHECK_DTBS warnings:
arch/arm/boot/dts/nxp/imx/imx53-kp-hsc.dtb: /soc/bus@50000000/i2c@53fec000/switch@a: failed to match any schema with compatible: ['smsc,lan9303-i2c']
Additional changes:
- rename switch-phy to switch in example.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
---
change in v3
- rebase to net-next
change in v2:
- fix typo Additional in commit message
- add rob's reviewed-by tags
- fix doc ref problem
---
.../devicetree/bindings/net/dsa/lan9303.txt | 100 --------------
.../bindings/net/dsa/smsc,lan9303.yaml | 123 ++++++++++++++++++
Documentation/networking/dsa/lan9303.rst | 2 +-
3 files changed, 124 insertions(+), 101 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/net/dsa/lan9303.txt
create mode 100644 Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
diff --git a/Documentation/devicetree/bindings/net/dsa/lan9303.txt b/Documentation/devicetree/bindings/net/dsa/lan9303.txt
deleted file mode 100644
index 0337c2ccfa9a7..0000000000000
--- a/Documentation/devicetree/bindings/net/dsa/lan9303.txt
+++ /dev/null
@@ -1,100 +0,0 @@
-SMSC/MicroChip LAN9303 three port ethernet switch
--------------------------------------------------
-
-Required properties:
-
-- compatible: should be
- - "smsc,lan9303-i2c" for I2C managed mode
- or
- - "smsc,lan9303-mdio" for mdio managed mode
-
-Optional properties:
-
-- reset-gpios: GPIO to be used to reset the whole device
-- reset-duration: reset duration in milliseconds, defaults to 200 ms
-
-Subnodes:
-
-The integrated switch subnode should be specified according to the binding
-described in dsa/dsa.yaml. The CPU port of this switch is always port 0.
-
-Note: always use 'reg = <0/1/2>;' for the three DSA ports, even if the device is
-configured to use 1/2/3 instead. This hardware configuration will be
-auto-detected and mapped accordingly.
-
-Example:
-
-I2C managed mode:
-
- master: masterdevice@X {
-
- fixed-link { /* RMII fixed link to LAN9303 */
- speed = <100>;
- full-duplex;
- };
- };
-
- switch: switch@a {
- compatible = "smsc,lan9303-i2c";
- reg = <0xa>;
- reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
- reset-duration = <200>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 { /* RMII fixed link to master */
- reg = <0>;
- ethernet = <&master>;
- };
-
- port@1 { /* external port 1 */
- reg = <1>;
- label = "lan1";
- };
-
- port@2 { /* external port 2 */
- reg = <2>;
- label = "lan2";
- };
- };
- };
-
-MDIO managed mode:
-
- master: masterdevice@X {
- phy-handle = <&switch>;
-
- mdio {
- #address-cells = <1>;
- #size-cells = <0>;
-
- switch: switch-phy@0 {
- compatible = "smsc,lan9303-mdio";
- reg = <0>;
- reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
- reset-duration = <100>;
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- ethernet = <&master>;
- };
-
- port@1 { /* external port 1 */
- reg = <1>;
- label = "lan1";
- };
-
- port@2 { /* external port 2 */
- reg = <2>;
- label = "lan2";
- };
- };
- };
- };
- };
diff --git a/Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml b/Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
new file mode 100644
index 0000000000000..42f8473538a07
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml
@@ -0,0 +1,123 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/net/dsa/smsc,lan9303.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: SMSC/MicroChip LAN9303 three port ethernet switch
+
+maintainers:
+ - Frank Li <Frank.Li@nxp.com>
+
+description:
+ The LAN9303 is a three port ethernet switch with integrated PHYs for the
+ two external ports. The third port is an RMII/MII interface to a host
+ processor. The device can be managed via I2C or MDIO.
+
+ Note - always use 'reg = <0/1/2>;' for the three DSA ports, even if the
+ device is configured to use 1/2/3 instead. This hardware configuration
+ will be auto-detected and mapped accordingly.
+
+properties:
+ compatible:
+ enum:
+ - smsc,lan9303-i2c
+ - smsc,lan9303-mdio
+
+ reg:
+ maxItems: 1
+
+ reset-gpios:
+ description:
+ GPIO to be used to reset the whole device
+ maxItems: 1
+
+ reset-duration:
+ description:
+ Reset duration in milliseconds
+ default: 200
+ $ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+allOf:
+ - $ref: dsa.yaml#
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ /* I2C managed mode */
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@a {
+ compatible = "smsc,lan9303-i2c";
+ reg = <0xa>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <200>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+ };
+
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ /* MDIO managed mode */
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ switch@0 {
+ compatible = "smsc,lan9303-mdio";
+ reg = <0>;
+ reset-gpios = <&gpio7 6 GPIO_ACTIVE_LOW>;
+ reset-duration = <100>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ label = "cpu";
+ ethernet = <&master>;
+ };
+
+ port@1 {
+ reg = <1>;
+ label = "lan1";
+ };
+
+ port@2 {
+ reg = <2>;
+ label = "lan2";
+ };
+ };
+ };
+ };
diff --git a/Documentation/networking/dsa/lan9303.rst b/Documentation/networking/dsa/lan9303.rst
index ab81b4e0139e3..776572be265e1 100644
--- a/Documentation/networking/dsa/lan9303.rst
+++ b/Documentation/networking/dsa/lan9303.rst
@@ -12,7 +12,7 @@ Driver details
The driver is implemented as a DSA driver, see ``Documentation/networking/dsa/dsa.rst``.
-See ``Documentation/devicetree/bindings/net/dsa/lan9303.txt`` for device tree
+See ``Documentation/devicetree/bindings/net/dsa/smsc,lan9303.yaml`` for device tree
binding.
The LAN9303 can be managed both via MDIO and I2C, both supported by this driver.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5] Docs/{admin-guide,mm}/damon: fix DAMON documentation details
From: Doehyun Baek @ 2026-06-10 14:41 UTC (permalink / raw)
To: SeongJae Park, Dongliang Mu
Cc: Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jonathan Corbet, Shuah Khan,
damon, linux-mm, linux-doc, linux-kernel
In-Reply-To: <20260610140217.65110-1-sj@kernel.org>
> Let me know if you think this is really urgent or I'm missing something, though.
Thanks for reviewing and applying it to damon/next.
It is not urgent from my side. I needed the English documentation fix as
a base for the Chinese translation patches.
Dongliang, would it be okay for me to send the Chinese translation
patches based on damon/next, or should I wait until the English fix is
picked up by mm.git or mainline?
Thanks,
Doehyun
^ permalink raw reply
* Re: [PATCH v6 08/12] PCI: liveupdate: Inherit ACS flags in incoming preserved devices
From: Pranjal Shrivastava @ 2026-06-10 14:37 UTC (permalink / raw)
To: Jason Gunthorpe
Cc: David Matlack, kexec, linux-doc, linux-kernel, linux-mm,
linux-pci, Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jonathan Corbet, Josh Hilke, Leon Romanovsky, Lukas Wunner,
Mike Rapoport, Parav Pandit, Pasha Tatashin, Pratyush Yadav,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Vipin Sharma,
William Tu, Yi Liu
In-Reply-To: <20260610000704.GR1962447@nvidia.com>
On Tue, Jun 09, 2026 at 09:07:04PM -0300, Jason Gunthorpe wrote:
> On Tue, Jun 09, 2026 at 05:20:14PM +0000, Pranjal Shrivastava wrote:
>
> > Now, the attacker has an opportunity with Liveupdate, since the devices
> > are already assigned, if *somehow* it flips a bit like ACS_RR, the
>
> If this is possible then your environment is already security broken,
> no need to involve live update.
Ack. Alright.
Thanks,
Praan
^ permalink raw reply
* Re: [PATCH v5] Docs/{admin-guide,mm}/damon: fix DAMON documentation details
From: SeongJae Park @ 2026-06-10 14:02 UTC (permalink / raw)
To: Doehyun Baek
Cc: SeongJae Park, Andrew Morton, David Hildenbrand, Lorenzo Stoakes,
Liam R. Howlett, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jonathan Corbet, Shuah Khan,
damon, linux-mm, linux-doc, linux-kernel
In-Reply-To: <20260610053951.553739-1-doehyunbaek@gmail.com>
On Wed, 10 Jun 2026 05:39:50 +0000 Doehyun Baek <doehyunbaek@gmail.com> wrote:
> Fix minor DAMON documentation issues. Correct the sysfs scheme file name
> apply_interval_us, the DAMON_STAT module count, a malformed reference, a
> misplaced label indentation, and a few typos.
Nice catches, thank you for fixing those!
>
> Signed-off-by: Doehyun Baek <doehyunbaek@gmail.com>
Reviewed-by: SeongJae Park <sj@kernel.org>
I applied this patch to damon/next [1] tree. We are now quite close to next
merge window. We (mm community) want to focus on making mm.git more stabilized
and therefore ready for the next merge window, rather than adding more changes
that are not really urgent. I understand this patch is not really urgent.
Hence, Andrew might not add this patch to mm.git until next -rc1 release. In
the case, I will request that after next -rc1 release. So, no action from your
side is needed for now. Let me know if you think this is really urgent or I'm
missing something, though.
[1] https://origin.kernel.org/doc/html/latest/mm/damon/maintainer-profile.html#scm-trees
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [PATCH v5 05/21] nfsd: update the fsnotify mark when setting or removing a dir delegation
From: Chuck Lever @ 2026-06-10 13:55 UTC (permalink / raw)
To: Jeff Layton, Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo,
Tom Talpey, Trond Myklebust, Anna Schumaker, Jonathan Corbet,
Shuah Khan
Cc: Steven Rostedt, Alexander Aring, Amir Goldstein, Jan Kara,
Alexander Viro, Christian Brauner, Calum Mackay, linux-kernel,
linux-doc, linux-nfs
In-Reply-To: <dd5836b365946641824dbde5b6edc5395271617d.camel@kernel.org>
On Wed, Jun 10, 2026, at 9:49 AM, Jeff Layton wrote:
> On Mon, 2026-06-08 at 12:38 -0400, Chuck Lever wrote:
>> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
>> > index 2a34ba457b74..efbc99f0a965 100644
>> > --- a/fs/nfsd/nfs4state.c
>> > +++ b/fs/nfsd/nfs4state.c
>> > @@ -1246,6 +1246,38 @@ static void
>> > nfsd4_finalize_deleg_timestamps(struct nfs4_delegation *dp, struct f
>> > nfsd_update_cmtime_attr(f, ATTR_ATIME);
>> > }
>> >
>> > +static void nfsd_fsnotify_recalc_mask(struct nfsd_file *nf)
>>
>> Since nfsd_fsnotify_recalc_mask() takes a single struct nfsd_file
>> as an argument, should this function reside in fs/nfsd/filecache.c
>> instead? The question might reflect my misunderstanding of the
>> new function's purpose.
>>
>
> The only caller is in this file, so by keeping it here we can make it
> static. I can change that if you'd prefer it be in filecache.c.
My thought was that the new function is accessing and modifying
the internals of an nfsd_file -- it contains local knowledge about
how the filecache manages fs notifications.
>> > +{
>> > + struct inode *inode = file_inode(nf->nf_file);
>> > + u32 lease_mask, set = 0, clear = 0;
>> > + struct fsnotify_mark *mark;
>> > +
>> > + /* This is only needed when adding or removing dir delegs */
>> > + if (!S_ISDIR(inode->i_mode) || !nf->nf_mark)
>> > + return;
>> > +
>> > + /* Set up notifications for any ignored delegation events */
>> > + lease_mask = inode_lease_ignore_mask(inode);
>> > + mark = &nf->nf_mark->nfm_mark;
>> > +
>> > + if (lease_mask & FL_IGN_DIR_CREATE)
>> > + set |= FS_CREATE | FS_MOVED_TO;
>> > + else
>> > + clear |= FS_CREATE | FS_MOVED_TO;
>> > +
>> > + if (lease_mask & FL_IGN_DIR_DELETE)
>> > + set |= FS_DELETE | FS_MOVED_FROM;
>> > + else
>> > + clear |= FS_DELETE | FS_MOVED_FROM;
>> > +
>> > + if (lease_mask & FL_IGN_DIR_RENAME)
>> > + set |= FS_RENAME;
>> > + else
>> > + clear |= FS_RENAME;
>> > +
>> > + fsnotify_modify_mark_mask(mark, set, clear);
>> > +}
>> > +
>> > static void nfs4_unlock_deleg_lease(struct nfs4_delegation *dp)
>> > {
>> > struct nfs4_file *fp = dp->dl_stid.sc_file;
--
Chuck Lever
^ permalink raw reply
* Re: [PATCH v5 05/21] nfsd: update the fsnotify mark when setting or removing a dir delegation
From: Jeff Layton @ 2026-06-10 13:49 UTC (permalink / raw)
To: Chuck Lever, Chuck Lever, NeilBrown, Olga Kornievskaia, Dai Ngo,
Tom Talpey, Trond Myklebust, Anna Schumaker, Jonathan Corbet,
Shuah Khan
Cc: Steven Rostedt, Alexander Aring, Amir Goldstein, Jan Kara,
Alexander Viro, Christian Brauner, Calum Mackay, linux-kernel,
linux-doc, linux-nfs
In-Reply-To: <e0e995e9-8272-44f6-b2e0-9e61ed0eef3b@app.fastmail.com>
On Mon, 2026-06-08 at 12:38 -0400, Chuck Lever wrote:
>
> On Fri, May 22, 2026, at 3:42 PM, Jeff Layton wrote:
> > Add a new helper function that will update the mask on the nfsd_file's
> > fsnotify_mark to be a union of all current directory delegations on an
> > inode. Call that when directory delegations are added or removed.
>
> This commit message repeats what the diff below says. Can it instead
> explain why this change is necessary?
>
The idea is that as new delegations are added or removed, the mask of
events that nfsd requires from the VFS layer can change, since clients
can request notifications of different events. I'll add that to the
changelog.
>
> > Reviewed-by: Jan Kara <jack@suse.cz>
> > Signed-off-by: Jeff Layton <jlayton@kernel.org>
> > ---
> > fs/nfsd/nfs4state.c | 34 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c
> > index 2a34ba457b74..efbc99f0a965 100644
> > --- a/fs/nfsd/nfs4state.c
> > +++ b/fs/nfsd/nfs4state.c
> > @@ -1246,6 +1246,38 @@ static void
> > nfsd4_finalize_deleg_timestamps(struct nfs4_delegation *dp, struct f
> > nfsd_update_cmtime_attr(f, ATTR_ATIME);
> > }
> >
> > +static void nfsd_fsnotify_recalc_mask(struct nfsd_file *nf)
>
> Since nfsd_fsnotify_recalc_mask() takes a single struct nfsd_file
> as an argument, should this function reside in fs/nfsd/filecache.c
> instead? The question might reflect my misunderstanding of the
> new function's purpose.
>
The only caller is in this file, so by keeping it here we can make it
static. I can change that if you'd prefer it be in filecache.c.
>
> > +{
> > + struct inode *inode = file_inode(nf->nf_file);
> > + u32 lease_mask, set = 0, clear = 0;
> > + struct fsnotify_mark *mark;
> > +
> > + /* This is only needed when adding or removing dir delegs */
> > + if (!S_ISDIR(inode->i_mode) || !nf->nf_mark)
> > + return;
> > +
> > + /* Set up notifications for any ignored delegation events */
> > + lease_mask = inode_lease_ignore_mask(inode);
> > + mark = &nf->nf_mark->nfm_mark;
> > +
> > + if (lease_mask & FL_IGN_DIR_CREATE)
> > + set |= FS_CREATE | FS_MOVED_TO;
> > + else
> > + clear |= FS_CREATE | FS_MOVED_TO;
> > +
> > + if (lease_mask & FL_IGN_DIR_DELETE)
> > + set |= FS_DELETE | FS_MOVED_FROM;
> > + else
> > + clear |= FS_DELETE | FS_MOVED_FROM;
> > +
> > + if (lease_mask & FL_IGN_DIR_RENAME)
> > + set |= FS_RENAME;
> > + else
> > + clear |= FS_RENAME;
> > +
> > + fsnotify_modify_mark_mask(mark, set, clear);
> > +}
> > +
> > static void nfs4_unlock_deleg_lease(struct nfs4_delegation *dp)
> > {
> > struct nfs4_file *fp = dp->dl_stid.sc_file;
> > @@ -1255,6 +1287,7 @@ static void nfs4_unlock_deleg_lease(struct
> > nfs4_delegation *dp)
> >
> > nfsd4_finalize_deleg_timestamps(dp, nf->nf_file);
> > kernel_setlease(nf->nf_file, F_UNLCK, NULL, (void **)&dp);
> > + nfsd_fsnotify_recalc_mask(nf);
> > put_deleg_file(fp);
> > }
> >
>
> I added the following edit to this patch>
>
> @@ -9597,8 +9629,7 @@ nfsd4_deleg_getattr_conflict(struct svc_rqst *rqstp, struct dentry *dentry,
> * @nf: nfsd_file opened on the directory
> *
> * Given a GET_DIR_DELEGATION request @gdd, attempt to acquire a delegation
> - * on the directory to which @nf refers. Note that this does not set up any
> - * sort of async notifications for the delegation.
> + * on the directory to which @nf refers.
> */
> struct nfs4_delegation *
> nfsd_get_dir_deleg
>
> The patch makes the above kerneldoc note ("does not set up any sort of async
> notifications") logically obsolete.
>
Thanks. I folded that change into this patch.
>
> > @@ -9682,6 +9715,7 @@ nfsd_get_dir_deleg(struct nfsd4_compound_state *cstate,
> >
> > if (!status) {
> > put_nfs4_file(fp);
> > + nfsd_fsnotify_recalc_mask(nf);
> > return dp;
> > }
> >
> >
> > --
> > 2.54.0
--
Jeff Layton <jlayton@kernel.org>
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
From: Shanker Donthineni @ 2026-06-10 13:20 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, linux-arm-kernel, Vladimir Murzin, Mark Rutland,
linux-kernel, linux-doc, Vikram Sethi, Jason Sequeira, jgg
In-Reply-To: <ailKYTOX23EMnJsK@willie-the-truck>
Hi Will,
On 6/10/2026 6:28 AM, Will Deacon wrote:
> External email: Use caution opening links or attachments
>
>
> [+Jason G]
>
> On Fri, Jun 05, 2026 at 09:45:51AM -0500, Shanker Donthineni wrote:
>> On systems with NVIDIA Olympus cores, a Device-nGnR* load can be
>> observed by a peripheral before an older, non-overlapping Device-nGnR*
>> store to the same peripheral. This breaks the program-order guarantee
>> that software expects for Device-nGnR* accesses and can leave a
>> peripheral in an incorrect state, as a load is observed before an
>> earlier store takes effect.
>>
>> The erratum can occur only when all of the following apply:
>>
>> - A PE executes a Device-nGnR* store followed by a younger
>> Device-nGnR* load.
>> - The store is not a store-release.
>> - The accesses target the same peripheral and do not overlap in bytes.
>> - There is at most one intervening Device-nGnR* store in program
>> order, and there are no intervening Device-nGnR* loads.
>> - There is no DSB, and no DMB that orders loads, between the store and
>> the load.
>> - Specific micro-architectural and timing conditions occur.
>>
>> Two ways to restore ordering: insert a barrier (any DSB, or a DMB that
>> orders loads) between the store and the load, or make the store a
>> store-release. A load-acquire on the load side would not help, because
>> acquire semantics do not prevent a load from being observed ahead of an
>> older store; only the store side (release or a barrier) closes the
>> window.
> I think you can drop the paragraph above. A store-release isn't enough
> to order against a later load in the architecture either, so we're
> clearly in micro-architecture territory and I don't think you need to
> describe mechanisms that don't work here.
>
>> Promote the raw MMIO store helpers (__raw_writeb/w/l/q) from plain str*
>> to stlr* (Store-Release), which removes the "store is not a
>> store-release" condition for every device write the kernel issues.
>> Because writel() and writel_relaxed() are both built on __raw_writel()
>> in asm-generic/io.h, patching the raw variants covers both the
>> non-relaxed and relaxed APIs without touching the higher layers. Note
>> that writel()'s own barrier sits before the store, so it does not order
>> the store against a subsequent readl(); the store-release promotion is
>> what provides that ordering.
Based on the existing code comments and after reviewing this path again,
__const_memcpy_toio_aligned32() and __const_memcpy_toio_aligned64()
appear to be intended for WC regions. Since the erratum is scoped to
Device-nGnR* accesses, and WC mappings are Normal-NC on arm64, I don’t
think the STLR workaround should apply to these helpers by default.
Applying it there would also break the contiguous STR grouping that
this path relies on for write combining.
-Shanker
^ permalink raw reply
* Re: [PATCH] hwmon: (pmbus/max34440): add support adpm12250
From: Guenter Roeck @ 2026-06-10 13:12 UTC (permalink / raw)
To: Alexis Czezar Torreno
Cc: Jonathan Corbet, Shuah Khan, linux-hwmon, linux-doc, linux-kernel
In-Reply-To: <20260610-dev-adpm12250-v1-1-422760bb80da@analog.com>
On Wed, Jun 10, 2026 at 09:12:10AM +0800, Alexis Czezar Torreno wrote:
> ADPM12250 is a quarter brick DC/DC Power Module. It is a high power
> non-isolated converter capable of delivering regulated 12V with
> continuous power level of 2500W. Uses PMBus.
>
> Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
> Reviewed-by: Nuno Sá <nuno.sa@analog.com>
Applied.
Thanks,
Guenter
^ permalink raw reply
* Re: configurable block error injection v4
From: Christoph Hellwig @ 2026-06-10 13:11 UTC (permalink / raw)
To: Jens Axboe
Cc: Jonathan Corbet, Damien Le Moal, Hannes Reinecke, Keith Busch,
linux-block, linux-doc
In-Reply-To: <20260610051015.1906799-1-hch@lst.de>
Sashiko had two comments on this:
- the one about the race of removal vs. addition is spot on, and
trivially fixed by actually removing the code (unlock/lock cycle).
- the other about zero-sized commands is valid, but more of an
enhancement. And one that if implemented right now actually
make things worse, as flushed actually show up as empty writes
with the preflush bit and not as REQ_OP_FLUSH. So if we'd special
case zero-sized bios, we'd make a flush hit all write rules,
which would defeat the point. We really need to do flushes as
REQ_OP_FLUSH at the bio level :(
Below is what I plan to fold in, and I'm thinking of the empty bio
issue above can be caught in a comment or the documentation nicely.
diff --git a/block/error-injection.c b/block/error-injection.c
index 7f7f0d3327bc..3bc91f199dc7 100644
--- a/block/error-injection.c
+++ b/block/error-injection.c
@@ -119,11 +119,7 @@ static void error_inject_removeall(struct gendisk *disk)
while ((inj = list_first_entry_or_null(&disk->error_injection_list,
struct blk_error_inject, entry))) {
list_del_rcu(&inj->entry);
- mutex_unlock(&disk->error_injection_lock);
-
kfree_rcu_mightsleep(inj);
-
- mutex_lock(&disk->error_injection_lock);
}
static_branch_dec(&blk_error_injection_enabled);
mutex_unlock(&disk->error_injection_lock);
^ permalink raw reply related
* Re: [PATCH v2] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
From: Shanker Donthineni @ 2026-06-10 12:53 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, linux-arm-kernel, Vladimir Murzin, Mark Rutland,
linux-kernel, linux-doc, Vikram Sethi, Jason Sequeira, jgg
In-Reply-To: <ailKYTOX23EMnJsK@willie-the-truck>
Hi Will,
On 6/10/2026 6:28 AM, Will Deacon wrote:
> External email: Use caution opening links or attachments
>
>
> [+Jason G]
>
> On Fri, Jun 05, 2026 at 09:45:51AM -0500, Shanker Donthineni wrote:
>> On systems with NVIDIA Olympus cores, a Device-nGnR* load can be
>> observed by a peripheral before an older, non-overlapping Device-nGnR*
>> store to the same peripheral. This breaks the program-order guarantee
>> that software expects for Device-nGnR* accesses and can leave a
>> peripheral in an incorrect state, as a load is observed before an
>> earlier store takes effect.
>>
>> The erratum can occur only when all of the following apply:
>>
>> - A PE executes a Device-nGnR* store followed by a younger
>> Device-nGnR* load.
>> - The store is not a store-release.
>> - The accesses target the same peripheral and do not overlap in bytes.
>> - There is at most one intervening Device-nGnR* store in program
>> order, and there are no intervening Device-nGnR* loads.
>> - There is no DSB, and no DMB that orders loads, between the store and
>> the load.
>> - Specific micro-architectural and timing conditions occur.
>>
>> Two ways to restore ordering: insert a barrier (any DSB, or a DMB that
>> orders loads) between the store and the load, or make the store a
>> store-release. A load-acquire on the load side would not help, because
>> acquire semantics do not prevent a load from being observed ahead of an
>> older store; only the store side (release or a barrier) closes the
>> window.
> I think you can drop the paragraph above. A store-release isn't enough
> to order against a later load in the architecture either, so we're
> clearly in micro-architecture territory and I don't think you need to
> describe mechanisms that don't work here.
Thanks, Will. I’ll drop paragraph and avoid describing store-release
as an architectural ordering mechanism here.
>> Promote the raw MMIO store helpers (__raw_writeb/w/l/q) from plain str*
>> to stlr* (Store-Release), which removes the "store is not a
>> store-release" condition for every device write the kernel issues.
>> Because writel() and writel_relaxed() are both built on __raw_writel()
>> in asm-generic/io.h, patching the raw variants covers both the
>> non-relaxed and relaxed APIs without touching the higher layers. Note
>> that writel()'s own barrier sits before the store, so it does not order
>> the store against a subsequent readl(); the store-release promotion is
>> what provides that ordering.
> Sashiko points out that you're missing __const_memcpy_toio_aligned32().
I’ll also cover __const_memcpy_toio_aligned32(); it currently emits plain
STRs directly and can bypass the raw write helper workaround. I’ll audit
the aligned64 path at the same time.
>> Like ARM64_ERRATUM_832075 on the load side, the change is gated on a new
>> ARM64_WORKAROUND_DEVICE_STORE_RELEASE capability and only activated on
>> parts that match MIDR_NVIDIA_OLYMPUS, so unaffected CPUs continue to use
>> the plain str* sequence.
>>
>> Note: stlr* only supports base-register addressing, so the raw accessors
>> can no longer use the offset addressing introduced by commit d044d6ba6f02
>> ("arm64: io: permit offset addressing"). The str* and stlr* alternates
>> share a single inline-asm operand and the sequence is selected at boot,
>> so the operand form is fixed at compile time; unaffected CPUs keep using
>> str* but also revert to base-register addressing. This keeps the store
>> side as simple as the existing load-side patching (load-acquire) and
>> avoids adding complexity to the device write path; retaining offset
>> addressing only for str* would otherwise require a runtime branch on
>> every write.
> I seem to remember Jason caring about that, possibly because some CPUs
> are very picky about write-combining?
For the offset-addressing concern, I’ll rework the raw accessors so
unaffected CPUs keep the existing offset-addressed STR sequence, and
only CPUs with ARM64_WORKAROUND_DEVICE_STORE_RELEASE take the base-register
STLR path.
I’ll post a v3 using the patched branch from alternative_has_cap_unlikely(),
and include the memcpy_toio() aligned-helper coverage as shown below.
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -22,10 +22,46 @@
/*
* Generic IO read/write. These perform native-endian accesses.
*/
+static __always_inline bool arm64_needs_device_store_release(void)
+{
+ return alternative_has_cap_unlikely(
+ ARM64_WORKAROUND_DEVICE_STORE_RELEASE);
+}
+
+static __always_inline void __raw_writeb_stlr(u8 val,
+ volatile void __iomem *addr)
+{
+ asm volatile("stlrb %w0, [%1]" : : "rZ" (val), "r" (addr));
+}
+
+static __always_inline void __raw_writew_stlr(u16 val,
+ volatile void __iomem *addr)
+{
+ asm volatile("stlrh %w0, [%1]" : : "rZ" (val), "r" (addr));
+}
+
+static __always_inline void __raw_writel_stlr(u32 val,
+ volatile void __iomem *addr)
+{
+ asm volatile("stlr %w0, [%1]" : : "rZ" (val), "r" (addr));
+}
+
+static __always_inline void __raw_writeq_stlr(u64 val,
+ volatile void __iomem *addr)
+{
+ asm volatile("stlr %x0, [%1]" : : "rZ" (val), "r" (addr));
+}
+
#define __raw_writeb __raw_writeb
static __always_inline void __raw_writeb(u8 val, volatile void __iomem *addr)
{
volatile u8 __iomem *ptr = addr;
+
+ if (arm64_needs_device_store_release()) {
+ __raw_writeb_stlr(val, addr);
+ return;
+ }
+
asm volatile("strb %w0, %1" : : "rZ" (val), "Qo" (*ptr));
}
@@ -33,6 +69,12 @@ static __always_inline void __raw_writeb(u8 val, volatile void __iomem *addr)
static __always_inline void __raw_writew(u16 val, volatile void __iomem *addr)
{
volatile u16 __iomem *ptr = addr;
+
+ if (arm64_needs_device_store_release()) {
+ __raw_writew_stlr(val, addr);
+ return;
+ }
+
asm volatile("strh %w0, %1" : : "rZ" (val), "Qo" (*ptr));
}
@@ -40,6 +82,12 @@ static __always_inline void __raw_writew(u16 val, volatile void __iomem *addr)
static __always_inline void __raw_writel(u32 val, volatile void __iomem *addr)
{
volatile u32 __iomem *ptr = addr;
+
+ if (arm64_needs_device_store_release()) {
+ __raw_writel_stlr(val, addr);
+ return;
+ }
+
asm volatile("str %w0, %1" : : "rZ" (val), "Qo" (*ptr));
}
@@ -47,6 +95,12 @@ static __always_inline void __raw_writel(u32 val, volatile void __iomem *addr)
static __always_inline void __raw_writeq(u64 val, volatile void __iomem *addr)
{
volatile u64 __iomem *ptr = addr;
+
+ if (arm64_needs_device_store_release()) {
+ __raw_writeq_stlr(val, addr);
+ return;
+ }
+
asm volatile("str %x0, %1" : : "rZ" (val), "Qo" (*ptr));
}
@@ -147,6 +201,12 @@ static __always_inline void
__const_memcpy_toio_aligned32(volatile u32 __iomem *to, const u32 *from,
size_t count)
{
+ if (arm64_needs_device_store_release()) {
+ while (count--)
+ __raw_writel_stlr(*from++, to++);
+ return;
+ }
+
switch (count) {
case 8:
asm volatile("str %w0, [%8, #4 * 0]\n"
@@ -204,6 +264,12 @@ static __always_inline void
__const_memcpy_toio_aligned64(volatile u64 __iomem *to, const u64 *from,
size_t count)
{
+ if (arm64_needs_device_store_release()) {
+ while (count--)
+ __raw_writeq_stlr(*from++, to++);
+ return;
+ }
+
switch (count) {
case 8:
asm volatile("str %x0, [%8, #8 * 0]\n"
I'll post v3 patch with jump instruction patch.
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -22,10 +22,46 @@
/*
* Generic IO read/write. These perform native-endian accesses.
*/
+static __always_inline bool arm64_needs_device_store_release(void)
+{
+ return alternative_has_cap_unlikely(
+ ARM64_WORKAROUND_DEVICE_STORE_RELEASE);
+}
+
+static __always_inline void __raw_writeb_stlr(u8 val,
+ volatile void __iomem *addr)
+{
+ asm volatile("stlrb %w0, [%1]" : : "rZ" (val), "r" (addr));
+}
+
+static __always_inline void __raw_writew_stlr(u16 val,
+ volatile void __iomem *addr)
+{
+ asm volatile("stlrh %w0, [%1]" : : "rZ" (val), "r" (addr));
+}
+
+static __always_inline void __raw_writel_stlr(u32 val,
+ volatile void __iomem *addr)
+{
+ asm volatile("stlr %w0, [%1]" : : "rZ" (val), "r" (addr));
+}
+
+static __always_inline void __raw_writeq_stlr(u64 val,
+ volatile void __iomem *addr)
+{
+ asm volatile("stlr %x0, [%1]" : : "rZ" (val), "r" (addr));
+}
+
#define __raw_writeb __raw_writeb
static __always_inline void __raw_writeb(u8 val, volatile void __iomem *addr)
{
volatile u8 __iomem *ptr = addr;
+
+ if (arm64_needs_device_store_release()) {
+ __raw_writeb_stlr(val, addr);
+ return;
+ }
+
asm volatile("strb %w0, %1" : : "rZ" (val), "Qo" (*ptr));
}
@@ -33,6 +69,12 @@ static __always_inline void __raw_writeb(u8 val, volatile void __iomem *addr)
static __always_inline void __raw_writew(u16 val, volatile void __iomem *addr)
{
volatile u16 __iomem *ptr = addr;
+
+ if (arm64_needs_device_store_release()) {
+ __raw_writew_stlr(val, addr);
+ return;
+ }
+
asm volatile("strh %w0, %1" : : "rZ" (val), "Qo" (*ptr));
}
@@ -40,6 +82,12 @@ static __always_inline void __raw_writew(u16 val, volatile void __iomem *addr)
static __always_inline void __raw_writel(u32 val, volatile void __iomem *addr)
{
volatile u32 __iomem *ptr = addr;
+
+ if (arm64_needs_device_store_release()) {
+ __raw_writel_stlr(val, addr);
+ return;
+ }
+
asm volatile("str %w0, %1" : : "rZ" (val), "Qo" (*ptr));
}
@@ -47,6 +95,12 @@ static __always_inline void __raw_writel(u32 val, volatile void __iomem *addr)
static __always_inline void __raw_writeq(u64 val, volatile void __iomem *addr)
{
volatile u64 __iomem *ptr = addr;
+
+ if (arm64_needs_device_store_release()) {
+ __raw_writeq_stlr(val, addr);
+ return;
+ }
+
asm volatile("str %x0, %1" : : "rZ" (val), "Qo" (*ptr));
}
@@ -147,6 +201,12 @@ static __always_inline void
__const_memcpy_toio_aligned32(volatile u32 __iomem *to, const u32 *from,
size_t count)
{
+ if (arm64_needs_device_store_release()) {
+ while (count--)
+ __raw_writel_stlr(*from++, to++);
+ return;
+ }
+
switch (count) {
case 8:
asm volatile("str %w0, [%8, #4 * 0]\n"
@@ -204,6 +264,12 @@ static __always_inline void
__const_memcpy_toio_aligned64(volatile u64 __iomem *to, const u64 *from,
size_t count)
{
+ if (arm64_needs_device_store_release()) {
+ while (count--)
+ __raw_writeq_stlr(*from++, to++);
+ return;
+ }
+
switch (count) {
case 8:
asm volatile("str %x0, [%8, #8 * 0]\n"
-Shanker
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Workaround NVIDIA Olympus device store/load ordering erratum
From: Jason Gunthorpe @ 2026-06-10 12:50 UTC (permalink / raw)
To: Will Deacon
Cc: Shanker Donthineni, Catalin Marinas, linux-arm-kernel,
Vladimir Murzin, Mark Rutland, linux-kernel, linux-doc,
Vikram Sethi, Jason Sequeira
In-Reply-To: <ailKYTOX23EMnJsK@willie-the-truck>
On Wed, Jun 10, 2026 at 12:28:33PM +0100, Will Deacon wrote:
> > Note: stlr* only supports base-register addressing, so the raw accessors
> > can no longer use the offset addressing introduced by commit d044d6ba6f02
> > ("arm64: io: permit offset addressing"). The str* and stlr* alternates
> > share a single inline-asm operand and the sequence is selected at boot,
> > so the operand form is fixed at compile time; unaffected CPUs keep using
> > str* but also revert to base-register addressing. This keeps the store
> > side as simple as the existing load-side patching (load-acquire) and
> > avoids adding complexity to the device write path; retaining offset
> > addressing only for str* would otherwise require a runtime branch on
> > every write.
>
> I seem to remember Jason caring about that, possibly because some CPUs
> are very picky about write-combining?
I think it was more a fall out of the work there, after looking at the
assembly this minor edit to the constraint made a nice codegen
impact. It is certainly a shame to loose it for this bug.
If we care about write combining we can't have a branch anyhow, but
that is most important for the specific memcpy operations (which will
need a branch)
Jason
^ permalink raw reply
* Re: [PATCH v4 2/2] cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
From: Catalin Marinas @ 2026-06-10 12:43 UTC (permalink / raw)
To: Jinjie Ruan
Cc: will, corbet, skhan, punit.agrawal, mrigendra.chaubey,
suzuki.poulose, chenl311, fengchengwen, maz, timothy.hayes,
lpieralisi, arnd, gshan, jic23, dietmar.eggemann, sudeep.holla,
pierre.gondois, linux-arm-kernel, linux-doc, linux-kernel
In-Reply-To: <20260610075202.3597031-3-ruanjinjie@huawei.com>
On Wed, Jun 10, 2026 at 03:52:02PM +0800, Jinjie Ruan wrote:
> diff --git a/Documentation/arch/arm64/cpu-hotplug.rst b/Documentation/arch/arm64/cpu-hotplug.rst
> index 8fb438bf7781..7c3379b704aa 100644
> --- a/Documentation/arch/arm64/cpu-hotplug.rst
> +++ b/Documentation/arch/arm64/cpu-hotplug.rst
> @@ -47,11 +47,12 @@ ever have can be described at boot. There are no power-domain considerations
> as such devices are emulated.
>
> CPU Hotplug on virtual systems is supported. It is distinct from physical
> -CPU Hotplug as all resources are described as ``present``, but CPUs may be
> -marked as disabled by firmware. Only the CPU's online/offline behaviour is
> -influenced by firmware. An example is where a virtual machine boots with a
> -single CPU, and additional CPUs are added once a cloud orchestrator deploys
> -the workload.
> +CPU Hotplug as all vCPU resources are statically described in the firmware
> +configuration tables (e.g. MADT), meaning their maximum possible count is
> +known at boot. However, vCPUs that are not enabled at boot are not marked
> +as ``present`` by the kernel until they are hotplugged. An example is where
> +a virtual machine boots with a single CPU, and additional CPUs are added
> +once a cloud orchestrator deploys the workload.
>
> For a virtual machine, the VMM (e.g. Qemu) plays the part of firmware.
>
> @@ -60,16 +61,19 @@ brought online. Firmware can enforce its policy via PSCI's return codes. e.g.
> ``DENIED``.
>
> The ACPI tables must describe all the resources of the virtual machine. CPUs
> -that firmware wishes to disable either from boot (or later) should not be
> -``enabled`` in the MADT GICC structures, but should have the ``online capable``
> -bit set, to indicate they can be enabled later. The boot CPU must be marked as
> -``enabled``. The 'always on' GICR structure must be used to describe the
> -redistributors.
> +that are hot-pluggable must have the ``online capable`` bit set and the
> +``enabled`` bit cleared in the MADT GICC structures to indicate they can be
> +enabled later. The boot CPU must be marked as ``enabled`` with its
> +``online capable`` bit cleared. The 'always on' GICR structure must be used
> +to describe the redistributors.
>
> CPUs described as ``online capable`` but not ``enabled`` can be set to enabled
> by the DSDT's Processor object's _STA method. On virtual systems the _STA method
> -must always report the CPU as ``present``. Changes to the firmware policy can
> -be notified to the OS via device-check or eject-request.
> +must always set the ``ACPI_STA_DEVICE_PRESENT`` bit, while toggling the
> +``ACPI_STA_DEVICE_ENABLED`` bit to reflect its plug status. The kernel will
> +then dynamically mark the vCPU as ``present`` within the OS when the
> +``ACPI_STA_DEVICE_ENABLED`` bit becomes set during hot-add. Changes to the
> +firmware policy can be notified to the OS via device-check or eject-request.
The doc update looks fine as well, thanks for clarifying. My reviewed-by
stands.
--
Catalin
^ permalink raw reply
* Re: [RFC PATCH v1 00/13] exec: add spawn templates for repeated executable startup
From: Li Chen @ 2026-06-10 12:29 UTC (permalink / raw)
To: John Ericson
Cc: Andy Lutomirski, Christian Brauner, Kees Cook, Al Viro,
linux-fsdevel, linux-api, LKML, linux-mm, linux-arch, linux-doc,
linux-kselftest, x86, Arnd Bergmann, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, Dave Hansen, H. Peter Anvin, Jan Kara,
Jonathan Corbet, Shuah Khan
In-Reply-To: <4e049396-377d-48a7-a34c-91318413a876@app.fastmail.com>
Hi John,
---- On Wed, 10 Jun 2026 01:27:47 +0800 John Ericson <mail@johnericson.me> wrote ---
>
>
> On Tue, Jun 9, 2026, at 10:43 AM, Li Chen wrote:
> > Hi Andy,
> >
> > ---- On Tue, 09 Jun 2026 08:01:57 +0800 Andy Lutomirski <luto@kernel.org> wrote ---
> > > [...]
> > >
> > > After contemplating this for a bit... why pidfd? Doesn't a pidfd
> > > refer to an actual process that is, or at least was, running? This
> > > new thing is a process that we are contemplating spawning. I can
> > > imagine that basically all pidfd APIs would be a bit confused by the
> > > nonexistence of the process in question.
> > >
> >
> > Yes, I think that is a real concern.
> >
> > In my current local WIP I tried to keep that distinction explicit.
> > pidfd_spawn_open() returns a pidfs-backed builder fd, not a normal pidfd
> > referring to a process. The builder fd is allocated as an anonymous pidfs
> > file with builder-specific file operations:
> >
> > file = pidfs_alloc_anon_file("[pidfd_spawn]",
> > &pidfd_spawn_builder_fops, builder,
> > O_RDWR);
> >
>
> What does your builder fd point to, explicitly? For example in my other reply I
> talked about how it was "real" process state. In my FreeBSD patch, for example,
> I found there was already a status for a process "in exec", and I figured that
> was clean to reuse for one of these "embryonic" processes that also hadn't
> started running. I would reckon that Linux probably has some similar notions.
>
> > and the normal pidfd helpers still reject it because it does not use the
> > ordinary pidfd file operations:
> >
> > struct pid *pidfd_pid(const struct file *file)
> > {
> > if (file->f_op != &pidfs_file_operations)
> > return ERR_PTR(-EBADF);
> > return file_inode(file)->i_private;
> > }
> >
> > So the current split is:
> >
> > builder_fd = pidfd_spawn_open(...); /* builder object */
> > pidfd_config(builder_fd, ...);
> > child_pidfd = pidfd_spawn_run(builder_fd, ...); /* real pidfd */
> >
> > Only the last fd is a normal pidfd for an actual child process. The builder
> > fd is only accepted by the builder operations.
> >
> > This avoids having to define what waitid(P_PIDFD), pidfd_send_signal(),
> > pidfd_getfd(), poll(), etc. mean before the process exists.
>
> I wouldn't be so sure this is necessary/good. For example, I think it could
> make sense to wait on a process that has yet to be started; one just waits for
> both the process to start and the process to exit. Obviously a blocking syscall
> in the thread that is spawning the process is not useful, but the asynchronous
> poll variation seems fine.
>
> As long as there is real process state here, it shouldn't be too hard to
> implement.
>
> > The downside is that it adds a separate open-style entry point and is less
> > uniform than the pidfd_open(0, PIDFD_EMPTY) spelling Christian sketched.
>
> I do think there is no point having two file descriptors. The file descriptor
> that previously referred to the builder/embryonic process then can refer to the
> real process, right?
>
> > If people think there is a better way to represent the pre-spawn builder
> > state, or if the preference is to integrate it directly into pidfd_open()
> > with an explicit empty/future-pidfd state, I would be happy to discuss that.
>
> Hope the above answers your question? I suppose my ideas lean more on the
> "future" than "empty" side --- there is indeed a thread in the thread group,
> with real VM/namespace/file descriptor etc. state. Moreover, state gets
> initialized before the process is started, so the actual start is a pretty
> lightweight step of just letting the scheduler know the now-ready process can
> be scheduled. The only thing that distinguishes the embryonic process from a
> real one is simply that it isn't running --- i.e. isn't (yet) available to be
> scheduled --- so the pidfds holders are free to poke at its state.
>
> Cheers,
>
> John
>
Thanks, this helped a lot. I looked at FreeBSD/OpenBSD/XNU after your
note. FreeBSD has P_INEXEC, OpenBSD has PS_INEXEC, and XNU seems even
closer with P_LINTRANSIT, described as "process in exec or in creation".
Linux does not seem to have a single equivalent today: current->in_execve
is only an LSM hint, while the real synchronization is spread across
exec_update_lock, cred_guard_mutex, and the exec path.
I am switching my local WIP from the two-fd builder model to one fd,
closer to Christian's sketch:
fd = pidfd_open(0, PIDFD_EMPTY);
pidfd_config(fd, ...);
pidfd_spawn_run(fd, ...);
In my current local version, I still use copy_process(), so the fd points
at a real task_struct/pid that is not woken until run. Following
Christian's point that existing APIs can handle this not-yet-running case
with ESRCH, I currently make ordinary pidfd operations that need a real
started process return -ESRCH before start.
I am not sure yet whether Linux should grow a general exec/creation
transition state like that, or whether a narrower future-process
lifecycle is enough for this API. I will think more about that when
working on the pristine process version.
Regards,
Li
^ permalink raw reply
* Re: [PATCH v1] arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU
From: Will Deacon @ 2026-06-10 12:14 UTC (permalink / raw)
To: Catalin Marinas, linux-arm-kernel, Mark Rutland,
Shanker Donthineni
Cc: kernel-team, Will Deacon, linux-kernel, linux-doc, Vikram Sethi,
Jason Sequeira, Alok Mooley, Rich Wiley
In-Reply-To: <20260609234044.3945938-1-sdonthineni@nvidia.com>
On Tue, 09 Jun 2026 18:40:44 -0500, Shanker Donthineni wrote:
> NVIDIA Olympus cores are affected by the TLBI completion issue tracked as
> CVE-2025-10263. The existing ARM64_ERRATUM_4118414 handling already uses
> ARM64_WORKAROUND_REPEAT_TLBI to issue an additional broadcast TLBI;DSB
> sequence and ensure affected memory write effects are globally observed.
>
> Add MIDR_NVIDIA_OLYMPUS to the repeat-TLBI match list so the same
> mitigation is enabled on affected Olympus systems. Also document the
> NVIDIA Olympus erratum in the arm64 silicon errata table and list it in
> the Kconfig help text.
>
> [...]
Applied to arm64 (for-next/errata), thanks!
[1/1] arm64: errata: Mitigate TLBI errata on NVIDIA Olympus CPU
https://git.kernel.org/arm64/c/ec7216f92e4e
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v17 21/28] drm/tests: bridge: Add KUnit tests for bridge chain format selection
From: Jani Nikula @ 2026-06-10 11:54 UTC (permalink / raw)
To: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, Daniel Stone
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel
In-Reply-To: <gnicb4WkT1S4aQIC2G_naw@collabora.com>
On Wed, 10 Jun 2026, Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
> If you don't want __maybe_unused, then sure, I'll move them into a new
> .c file. Though I think the two are roughly equivalent in that I don't
> think anyone is really trying to minimise the size of their KUnit
> binaries.
I think placing arrays in headers is bad practice, and we shouldn't set
that example, kunit or not.
> I'll send a patch to move them to a .c
Thanks.
BR,
Jani.
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH v17 21/28] drm/tests: bridge: Add KUnit tests for bridge chain format selection
From: Nicolas Frattaroli @ 2026-06-10 11:42 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, Daniel Stone, Jani Nikula
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc, wayland-devel
In-Reply-To: <04ff70850213ae0f75486b1a27a7edb6fb4e71c3@intel.com>
On Wednesday, 10 June 2026 12:32:29 Central European Summer Time Jani Nikula wrote:
> On Tue, 09 Jun 2026, Nicolas Frattaroli <nicolas.frattaroli@collabora.com> wrote:
> > diff --git a/drivers/gpu/drm/tests/drm_bridge_test.c b/drivers/gpu/drm/tests/drm_bridge_test.c
> > index 64b665580a88..92f142ca6695 100644
> > --- a/drivers/gpu/drm/tests/drm_bridge_test.c
> > +++ b/drivers/gpu/drm/tests/drm_bridge_test.c
> > @@ -2,15 +2,23 @@
> > /*
> > * Kunit test for drm_bridge functions
> > */
> > +#include <linux/cleanup.h>
> > +#include <linux/media-bus-format.h>
> > +
> > #include <drm/drm_atomic_state_helper.h>
> > +#include <drm/drm_atomic_uapi.h>
> > #include <drm/drm_bridge.h>
> > #include <drm/drm_bridge_connector.h>
> > #include <drm/drm_bridge_helper.h>
> > +#include <drm/drm_edid.h>
> > #include <drm/drm_kunit_helpers.h>
> > +#include <drm/drm_managed.h>
> >
> > #include <kunit/device.h>
> > #include <kunit/test.h>
> >
> > +#include "drm_kunit_edid.h"
>
> So here's the problem with adding *any* arrays into headers: every
> compilation unit that includes them duplicates all the arrays. It's only
> really okay for single use.
>
> And, in this case, most of the included arrays are unused, leading to
> build failures:
>
> CC [M] drivers/gpu/drm/tests/drm_bridge_test.o
> In file included from ../drivers/gpu/drm/tests/drm_bridge_test.c:21:
> ../drivers/gpu/drm/tests/drm_kunit_edid.h:958:28: error: ‘test_edid_hdmi_4k_rgb_yuv420_dc_max_340mhz’ defined but not used [-Werror=unused-const-variable=]
> 958 | static const unsigned char test_edid_hdmi_4k_rgb_yuv420_dc_max_340mhz[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../drivers/gpu/drm/tests/drm_kunit_edid.h:726:28: error: ‘test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz’ defined but not used [-Werror=unused-const-variable=]
> 726 | static const unsigned char test_edid_hdmi_1080p_rgb_yuv_dc_max_340mhz[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../drivers/gpu/drm/tests/drm_kunit_edid.h:612:28: error: ‘test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz’ defined but not used [-Werror=unused-const-variable=]
> 612 | static const unsigned char test_edid_hdmi_1080p_rgb_yuv_dc_max_200mhz[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../drivers/gpu/drm/tests/drm_kunit_edid.h:498:28: error: ‘test_edid_hdmi_1080p_rgb_max_340mhz’ defined but not used [-Werror=unused-const-variable=]
> 498 | static const unsigned char test_edid_hdmi_1080p_rgb_max_340mhz[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../drivers/gpu/drm/tests/drm_kunit_edid.h:390:28: error: ‘test_edid_hdmi_1080p_rgb_max_200mhz_hdr’ defined but not used [-Werror=unused-const-variable=]
> 390 | static const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz_hdr[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../drivers/gpu/drm/tests/drm_kunit_edid.h:271:28: error: ‘test_edid_hdmi_1080p_rgb_max_200mhz’ defined but not used [-Werror=unused-const-variable=]
> 271 | static const unsigned char test_edid_hdmi_1080p_rgb_max_200mhz[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../drivers/gpu/drm/tests/drm_kunit_edid.h:163:28: error: ‘test_edid_hdmi_1080p_rgb_max_100mhz’ defined but not used [-Werror=unused-const-variable=]
> 163 | static const unsigned char test_edid_hdmi_1080p_rgb_max_100mhz[] = {
> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> ../drivers/gpu/drm/tests/drm_kunit_edid.h:57:28: error: ‘test_edid_dvi_1080p’ defined but not used [-Werror=unused-const-variable=]
> 57 | static const unsigned char test_edid_dvi_1080p[] = {
> | ^~~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> This breaks the build for me, I don't know how it didn't for any of you.
It broke the build for me in the past[1], but then I couldn't repro
it anymore when challenged on my fix[2].
>
> Reverting these two fixes it:
>
> ce1d0139adac ("drm/tests: bridge: Add test for HDMI output bus formats helper")
> 082fbc179c01 ("drm/tests: bridge: Add KUnit tests for bridge chain format selection")
>
> I think the proper fix would be to move the arrays into a .c file, and
> only have declarations in the headers. But that needs to happen real
> soon or the commits need to be reverted.
If you don't want __maybe_unused, then sure, I'll move them into a new
.c file. Though I think the two are roughly equivalent in that I don't
think anyone is really trying to minimise the size of their KUnit
binaries.
I'll send a patch to move them to a .c
[1]: https://lore.kernel.org/dri-devel/20260121-color-format-v7-20-ef790dae780c@collabora.com/
[2]: https://lore.kernel.org/dri-devel/20260210-didactic-okapi-of-modernism-ff00d9@houat/
Kind regards,
Nicolas Frattaroli
>
> BR,
> Jani.
>
>
>
^ permalink raw reply
* Re: [PATCH v4 1/2] arm64: smp: Fix hot-unplug tearing by forcing unregistration
From: Catalin Marinas @ 2026-06-10 11:38 UTC (permalink / raw)
To: Jinjie Ruan
Cc: will, corbet, skhan, punit.agrawal, mrigendra.chaubey,
suzuki.poulose, chenl311, fengchengwen, maz, timothy.hayes,
lpieralisi, arnd, gshan, jic23, dietmar.eggemann, sudeep.holla,
pierre.gondois, linux-arm-kernel, linux-doc, linux-kernel
In-Reply-To: <20260610075202.3597031-2-ruanjinjie@huawei.com>
On Wed, Jun 10, 2026 at 03:52:01PM +0800, Jinjie Ruan wrote:
> Sashiko review pointed out the following issue[1].
>
> Commit eba4675008a6 ("arm64: arch_register_cpu() variant to check if
> an ACPI handle is now available.") introduced architectural safety
> blocks inside arch_unregister_cpu(). If a hot-unplug operation is
> determined to be a physical hardware removal (where _STA evaluates to
> !ACPI_STA_DEVICE_PRESENT), or if firmware evaluation fails, it aborts
> the unregistration transaction early to protect unreadied arm64
> infrastructure.
>
> However, returning early from arch_unregister_cpu() causes a catastrophic
> state tearing because the generic ACPI layer (acpi_processor_post_eject())
> unconditionally continues its cleanup flow. This leaves the stale sysfs
> device leaked in the memory, deadlocking any subsequent hot-add attempts
> on the same CPU.
>
> Fix it by simplifying arch_unregister_cpu() to always proceed with
> the unregistration, as a pr_err_once() warning is sufficient to make
> it more visible for currently not supported physical CPU removal.
> Also remove the redundant NULL check on acpi_handle as it cannot be
> NULL when calling arch_unregister_cpu().
>
> [1]: https://sashiko.dev/#/patchset/20260520022023.126670-1-ruanjinjie@huawei.com
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: James Morse <james.morse@arm.com>
> Cc: stable@vger.kernel.org
> Fixes: eba4675008a6e ("arm64: arch_register_cpu() variant to check if an ACPI handle is now available.")
> Suggested-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ 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