* [PATCH net-next] net: macb: fix build of TX stall watchdog by replacing undefined netdev_warn_ratelimited
From: Lukasz Raczylo @ 2026-05-15 9:53 UTC (permalink / raw)
To: netdev
Cc: Theo Lebrun, Andrea della Porta, Nicolas Ferre, Claudiu Beznea,
Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-kernel, linux-arm-kernel, linux-rpi-kernel
In-Reply-To: <20260514215459.36109-4-lukasz@raczylo.com>
netdev_warn_ratelimited() does not exist in this kernel -- neither
mainline net-next nor raspberrypi/linux rpi-6.18.y define a
netdev_*_ratelimited() family. I confused it with the existing
net_warn_ratelimited() / pr_warn_ratelimited() macros when
authoring v2 patch 3 of the macb silent TX stall series, and the
result fails to build with implicit-function-declaration.
Replace with the standard `if (printk_ratelimit()) netdev_warn(...)`
pattern. Same semantics intended by v2 patch 3 (bounded log noise,
retains the netdev prefix in the message); works in every kernel
version.
Fixes the build of patch 3/3 of:
https://lore.kernel.org/netdev/20260514215459.36109-1-lukasz@raczylo.com/T/
Caught by an independent build test on the Talos Linux Pi 5 build
(John Laur / johnlaur on GitHub), reported at:
https://github.com/siderolabs/sbc-raspberrypi/issues/91#issuecomment-4456874307
Signed-off-by: Lukasz Raczylo <lukasz@raczylo.com>
---
drivers/net/ethernet/cadence/macb_main.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
--- a/drivers/net/ethernet/cadence/macb_main.c
+++ b/drivers/net/ethernet/cadence/macb_main.c
@@ -2057,10 +2057,11 @@ static void macb_tx_stall_watchdog(struct work_struct *work)
spin_unlock_irqrestore(&queue->tx_ptr_lock, flags);
if (stalled) {
- netdev_warn_ratelimited(bp->dev,
- "TX stall detected on queue %u (tail=%u head=%u); re-kicking TSTART\n",
- (unsigned int)(queue - bp->queues),
- cur_tail, cur_head);
+ if (printk_ratelimit())
+ netdev_warn(bp->dev,
+ "TX stall detected on queue %u (tail=%u head=%u); re-kicking TSTART\n",
+ (unsigned int)(queue - bp->queues),
+ cur_tail, cur_head);
macb_tx_restart(queue);
}
--
2.54.0
^ permalink raw reply
* Re: [PATCH v2 01/17] ACPI: GTDT: Account for GTDTv3 size when walking the platform timer descriptors
From: Sudeep Holla @ 2026-05-15 9:51 UTC (permalink / raw)
To: Marc Zyngier
Cc: linux-arm-kernel, linux-acpi, linux-kernel, devicetree,
Lorenzo Pieralisi, Sudeep Holla, Hanjun Guo, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Heiko Stuebner, Shawn Lin, Orson Zhai,
Baolin Wang, Michal Simek
In-Reply-To: <20260514150945.3917510-2-maz@kernel.org>
On Thu, May 14, 2026 at 04:09:29PM +0100, Marc Zyngier wrote:
> Since ARMv8.1, the architecture has grown an EL2-private virtual
> timer. This has been described in ACPI since ACPI v6.3 and revision
> 3 of the GTDT table.
>
> An aditional structure was added in ACPICA, though in a rather
> bizarre way, and merged in v5.1 as 8f5a14d053100 ("ACPICA: ACPI 6.3:
> add GTDT Revision 3 support").
>
> Finally plug the table parsing in GTDT, and correct the parsing of
> the platform timer subtables to account for the expanded size of
> the base table.
>
> Suggested-by: Sudeep Holla <sudeep.holla@kernel.org>
> Signed-off-by: Marc Zyngier <maz@kernel.org>
> ---
> drivers/acpi/arm64/gtdt.c | 15 ++++++++++++++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/arm64/gtdt.c b/drivers/acpi/arm64/gtdt.c
> index ffc867bac2d60..b9d9b8edf2df7 100644
> --- a/drivers/acpi/arm64/gtdt.c
> +++ b/drivers/acpi/arm64/gtdt.c
> @@ -32,6 +32,12 @@ struct acpi_gtdt_descriptor {
> struct acpi_table_gtdt *gtdt;
> void *gtdt_end;
> void *platform_timer;
> + bool v3;
> +};
> +
> +struct gtdt_v3 {
> + struct acpi_table_gtdt gtdt_v2;
> + struct acpi_gtdt_el2 el2_vtimer;
> };
>
> static struct acpi_gtdt_descriptor acpi_gtdt_desc __initdata;
> @@ -39,8 +45,14 @@ static struct acpi_gtdt_descriptor acpi_gtdt_desc __initdata;
> static __init bool platform_timer_valid(void *platform_timer)
> {
> struct acpi_gtdt_header *gh = platform_timer;
> + void *platform_timer_begin;
> +
> + if (acpi_gtdt_desc.v3)
> + platform_timer_begin = container_of(acpi_gtdt_desc.gtdt, struct gtdt_v3, gtdt_v2) + 1;
> + else
> + platform_timer_begin = acpi_gtdt_desc.gtdt + 1;
>
> - return (platform_timer >= (void *)(acpi_gtdt_desc.gtdt + 1) &&
> + return (platform_timer >= platform_timer_begin &&
> platform_timer < acpi_gtdt_desc.gtdt_end &&
> gh->length != 0 &&
> platform_timer + gh->length <= acpi_gtdt_desc.gtdt_end);
> @@ -169,6 +181,7 @@ int __init acpi_gtdt_init(struct acpi_table_header *table,
> acpi_gtdt_desc.gtdt = gtdt;
> acpi_gtdt_desc.gtdt_end = (void *)table + table->length;
> acpi_gtdt_desc.platform_timer = NULL;
> + acpi_gtdt_desc.v3 = gtdt->header.revision >= 3 && gtdt->header.length >= sizeof(struct gtdt_v3);
Regarding Sashiko’s comment about the missing length validation for GTDT v2, I
realised that the current check could cause a malformed v3 table to be
interpreted as v2 if its length does not match the expected v3 length.
It would be better to fail early and return an error rather than allow
processing to continue with the table incorrectly interpreted as v2.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH] iommu: Allow device driver to use its own PASID space for SVA
From: Joonwon Kang @ 2026-05-15 9:46 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.
Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Suggested-by: Kevin Tian <kevin.tian@intel.com>
Signed-off-by: Joonwon Kang <joonwonkang@google.com>
---
arch/x86/kernel/traps.c | 2 +
drivers/iommu/iommu-sva.c | 111 +++++++++++++++++++++++++++++---------
include/linux/iommu.h | 14 ++++-
3 files changed, 102 insertions(+), 25 deletions(-)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 0ca3912ecb7f..61e2e52105e5 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -864,6 +864,8 @@ static bool try_fixup_enqcmd_gp(void)
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..12d6d638c827 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);
@@ -39,10 +43,15 @@ 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 {
+ iommu_mm->pasid_global = false;
}
iommu_mm->pasid = pasid;
iommu_mm->mm = mm;
@@ -56,20 +65,9 @@ static struct iommu_mm_data *iommu_alloc_mm_data(struct mm_struct *mm, struct de
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,12 +82,25 @@ 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;
}
+ if ((pasid == IOMMU_PASID_GLOBAL_ANY && !iommu_mm->pasid_global) ||
+ (pasid != IOMMU_PASID_GLOBAL_ANY && iommu_mm->pasid_global)) {
+ ret = -EBUSY;
+ goto out_unlock;
+ } else if (pasid != IOMMU_PASID_GLOBAL_ANY && pasid != iommu_mm->pasid) {
+ /*
+ * Currently, a process simultaneously doing SVA with multiple
+ * devices with different PASIDs is not supported.
+ */
+ ret = -ENOSPC;
+ goto out_unlock;
+ }
+
/* A bond already exists, just take a reference`. */
attach_handle = iommu_attach_handle_get(group, iommu_mm->pasid, IOMMU_DOMAIN_SVA);
if (!IS_ERR(attach_handle)) {
@@ -157,8 +168,56 @@ struct iommu_sva *iommu_sva_bind_device(struct device *dev, struct mm_struct *mm
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 +257,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 +273,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.563.g4f69b47b94-goog
^ permalink raw reply related
* Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Sudeep Holla @ 2026-05-15 9:40 UTC (permalink / raw)
To: Jamie Nguyen
Cc: linux-arm-kernel@lists.infradead.org, Sudeep Holla,
linux-kernel@vger.kernel.org
In-Reply-To: <27E42CCD-8518-4802-B549-A79B94B5658A@nvidia.com>
On Thu, May 14, 2026 at 05:37:41PM +0000, Jamie Nguyen wrote:
>
>
> > On May 14, 2026, at 2:31 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> >
> > On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
> >> __ffa_partition_info_get_regs() walks the response with a hardcoded
> >> 24-byte stride (regs += 3) even though the SPMC tells us the actual
> >> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
> >> read into buf_sz and then thrown away.
> >>
> >> That works while every SPMC returns the FF-A v1.1 layout, but it falls
> >> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
> >> strides over half a descriptor at a time and ends up parsing every
> >> other entry from a slice of two adjacent ones.
> >>
> >> The FF-A spec (v1.2, section 18.5) says that the producer should
> >> report the descriptor size, and the consumer is supposed to stride by
> >> that size and ignore any trailing fields it doesn't understand. The
> >> non-REGS path (__ffa_partition_info_get) does this already, and the
> >> REGS path should match.
> >>
> >> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
> >> reports something we can't safely walk.
> >>
> >> Fixes: 7bc0f589c81d ("firmware: arm_ffa: Fix big-endian support in __ffa_partition_info_regs_get()")
> >> Signed-off-by: Jamie Nguyen <jamien@nvidia.com>
> >> ---
> >> drivers/firmware/arm_ffa/driver.c | 35 ++++++++++++++++++++++++++++---
> >> 1 file changed, 32 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/drivers/firmware/arm_ffa/driver.c b/drivers/firmware/arm_ffa/driver.c
> >> index c72ee4756585..b712e8a03dab 100644
> >> --- a/drivers/firmware/arm_ffa/driver.c
> >> +++ b/drivers/firmware/arm_ffa/driver.c
> >> @@ -321,6 +321,22 @@ __ffa_partition_info_get(u32 uuid0, u32 uuid1, u32 uuid2, u32 uuid3,
> >> #define PART_INFO_ID(x) ((u16)(FIELD_GET(PART_INFO_ID_MASK, (x))))
> >> #define PART_INFO_EXEC_CXT(x) ((u16)(FIELD_GET(PART_INFO_EXEC_CXT_MASK, (x))))
> >> #define PART_INFO_PROPERTIES(x) ((u32)(FIELD_GET(PART_INFO_PROPS_MASK, (x))))
> >> +
> >> +/*
> >> + * FF-A v1.2 section 13.9 Table 13.40: registers x3..x17 carry the partition
> >> + * descriptors, i.e. 15 u64 of payload per FFA_PARTITION_INFO_GET_REGS call.
> >> + */
> >> +#define FFA_PART_INFO_REGS_PAYLOAD_U64 15
> >> +
> >> +/*
> >> + * FF-A v1.1 partition information descriptor (FF-A v1.2 section 6.2.1
> >> + * Table 6.1): id (2) + exec_ctxt (2) + properties (4) + UUID (16) = 24
> >> + * bytes. This is the minimum size the SPMC must report; the kernel reads
> >> + * exactly these fields and ignores any trailing ones per the forward-
> >> + * compatibility rules in FF-A v1.2 section 18.5.
> >> + */
> >
> > I can't see any such details is the above mention version and section.
> > Can you confirm you are looking at [1] ?
>
> Yes, I am looking at [1]. The size field and the rule are in two
> different places:
>
> - Section 13.9 Table 13.40, page 188:
> x2 Bits[63:48] = "Size in bytes of each partition information
> entry descriptor."
> (read into buf_sz today and discarded)
>
Sorry my bad, I was looking at Section 18 and was confused a bit.
> - Section 18.5 page 264 rule 4:
> "A consumer of this data structure uses the size corresponding
> to the Framework version it implements to consume only fields
> defined in its version. Additional fields in the producer's
> version of this data structure are safely ignored enabling
> forward compatibility."
>
Now makes sense, was just looking at this w/o reading Section 13.9
> If you agree, I'll rebase against linux-next and send a v2.
>
Yes please. Thanks for your patience.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH v6 09/13] coresight: etm4x: missing cscfg_csdev_disable_active_config() in perf enable
From: Leo Yan @ 2026-05-15 9:39 UTC (permalink / raw)
To: Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <20260422132203.977549-10-yeoreum.yun@arm.com>
On Wed, Apr 22, 2026 at 02:21:59PM +0100, Yeoreum Yun wrote:
[...]
> @@ -895,6 +895,8 @@ static int etm4_parse_event_config(struct coresight_device *csdev,
> * Missing BB support could cause silent decode errors
> * so fail to open if it's not supported.
> */
> + if (cfg_hash)
> + cscfg_csdev_disable_active_config(csdev);
I prefer do a bit refactoring for this.
we just save cfg_hash and cfg_preset into drvdata in
etm4_parse_event_config():
drvdata->cfg_hash = ATTR_CFG_GET_FLD(attr, configid);
if (drvdata->cfg_hash)
drvdata->preset = ATTR_CFG_GET_FLD(attr, preset);
Then create two helpers:
etm4_cscfg_enable(csdev) {
struct etmv4_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
return cscfg_csdev_enable_active_config(csdev, drvdata->cfg_hash,
drvdata->preset);
}
etm4_cscfg_disable(csdev) {
cscfg_csdev_disable_active_config(csdev);
}
These helpers will be used by etm4_{enable|disable}_perf()
and etm4_{enable|disable}_sysfs(). This might benefit the future cscfg
refactoring.
Thanks,
Leo
P.s. I will stop review at here. I assume ETMv3 changes just mirror
ETMv4's. So all ETMv4's comments would apply on ETMv3 patches. If I
miss anything, please let me know.
^ permalink raw reply
* [PATCH v3 2/3] dt-bindings: pinctrl: Add aspeed,ast2700-soc1-pinctrl
From: Billy Tsai @ 2026-05-15 9:37 UTC (permalink / raw)
To: Linus Walleij, Tony Lindgren, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Bartosz Golaszewski,
Lee Jones, Ryan Chen
Cc: patrickw3, linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, BMC-SW, openbmc, Andrew Jeffery, linux-clk,
Billy Tsai
In-Reply-To: <20260515-pinctrl-single-bit-v3-0-e97da4312104@aspeedtech.com>
SoC1 in the AST2700 integrates its own pin controller responsible for
pin multiplexing and pin configuration.
The controller manages various peripheral functions such as eSPI, LPC,
VPI, SD, UART, I2C, I3C, PWM and others through SCU registers.
The binding reuses the standard pinmux and generic pin configuration
schemas and does not introduce custom Devicetree properties.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
.../pinctrl/aspeed,ast2700-soc1-pinctrl.yaml | 760 +++++++++++++++++++++
1 file changed, 760 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml
new file mode 100644
index 000000000000..76944fd14e2c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml
@@ -0,0 +1,760 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/aspeed,ast2700-soc1-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ASPEED AST2700 SoC1 Pin Controller
+
+maintainers:
+ - Billy Tsai <billy_tsai@aspeedtech.com>
+
+description:
+ The AST2700 features a dual-SoC architecture with two interconnected SoCs,
+ each having its own System Control Unit (SCU) for independent pin control.
+ This pin controller manages the pin multiplexing for SoC1.
+
+ The SoC1 pin controller manages pin functions including eSPI, LPC and I2C,
+ among others.
+
+properties:
+ compatible:
+ const: aspeed,ast2700-soc1-pinctrl
+ reg:
+ maxItems: 1
+
+patternProperties:
+ '-state$':
+ description: |
+ Pin control state.
+
+ If `function` is present, the node describes a pinmux state and must
+ specify `groups`.
+
+ For pin configuration, exactly one of `groups` or `pins` must be
+ specified in each state node. Group-level configuration applies to all
+ pins in the group. Pin-level configuration may be supplied in a
+ separate state node for individual pins; when both group-level and
+ pin-level configuration apply to the same pin, the pin-level
+ configuration takes precedence.
+
+ type: object
+ allOf:
+ - $ref: pinmux-node.yaml#
+ - $ref: pincfg-node.yaml#
+ - if:
+ required:
+ - function
+ then:
+ required:
+ - groups
+ - oneOf:
+ - required:
+ - groups
+ - required:
+ - pins
+ additionalProperties: false
+
+ properties:
+ function:
+ enum:
+ - ADC0
+ - ADC1
+ - ADC10
+ - ADC11
+ - ADC12
+ - ADC13
+ - ADC14
+ - ADC15
+ - ADC2
+ - ADC3
+ - ADC4
+ - ADC5
+ - ADC6
+ - ADC7
+ - ADC8
+ - ADC9
+ - AUXPWRGOOD0
+ - AUXPWRGOOD1
+ - CANBUS
+ - ESPI0
+ - ESPI1
+ - FSI0
+ - FSI1
+ - FSI2
+ - FSI3
+ - FWQSPI
+ - FWSPIABR
+ - FWWPN
+ - HBLED
+ - I2C0
+ - I2C1
+ - I2C10
+ - I2C11
+ - I2C12
+ - I2C13
+ - I2C14
+ - I2C15
+ - I2C2
+ - I2C3
+ - I2C4
+ - I2C5
+ - I2C6
+ - I2C7
+ - I2C8
+ - I2C9
+ - I2CF0
+ - I2CF1
+ - I2CF2
+ - I3C0
+ - I3C1
+ - I3C10
+ - I3C11
+ - I3C12
+ - I3C13
+ - I3C14
+ - I3C15
+ - I3C2
+ - I3C3
+ - I3C4
+ - I3C5
+ - I3C6
+ - I3C7
+ - I3C8
+ - I3C9
+ - JTAGM1
+ - LPC0
+ - LPC1
+ - LTPI
+ - MACLINK0
+ - MACLINK1
+ - MACLINK2
+ - MDIO0
+ - MDIO1
+ - MDIO2
+ - NCTS0
+ - NCTS1
+ - NCTS5
+ - NCTS6
+ - NDCD0
+ - NDCD1
+ - NDCD5
+ - NDCD6
+ - NDSR0
+ - NDSR1
+ - NDSR5
+ - NDSR6
+ - NDTR0
+ - NDTR1
+ - NDTR5
+ - NDTR6
+ - NRI0
+ - NRI1
+ - NRI5
+ - NRI6
+ - NRTS0
+ - NRTS1
+ - NRTS5
+ - NRTS6
+ - OSCCLK
+ - PCIERC
+ - PWM0
+ - PWM1
+ - PWM10
+ - PWM11
+ - PWM12
+ - PWM13
+ - PWM14
+ - PWM15
+ - PWM2
+ - PWM3
+ - PWM4
+ - PWM5
+ - PWM6
+ - PWM7
+ - PWM8
+ - PWM9
+ - QSPI0
+ - QSPI1
+ - QSPI2
+ - RGMII0
+ - RGMII1
+ - RMII0
+ - RMII0RCLKO
+ - RMII1
+ - RMII1RCLKO
+ - SALT0
+ - SALT1
+ - SALT10
+ - SALT11
+ - SALT12
+ - SALT13
+ - SALT14
+ - SALT15
+ - SALT2
+ - SALT3
+ - SALT4
+ - SALT5
+ - SALT6
+ - SALT7
+ - SALT8
+ - SALT9
+ - SD
+ - SGMII
+ - SGPM0
+ - SGPM1
+ - SGPS
+ - SIOONCTRLN0
+ - SIOONCTRLN1
+ - SIOPBIN0
+ - SIOPBIN1
+ - SIOPBON0
+ - SIOPBON1
+ - SIOPWREQN0
+ - SIOPWREQN1
+ - SIOPWRGD1
+ - SIOS3N0
+ - SIOS3N1
+ - SIOS5N0
+ - SIOS5N1
+ - SIOSCIN0
+ - SIOSCIN1
+ - SMON0
+ - SMON1
+ - SPI0
+ - SPI0ABR
+ - SPI0CS1
+ - SPI0WPN
+ - SPI1
+ - SPI1ABR
+ - SPI1CS1
+ - SPI1WPN
+ - SPI2
+ - SPI2CS1
+ - TACH0
+ - TACH1
+ - TACH10
+ - TACH11
+ - TACH12
+ - TACH13
+ - TACH14
+ - TACH15
+ - TACH2
+ - TACH3
+ - TACH4
+ - TACH5
+ - TACH6
+ - TACH7
+ - TACH8
+ - TACH9
+ - THRU0
+ - THRU1
+ - THRU2
+ - THRU3
+ - UART0
+ - UART1
+ - UART10
+ - UART11
+ - UART2
+ - UART3
+ - UART5
+ - UART6
+ - UART7
+ - UART8
+ - UART9
+ - USB2C
+ - USB2D
+ - USBUART
+ - VGA
+ - VPI
+ - WDTRST0N
+ - WDTRST1N
+ - WDTRST2N
+ - WDTRST3N
+ - WDTRST4N
+ - WDTRST5N
+ - WDTRST6N
+ - WDTRST7N
+
+ groups:
+ enum:
+ - ADC0
+ - ADC1
+ - ADC10
+ - ADC11
+ - ADC12
+ - ADC13
+ - ADC14
+ - ADC15
+ - ADC2
+ - ADC3
+ - ADC4
+ - ADC5
+ - ADC6
+ - ADC7
+ - ADC8
+ - ADC9
+ - AUXPWRGOOD0
+ - AUXPWRGOOD1
+ - CANBUS
+ - DI2C0
+ - DI2C1
+ - DI2C10
+ - DI2C11
+ - DI2C12
+ - DI2C13
+ - DI2C14
+ - DI2C15
+ - DI2C2
+ - DI2C3
+ - DI2C8
+ - DI2C9
+ - DSGPM0
+ - ESPI0
+ - ESPI1
+ - FSI0
+ - FSI1
+ - FSI2
+ - FSI3
+ - FWQSPI
+ - FWSPIABR
+ - FWWPN
+ - HBLED
+ - HVI3C0
+ - HVI3C1
+ - HVI3C12
+ - HVI3C13
+ - HVI3C14
+ - HVI3C15
+ - HVI3C2
+ - HVI3C3
+ - I2C0
+ - I2C1
+ - I2C10
+ - I2C11
+ - I2C12
+ - I2C13
+ - I2C14
+ - I2C15
+ - I2C2
+ - I2C3
+ - I2C4
+ - I2C5
+ - I2C6
+ - I2C7
+ - I2C8
+ - I2C9
+ - I2CF0
+ - I2CF1
+ - I2CF2
+ - I3C10
+ - I3C11
+ - I3C4
+ - I3C5
+ - I3C6
+ - I3C7
+ - I3C8
+ - I3C9
+ - JTAGM1
+ - LPC0
+ - LPC1
+ - LTPI
+ - LTPI_PS_I2C0
+ - LTPI_PS_I2C1
+ - LTPI_PS_I2C2
+ - LTPI_PS_I2C3
+ - MACLINK0
+ - MACLINK1
+ - MACLINK2
+ - MDIO0
+ - MDIO1
+ - MDIO2
+ - NCTS0
+ - NCTS1
+ - NCTS5
+ - NCTS6
+ - NDCD0
+ - NDCD1
+ - NDCD5
+ - NDCD6
+ - NDSR0
+ - NDSR1
+ - NDSR5
+ - NDSR6
+ - NDTR0
+ - NDTR1
+ - NDTR5
+ - NDTR6
+ - NRI0
+ - NRI1
+ - NRI5
+ - NRI6
+ - NRTS0
+ - NRTS1
+ - NRTS5
+ - NRTS6
+ - OSCCLK
+ - PE2SGRSTN
+ - PWM0
+ - PWM1
+ - PWM10
+ - PWM11
+ - PWM12
+ - PWM13
+ - PWM14
+ - PWM15
+ - PWM2
+ - PWM3
+ - PWM4
+ - PWM5
+ - PWM6
+ - PWM7
+ - PWM8
+ - PWM9
+ - QSPI0
+ - QSPI1
+ - QSPI2
+ - RGMII0
+ - RGMII1
+ - RMII0
+ - RMII0RCLKO
+ - RMII1
+ - RMII1RCLKO
+ - SALT0
+ - SALT1
+ - SALT10
+ - SALT11
+ - SALT12
+ - SALT13
+ - SALT14
+ - SALT15
+ - SALT2
+ - SALT3
+ - SALT4
+ - SALT5
+ - SALT6
+ - SALT7
+ - SALT8
+ - SALT9
+ - SD
+ - SGMII
+ - SGPM0
+ - SGPM1
+ - SGPS
+ - SIOONCTRLN0
+ - SIOONCTRLN1
+ - SIOPBIN0
+ - SIOPBIN1
+ - SIOPBON0
+ - SIOPBON1
+ - SIOPWREQN0
+ - SIOPWREQN1
+ - SIOPWRGD1
+ - SIOS3N0
+ - SIOS3N1
+ - SIOS5N0
+ - SIOS5N1
+ - SIOSCIN0
+ - SIOSCIN1
+ - SMON0
+ - SMON1
+ - SPI0
+ - SPI0ABR
+ - SPI0CS1
+ - SPI0WPN
+ - SPI1
+ - SPI1ABR
+ - SPI1CS1
+ - SPI1WPN
+ - SPI2
+ - SPI2CS1
+ - TACH0
+ - TACH1
+ - TACH10
+ - TACH11
+ - TACH12
+ - TACH13
+ - TACH14
+ - TACH15
+ - TACH2
+ - TACH3
+ - TACH4
+ - TACH5
+ - TACH6
+ - TACH7
+ - TACH8
+ - TACH9
+ - THRU0
+ - THRU1
+ - THRU2
+ - THRU3
+ - UART0
+ - UART1
+ - UART10
+ - UART11
+ - UART2
+ - UART3
+ - UART5
+ - UART6
+ - UART7
+ - UART8
+ - UART9
+ - USB2CD
+ - USB2CH
+ - USB2CU
+ - USB2CUD
+ - USB2DD
+ - USB2DH
+ - USBUART
+ - VGA
+ - VPI
+ - WDTRST0N
+ - WDTRST1N
+ - WDTRST2N
+ - WDTRST3N
+ - WDTRST4N
+ - WDTRST5N
+ - WDTRST6N
+ - WDTRST7N
+
+ pins:
+ enum:
+ - A14
+ - A15
+ - A18
+ - A19
+ - A21
+ - A22
+ - A23
+ - A24
+ - A25
+ - A26
+ - A6
+ - A7
+ - A8
+ - AA12
+ - AA13
+ - AA14
+ - AA15
+ - AA16
+ - AA17
+ - AA18
+ - AA20
+ - AA21
+ - AA22
+ - AA23
+ - AA24
+ - AA25
+ - AA26
+ - AB15
+ - AB16
+ - AB17
+ - AB18
+ - AB19
+ - AB20
+ - AB21
+ - AB22
+ - AB23
+ - AB24
+ - AB25
+ - AB26
+ - AC15
+ - AC16
+ - AC17
+ - AC18
+ - AC19
+ - AC20
+ - AC22
+ - AC24
+ - AC25
+ - AC26
+ - AD15
+ - AD16
+ - AD17
+ - AD18
+ - AD19
+ - AD20
+ - AD22
+ - AD25
+ - AD26
+ - AE16
+ - AE17
+ - AE18
+ - AE19
+ - AE20
+ - AE21
+ - AE23
+ - AE25
+ - AE26
+ - AF16
+ - AF17
+ - AF18
+ - AF19
+ - AF20
+ - AF21
+ - AF23
+ - AF25
+ - AF26
+ - B10
+ - B11
+ - B12
+ - B13
+ - B14
+ - B15
+ - B16
+ - B18
+ - B19
+ - B21
+ - B22
+ - B23
+ - B24
+ - B25
+ - B26
+ - B6
+ - B7
+ - B8
+ - B9
+ - C10
+ - C11
+ - C12
+ - C13
+ - C14
+ - C15
+ - C16
+ - C17
+ - C18
+ - C19
+ - C20
+ - C23
+ - C26
+ - C6
+ - C7
+ - C8
+ - C9
+ - D10
+ - D12
+ - D14
+ - D15
+ - D19
+ - D20
+ - D24
+ - D26
+ - D7
+ - D8
+ - D9
+ - E10
+ - E11
+ - E12
+ - E13
+ - E14
+ - E26
+ - E7
+ - E8
+ - E9
+ - F10
+ - F11
+ - F12
+ - F13
+ - F14
+ - F26
+ - F7
+ - F8
+ - F9
+ - G10
+ - G11
+ - G7
+ - G8
+ - G9
+ - H10
+ - H11
+ - H7
+ - H8
+ - H9
+ - J10
+ - J11
+ - J12
+ - J13
+ - J9
+ - K12
+ - K13
+ - L12
+ - M13
+ - M14
+ - M15
+ - M16
+ - N13
+ - N14
+ - N15
+ - N25
+ - N26
+ - P13
+ - P14
+ - P25
+ - P26
+ - R14
+ - R25
+ - R26
+ - T23
+ - T24
+ - U21
+ - U22
+ - U25
+ - U26
+ - V14
+ - V16
+ - V17
+ - V18
+ - V19
+ - V20
+ - V21
+ - V22
+ - V23
+ - V24
+ - W14
+ - W16
+ - W17
+ - W18
+ - W20
+ - W21
+ - W22
+ - W25
+ - W26
+ - Y11
+ - Y15
+ - Y16
+ - Y17
+ - Y18
+ - Y20
+ - Y21
+ - Y22
+ - Y23
+ - Y24
+ - Y25
+ - Y26
+
+ drive-strength:
+ enum: [4, 8, 12, 16]
+
+ bias-disable: true
+ bias-pull-up: true
+ bias-pull-down: true
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: pinctrl.yaml#
+
+additionalProperties: false
+
+examples:
+ - |
+ pinctrl@400 {
+ compatible = "aspeed,ast2700-soc1-pinctrl";
+ reg = <0x400 0x2A0>;
+ sgpm0-state {
+ function = "SGPM0";
+ groups = "SGPM0";
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/3] dt-bindings: mfd: aspeed,ast2x00-scu: Support AST2700 SoC1 pinctrl
From: Billy Tsai @ 2026-05-15 9:37 UTC (permalink / raw)
To: Linus Walleij, Tony Lindgren, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Bartosz Golaszewski,
Lee Jones, Ryan Chen
Cc: patrickw3, linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, BMC-SW, openbmc, Andrew Jeffery, linux-clk,
Billy Tsai
In-Reply-To: <20260515-pinctrl-single-bit-v3-0-e97da4312104@aspeedtech.com>
The AST2700 SoC integrates two interconnected SoC instances, each
managed by its own System Control Unit (SCU).
Allow the AST2700 SoC1 pin controller to be described as a child
node of the SCU by extending the compatible strings accepted by
the SCU binding.
There is no functional change to the SCU binding beyond permitting
the aspeed,ast2700-soc1-pinctrl compatible string.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
Note: The companion AST2700 SoC0 pinctrl series modifies the same
binding and has been applied to pinctrl/for-next. Linus Walleij noted
for the equivalent SoC0 MFD patch that it should be applied through the
MFD tree by Lee Jones, providing an Acked-by in the process [1]. The
same routing applies to this patch.
[1] https://lore.kernel.org/all/CAD++jL=3p9BvDgaot3=emM4Zn5jU-ZAUKtB4UwT1HzDiyzKq4Q@mail.gmail.com/
---
Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
index a87f31fce019..b81c561d2a8c 100644
--- a/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
+++ b/Documentation/devicetree/bindings/mfd/aspeed,ast2x00-scu.yaml
@@ -87,6 +87,7 @@ patternProperties:
- aspeed,ast2400-pinctrl
- aspeed,ast2500-pinctrl
- aspeed,ast2600-pinctrl
+ - aspeed,ast2700-soc1-pinctrl
required:
- compatible
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/3] pinctrl: aspeed: Add AST2700 SoC1 support
From: Billy Tsai @ 2026-05-15 9:37 UTC (permalink / raw)
To: Linus Walleij, Tony Lindgren, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Joel Stanley, Andrew Jeffery, Bartosz Golaszewski,
Lee Jones, Ryan Chen
Cc: patrickw3, linux-gpio, devicetree, linux-kernel, linux-arm-kernel,
linux-aspeed, BMC-SW, openbmc, Andrew Jeffery, linux-clk,
Billy Tsai
Legacy ASPEED pin controllers have historically not had a coherent
register interface. Control fields often had no consistent mapping to
individual pins, and configuring a function frequently required
coordinating multiple control bits across several registers. As a
result, the existing ASPEED pinctrl drivers rely on complex macro
infrastructure to describe the dependencies between pins, functions,
and register fields.
The pin controller for SoC1 in the AST2700 breaks from this legacy
design.
For SoC1, each pin maps directly to a dedicated function field in the
SCU register space that determines the active mux function for that
pin. This results in a much more regular register layout compared to
previous generations.
While the behaviour is conceptually similar to pinctrl-single, the
register layout and configuration model differ enough that reusing
pinctrl-single directly is not practical. Therefore this driver is
implemented as a SoC-specific pinctrl driver using static data tables
to describe the register layout.
The binding reuses the standard pinmux and generic pin configuration
schemas and does not introduce any custom Devicetree properties.
Signed-off-by: Billy Tsai <billy_tsai@aspeedtech.com>
---
Changes in v3:
- Added pin configuration group support for AST2700 SoC1 by
implementing `pin_config_group_get()` and `pin_config_group_set()`.
- Restricted AST2700 SoC1 `drive-strength` settings to the supported
4/8/12/16 mA values in the pinctrl driver.
- Convert kernel-doc comment for aspeed_g7_soc1_drv_map to a regular
comment to avoid kernel-doc warning reported by kernel test robot.
- Update the AST2700 SoC1 pinctrl binding to describe the `reg`
property and require it.
- Allow standard pinconf properties in pin state nodes.
- Add a binding example for the AST2700 SoC1 pinctrl node.
- Add state-node description, function+groups dependency constraint,
and oneOf groups/pins constraint to the binding, matching the SoC0
binding style.
- Add pins enum (212 entries) to the binding to cover all physical pins
that support per-pin configuration.
- Add UART modem-line signals as independent functions/groups:
NCTS0/1/5/6, NDCD0/1/5/6, NDSR0/1/5/6, NDTR0/1/5/6,
NRI0/1/5/6, NRTS0/1/5/6; remove those pins from UART0/1/5/6 groups.
- Add LTPI_PS_I2C0/1/2/3 functions/groups for I2C-over-LTPI;
extend I2C0/1/2/3 functions with the new LTPI groups.
- Fix typo: rename RMII0RCKO/RMII1RCKO to RMII0RCLKO/RMII1RCLKO.
- Fix wrong index: rename DSGPM1 to DSGPM0.
- Kconfig: use "Aspeed G7 SoC1 pin control" to match neighbouring entries.
- pin_config_get: fix BIAS_DISABLE readback (val=!val must be skipped
for BIAS_DISABLE since hardware bit=1 means pull disabled).
- set_mux: remove dead null check on grp; propagate regmap_update_bits()
return value.
- gpio_request_enable: propagate regmap_update_bits() return value.
- Link to v2: https://lore.kernel.org/r/20260306-pinctrl-single-bit-v2-0-79918cfab641@aspeedtech.com
Changes in v2:
- Updated the series title to focus on AST2700 SoC1 support.
- Reworked implementation to use static SoC-specific layout tables
instead of a generic packed-field model.
- Dropped the generic "pinctrl-packed" driver approach.
- Removed custom Devicetree properties.
- Updated binding to reuse standard pinmux and generic pin
configuration schemas.
- Link to v1: https://lore.kernel.org/r/20260213-pinctrl-single-bit-v1-0-c60f2fb80efb@aspeedtech.com
---
Billy Tsai (3):
dt-bindings: mfd: aspeed,ast2x00-scu: Support AST2700 SoC1 pinctrl
dt-bindings: pinctrl: Add aspeed,ast2700-soc1-pinctrl
pinctrl: aspeed: Add AST2700 SoC1 support
.../bindings/mfd/aspeed,ast2x00-scu.yaml | 1 +
.../pinctrl/aspeed,ast2700-soc1-pinctrl.yaml | 760 +++++++++
drivers/pinctrl/aspeed/Kconfig | 14 +
drivers/pinctrl/aspeed/Makefile | 1 +
drivers/pinctrl/aspeed/pinctrl-aspeed-g7-soc1.c | 1732 ++++++++++++++++++++
5 files changed, 2508 insertions(+)
---
base-commit: e532a5a81d0db872acd2c0a92d2639580ca3da44
change-id: 20260211-pinctrl-single-bit-da213f282c95
Best regards,
--
Billy Tsai <billy_tsai@aspeedtech.com>
^ permalink raw reply
* [PATCH v2 5/6] firmware: samsung: acpm: Add TMU protocol support
From: Tudor Ambarus @ 2026-05-15 9:32 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Michael Turquette,
Stephen Boyd, Lee Jones
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, andre.draszik, jyescas, kernel-team,
Krzysztof Kozlowski
In-Reply-To: <20260515-acpm-tmu-helpers-v2-0-8ca011d5a965@linaro.org>
The Thermal Management Unit (TMU) on the Google GS101 SoC is managed
through a hybrid model shared between the kernel and the Alive Clock
and Power Manager (ACPM) firmware.
Add the protocol helpers required to communicate with the ACPM for
thermal operations, including initialization, threshold configuration,
temperature reading, and system suspend/resume handshakes.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
---
drivers/firmware/samsung/Makefile | 1 +
drivers/firmware/samsung/exynos-acpm-tmu.c | 239 +++++++++++++++++++++
drivers/firmware/samsung/exynos-acpm-tmu.h | 28 +++
drivers/firmware/samsung/exynos-acpm.c | 12 ++
.../linux/firmware/samsung/exynos-acpm-protocol.h | 18 ++
5 files changed, 298 insertions(+)
diff --git a/drivers/firmware/samsung/Makefile b/drivers/firmware/samsung/Makefile
index 80d4f89b33a9..5a6f72bececf 100644
--- a/drivers/firmware/samsung/Makefile
+++ b/drivers/firmware/samsung/Makefile
@@ -3,4 +3,5 @@
acpm-protocol-objs := exynos-acpm.o
acpm-protocol-objs += exynos-acpm-pmic.o
acpm-protocol-objs += exynos-acpm-dvfs.o
+acpm-protocol-objs += exynos-acpm-tmu.o
obj-$(CONFIG_EXYNOS_ACPM_PROTOCOL) += acpm-protocol.o
diff --git a/drivers/firmware/samsung/exynos-acpm-tmu.c b/drivers/firmware/samsung/exynos-acpm-tmu.c
new file mode 100644
index 000000000000..c68d60b4c0b3
--- /dev/null
+++ b/drivers/firmware/samsung/exynos-acpm-tmu.c
@@ -0,0 +1,239 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright 2020 Samsung Electronics Co., Ltd.
+ * Copyright 2020 Google LLC.
+ * Copyright 2026 Linaro Ltd.
+ */
+
+#include <linux/array_size.h>
+#include <linux/bitfield.h>
+#include <linux/bits.h>
+#include <linux/firmware/samsung/exynos-acpm-protocol.h>
+#include <linux/ktime.h>
+#include <linux/string.h>
+#include <linux/types.h>
+#include <linux/units.h>
+
+#include "exynos-acpm.h"
+#include "exynos-acpm-tmu.h"
+
+/* IPC Request Types */
+#define ACPM_TMU_INIT 0x01
+#define ACPM_TMU_READ_TEMP 0x02
+#define ACPM_TMU_SUSPEND 0x04
+#define ACPM_TMU_RESUME 0x10
+#define ACPM_TMU_THRESHOLD 0x11
+#define ACPM_TMU_INTEN 0x12
+#define ACPM_TMU_CONTROL 0x13
+#define ACPM_TMU_IRQ_CLEAR 0x14
+
+#define ACPM_TMU_TX_DATA_LEN 8
+#define ACPM_TMU_RX_DATA_LEN 7
+
+struct acpm_tmu_tx {
+ u16 ctx;
+ u16 fw_use;
+ u8 type;
+ u8 rsvd0;
+ u8 tzid;
+ u8 rsvd1;
+ u8 data[ACPM_TMU_TX_DATA_LEN];
+} __packed;
+
+struct acpm_tmu_rx {
+ u16 ctx;
+ u16 fw_use;
+ u8 type;
+ s8 ret;
+ u8 tzid;
+ s8 temp;
+ u8 rsvd;
+ u8 data[ACPM_TMU_RX_DATA_LEN];
+} __packed;
+
+union acpm_tmu_msg {
+ u32 data[4];
+ struct acpm_tmu_tx tx;
+ struct acpm_tmu_rx rx;
+};
+
+static int acpm_tmu_to_linux_err(s8 fw_err)
+{
+ /*
+ * ACPM_TMU_INIT uses BIT(0) and BIT(1) of msg.rx.ret to flag APM
+ * capabilities. Treat zero and all positive values as success.
+ */
+ if (fw_err >= 0)
+ return 0;
+
+ if (fw_err == -1)
+ return -EACCES;
+
+ return -EIO;
+}
+
+int acpm_tmu_init(struct acpm_handle *handle, unsigned int acpm_chan_id)
+{
+ union acpm_tmu_msg msg = {0};
+ struct acpm_xfer xfer;
+ int ret;
+
+ msg.tx.type = ACPM_TMU_INIT;
+ acpm_set_xfer(&xfer, msg.data, ARRAY_SIZE(msg.data), acpm_chan_id,
+ true);
+
+ ret = acpm_do_xfer(handle, &xfer);
+ if (ret)
+ return ret;
+
+ return acpm_tmu_to_linux_err(msg.rx.ret);
+}
+
+int acpm_tmu_read_temp(struct acpm_handle *handle, unsigned int acpm_chan_id,
+ u8 tz, int *temp)
+{
+ union acpm_tmu_msg msg = {0};
+ struct acpm_xfer xfer;
+ int ret;
+
+ msg.tx.type = ACPM_TMU_READ_TEMP;
+ msg.tx.tzid = tz;
+
+ acpm_set_xfer(&xfer, msg.data, ARRAY_SIZE(msg.data), acpm_chan_id,
+ true);
+
+ ret = acpm_do_xfer(handle, &xfer);
+ if (ret)
+ return ret;
+
+ ret = acpm_tmu_to_linux_err(msg.rx.ret);
+ if (ret)
+ return ret;
+
+ *temp = msg.rx.temp;
+
+ return 0;
+}
+
+int acpm_tmu_set_threshold(struct acpm_handle *handle,
+ unsigned int acpm_chan_id, u8 tz,
+ const u8 temperature[8], size_t tlen)
+{
+ union acpm_tmu_msg msg = {0};
+ struct acpm_xfer xfer;
+ int ret;
+
+ if (tlen > ACPM_TMU_TX_DATA_LEN)
+ return -EINVAL;
+
+ msg.tx.type = ACPM_TMU_THRESHOLD;
+ msg.tx.tzid = tz;
+ memcpy(msg.tx.data, temperature, tlen);
+
+ acpm_set_xfer(&xfer, msg.data, ARRAY_SIZE(msg.data), acpm_chan_id,
+ true);
+
+ ret = acpm_do_xfer(handle, &xfer);
+ if (ret)
+ return ret;
+
+ return acpm_tmu_to_linux_err(msg.rx.ret);
+}
+
+int acpm_tmu_set_interrupt_enable(struct acpm_handle *handle,
+ unsigned int acpm_chan_id, u8 tz, u8 inten)
+{
+ union acpm_tmu_msg msg = {0};
+ struct acpm_xfer xfer;
+ int ret;
+
+ msg.tx.type = ACPM_TMU_INTEN;
+ msg.tx.tzid = tz;
+ msg.tx.data[0] = inten;
+
+ acpm_set_xfer(&xfer, msg.data, ARRAY_SIZE(msg.data), acpm_chan_id,
+ true);
+
+ ret = acpm_do_xfer(handle, &xfer);
+ if (ret)
+ return ret;
+
+ return acpm_tmu_to_linux_err(msg.rx.ret);
+}
+
+int acpm_tmu_tz_control(struct acpm_handle *handle, unsigned int acpm_chan_id,
+ u8 tz, bool enable)
+{
+ union acpm_tmu_msg msg = {0};
+ struct acpm_xfer xfer;
+ int ret;
+
+ msg.tx.type = ACPM_TMU_CONTROL;
+ msg.tx.tzid = tz;
+ msg.tx.data[0] = enable ? 1 : 0;
+
+ acpm_set_xfer(&xfer, msg.data, ARRAY_SIZE(msg.data), acpm_chan_id,
+ true);
+
+ ret = acpm_do_xfer(handle, &xfer);
+ if (ret)
+ return ret;
+
+ return acpm_tmu_to_linux_err(msg.rx.ret);
+}
+
+int acpm_tmu_clear_tz_irq(struct acpm_handle *handle, unsigned int acpm_chan_id,
+ u8 tz)
+{
+ union acpm_tmu_msg msg = {0};
+ struct acpm_xfer xfer;
+ int ret;
+
+ msg.tx.type = ACPM_TMU_IRQ_CLEAR;
+ msg.tx.tzid = tz;
+
+ acpm_set_xfer(&xfer, msg.data, ARRAY_SIZE(msg.data), acpm_chan_id,
+ true);
+
+ ret = acpm_do_xfer(handle, &xfer);
+ if (ret)
+ return ret;
+
+ return acpm_tmu_to_linux_err(msg.rx.ret);
+}
+
+int acpm_tmu_suspend(struct acpm_handle *handle, unsigned int acpm_chan_id)
+{
+ union acpm_tmu_msg msg = {0};
+ struct acpm_xfer xfer;
+ int ret;
+
+ msg.tx.type = ACPM_TMU_SUSPEND;
+
+ acpm_set_xfer(&xfer, msg.data, ARRAY_SIZE(msg.data), acpm_chan_id,
+ true);
+
+ ret = acpm_do_xfer(handle, &xfer);
+ if (ret)
+ return ret;
+
+ return acpm_tmu_to_linux_err(msg.rx.ret);
+}
+
+int acpm_tmu_resume(struct acpm_handle *handle, unsigned int acpm_chan_id)
+{
+ union acpm_tmu_msg msg = {0};
+ struct acpm_xfer xfer;
+ int ret;
+
+ msg.tx.type = ACPM_TMU_RESUME;
+
+ acpm_set_xfer(&xfer, msg.data, ARRAY_SIZE(msg.data), acpm_chan_id,
+ true);
+
+ ret = acpm_do_xfer(handle, &xfer);
+ if (ret)
+ return ret;
+
+ return acpm_tmu_to_linux_err(msg.rx.ret);
+}
diff --git a/drivers/firmware/samsung/exynos-acpm-tmu.h b/drivers/firmware/samsung/exynos-acpm-tmu.h
new file mode 100644
index 000000000000..8b89f29fda67
--- /dev/null
+++ b/drivers/firmware/samsung/exynos-acpm-tmu.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * Copyright 2020 Samsung Electronics Co., Ltd.
+ * Copyright 2020 Google LLC.
+ * Copyright 2026 Linaro Ltd.
+ */
+#ifndef __EXYNOS_ACPM_TMU_H__
+#define __EXYNOS_ACPM_TMU_H__
+
+#include <linux/types.h>
+
+struct acpm_handle;
+
+int acpm_tmu_init(struct acpm_handle *handle, unsigned int acpm_chan_id);
+int acpm_tmu_read_temp(struct acpm_handle *handle, unsigned int acpm_chan_id,
+ u8 tz, int *temp);
+int acpm_tmu_set_threshold(struct acpm_handle *handle,
+ unsigned int acpm_chan_id, u8 tz,
+ const u8 temperature[8], size_t tlen);
+int acpm_tmu_set_interrupt_enable(struct acpm_handle *handle,
+ unsigned int acpm_chan_id, u8 tz, u8 inten);
+int acpm_tmu_tz_control(struct acpm_handle *handle, unsigned int acpm_chan_id,
+ u8 tz, bool enable);
+int acpm_tmu_clear_tz_irq(struct acpm_handle *handle, unsigned int acpm_chan_id,
+ u8 tz);
+int acpm_tmu_suspend(struct acpm_handle *handle, unsigned int acpm_chan_id);
+int acpm_tmu_resume(struct acpm_handle *handle, unsigned int acpm_chan_id);
+#endif /* __EXYNOS_ACPM_TMU_H__ */
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index 1a0d98b55439..2cebc5456968 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -33,6 +33,7 @@
#include "exynos-acpm.h"
#include "exynos-acpm-dvfs.h"
#include "exynos-acpm-pmic.h"
+#include "exynos-acpm-tmu.h"
#define ACPM_PROTOCOL_SEQNUM GENMASK(21, 16)
@@ -688,6 +689,17 @@ static const struct acpm_ops exynos_acpm_driver_ops = {
.bulk_write = acpm_pmic_bulk_write,
.update_reg = acpm_pmic_update_reg,
},
+
+ .tmu = {
+ .init = acpm_tmu_init,
+ .read_temp = acpm_tmu_read_temp,
+ .set_threshold = acpm_tmu_set_threshold,
+ .set_interrupt_enable = acpm_tmu_set_interrupt_enable,
+ .tz_control = acpm_tmu_tz_control,
+ .clear_tz_irq = acpm_tmu_clear_tz_irq,
+ .suspend = acpm_tmu_suspend,
+ .resume = acpm_tmu_resume,
+ },
};
static int acpm_probe(struct platform_device *pdev)
diff --git a/include/linux/firmware/samsung/exynos-acpm-protocol.h b/include/linux/firmware/samsung/exynos-acpm-protocol.h
index fbf1829b33db..08d9f5c95701 100644
--- a/include/linux/firmware/samsung/exynos-acpm-protocol.h
+++ b/include/linux/firmware/samsung/exynos-acpm-protocol.h
@@ -35,9 +35,27 @@ struct acpm_pmic_ops {
u8 type, u8 reg, u8 chan, u8 value, u8 mask);
};
+struct acpm_tmu_ops {
+ int (*init)(struct acpm_handle *handle, unsigned int acpm_chan_id);
+ int (*read_temp)(struct acpm_handle *handle, unsigned int acpm_chan_id,
+ u8 tz, int *temp);
+ int (*set_threshold)(struct acpm_handle *handle,
+ unsigned int acpm_chan_id, u8 tz,
+ const u8 temperature[8], size_t tlen);
+ int (*set_interrupt_enable)(struct acpm_handle *handle,
+ unsigned int acpm_chan_id, u8 tz, u8 inten);
+ int (*tz_control)(struct acpm_handle *handle, unsigned int acpm_chan_id,
+ u8 tz, bool enable);
+ int (*clear_tz_irq)(struct acpm_handle *handle,
+ unsigned int acpm_chan_id, u8 tz);
+ int (*suspend)(struct acpm_handle *handle, unsigned int acpm_chan_id);
+ int (*resume)(struct acpm_handle *handle, unsigned int acpm_chan_id);
+};
+
struct acpm_ops {
struct acpm_dvfs_ops dvfs;
struct acpm_pmic_ops pmic;
+ struct acpm_tmu_ops tmu;
};
/**
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v2 6/6] firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper
From: Tudor Ambarus @ 2026-05-15 9:32 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Michael Turquette,
Stephen Boyd, Lee Jones
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, andre.draszik, jyescas, kernel-team
In-Reply-To: <20260515-acpm-tmu-helpers-v2-0-8ca011d5a965@linaro.org>
Introduce devm_acpm_get_by_phandle() to standardize how consumer
drivers acquire a handle to the ACPM IPC interface. Enforce the
use of the "samsung,acpm-ipc" property name across the SoC and
simplify the boilerplate code in client drivers.
The first consumer of this helper is the Exynos ACPM Thermal Management
Unit (TMU) driver. The TMU utilizes a hybrid management approach: direct
register access from the Application Processor (AP) is restricted to the
interrupt pending (INTPEND) registers for event identification.
High-level functional tasks, such as sensor initialization, threshold
programming, and temperature reads, are delegated to the ACPM firmware
via this IPC interface.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
---
drivers/firmware/samsung/exynos-acpm.c | 23 ++++++++++++++++++++++
.../linux/firmware/samsung/exynos-acpm-protocol.h | 6 ++++++
2 files changed, 29 insertions(+)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index 2cebc5456968..a663e15fbad6 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -857,6 +857,29 @@ struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
}
EXPORT_SYMBOL_GPL(devm_acpm_get_by_node);
+/**
+ * devm_acpm_get_by_phandle - Resource managed lookup of the standardized
+ * "samsung,acpm-ipc" handle.
+ * @dev: consumer device
+ *
+ * Return: pointer to handle on success, ERR_PTR(-errno) otherwise.
+ */
+struct acpm_handle *devm_acpm_get_by_phandle(struct device *dev)
+{
+ struct acpm_handle *handle;
+ struct device_node *np;
+
+ np = of_parse_phandle(dev->of_node, "samsung,acpm-ipc", 0);
+ if (!np)
+ return ERR_PTR(-ENODEV);
+
+ handle = devm_acpm_get_by_node(dev, np);
+ of_node_put(np);
+
+ return handle;
+}
+EXPORT_SYMBOL_GPL(devm_acpm_get_by_phandle);
+
static const struct acpm_match_data acpm_gs101 = {
.initdata_base = ACPM_GS101_INITDATA_BASE,
.acpm_clk_dev_name = "gs101-acpm-clk",
diff --git a/include/linux/firmware/samsung/exynos-acpm-protocol.h b/include/linux/firmware/samsung/exynos-acpm-protocol.h
index 08d9f5c95701..83cbd425b652 100644
--- a/include/linux/firmware/samsung/exynos-acpm-protocol.h
+++ b/include/linux/firmware/samsung/exynos-acpm-protocol.h
@@ -71,6 +71,7 @@ struct device;
#if IS_ENABLED(CONFIG_EXYNOS_ACPM_PROTOCOL)
struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
struct device_node *np);
+struct acpm_handle *devm_acpm_get_by_phandle(struct device *dev);
#else
static inline struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
@@ -78,6 +79,11 @@ static inline struct acpm_handle *devm_acpm_get_by_node(struct device *dev,
{
return ERR_PTR(-ENODEV);
}
+
+static inline struct acpm_handle *devm_acpm_get_by_phandle(struct device *dev)
+{
+ return ERR_PTR(-ENODEV);
+}
#endif
#endif /* __EXYNOS_ACPM_PROTOCOL_H */
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v2 4/6] firmware: samsung: acpm: Make acpm_ops const and access via pointer
From: Tudor Ambarus @ 2026-05-15 9:32 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Michael Turquette,
Stephen Boyd, Lee Jones
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, andre.draszik, jyescas, kernel-team
In-Reply-To: <20260515-acpm-tmu-helpers-v2-0-8ca011d5a965@linaro.org>
Replace the embedded `struct acpm_ops` inside `struct acpm_handle` with
a pointer to a `const struct acpm_ops`.
Previously, the operations structure was embedded directly within the
handle and populated dynamically at runtime via `acpm_setup_ops()`.
This resulted in mutable function pointers and unnecessary per-instance
memory overhead.
By defining `exynos_acpm_driver_ops` statically as a `const` structure,
the function pointers are now safely housed in the read-only `.rodata`
section. This improves security by preventing function pointer
overwrites, saves memory, and slightly reduces initialization overhead
in `acpm_probe()`.
Consequently, update all consumer drivers (clk, mfd) to access the
operations via the new pointer indirection (`->ops->`). Finally, fix
the previously empty kernel-doc description for the ops member to
reflect its new pointer nature.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
---
drivers/clk/samsung/clk-acpm.c | 8 ++---
drivers/firmware/samsung/exynos-acpm.c | 36 ++++++++++------------
drivers/mfd/sec-acpm.c | 6 ++--
.../linux/firmware/samsung/exynos-acpm-protocol.h | 4 +--
4 files changed, 25 insertions(+), 29 deletions(-)
diff --git a/drivers/clk/samsung/clk-acpm.c b/drivers/clk/samsung/clk-acpm.c
index 93667777094c..953ca8d5720a 100644
--- a/drivers/clk/samsung/clk-acpm.c
+++ b/drivers/clk/samsung/clk-acpm.c
@@ -68,8 +68,8 @@ static unsigned long acpm_clk_recalc_rate(struct clk_hw *hw,
{
struct acpm_clk *clk = to_acpm_clk(hw);
- return clk->handle->ops.dvfs.get_rate(clk->handle, clk->mbox_chan_id,
- clk->id);
+ return clk->handle->ops->dvfs.get_rate(clk->handle, clk->mbox_chan_id,
+ clk->id);
}
static int acpm_clk_determine_rate(struct clk_hw *hw,
@@ -89,8 +89,8 @@ static int acpm_clk_set_rate(struct clk_hw *hw, unsigned long rate,
{
struct acpm_clk *clk = to_acpm_clk(hw);
- return clk->handle->ops.dvfs.set_rate(clk->handle, clk->mbox_chan_id,
- clk->id, rate);
+ return clk->handle->ops->dvfs.set_rate(clk->handle, clk->mbox_chan_id,
+ clk->id, rate);
}
static const struct clk_ops acpm_clk_ops = {
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index da960d3e1145..1a0d98b55439 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -670,30 +670,26 @@ static int acpm_channels_init(struct acpm_info *acpm)
return 0;
}
-/**
- * acpm_setup_ops() - setup the operations structures.
- * @acpm: pointer to the driver data.
- */
-static void acpm_setup_ops(struct acpm_info *acpm)
-{
- struct acpm_dvfs_ops *dvfs_ops = &acpm->handle.ops.dvfs;
- struct acpm_pmic_ops *pmic_ops = &acpm->handle.ops.pmic;
-
- dvfs_ops->set_rate = acpm_dvfs_set_rate;
- dvfs_ops->get_rate = acpm_dvfs_get_rate;
-
- pmic_ops->read_reg = acpm_pmic_read_reg;
- pmic_ops->bulk_read = acpm_pmic_bulk_read;
- pmic_ops->write_reg = acpm_pmic_write_reg;
- pmic_ops->bulk_write = acpm_pmic_bulk_write;
- pmic_ops->update_reg = acpm_pmic_update_reg;
-}
-
static void acpm_clk_pdev_unregister(void *data)
{
platform_device_unregister(data);
}
+static const struct acpm_ops exynos_acpm_driver_ops = {
+ .dvfs = {
+ .set_rate = acpm_dvfs_set_rate,
+ .get_rate = acpm_dvfs_get_rate,
+ },
+
+ .pmic = {
+ .read_reg = acpm_pmic_read_reg,
+ .bulk_read = acpm_pmic_bulk_read,
+ .write_reg = acpm_pmic_write_reg,
+ .bulk_write = acpm_pmic_bulk_write,
+ .update_reg = acpm_pmic_update_reg,
+ },
+};
+
static int acpm_probe(struct platform_device *pdev)
{
const struct acpm_match_data *match_data;
@@ -734,7 +730,7 @@ static int acpm_probe(struct platform_device *pdev)
if (ret)
return ret;
- acpm_setup_ops(acpm);
+ acpm->handle.ops = &exynos_acpm_driver_ops;
platform_set_drvdata(pdev, acpm);
diff --git a/drivers/mfd/sec-acpm.c b/drivers/mfd/sec-acpm.c
index 9e15b260b8df..3397d13d3b7f 100644
--- a/drivers/mfd/sec-acpm.c
+++ b/drivers/mfd/sec-acpm.c
@@ -391,7 +391,7 @@ static int sec_pmic_acpm_bus_write(void *context, const void *data,
{
struct sec_pmic_acpm_bus_context *ctx = context;
struct acpm_handle *acpm = ctx->shared->acpm;
- const struct acpm_pmic_ops *pmic_ops = &acpm->ops.pmic;
+ const struct acpm_pmic_ops *pmic_ops = &acpm->ops->pmic;
size_t val_count = count - BITS_TO_BYTES(ACPM_ADDR_BITS);
const u8 *d = data;
const u8 *vals = &d[BITS_TO_BYTES(ACPM_ADDR_BITS)];
@@ -411,7 +411,7 @@ static int sec_pmic_acpm_bus_read(void *context, const void *reg_buf, size_t reg
{
struct sec_pmic_acpm_bus_context *ctx = context;
struct acpm_handle *acpm = ctx->shared->acpm;
- const struct acpm_pmic_ops *pmic_ops = &acpm->ops.pmic;
+ const struct acpm_pmic_ops *pmic_ops = &acpm->ops->pmic;
const u8 *r = reg_buf;
u8 reg;
@@ -430,7 +430,7 @@ static int sec_pmic_acpm_bus_reg_update_bits(void *context, unsigned int reg, un
{
struct sec_pmic_acpm_bus_context *ctx = context;
struct acpm_handle *acpm = ctx->shared->acpm;
- const struct acpm_pmic_ops *pmic_ops = &acpm->ops.pmic;
+ const struct acpm_pmic_ops *pmic_ops = &acpm->ops->pmic;
return pmic_ops->update_reg(acpm, ctx->shared->acpm_chan_id, ctx->type, reg & 0xff,
ctx->shared->speedy_channel, val, mask);
diff --git a/include/linux/firmware/samsung/exynos-acpm-protocol.h b/include/linux/firmware/samsung/exynos-acpm-protocol.h
index b206efa62be6..fbf1829b33db 100644
--- a/include/linux/firmware/samsung/exynos-acpm-protocol.h
+++ b/include/linux/firmware/samsung/exynos-acpm-protocol.h
@@ -42,10 +42,10 @@ struct acpm_ops {
/**
* struct acpm_handle - Reference to an initialized protocol instance
- * @ops:
+ * @ops: pointer to the constant ACPM protocol operations.
*/
struct acpm_handle {
- struct acpm_ops ops;
+ const struct acpm_ops *ops;
};
struct device;
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v2 3/6] firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
From: Tudor Ambarus @ 2026-05-15 9:32 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Michael Turquette,
Stephen Boyd, Lee Jones
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, andre.draszik, jyescas, kernel-team
In-Reply-To: <20260515-acpm-tmu-helpers-v2-0-8ca011d5a965@linaro.org>
Rename the `dvfs_ops` and `pmic_ops` members of `struct acpm_ops` to
`dvfs` and `pmic` respectively.
Since these members are housed within the `acpm_ops` structure and
utilize the `acpm_*_ops` types, the `_ops` suffix on the variable names
creates unnecessary redundancy (e.g., `handle.ops.dvfs_ops`).
This cleanup removes the stuttering, leading to cleaner consumer code.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
Acked-by: Lee Jones <lee@kernel.org>
---
drivers/clk/samsung/clk-acpm.c | 8 ++++----
drivers/firmware/samsung/exynos-acpm.c | 4 ++--
drivers/mfd/sec-acpm.c | 6 +++---
include/linux/firmware/samsung/exynos-acpm-protocol.h | 4 ++--
4 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/samsung/clk-acpm.c b/drivers/clk/samsung/clk-acpm.c
index d8944160793a..93667777094c 100644
--- a/drivers/clk/samsung/clk-acpm.c
+++ b/drivers/clk/samsung/clk-acpm.c
@@ -68,8 +68,8 @@ static unsigned long acpm_clk_recalc_rate(struct clk_hw *hw,
{
struct acpm_clk *clk = to_acpm_clk(hw);
- return clk->handle->ops.dvfs_ops.get_rate(clk->handle,
- clk->mbox_chan_id, clk->id);
+ return clk->handle->ops.dvfs.get_rate(clk->handle, clk->mbox_chan_id,
+ clk->id);
}
static int acpm_clk_determine_rate(struct clk_hw *hw,
@@ -89,8 +89,8 @@ static int acpm_clk_set_rate(struct clk_hw *hw, unsigned long rate,
{
struct acpm_clk *clk = to_acpm_clk(hw);
- return clk->handle->ops.dvfs_ops.set_rate(clk->handle,
- clk->mbox_chan_id, clk->id, rate);
+ return clk->handle->ops.dvfs.set_rate(clk->handle, clk->mbox_chan_id,
+ clk->id, rate);
}
static const struct clk_ops acpm_clk_ops = {
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index fac88c427d2a..da960d3e1145 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -676,8 +676,8 @@ static int acpm_channels_init(struct acpm_info *acpm)
*/
static void acpm_setup_ops(struct acpm_info *acpm)
{
- struct acpm_dvfs_ops *dvfs_ops = &acpm->handle.ops.dvfs_ops;
- struct acpm_pmic_ops *pmic_ops = &acpm->handle.ops.pmic_ops;
+ struct acpm_dvfs_ops *dvfs_ops = &acpm->handle.ops.dvfs;
+ struct acpm_pmic_ops *pmic_ops = &acpm->handle.ops.pmic;
dvfs_ops->set_rate = acpm_dvfs_set_rate;
dvfs_ops->get_rate = acpm_dvfs_get_rate;
diff --git a/drivers/mfd/sec-acpm.c b/drivers/mfd/sec-acpm.c
index 0e23b9d9f7ee..9e15b260b8df 100644
--- a/drivers/mfd/sec-acpm.c
+++ b/drivers/mfd/sec-acpm.c
@@ -391,7 +391,7 @@ static int sec_pmic_acpm_bus_write(void *context, const void *data,
{
struct sec_pmic_acpm_bus_context *ctx = context;
struct acpm_handle *acpm = ctx->shared->acpm;
- const struct acpm_pmic_ops *pmic_ops = &acpm->ops.pmic_ops;
+ const struct acpm_pmic_ops *pmic_ops = &acpm->ops.pmic;
size_t val_count = count - BITS_TO_BYTES(ACPM_ADDR_BITS);
const u8 *d = data;
const u8 *vals = &d[BITS_TO_BYTES(ACPM_ADDR_BITS)];
@@ -411,7 +411,7 @@ static int sec_pmic_acpm_bus_read(void *context, const void *reg_buf, size_t reg
{
struct sec_pmic_acpm_bus_context *ctx = context;
struct acpm_handle *acpm = ctx->shared->acpm;
- const struct acpm_pmic_ops *pmic_ops = &acpm->ops.pmic_ops;
+ const struct acpm_pmic_ops *pmic_ops = &acpm->ops.pmic;
const u8 *r = reg_buf;
u8 reg;
@@ -430,7 +430,7 @@ static int sec_pmic_acpm_bus_reg_update_bits(void *context, unsigned int reg, un
{
struct sec_pmic_acpm_bus_context *ctx = context;
struct acpm_handle *acpm = ctx->shared->acpm;
- const struct acpm_pmic_ops *pmic_ops = &acpm->ops.pmic_ops;
+ const struct acpm_pmic_ops *pmic_ops = &acpm->ops.pmic;
return pmic_ops->update_reg(acpm, ctx->shared->acpm_chan_id, ctx->type, reg & 0xff,
ctx->shared->speedy_channel, val, mask);
diff --git a/include/linux/firmware/samsung/exynos-acpm-protocol.h b/include/linux/firmware/samsung/exynos-acpm-protocol.h
index d4db2796a6fb..b206efa62be6 100644
--- a/include/linux/firmware/samsung/exynos-acpm-protocol.h
+++ b/include/linux/firmware/samsung/exynos-acpm-protocol.h
@@ -36,8 +36,8 @@ struct acpm_pmic_ops {
};
struct acpm_ops {
- struct acpm_dvfs_ops dvfs_ops;
- struct acpm_pmic_ops pmic_ops;
+ struct acpm_dvfs_ops dvfs;
+ struct acpm_pmic_ops pmic;
};
/**
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v2 2/6] firmware: samsung: acpm: Annotate rx_data->cmd with __counted_by_ptr
From: Tudor Ambarus @ 2026-05-15 9:32 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Michael Turquette,
Stephen Boyd, Lee Jones
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, andre.draszik, jyescas, kernel-team
In-Reply-To: <20260515-acpm-tmu-helpers-v2-0-8ca011d5a965@linaro.org>
Rename the `n_cmd` member of `struct acpm_rx_data` to `cmdcnt` to
maintain consistent nomenclature across the driver (aligning with
`txcnt`, `rxcnt`, and transfer helpers).
With the member renamed, annotate the dynamically allocated `cmd`
pointer with the `__counted_by_ptr(cmdcnt)` macro to improve runtime
bounds checking.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
---
drivers/firmware/samsung/exynos-acpm.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index 88a06842753d..fac88c427d2a 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -105,14 +105,14 @@ struct acpm_queue {
* struct acpm_rx_data - RX queue data.
*
* @cmd: pointer to where the data shall be saved.
- * @n_cmd: number of 32-bit commands.
+ * @cmdcnt: allocated capacity of the @cmd buffer in 32-bit words.
* @rxcnt: expected length of the response in 32-bit words.
* @completed: flag indicating if the firmware response has been fully
* processed.
*/
struct acpm_rx_data {
- u32 *cmd;
- size_t n_cmd;
+ u32 *cmd __counted_by_ptr(cmdcnt);
+ size_t cmdcnt;
size_t rxcnt;
bool completed;
};
@@ -432,7 +432,7 @@ static int acpm_prepare_xfer(struct acpm_chan *achan,
/* Clear data for upcoming responses */
rx_data = &achan->rx_data[bit];
rx_data->completed = false;
- memset(rx_data->cmd, 0, sizeof(*rx_data->cmd) * rx_data->n_cmd);
+ memset(rx_data->cmd, 0, sizeof(*rx_data->cmd) * rx_data->cmdcnt);
/* zero means no response expected */
rx_data->rxcnt = xfer->rxcnt;
@@ -584,19 +584,19 @@ static int acpm_achan_alloc_cmds(struct acpm_chan *achan)
{
struct device *dev = achan->acpm->dev;
struct acpm_rx_data *rx_data;
- size_t cmd_size, n_cmd;
+ size_t cmd_size, cmdcnt;
int i;
if (achan->mlen == 0)
return 0;
cmd_size = sizeof(*(achan->rx_data[0].cmd));
- n_cmd = DIV_ROUND_UP_ULL(achan->mlen, cmd_size);
+ cmdcnt = DIV_ROUND_UP_ULL(achan->mlen, cmd_size);
for (i = 0; i < ACPM_SEQNUM_MAX; i++) {
rx_data = &achan->rx_data[i];
- rx_data->n_cmd = n_cmd;
- rx_data->cmd = devm_kcalloc(dev, n_cmd, cmd_size, GFP_KERNEL);
+ rx_data->cmdcnt = cmdcnt;
+ rx_data->cmd = devm_kcalloc(dev, cmdcnt, cmd_size, GFP_KERNEL);
if (!rx_data->cmd)
return -ENOMEM;
}
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v2 1/6] firmware: samsung: acpm: Consolidate transfer initialization helper
From: Tudor Ambarus @ 2026-05-15 9:32 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Michael Turquette,
Stephen Boyd, Lee Jones
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, andre.draszik, jyescas, kernel-team
In-Reply-To: <20260515-acpm-tmu-helpers-v2-0-8ca011d5a965@linaro.org>
Both the DVFS and PMIC ACPM sub-drivers implement similar local helper
functions (acpm_dvfs_set_xfer and acpm_pmic_set_xfer) to initialize the
acpm_xfer structure before sending an IPC message.
Move this logic into a single centralized helper, acpm_set_xfer(),
in the core ACPM driver to reduce boilerplate, eliminate code
duplication, and prepare for the upcoming ACPM TMU helper sub-driver
which will also utilize this method.
Note that there is no change in underlying functionality. While the old
acpm_pmic_set_xfer() unconditionally assigned the RX buffer parameters
(xfer->rxd and xfer->rxcnt), the new unified helper introduces a
'response' boolean. All updated PMIC call sites now explicitly pass
'true' for this argument. This ensures the unified helper takes the
'if (response)' branch, performing the exact same assignments and
preserving the original PMIC behavior.
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Reviewed-by: Peter Griffin <peter.griffin@linaro.org>
---
drivers/firmware/samsung/exynos-acpm-dvfs.c | 20 ++------------------
drivers/firmware/samsung/exynos-acpm-pmic.c | 20 +++++---------------
drivers/firmware/samsung/exynos-acpm.c | 26 ++++++++++++++++++++++++++
drivers/firmware/samsung/exynos-acpm.h | 2 ++
4 files changed, 35 insertions(+), 33 deletions(-)
diff --git a/drivers/firmware/samsung/exynos-acpm-dvfs.c b/drivers/firmware/samsung/exynos-acpm-dvfs.c
index fdea7aa24ca0..7266312ef5a6 100644
--- a/drivers/firmware/samsung/exynos-acpm-dvfs.c
+++ b/drivers/firmware/samsung/exynos-acpm-dvfs.c
@@ -21,22 +21,6 @@
#define ACPM_DVFS_FREQ_REQ 0
#define ACPM_DVFS_FREQ_GET 1
-static void acpm_dvfs_set_xfer(struct acpm_xfer *xfer, u32 *cmd, size_t cmdlen,
- unsigned int acpm_chan_id, bool response)
-{
- xfer->acpm_chan_id = acpm_chan_id;
- xfer->txcnt = cmdlen;
- xfer->txd = cmd;
-
- if (response) {
- xfer->rxcnt = cmdlen;
- xfer->rxd = cmd;
- } else {
- xfer->rxcnt = 0;
- xfer->rxd = NULL;
- }
-}
-
static void acpm_dvfs_init_set_rate_cmd(u32 cmd[4], unsigned int clk_id,
unsigned long rate)
{
@@ -54,7 +38,7 @@ int acpm_dvfs_set_rate(struct acpm_handle *handle,
u32 cmd[4];
acpm_dvfs_init_set_rate_cmd(cmd, clk_id, rate);
- acpm_dvfs_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, false);
+ acpm_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, false);
return acpm_do_xfer(handle, &xfer);
}
@@ -74,7 +58,7 @@ unsigned long acpm_dvfs_get_rate(struct acpm_handle *handle,
int ret;
acpm_dvfs_init_get_rate_cmd(cmd, clk_id);
- acpm_dvfs_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, true);
+ acpm_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, true);
ret = acpm_do_xfer(handle, &xfer);
if (ret)
diff --git a/drivers/firmware/samsung/exynos-acpm-pmic.c b/drivers/firmware/samsung/exynos-acpm-pmic.c
index 0c50993cc9a8..f032f2c69685 100644
--- a/drivers/firmware/samsung/exynos-acpm-pmic.c
+++ b/drivers/firmware/samsung/exynos-acpm-pmic.c
@@ -58,16 +58,6 @@ static inline u32 acpm_pmic_get_bulk(u32 data, unsigned int i)
return (data >> (ACPM_PMIC_BULK_SHIFT * i)) & ACPM_PMIC_BULK_MASK;
}
-static void acpm_pmic_set_xfer(struct acpm_xfer *xfer, u32 *cmd, size_t cmdlen,
- unsigned int acpm_chan_id)
-{
- xfer->txd = cmd;
- xfer->rxd = cmd;
- xfer->txcnt = cmdlen;
- xfer->rxcnt = cmdlen;
- xfer->acpm_chan_id = acpm_chan_id;
-}
-
static void acpm_pmic_init_read_cmd(u32 cmd[4], u8 type, u8 reg, u8 chan)
{
cmd[0] = FIELD_PREP(ACPM_PMIC_TYPE, type) |
@@ -86,7 +76,7 @@ int acpm_pmic_read_reg(struct acpm_handle *handle,
int ret;
acpm_pmic_init_read_cmd(cmd, type, reg, chan);
- acpm_pmic_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id);
+ acpm_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, true);
ret = acpm_do_xfer(handle, &xfer);
if (ret)
@@ -119,7 +109,7 @@ int acpm_pmic_bulk_read(struct acpm_handle *handle,
return -EINVAL;
acpm_pmic_init_bulk_read_cmd(cmd, type, reg, chan, count);
- acpm_pmic_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id);
+ acpm_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, true);
ret = acpm_do_xfer(handle, &xfer);
if (ret)
@@ -159,7 +149,7 @@ int acpm_pmic_write_reg(struct acpm_handle *handle,
int ret;
acpm_pmic_init_write_cmd(cmd, type, reg, chan, value);
- acpm_pmic_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id);
+ acpm_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, true);
ret = acpm_do_xfer(handle, &xfer);
if (ret)
@@ -199,7 +189,7 @@ int acpm_pmic_bulk_write(struct acpm_handle *handle,
return -EINVAL;
acpm_pmic_init_bulk_write_cmd(cmd, type, reg, chan, count, buf);
- acpm_pmic_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id);
+ acpm_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, true);
ret = acpm_do_xfer(handle, &xfer);
if (ret)
@@ -229,7 +219,7 @@ int acpm_pmic_update_reg(struct acpm_handle *handle,
int ret;
acpm_pmic_init_update_cmd(cmd, type, reg, chan, value, mask);
- acpm_pmic_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id);
+ acpm_set_xfer(&xfer, cmd, ARRAY_SIZE(cmd), acpm_chan_id, true);
ret = acpm_do_xfer(handle, &xfer);
if (ret)
diff --git a/drivers/firmware/samsung/exynos-acpm.c b/drivers/firmware/samsung/exynos-acpm.c
index a2cac913b2bd..88a06842753d 100644
--- a/drivers/firmware/samsung/exynos-acpm.c
+++ b/drivers/firmware/samsung/exynos-acpm.c
@@ -517,6 +517,32 @@ int acpm_do_xfer(struct acpm_handle *handle, const struct acpm_xfer *xfer)
return acpm_wait_for_message_response(achan, xfer);
}
+/**
+ * acpm_set_xfer() - initialize an ACPM IPC transfer structure.
+ * @xfer: pointer to the ACPM transfer structure that is being initialized.
+ * @cmd: pointer to the buffer containing the command to be transmitted
+ * to the ACPM firmware.
+ * @cmdcnt: length of the command in 32-bit words.
+ * @acpm_chan_id: mailbox channel identifier.
+ * @response: boolean flag indicating whether the kernel expects the ACPM
+ * firmware to send a reply to this specific command.
+ */
+void acpm_set_xfer(struct acpm_xfer *xfer, u32 *cmd, size_t cmdcnt,
+ unsigned int acpm_chan_id, bool response)
+{
+ xfer->acpm_chan_id = acpm_chan_id;
+ xfer->txcnt = cmdcnt;
+ xfer->txd = cmd;
+
+ if (response) {
+ xfer->rxcnt = cmdcnt;
+ xfer->rxd = cmd;
+ } else {
+ xfer->rxcnt = 0;
+ xfer->rxd = NULL;
+ }
+}
+
/**
* acpm_chan_shmem_get_params() - get channel parameters and addresses of the
* TX/RX queues.
diff --git a/drivers/firmware/samsung/exynos-acpm.h b/drivers/firmware/samsung/exynos-acpm.h
index 5df8354dc96c..708f6b0102ac 100644
--- a/drivers/firmware/samsung/exynos-acpm.h
+++ b/drivers/firmware/samsung/exynos-acpm.h
@@ -17,6 +17,8 @@ struct acpm_xfer {
struct acpm_handle;
+void acpm_set_xfer(struct acpm_xfer *xfer, u32 *cmd, size_t cmdcnt,
+ unsigned int acpm_chan_id, bool response);
int acpm_do_xfer(struct acpm_handle *handle,
const struct acpm_xfer *xfer);
--
2.54.0.563.g4f69b47b94-goog
^ permalink raw reply related
* [PATCH v2 0/6] firmware: samsung: acpm: TMU support and cleanups
From: Tudor Ambarus @ 2026-05-15 9:32 UTC (permalink / raw)
To: Tudor Ambarus, Krzysztof Kozlowski, Michael Turquette,
Stephen Boyd, Lee Jones
Cc: Alim Akhtar, Sylwester Nawrocki, Chanwoo Choi, André Draszik,
linux-kernel, linux-samsung-soc, linux-arm-kernel, linux-clk,
peter.griffin, andre.draszik, jyescas, kernel-team,
Krzysztof Kozlowski
Hi all,
This series introduces protocol support for the Exynos
Thermal Management Unit (TMU) to the ACPM driver, alongside several
cleanups.
Dependencies
============
Krzysztof, these patches together with the acpm fixes from your `fixes`
branch will be needed by the thermal maintainers. I'm going to send the
ACPM TMU (thermal) driver for review. In case they'll take it for the
next release, we'll need an immutable tag with the acpm fixes, cleanup
and thermal helpers. Thanks!
Other notes
===========
The MFD and clk maintainers are included because of the cleanup patches
(3 and 4). ACPM updated some structures that the mfd and clk client
drivers are using, so these patches shall naturally go via the Samsung
SoC tree.
Note that when compiling with W=1 one will see the following kdoc
false-positive warning:
CC [M] drivers/firmware/samsung/exynos-acpm.o
Warning: drivers/firmware/samsung/exynos-acpm.c:118 struct member '__counted_by_ptr(cmdcnt' not described in 'acpm_rx_data'
Warning: linux/drivers/firmware/samsung/exynos-acpm.c:118 struct member '__counted_by_ptr(cmdcnt' not described in 'acpm_rx_data'
I proposed the following patch to fix it:
Link: https://lore.kernel.org/all/20260506-kdoc-__counted_by_ptr-v1-1-70763486871f@linaro.org/
Cheers,
ta
---
Changes in v2:
- collect tags
- resend as sashiko couldn't apply previous version. We want
sashiko's review feedback
- Link to v1: https://lore.kernel.org/r/20260506-acpm-tmu-helpers-v1-0-a9cd5daf8355@linaro.org
Changes since 20260113-acpm-tmu-27e21f0e2c3b:v4:
- reword commit message of first patch emphasizing there's no
functional change (Krzysztof)
- remove static keyword from `static void acpm_set_xfer`
- replace for loop with memcpy in acpm_tmu_set_threshold()
- update kernel doc on devm_acpm_get_by_phandle()
Signed-off-by: Tudor Ambarus <tudor.ambarus@linaro.org>
---
Tudor Ambarus (6):
firmware: samsung: acpm: Consolidate transfer initialization helper
firmware: samsung: acpm: Annotate rx_data->cmd with __counted_by_ptr
firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
firmware: samsung: acpm: Make acpm_ops const and access via pointer
firmware: samsung: acpm: Add TMU protocol support
firmware: samsung: acpm: Add devm_acpm_get_by_phandle helper
drivers/clk/samsung/clk-acpm.c | 8 +-
drivers/firmware/samsung/Makefile | 1 +
drivers/firmware/samsung/exynos-acpm-dvfs.c | 20 +-
drivers/firmware/samsung/exynos-acpm-pmic.c | 20 +-
drivers/firmware/samsung/exynos-acpm-tmu.c | 239 +++++++++++++++++++++
drivers/firmware/samsung/exynos-acpm-tmu.h | 28 +++
drivers/firmware/samsung/exynos-acpm.c | 113 +++++++---
drivers/firmware/samsung/exynos-acpm.h | 2 +
drivers/mfd/sec-acpm.c | 6 +-
.../linux/firmware/samsung/exynos-acpm-protocol.h | 32 ++-
10 files changed, 397 insertions(+), 72 deletions(-)
---
base-commit: 5e9b7d093f3f77cb0af4409559e3d139babfb443
change-id: 20260505-acpm-tmu-helpers-4c5af0e2f07c
prerequisite-change-id: 20260423-acpm-fixes-sashiko-reports-ae28b6ed5581:v5
prerequisite-patch-id: 18d89d0e2bc0efe2cb366746ac4db36f4682f061
prerequisite-patch-id: e877f865862ee94f5750b877b5fad863d8acd7c8
prerequisite-patch-id: b5da16b5c6d6731ea519ed68302fd52ce57c7ffa
prerequisite-patch-id: df5b1d9df4c8894afaff645c9eb84aa4e3daeeee
prerequisite-patch-id: be74a55583acb36dedca3e118f49633172979617
prerequisite-patch-id: 31ebc7bd806d4d466c256049f32e3270e2caeeb6
prerequisite-patch-id: 7ea0832fcf76e4f40e18b74083904e7e37e1addf
Best regards,
--
Tudor Ambarus <tudor.ambarus@linaro.org>
^ permalink raw reply
* Re: [PATCH tty v4 2/6] serial: Replace driver usage of UPF_CONS_FLOW
From: Tudor Ambarus @ 2026-05-15 9:29 UTC (permalink / raw)
To: Krzysztof Kozlowski, John Ogness, Greg Kroah-Hartman, Jiri Slaby,
Alim Akhtar
Cc: Andy Shevchenko, linux-kernel, David S. Miller,
Ilpo Järvinen, Andy Shevchenko, Thomas Fourier, Kees Cook,
linux-serial, linux-arm-kernel, linux-samsung-soc, sparclinux,
Peter Griffin, André Draszik, Alexey Klimov
In-Reply-To: <1a5abd2e-e9ab-4a48-94c2-5e082f57adde@kernel.org>
On 5/13/26 10:50 PM, Krzysztof Kozlowski wrote:
> Cc-ing also a few Linaro folks
> which are using this platform and might be able to help us here.
I think that will be me as I worked with the serial.
I'm a little bit busy right now, but I'm adding this to my todo
list in case no else is taking care about it before I get to it.
Cheers,
ta
^ permalink raw reply
* Re: [PATCH v5 00/21] drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup
From: Diederik de Haas @ 2026-05-15 9:27 UTC (permalink / raw)
To: Jonas Karlman, Andrzej Hajda, Neil Armstrong, Robert Foss,
Heiko Stuebner
Cc: Laurent Pinchart, Jernej Skrabec, Luca Ceresoli, Liu Ying,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sandy Huang, Andy Yan, Chen-Yu Tsai,
Christian Hewitt, Diederik de Haas, Nicolas Frattaroli,
Dmitry Baryshkov, dri-devel, linux-arm-kernel, linux-rockchip,
linux-amlogic, linux-sunxi, imx, linux-kernel
In-Reply-To: <20260510124111.1226584-1-jonas@kwiboo.se>
Hi Jonas,
On Sun May 10, 2026 at 2:42 PM CEST, Jonas Karlman wrote:
> This is a revival of an old dw-hdmi series and is the first series part
> of a new effort to upstream old LibreELEC HDMI 2.0 patches for Rockchip
> RK33xx devices.
>
> This series ensure poweron/poweroff and CEC phys addr invalidation is
> happening under drm mode_config mutex lock, and also ensure EDID is
> updated after a HPD low voltage pulse by changing to debounce hotplug
> processing.
>
> These changes have mainly been tested on Rockchip RK3328, RK3399 and
> RK3568 devices using both the dw-hdmi connector and also using a basic
> convert to use a bridge connector.
Yesterday I made a test run and the TL;DR is this:
Tested-by: Diederik de Haas <diederik@cknow-tech.com> # Rock64, RockPro64, Quartz64-B
The longer version ...
Test setup:
I have a 1080p monitor capable of HDMI 1.4 (I think) and a 4K TV capable of
HDMI 2.0 (but not 2.1). I'm running Debian Testing/Sid on them with Sway
1.12-rc3-1 (from Experimental) and see if that works (at all) and then I try to
play one or more of my 'test' videos with mpv and using v4l2request HW accel.
I used 2 kernels: 7.1-rc3 and 7.1-rc3 with this patch set.
One of the possible issues that may have been fixed with this patch set is
doing hotplugging of the HDMI connection, especially going from 4K to 1080p.
So when testing I unplugged my 4K cable and plugged in the 1080p cable and
looked if it has adjusted things properly. I also checked dmesg to see if
there were interesting msgs.
> Testing with a Rock Pi 4 (RK3399) using a Raspberry Pi Monitor with
> Linux kms client console using drm.debug=0xe should log something like
> following:
>
> Power cycle monitor using the power button:
> [CONNECTOR:68:HDMI-A-1] CEA VCDB 0x4a
> [CONNECTOR:68:HDMI-A-1] HDMI: DVI dual 0, max TMDS clock 0 kHz
> [CONNECTOR:68:HDMI-A-1] ELD monitor RPI MON156
> [CONNECTOR:68:HDMI-A-1] HDMI: latency present 0 0, video latency 0 0, audio latency 0 0
> [CONNECTOR:68:HDMI-A-1] ELD size 36, SAD count 1
> [CONNECTOR:68:HDMI-A-1] Same epoch counter 10
>
> Cable unplugged:
> [CONNECTOR:68:HDMI-A-1] EDID changed, epoch counter 11
> [CONNECTOR:68:HDMI-A-1] status updated from connected to disconnected
> [CONNECTOR:68:HDMI-A-1] Changed epoch counter 10 => 12
> [CONNECTOR:68:HDMI-A-1] generating connector hotplug event
> [CONNECTOR:68:HDMI-A-1] Sent hotplug event
When I was preparing my testing session the 'Sent hotplug event' caught my eye
as it seemed like a clear differentiator between the kernel with and without
this patch set.
Unfortunately during my 'real' testing session I did not see that message ...
> Cable connected:
> [CONNECTOR:68:HDMI-A-1] CEA VCDB 0x4a
> [CONNECTOR:68:HDMI-A-1] HDMI: DVI dual 0, max TMDS clock 0 kHz
> [CONNECTOR:68:HDMI-A-1] ELD monitor RPI MON156
> [CONNECTOR:68:HDMI-A-1] HDMI: latency present 0 0, video latency 0 0, audio latency 0 0
> [CONNECTOR:68:HDMI-A-1] ELD size 36, SAD count 1
> [CONNECTOR:68:HDMI-A-1] status updated from disconnected to connected
> [CONNECTOR:68:HDMI-A-1] Changed epoch counter 12 => 13
> [CONNECTOR:68:HDMI-A-1] generating connector hotplug event
> [CONNECTOR:68:HDMI-A-1] Sent hotplug event
... but I did see all the others. With my 4K TV I got
``max TMDS clock 300000 kHz``
but on my 1080p monitor I got 0 kHz just like quoted above.
I also checked CEC and EDID with the following commands:
- ``cat /sys/kernel/debug/cec/cec0/status``
- ``di-edid-decode /sys/devices/platform/display-subsystem/drm/card0/card0-HDMI-A-1/edid``
And in all cases they produced identical outputs.
Rock64 testing:
On the Rock64 I got a stack trace:
```sh
root@rock64-test:~# dmesg --level 4
[ 2.302852] dw-apb-uart ff130000.serial: forbid DMA for kernel console
[ 5.068434] dw_wdt ff1a0000.watchdog: No valid TOPs array specified
[ 5.841772] dwc2 ff580000.usb: supply vusb_d not found, using dummy regulator
[ 5.842752] dwc2 ff580000.usb: supply vusb_a not found, using dummy regulator
[ 7.392797] ------------[ cut here ]------------
[ 7.393236] WARNING: drivers/media/cec/core/cec-adap.c:1116 at cec_received_msg_ts+0x530/0xc10 [cec], CPU#0: irq/50-dw-hdmi-/186
[ 7.394811] Modules linked in: dw_hdmi_cec(+) hid_generic usbhid rockchipdrm hid dw_hdmi_qp dw_mipi_dsi realtek dw_hdmi phy_package analogix_dp drm_dp_aux_bus dwmac_rk drm_display_helper stmmac_platform xhci_plat_hcd stmmac cec rc_core xhci_hcd pcs_xpcs drm_client_lib phylink rtc_rk808 drm_dma_helper ohci_platform rk808_regulator mdio_devres dwc2 of_mdio drm_kms_helper ehci_platform dwc3 ehci_hcd fixed_phy udc_core ohci_hcd drm fwnode_mdio usbcore libphy syscon_reboot_mode ulpi gpio_rockchip phy_rockchip_inno_usb2 dw_mmc_rockchip reboot_mode io_domain gpio_syscon mdio_bus dw_mmc_pltfm fixed usb_common dw_wdt dw_mmc phy_rockchip_inno_hdmi spi_rockchip nvmem_rockchip_efuse i2c_rk3x pl330
[ 7.404613] CPU: 0 UID: 0 PID: 186 Comm: irq/50-dw-hdmi- Not tainted 7.1-rc3+unreleased-arm64-cknow #1 PREEMPTLAZY Debian 7.1~rc3-2
[ 7.406138] Hardware name: Pine64 Rock64 (DT)
[ 7.406725] pstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 7.407634] pc : cec_received_msg_ts+0x530/0xc10 [cec]
[ 7.408344] lr : dw_hdmi_cec_thread+0x98/0xb8 [dw_hdmi_cec]
[ 7.409095] sp : ffff8000809e3cc0
[ 7.409552] x29: ffff8000809e3d30 x28: 0000000000000000 x27: 0000000000000000
[ 7.410500] x26: ffff0000faae44ac x25: ffffa02b5edaf370 x24: ffff00000bd9f6a0
[ 7.411447] x23: ffffa02b60e3e000 x22: ffff0000faae4400 x21: 0000000000000001
[ 7.412392] x20: ffff0000faae4400 x19: ffff00000a887800 x18: ffff5fd59d9c7000
[ 7.413333] x17: 0000000061dcb992 x16: ffffa02b5edf4d88 x15: ffffa02b60e421d0
[ 7.414256] x14: ffffa02b60d5a100 x13: 00000000000000c0 x12: ffff0000fe721100
[ 7.415175] x11: 00000000000000c0 x10: 0000000000000db0 x9 : ffffa02af03675c8
[ 7.416095] x8 : ffff0000fa3f0e10 x7 : 0000000000000000 x6 : 0000000000000010
[ 7.417011] x5 : ffff5fd59d9c7000 x4 : ffff000000c7ccc0 x3 : ffff00000bd9f680
[ 7.417927] x2 : 00000001b8300c79 x1 : 00000000ffffffff x0 : 0000000000000000
[ 7.418845] Call trace:
[ 7.419174] cec_received_msg_ts+0x530/0xc10 [cec] (P)
[ 7.419855] dw_hdmi_cec_thread+0x98/0xb8 [dw_hdmi_cec]
[ 7.420536] irq_thread_fn+0x30/0xc0
[ 7.421021] irq_thread+0x19c/0x3e8
[ 7.421491] kthread+0x134/0x150
[ 7.421925] ret_from_fork+0x10/0x20
[ 7.422405] ---[ end trace 0000000000000000 ]---
[ 23.252709] rockchip-i2s ff000000.i2s: using zero-initialized flat cache, this may cause unexpected behavior
```
This was with the kernel *with* this patch set (and connected to 4K TV; no
idea if that's relevant though).
But I did not see any adverse affects from it and when I tried again today,
I did NOT get a/that stack trace.
The Rock64 was the device which showed most clearly the difference between
having this patch set applied or not.
As always, I started with the kernel without this patch set and booted it up
connected to my 4K TV. Then I logged into a Sway session via greetd (thus ~
also Sway) and everything looked fine*.
I then tried hotplugging the HDMI from my 4K TV to my 1080p monitor ... and I
did NOT get any output on my monitor. I didn't even see any message in dmesg
that it noticed that first a cable got unplugged and later another cable got
plugged. My monitor itself did notice when I then unplugged the cable again.
When I then plugged the 4K cable back in, my TV showed Sway like before and
AFAICT everything was working again.
When I booted into the kernel WITH this patch set, hotplugging back and forth
worked absolutely fine :-D The screen resolution got adjusted to the new one
and dmesg noticed the unplugging and plugging actions and it showed similar
messages as Jonas showed in his cover page (and quoted above).
With the exception of 'Sent hotplug event' as mentioned above.
*) There are pretty substantial artifacts which are AFAIUI due to the
not-exactly-fast GPU and memory, but that's unrelated to this patch set.
Playing a HW accelerated video full-screen often works pretty decently.
RockPro64 testing:
I can be much shorter about the RockPro64.
Everything seemed to work just fine with and without this patch set applied. So
no improvement, but also no regressions.
Quartz64-B testing:
Same story as with RockPro64: no improvements, but also no regressions.
I did notice that ``drm.debug=0xe`` was *quite* verbose on this device.
On Rock64 and RockPro64 I saw various drm related msgs in dmesg _when I
actually did something_ but on Q64-B I got several ~ identical lines per
second, whether I did sth or not. But that was with and without this patch
set, so I guess that's a general RK356X 'issue' (if at all an issue).
Cheers,
Diederik
> Jonas Karlman (21):
> drm: bridge: dw_hdmi: Disable scrambler feature when not supported
> drm: bridge: dw_hdmi: Only notify connected status on HPD interrupt
> drm: bridge: dw_hdmi: Call poweron/poweroff from atomic enable/disable
> drm: bridge: dw_hdmi: Use passed mode instead of stored previous_mode
> drm: bridge: dw_hdmi: Fold poweron and setup functions
> drm: bridge: dw_hdmi: Remove previous_mode and mode_set
> drm: bridge: dw_hdmi: Hold bridge ref until connector cleanup
> drm: bridge: dw_hdmi: Unregister CEC notifier during connector cleanup
> drm: bridge: dw_hdmi: Invalidate CEC phys addr from connector detect
> drm: bridge: dw_hdmi: Remove cec_notifier_mutex
> drm: bridge: dw_hdmi: Extract dw_hdmi_connector_status_update()
> drm: bridge: dw_hdmi: Use dw_hdmi_connector_status_update()
> drm: bridge: dw_hdmi: Use display_info is_hdmi and has_audio
> drm: bridge: dw_hdmi: Use generic CEC notifier helpers
> drm: bridge: dw_hdmi: Add common suspend helper
> drm: bridge: dw_hdmi: Use delayed_work to debounce hotplug event
> drm: bridge: dw_hdmi: Rework HDP and RXSENSE interrupt handling
> drm: bridge: dw_hdmi: Remove the empty dw_hdmi_setup_rx_sense()
> drm: bridge: dw_hdmi: Remove the empty dw_hdmi_phy_update_hpd()
> drm: bridge: dw_hdmi: Merge top and bottom half IRQ handlers
> drm: bridge: dw_hdmi: Drop call to drm_bridge_hpd_notify()
>
> drivers/gpu/drm/bridge/imx/imx8mp-hdmi-tx.c | 5 +-
> drivers/gpu/drm/bridge/synopsys/Kconfig | 1 +
> drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 483 +++++++-------------
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 5 +-
> drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +-
> drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 2 -
> include/drm/bridge/dw_hdmi.h | 7 +-
> 7 files changed, 194 insertions(+), 322 deletions(-)
^ permalink raw reply
* Re: [PATCH v2] iio: adc: sun20i-gpadc: support non-contiguous channel lookups
From: Andy Shevchenko @ 2026-05-15 9:26 UTC (permalink / raw)
To: Michal Piekos
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, linux-iio,
linux-arm-kernel, linux-sunxi, linux-kernel, Nathan Chancellor,
Nick Desaulniers, Bill Wendling, Justin Stitt, llvm
In-Reply-To: <20260514-fix-sunxi-gpadc-sparse-channels-v2-1-d4a66b70c7a7@mmpsystems.pl>
On Thu, May 14, 2026 at 05:19:34AM +0200, Michal Piekos wrote:
> Using consumer driver like iio-hwmon which resolve channels thorugh
> io-channels phandles will fail for sparse channels because IIO core by
> default threats phandle argument as index into channel array.
> eg. <&gpadc 1> will fail if there is only channel@1 specified
>
> Add .fwnode_xlate() which maps DT phandle to the registered channel
> whose chan->channel matches the hardware channel number. It allows
> sparse channel maps to be consumed by drivers like iio-hwmon.
>
> Tested on Radxa Cubie A5E.
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v3] i2c: davinci: fix division by zero on missing clock-frequency
From: Chaitanya Sabnis @ 2026-05-15 9:25 UTC (permalink / raw)
To: brgl, andi.shyti
Cc: linux-arm-kernel, linux-i2c, linux-kernel, Chaitanya Sabnis,
Sashiko
When the 'clock-frequency' property is missing from the device tree,
the driver falls back to DAVINCI_I2C_DEFAULT_BUS_FREQ. However, this
macro was defined in kHz (100), whereas the device tree property is
expected in Hz.
The probe function divided the fallback value by 1000, causing
integer truncation that resulted in dev->bus_freq = 0. This triggered
a deterministic division-by-zero kernel panic when calculating clock
dividers later in the probe sequence.
Fix this by redefining DAVINCI_I2C_DEFAULT_BUS_FREQ in Hz (100000)
to match the expected device tree property unit, allowing the existing
division logic to work correctly for both cases.
Fixes: b04ce6385979 ("i2c: davinci: kill platform data")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/all/20260514044726.57297C2BCB7@smtp.kernel.org/
Signed-off-by: Chaitanya Sabnis <chaitanya.msabnis@gmail.com>
---
drivers/i2c/busses/i2c-davinci.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-davinci.c b/drivers/i2c/busses/i2c-davinci.c
index a773ba082321..a264a480dc3c 100644
--- a/drivers/i2c/busses/i2c-davinci.c
+++ b/drivers/i2c/busses/i2c-davinci.c
@@ -117,7 +117,7 @@
/* timeout for pm runtime autosuspend */
#define DAVINCI_I2C_PM_TIMEOUT 1000 /* ms */
-#define DAVINCI_I2C_DEFAULT_BUS_FREQ 100
+#define DAVINCI_I2C_DEFAULT_BUS_FREQ 100000
struct davinci_i2c_dev {
struct device *dev;
@@ -761,9 +761,7 @@ static int davinci_i2c_probe(struct platform_device *pdev)
r = device_property_read_u32(&pdev->dev, "clock-frequency", &prop);
if (r)
prop = DAVINCI_I2C_DEFAULT_BUS_FREQ;
-
dev->bus_freq = prop / 1000;
-
dev->has_pfunc = device_property_present(&pdev->dev, "ti,has-pfunc");
dev->clk = devm_clk_get(&pdev->dev, NULL);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] firmware: arm_ffa: honor descriptor size in PARTITION_INFO_GET_REGS
From: Sudeep Holla @ 2026-05-15 9:23 UTC (permalink / raw)
To: Jamie Nguyen
Cc: linux-arm-kernel@lists.infradead.org, Sudeep Holla,
linux-kernel@vger.kernel.org
In-Reply-To: <5AF8DFBF-18EC-4C8A-84A0-F27298DB9BD0@nvidia.com>
On Thu, May 14, 2026 at 05:37:38PM +0000, Jamie Nguyen wrote:
>
>
> > On May 14, 2026, at 2:16 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> >
> > On Wed, May 13, 2026 at 07:48:05PM +0000, Jamie Nguyen wrote:
> >>
> >>
> >>> On May 13, 2026, at 10:15 AM, Sudeep Holla <sudeep.holla@kernel.org> wrote:
> >>>
> >>> On Tue, May 12, 2026 at 08:28:00PM -0700, Jamie Nguyen wrote:
> >>>> __ffa_partition_info_get_regs() walks the response with a hardcoded
> >>>> 24-byte stride (regs += 3) even though the SPMC tells us the actual
> >>>> per-descriptor size via PARTITION_INFO_SZ in x2[63:48]. The size is
> >>>> read into buf_sz and then thrown away.
> >>>>
> >>>> That works while every SPMC returns the FF-A v1.1 layout, but it falls
> >>>> apart against a v1.3 SPMC returning the 48-byte descriptor. The loop
> >>>> strides over half a descriptor at a time and ends up parsing every
> >>>> other entry from a slice of two adjacent ones.
> >>>>
> >>>> The FF-A spec (v1.2, section 18.5) says that the producer should
> >>>> report the descriptor size, and the consumer is supposed to stride by
> >>>> that size and ignore any trailing fields it doesn't understand. The
> >>>> non-REGS path (__ffa_partition_info_get) does this already, and the
> >>>> REGS path should match.
> >>>>
> >>>> Use buf_sz for the stride, and bail out with -EPROTO if the SPMC
> >>>> reports something we can't safely walk.
> >>>>
> >>>
> >>> Can you check if the issue is addressed in -next by:
> >>> Commit 3974ea193840 ("firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies")
> >>
> >> Thanks for the pointer. I tested 3974ea193840 on the same hardware
> >> that reproduces the bug, but the descriptor-stride issue is still
> >> present.
> >>
> >> The relevant loop at the end of __ffa_partition_info_get_regs()
> >> still has:
> >>
> >> buf_sz = PARTITION_INFO_SZ(partition_info.a2);
> >> if (buf_sz > sizeof(*buffer))
> >> buf_sz = sizeof(*buffer);
> >> ...
> >> for (idx = 0; idx < nr_desc; idx++, buf++) {
> >> ...
> >> regs += 3; /* bug is here */
> >> }
> >>
> >> With 48-byte descriptors the SPMC returns nr_desc = 2 per call,
> >
> > Well why is the firmware sending 48byte entry when 24byte is expected.
>
> We're starting to test with a v1.3 SPMC implementation. UEFI brings
> up its FF-A driver first and negotiates v1.3, which the SPMC then must
> keep for the lifetime of the primary VM per DEN0077A v1.2 REL0 section
> 13.2.2 [0]:
>
> "Once an FF-A version has been negotiated between a caller and a
> callee, the version may not be changed for the lifetime of the
> calling component.”
>
I need to check the v1.3-alpha specs to understand/recall the version
negotiations but until v1.2 and the current driver which is v1.2 we don't
have any idea about all these new changes. But since v1.2 already has size
of descriptor, we can and must handle that independently of this new
version (re-)negotiation.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH net-next v6 01/12] dt-bindings: net: airoha: Add EN7581 ethernet-ports properties
From: Lorenzo Bianconi @ 2026-05-15 9:12 UTC (permalink / raw)
To: Rob Herring
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Krzysztof Kozlowski, Conor Dooley, Christian Marangi,
Benjamin Larsson, linux-arm-kernel, linux-mediatek, netdev,
devicetree
In-Reply-To: <20260514140130.GA257001-robh@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3874 bytes --]
> On Mon, May 11, 2026 at 12:49:27PM +0200, Lorenzo Bianconi wrote:
> > EN7581 and AN7583 SoCs support connecting multiple external SerDes to GDM3
> > or GDM4 ports via a hw arbiter that manages the traffic in a TDM manner.
> > As a result multiple net_devices can connect to the same GDM{3,4} port
> > and there is a theoretical "1:n" relation between GDM ports and
> > net_devices.
> > Introduce the ethernet-port property in order to model a given net_device
> > that is connected via the external arbiter to the GDM{3,4} port (that
> > is represented by the ethernet property. Please note GDM1 or GDM2 does not
> > support the connection with the external arbiter and are represented
> > by ethernet property.
> >
> > Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> > ---
> > .../devicetree/bindings/net/airoha,en7581-eth.yaml | 64 +++++++++++++++++++++-
> > 1 file changed, 63 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > index fbe2ddcdd909..642f300c0945 100644
> > --- a/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > +++ b/Documentation/devicetree/bindings/net/airoha,en7581-eth.yaml
> > @@ -130,6 +130,50 @@ patternProperties:
> > maximum: 4
> > description: GMAC port identifier
> >
> > + '#address-cells':
> > + const: 1
>
> blank line
ack, I will fix it in v7.
>
> > + '#size-cells':
> > + const: 0
> > +
> > + allOf:
> > + - if:
> > + properties:
> > + reg:
> > + contains:
> > + items:
> > + - enum:
> > + - 3
> > + - 4
> > + then:
> > + properties:
> > + '#address-cells':
> > + const: 1
> > + '#size-cells':
> > + const: 0
>
> Why do you have these twice? Drop this one.
ack, I will fix it in v7.
>
> > +
> > + patternProperties:
> > + "^ethernet-port@[0-5]$":
> > + type: object
> > + unevaluatedProperties: false
> > + $ref: ethernet-controller.yaml#
> > + description: External ethernet port ID available on the GDM port
> > +
> > + properties:
> > + compatible:
> > + const: airoha,eth-port
> > +
> > + reg:
> > + maxItems: 1
>
> Instead, 'maximum: 5'.
ack, I will fix it in v7.
>
> > + description: External ethernet port identifier
> > +
> > + required:
> > + - reg
> > + - compatible
> > +
> > + required:
> > + - "#address-cells"
> > + - "#size-cells"
> > +
> > required:
> > - reg
> > - compatible
> > @@ -191,9 +235,27 @@ examples:
> > #address-cells = <1>;
> > #size-cells = <0>;
> >
> > - mac: ethernet@1 {
> > + mac1: ethernet@1 {
>
> Just drop unused labels.
ack, I will fix it in v7.
Regards,
Lorenzo
>
> > compatible = "airoha,eth-mac";
> > reg = <1>;
> > };
> > +
> > + mac4: ethernet@4 {
> > + compatible = "airoha,eth-mac";
> > + reg = <4>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + ethernet-port@0 {
> > + compatible = "airoha,eth-port";
> > + reg = <0>;
> > + };
> > +
> > + ethernet-port@1 {
> > + compatible = "airoha,eth-port";
> > + reg = <1>;
> > + };
> > + };
> > };
> > };
> >
> > --
> > 2.54.0
> >
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v6 08/13] coresight: etm4x: remove redundant call etm4_enable_hw() with hotplug
From: Leo Yan @ 2026-05-15 9:08 UTC (permalink / raw)
To: Yeoreum Yun
Cc: coresight, linux-arm-kernel, linux-kernel, suzuki.poulose,
mike.leach, james.clark, alexander.shishkin, jie.gan
In-Reply-To: <20260422132203.977549-9-yeoreum.yun@arm.com>
On Wed, Apr 22, 2026 at 02:21:58PM +0100, Yeoreum Yun wrote:
[...]
> + /*
> + * Take the hotplug lock to prevent redundant calls to etm4_enable_hw().
> + *
> + * The cpu_online_mask is set at the CPUHP_BRINGUP_CPU step.
> + * In other words, if etm4_enable_sysfs() is called between
> + * CPUHP_BRINGUP_CPU and CPUHP_AP_ARM_CORESIGHT_STARTING,
> + * etm4_enable_hw() may be invoked in etm4_enable_sysfs_smp_call()
> + * and then executed again in etm4_starting_cpu().
> + */
> + cpus_read_lock();
> ret = smp_call_function_single(drvdata->cpu,
> etm4_enable_sysfs_smp_call, &arg, 1);
> + cpus_read_unlock();
This will cause double deadlock with the patch:
https://lore.kernel.org/linux-arm-kernel/20260511-arm_coresight_path_power_management_improvement-v12-6-1c9dcb1de8c9@arm.com/#t
I think we need to drop this one.
Thanks,
Leo
^ permalink raw reply
* Re: [PATCH 2/2] drm/verisilicon: add support for Nuvoton MA35D1 DCUltra Lite display controller
From: Joey Lu @ 2026-05-15 9:08 UTC (permalink / raw)
To: Icenowy Zheng, maarten.lankhorst, mripard, tzimmermann, airlied,
simona, robh, krzk+dt, conor+dt
Cc: ychuang3, schung, yclu4, dri-devel, devicetree, linux-arm-kernel,
linux-kernel
In-Reply-To: <1c4d8611411e2d14699ac0b9aeb5b2377feedc8a.camel@iscas.ac.cn>
On 5/15/2026 4:38 PM, Icenowy Zheng wrote:
> 在 2026-05-15五的 14:25 +0800，Joey Lu写道：
>> On 5/12/2026 9:12 PM, Icenowy Zheng wrote:
>>> 在 2026-05-12二的 18:59 +0800，Joey Lu写道：
>>>> On 5/12/2026 6:01 PM, Icenowy Zheng wrote:
>>>>> 在 2026-05-12二的 17:06 +0800，Joey Lu写道：
>>>>>
>>>>> ======= 8< =============
>>>>>>>>>> diff --git a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>> b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>> index 7a93049368db..225af322de32 100644
>>>>>>>>>> --- a/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>> +++ b/drivers/gpu/drm/verisilicon/vs_bridge.c
>>>>>>>>>> @@ -164,13 +164,16 @@ static void
>>>>>>>>>> vs_bridge_enable_common(struct
>>>>>>>>>> vs_crtc *crtc,
>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_CLK_E
>>>>>>>>>> N);
>>>>>>>>>> regmap_set_bits(dc->regs,
>>>>>>>>>> VSDC_DISP_PANEL_CONFIG(output),
>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_RUNNI
>>>>>>>>>> NG);
>>>>>>>>>> - regmap_clear_bits(dc->regs,
>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>> -
>>>>>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>>>>>> - regmap_set_bits(dc->regs,
>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>> -
>>>>>>>>>> VSDC_DISP_PANEL_START_RUNNIN
>>>>>>>>>> G(ou
>>>>>>>>>> tput));
>>>>>>>>>>
>>>>>>>>>> - regmap_set_bits(dc->regs,
>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc-
>>>>>>>>>>> id),
>>>>>>>>>> -
>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX_CO
>>>>>>>>>> MMIT);
>>>>>>>>>> + if (dc->info->has_config_ex) {
>>>>>>>>>> + regmap_clear_bits(dc->regs,
>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>> +
>>>>>>>>>> VSDC_DISP_PANEL_START_MULTI_DISP_SYNC);
>>>>>>>>>> + regmap_set_bits(dc->regs,
>>>>>>>>>> VSDC_DISP_PANEL_START,
>>>>>>>>>> + VSDC_DISP_PANEL_STAR
>>>>>>>>>> T_RU
>>>>>>>>>> NNIN
>>>>>>>>>> G(ou
>>>>>>>>>> tput
>>>>>>>>>> ));
>>>>>>>>>> +
>>>>>>>>>> + regmap_set_bits(dc->regs,
>>>>>>>>>> VSDC_DISP_PANEL_CONFIG_EX(crtc->id),
>>>>>>>>>> + VSDC_DISP_PANEL_CONF
>>>>>>>>>> IG_E
>>>>>>>>>> X_CO
>>>>>>>>>> MMIT
>>>>>>>>>> );
>>>>>>>>> Should the commit operation happen on
>>>>>>>>> DC8000/DCUltraLite
>>>>>>>>> too?
>>>>>>>>> (By
>>>>>>>>> writing to DcregFrameBufferConfig0.VALID).
>>>>>>>>>
>>>>>>>>> Many registers written has "Note: This field is double
>>>>>>>>> buffered" in
>>>>>>>>> the
>>>>>>>>> DCUltraLite documentation.
>>>>>>>>>
>>>>>>>>> I suggest create a static function for commit -- write
>>>>>>>>> to
>>>>>>>>> the
>>>>>>>>> corresponding commit bit on DC8200, and write to
>>>>>>>>> DcregFrameBufferConfig0.VALID on DC8000/DCUltraLite.
>>>>>>>> [a] There is no commit operation for DCUltra Lite.
>>>>>>>> I'll not add a `VSDC_FB_CONFIG_VALID` macro. VALID
>>>>>>>> (BIT(3))
>>>>>>>> is a
>>>>>>>> hardware-managed double-buffer status bit: hardware
>>>>>>>> writes
>>>>>>>> 1=PENDING
>>>>>>>> when a new register set is ready and clears to 0=WORKING
>>>>>>>> after
>>>>>>>> the
>>>>>>>> VBLANK copy. Software must never write it, and there is
>>>>>>>> no
>>>>>>>> polling
>>>>>>>> use
>>>>>>> It seems to be writable and controls whether register
>>>>>>> buffering
>>>>>>> is
>>>>>>> enabled, see [1].
>>>>>>>
>>>>>>> The description of this bit in MA35D1 TRM says "This
>>>>>>> ensures a
>>>>>>> frame
>>>>>>> will always start with a valid working set if this register
>>>>>>> is
>>>>>>> programmed last, which reduces the need for SW to wait for
>>>>>>> the
>>>>>>> start of
>>>>>>> a VBLANK signal in order to ensure all states are loaded
>>>>>>> before
>>>>>>> the
>>>>>>> next VBLANK", which indicates some kind of "committing
>>>>>>> write",
>>>>>>> although
>>>>>>> the code at [1] seems to indicate that double buffering is
>>>>>>> only
>>>>>>> enabled
>>>>>>> when bit is cleared.
>>>>>>>
>>>>>>> Anyway this bit should be programmable, and "Software must
>>>>>>> never
>>>>>>> write
>>>>>>> it" contradicts with the MA35D1 TRM.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Icenowy
>>>>>>>
>>>>>>> [1]
>>>>>>> https://github.com/rockos-riscv/rockos-kernel/blob/rockos-v6.6.y/drivers/gpu/drm/eswin/es_dc_hw.c#L993
>>>>>> Thank you for the correction. I'll add
>>>>>> `#define VSDC_FB_CONFIG_VALID BIT(3)` to
>>>>>> vs_primary_plane_regs.h
>>>>>> and
>>>>>> write it in `vs_primary_plane_commit()` for non-config_ex
>>>>>> variants.
>>>>>>>> case in the driver that requires a named constant. For
>>>>>>>> non-
>>>>>>>> config_ex
>>>>>>>> variants, `vs_primary_plane_commit()` performs no commit
>>>>>>>> operation —
>>>>>>>> `VSDC_FB_CONFIG_ENABLE` (OUTPUT, BIT(0)) is set in
>>>>>>>> `vs_crtc_atomic_enable()` and `VSDC_FB_CONFIG_RESET`
>>>>>>>> (BIT(4))
>>>>>>>> is
>>>>>>>> set/cleared in the bridge enable/disable paths.
>>>>> Well according to the driver code for DC8000 from Eswin, and
>>>>> the
>>>>> bit
>>>>> named "VALID", maybe it should be cleared before programming
>>>>> the
>>>>> registers, and set after programming registers, to make the
>>>>> process
>>>>> of
>>>>> programming registers atomic from the perspective of the
>>>>> display
>>>>> controller.
>>>>>
>>>>> Anyway this should require testing on real hardware to verify.
>>>>>
>>>>> By the way, I see multiple peripheral drivers for MA35D1 get
>>>>> applied in
>>>>> the torvalds tree, but the device tree is still only a
>>>>> skeleton;
>>>>> when
>>>>> will the device tree be updated?
>>>>>
>>>>> Thanks,
>>>>> Icenowy
>>>> Thanks for pointing this out. I’ll perform tests on real hardware
>>>> since
>>>> I haven’t used this bit before.
>>>>
>>>> As for the device tree, we plan to update it comprehensively
>>>> after
>>>> completing several major IPs, with the goal of releasing the
>>>> update
>>>> later this year.
>>> Well I bought a MA35D1 board (MYIR MYB-LMA35 + RGB LCD) earlier
>>> this
>>> year (and this is where I got the MA35D1 identification register
>>> values). Hope I can have a chance to test this driver by myself.
>>>
>>> As MMC, Ethernet and USB support is all applied, maybe it's already
>>> worthy to update the device tree ;-)
>>>
>>> Thanks,
>>> Icenowy
>> Yes you can!
>>
>> I have performed hardware validation on the MA35D1 and found that
>> this
>> bit acts as a manual latch for the shadow registers rather than an
>> auto-clearing trigger, which clarifies the slightly ambiguous
>> description in the TRM.
>>
>> Following your suggestion, I will align the implementation with
>> ESWIN's
>> DC8000 logic: setting the VALID bit at atomic_begin and clearing it
> Ah do you mean clearing it at begin and setting it at flush?
>
> In the Eswin driver (which seems to be based on reference code by
> Verisilicon, I saw similar driver code for DC8200),
> dc_hw_enable_shadow_register() clears VALID bit when enable is true,
> and all register setting sequences calls that function with enable =
> true before setting and enable = false after setting.
>
> In addition, considering this bit is called "VALID" instead of
> "INVALID", I think it represents that the DC will apply the new setting
> when it's set and keep the current setting when it's cleared, so I
> think it should be cleared before modeset sequence and be set after
> modeset sequence.
>
> Thanks,
> Icenowy
Thanks for pointing that out. To clarify, the TRM defines the states for
this bit as:
1: PENDING (Shadow registers are locked; incoming CPU writes are held in
the shadow buffer).
0: WORKING (Shadow registers are unfrozen/live; configuration is committed).
Regarding the Eswin reference, `dc_hw_enable_shadow_register(hw, false)`
actually writes a 1 to isolate the registers during a batch update, and
then transitions back to true (0) to flush them out.
My hardware test confirms this sequence:
- atomic_begin: We set VALID = 1. This safely freezes the current
scanout configuration so we can update multiple registers (like frame
addresses and pitches) without mid-frame tearing.
- atomic_update: We write the new register values safely into the frozen
shadow space.
- atomic_flush: We clear VALID = 0. This releases the shadow lock,
triggering the hardware to latch the whole batch atomically.
If we reverse this logic—leaving the bit at 1 after the flush — the
hardware remains permanently stuck in the PENDING state, waiting to be
unfrozen, which starves the display engine and results in the blank
screen behavior I observed.
>> at
>> atomic_flush. My tests confirm this allows the hardware to latch the
>> plane configuration correctly while avoiding the blank screen issues
>> observed with other configurations.
>>
>> I am preparing the v2 patchset with this change, along with the
>> requested commit splits, and will submit it shortly.🙂
>>
>>>>>>> ========= 8< ==========
>>>>>>>
^ permalink raw reply
* Re: [PATCH v3 03/10] firmware: samsung: acpm: Drop redundant _ops suffix in acpm_ops members
From: Tudor Ambarus @ 2026-05-15 9:05 UTC (permalink / raw)
To: Lee Jones
Cc: Rafael J. Wysocki, Zhang Rui, Lukasz Luba, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Krzysztof Kozlowski,
Alim Akhtar, Bartlomiej Zolnierkiewicz, Kees Cook,
Gustavo A. R. Silva, Peter Griffin, André Draszik,
Daniel Lezcano, Sylwester Nawrocki, Chanwoo Choi,
Michael Turquette, Stephen Boyd, willmcvicker, jyescas, shin.son,
linux-samsung-soc, linux-kernel, linux-pm, devicetree,
linux-arm-kernel, linux-hardening, linux-clk
In-Reply-To: <20260507120003.GG305027@google.com>
On 5/7/26 3:00 PM, Lee Jones wrote:
> Acked-by: Lee Jones <lee@kernel.org>
Thanks, Lee!
The set evolved [1], but this particular patch was not changed.
I'm going to carry your Acked-by in the resend I'm going to do.
Cheers,
ta
Link: https://lore.kernel.org/linux-samsung-soc/CADrjBPqzKpcd9vuCmNUptCUPyPpPbHcc19-7kN-1c0RpW1e5DQ@mail.gmail.com/T/#mcce154a7e0c6cd1ca6cd5a1e37541ed7a85a84d4 [1]
^ permalink raw reply
* Re: [PATCH v1 1/3] dt-bindings: display: rockchip: analogix-dp: Expose inherited properties
From: Conor Dooley @ 2026-05-15 9:04 UTC (permalink / raw)
To: Damon Ding
Cc: Conor Dooley, hjc, heiko, andy.yan, maarten.lankhorst, mripard,
tzimmermann, airlied, simona, robh, krzk+dt, conor+dt,
andrzej.hajda, neil.armstrong, rfoss, Laurent.pinchart, jonas,
jernej.skrabec, nicolas.frattaroli, cristian.ciocaltea,
sebastian.reichel, dmitry.baryshkov, luca.ceresoli, dianders,
m.szyprowski, dri-devel, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <2f653664-27e9-4632-97e9-8b59cf7e585e@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 3781 bytes --]
On Fri, May 15, 2026 at 11:57:58AM +0800, Damon Ding wrote:
> Hi Conor,
>
> On 5/15/2026 2:16 AM, Conor Dooley wrote:
> > On Thu, May 14, 2026 at 03:01:31PM +0800, Damon Ding wrote:
> > > Expose the inherited properties from the base analogix-dp schema
> > > to satisfy unevaluatedProperties constraints.
> > >
> > > Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
> >
> > Given it's unevaluatedProperties, not addtionalProperties, this patch
> > shouldn't be needed?
> >
>
> When I remove both the top-level data-lanes property and those explicit
> "xxx: true" property entries and run the dtbs check with:
>
> make CHECK_DTBS=y CROSS_COMPILE=aarch64-linux-gnu- LT0=none LLVM=1
> LLVM_IAS=1 ARCH=arm64 rockchip/rk3588-evb1-v10.dtb
> rockchip/rk3588s-evb1-v10.dtb rockchip/rk3399-sapphire-excavator.dtb
> rockchip/rk3576-evb1-v10.dtb -j4
>
> It results in validation errors like these:
>
> /home/ding/drm-misc/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb:
> edp@27dc0000: ports:port@1:endpoint: Unevaluated properties are not allowed
> ('data-lanes' was unexpected)
> from schema $id:
> http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml#
> /home/ding/drm-misc/arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb:
> edp@27dc0000: Unevaluated properties are not allowed ('force-hpd',
> 'interrupts', 'phy-names', 'phys', 'ports', 'reg' were unexpected)
> from schema $id:
> http://devicetree.org/schemas/display/rockchip/rockchip,analogix-dp.yaml#
>
> I suspect that the properties defined in the child binding are
> overriding/masking all the inherited properties from the parent Analogix DP
> schema.
>
> Is there a better way to fix this issue without explicitly listing all
> inherited properties as true?
The example in this file uses most of the properties that you mention
above:
dp@ff970000 {
compatible = "rockchip,rk3288-dp";
reg = <0xff970000 0x4000>;
interrupts = <GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru SCLK_EDP>, <&cru PCLK_EDP_CTRL>;
clock-names = "dp", "pclk";
phys = <&dp_phy>;
phy-names = "dp";
resets = <&cru 111>;
reset-names = "dp";
rockchip,grf = <&grf>;
pinctrl-0 = <&edp_hpd>;
pinctrl-names = "default";
dt_binding_check reports no problems with this node, so I think the
problem might lie elsewhere?
There's no edp node in the dts you mention above, so this looks like an
interaction with something that's not yet upstream.
If this is required for the rk3576 edp, then you should include this
patch in the rk3576 edp support series rather than this one anyway where
it can actually be evaluated alongside the node it apparently causes
problems with.
pw-bot: changes-requested
Thanks,
Conor.
>
> Best regards,
> Damon
>
> > > ---
> > > .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 7 +++++++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> > > index bb75d898a5c5..896ded87880f 100644
> > > --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> > > +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> > > @@ -50,6 +50,13 @@ properties:
> > > aux-bus:
> > > $ref: /schemas/display/dp-aux-bus.yaml#
> > > + reg: true
> > > + interrupts: true
> > > + phys: true
> > > + phy-names: true
> > > + force-hpd: true
> > > + ports: true
> > > +
> > > required:
> > > - compatible
> > > - clocks
> > > --
> > > 2.34.1
> > >
> > >
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox