* [PATCH v8 1/5] dt-bindings: clock: airoha: Add PHY binding for Serdes port
From: Christian Marangi @ 2026-05-20 15:09 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Christian Marangi, Vinod Koul,
Neil Armstrong, Lorenzo Bianconi, Felix Fietkau, linux-clk,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
In-Reply-To: <20260520150912.11614-1-ansuelsmth@gmail.com>
Add PHY cell property for Serdes port selection. Currently supported only
for Airoha AN7581 SoC, that support up to 4 Serdes port.
The Serdes port can support both PCIe, USB3 or Ethernet mode.
- PCIe1 Serdes can support PCIe or Ethernet mode.
- PCIe2 Serdes can support PCIe or Ethernet mode.
- USB1 Serdes can support USB3 or HSGMII mode.
- USB2 Serdes can support USB3 or PCIe mode.
Add bindings to permit correct reference of the Serdes ports in DT.
Values are just symbolic and enumerates the Serdes port with a specific
number for precise reference.
The available Serdes port can be selected following the dt-binding header
in [2].
[2] <include/dt-bindings/soc/airoha,scu-ssr.h>
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
.../devicetree/bindings/clock/airoha,en7523-scu.yaml | 9 +++++++++
include/dt-bindings/soc/airoha,scu-ssr.h | 11 +++++++++++
2 files changed, 20 insertions(+)
create mode 100644 include/dt-bindings/soc/airoha,scu-ssr.h
diff --git a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
index eb24a5687639..913ddc16182b 100644
--- a/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
+++ b/Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
@@ -23,6 +23,7 @@ description: |
All these identifiers can be found in:
[1]: <include/dt-bindings/clock/en7523-clk.h>.
+ [2]: <include/dt-bindings/soc/airoha,scu-ssr.h>.
The clocks are provided inside a system controller node.
@@ -50,6 +51,12 @@ properties:
description: ID of the controller reset line
const: 1
+ '#phy-cells':
+ description:
+ The first cell indicates the serdes phy number, see [2] for the
+ available serdes port.
+ const: 1
+
required:
- compatible
- reg
@@ -65,6 +72,8 @@ allOf:
reg:
minItems: 2
+ '#phy-cells': false
+
- if:
properties:
compatible:
diff --git a/include/dt-bindings/soc/airoha,scu-ssr.h b/include/dt-bindings/soc/airoha,scu-ssr.h
new file mode 100644
index 000000000000..33c64844ada3
--- /dev/null
+++ b/include/dt-bindings/soc/airoha,scu-ssr.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
+
+#ifndef __DT_BINDINGS_AIROHA_SCU_SSR_H
+#define __DT_BINDINGS_AIROHA_SCU_SSR_H
+
+#define AIROHA_SCU_SERDES_PCIE1 0
+#define AIROHA_SCU_SERDES_PCIE2 1
+#define AIROHA_SCU_SERDES_USB1 2
+#define AIROHA_SCU_SERDES_USB2 3
+
+#endif /* __DT_BINDINGS_AIROHA_SCU_SSR_H */
--
2.53.0
^ permalink raw reply related
* [PATCH v8 0/5] airoha: an7581: USB support
From: Christian Marangi @ 2026-05-20 15:09 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Christian Marangi, Vinod Koul,
Neil Armstrong, Lorenzo Bianconi, Felix Fietkau, linux-clk,
devicetree, linux-kernel, linux-arm-kernel, linux-phy
This is a major rework of the old v2 series.
The SoC always support USB 2.0 but for USB 3.0 it needs additional
configuration for the Serdes port. Such port can be either configured
for USB usage or for PCIe lines or HSGMII and these are configured
in the SCU space.
The previous implementation of a dedicated SSR driver was too
complex and fragile for the simple task of configuring a register
hence it was dropped and the handling is entirely in the PHY driver.
Everything was reducted to the dt-bindings to describe the Serdes line.
Also the property for the PHY are renamed to a more suitable name and
everything is now mandatory to simplify the implementation.
(the PHY are always present and active on the SoC)
Also other unrelated patch are dropped from this series.
Changes v8:
- Squash header to clk Documentation patch
- Address comments from AI Bot
Changes v7:
- Rework to double PHY implementation
(suggested by Rob)
Now the clk driver expose a PHY for Serdes port
USB PHY driver selects it
- Rebase on top of linux-next
Link: https://lore.kernel.org/all/20260306190156.22297-1-ansuelsmth@gmail.com/
Changes v6:
- Fix kernel test robot (sparse warning)
Link: https://lore.kernel.org/all/20260306190156.22297-1-ansuelsmth@gmail.com/
Changes v5:
- Add Ack and Review tag from Connor
- Implement Ethernet support in the USB driver
(testing support for this Serdes on a special reference board)
- Use an7581 prefix for USB PHY driver
Link: https://lore.kernel.org/all/20251107160251.2307088-1-ansuelsmth@gmail.com/
Changes v4:
- Rename PCIe and USB PHY to AN7581
- Drop airoha,scu (handled directly in driver)
- Drop dt-bindings for monitor clock in favor of raw values
- Better describe the usage of airoha,usb3-serdes
- Simplify values of dt-bindings SSR SERDES
Link: https://lore.kernel.org/all/20251107160251.2307088-1-ansuelsmth@gmail.com/
Changes v3:
- Drop clk changes
- Drop SSR driver
- Rename property in Documentation
- Simplify PHY handling
- Move SSR handling inside the PHY driver
Link: https://lore.kernel.org/all/20251029173713.7670-1-ansuelsmth@gmail.com/
Changes v2:
- Drop changes for simple-mfd
- Rework PHY node structure to single node
- Drop port-id property in favor of serdes-port and
usb2-monitor-clock-sel
- Make the SSR driver probe from the clock driver
Christian Marangi (5):
dt-bindings: clock: airoha: Add PHY binding for Serdes port
dt-bindings: phy: Add documentation for Airoha AN7581 USB PHY
clk: en7523: Add support for selecting the Serdes port in SCU
phy: move and rename Airoha PCIe PHY driver to dedicated directory
phy: airoha: Add support for Airoha AN7581 USB PHY
.../bindings/clock/airoha,en7523-scu.yaml | 9 +
.../bindings/phy/airoha,an7581-usb-phy.yaml | 62 ++
MAINTAINERS | 11 +-
drivers/clk/Kconfig | 1 +
drivers/clk/clk-en7523.c | 216 ++++++-
drivers/phy/Kconfig | 11 +-
drivers/phy/Makefile | 4 +-
drivers/phy/airoha/Kconfig | 24 +
drivers/phy/airoha/Makefile | 4 +
.../phy-an7581-pcie-regs.h} | 2 +-
.../phy-an7581-pcie.c} | 6 +-
drivers/phy/airoha/phy-an7581-usb.c | 554 ++++++++++++++++++
include/dt-bindings/soc/airoha,scu-ssr.h | 11 +
13 files changed, 894 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/phy/airoha,an7581-usb-phy.yaml
create mode 100644 drivers/phy/airoha/Kconfig
create mode 100644 drivers/phy/airoha/Makefile
rename drivers/phy/{phy-airoha-pcie-regs.h => airoha/phy-an7581-pcie-regs.h} (99%)
rename drivers/phy/{phy-airoha-pcie.c => airoha/phy-an7581-pcie.c} (99%)
create mode 100644 drivers/phy/airoha/phy-an7581-usb.c
create mode 100644 include/dt-bindings/soc/airoha,scu-ssr.h
--
2.53.0
^ permalink raw reply
* [PATCH v2] iommu: Allow device driver to use its own PASID space for SVA
From: Joonwon Kang @ 2026-05-20 15:07 UTC (permalink / raw)
To: jgg, will, robin.murphy, joro, jpb
Cc: Alexander.Grest, amhetre, baolu.lu, easwar.hariharan,
jacob.jun.pan, kees, kevin.tian, nicolinc, praan, smostafa, tglx,
mingo, bp, dave.hansen, x86, hpa, peterz, sohil.mehta, kas,
alexander.shishkin, ryasuoka, xin, linux-kernel, iommu,
linux-arm-kernel, joonwonkang
For SVA, the IOMMU core always allocates PASID from the global PASID
space. The use of this global PASID space comes from the limitation of
the ENQCMD instruction in Intel CPUs that it fetches its PASID operand
from IA32_PASID, which is per-process; when a process wants to
communicate with multiple devices with the ENQCMD instruction, it cannot
change its PASID for each device without the kernel's intervention. Also
note that ARM introduced a similar instruction, which is ST64BV0.
Due to this nature, SVA with ARM SMMU v3 has been found not working in
our environment when other modules/devices compete for PASID. The
environment looks as follows:
- The device is not a PCIe device.
- The device is to use SVA.
- The supported SSID/PASID space is very small for the device; only 1 to
3 SSIDs are supported.
With this setup, when other modules have allocated all the PASIDs that
our device is expected to use from the global PASID space via APIs like
iommu_alloc_global_pasid() or iommu_sva_bind_device(), SVA binding to
our device fails due to the lack of available PASIDs.
This commit resolves the issue by allowing device driver to maintain its
own PASID space and assign a PASID from that for the process-device bond
via a new API called `iommu_sva_bind_device_pasid(dev, mm, pasid)`. Doing
that, however, will disallow the process to execute the ENQCMD-like
instructions at EL0. It is because the process cannot change its PASID in
IA32_PASID(or ACCDATA_EL1 on ARM) for each device without the kernel's
intervention. For this reason, calling `iommu_sva_bind_device()` and then
`iommu_sva_bind_device_pasid()` for the same process will not be allowed
and vice versa.
Currently, there is a limitation that a process simultaneously doing SVA
with multiple devices with different PASIDs is not supported. So, calling
`iommu_sva_bind_device_pasid()` multiple times for the same process with
different devices will not be allowed for now while that for
`iommu_sva_bind_device()` will be.
Another limitation is that a process cannot do `iommu_sva_bind_device()`
if it has ever done `iommu_sva_bind_device_pasid()` even though it has
been unbound after use.
Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Suggested-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Joonwon Kang <joonwonkang@google.com>
---
v2: Reuse iommu_mm->pasid after SVA bound by iommu_sva_bind_device_pasid()
is unbound.
v1: Initial version.
arch/x86/kernel/traps.c | 9 +--
drivers/iommu/iommu-sva.c | 151 +++++++++++++++++++++++++++++---------
include/linux/iommu.h | 14 +++-
3 files changed, 134 insertions(+), 40 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 0ca3912ecb7f..0131c8e5fb10 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -857,13 +857,12 @@ static bool try_fixup_enqcmd_gp(void)
return false;
/*
- * If the mm has not been allocated a
- * PASID, the #GP can not be fixed up.
+ * If the mm has not been allocated a PASID or ENQCMD has been
+ * disallowed, the #GP can not be fixed up.
*/
- if (!mm_valid_pasid(current->mm))
- return false;
-
pasid = mm_get_enqcmd_pasid(current->mm);
+ if (pasid == IOMMU_PASID_INVALID)
+ return false;
/*
* Did this thread already have its PASID activated?
diff --git a/drivers/iommu/iommu-sva.c b/drivers/iommu/iommu-sva.c
index bc7c7232a43e..a83333651ad0 100644
--- a/drivers/iommu/iommu-sva.c
+++ b/drivers/iommu/iommu-sva.c
@@ -10,6 +10,9 @@
#include "iommu-priv.h"
+/* Whether pasid is to be allocated from the global PASID space */
+#define IOMMU_PASID_GLOBAL_ANY IOMMU_NO_PASID
+
static DEFINE_MUTEX(iommu_sva_lock);
static bool iommu_sva_present;
static LIST_HEAD(iommu_sva_mms);
@@ -17,10 +20,11 @@ static struct iommu_domain *iommu_sva_domain_alloc(struct device *dev,
struct mm_struct *mm);
/* Allocate a PASID for the mm within range (inclusive) */
-static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct device *dev)
+static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm,
+ struct device *dev,
+ ioasid_t pasid)
{
struct iommu_mm_data *iommu_mm;
- ioasid_t pasid;
lockdep_assert_held(&iommu_sva_lock);
@@ -30,8 +34,27 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de
iommu_mm = mm->iommu_mm;
/* Is a PASID already associated with this mm? */
if (iommu_mm) {
+ if ((pasid == IOMMU_PASID_GLOBAL_ANY && !iommu_mm->pasid_global) ||
+ (pasid != IOMMU_PASID_GLOBAL_ANY && iommu_mm->pasid_global))
+ return ERR_PTR(-EBUSY);
+
+ if (!iommu_mm->pasid_global) {
+ if (list_empty(&iommu_mm->sva_domains))
+ iommu_mm->pasid = pasid;
+
+ if (pasid != iommu_mm->pasid) {
+ /*
+ * Currently, a process simultaneously doing
+ * SVA with multiple devices with different
+ * PASIDs is not supported.
+ */
+ return ERR_PTR(-ENOSPC);
+ }
+ }
+
if (iommu_mm->pasid >= dev->iommu->max_pasids)
return ERR_PTR(-EOVERFLOW);
+
return iommu_mm;
}
@@ -39,37 +62,30 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de
if (!iommu_mm)
return ERR_PTR(-ENOMEM);
- pasid = iommu_alloc_global_pasid(dev);
- if (pasid == IOMMU_PASID_INVALID) {
- kfree(iommu_mm);
- return ERR_PTR(-ENOSPC);
+ if (pasid == IOMMU_PASID_GLOBAL_ANY) {
+ pasid = iommu_alloc_global_pasid(dev);
+ if (pasid == IOMMU_PASID_INVALID) {
+ kfree(iommu_mm);
+ return ERR_PTR(-ENOSPC);
+ }
+ iommu_mm->pasid_global = true;
+ } else {
+ if (pasid >= dev->iommu->max_pasids) {
+ kfree(iommu_mm);
+ return ERR_PTR(-EOVERFLOW);
+ }
+ iommu_mm->pasid_global = false;
}
iommu_mm->pasid = pasid;
iommu_mm->mm = mm;
INIT_LIST_HEAD(&iommu_mm->sva_domains);
- /*
- * Make sure the write to mm->iommu_mm is not reordered in front of
- * initialization to iommu_mm fields. If it does, readers may see a
- * valid iommu_mm with uninitialized values.
- */
- smp_store_release(&mm->iommu_mm, iommu_mm);
+
return iommu_mm;
}
-/**
- * iommu_sva_bind_device() - Bind a process address space to a device
- * @dev: the device
- * @mm: the mm to bind, caller must hold a reference to mm_users
- *
- * Create a bond between device and address space, allowing the device to
- * access the mm using the PASID returned by iommu_sva_get_pasid(). If a
- * bond already exists between @device and @mm, an additional internal
- * reference is taken. Caller must call iommu_sva_unbind_device()
- * to release each reference.
- *
- * On error, returns an ERR_PTR value.
- */
-struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
+static struct iommu_sva *iommu_sva_bind_device_internal(struct device *dev,
+ struct mm_struct *mm,
+ ioasid_t pasid)
{
struct iommu_group *group = dev->iommu_group;
struct iommu_attach_handle *attach_handle;
@@ -84,7 +100,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
mutex_lock(&iommu_sva_lock);
/* Allocate mm->pasid if necessary. */
- iommu_mm = iommu_alloc_mm_data(mm, dev);
+ iommu_mm = iommu_alloc_mm_data(mm, dev, pasid);
if (IS_ERR(iommu_mm)) {
ret = PTR_ERR(iommu_mm);
goto out_unlock;
@@ -96,7 +112,7 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
handle = container_of(attach_handle, struct iommu_sva, handle);
if (attach_handle->domain->mm != mm) {
ret = -EBUSY;
- goto out_unlock;
+ goto out_free_iommu_mm;
}
refcount_inc(&handle->users);
mutex_unlock(&iommu_sva_lock);
@@ -105,17 +121,17 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
if (PTR_ERR(attach_handle) != -ENOENT) {
ret = PTR_ERR(attach_handle);
- goto out_unlock;
+ goto out_free_iommu_mm;
}
handle = kzalloc_obj(*handle);
if (!handle) {
ret = -ENOMEM;
- goto out_unlock;
+ goto out_free_iommu_mm;
}
/* Search for an existing domain. */
- list_for_each_entry(domain, &mm->iommu_mm->sva_domains, next) {
+ list_for_each_entry(domain, &iommu_mm->sva_domains, next) {
ret = iommu_attach_device_pasid(domain, dev, iommu_mm->pasid,
&handle->handle);
if (!ret) {
@@ -143,6 +159,15 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
list_add(&iommu_mm->mm_list_elm, &iommu_sva_mms);
}
list_add(&domain->next, &iommu_mm->sva_domains);
+ if (!mm->iommu_mm) {
+ /*
+ * Make sure the write to mm->iommu_mm is not reordered in
+ * front of initialization to iommu_mm fields. If it does,
+ * readers may see a valid iommu_mm with uninitialized values.
+ */
+ smp_store_release(&mm->iommu_mm, iommu_mm);
+ }
+
out:
refcount_set(&handle->users, 1);
mutex_unlock(&iommu_sva_lock);
@@ -153,12 +178,66 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
iommu_domain_free(domain);
out_free_handle:
kfree(handle);
+out_free_iommu_mm:
+ if (!mm->iommu_mm) {
+ if (iommu_mm->pasid_global)
+ iommu_free_global_pasid(iommu_mm->pasid);
+ kfree(iommu_mm);
+ }
out_unlock:
mutex_unlock(&iommu_sva_lock);
return ERR_PTR(ret);
}
+
+/**
+ * iommu_sva_bind_device() - Bind a process address space to a device
+ * @dev: the device
+ * @mm: the mm to bind, caller must hold a reference to mm_users
+ *
+ * Create a bond between device and address space, allowing the device to
+ * access the mm using the PASID returned by iommu_sva_get_pasid(). If a
+ * bond already exists between @device and @mm, an additional internal
+ * reference is taken. Caller must call iommu_sva_unbind_device()
+ * to release each reference.
+ *
+ * On error, returns an ERR_PTR value.
+ */
+struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
+{
+ return iommu_sva_bind_device_internal(dev, mm, IOMMU_PASID_GLOBAL_ANY);
+}
EXPORT_SYMBOL_GPL(iommu_sva_bind_device);
+/**
+ * iommu_sva_bind_device_pasid() - Bind a process address space to a device
+ * with a designated pasid
+ * @dev: the device
+ * @mm: the mm to bind, caller must hold a reference to mm_users
+ * @pasid: the pasid to assign to the bond
+ *
+ * Create a bond between device and address space, allowing the device to
+ * access the mm using the PASID returned by iommu_sva_get_pasid(). If a
+ * bond already exists between @device and @mm, an additional internal
+ * reference is taken. Caller must call iommu_sva_unbind_device()
+ * to release each reference.
+ *
+ * It is the caller's responsibility to maintain the PASID space for @pasid.
+ * After the bond is created, the process for @mm will not be able to execute
+ * ENQCMD or similar instructions at EL0. To allow those instructions at EL0,
+ * iommu_sva_bind_device() must be used instead.
+ *
+ * On error, returns an ERR_PTR value.
+ */
+struct iommu_sva *iommu_sva_bind_device_pasid(struct device *dev,
+ struct mm_struct *mm,
+ ioasid_t pasid)
+{
+ if (pasid == IOMMU_PASID_GLOBAL_ANY)
+ return ERR_PTR(-EINVAL);
+ return iommu_sva_bind_device_internal(dev, mm, pasid);
+}
+EXPORT_SYMBOL_GPL(iommu_sva_bind_device_pasid);
+
/**
* iommu_sva_unbind_device() - Remove a bond created with iommu_sva_bind_device
* @handle: the handle returned by iommu_sva_bind_device()
@@ -198,9 +277,12 @@ EXPORT_SYMBOL_GPL(iommu_sva_unbind_device);
u32 iommu_sva_get_pasid(struct iommu_sva *handle)
{
- struct iommu_domain *domain = handle->handle.domain;
+ struct iommu_mm_data *iommu_mm = handle->handle.domain->mm->iommu_mm;
+
+ if (!iommu_mm)
+ return IOMMU_PASID_INVALID;
- return mm_get_enqcmd_pasid(domain->mm);
+ return iommu_mm->pasid;
}
EXPORT_SYMBOL_GPL(iommu_sva_get_pasid);
@@ -211,7 +293,8 @@ void mm_pasid_drop(struct mm_struct *mm)
if (!iommu_mm)
return;
- iommu_free_global_pasid(iommu_mm->pasid);
+ if (iommu_mm->pasid_global)
+ iommu_free_global_pasid(iommu_mm->pasid);
kfree(iommu_mm);
}
diff --git a/include/linux/iommu.h b/include/linux/iommu.h
index e587d4ac4d33..5b6116e7152d 100644
--- a/include/linux/iommu.h
+++ b/include/linux/iommu.h
@@ -1140,6 +1140,7 @@ struct iommu_sva {
struct iommu_mm_data {
u32 pasid;
+ bool pasid_global;
struct mm_struct *mm;
struct list_head sva_domains;
struct list_head mm_list_elm;
@@ -1626,7 +1627,7 @@ static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
{
struct iommu_mm_data *iommu_mm = READ_ONCE(mm->iommu_mm);
- if (!iommu_mm)
+ if (!iommu_mm || !iommu_mm->pasid_global)
return IOMMU_PASID_INVALID;
return iommu_mm->pasid;
}
@@ -1634,6 +1635,9 @@ static inline u32 mm_get_enqcmd_pasid(struct mm_struct *mm)
void mm_pasid_drop(struct mm_struct *mm);
struct iommu_sva *iommu_sva_bind_device(struct device *dev,
struct mm_struct *mm);
+struct iommu_sva *iommu_sva_bind_device_pasid(struct device *dev,
+ struct mm_struct *mm,
+ ioasid_t pasid);
void iommu_sva_unbind_device(struct iommu_sva *handle);
u32 iommu_sva_get_pasid(struct iommu_sva *handle);
void iommu_sva_invalidate_kva_range(unsigned long start, unsigned long end);
@@ -1644,6 +1648,14 @@ iommu_sva_bind_device(struct device *dev, struct mm_struct *mm)
return ERR_PTR(-ENODEV);
}
+static inline struct iommu_sva *
+iommu_sva_bind_device_pasid(struct device *dev,
+ struct mm_struct *mm,
+ ioasid_t pasid)
+{
+ return ERR_PTR(-ENODEV);
+}
+
static inline void iommu_sva_unbind_device(struct iommu_sva *handle)
{
}
--
2.54.0.631.ge1b05301d1-goog
^ permalink raw reply related
* Re: [PATCH v5 5/9] mfd: mt6397: Add support for MT6392 PMIC
From: Lee Jones @ 2026-05-20 15:00 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Fabien Parent, Val Packett,
AngeloGioacchino Del Regno, Dmitry Torokhov, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sen Chu, Sean Wang,
Macpaul Lin, Matthias Brugger, Linus Walleij, Liam Girdwood,
Mark Brown, Gary Bisson, Louis-Alexis Eyraud, Julien Massot,
Akari Tsuyukusa, Chen Zhong, linux-input, devicetree,
linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <20260420213529.1645560-6-l.scorcia@gmail.com>
On Mon, 20 Apr 2026, Luca Leonardo Scorcia wrote:
> From: Fabien Parent <parent.f@gmail.com>
>
> Align the MT6397 PMIC driver to other MFD drivers by passing only an
> identifier through mt6397_of_match[*].data and add support for the MT6392
> PMIC.
>
> Signed-off-by: Fabien Parent <parent.f@gmail.com>
> Signed-off-by: Val Packett <val@packett.cool>
> Signed-off-by: Luca Leonardo Scorcia <l.scorcia@gmail.com>
> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/mfd/mt6397-core.c | 118 +++++--
> drivers/mfd/mt6397-irq.c | 8 +
> include/linux/mfd/mt6392/core.h | 42 +++
> include/linux/mfd/mt6392/registers.h | 487 +++++++++++++++++++++++++++
> include/linux/mfd/mt6397/core.h | 1 +
> 5 files changed, 630 insertions(+), 26 deletions(-)
> create mode 100644 include/linux/mfd/mt6392/core.h
> create mode 100644 include/linux/mfd/mt6392/registers.h
>
> diff --git "a/drivers/mfd/mt6397-core.c" "b/drivers/mfd/mt6397-core.c"
> index 1bdacda9a933..5c5c24517c00 100644
> --- "a/drivers/mfd/mt6397-core.c"
> +++ "b/drivers/mfd/mt6397-core.c"
> @@ -18,6 +18,7 @@
> #include <linux/mfd/mt6357/core.h>
> #include <linux/mfd/mt6358/core.h>
> #include <linux/mfd/mt6359/core.h>
> +#include <linux/mfd/mt6392/core.h>
> #include <linux/mfd/mt6397/core.h>
> #include <linux/mfd/mt6323/registers.h>
> #include <linux/mfd/mt6328/registers.h>
> @@ -25,8 +26,20 @@
> #include <linux/mfd/mt6357/registers.h>
> #include <linux/mfd/mt6358/registers.h>
> #include <linux/mfd/mt6359/registers.h>
> +#include <linux/mfd/mt6392/registers.h>
> #include <linux/mfd/mt6397/registers.h>
>
> +enum mfd_match_data {
> + MATCH_DATA_MT6323 = 23,
> + MATCH_DATA_MT6328 = 28,
> + MATCH_DATA_MT6331 = 31,
> + MATCH_DATA_MT6357 = 57,
> + MATCH_DATA_MT6358 = 58,
> + MATCH_DATA_MT6359 = 59,
> + MATCH_DATA_MT6392 = 92,
> + MATCH_DATA_MT6397 = 97,
> +};
> +
> #define MT6323_RTC_BASE 0x8000
> #define MT6323_RTC_SIZE 0x40
>
> @@ -39,6 +52,9 @@
> #define MT6358_RTC_BASE 0x0588
> #define MT6358_RTC_SIZE 0x3c
>
> +#define MT6392_RTC_BASE 0x8000
> +#define MT6392_RTC_SIZE 0x3e
> +
> #define MT6397_RTC_BASE 0xe000
> #define MT6397_RTC_SIZE 0x3e
>
> @@ -65,6 +81,11 @@ static const struct resource mt6358_rtc_resources[] = {
> DEFINE_RES_IRQ(MT6358_IRQ_RTC),
> };
>
> +static const struct resource mt6392_rtc_resources[] = {
> + DEFINE_RES_MEM(MT6392_RTC_BASE, MT6392_RTC_SIZE),
> + DEFINE_RES_IRQ(MT6392_IRQ_RTC),
> +};
> +
> static const struct resource mt6397_rtc_resources[] = {
> DEFINE_RES_MEM(MT6397_RTC_BASE, MT6397_RTC_SIZE),
> DEFINE_RES_IRQ(MT6397_IRQ_RTC),
> @@ -114,6 +135,11 @@ static const struct resource mt6331_keys_resources[] = {
> DEFINE_RES_IRQ_NAMED(MT6331_IRQ_STATUS_HOMEKEY, "homekey"),
> };
>
> +static const struct resource mt6392_keys_resources[] = {
> + DEFINE_RES_IRQ_NAMED(MT6392_IRQ_PWRKEY, "powerkey"),
> + DEFINE_RES_IRQ_NAMED(MT6392_IRQ_FCHRKEY, "homekey"),
What does FCHRKEY mean? Is that a datasheet name?
> +};
> +
> static const struct resource mt6397_keys_resources[] = {
> DEFINE_RES_IRQ_NAMED(MT6397_IRQ_PWRKEY, "powerkey"),
> DEFINE_RES_IRQ_NAMED(MT6397_IRQ_HOMEKEY, "homekey"),
> @@ -253,6 +279,25 @@ static const struct mfd_cell mt6359_devs[] = {
> },
> };
>
> +static const struct mfd_cell mt6392_devs[] = {
> + {
> + .name = "mt6392-rtc",
> + .num_resources = ARRAY_SIZE(mt6392_rtc_resources),
> + .resources = mt6392_rtc_resources,
> + .of_compatible = "mediatek,mt6392-rtc",
> + }, {
> + .name = "mt6392-regulator",
> + }, {
> + .name = "mt6392-pinctrl",
> + .of_compatible = "mediatek,mt6392-pinctrl",
> + }, {
> + .name = "mt6392-keys",
> + .num_resources = ARRAY_SIZE(mt6392_keys_resources),
> + .resources = mt6392_keys_resources,
> + .of_compatible = "mediatek,mt6392-keys"
> + },
MFD_CELL_*() for each.
> +};
> +
> static const struct mfd_cell mt6397_devs[] = {
> {
> .name = "mt6397-rtc",
> @@ -335,6 +380,14 @@ static const struct chip_data mt6359_core = {
> .irq_init = mt6358_irq_init,
> };
>
> +static const struct chip_data mt6392_core = {
> + .cid_addr = MT6392_CID,
> + .cid_shift = 0,
> + .cells = mt6392_devs,
> + .cell_size = ARRAY_SIZE(mt6392_devs),
> + .irq_init = mt6397_irq_init,
> +};
> +
> static const struct chip_data mt6397_core = {
> .cid_addr = MT6397_CID,
> .cid_shift = 0,
> @@ -349,6 +402,7 @@ static int mt6397_probe(struct platform_device *pdev)
> unsigned int id = 0;
> struct mt6397_chip *pmic;
> const struct chip_data *pmic_core;
> + enum mfd_match_data device_data;
>
> pmic = devm_kzalloc(&pdev->dev, sizeof(*pmic), GFP_KERNEL);
> if (!pmic)
> @@ -364,9 +418,36 @@ static int mt6397_probe(struct platform_device *pdev)
> if (!pmic->regmap)
> return -ENODEV;
>
> - pmic_core = of_device_get_match_data(&pdev->dev);
> - if (!pmic_core)
> + device_data = (unsigned int)(uintptr_t)of_device_get_match_data(&pdev->dev);
We should be using generic match data variants now like device_get_match_data().
device_data should be chip_id or something.
> + switch (device_data) {
> + case MATCH_DATA_MT6323:
Pick some better nomenclature.
Ignore the fact that we're using these values in match data.
Do they have real differences, ideally ones which can be read from h/w?
> + pmic_core = &mt6323_core;
> + break;
> + case MATCH_DATA_MT6328:
> + pmic_core = &mt6328_core;
> + break;
> + case MATCH_DATA_MT6331:
> + pmic_core = &mt6331_mt6332_core;
> + break;
> + case MATCH_DATA_MT6357:
> + pmic_core = &mt6357_core;
> + break;
> + case MATCH_DATA_MT6358:
> + pmic_core = &mt6358_core;
> + break;
> + case MATCH_DATA_MT6359:
> + pmic_core = &mt6359_core;
> + break;
> + case MATCH_DATA_MT6392:
> + pmic_core = &mt6392_core;
> + break;
> + case MATCH_DATA_MT6397:
> + pmic_core = &mt6397_core;
> + break;
> + default:
> + dev_err(&pdev->dev, "Unknown device match data %u\n", device_data);
The user doesn't care about your match data.
"Device not supported"
> return -ENODEV;
> + }
>
> ret = regmap_read(pmic->regmap, pmic_core->cid_addr, &id);
> if (ret) {
> @@ -398,30 +479,15 @@ static int mt6397_probe(struct platform_device *pdev)
> }
>
> static const struct of_device_id mt6397_of_match[] = {
> - {
> - .compatible = "mediatek,mt6323",
> - .data = &mt6323_core,
> - }, {
> - .compatible = "mediatek,mt6328",
> - .data = &mt6328_core,
> - }, {
> - .compatible = "mediatek,mt6331",
> - .data = &mt6331_mt6332_core,
> - }, {
> - .compatible = "mediatek,mt6357",
> - .data = &mt6357_core,
> - }, {
> - .compatible = "mediatek,mt6358",
> - .data = &mt6358_core,
> - }, {
> - .compatible = "mediatek,mt6359",
> - .data = &mt6359_core,
> - }, {
> - .compatible = "mediatek,mt6397",
> - .data = &mt6397_core,
> - }, {
> - /* sentinel */
> - }
> + { .compatible = "mediatek,mt6323", .data = (void *)MATCH_DATA_MT6323, },
> + { .compatible = "mediatek,mt6328", .data = (void *)MATCH_DATA_MT6328, },
> + { .compatible = "mediatek,mt6331", .data = (void *)MATCH_DATA_MT6331, },
> + { .compatible = "mediatek,mt6357", .data = (void *)MATCH_DATA_MT6357, },
> + { .compatible = "mediatek,mt6358", .data = (void *)MATCH_DATA_MT6358, },
> + { .compatible = "mediatek,mt6359", .data = (void *)MATCH_DATA_MT6359, },
> + { .compatible = "mediatek,mt6392", .data = (void *)MATCH_DATA_MT6392, },
> + { .compatible = "mediatek,mt6397", .data = (void *)MATCH_DATA_MT6397, },
This is much better.
Maybe we can get rid of the bespoke 'struct chip_data' now?
> + { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, mt6397_of_match);
>
> diff --git "a/drivers/mfd/mt6397-irq.c" "b/drivers/mfd/mt6397-irq.c"
> index 5d2e5459f744..80ea5b92d232 100644
> --- "a/drivers/mfd/mt6397-irq.c"
> +++ "b/drivers/mfd/mt6397-irq.c"
> @@ -15,6 +15,8 @@
> #include <linux/mfd/mt6328/registers.h>
> #include <linux/mfd/mt6331/core.h>
> #include <linux/mfd/mt6331/registers.h>
> +#include <linux/mfd/mt6392/core.h>
> +#include <linux/mfd/mt6392/registers.h>
> #include <linux/mfd/mt6397/core.h>
> #include <linux/mfd/mt6397/registers.h>
>
> @@ -203,6 +205,12 @@ int mt6397_irq_init(struct mt6397_chip *chip)
> chip->int_status[0] = MT6397_INT_STATUS0;
> chip->int_status[1] = MT6397_INT_STATUS1;
> break;
> + case MT6392_CHIP_ID:
> + chip->int_con[0] = MT6392_INT_CON0;
> + chip->int_con[1] = MT6392_INT_CON1;
> + chip->int_status[0] = MT6392_INT_STATUS0;
> + chip->int_status[1] = MT6392_INT_STATUS1;
> + break;
>
> default:
> dev_err(chip->dev, "unsupported chip: 0x%x\n", chip->chip_id);
> diff --git "a/include/linux/mfd/mt6392/core.h" "b/include/linux/mfd/mt6392/core.h"
> new file mode 100644
> index 000000000000..4780dab4da92
> --- /dev/null
> +++ "b/include/linux/mfd/mt6392/core.h"
> @@ -0,0 +1,42 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
This needs an update.
> + * Author: Chen Zhong <chen.zhong@mediatek.com>
> + */
> +
> +#ifndef __MFD_MT6392_CORE_H__
> +#define __MFD_MT6392_CORE_H__
> +
> +enum mt6392_irq_numbers {
> + MT6392_IRQ_SPKL_AB = 0,
> + MT6392_IRQ_SPKL,
> + MT6392_IRQ_BAT_L,
> + MT6392_IRQ_BAT_H,
> + MT6392_IRQ_WATCHDOG,
> + MT6392_IRQ_PWRKEY,
> + MT6392_IRQ_THR_L,
> + MT6392_IRQ_THR_H,
> + MT6392_IRQ_VBATON_UNDET,
> + MT6392_IRQ_BVALID_DET,
> + MT6392_IRQ_CHRDET,
> + MT6392_IRQ_OV,
> + MT6392_IRQ_LDO = 16,
> + MT6392_IRQ_FCHRKEY,
> + MT6392_IRQ_RELEASE_PWRKEY,
> + MT6392_IRQ_RELEASE_FCHRKEY,
> + MT6392_IRQ_RTC,
> + MT6392_IRQ_VPROC,
> + MT6392_IRQ_VSYS,
> + MT6392_IRQ_VCORE,
> + MT6392_IRQ_TYPE_C_CC,
> + MT6392_IRQ_TYPEC_H_MAX,
> + MT6392_IRQ_TYPEC_H_MIN,
> + MT6392_IRQ_TYPEC_L_MAX,
> + MT6392_IRQ_TYPEC_L_MIN,
> + MT6392_IRQ_THR_MAX,
> + MT6392_IRQ_THR_MIN,
> + MT6392_IRQ_NAG_C_DLTV,
> + MT6392_IRQ_NR,
> +};
> +
> +#endif /* __MFD_MT6392_CORE_H__ */
> diff --git "a/include/linux/mfd/mt6392/registers.h" "b/include/linux/mfd/mt6392/registers.h"
> new file mode 100644
> index 000000000000..4f3a6db830d1
> --- /dev/null
> +++ "b/include/linux/mfd/mt6392/registers.h"
> @@ -0,0 +1,487 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) 2020 MediaTek Inc.
Same and throughout.
> + * Author: Chen Zhong <chen.zhong@mediatek.com>
> + */
> +
> +#ifndef __MFD_MT6392_REGISTERS_H__
> +#define __MFD_MT6392_REGISTERS_H__
> +
> +/* PMIC Registers */
> +#define MT6392_CHR_CON0 0x0000
> +#define MT6392_CHR_CON1 0x0002
> +#define MT6392_CHR_CON2 0x0004
> +#define MT6392_CHR_CON3 0x0006
> +#define MT6392_CHR_CON4 0x0008
> +#define MT6392_CHR_CON5 0x000A
> +#define MT6392_CHR_CON6 0x000C
> +#define MT6392_CHR_CON7 0x000E
> +#define MT6392_CHR_CON8 0x0010
> +#define MT6392_CHR_CON9 0x0012
> +#define MT6392_CHR_CON10 0x0014
> +#define MT6392_CHR_CON11 0x0016
> +#define MT6392_CHR_CON12 0x0018
> +#define MT6392_CHR_CON13 0x001A
> +#define MT6392_CHR_CON14 0x001C
> +#define MT6392_CHR_CON15 0x001E
> +#define MT6392_CHR_CON16 0x0020
> +#define MT6392_CHR_CON17 0x0022
> +#define MT6392_CHR_CON18 0x0024
> +#define MT6392_CHR_CON19 0x0026
> +#define MT6392_CHR_CON20 0x0028
> +#define MT6392_CHR_CON21 0x002A
> +#define MT6392_CHR_CON22 0x002C
> +#define MT6392_CHR_CON23 0x002E
> +#define MT6392_CHR_CON24 0x0030
> +#define MT6392_CHR_CON25 0x0032
> +#define MT6392_CHR_CON26 0x0034
> +#define MT6392_CHR_CON27 0x0036
> +#define MT6392_CHR_CON28 0x0038
> +#define MT6392_CHR_CON29 0x003A
> +#define MT6392_STRUP_CON0 0x003C
> +#define MT6392_STRUP_CON2 0x003E
> +#define MT6392_STRUP_CON3 0x0040
> +#define MT6392_STRUP_CON4 0x0042
> +#define MT6392_STRUP_CON5 0x0044
> +#define MT6392_STRUP_CON6 0x0046
> +#define MT6392_STRUP_CON7 0x0048
> +#define MT6392_STRUP_CON8 0x004A
> +#define MT6392_STRUP_CON9 0x004C
> +#define MT6392_STRUP_CON10 0x004E
> +#define MT6392_STRUP_CON11 0x0050
> +#define MT6392_SPK_CON0 0x0052
> +#define MT6392_SPK_CON1 0x0054
> +#define MT6392_SPK_CON2 0x0056
> +#define MT6392_SPK_CON6 0x005E
> +#define MT6392_SPK_CON7 0x0060
> +#define MT6392_SPK_CON8 0x0062
> +#define MT6392_SPK_CON9 0x0064
> +#define MT6392_SPK_CON10 0x0066
> +#define MT6392_SPK_CON11 0x0068
> +#define MT6392_SPK_CON12 0x006A
> +#define MT6392_STRUP_CON12 0x006E
> +#define MT6392_STRUP_CON13 0x0070
> +#define MT6392_STRUP_CON14 0x0072
> +#define MT6392_STRUP_CON15 0x0074
> +#define MT6392_STRUP_CON16 0x0076
> +#define MT6392_STRUP_CON17 0x0078
> +#define MT6392_STRUP_CON18 0x007A
> +#define MT6392_STRUP_CON19 0x007C
> +#define MT6392_STRUP_CON20 0x007E
> +#define MT6392_CID 0x0100
> +#define MT6392_TOP_CKPDN0 0x0102
> +#define MT6392_TOP_CKPDN0_SET 0x0104
> +#define MT6392_TOP_CKPDN0_CLR 0x0106
> +#define MT6392_TOP_CKPDN1 0x0108
> +#define MT6392_TOP_CKPDN1_SET 0x010A
> +#define MT6392_TOP_CKPDN1_CLR 0x010C
> +#define MT6392_TOP_CKPDN2 0x010E
> +#define MT6392_TOP_CKPDN2_SET 0x0110
> +#define MT6392_TOP_CKPDN2_CLR 0x0112
> +#define MT6392_TOP_RST_CON 0x0114
> +#define MT6392_TOP_RST_CON_SET 0x0116
> +#define MT6392_TOP_RST_CON_CLR 0x0118
> +#define MT6392_TOP_RST_MISC 0x011A
> +#define MT6392_TOP_RST_MISC_SET 0x011C
> +#define MT6392_TOP_RST_MISC_CLR 0x011E
> +#define MT6392_TOP_CKCON0 0x0120
> +#define MT6392_TOP_CKCON0_SET 0x0122
> +#define MT6392_TOP_CKCON0_CLR 0x0124
> +#define MT6392_TOP_CKCON1 0x0126
> +#define MT6392_TOP_CKCON1_SET 0x0128
> +#define MT6392_TOP_CKCON1_CLR 0x012A
> +#define MT6392_TOP_CKTST0 0x012C
> +#define MT6392_TOP_CKTST1 0x012E
> +#define MT6392_TOP_CKTST2 0x0130
> +#define MT6392_TEST_OUT 0x0132
> +#define MT6392_TEST_CON0 0x0134
> +#define MT6392_TEST_CON1 0x0136
> +#define MT6392_EN_STATUS0 0x0138
> +#define MT6392_EN_STATUS1 0x013A
> +#define MT6392_OCSTATUS0 0x013C
> +#define MT6392_OCSTATUS1 0x013E
> +#define MT6392_PGSTATUS 0x0140
> +#define MT6392_CHRSTATUS 0x0142
> +#define MT6392_TDSEL_CON 0x0144
> +#define MT6392_RDSEL_CON 0x0146
> +#define MT6392_SMT_CON0 0x0148
> +#define MT6392_SMT_CON1 0x014A
> +#define MT6392_DRV_CON0 0x0152
> +#define MT6392_DRV_CON1 0x0154
> +#define MT6392_INT_CON0 0x0160
> +#define MT6392_INT_CON0_SET 0x0162
> +#define MT6392_INT_CON0_CLR 0x0164
> +#define MT6392_INT_CON1 0x0166
> +#define MT6392_INT_CON1_SET 0x0168
> +#define MT6392_INT_CON1_CLR 0x016A
> +#define MT6392_INT_MISC_CON 0x016C
> +#define MT6392_INT_MISC_CON_SET 0x016E
> +#define MT6392_INT_MISC_CON_CLR 0x0170
> +#define MT6392_INT_STATUS0 0x0172
> +#define MT6392_INT_STATUS1 0x0174
> +#define MT6392_OC_GEAR_0 0x0176
> +#define MT6392_OC_GEAR_1 0x0178
> +#define MT6392_OC_GEAR_2 0x017A
> +#define MT6392_OC_CTL_VPROC 0x017C
> +#define MT6392_OC_CTL_VSYS 0x017E
> +#define MT6392_OC_CTL_VCORE 0x0180
> +#define MT6392_FQMTR_CON0 0x0182
> +#define MT6392_FQMTR_CON1 0x0184
> +#define MT6392_FQMTR_CON2 0x0186
> +#define MT6392_RG_SPI_CON 0x0188
> +#define MT6392_DEW_DIO_EN 0x018A
> +#define MT6392_DEW_READ_TEST 0x018C
> +#define MT6392_DEW_WRITE_TEST 0x018E
> +#define MT6392_DEW_CRC_SWRST 0x0190
> +#define MT6392_DEW_CRC_EN 0x0192
> +#define MT6392_DEW_CRC_VAL 0x0194
> +#define MT6392_DEW_DBG_MON_SEL 0x0196
> +#define MT6392_DEW_CIPHER_KEY_SEL 0x0198
> +#define MT6392_DEW_CIPHER_IV_SEL 0x019A
> +#define MT6392_DEW_CIPHER_EN 0x019C
> +#define MT6392_DEW_CIPHER_RDY 0x019E
> +#define MT6392_DEW_CIPHER_MODE 0x01A0
> +#define MT6392_DEW_CIPHER_SWRST 0x01A2
> +#define MT6392_DEW_RDDMY_NO 0x01A4
> +#define MT6392_DEW_RDATA_DLY_SEL 0x01A6
> +#define MT6392_CLK_TRIM_CON0 0x01A8
> +#define MT6392_BUCK_CON0 0x0200
> +#define MT6392_BUCK_CON1 0x0202
> +#define MT6392_BUCK_CON2 0x0204
> +#define MT6392_BUCK_CON3 0x0206
> +#define MT6392_BUCK_CON4 0x0208
> +#define MT6392_BUCK_CON5 0x020A
> +#define MT6392_VPROC_CON0 0x020C
> +#define MT6392_VPROC_CON1 0x020E
> +#define MT6392_VPROC_CON2 0x0210
> +#define MT6392_VPROC_CON3 0x0212
> +#define MT6392_VPROC_CON4 0x0214
> +#define MT6392_VPROC_CON5 0x0216
> +#define MT6392_VPROC_CON7 0x021A
> +#define MT6392_VPROC_CON8 0x021C
> +#define MT6392_VPROC_CON9 0x021E
> +#define MT6392_VPROC_CON10 0x0220
> +#define MT6392_VPROC_CON11 0x0222
> +#define MT6392_VPROC_CON12 0x0224
> +#define MT6392_VPROC_CON13 0x0226
> +#define MT6392_VPROC_CON14 0x0228
> +#define MT6392_VPROC_CON15 0x022A
> +#define MT6392_VPROC_CON18 0x0230
> +#define MT6392_VSYS_CON0 0x0232
> +#define MT6392_VSYS_CON1 0x0234
> +#define MT6392_VSYS_CON2 0x0236
> +#define MT6392_VSYS_CON3 0x0238
> +#define MT6392_VSYS_CON4 0x023A
> +#define MT6392_VSYS_CON5 0x023C
> +#define MT6392_VSYS_CON7 0x0240
> +#define MT6392_VSYS_CON8 0x0242
> +#define MT6392_VSYS_CON9 0x0244
> +#define MT6392_VSYS_CON10 0x0246
> +#define MT6392_VSYS_CON11 0x0248
> +#define MT6392_VSYS_CON12 0x024A
> +#define MT6392_VSYS_CON13 0x024C
> +#define MT6392_VSYS_CON14 0x024E
> +#define MT6392_VSYS_CON15 0x0250
> +#define MT6392_VSYS_CON18 0x0256
> +#define MT6392_BUCK_OC_CON0 0x0258
> +#define MT6392_BUCK_OC_CON1 0x025A
> +#define MT6392_BUCK_OC_CON2 0x025C
> +#define MT6392_BUCK_OC_CON3 0x025E
> +#define MT6392_BUCK_OC_CON4 0x0260
> +#define MT6392_BUCK_OC_VPROC_CON0 0x0262
> +#define MT6392_BUCK_OC_VCORE_CON0 0x0264
> +#define MT6392_BUCK_OC_VSYS_CON0 0x0266
> +#define MT6392_BUCK_ANA_MON_CON0 0x0268
> +#define MT6392_BUCK_EFUSE_OC_CON0 0x026A
> +#define MT6392_VCORE_CON0 0x0300
> +#define MT6392_VCORE_CON1 0x0302
> +#define MT6392_VCORE_CON2 0x0304
> +#define MT6392_VCORE_CON3 0x0306
> +#define MT6392_VCORE_CON4 0x0308
> +#define MT6392_VCORE_CON5 0x030A
> +#define MT6392_VCORE_CON7 0x030E
> +#define MT6392_VCORE_CON8 0x0310
> +#define MT6392_VCORE_CON9 0x0312
> +#define MT6392_VCORE_CON10 0x0314
> +#define MT6392_VCORE_CON11 0x0316
> +#define MT6392_VCORE_CON12 0x0318
> +#define MT6392_VCORE_CON13 0x031A
> +#define MT6392_VCORE_CON14 0x031C
> +#define MT6392_VCORE_CON15 0x031E
> +#define MT6392_VCORE_CON18 0x0324
> +#define MT6392_BUCK_K_CON0 0x032A
> +#define MT6392_BUCK_K_CON1 0x032C
> +#define MT6392_BUCK_K_CON2 0x032E
> +#define MT6392_ANALDO_CON0 0x0400
> +#define MT6392_ANALDO_CON1 0x0402
> +#define MT6392_ANALDO_CON2 0x0404
> +#define MT6392_ANALDO_CON3 0x0406
> +#define MT6392_ANALDO_CON4 0x0408
> +#define MT6392_ANALDO_CON6 0x040C
> +#define MT6392_ANALDO_CON7 0x040E
> +#define MT6392_ANALDO_CON8 0x0410
> +#define MT6392_ANALDO_CON10 0x0412
> +#define MT6392_ANALDO_CON15 0x0414
> +#define MT6392_ANALDO_CON16 0x0416
> +#define MT6392_ANALDO_CON17 0x0418
> +#define MT6392_ANALDO_CON21 0x0420
> +#define MT6392_ANALDO_CON22 0x0422
> +#define MT6392_ANALDO_CON23 0x0424
> +#define MT6392_ANALDO_CON24 0x0426
> +#define MT6392_ANALDO_CON25 0x0428
> +#define MT6392_ANALDO_CON26 0x042A
> +#define MT6392_ANALDO_CON27 0x042C
> +#define MT6392_ANALDO_CON28 0x042E
> +#define MT6392_ANALDO_CON29 0x0430
> +#define MT6392_DIGLDO_CON0 0x0500
> +#define MT6392_DIGLDO_CON2 0x0502
> +#define MT6392_DIGLDO_CON3 0x0504
> +#define MT6392_DIGLDO_CON5 0x0506
> +#define MT6392_DIGLDO_CON6 0x0508
> +#define MT6392_DIGLDO_CON7 0x050A
> +#define MT6392_DIGLDO_CON8 0x050C
> +#define MT6392_DIGLDO_CON10 0x0510
> +#define MT6392_DIGLDO_CON11 0x0512
> +#define MT6392_DIGLDO_CON12 0x0514
> +#define MT6392_DIGLDO_CON15 0x051A
> +#define MT6392_DIGLDO_CON20 0x0524
> +#define MT6392_DIGLDO_CON21 0x0526
> +#define MT6392_DIGLDO_CON23 0x0528
> +#define MT6392_DIGLDO_CON24 0x052A
> +#define MT6392_DIGLDO_CON26 0x052C
> +#define MT6392_DIGLDO_CON27 0x052E
> +#define MT6392_DIGLDO_CON28 0x0530
> +#define MT6392_DIGLDO_CON29 0x0532
> +#define MT6392_DIGLDO_CON30 0x0534
> +#define MT6392_DIGLDO_CON31 0x0536
> +#define MT6392_DIGLDO_CON32 0x0538
> +#define MT6392_DIGLDO_CON33 0x053A
> +#define MT6392_DIGLDO_CON36 0x0540
> +#define MT6392_DIGLDO_CON41 0x0546
> +#define MT6392_DIGLDO_CON44 0x054C
> +#define MT6392_DIGLDO_CON47 0x0552
> +#define MT6392_DIGLDO_CON48 0x0554
> +#define MT6392_DIGLDO_CON49 0x0556
> +#define MT6392_DIGLDO_CON50 0x0558
> +#define MT6392_DIGLDO_CON51 0x055A
> +#define MT6392_DIGLDO_CON52 0x055C
> +#define MT6392_DIGLDO_CON53 0x055E
> +#define MT6392_DIGLDO_CON54 0x0560
> +#define MT6392_DIGLDO_CON55 0x0562
> +#define MT6392_DIGLDO_CON56 0x0564
> +#define MT6392_DIGLDO_CON57 0x0566
> +#define MT6392_DIGLDO_CON58 0x0568
> +#define MT6392_DIGLDO_CON59 0x056A
> +#define MT6392_DIGLDO_CON60 0x056C
> +#define MT6392_DIGLDO_CON61 0x056E
> +#define MT6392_DIGLDO_CON62 0x0570
> +#define MT6392_DIGLDO_CON63 0x0572
> +#define MT6392_EFUSE_CON0 0x0600
> +#define MT6392_EFUSE_CON1 0x0602
> +#define MT6392_EFUSE_CON2 0x0604
> +#define MT6392_EFUSE_CON3 0x0606
> +#define MT6392_EFUSE_CON4 0x0608
> +#define MT6392_EFUSE_CON5 0x060A
> +#define MT6392_EFUSE_CON6 0x060C
> +#define MT6392_EFUSE_VAL_0_15 0x060E
> +#define MT6392_EFUSE_VAL_16_31 0x0610
> +#define MT6392_EFUSE_VAL_32_47 0x0612
> +#define MT6392_EFUSE_VAL_48_63 0x0614
> +#define MT6392_EFUSE_VAL_64_79 0x0616
> +#define MT6392_EFUSE_VAL_80_95 0x0618
> +#define MT6392_EFUSE_VAL_96_111 0x061A
> +#define MT6392_EFUSE_VAL_112_127 0x061C
> +#define MT6392_EFUSE_VAL_128_143 0x061E
> +#define MT6392_EFUSE_VAL_144_159 0x0620
> +#define MT6392_EFUSE_VAL_160_175 0x0622
> +#define MT6392_EFUSE_VAL_176_191 0x0624
> +#define MT6392_EFUSE_VAL_192_207 0x0626
> +#define MT6392_EFUSE_VAL_208_223 0x0628
> +#define MT6392_EFUSE_VAL_224_239 0x062A
> +#define MT6392_EFUSE_VAL_240_255 0x062C
> +#define MT6392_EFUSE_VAL_256_271 0x062E
> +#define MT6392_EFUSE_VAL_272_287 0x0630
> +#define MT6392_EFUSE_VAL_288_303 0x0632
> +#define MT6392_EFUSE_VAL_304_319 0x0634
> +#define MT6392_EFUSE_VAL_320_335 0x0636
> +#define MT6392_EFUSE_VAL_336_351 0x0638
> +#define MT6392_EFUSE_VAL_352_367 0x063A
> +#define MT6392_EFUSE_VAL_368_383 0x063C
> +#define MT6392_EFUSE_VAL_384_399 0x063E
> +#define MT6392_EFUSE_VAL_400_415 0x0640
> +#define MT6392_EFUSE_VAL_416_431 0x0642
> +#define MT6392_RTC_MIX_CON0 0x0644
> +#define MT6392_RTC_MIX_CON1 0x0646
> +#define MT6392_EFUSE_VAL_432_447 0x0648
> +#define MT6392_EFUSE_VAL_448_463 0x064A
> +#define MT6392_EFUSE_VAL_464_479 0x064C
> +#define MT6392_EFUSE_VAL_480_495 0x064E
> +#define MT6392_EFUSE_VAL_496_511 0x0650
> +#define MT6392_EFUSE_DOUT_0_15 0x0652
> +#define MT6392_EFUSE_DOUT_16_31 0x0654
> +#define MT6392_EFUSE_DOUT_32_47 0x0656
> +#define MT6392_EFUSE_DOUT_48_63 0x0658
> +#define MT6392_EFUSE_DOUT_64_79 0x065A
> +#define MT6392_EFUSE_DOUT_80_95 0x065C
> +#define MT6392_EFUSE_DOUT_96_111 0x065E
> +#define MT6392_EFUSE_DOUT_112_127 0x0660
> +#define MT6392_EFUSE_DOUT_128_143 0x0662
> +#define MT6392_EFUSE_DOUT_144_159 0x0664
> +#define MT6392_EFUSE_DOUT_160_175 0x0666
> +#define MT6392_EFUSE_DOUT_176_191 0x0668
> +#define MT6392_EFUSE_DOUT_192_207 0x066A
> +#define MT6392_EFUSE_DOUT_208_223 0x066C
> +#define MT6392_EFUSE_DOUT_224_239 0x066E
> +#define MT6392_EFUSE_DOUT_240_255 0x0670
> +#define MT6392_EFUSE_DOUT_256_271 0x0672
> +#define MT6392_EFUSE_DOUT_272_287 0x0674
> +#define MT6392_EFUSE_DOUT_288_303 0x0676
> +#define MT6392_EFUSE_DOUT_304_319 0x0678
> +#define MT6392_EFUSE_DOUT_320_335 0x067A
> +#define MT6392_EFUSE_DOUT_336_351 0x067C
> +#define MT6392_EFUSE_DOUT_352_367 0x067E
> +#define MT6392_EFUSE_DOUT_368_383 0x0680
> +#define MT6392_EFUSE_DOUT_384_399 0x0682
> +#define MT6392_EFUSE_DOUT_400_415 0x0684
> +#define MT6392_EFUSE_DOUT_416_431 0x0686
> +#define MT6392_EFUSE_DOUT_432_447 0x0688
> +#define MT6392_EFUSE_DOUT_448_463 0x068A
> +#define MT6392_EFUSE_DOUT_464_479 0x068C
> +#define MT6392_EFUSE_DOUT_480_495 0x068E
> +#define MT6392_EFUSE_DOUT_496_511 0x0690
> +#define MT6392_EFUSE_CON7 0x0692
> +#define MT6392_EFUSE_CON8 0x0694
> +#define MT6392_EFUSE_CON9 0x0696
> +#define MT6392_AUXADC_ADC0 0x0700
> +#define MT6392_AUXADC_ADC1 0x0702
> +#define MT6392_AUXADC_ADC2 0x0704
> +#define MT6392_AUXADC_ADC3 0x0706
> +#define MT6392_AUXADC_ADC4 0x0708
> +#define MT6392_AUXADC_ADC5 0x070A
> +#define MT6392_AUXADC_ADC6 0x070C
> +#define MT6392_AUXADC_ADC7 0x070E
> +#define MT6392_AUXADC_ADC8 0x0710
> +#define MT6392_AUXADC_ADC9 0x0712
> +#define MT6392_AUXADC_ADC10 0x0714
> +#define MT6392_AUXADC_ADC11 0x0716
> +#define MT6392_AUXADC_ADC12 0x0718
> +#define MT6392_AUXADC_ADC13 0x071A
> +#define MT6392_AUXADC_ADC14 0x071C
> +#define MT6392_AUXADC_ADC15 0x071E
> +#define MT6392_AUXADC_ADC16 0x0720
> +#define MT6392_AUXADC_ADC17 0x0722
> +#define MT6392_AUXADC_ADC18 0x0724
> +#define MT6392_AUXADC_ADC19 0x0726
> +#define MT6392_AUXADC_ADC20 0x0728
> +#define MT6392_AUXADC_ADC21 0x072A
> +#define MT6392_AUXADC_ADC22 0x072C
> +#define MT6392_AUXADC_STA0 0x072E
> +#define MT6392_AUXADC_STA1 0x0730
> +#define MT6392_AUXADC_RQST0 0x0732
> +#define MT6392_AUXADC_RQST0_SET 0x0734
> +#define MT6392_AUXADC_RQST0_CLR 0x0736
> +#define MT6392_AUXADC_CON0 0x0738
> +#define MT6392_AUXADC_CON0_SET 0x073A
> +#define MT6392_AUXADC_CON0_CLR 0x073C
> +#define MT6392_AUXADC_CON1 0x073E
> +#define MT6392_AUXADC_CON2 0x0740
> +#define MT6392_AUXADC_CON3 0x0742
> +#define MT6392_AUXADC_CON4 0x0744
> +#define MT6392_AUXADC_CON5 0x0746
> +#define MT6392_AUXADC_CON6 0x0748
> +#define MT6392_AUXADC_CON7 0x074A
> +#define MT6392_AUXADC_CON8 0x074C
> +#define MT6392_AUXADC_CON9 0x074E
> +#define MT6392_AUXADC_CON10 0x0750
> +#define MT6392_AUXADC_CON11 0x0752
> +#define MT6392_AUXADC_CON12 0x0754
> +#define MT6392_AUXADC_CON13 0x0756
> +#define MT6392_AUXADC_CON14 0x0758
> +#define MT6392_AUXADC_CON15 0x075A
> +#define MT6392_AUXADC_CON16 0x075C
> +#define MT6392_AUXADC_AUTORPT0 0x075E
> +#define MT6392_AUXADC_LBAT0 0x0760
> +#define MT6392_AUXADC_LBAT1 0x0762
> +#define MT6392_AUXADC_LBAT2 0x0764
> +#define MT6392_AUXADC_LBAT3 0x0766
> +#define MT6392_AUXADC_LBAT4 0x0768
> +#define MT6392_AUXADC_LBAT5 0x076A
> +#define MT6392_AUXADC_LBAT6 0x076C
> +#define MT6392_AUXADC_THR0 0x076E
> +#define MT6392_AUXADC_THR1 0x0770
> +#define MT6392_AUXADC_THR2 0x0772
> +#define MT6392_AUXADC_THR3 0x0774
> +#define MT6392_AUXADC_THR4 0x0776
> +#define MT6392_AUXADC_THR5 0x0778
> +#define MT6392_AUXADC_THR6 0x077A
> +#define MT6392_AUXADC_EFUSE0 0x077C
> +#define MT6392_AUXADC_EFUSE1 0x077E
> +#define MT6392_AUXADC_EFUSE2 0x0780
> +#define MT6392_AUXADC_EFUSE3 0x0782
> +#define MT6392_AUXADC_EFUSE4 0x0784
> +#define MT6392_AUXADC_EFUSE5 0x0786
> +#define MT6392_AUXADC_NAG_0 0x0788
> +#define MT6392_AUXADC_NAG_1 0x078A
> +#define MT6392_AUXADC_NAG_2 0x078C
> +#define MT6392_AUXADC_NAG_3 0x078E
> +#define MT6392_AUXADC_NAG_4 0x0790
> +#define MT6392_AUXADC_NAG_5 0x0792
> +#define MT6392_AUXADC_NAG_6 0x0794
> +#define MT6392_AUXADC_NAG_7 0x0796
> +#define MT6392_AUXADC_NAG_8 0x0798
> +#define MT6392_AUXADC_TYPEC_H_1 0x079A
> +#define MT6392_AUXADC_TYPEC_H_2 0x079C
> +#define MT6392_AUXADC_TYPEC_H_3 0x079E
> +#define MT6392_AUXADC_TYPEC_H_4 0x07A0
> +#define MT6392_AUXADC_TYPEC_H_5 0x07A2
> +#define MT6392_AUXADC_TYPEC_H_6 0x07A4
> +#define MT6392_AUXADC_TYPEC_H_7 0x07A6
> +#define MT6392_AUXADC_TYPEC_L_1 0x07A8
> +#define MT6392_AUXADC_TYPEC_L_2 0x07AA
> +#define MT6392_AUXADC_TYPEC_L_3 0x07AC
> +#define MT6392_AUXADC_TYPEC_L_4 0x07AE
> +#define MT6392_AUXADC_TYPEC_L_5 0x07B0
> +#define MT6392_AUXADC_TYPEC_L_6 0x07B2
> +#define MT6392_AUXADC_TYPEC_L_7 0x07B4
> +#define MT6392_AUXADC_NAG_9 0x07B6
> +#define MT6392_TYPE_C_PHY_RG_0 0x0800
> +#define MT6392_TYPE_C_PHY_RG_CC_RESERVE_CSR 0x0802
> +#define MT6392_TYPE_C_VCMP_CTRL 0x0804
> +#define MT6392_TYPE_C_CTRL 0x0806
> +#define MT6392_TYPE_C_CC_SW_CTRL 0x080a
> +#define MT6392_TYPE_C_CC_VOL_PERIODIC_MEAS_VAL 0x080c
> +#define MT6392_TYPE_C_CC_VOL_DEBOUNCE_CNT_VAL 0x080e
> +#define MT6392_TYPE_C_DRP_SRC_CNT_VAL_0 0x0810
> +#define MT6392_TYPE_C_DRP_SNK_CNT_VAL_0 0x0814
> +#define MT6392_TYPE_C_DRP_TRY_CNT_VAL_0 0x0818
> +#define MT6392_TYPE_C_CC_SRC_DEFAULT_DAC_VAL 0x0820
> +#define MT6392_TYPE_C_CC_SRC_15_DAC_VAL 0x0822
> +#define MT6392_TYPE_C_CC_SRC_30_DAC_VAL 0x0824
> +#define MT6392_TYPE_C_CC_SNK_DAC_VAL_0 0x0828
> +#define MT6392_TYPE_C_CC_SNK_DAC_VAL_1 0x082a
> +#define MT6392_TYPE_C_INTR_EN_0 0x0830
> +#define MT6392_TYPE_C_INTR_EN_2 0x0834
> +#define MT6392_TYPE_C_INTR_0 0x0838
> +#define MT6392_TYPE_C_INTR_2 0x083C
> +#define MT6392_TYPE_C_CC_STATUS 0x0840
> +#define MT6392_TYPE_C_PWR_STATUS 0x0842
> +#define MT6392_TYPE_C_PHY_RG_CC1_RESISTENCE_0 0x0844
> +#define MT6392_TYPE_C_PHY_RG_CC1_RESISTENCE_1 0x0846
> +#define MT6392_TYPE_C_PHY_RG_CC2_RESISTENCE_0 0x0848
> +#define MT6392_TYPE_C_PHY_RG_CC2_RESISTENCE_1 0x084a
> +#define MT6392_TYPE_C_CC_SW_FORCE_MODE_ENABLE_0 0x0860
> +#define MT6392_TYPE_C_CC_SW_FORCE_MODE_VAL_0 0x0864
> +#define MT6392_TYPE_C_CC_SW_FORCE_MODE_VAL_1 0x0866
> +#define MT6392_TYPE_C_CC_SW_FORCE_MODE_ENABLE_1 0x0868
> +#define MT6392_TYPE_C_CC_SW_FORCE_MODE_VAL_2 0x086c
> +#define MT6392_TYPE_C_CC_DAC_CALI_CTRL 0x0870
> +#define MT6392_TYPE_C_CC_DAC_CALI_RESULT 0x0872
> +#define MT6392_TYPE_C_DEBUG_PORT_SELECT_0 0x0880
> +#define MT6392_TYPE_C_DEBUG_PORT_SELECT_1 0x0882
> +#define MT6392_TYPE_C_DEBUG_MODE_SELECT 0x0884
> +#define MT6392_TYPE_C_DEBUG_OUT_READ_0 0x0888
> +#define MT6392_TYPE_C_DEBUG_OUT_READ_1 0x088a
> +#define MT6392_TYPE_C_SW_DEBUG_PORT_0 0x088c
> +#define MT6392_TYPE_C_SW_DEBUG_PORT_1 0x088e
> +
> +#endif /* __MFD_MT6392_REGISTERS_H__ */
> diff --git "a/include/linux/mfd/mt6397/core.h" "b/include/linux/mfd/mt6397/core.h"
> index 340fc72e22aa..3729a6856c13 100644
> --- "a/include/linux/mfd/mt6397/core.h"
> +++ "b/include/linux/mfd/mt6397/core.h"
> @@ -20,6 +20,7 @@ enum chip_id {
> MT6359_CHIP_ID = 0x59,
> MT6366_CHIP_ID = 0x66,
> MT6391_CHIP_ID = 0x91,
> + MT6392_CHIP_ID = 0x92,
This looks like a duplicated struct.
Can't we use this instead of the made-up 'mfd_match_data'?
> MT6397_CHIP_ID = 0x97,
> };
>
> --
> 2.43.0
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v2] phy: exynos5-usbdrd: Remove error print for devm_add_action_or_reset()
From: Waqar Hameed @ 2026-05-20 14:58 UTC (permalink / raw)
To: Vinod Koul, Kishon Vijay Abraham I, Krzysztof Kozlowski,
Alim Akhtar
Cc: kernel, linux-phy, linux-arm-kernel, linux-samsung-soc,
linux-kernel
In-Reply-To: <pnd7bx2j2pi.a.out@axis.com>
On Fri, Oct 10, 2025 at 15:39 +0200 Waqar Hameed <waqar.hameed@axis.com> wrote:
> On Tue, Aug 05, 2025 at 11:33 +0200 Waqar Hameed <waqar.hameed@axis.com> wrote:
[...]
> Friendly ping incoming!
Friendly ping 2 incoming!
This will be the last ping for the original patch [1]. I'll interpret
the silence as a NACK (though it would preferable to get an explicit
one...). All other patches in the previous patch series has been merged
[2].
[1] https://lore.kernel.org/all/pnd34a6m7tc.a.out@axis.com/
[2] https://lore.kernel.org/all/pnd7c0s6ji2.fsf@axis.com/
^ permalink raw reply
* [PATCH v2 6/8] drm/sun4i: hdmi: Use the common TMDS char rate constant
From: Javier Martinez Canillas @ 2026-05-20 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, Maxime Ripard, Chen-Yu Tsai,
David Airlie, Jernej Skrabec, Maarten Lankhorst, Samuel Holland,
Simona Vetter, Thomas Zimmermann, dri-devel, linux-arm-kernel,
linux-sunxi
In-Reply-To: <20260520144424.1633354-1-javierm@redhat.com>
Replace the 165000000 magic number with the shared constant defined
in the <linux/hdmi.h> header.
The old comment referenced "HDMI <= 1.2" but 165 MHz is actually
the maximum TMDS character rate defined by the HDMI 1.0 spec.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
---
(no changes since v1)
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
index 07e2afcb4f95..74c7c3720ba8 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
@@ -189,8 +189,8 @@ sun4i_hdmi_connector_clock_valid(const struct drm_connector *connector,
if (mode->flags & DRM_MODE_FLAG_DBLCLK)
return MODE_BAD;
- /* 165 MHz is the typical max pixelclock frequency for HDMI <= 1.2 */
- if (clock > 165000000)
+ /* HDMI 1.0 max TMDS character rate */
+ if (clock > HDMI_1_0_TMDS_CHAR_RATE_MAX_HZ)
return MODE_CLOCK_HIGH;
rounded_rate = clk_round_rate(hdmi->tmds_clk, clock);
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/8] hdmi: Add common TMDS character rate constants
From: Javier Martinez Canillas @ 2026-05-20 14:43 UTC (permalink / raw)
To: linux-kernel
Cc: Javier Martinez Canillas, Abhinav Kumar, Alain Volmat,
Andrzej Hajda, Andy Yan, Brian Masney, Chen-Yu Tsai, Chris Morgan,
Cristian Ciocaltea, Daniel Stone, David Airlie, Dmitry Baryshkov,
Dmitry Baryshkov, Heiko Stuebner, Jani Nikula, Jernej Skrabec,
Jessica Zhang, Jonas Karlman, Konrad Dybcio, Laurent Pinchart,
Liu Ying, Luca Ceresoli, Maarten Lankhorst, Marijn Suijten,
Maxime Ripard, Neil Armstrong, Raphael Gallais-Pou, Rob Clark,
Robert Foss, Samuel Holland, Sean Paul, Shengjiu Wang,
Simona Vetter, Thomas Zimmermann, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-sunxi
Several DRM drivers define their own local macros or use magic numbers for
the standard HDMI TMDS character rate limits. Maxime Ripard suggested that
instead these common rate constants could be included to a shared header.
This series introduces these constants to the <linux/hdmi.h> header and
replaces the local defined constants or magic numbers in drivers.
I split the changes as one patch per driver, so that these can be reviewed
individually and merged at their own pace.
This is a version 2 that addresses issues pointed out by Maxime Ripard and
Dmitry Baryshkov.
Changes in v2:
- Change naming convention to HDMI_$SPEC_TMDS_CHAR_RATE_MAX_HZ (Maxime).
- Define the constants in <linux/hdmi.h> (Dmitry).
Javier Martinez Canillas (8):
video/hdmi: Add common TMDS character rate constants
drm/bridge: dw-hdmi: Use the common TMDS char rate constant
drm/bridge: dw-hdmi-qp: Use the common TMDS char rate constant
drm/bridge: inno-hdmi: Use the common TMDS char rate constant
drm/sti: hdmi: Use the common TMDS char rate constants
drm/sun4i: hdmi: Use the common TMDS char rate constant
drm/msm/hdmi: Use the common TMDS char rate constants in 8996 PHY
drm/msm/hdmi: Use the common TMDS char rate constants in 8998 PHY
drivers/gpu/drm/bridge/inno-hdmi.c | 4 +---
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 6 ++----
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 10 ++++------
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c | 6 ++----
drivers/gpu/drm/msm/hdmi/hdmi_phy_8998.c | 6 ++----
drivers/gpu/drm/sti/sti_hdmi_tx3g4c28phy.c | 6 ++++--
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 4 ++--
include/linux/hdmi.h | 6 ++++++
8 files changed, 23 insertions(+), 25 deletions(-)
--
2.54.0
base-commit: 88658ff0e4e7f46dbf8179af1280f2cb295fb0cb
branch: add-common-tmds-rates-v2
^ permalink raw reply
* Re: [PATCH v9 2/3] dt-bindings: mfd: aspeed,ast2x00-scu: Describe AST2700 SCU0
From: Lee Jones @ 2026-05-20 14:43 UTC (permalink / raw)
To: Linus Walleij
Cc: Billy Tsai, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Joel Stanley, Andrew Jeffery, Bartosz Golaszewski, Ryan Chen,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, openbmc, linux-gpio, linux-clk
In-Reply-To: <CAD++jL=3p9BvDgaot3=emM4Zn5jU-ZAUKtB4UwT1HzDiyzKq4Q@mail.gmail.com>
On Mon, 11 May 2026, Linus Walleij wrote:
> On Wed, May 6, 2026 at 10:07 AM Billy Tsai <billy_tsai@aspeedtech.com> wrote:
>
> > AST2700 consists of two interconnected SoC instances, each with its own
> > System Control Unit (SCU). The SCU0 provides pin control, interrupt
> > controllers, clocks, resets, and address-space mappings for the
> > Secondary and Tertiary Service Processors (SSP and TSP).
> >
> > Describe the SSP/TSP address mappings using the standard
> > memory-region and memory-region-names properties.
> >
> > Disallow legacy child nodes that are not present on AST2700, including
> > p2a-control and smp-memram. The latter is unnecessary as software can
> > access the scratch registers via the SCU syscon.
> >
> > Also allow the AST2700 SoC0 pin controller to be described as a child
> > node of the SCU0, and add an example illustrating the SCU0 layout,
> > including reserved-memory, interrupt controllers, and pinctrl.
> >
> > Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
> > Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
>
> This is an MFD patch in the middle of a pinctrl series, I think Lee
> should apply this.
> FWIW:
> Acked-by: Linus Walleij <linusw@kernel.org>
Already applied v8.
--
Lee Jones
^ permalink raw reply
* Re: (subset) [PATCH 2/9] dt-bindings: mfd: mediatek: mt6397: Add MT6365 PMIC support
From: Lee Jones @ 2026-05-20 14:41 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Louis-Alexis Eyraud
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-2-6f43838be92f@collabora.com>
On Wed, 29 Apr 2026 11:44:15 +0200, Louis-Alexis Eyraud wrote:
> MT6365 PMIC is compatible with MT6359, so add the compatible strings
> for the main and sub devices (regulator, rtc, audio codec).
Applied, thanks!
[2/9] dt-bindings: mfd: mediatek: mt6397: Add MT6365 PMIC support
commit: 5a7c6466133eee4370995ad5ccf4c377011a381e
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH 1/9] dt-bindings: mfd: mediatek: mt6397: Add rtc for MT6359
From: Lee Jones @ 2026-05-20 14:40 UTC (permalink / raw)
To: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Dmitry Torokhov, Chen Zhong,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Louis-Alexis Eyraud
Cc: kernel, linux-pm, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-input, linux-iio
In-Reply-To: <20260429-mediatek-genio-mt6365-cleanup-v1-1-6f43838be92f@collabora.com>
On Wed, 29 Apr 2026 11:44:14 +0200, Louis-Alexis Eyraud wrote:
> The rtc block of MT6359 PMIC is compatible with the one found in MT6358
> but this compatibility was never expressed in the dt-bindings, so add
> the missing compatible string for the rtc subnode.
Applied, thanks!
[1/9] dt-bindings: mfd: mediatek: mt6397: Add rtc for MT6359
commit: 4edf75f835bad0b7e7ac022594b129f9dbf8698c
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH v8 1/4] dt-bindings: backlight: Add max25014 support
From: Frank Li @ 2026-05-20 14:38 UTC (permalink / raw)
To: Lee Jones
Cc: Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Helge Deller, Shawn Guo,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Liam Girdwood, Mark Brown, Maud Spierings, dri-devel, linux-leds,
devicetree, linux-kernel, linux-fbdev, imx, linux-arm-kernel
In-Reply-To: <20260520114745.GX305027@google.com>
On Wed, May 20, 2026 at 12:47:45PM +0100, Lee Jones wrote:
> On Tue, 19 May 2026, Frank Li wrote:
>
> > On Thu, Apr 30, 2026 at 02:53:40PM +0100, Lee Jones wrote:
> > > On Tue, 07 Apr 2026 16:41:42 +0200, Maud Spierings wrote:
> > > > The Maxim MAX25014 is a 4-channel automotive grade backlight driver IC
> > > > with integrated boost controller.
> > >
> > > Applied, thanks!
> > >
> > > [1/4] dt-bindings: backlight: Add max25014 support
> > > commit: 5fcbbedec9dfce78044eee922bf2030e1bd03faa
> >
> > Lee Jones:
> >
> > I have not seen it in linux-next. Anything wrong?
>
> I don't know why Backlight hasn't been added to Linux Next.
>
> Rest assured, it's applied to the Backlight tree.
Thank, you'd better check with Mark brown to make sure it is merged into
linux-next because linux-next will do many checking and build works.
Frank
>
> --
> Lee Jones
^ permalink raw reply
* Re: [PATCH v4 1/3] PCI: Allow ATS to be always on for CXL.cache capable devices
From: Jason Gunthorpe @ 2026-05-20 14:34 UTC (permalink / raw)
To: Yi Liu
Cc: Nicolin Chen, will, robin.murphy, bhelgaas, joro, praan, baolu.lu,
kevin.tian, miko.lenczewski, linux-arm-kernel, iommu,
linux-kernel, linux-pci, dan.j.williams, jonathan.cameron, vsethi,
linux-cxl, nirmoyd
In-Reply-To: <e8337102-aecd-48e8-9a2d-10f41ed43c5b@intel.com>
On Wed, May 20, 2026 at 09:12:31PM +0800, Yi Liu wrote:
> On 4/27/26 13:54, Nicolin Chen wrote:
> > Controlled by the IOMMU driver, ATS is usually enabled "on demand" when a
> > given PASID on a device is attached to an I/O page table. This is working
> > even when a device has no translation on its RID (i.e., the RID is IOMMU
> > bypassed).
>
> nit: this description seems not accurate. Intel iommu driver enables ATS
> in the probe_device() phase. mind tweak a bit to avoid misleading
> message. :)
It probably shouldn't do this, it should follow ARM and have it
dynamic during domain attach.
For security we need ATS disabled for blocking domains at a minimum.
Jason
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Frank Li @ 2026-05-20 14:33 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Chancel Liu (OSS), Chancel Liu, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, s.hauer@pengutronix.de,
festevam@gmail.com, mturquette@baylibre.com, sboyd@kernel.org,
kernel@pengutronix.de, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org
In-Reply-To: <e23a610f-e1ad-4536-80fb-8b5707e77f39@kernel.org>
On Wed, May 20, 2026 at 09:08:42AM +0200, Krzysztof Kozlowski wrote:
> On 20/05/2026 07:02, Chancel Liu (OSS) wrote:
> >>>>>>> +description:
> >>>>>>> + The NXP I/O connector represents a physically present I/O
> >>>>>>> +connector on the
> >>>>>>> + base board. It acts as a nexus that exposes a constrained set
> >> of
> >>>>>>> +I/O
> >>>>>>> + resources, such as GPIOs, clocks, PWMs and interrupts, through
> >>>>>>> +fixed
> >>>>>>> + electrical wiring. All actual hardware providers reside on the
> >> base
> >>>> board.
> >>>>>>> + The connector node only defines index-based mappings to those
> >>>>>> providers.
> >>>>>>> +
> >>>>>>> +properties:
> >>>>>>> + compatible:
> >>>>>>> + const: fsl,io-connector
> >>>>>>
> >>>>>> Everything is IO. Everything is connector, so your compatible does
> >>>>>> not match requirements from writing bindings.
> >>>>>>
> >>>>>
> >>>>> Yes, this compatible is too generic. I will rename the compatible to
> >>>>> fsl,aud-io-connector.
> >>>>
> >>>> aud is not much better. Which boards have it? What's the pinout?
> >> What's
> >>>> standard? Is it described anywhere? If so, provide reference to
> >> spec/docs.
> >>>>
> >>>
> >>> This is not an industry standard electrical interface. This connector
> >>
> >> Then if you do not have standard, then you have board specific layouts
> >> thus you need board-specific compatibles. You can use fallbacks. Generic
> >> fallback could work, but both io-connector and aud-io-connector are just
> >> too generic. Every connector is "connector" and "io", thus absolutely
> >> anything can be "io-connector". "aud" improves it only a bit, thus
> >> honestly I would go with board specific fallback as well.
> >>
> >
> > How about board specific + common fallback compatible like this:
> > compatible:
> > items:
> > - enum:
> > - fsl,imx95-19x19-evk-aud-io-connector
> > - fsl,imx952-evk-aud-io-connector
> > - const: fsl,imx-aud-io-connector
> > Since the daughter board is named “IMX-AUD-IO” in publicly available
>
> I don't think it is named like that.
>
> git grep -i imx-aud-io
>
> > documentation, common compatible clearly indicates that this connector
> > is intended for that.
> >
> > Also, I want to talk about the topic of generic connector. It's a common
> > design that daughter board is connected to base board through a
> > connector. This connector more often acts as a nexus that exposes a
> > constrained subset of GPIO, clock, PWM and interrupt resources to the
> > daughter board. Can we document this kind of connector as a generic
> > binding?
>
> So this binding is the connector between carrier and some addon? Then
> you don't get a compatible for that at all, because it is not necessary,
> not useful and NEVER used. Do you see socket LGA "connector" bindings? No.
Not exactly. Any connector connects a carrier board with an add-on board.
The key point here is that this connector type is reused across different
boards, even though it is not an industry-standard connector. Both the
signal definitions and the mechanical layout are defined.
The same add-on boards can therefore be reused across different base boards
that use this type of connector.
There are also GPIO mappings involved. For example, pin 1 on the connector
may represent reset-gpios, but it could be connected to GPIO0 on board A
and GPIO1 on board B.
Without a connector definition layer, this would create an N × M
combination problem. The Nexus node discussion already covered this topic:
https://osseu2025.sched.com/event/25Vrw
An LGA socket is a CPU socket, where the signals are completely transparent
to software, so it is not a good comparison. A PCIe M.2 Key-M/E connector
would be a more appropriate comparison.
Frank
>
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH 1/8] mm: Add ptep_try_install() for lockless empty-slot installs
From: Alexei Starovoitov @ 2026-05-20 14:31 UTC (permalink / raw)
To: David Hildenbrand (Arm)
Cc: Tejun Heo, David Vernet, Andrea Righi, Changwoo Min,
Alexei Starovoitov, Andrii Nakryiko, Daniel Borkmann,
Martin KaFai Lau, Kumar Kartikeya Dwivedi, Catalin Marinas,
Will Deacon, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, Andrew Morton, Mike Rapoport, Emil Tsalapatis,
sched-ext, bpf, X86 ML, linux-arm-kernel, linux-mm, LKML
In-Reply-To: <fb889bfc-af0e-491e-a69f-38c2abf88d22@kernel.org>
On Wed, May 20, 2026 at 10:41 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 5/19/26 21:04, Alexei Starovoitov wrote:
> > On Tue, May 19, 2026 at 10:11 AM Tejun Heo <tj@kernel.org> wrote:
> >>
> >> On Tue, May 19, 2026 at 11:40:48AM +0200, David Hildenbrand (Arm) wrote:
> >> ...
> >>
> >> Wouldn't it still be either or with both cases being okay?
> >>
> >>>
> >>> ... or can we run into similar problems with kprobes? (I am obviously no bpf
> >>> expert ...)
> >>
> >> Yeah, I mean, that was just the first TP I found scanning the code. Any
> >> kprobes or other TPs in the path would behave the same.
> >>
> >> When this fault triggers, the BPF program has already malfunctioned, so it's
> >> not going to be a high frequency path and performance isn't a primary
> >> consideration. So, anything that can ensure that the kernel doesn't crash or
> >> lock up would be fine. Any better ideas?
> >
> > As you guys already figured out the trylock is not an option.
>
> And that should be carefully documented.
+1
>
> At least in apply_range_clear_cb() one could similarly switch to
> ptep_try_install() to at least have both these paths handle races in a
> reasonable way. (having to handle when ptep_try_install() is not really implemented)
You mean to use ptep_get_and_clear() ?
Makes sense to me.
Also noticed bogus defensive check there that should be removed:
+ if (unlikely(!d))
+ return 0;
> Anyhow, the documentation of ptep_try_install() must clearly spell out that this
> must be used very carefully, and only in special kernel page tables, never user
> page tables. There are likely other scenarios we should document (caller must
> prevent concurrent page table teardown somehow, and must be prepared to handle
> races if other code is not using atomics).
>
> To highlight that, we should likely consider adding a "kernel" in the name, like
> "ptep_try_install_kernel()".
>
> I am also not sure if "install" is the right terminology and whether it should
> instead be "ptep_try_set()". (set_pte_at is the non-atomic interface right now)
I suggested using the ptep_try_set() name too :)
> Further note that last time I talked to Linus about arch helpers, he preferred
>
> #define ptep_try_install ptep_try_install
>
> over __HAVE_ARCH_PTEP_TRY_INSTALL
ok.
I guess __HAVE_ARCH_PTEP_GET_AND_CLEAR is legacy ?
^ permalink raw reply
* [PATCH v5 7/8] dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
From: Gregor Herburger @ 2026-05-20 14:27 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Conor Dooley, Gregor Herburger
In-Reply-To: <20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de>
The select schema is not necessary because the
raspberrypi,bcm2835-firmware compatible is already matched by the
compatible string values. The documentation says "Most bindings should
not need select", so remove it.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 9 ---------
1 file changed, 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index a3a5243b91706..7cf9a6fa1e5be 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -10,15 +10,6 @@ maintainers:
- Eric Anholt <eric@anholt.net>
- Stefan Wahren <wahrenst@gmx.net>
-select:
- properties:
- compatible:
- contains:
- const: raspberrypi,bcm2835-firmware
-
- required:
- - compatible
-
properties:
compatible:
oneOf:
--
2.47.3
^ permalink raw reply related
* [PATCH v5 8/8] arm64: defconfig: Enable the raspberrypi otp driver as module
From: Gregor Herburger @ 2026-05-20 14:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de>
Enable the newly add Raspberry Pi OTP driver as module to allow access
to the otp registers.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e44e83bc57812..3abb3ca34c708 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -1849,6 +1849,7 @@ CONFIG_NVMEM_SPMI_SDAM=m
CONFIG_NVMEM_SUNXI_SID=y
CONFIG_NVMEM_UNIPHIER_EFUSE=y
CONFIG_NVMEM_ZYNQMP=m
+CONFIG_NVMEM_RASPBERRYPI_OTP=m
CONFIG_FPGA=y
CONFIG_FPGA_MGR_ALTERA_CVP=m
CONFIG_FPGA_MGR_STRATIX10_SOC=m
--
2.47.3
^ permalink raw reply related
* [PATCH v5 5/8] firmware: raspberrypi: register nvmem driver
From: Gregor Herburger @ 2026-05-20 14:27 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de>
The Raspberry Pi firmware exposes two regions with otp registers. The
first region called "customer otp" is available on all Raspberry Pi
models. The second is only available on the Raspberry Pi 5 (bcm2712).
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/firmware/raspberrypi.c | 59 +++++++++++++++++++++++++++++-
include/soc/bcm2835/raspberrypi-firmware.h | 5 +++
2 files changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/raspberrypi.c b/drivers/firmware/raspberrypi.c
index 0aa322e9a2e73..e24636feae0ea 100644
--- a/drivers/firmware/raspberrypi.c
+++ b/drivers/firmware/raspberrypi.c
@@ -24,12 +24,15 @@
static struct platform_device *rpi_hwmon;
static struct platform_device *rpi_clk;
+static struct platform_device *rpi_otp_customer;
+static struct platform_device *rpi_otp_private;
struct rpi_firmware {
struct mbox_client cl;
struct mbox_chan *chan; /* The property channel. */
struct completion c;
u32 enabled;
+ enum rpi_firmware_soc soc;
struct kref consumers;
};
@@ -231,6 +234,47 @@ static void rpi_register_clk_driver(struct device *dev)
-1, NULL, 0);
}
+static const struct rpi_otp_driver_data rpi_otp_customer_data = {
+ .name = "rpi-otp-customer",
+ .read_tag = RPI_FIRMWARE_GET_CUSTOMER_OTP,
+ .write_tag = RPI_FIRMWARE_SET_CUSTOMER_OTP,
+ .size = 32,
+ .root_only = false,
+};
+
+static const struct rpi_otp_driver_data rpi_otp_private_data = {
+ .name = "rpi-otp-private",
+ .read_tag = RPI_FIRMWARE_GET_PRIVATE_OTP,
+ .write_tag = RPI_FIRMWARE_SET_PRIVATE_OTP,
+ .size = 32,
+ .root_only = true,
+};
+
+static void rpi_register_otp_driver(struct device *dev)
+{
+ struct rpi_firmware *fw = dev_get_drvdata(dev);
+
+ rpi_otp_customer = platform_device_register_data(dev, "raspberrypi-otp",
+ PLATFORM_DEVID_AUTO,
+ &rpi_otp_customer_data,
+ sizeof(rpi_otp_customer_data));
+
+ if (IS_ERR(rpi_otp_customer))
+ dev_err(dev, "Failed to register customer OTP device: %ld\n",
+ PTR_ERR(rpi_otp_customer));
+
+ if (fw->soc == RPI_FIRMWARE_SOC_BCM2712) {
+ rpi_otp_private = platform_device_register_data(dev, "raspberrypi-otp",
+ PLATFORM_DEVID_AUTO,
+ &rpi_otp_private_data,
+ sizeof(rpi_otp_private_data));
+
+ if (IS_ERR(rpi_otp_private))
+ dev_err(dev, "Failed to register private OTP device: %ld\n",
+ PTR_ERR(rpi_otp_private));
+ }
+}
+
unsigned int rpi_firmware_clk_get_max_rate(struct rpi_firmware *fw, unsigned int id)
{
struct rpi_firmware_clk_rate_request msg =
@@ -299,12 +343,14 @@ static int rpi_firmware_probe(struct platform_device *pdev)
init_completion(&fw->c);
kref_init(&fw->consumers);
+ fw->soc = (uintptr_t)device_get_match_data(dev);
platform_set_drvdata(pdev, fw);
rpi_firmware_print_firmware_revision(fw);
rpi_register_hwmon_driver(dev, fw);
rpi_register_clk_driver(dev);
+ rpi_register_otp_driver(dev);
return 0;
}
@@ -327,12 +373,23 @@ static void rpi_firmware_remove(struct platform_device *pdev)
rpi_hwmon = NULL;
platform_device_unregister(rpi_clk);
rpi_clk = NULL;
+ platform_device_unregister(rpi_otp_customer);
+ rpi_otp_customer = NULL;
+ platform_device_unregister(rpi_otp_private);
+ rpi_otp_private = NULL;
rpi_firmware_put(fw);
}
static const struct of_device_id rpi_firmware_of_match[] = {
- { .compatible = "raspberrypi,bcm2835-firmware", },
+ {
+ .compatible = "raspberrypi,bcm2835-firmware",
+ .data = (void *)RPI_FIRMWARE_SOC_BCM2835,
+ },
+ {
+ .compatible = "raspberrypi,bcm2712-firmware",
+ .data = (void *)RPI_FIRMWARE_SOC_BCM2712,
+ },
{},
};
MODULE_DEVICE_TABLE(of, rpi_firmware_of_match);
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index 1e5e5f7e378d0..a4c94b85b7aa9 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -9,6 +9,11 @@
#include <linux/types.h>
#include <linux/of_device.h>
+enum rpi_firmware_soc {
+ RPI_FIRMWARE_SOC_BCM2835,
+ RPI_FIRMWARE_SOC_BCM2712,
+};
+
struct rpi_firmware;
enum rpi_firmware_property_status {
--
2.47.3
^ permalink raw reply related
* [PATCH v5 6/8] arm64: dts: broadcom: bcm2712: add raspberrypi,bcm2712-firmware compatible
From: Gregor Herburger @ 2026-05-20 14:27 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de>
The Raspberry Pi 5 (BCM2712) firmware exposes additional features such
as the additional OTP register region called 'private OTP'.
Add the raspberrypi,bcm2712-firmware compatible to allow drivers to
distinguish this hardware variant while keeping
raspberrypi,bcm2835-firmware as a fallback for backward compatibility
with existing drivers.
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
index b7a6bc34ae1ab..4aa8ec7601b84 100644
--- a/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
+++ b/arch/arm64/boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi
@@ -46,7 +46,9 @@ power_button: power-button {
firmware {
firmware: rpi-firmware {
- compatible = "raspberrypi,bcm2835-firmware", "simple-mfd";
+ compatible = "raspberrypi,bcm2712-firmware",
+ "raspberrypi,bcm2835-firmware",
+ "simple-mfd";
mboxes = <&mailbox>;
--
2.47.3
^ permalink raw reply related
* [PATCH v5 4/8] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-05-20 14:27 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de>
Raspberry Pis have OTP registers which can be accessed through the
videocore firmware. Add a nvmem driver to support these OTP registers.
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/nvmem/Kconfig | 11 +++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/raspberrypi-otp.c | 130 +++++++++++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 10 +++
4 files changed, 152 insertions(+)
diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
index 74ddbd0f79b0e..a1922b48d0c2e 100644
--- a/drivers/nvmem/Kconfig
+++ b/drivers/nvmem/Kconfig
@@ -483,4 +483,15 @@ config NVMEM_QORIQ_EFUSE
This driver can also be built as a module. If so, the module
will be called nvmem_qoriq_efuse.
+config NVMEM_RASPBERRYPI_OTP
+ tristate "Raspberry Pi OTP support"
+ depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
+ help
+ This driver provides access to the Raspberry Pi OTP memory via the
+ nvmem subsystem. The driver supports the customer OTP as well as the
+ device specific private key OTP (BCM2712 only).
+
+ This driver can also be built as a module. If so, the module
+ will be called raspberrypi-otp.
+
endif
diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
index 7252b8ec88d46..8ca2095e068f3 100644
--- a/drivers/nvmem/Makefile
+++ b/drivers/nvmem/Makefile
@@ -95,3 +95,4 @@ obj-$(CONFIG_NVMEM_ZYNQMP) += nvmem_zynqmp_nvmem.o
nvmem_zynqmp_nvmem-y := zynqmp_nvmem.o
obj-$(CONFIG_NVMEM_QORIQ_EFUSE) += nvmem-qoriq-efuse.o
nvmem-qoriq-efuse-y := qoriq-efuse.o
+obj-$(CONFIG_NVMEM_RASPBERRYPI_OTP) += raspberrypi-otp.o
diff --git a/drivers/nvmem/raspberrypi-otp.c b/drivers/nvmem/raspberrypi-otp.c
new file mode 100644
index 0000000000000..3c24548267219
--- /dev/null
+++ b/drivers/nvmem/raspberrypi-otp.c
@@ -0,0 +1,130 @@
+// SPDX-License-Identifier: GPL-2.0-only
+
+#include <linux/module.h>
+#include <linux/mod_devicetable.h>
+#include <linux/nvmem-provider.h>
+#include <linux/platform_device.h>
+#include <linux/types.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+struct rpi_otp_priv {
+ struct rpi_firmware *fw;
+ u32 read_tag;
+ u32 write_tag;
+};
+
+struct rpi_otp_header {
+ __le32 start;
+ __le32 count;
+ __le32 data[] __counted_by_le(count);
+};
+
+static int rpi_otp_read(void *context, unsigned int offset, void *buf, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ u32 count;
+ int ret;
+
+ count = bytes / 4;
+
+ fwbuf = kzalloc(struct_size(fwbuf, data, count), GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = cpu_to_le32(offset / 4);
+ fwbuf->count = cpu_to_le32(count);
+
+ ret = rpi_firmware_property(priv->fw, priv->read_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+ if (ret)
+ goto out;
+
+ memcpy(buf, fwbuf->data, bytes);
+
+out:
+ kfree(fwbuf);
+ return ret;
+}
+
+static int rpi_otp_write(void *context, unsigned int offset, void *val, size_t bytes)
+{
+ struct rpi_otp_priv *priv = context;
+ struct rpi_otp_header *fwbuf;
+ u32 count;
+ int ret;
+
+ count = bytes / 4;
+
+ fwbuf = kzalloc(struct_size(fwbuf, data, count), GFP_KERNEL);
+ if (!fwbuf)
+ return -ENOMEM;
+
+ fwbuf->start = cpu_to_le32(offset / 4);
+ fwbuf->count = cpu_to_le32(count);
+ memcpy(fwbuf->data, val, bytes);
+
+ ret = rpi_firmware_property(priv->fw, priv->write_tag, fwbuf,
+ sizeof(struct rpi_otp_header) + bytes);
+
+ kfree(fwbuf);
+ return ret;
+}
+
+static int rpi_otp_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct nvmem_device *nvmem;
+ struct rpi_otp_priv *priv;
+ const struct rpi_otp_driver_data *data;
+ struct nvmem_config config = {
+ .read_only = false,
+ .word_size = 4,
+ .stride = 4,
+ .reg_read = rpi_otp_read,
+ .reg_write = rpi_otp_write,
+ .id = NVMEM_DEVID_NONE,
+ };
+
+ data = dev_get_platdata(dev);
+ if (!data)
+ return -ENODEV;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ priv->fw = dev_get_drvdata(dev->parent);
+ priv->read_tag = data->read_tag;
+ priv->write_tag = data->write_tag;
+ config.dev = dev;
+ config.priv = priv;
+ config.name = data->name;
+ config.size = data->size;
+ config.root_only = data->root_only;
+
+ nvmem = devm_nvmem_register(dev, &config);
+ if (IS_ERR(nvmem))
+ return dev_err_probe(dev, PTR_ERR(nvmem), "error registering nvmem config\n");
+
+ return 0;
+}
+
+static const struct platform_device_id raspberrypi_otp_id[] = {
+ { "raspberrypi-otp" },
+ {},
+};
+MODULE_DEVICE_TABLE(platform, raspberrypi_otp_id);
+
+static struct platform_driver raspberrypi_otp_driver = {
+ .probe = rpi_otp_probe,
+ .driver = {
+ .name = "raspberrypi-otp",
+ },
+ .id_table = raspberrypi_otp_id,
+};
+module_platform_driver(raspberrypi_otp_driver);
+
+MODULE_AUTHOR("Gregor Herburger <gregor.herburger@linutronix.de>");
+MODULE_DESCRIPTION("Raspberry Pi OTP driver");
+MODULE_LICENSE("GPL");
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index eb33838e0cd10..1e5e5f7e378d0 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -92,6 +92,8 @@ enum rpi_firmware_property_tag {
RPI_FIRMWARE_SET_POE_HAT_VAL = 0x00030050,
RPI_FIRMWARE_NOTIFY_XHCI_RESET = 0x00030058,
RPI_FIRMWARE_NOTIFY_DISPLAY_DONE = 0x00030066,
+ RPI_FIRMWARE_GET_PRIVATE_OTP = 0x00030081,
+ RPI_FIRMWARE_SET_PRIVATE_OTP = 0x00038081,
/* Dispmanx TAGS */
RPI_FIRMWARE_FRAMEBUFFER_ALLOCATE = 0x00040001,
@@ -174,6 +176,14 @@ struct rpi_firmware_clk_rate_request {
.id = cpu_to_le32(_id), \
}
+struct rpi_otp_driver_data {
+ const char *name;
+ u32 read_tag;
+ u32 write_tag;
+ int size;
+ bool root_only;
+};
+
#if IS_REACHABLE(CONFIG_RASPBERRYPI_FIRMWARE)
int rpi_firmware_property(struct rpi_firmware *fw,
u32 tag, void *data, size_t len);
--
2.47.3
^ permalink raw reply related
* [PATCH v5 3/8] dt-bindings: raspberrypi,bcm2835-firmware: Add bcm2712-firmware compatible
From: Gregor Herburger @ 2026-05-20 14:27 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Conor Dooley, Gregor Herburger
In-Reply-To: <20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de>
Add a compatible string for the bcm2712 firmware. The bcm2712-firmware
is compatible with the bcm2835-firmware so allow the bcm2835-firmware as
fallback.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
.../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
index 983ea80eaec97..a3a5243b91706 100644
--- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
+++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
@@ -21,9 +21,14 @@ select:
properties:
compatible:
- items:
- - const: raspberrypi,bcm2835-firmware
- - const: simple-mfd
+ oneOf:
+ - items:
+ - const: raspberrypi,bcm2835-firmware
+ - const: simple-mfd
+ - items:
+ - const: raspberrypi,bcm2712-firmware
+ - const: raspberrypi,bcm2835-firmware
+ - const: simple-mfd
mboxes:
maxItems: 1
--
2.47.3
^ permalink raw reply related
* [PATCH v5 1/8] soc: bcm2835: Use IS_REACHABLE for function declaration
From: Gregor Herburger @ 2026-05-20 14:27 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de>
The drivers that depend on the RASPBERRYPI_FIRMWARE use
depends on RASPBERRYPI_FIRMWARE || (COMPILE_TEST && !RASPBERRYPI_FIRMWARE)
This should ensure that the driver is not compiled in when
RASPBERRYPI_FIRMWARE is 'm' on COMPILE_TEST which leads to linker
errors.
The same can be achieved by using IS_REACHABLE in the
raspberrypi-firmware header. This evaluates to false when invoked from
built-in code. This way the Kconfig can be written as
depends on RASPBERRYPI_FIRMWARE || COMPILE_TEST
Which is a more readable variant.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
include/soc/bcm2835/raspberrypi-firmware.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
index e1f87fbfe5542..eb33838e0cd10 100644
--- a/include/soc/bcm2835/raspberrypi-firmware.h
+++ b/include/soc/bcm2835/raspberrypi-firmware.h
@@ -174,7 +174,7 @@ struct rpi_firmware_clk_rate_request {
.id = cpu_to_le32(_id), \
}
-#if IS_ENABLED(CONFIG_RASPBERRYPI_FIRMWARE)
+#if IS_REACHABLE(CONFIG_RASPBERRYPI_FIRMWARE)
int rpi_firmware_property(struct rpi_firmware *fw,
u32 tag, void *data, size_t len);
int rpi_firmware_property_list(struct rpi_firmware *fw,
--
2.47.3
^ permalink raw reply related
* [PATCH v5 0/8] nvmem: Add Raspberry Pi OTP nvmem driver
From: Gregor Herburger @ 2026-05-20 14:27 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger, Conor Dooley
Hi,
This series adds support for the Raspberry Pis OTP registers. The
Raspberry Pi has one or more OTP regions. These registers are accessible
through the firmware. Add a driver for it and add updates the devicetree
for the Raspberry Pi 5.
---
Changes in v5:
- Move alignment check to nvmem core
- Use IS_REACHABLE to simplify Kconfig
- use root_only for private driver
- Add driver as module to arch64 defconfig
- Use MODULE_DEVICE_TABLE
- Remove some unused attributes, fix typos, minor fixups
- Link to v4: https://patch.msgid.link/20260508-rpi-otp-driver-v4-0-cf8d725d8821@linutronix.de
Changes in v4:
- Additional patch to drop unnecessary select schema
- fix dt-bindings
- use __counted_by_le
- additional alignment check in read/write callbacks
- Link to v3: https://patch.msgid.link/20260506-rpi-otp-driver-v3-0-294602663695@linutronix.de
Changes in v3:
- dts: add "raspberrypi,bcm2835-firmware" as fallback and fix dt-bindings
- Fix Kconfig depends
- Changed firmware data fields to __le32
- Add MODULE_ALIAS
- Link to v2: https://patch.msgid.link/20260505-rpi-otp-driver-v2-0-e9176ec72837@linutronix.de
Changes in v2:
- register nvmem driver from firmware driver and drop firmware sub nodes
- Use struct_size and __counted_by for dynamic array
- Drop unneeded comment in Kconfig
- Use NVMEM_DEVID_NONE
- Use kzalloc
- Update module description
- Link to v1: https://patch.msgid.link/20260408-rpi-otp-driver-v1-0-e02d1dbe6008@linutronix.de
---
Gregor Herburger (8):
soc: bcm2835: Use IS_REACHABLE for function declaration
nvmem: core: Enforce stride and alignment checks for nvmem_device functions
dt-bindings: raspberrypi,bcm2835-firmware: Add bcm2712-firmware compatible
nvmem: Add the Raspberry Pi OTP driver
firmware: raspberrypi: register nvmem driver
arm64: dts: broadcom: bcm2712: add raspberrypi,bcm2712-firmware compatible
dt-bindings: raspberrypi,bcm2835-firmware: Drop unnecessary select
arm64: defconfig: Enable the raspberrypi otp driver as module
.../arm/bcm/raspberrypi,bcm2835-firmware.yaml | 20 ++--
.../boot/dts/broadcom/bcm2712-rpi-5-b-base.dtsi | 4 +-
arch/arm64/configs/defconfig | 1 +
drivers/firmware/raspberrypi.c | 59 +++++++++-
drivers/nvmem/Kconfig | 11 ++
drivers/nvmem/Makefile | 1 +
drivers/nvmem/core.c | 12 ++
drivers/nvmem/raspberrypi-otp.c | 130 +++++++++++++++++++++
include/soc/bcm2835/raspberrypi-firmware.h | 17 ++-
9 files changed, 240 insertions(+), 15 deletions(-)
---
base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
change-id: 20260408-rpi-otp-driver-75fce1dcff7d
Best regards,
--
Gregor Herburger <gregor.herburger@linutronix.de>
^ permalink raw reply
* [PATCH v5 2/8] nvmem: core: Enforce stride and alignment checks for nvmem_device functions
From: Gregor Herburger @ 2026-05-20 14:27 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, Kees Cook,
Gustavo A. R. Silva, Thomas Weißschuh
Cc: devicetree, linux-rpi-kernel, linux-arm-kernel, linux-kernel,
linux-hardening, Gregor Herburger
In-Reply-To: <20260520-rpi-otp-driver-v5-0-b26e5908eeac@linutronix.de>
The stride and word_size attributes in the nvmem_config struct are
currently only used when reading/writing through sysfs functions
bin_attr_nvmem_read/bin_attr_nvmem_write and in the nvmem_cell api.
Reads and writes with nvmem_device_write/nvmem_device_read still allow
unaligned access.
Add a check to these functions to enforce word_size and stride_length
aligned reads and writes.
Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
---
drivers/nvmem/core.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
index 311cb2e5a5c02..6b313f63d07ef 100644
--- a/drivers/nvmem/core.c
+++ b/drivers/nvmem/core.c
@@ -2068,6 +2068,12 @@ int nvmem_device_read(struct nvmem_device *nvmem,
if (!nvmem)
return -EINVAL;
+ if (!IS_ALIGNED(offset, nvmem->stride))
+ return -EINVAL;
+
+ if (!IS_ALIGNED(bytes, nvmem->word_size))
+ return -EINVAL;
+
rc = nvmem_reg_read(nvmem, offset, buf, bytes);
if (rc)
@@ -2096,6 +2102,12 @@ int nvmem_device_write(struct nvmem_device *nvmem,
if (!nvmem)
return -EINVAL;
+ if (!IS_ALIGNED(offset, nvmem->stride))
+ return -EINVAL;
+
+ if (!IS_ALIGNED(bytes, nvmem->word_size))
+ return -EINVAL;
+
rc = nvmem_reg_write(nvmem, offset, buf, bytes);
if (rc)
--
2.47.3
^ permalink raw reply related
* [PATCH] net: stmmac: mmc: Remove duplicate mmc_rx crc
From: Abid Ali via B4 Relay @ 2026-05-20 14:25 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maxime Coquelin, Alexandre Torgue
Cc: netdev, linux-stm32, linux-arm-kernel, linux-kernel, Abid Ali
From: Abid Ali <dev.taqnialabs@gmail.com>
Double read of mmc_rx_crc_error in XGMAC is removed.
Signed-off-by: Abid Ali <dev.taqnialabs@gmail.com>
---
drivers/net/ethernet/stmicro/stmmac/mmc_core.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
index 1b3b114e7..d81581dfa 100644
--- a/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/mmc_core.c
@@ -479,8 +479,6 @@ static void dwxgmac_mmc_read(void __iomem *mmcaddr, struct stmmac_counters *mmc)
&mmc->mmc_rx_multicastframe_g);
dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_CRC_ERR,
&mmc->mmc_rx_crc_error);
- dwxgmac_read_mmc_reg(mmcaddr, MMC_XGMAC_RX_CRC_ERR,
- &mmc->mmc_rx_crc_error);
mmc->mmc_rx_run_error += readl(mmcaddr + MMC_XGMAC_RX_RUNT_ERR);
mmc->mmc_rx_jabber_error += readl(mmcaddr + MMC_XGMAC_RX_JABBER_ERR);
mmc->mmc_rx_undersize_g += readl(mmcaddr + MMC_XGMAC_RX_UNDER);
---
base-commit: 028ef9c96e96197026887c0f092424679298aae8
change-id: 20260520-xgmac-mmc_rx_crc-cleanup-afcea6faa8ab
Best regards,
--
Abid Ali <dev.taqnialabs@gmail.com>
^ permalink raw reply related
* Re: [PATCH v8 phy-next 15/31] drm/rockchip: dw_hdmi: avoid direct dereference of phy->dev.of_node
From: Heiko Stuebner @ 2026-05-20 14:21 UTC (permalink / raw)
To: linux-phy, Vladimir Oltean
Cc: Vinod Koul, Neil Armstrong, dri-devel, freedreno,
linux-arm-kernel, linux-arm-msm, linux-can, linux-gpio, linux-ide,
linux-kernel, linux-media, linux-pci, linux-renesas-soc,
linux-riscv, linux-rockchip, linux-samsung-soc, linux-scsi,
linux-sunxi, linux-tegra, linux-usb, netdev, spacemit,
UNGLinuxDriver, Sandy Huang, Andy Yan, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter
In-Reply-To: <20260505100523.1922388-16-vladimir.oltean@nxp.com>
Hi Vladimir,
Am Dienstag, 5. Mai 2026, 12:05:07 Mitteleuropäische Sommerzeit schrieb Vladimir Oltean:
> The dw_hdmi-rockchip driver validates pixel clock rates against the
> HDMI PHY's internal clock provider on certain SoCs like RK3328.
> This is currently achieved by dereferencing hdmi->phy->dev.of_node
> to obtain the provider node, which violates the Generic PHY API's
> encapsulation (the goal is for struct phy to be an opaque pointer
> with a hidden definition, to be interacted with only using API
> functions or NULL pointer checks, for the case where optional variants
> of phy_get() did not find a PHY).
>
> Refactor dw_hdmi_rockchip_bind() to perform a manual phandle lookup
> on the "hdmi" PHY index within the controller's DT node. This provides
> a parallel path to the clock provider's OF node without relying on the
> internal structure of the struct phy handle.
>
> Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> Reviewed-by: Heiko Stueber <heiko@sntech.de>
there is now already more stuff depending on this change [0], and
the change itself also is sort of independent of the whole
phy-series. And somehow this series itself sadly hasn't gotten
much review yet.
So would you be ok with me just picking this one patch for the
drm-misc-tree?
Thanks
Heiko
[0] https://lore.kernel.org/dri-devel/20260518193748.2482823-1-jonas@kwiboo.se/
^ 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