* [PATCH V2 11/11] soc: ti: k3-ringacc: Use str_enabled_disabled() helper
From: Nishanth Menon @ 2026-05-12 17:06 UTC (permalink / raw)
To: Justin Stitt, Bill Wendling, Nick Desaulniers, Nathan Chancellor,
Santosh Shilimkar
Cc: afd, Nishanth Menon, llvm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512170623.3174416-1-nm@ti.com>
Coccinelle (scripts/coccinelle/api/string_choices.cocci) flags an
opportunity to replace the open-coded ternary expression in the probe
dev_info() call:
k3-ringacc.c:1439:3-32: opportunity for
str_enabled_disabled(ringacc->dma_ring_reset_quirk)
Replace the ternary with str_enabled_disabled() and add the required
include for <linux/string_choices.h>.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since V1:
- None.
V1: https://lore.kernel.org/all/20260508153211.3688277-12-nm@ti.com/
drivers/soc/ti/k3-ringacc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/ti/k3-ringacc.c b/drivers/soc/ti/k3-ringacc.c
index 7602b8a909b0..ec4207d98dca 100644
--- a/drivers/soc/ti/k3-ringacc.c
+++ b/drivers/soc/ti/k3-ringacc.c
@@ -10,6 +10,7 @@
#include <linux/module.h>
#include <linux/of.h>
#include <linux/platform_device.h>
+#include <linux/string_choices.h>
#include <linux/sys_soc.h>
#include <linux/dma/ti-cppi5.h>
#include <linux/soc/ti/k3-ringacc.h>
@@ -1436,7 +1437,7 @@ static int k3_ringacc_init(struct platform_device *pdev,
ringacc->rm_gp_range->desc[0].num,
ringacc->tisci_dev_id);
dev_info(dev, "dma-ring-reset-quirk: %s\n",
- ringacc->dma_ring_reset_quirk ? "enabled" : "disabled");
+ str_enabled_disabled(ringacc->dma_ring_reset_quirk));
dev_info(dev, "RA Proxy rev. %08x, num_proxies:%u\n",
readl(&ringacc->proxy_gcfg->revision), ringacc->num_proxies);
--
2.47.0
^ permalink raw reply related
* Re: [PATCH v2 01/16] dt-bindings: iio: adc: mt6359: generalize description for mt63xx series
From: Jonathan Cameron @ 2026-05-12 17:06 UTC (permalink / raw)
To: Roman Vivchar
Cc: David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Sen Chu, Sean Wang, Macpaul Lin,
Lee Jones, Srinivas Kandagatla, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, linux-pm, Ben Grisdale
In-Reply-To: <wTd36596tJhd0sPk-1MSi79xz14IBgTKXpD25tnKuRXLfGywkoenZ-wIDtOvRxEZL8xpqijZ0nxMsCFTOJgJq__y26VzCpe_9f0JQGWrJVo=@protonmail.com>
On Tue, 12 May 2026 13:55:26 +0000
Roman Vivchar <rva333@protonmail.com> wrote:
> On Tuesday, May 12th, 2026 at 4:13 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>
> > On Tue, 12 May 2026 08:18:15 +0300
> > Roman Vivchar via B4 Relay <devnull+rva333.protonmail.com@kernel.org> wrote:
> >
> > > From: Roman Vivchar <rva333@protonmail.com>
> > >
> > > Update binding title to the MT63xx, since the list of compatibles already
> > > includes mt6363 and mt6373 which don't belong to the mt6350 family.
> > Hi Roman,
> >
> > Wild cards have a nasty habit of going wrong. I'd prefer to see
> > language like: MT6359 and similar PMIC AUXADC
>
> Hi Jonathan,
>
> I agree that it would be better to specify the exact PMIC models, however
> 'similar' wording might be a bit misleading here. As far as I know,
> the mt6363 and mt6373 use SPMI, while mt635x (and older models, like
> most of the mt63xx series) use PWRAP (a custom SPI-based protocol).
> The mt6323 has an older AUXADC revision which is not compatible
> with the mt635x driver.
>
> Would you prefer more explicit list like 'MT6323, MT6350 series, MT6363
> and MT6373 PMIC AUXADC'? It's a bit mess because some mt63xx
> (like mt6333) are sub-PMICs and use I2C instead of PWRAP.
Complete lists don't work because sooner or later they become too long
for a title (though they should be there elsewhere in the dt-binding!)
Perhaps something around: mt6359 and similar SoC ADCs including those accessed via ....
>
> > It is less important here than in many other places because the
> > file has an explicit list soon after this, but none the less
> > we've been bitten by this too often to think manufacturers won't
> > throw a completely non compatible part in the middle of a wild
> > card covered range.
> >
>
> Best regards,
> Roman
^ permalink raw reply
* [PATCH V2 02/11] soc: ti: knav_qmss: Rename global kdev to knav_qdev to fix -Wshadow
From: Nishanth Menon @ 2026-05-12 17:06 UTC (permalink / raw)
To: Justin Stitt, Bill Wendling, Nick Desaulniers, Nathan Chancellor,
Santosh Shilimkar
Cc: afd, Nishanth Menon, llvm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512170623.3174416-1-nm@ti.com>
Building with W=2 (clang, LLVM=1) produces 22 -Wshadow warnings in
knav_qmss_queue.c because the file-scoped singleton 'kdev' is shadowed
by a parameter of the same name in 21 internal functions and one local
variable, e.g.:
knav_qmss_queue.c:194:49: warning: declaration shadows a variable
in the global scope [-Wshadow]
194 | knav_queue_match_id_to_inst(struct knav_device *kdev, unsigned id)
Rename the global singleton from kdev to knav_qdev rather than
renaming all ~21 function parameters, as this requires fewer changes
and leaves function signatures, struct field accesses, and header
macros in knav_qmss.h untouched.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since V1:
- None.
V1: https://lore.kernel.org/all/20260508153211.3688277-3-nm@ti.com/
drivers/soc/ti/knav_qmss_queue.c | 94 ++++++++++++++++----------------
1 file changed, 47 insertions(+), 47 deletions(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index e87a42734f25..2c103bb6edef 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -25,7 +25,7 @@
#include "knav_qmss.h"
-static struct knav_device *kdev;
+static struct knav_device *knav_qdev;
static DEFINE_MUTEX(knav_dev_lock);
#define knav_dev_lock_held() \
lockdep_is_held(&knav_dev_lock)
@@ -205,10 +205,10 @@ knav_queue_match_id_to_inst(struct knav_device *kdev, unsigned id)
static inline struct knav_queue_inst *knav_queue_find_by_id(int id)
{
- if (kdev->base_id <= id &&
- kdev->base_id + kdev->num_queues > id) {
- id -= kdev->base_id;
- return knav_queue_match_id_to_inst(kdev, id);
+ if (knav_qdev->base_id <= id &&
+ knav_qdev->base_id + knav_qdev->num_queues > id) {
+ id -= knav_qdev->base_id;
+ return knav_queue_match_id_to_inst(knav_qdev, id);
}
return NULL;
}
@@ -296,7 +296,7 @@ static struct knav_queue *knav_queue_open_by_type(const char *name,
mutex_lock(&knav_dev_lock);
- for_each_instance(idx, inst, kdev) {
+ for_each_instance(idx, inst, knav_qdev) {
if (knav_queue_is_reserved(inst))
continue;
if (!knav_queue_match_type(inst, type))
@@ -469,9 +469,9 @@ static int knav_queue_debug_show(struct seq_file *s, void *v)
mutex_lock(&knav_dev_lock);
seq_printf(s, "%s: %u-%u\n",
- dev_name(kdev->dev), kdev->base_id,
- kdev->base_id + kdev->num_queues - 1);
- for_each_instance(idx, inst, kdev)
+ dev_name(knav_qdev->dev), knav_qdev->base_id,
+ knav_qdev->base_id + knav_qdev->num_queues - 1);
+ for_each_instance(idx, inst, knav_qdev)
knav_queue_debug_show_instance(s, inst);
mutex_unlock(&knav_dev_lock);
@@ -762,17 +762,17 @@ void *knav_pool_create(const char *name,
unsigned last_offset;
int ret;
- if (!kdev)
+ if (!knav_qdev)
return ERR_PTR(-EPROBE_DEFER);
- if (!kdev->dev)
+ if (!knav_qdev->dev)
return ERR_PTR(-ENODEV);
- pool = devm_kzalloc(kdev->dev, sizeof(*pool), GFP_KERNEL);
+ pool = devm_kzalloc(knav_qdev->dev, sizeof(*pool), GFP_KERNEL);
if (!pool)
return ERR_PTR(-ENOMEM);
- for_each_region(kdev, reg_itr) {
+ for_each_region(knav_qdev, reg_itr) {
if (reg_itr->id != region_id)
continue;
region = reg_itr;
@@ -780,14 +780,14 @@ void *knav_pool_create(const char *name,
}
if (!region) {
- dev_err(kdev->dev, "region-id(%d) not found\n", region_id);
+ dev_err(knav_qdev->dev, "region-id(%d) not found\n", region_id);
ret = -EINVAL;
goto err;
}
pool->queue = knav_queue_open(name, KNAV_QUEUE_GP, 0);
if (IS_ERR(pool->queue)) {
- dev_err(kdev->dev,
+ dev_err(knav_qdev->dev,
"failed to open queue for pool(%s), error %ld\n",
name, PTR_ERR(pool->queue));
ret = PTR_ERR(pool->queue);
@@ -795,13 +795,13 @@ void *knav_pool_create(const char *name,
}
pool->name = kstrndup(name, KNAV_NAME_SIZE - 1, GFP_KERNEL);
- pool->kdev = kdev;
- pool->dev = kdev->dev;
+ pool->kdev = knav_qdev;
+ pool->dev = knav_qdev->dev;
mutex_lock(&knav_dev_lock);
if (num_desc > (region->num_desc - region->used_desc)) {
- dev_err(kdev->dev, "out of descs in region(%d) for pool(%s)\n",
+ dev_err(knav_qdev->dev, "out of descs in region(%d) for pool(%s)\n",
region_id, name);
ret = -ENOMEM;
goto err_unlock;
@@ -827,10 +827,10 @@ void *knav_pool_create(const char *name,
pool->num_desc = num_desc;
pool->region_offset = last_offset;
region->used_desc += num_desc;
- list_add_tail(&pool->list, &kdev->pools);
+ list_add_tail(&pool->list, &knav_qdev->pools);
list_add_tail(&pool->region_inst, node);
} else {
- dev_err(kdev->dev, "pool(%s) create failed: fragmented desc pool in region(%d)\n",
+ dev_err(knav_qdev->dev, "pool(%s) create failed: fragmented desc pool in region(%d)\n",
name, region_id);
ret = -ENOMEM;
goto err_unlock;
@@ -844,7 +844,7 @@ void *knav_pool_create(const char *name,
mutex_unlock(&knav_dev_lock);
err:
kfree(pool->name);
- devm_kfree(kdev->dev, pool);
+ devm_kfree(knav_qdev->dev, pool);
return ERR_PTR(ret);
}
EXPORT_SYMBOL_GPL(knav_pool_create);
@@ -872,7 +872,7 @@ void knav_pool_destroy(void *ph)
mutex_unlock(&knav_dev_lock);
kfree(pool->name);
- devm_kfree(kdev->dev, pool);
+ devm_kfree(knav_qdev->dev, pool);
}
EXPORT_SYMBOL_GPL(knav_pool_destroy);
@@ -1683,7 +1683,7 @@ static inline struct knav_qmgr_info *knav_find_qmgr(unsigned id)
{
struct knav_qmgr_info *qmgr;
- for_each_qmgr(kdev, qmgr) {
+ for_each_qmgr(knav_qdev, qmgr) {
if ((id >= qmgr->start_queue) &&
(id < qmgr->start_queue + qmgr->num_queues))
return qmgr;
@@ -1775,22 +1775,22 @@ static int knav_queue_probe(struct platform_device *pdev)
return -ENODEV;
}
- kdev = devm_kzalloc(dev, sizeof(struct knav_device), GFP_KERNEL);
- if (!kdev) {
+ knav_qdev = devm_kzalloc(dev, sizeof(struct knav_device), GFP_KERNEL);
+ if (!knav_qdev) {
dev_err(dev, "memory allocation failed\n");
return -ENOMEM;
}
if (device_get_match_data(dev))
- kdev->version = QMSS_66AK2G;
+ knav_qdev->version = QMSS_66AK2G;
- platform_set_drvdata(pdev, kdev);
- kdev->dev = dev;
- INIT_LIST_HEAD(&kdev->queue_ranges);
- INIT_LIST_HEAD(&kdev->qmgrs);
- INIT_LIST_HEAD(&kdev->pools);
- INIT_LIST_HEAD(&kdev->regions);
- INIT_LIST_HEAD(&kdev->pdsps);
+ platform_set_drvdata(pdev, knav_qdev);
+ knav_qdev->dev = dev;
+ INIT_LIST_HEAD(&knav_qdev->queue_ranges);
+ INIT_LIST_HEAD(&knav_qdev->qmgrs);
+ INIT_LIST_HEAD(&knav_qdev->pools);
+ INIT_LIST_HEAD(&knav_qdev->regions);
+ INIT_LIST_HEAD(&knav_qdev->pdsps);
pm_runtime_enable(&pdev->dev);
ret = pm_runtime_resume_and_get(&pdev->dev);
@@ -1805,31 +1805,31 @@ static int knav_queue_probe(struct platform_device *pdev)
ret = -ENODEV;
goto err;
}
- kdev->base_id = temp[0];
- kdev->num_queues = temp[1];
+ knav_qdev->base_id = temp[0];
+ knav_qdev->num_queues = temp[1];
/* Initialize queue managers using device tree configuration */
- ret = knav_queue_init_qmgrs(kdev, node);
+ ret = knav_queue_init_qmgrs(knav_qdev, node);
if (ret)
goto err;
/* get pdsp configuration values from device tree */
- ret = knav_queue_setup_pdsps(kdev, node);
+ ret = knav_queue_setup_pdsps(knav_qdev, node);
if (ret)
goto err;
/* get usable queue range values from device tree */
- ret = knav_setup_queue_pools(kdev, node);
+ ret = knav_setup_queue_pools(knav_qdev, node);
if (ret)
goto err;
- ret = knav_get_link_ram(kdev, "linkram0", &kdev->link_rams[0]);
+ ret = knav_get_link_ram(knav_qdev, "linkram0", &knav_qdev->link_rams[0]);
if (ret) {
- dev_err(kdev->dev, "could not setup linking ram\n");
+ dev_err(knav_qdev->dev, "could not setup linking ram\n");
goto err;
}
- ret = knav_get_link_ram(kdev, "linkram1", &kdev->link_rams[1]);
+ ret = knav_get_link_ram(knav_qdev, "linkram1", &knav_qdev->link_rams[1]);
if (ret) {
/*
* nothing really, we have one linking ram already, so we just
@@ -1837,15 +1837,15 @@ static int knav_queue_probe(struct platform_device *pdev)
*/
}
- ret = knav_queue_setup_link_ram(kdev);
+ ret = knav_queue_setup_link_ram(knav_qdev);
if (ret)
goto err;
- ret = knav_queue_setup_regions(kdev, node);
+ ret = knav_queue_setup_regions(knav_qdev, node);
if (ret)
goto err;
- ret = knav_queue_init_queues(kdev);
+ ret = knav_queue_init_queues(knav_qdev);
if (ret < 0) {
dev_err(dev, "hwqueue initialization failed\n");
goto err;
@@ -1857,9 +1857,9 @@ static int knav_queue_probe(struct platform_device *pdev)
return 0;
err:
- knav_queue_stop_pdsps(kdev);
- knav_queue_free_regions(kdev);
- knav_free_queue_ranges(kdev);
+ knav_queue_stop_pdsps(knav_qdev);
+ knav_queue_free_regions(knav_qdev);
+ knav_free_queue_ranges(knav_qdev);
pm_runtime_put_sync(&pdev->dev);
pm_runtime_disable(&pdev->dev);
return ret;
--
2.47.0
^ permalink raw reply related
* [PATCH V2 04/11] soc: ti: knav_qmss: Fix kernel-doc Return: tags
From: Nishanth Menon @ 2026-05-12 17:06 UTC (permalink / raw)
To: Justin Stitt, Bill Wendling, Nick Desaulniers, Nathan Chancellor,
Santosh Shilimkar
Cc: afd, Nishanth Menon, llvm, linux-arm-kernel, linux-kernel,
Randy Dunlap
In-Reply-To: <20260512170623.3174416-1-nm@ti.com>
Fix functions that use inline 'Returns ...' instead of 'Return:'
kernel-doc comments, producing warnings with W=2:
knav_qmss_queue.c:524: No description found for return value
of 'knav_queue_open'
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since V1:
- Picked Randy's Tested and Acked.
V1: https://lore.kernel.org/all/20260508153211.3688277-5-nm@ti.com/
drivers/soc/ti/knav_qmss_queue.c | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index f65658014b05..c3f85052002b 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -517,7 +517,7 @@ static int knav_queue_flush(struct knav_queue *qh)
* Subsequent attempts to open a shared queue should
* also have this flag.
*
- * Returns a handle to the open hardware queue if successful. Use IS_ERR()
+ * Return: handle to the open hardware queue on success. Use IS_ERR()
* to check the returned value for error codes.
*/
void *knav_queue_open(const char *name, unsigned id,
@@ -573,7 +573,7 @@ EXPORT_SYMBOL_GPL(knav_queue_close);
* @cmd: - control commands
* @arg: - command argument
*
- * Returns 0 on success, errno otherwise.
+ * Return: 0 on success, errno otherwise.
*/
int knav_queue_device_control(void *qhandle, enum knav_queue_ctrl_cmd cmd,
unsigned long arg)
@@ -625,7 +625,7 @@ EXPORT_SYMBOL_GPL(knav_queue_device_control);
* @size: - size of data to push
* @flags: - can be used to pass additional information
*
- * Returns 0 on success, errno otherwise.
+ * Return: 0 on success, errno otherwise.
*/
int knav_queue_push(void *qhandle, dma_addr_t dma,
unsigned size, unsigned flags)
@@ -646,7 +646,7 @@ EXPORT_SYMBOL_GPL(knav_queue_push);
* @qhandle: - hardware queue handle
* @size: - (optional) size of the data pop'ed.
*
- * Returns a DMA address on success, 0 on failure.
+ * Return: DMA address on success, 0 on failure.
*/
dma_addr_t knav_queue_pop(void *qhandle, unsigned *size)
{
@@ -747,8 +747,8 @@ EXPORT_SYMBOL_GPL(knav_pool_desc_dma_to_virt);
* @region_id: - QMSS region id from which the descriptors are to be
* allocated.
*
- * Returns a pool handle on success.
- * Use IS_ERR_OR_NULL() to identify error values on return.
+ * Return: pool handle on success. Use IS_ERR_OR_NULL() to identify
+ * error values on return.
*/
void *knav_pool_create(const char *name,
int num_desc, int region_id)
@@ -878,7 +878,7 @@ EXPORT_SYMBOL_GPL(knav_pool_destroy);
* knav_pool_desc_get() - Get a descriptor from the pool
* @ph: - pool handle
*
- * Returns descriptor from the pool.
+ * Return: descriptor from the pool on success, error pointer otherwise.
*/
void *knav_pool_desc_get(void *ph)
{
@@ -917,7 +917,7 @@ EXPORT_SYMBOL_GPL(knav_pool_desc_put);
* @dma: - DMA address return pointer
* @dma_sz: - adjusted return pointer
*
- * Returns 0 on success, errno otherwise.
+ * Return: 0 on success, errno otherwise.
*/
int knav_pool_desc_map(void *ph, void *desc, unsigned size,
dma_addr_t *dma, unsigned *dma_sz)
@@ -942,7 +942,7 @@ EXPORT_SYMBOL_GPL(knav_pool_desc_map);
* @dma: - DMA address of descriptor to unmap
* @dma_sz: - size of descriptor to unmap
*
- * Returns descriptor address on success, Use IS_ERR_OR_NULL() to identify
+ * Return: descriptor address on success. Use IS_ERR_OR_NULL() to identify
* error values on return.
*/
void *knav_pool_desc_unmap(void *ph, dma_addr_t dma, unsigned dma_sz)
@@ -962,7 +962,8 @@ EXPORT_SYMBOL_GPL(knav_pool_desc_unmap);
/**
* knav_pool_count() - Get the number of descriptors in pool.
* @ph: - pool handle
- * Returns number of elements in the pool.
+ *
+ * Return: number of elements in the pool.
*/
int knav_pool_count(void *ph)
{
--
2.47.0
^ permalink raw reply related
* [PATCH V2 05/11] soc: ti: knav_qmss: Use %pe to print PTR_ERR()
From: Nishanth Menon @ 2026-05-12 17:06 UTC (permalink / raw)
To: Justin Stitt, Bill Wendling, Nick Desaulniers, Nathan Chancellor,
Santosh Shilimkar
Cc: afd, Nishanth Menon, llvm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512170623.3174416-1-nm@ti.com>
Coccinelle (scripts/coccinelle/misc/ptr_err_to_pe.cocci) flags the
dev_err() call in knav_pool_create():
knav_qmss_queue.c:789:9-16: WARNING: Consider using %pe to print
PTR_ERR()
Replace the %ld / PTR_ERR() pair with %pe and pass the error pointer
directly to also print the symbolic error name.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since V1:
- None.
V1: https://lore.kernel.org/all/20260508153211.3688277-6-nm@ti.com/
drivers/soc/ti/knav_qmss_queue.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/soc/ti/knav_qmss_queue.c b/drivers/soc/ti/knav_qmss_queue.c
index c3f85052002b..50072e9dea37 100644
--- a/drivers/soc/ti/knav_qmss_queue.c
+++ b/drivers/soc/ti/knav_qmss_queue.c
@@ -785,8 +785,8 @@ void *knav_pool_create(const char *name,
pool->queue = knav_queue_open(name, KNAV_QUEUE_GP, 0);
if (IS_ERR(pool->queue)) {
dev_err(knav_qdev->dev,
- "failed to open queue for pool(%s), error %ld\n",
- name, PTR_ERR(pool->queue));
+ "failed to open queue for pool(%s), error %pe\n",
+ name, pool->queue);
ret = PTR_ERR(pool->queue);
goto err;
}
--
2.47.0
^ permalink raw reply related
* [PATCH V2 10/11] soc: ti: knav_dma: Use IOMEM_ERR_PTR() in pktdma_get_regs()
From: Nishanth Menon @ 2026-05-12 17:06 UTC (permalink / raw)
To: Justin Stitt, Bill Wendling, Nick Desaulniers, Nathan Chancellor,
Santosh Shilimkar
Cc: afd, Nishanth Menon, llvm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512170623.3174416-1-nm@ti.com>
pktdma_get_regs() returns a void __iomem * but uses ERR_PTR() on the
error path, causing sparse to warn about an address space mismatch.
Replace ERR_PTR() with IOMEM_ERR_PTR() to resolve the warning cleanly.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since V1:
- None.
V1: https://lore.kernel.org/all/20260508153211.3688277-11-nm@ti.com/
drivers/soc/ti/knav_dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index 7ba6fd58e9ce..96df3982e47b 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -520,7 +520,7 @@ static void __iomem *pktdma_get_regs(struct knav_dma_device *dma,
if (ret) {
dev_err(dev, "Can't translate of node(%pOFn) address for index(%d)\n",
node, index);
- return ERR_PTR(ret);
+ return IOMEM_ERR_PTR(ret);
}
regs = devm_ioremap_resource(kdev->dev, &res);
--
2.47.0
^ permalink raw reply related
* [PATCH V2 09/11] soc: ti: knav_dma: Remove dead check on unsigned args.args[0]
From: Nishanth Menon @ 2026-05-12 17:06 UTC (permalink / raw)
To: Justin Stitt, Bill Wendling, Nick Desaulniers, Nathan Chancellor,
Santosh Shilimkar
Cc: afd, Nishanth Menon, llvm, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512170623.3174416-1-nm@ti.com>
smatch warns:
knav_dma.c:390 of_channel_match_helper() warn: unsigned
'args.args[0]' is never less than zero.
of_phandle_args.args[] is uint32_t, so the 'args.args[0] < 0' check
is always false. of_parse_phandle_with_fixed_args() already handles
errors by returning a non-zero code, which is checked immediately
above. Remove the dead check.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
Changes since V1:
- None.
V1: https://lore.kernel.org/all/20260508153211.3688277-10-nm@ti.com/
drivers/soc/ti/knav_dma.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/soc/ti/knav_dma.c b/drivers/soc/ti/knav_dma.c
index 462d181ca564..7ba6fd58e9ce 100644
--- a/drivers/soc/ti/knav_dma.c
+++ b/drivers/soc/ti/knav_dma.c
@@ -387,11 +387,6 @@ static int of_channel_match_helper(struct device_node *np, const char *name,
return -ENODEV;
}
- if (args.args[0] < 0) {
- dev_err(kdev->dev, "Missing args for %s\n", name);
- return -ENODEV;
- }
-
return args.args[0];
}
--
2.47.0
^ permalink raw reply related
* Re: [PATCH v4 02/10] dt-bindings: display: rockchip: analogix-dp: Add per-clock descriptions
From: Conor Dooley @ 2026-05-12 17:11 UTC (permalink / raw)
To: Damon Ding
Cc: 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: <20260512095644.1946084-3-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 01/10] dt-bindings: display: rockchip: analogix-dp: Allow hclk as third clock
From: Conor Dooley @ 2026-05-12 17:12 UTC (permalink / raw)
To: Damon Ding
Cc: 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: <20260512095644.1946084-2-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 1863 bytes --]
On Tue, May 12, 2026 at 05:56:35PM +0800, Damon Ding wrote:
> RK3588 eDP controller requires HCLK_VO1 (video output bus clock)
> to access the VO1 GRF registers and enable the video datapath.
>
> Previously, the clock was enabled implicitly via the 'rockchip,vo-grf'
> phandle reference, which allowed the eDP to work without explicitly
> managing the hclk_vo1 clock. However, this is not safe or explicit.
>
> To align with other display controllers (HDMI) on RK3588 and make
> the clock requirement explicit, expand clock-names to support either
> "grf" (for older SoCs) or "hclk" (for RK3588) as the third clock.
>
> This makes the clock dependency clear and removes reliance on implicit
> clock enablement from GRF phandle.
>
> Fixes: f855146263b1 ("dt-bindings: display: rockchip: analogix-dp: Add support for RK3588")
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
>
> ---
>
> Changes in v4:
> - Modify the commit msg.
> ---
> .../bindings/display/rockchip/rockchip,analogix-dp.yaml | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> index d99b23b88cc5..d2bc8636b626 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,analogix-dp.yaml
> @@ -26,7 +26,9 @@ properties:
> items:
> - const: dp
> - const: pclk
> - - const: grf
> + - enum:
> + - grf
> + - hclk
Could you also enforce the correct clock name on a per-compatible basis
please?
pw-bot: changes-requested
Cheers,
Conor.
>
> power-domains:
> maxItems: 1
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 06/10] dt-bindings: display: rockchip: analogix-dp: Add support for RK3576
From: Conor Dooley @ 2026-05-12 17:13 UTC (permalink / raw)
To: Damon Ding
Cc: 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: <20260512095644.1946084-7-damon.ding@rock-chips.com>
[-- Attachment #1: Type: text/plain, Size: 346 bytes --]
On Tue, May 12, 2026 at 05:56:40PM +0800, Damon Ding wrote:
> RK3576 integrates an eDP TX controller compatible with the existing
> RK3588 hardware design, reuse the same binding configuration directly.
>
> Signed-off-by: Damon Ding <damon.ding@rock-chips.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/4] remoteproc: add common wc-ioremap carveout callbacks
From: Ben Levinsky @ 2026-05-12 17:15 UTC (permalink / raw)
To: Arnaud POULIQUEN, Bjorn Andersson, Mathieu Poirier,
linux-remoteproc@vger.kernel.org, Geert Uytterhoeven
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Magnus Damm, Patrice Chotard, Maxime Coquelin, Alexandre Torgue,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com, Shah, Tanmay
In-Reply-To: <DM4PR12MB64482037D67096393D4668CE83392@DM4PR12MB6448.namprd12.prod.outlook.com>
Hi Arnaud, Geert,
See my replies below
On 5/12/26 10:03 AM, Levinsky, Ben wrote:
> AMD General
>
>
>
>
> *From: *Arnaud POULIQUEN <arnaud.pouliquen@foss.st.com>
> *Date: *Tuesday, May 12, 2026 at 2:45 AM
> *To: *Levinsky, Ben <ben.levinsky@amd.com>; Bjorn Andersson
> <andersson@kernel.org>; Mathieu Poirier <mathieu.poirier@linaro.org>; linux-
> remoteproc@vger.kernel.org <linux-remoteproc@vger.kernel.org>
> *Cc: *Frank Li <Frank.Li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>;
> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Magnus Damm
> <magnus.damm@gmail.com>; Patrice Chotard <patrice.chotard@foss.st.com>; Maxime
> Coquelin <mcoquelin.stm32@gmail.com>; Alexandre Torgue
> <alexandre.torgue@foss.st.com>; imx@lists.linux.dev <imx@lists.linux.dev>;
> linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>;
> linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-renesas-
> soc@vger.kernel.org <linux-renesas-soc@vger.kernel.org>; linux-stm32@st-md-
> mailman.stormreply.com <linux-stm32@st-md-mailman.stormreply.com>; Shah, Tanmay
> <tanmay.shah@amd.com>
> *Subject: *Re: [PATCH 1/4] remoteproc: add common wc-ioremap carveout callbacks
>
>
>
> On 5/11/26 23:18, Ben Levinsky wrote:
> > Several remoteproc drivers open-code the same ioremap_wc() and
> > iounmap() callbacks for carveout mappings. Add subsystem-private
> > helpers in remoteproc_internal.h so those drivers can share the same
> > implementation.
> >
> > Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
> > ---
> > drivers/remoteproc/remoteproc_internal.h | 26 +++++++++++++++++++++++-
> > 1 file changed, 25 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/
> remoteproc_internal.h
> > index 0a5e15744b1d..3724a47a9748 100644
> > --- a/drivers/remoteproc/remoteproc_internal.h
> > +++ b/drivers/remoteproc/remoteproc_internal.h
> > @@ -12,8 +12,9 @@
> > #ifndef REMOTEPROC_INTERNAL_H
> > #define REMOTEPROC_INTERNAL_H
> >
> > -#include <linux/irqreturn.h>
> > #include <linux/firmware.h>
> > +#include <linux/io.h>
> > +#include <linux/irqreturn.h>
> >
> > struct rproc;
> >
> > @@ -122,6 +123,29 @@ rproc_find_carveout_by_name(struct rproc *rproc, const
> char *name, ...);
> > void rproc_add_rvdev(struct rproc *rproc, struct rproc_vdev *rvdev);
> > void rproc_remove_rvdev(struct rproc_vdev *rvdev);
> >
> > +static inline int rproc_mem_entry_ioremap_wc(struct rproc *rproc,
> > + struct rproc_mem_entry *mem)
> > +{
> > + void __iomem *va;
> > +
> > + va = ioremap_wc(mem->dma, mem->len);
> > + if (!va)
> > + return -ENOMEM;
>
> Could you add error message here to help for debug
>
> + dev_err(dev, "Unable to map memory region: %pa+%zx\n",
> + &mem->dma, mem->len);
> > +
> > + mem->va = (__force void *)va;
> > + mem->is_iomem = true;
Hi Geert,
Thanks for the review and the Reviewed-by for 4/4.
Here there is a real behavioral impact from not setting mem->is_iomem for carveouts backed by ioremap_wc(). In that case rproc_da_to_va() reports the region as normal memory, so the ELF load and
coredump paths can end up using memcpy/memset/memcpy_fromio incorrectly instead of the io accessors.
Given Arnaud's feedback, I'll split that out from the helper cleanup and explain it explicitly in a separate patch in v2.
Thanks,
Ben
>
> HHere, you set mem->is_iomem, but this is not done in platform drivers.
>
> It seems better to add this in a separate commit after patch 2/4, with
> an explanation of why it needs to be set.
>
> Regards,
> Arnaud
Hi Arnaud,
Thanks for the review.
Agreed on both points. I'll add the missing map-failure error message in v2.
For mem->is_iomem, I agree it should not be folded into this cleanup patch without its own justification. I'll keep the helper conversion behavior-neutral here and split
it into a separate patch with an explanation of the impact on the remoteproc load/coredump paths.
Thanks,
Ben
>
> > +
> > + return 0;
> > +}
> > +
> > +static inline int rproc_mem_entry_iounmap(struct rproc *rproc,
> > + struct rproc_mem_entry *mem)
> > +{
> > + iounmap((__force __iomem void *)mem->va);
> > +
> > + return 0;
> > +}
> > +
> > static inline int rproc_prepare_device(struct rproc *rproc)
> > {
> > if (rproc->ops->prepare)
>
^ permalink raw reply
* Re: [PATCH v2] clk: keystone: don't cache clock rate
From: Nishanth Menon @ 2026-05-12 17:16 UTC (permalink / raw)
To: Brian Masney
Cc: a-christidis, Tero Kristo, Santosh Shilimkar, Michael Turquette,
Stephen Boyd, linux-arm-kernel, linux-kernel, linux-clk,
Michael Walle, Kevin Hilman, Randolph Sapp
In-Reply-To: <agM-VB-ToGFNphfu@redhat.com>
On 10:51-20260512, Brian Masney wrote:
> Hi Nishanth,
> > Could you clarify if I need to take it via my tree to arnd or if this
> > patch will go via the clk tree?
>
> Sorry, I'm not sure what Stephen prefers here. An argument could be made
> for either approach. I would just go with whatever you have done in the
> past.
Thanks Brian for the review.
This usually will go via Stephen. Will wait, just trying to make sure
there is no change in expectations (given this patch missed a window).
--
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 849D 1736 249D
https://ti.com/opensource
^ permalink raw reply
* Re: [PATCH 3/4] remoteproc: add helper for optional ELF resource tables
From: Ben Levinsky @ 2026-05-12 17:19 UTC (permalink / raw)
To: Shah, Tanmay, Daniel Baluta, Bjorn Andersson, Mathieu Poirier,
linux-remoteproc@vger.kernel.org, Arnaud POULIQUEN
Cc: Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Patrice Chotard, Maxime Coquelin,
Alexandre Torgue, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com
In-Reply-To: <DM4PR12MB6448B1E51D58F3F8B11171F683392@DM4PR12MB6448.namprd12.prod.outlook.com>
Hi Daniel, Arnaud, Tanmay,
Please see my reply below
On 5/12/26 10:04 AM, Levinsky, Ben wrote:
> AMD General
>
>
>
>
> *From: *Shah, Tanmay <tanmays@amd.com>
> *Date: *Tuesday, May 12, 2026 at 7:53 AM
> *To: *Daniel Baluta <daniel.baluta@oss.nxp.com>; Levinsky, Ben
> <ben.levinsky@amd.com>; Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
> <mathieu.poirier@linaro.org>; linux-remoteproc@vger.kernel.org <linux-
> remoteproc@vger.kernel.org>
> *Cc: *Frank Li <Frank.Li@nxp.com>; Sascha Hauer <s.hauer@pengutronix.de>;
> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
> <festevam@gmail.com>; Geert Uytterhoeven <geert+renesas@glider.be>; Magnus Damm
> <magnus.damm@gmail.com>; Patrice Chotard <patrice.chotard@foss.st.com>; Maxime
> Coquelin <mcoquelin.stm32@gmail.com>; Alexandre Torgue
> <alexandre.torgue@foss.st.com>; imx@lists.linux.dev <imx@lists.linux.dev>;
> linux-arm-kernel@lists.infradead.org <linux-arm-kernel@lists.infradead.org>;
> linux-kernel@vger.kernel.org <linux-kernel@vger.kernel.org>; linux-renesas-
> soc@vger.kernel.org <linux-renesas-soc@vger.kernel.org>; linux-stm32@st-md-
> mailman.stormreply.com <linux-stm32@st-md-mailman.stormreply.com>; Shah, Tanmay
> <tanmay.shah@amd.com>
> *Subject: *Re: [PATCH 3/4] remoteproc: add helper for optional ELF resource tables
>
>
>
> On 5/12/2026 2:55 AM, Daniel Baluta wrote:
> > On 5/12/26 00:18, Ben Levinsky wrote:
> >> [You don't often get email from ben.levinsky@amd.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/
> LearnAboutSenderIdentification> ]
> >>
> >> Add a small helper around rproc_elf_load_rsc_table() for remoteproc
> >> drivers that treat a missing ELF resource table as optional. The helper
> >> returns success on -EINVAL and propagates other failures unchanged.
> >>
> >> Signed-off-by: Ben Levinsky <ben.levinsky@amd.com>
> >> ---
> >> drivers/remoteproc/remoteproc_internal.h | 12 ++++++++++++
> >> 1 file changed, 12 insertions(+)
> >>
> >> diff --git a/drivers/remoteproc/remoteproc_internal.h b/drivers/remoteproc/
> remoteproc_internal.h
> >> index 3724a47a9748..dff87e468837 100644
> >> --- a/drivers/remoteproc/remoteproc_internal.h
> >> +++ b/drivers/remoteproc/remoteproc_internal.h
> >> @@ -146,6 +146,18 @@ static inline int rproc_mem_entry_iounmap(struct rproc
> *rproc,
> >> return 0;
> >> }
> >>
> >> +static inline int rproc_elf_load_rsc_table_optional(struct rproc *rproc,
> >> + const struct firmware *fw)
> >> +{
> >> + int ret;
> >> +
> >> + ret = rproc_elf_load_rsc_table(rproc, fw);
> >> + if (ret == -EINVAL)
> >> + dev_dbg(&rproc->dev, "no resource table found\n");
> >
> > You are changing loglevel here. Initial drivers use dev_info or dev_warn. At
> least I'm used
> > with seeing this messages in the logs.
> >
> > So, what do you think on adding at least dev_info to this instead of dev_dbg?
> >
>
> Actually can we leave that choice to the platform driver ? There are
> many use cases where the remoteproc subsystem is used to load and start
> the remote core and the firmware doesn't have the resource table. We
> don't want to make info level log for such use cases, as the resource
> table is not expected in the first place there.
Thanks for the feedback.
I agree the helper should not impose a common log level. Some platforms intentionally run firmware without a resource table, so forcing a shared dev_info/dev_warn message from the helper would add
noise in those cases.
I'll rework this in v2 so the helper only handles the return-value behavior, while platform drivers keep control over whether the missing-table case is logged and at what level.
Thanks,
Ben
>
> >> +
> >> + return ret == -EINVAL ? 0 : ret;
> >> +}
> >> +
> >> static inline int rproc_prepare_device(struct rproc *rproc)
> >> {
> >> if (rproc->ops->prepare)
> >> --
> >> 2.34.1
> >>
> >>
> >
>
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Shah, Tanmay @ 2026-05-12 17:19 UTC (permalink / raw)
To: Mathieu Poirier, tanmay.shah
Cc: Arnaud POULIQUEN, Beleswar Prasad Padhi, Shenwei Wang,
Andrew Lunn, Linus Walleij, Bartosz Golaszewski, Jonathan Corbet,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Frank Li, Sascha Hauer, Shuah Khan, linux-gpio@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Pengutronix Kernel Team, Fabio Estevam, Peng Fan,
devicetree@vger.kernel.org, linux-remoteproc@vger.kernel.org,
imx@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
dl-linux-imx, Bartosz Golaszewski
In-Reply-To: <agNKHsAEscc1TDiq@p14s>
On 5/12/2026 10:41 AM, Mathieu Poirier wrote:
> On Mon, May 11, 2026 at 04:35:46PM -0500, Shah, Tanmay wrote:
>>
>>
>> On 5/11/2026 12:58 PM, Mathieu Poirier wrote:
>>> On Mon, 11 May 2026 at 10:47, Shah, Tanmay <tanmays@amd.com> wrote:
>>>>
>>>>
>>>>
>>>> On 5/5/2026 10:52 AM, Shah, Tanmay wrote:
>>>>>
>>>>>
>>>>> On 5/5/2026 4:28 AM, Arnaud POULIQUEN wrote:
>>>>>> Hi Tanmay,
>>>>>>
>>>>>> On 5/4/26 21:19, Shah, Tanmay wrote:
>>>>>>>
>>>>>>> Hello all,
>>>>>>>
>>>>>>> I have started reviewing this work as well.
>>>>>>> Thanks Shenwei for this work.
>>>>>>>
>>>>>>> I have gone through only the current revision, and would like to provide
>>>>>>> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
>>>>>>> Also, have some bindings related question.
>>>>>>>
>>>>>>> Please see below:
>>>>>>>
>>>>>>> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>>>>>>>> Hello Arnaud,
>>>>>>>>>
>>>>>>>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>>>>>>>> Hello,
>>>>>>>>>>
>>>>>>>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>>>>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Mathieu,
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>>>>>>>> Andersson
>>>>>>>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>>>>>>>> linux-imx <linux-
>>>>>>>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>>>> rpmsg GPIO driver
>>>>>>>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>>>>>>>> Jonathan
>>>>>>>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>>>>>>>>>> Krzysztof
>>>>>>>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>;
>>>>>>>>>>>>>>>>> Sascha
>>>>>>>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>>>>>>>>>> rpmsg
>>>>>>>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>>>>>>>> __u8 status;
>>>>>>>>>>>>>>>>>>> __u8 value;
>>>>>>>>>>>>>>>>>>> };
>>>>>>>>>>>>>>>>>> It is the same message format. Please see the message
>>>>>>>>>>>>>>>>>> definition
>>>>>>>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>>>>>>>> message format.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>>>>>>>> requests and
>>>>>>>>>>>>>>> replies, and a second one for events.
>>>>>>>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>>>>>>>> channel, so a
>>>>>>>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>>>>>>>> of messages.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>>>>>>>> an additional
>>>>>>>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>>>>>>>> field is added to
>>>>>>>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>>>>>>>> multiplexing
>>>>>>>>>>>>>>> capability by way of endpoints. There is no need for a port
>>>>>>>>>>>>>>> field. One endpoint,
>>>>>>>>>>>>>>> one GPIO controller.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>>>>>>>> endpoint maps to, either
>>>>>>>>>>>>>> by embedding the port information in the message (the current
>>>>>>>>>>>>>> way), or by sending it
>>>>>>>>>>>>>> separately.
>>>>>>>>>>>>>>
>>>>>>>>>>>>> An endpoint is created with every namespace request. There
>>>>>>>>>>>>> should be
>>>>>>>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>>>>>>>> unique
>>>>>>>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>>>>>>>> field to identify them.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Right, but this can still be done by just having one namespace
>>>>>>>>>>>> request.
>>>>>>>>>>>> We can create new endpoints bound to an existing namespace/
>>>>>>>>>>>> channel by
>>>>>>>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>>>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>>>>>>>> b73d-228295daaeec@ti.com/
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>>>>>>>> next week.
>>>>>>>>>>>
>>>>>>>>>>>> My mental model looks like this for the complete picture:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>>>>>>>> a. ept1 -> gpio-controller@1
>>>>>>>>>>>> b. ept2 -> gpio-controller@2
>>>>>>>>>>>>
>>>>>>>
>>>>>>> If my understanding of what gpio-controller is right, than this won't
>>>>>>> work. We need one rpmsg channel per gpio-controller, and in most cases
>>>>>>> there will be only one GPIO-controller on the remote side. If there are
>>>>>>> multiple or multiple instances of same controller, than we need separate
>>>>>>> channel name for that controller just like we would have separate device
>>>>>>> on the Linux.
>>>>>>
>>>>>> As done in ehe rpmsg_tty driver it could be instantiated several times with
>>>>>> the same channel/service name. This would imply a specific rpmsg to
>>>>>> retreive
>>>>>> the gpio controller index from the remote side.
>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>>>>>>>> beginning. I don't yet have a strong opinion on whether to use one
>>>>>>>>>>> namespace request per GPIO controller or a single request that spins
>>>>>>>>>>> off multiple endpoints. I'll have to look at your link and
>>>>>>>>>>> reflect on
>>>>>>>>>>> that. Regardless of how we proceed on that front, multiplexing needs
>>>>>>>>>>> to happen at the endpoint level rather than the packet level.
>>>>>>>>>>> This is
>>>>>>>>>>> the only way this work can move forward.
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>>>>>>>> created with every namespace request.”
>>>>>>>>>>
>>>>>>>>>> If the endpoint is created only on the Linux side, how do we match
>>>>>>>>>> the Linux endpoint address with the local port field on the remote
>>>>>>>>>> side?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Simply by sending a message to the remote containing the newly created
>>>>>>>>> endpoint and the port idx. Note that is this done just one time, after
>>>>>>>>> this
>>>>>>>>> Linux need not have the port field in the message everytime its sending
>>>>>>>>> a message.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>>>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>>>>>>>> the DT. This would:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> You will face the same problem in this case also that you asked above:
>>>>>>>>> "how do we match the Linux endpoint address with the local port field
>>>>>>>>> on the remote side?"
>>>>>>>>
>>>>>>>> Sorry I probably introduced confusion here
>>>>>>>> my sentence should be;
>>>>>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>>>>>> [port],
>>>>>>>> where [port] corresponds to the GPIO controller port in the DT.
>>>>>>>>
>>>>>>>>
>>>>>>>> For instance:
>>>>>>>>
>>>>>>>> rpmsg {
>>>>>>>> rpmsg-io {
>>>>>>>> #address-cells = <1>;
>>>>>>>> #size-cells = <0>;
>>>>>>>>
>>>>>>>> gpio@25 {
>>>>>>>> compatible = "rpmsg-gpio";
>>>>>>>> reg = <25>;
>>>>>>>> gpio-controller;
>>>>>>>> #gpio-cells = <2>;
>>>>>>>> #interrupt-cells = <2>;
>>>>>>>> interrupt-controller;
>>>>>>>> };
>>>>>>>>
>>>>>>>> gpio@32 {
>>>>>>>> compatible = "rpmsg-gpio";
>>>>>>>> reg = <32>;
>>>>>>>> gpio-controller;
>>>>>>>> #gpio-cells = <2>;
>>>>>>>> #interrupt-cells = <2>;
>>>>>>>> interrupt-controller;
>>>>>>>> };
>>>>>>>> };
>>>>>>>> };
>>>>>>>>
>>>>>>>> rpmsg-io-25 would match with gpio@25
>>>>>>>> rpmsg-io-32 would match with gpio@32
>>>>>>>>
>>>>>>>
>>>>>>> The problem with this approach is, we will endup creating way too many
>>>>>>> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
>>>>>>> many GPIOs can be handled by remote from memory perspective. At
>>>>>>> somepoint we might just run-out of number ept & channels created by the
>>>>>>> remote. As of now, open-amp library supports 128 epts I think.
>>>>>>
>>>>>> Right, I proposed a solution in my previous answer to Beleswar who has
>>>>>> the same concern.
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Because the endpoint that is created on a namespace request is also
>>>>>>>>> dynamic in nature. How will the remote know which endpoint addr
>>>>>>>>> Linux allocated for a namespace that it announced?
>>>>>>>>>
>>>>>>>>> As an example/PoC, I created a firmware example which announces
>>>>>>>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>>>>>>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>>>>>>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>>>>>>>> the name service request from the same firmware:
>>>>>>>>>
>>>>>>>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>>>>>>>> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel
>>>>>>>>> ti.ipc4.ping-pong addr 0xd
>>>>>>>>> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>>>>>>>> addr 0xe
>>>>>>>>> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>>>>>>>> formed from src = 0x400 to dst = 0xe
>>>>>>>>> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>>>>>>>> new channel: 0x401 -> 0xd!
>>>>>>>>>
>>>>>>>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>>>>>>>> Back to same problem. Simple solution is to reply to remote with the
>>>>>>>>> created ept addr and the index.
>>>>>>>>
>>>>>>>> That why I would like to suggest to use the name service field to
>>>>>>>> identify the port/controller, instead of the endpoint address.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> - match the RPMsg probe with the DT,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We can probe from all controllers with a single name service
>>>>>>>>> announcement too.
>>>>>>>>>
>>>>>>>>>> - provide a simple mapping between the port and the endpoint on both
>>>>>>>>>> sides,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We are trying to get rid of this mapping from Linux side to adapt
>>>>>>>>> the gpio-virtio design.
>>>>>>>>>
>>>>>>>>>> - allow multiple endpoints on the remote side,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> We can support this as well with single nameservice model.
>>>>>>>>> There is no limitation. Remote has to send a message with
>>>>>>>>> its newly created ept that's all.
>>>>>>>>>
>>>>>>>>>> - provide a simple discovery mechanism for remote capabilities.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>>>>>>>
>>>>>>>>> Feel free to let me know if you have concerns with any of the
>>>>>>>>> suggestions!
>>>>>>>>
>>>>>>>> My only concern, whatever the solution, is that we find a smart
>>>>>>>> solution to associate the correct endpoint with the correct GPIO
>>>>>>>> port/controller defined in the DT.
>>>>>>>>
>>>>>>>> I may have misunderstood your solution. Could you please help me
>>>>>>>> understand your proposal by explaining how you would handle three
>>>>>>>> GPIO ports defined in the DT, considering that the endpoint
>>>>>>>> addresses on the Linux side can be random?
>>>>>>>> If I assume there is a unique endpoint on the remote side,
>>>>>>>> I do not understand how you can match, on the firmware side,
>>>>>>>> the Linux endpoint address to the GPIO port.
>>>>>>>>
>>>>>>>> Thanks and Regards,Arnaud
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Beleswar
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Arnaud
>>>>>>>>>>
>>>>>>>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>>>>>>>> a. ept1 -> i2c@1
>>>>>>>>>>>> b. ept2 -> i2c@2
>>>>>>>>>>>> c. ept3 -> i2c@3
>>>>>>>>>>>>
>>>>>>>>>>>> etc...
>>>>>>>>>>>>
>>>>>>>
>>>>>>> Just want to clear-up few terms before I jump to the solution:
>>>>>>>
>>>>>>> **RPMsg channel/device**:
>>>>>>> - These are devices announced by the remote processor, and created by
>>>>>>> linux. They are created at: /sys/bus/rpmsg/devices
>>>>>>> - The channel format: <name>.<src ept>.<dst ept>
>>>>>>>
>>>>>>> **RPMsg endpoint**:
>>>>>>> - Endpoint is differnt than channel. Single channel can have multiple
>>>>>>> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>>>>>>>
>>>>>>> To create endpoint device, we have rpmsg_create_ept API, which takes
>>>>>>> channel information as input, which has src-ept, dst-ept.
>>>>>>>
>>>>>>> Following is proposed solution:
>>>>>>>
>>>>>>> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
>>>>>>> pin/port).
>>>>>>> - In our case that would be, single rpmsg-io node. (That makes me
>>>>>>> question if bindings are correct or not).
>>>>>>>
>>>>>>> 2) Assign GPIO number as src ept.
>>>>>>>
>>>>>>> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
>>>>>>> endpoint.
>>>>>>>
>>>>>>> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
>>>>>>> add 1024 offset to the GPIO number:
>>>>>>>
>>>>>>> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
>>>>>>> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>>>>>>>
>>>>>>> Now on the remote side, there is single channel and only single-endpoint
>>>>>>> is needed that is mapped to the rpmsg-io channel callback.
>>>>>>>
>>>>>>> That callback will receive all the payloads from the Linux, which will
>>>>>>> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>>>>>>
>>>>>>
>>>>>> Interesting approach. I also tried to find a similar solution.
>>>>>>
>>>>>> The question here is: how can we guarantee continuous addresses? Given
>>>>>> the static and dynamic allocation of endpoint addresses that are
>>>>>> implemented, my conclusion was that it is not reliable enough.
>>>>>>
>>>>>> but perhaps I missed something...
>>>>>>
>>>>>>>
>>>>>>> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
>>>>>>> on platform specific logic.
>>>>>>>
>>>>>>> This doesn't need PORT information at all. Also it makes sure that
>>>>>>> remote is using only single-endpoint so not much memory is used.
>>>>>>>
>>>>>>> *Example*:
>>>>>>> If only rpmsg-gpio channel is created by the remote side, than following
>>>>>>> is the representation of the devices when GPIO 25, 26, 27 is assigned to
>>>>>>> the rpmsg-io controller:
>>>>>>>
>>>>>>> Linux Remote
>>>>>>>
>>>>>>> rpmsg-channel: rpmsg-gpio.0x400.0x400
>>>>>>>
>>>>>>> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
>>>>>>> |
>>>>>>> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
>>>>>>> |
>>>>>>> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-| 0x400 ept callback.
>>>>>>>
>>>>>>>
>>>>>>> *On remote side*:
>>>>>>>
>>>>>>> ept_0x400_callback(..., int src_ept, ...,)
>>>>>>> {
>>>>>>> int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
>>>>>>> // platform specific logic to convert gpio num to proper pin,
>>>>>>> // just like you would convert gpio num to pin on a linux gpio
>>>>>>> controller.
>>>>>>> }
>>>>>>>
>>>>>>> My question on the binding:
>>>>>>>
>>>>>>> Why each GPIO is represented with the separate node? I think rpmsg-gpio
>>>>>>> can be represented just any other GPIO controller? Please let me know if
>>>>>>> I am missing something. So rpmsg channel/rpmsg device is not created per
>>>>>>> GPIO, but per controller. GPIO number multiplexing should be done with
>>>>>>> rpmsg src ept, that removes the need of having each GPIO as a separate
>>>>>>> node.
>>>>>>>
>>>>>>>
>>>>>>> rpmsg_gpio: rpmsg-gpio@0 {
>>>>>>> compatible = "rpmsg-gpio";
>>>>>>> reg = <0>;
>>>>>>> gpio-controller;
>>>>>>> #gpio-cells = <2>;
>>>>>>> #interrupt-cells = <2>;
>>>>>>> interrupt-controller;
>>>>>>> };
>>>>>>>
>>>>>>> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
>>>>>>>
>>>>>>> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
>>>>>>>
>>>>>>> If the intent to create separate gpio nodes was only for the channel
>>>>>>> creation, then it's not really needed.
>>>>>>>
>>>>>>> [1]
>>>>>>> https://github.com/torvalds/linux/
>>>>>>> blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/
>>>>>>> virtio_rpmsg_bus.c#L136
>>>>>>>
>>>>>>
>>>>>> It is already the case. bindings declare GPIO controllers, not directly
>>>>>> GPIOs in:
>>>>>>
>>>>>> [PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
>>>>>> support
>>>>>>
>>>>>> The discussion is around having an unique RPmsg endpoint for all
>>>>>> GPIO controller or one RPmsg endpoint per GPIO controller.
>>>>>>
>>>>>
>>>>> Endpoint where remote side or linux side?
>>>>>
>>>>> If unique endpoint on remote side per gpio controller then it makes sense.
>>>>>
>>>>> Unique endpoint on linux side doesn't make sense. Instead, unique
>>>>> channel per gpio controller makes sense, and each channel will have
>>>>> multiple endpoints on linux side. As I replied to Beleswar on the other
>>>>> email, I will copy past my answer here too:
>>>>>
>>>>>
>>>>> To be more specific:
>>>>>
>>>>> Linux: remote:
>>>>>
>>>>> ch1: rpmsg-gpio.-1.1024 -> gpio-controller@1024
>>>>> - gpio-line ept1
>>>>> - gpio-line ept2 -> They all map to same callback_ept_1024.
>>>>> - gpio-line ept3
>>>>>
>>>>> ch2: rpmsg-gpio.-1.1025 -> gpio-controller@1025
>>>>> - gpio-line ept1
>>>>> - gpio-line ept2 -> They all map to same callback_ept_1025.
>>>>> - gpio-line ept3
>>>>>
>>>>
>>>>
>>>> Hi Mathieu,
>>>>
>>>> So upon more brain storming in this approach I found limitation:
>>>>
>>>> This approach won't work if host OS is any other OS but Linux. For
>>>> example, if the remote OS is zephyr/baremetal using open-amp, then Only
>>>> Linux <-> zephyr combination will work, and we won't be able to re-use
>>>> this approach for zephyr <-> zephyr use case. The concept of rpmsg
>>>> channel/device exist only in the linux kernel implementation. This
>>>> brings another question: Should the protocol we decide work on other use
>>>> cases as well? Or Linux must be the Host OS for this protocol ?
>>>>
>>>
>>> Linux and Zephyr are very distinct OS, each with their own subsystems
>>> and characteristics. The design we choose here involves RPMSG and,
>>> inherently, Linux. We can't make decisions based on what may
>>> potentially happen in Zephyr.
>>>
>>>>
>>>> I think your & Arnaud's proposed approach of single endpoint per
>>>> gpio-controller on both side makes more sense, as it will work
>>>> regardless of any OS on host or remote side.
>>>>
>>>
>>> Arnaud, Beleswar, Andrew and I are all advocating for one endpoint per
>>> GPIO controller. The remaining issue it about the best way to work
>>> out source and destination addresses between Linux and the remote
>>> processor. I'm running out of time for today but I'll return to this
>>> thread with a final analysis by the end of the week.
>>>
>>
>> Okay. Then that means multiple endpoints on Linux side can be considered.
>
> If there are multiple GPIO controllers then yes, there will be more than one
> endpoint. At this time I do now want to condiser other bus architectures (i2c,
> spi, ...) to avoid muddying an already difficult conversation.
>
>>
>> If we decide to go single-endpoint per device on both side, then for
>> that here is the proposal to represent src ept and dst ept:
>
> I do not understand what you mean by "per device" - please be more specific.
>
"per device" I mean, per rpmsg device/channel. In our case that would be
per gpio-controller.
>>
>> When we represent any device under rpmsg bus node, I think it should be
>> considered remote's view of the adddress space. So ideally we can
>> convert it to Linux view of the address space, via 'ranges' property.
>
> There is no address space to consider since there is no GPIO controller memory
> space to access. All that is done by the driver (remote processor) and
> completely hidden from Linux by rpmsg-virtio-gpio.
>
So IMHO the dt-binding is the representation of the device hardware and
is independent of how driver will access it. Any gpio-controller device
node, we are just representing how gpio-controller hardware on the
remote side looks like, and what is the corresponding view of the linux is.
The rpmsg-gpio driver is different than the platform gpio controller
driver mainly in two ways:
1) How the driver is probed: rpmsg-gpio driver will be probed when
corresponding rpmsg channel/device name-service announcment will happen
from the remote side.
2) The GPIO Ops are not performed on the hardware directly, but it's
done via rpmsg commands on the remote side.
However, the GPIO controller hardware remains the same. So bindings
shoudln't change.
IMHO That means, if I want to move any existing GPIO-controller to the
remote side, and want the rpmsg-gpio driver to handle it then, all I
need to change is the compatible string of the current gpio-controller
device node. The rest of the address space should remain the same, and
leave ranges property empty. If the remote core has different view of
the address space, then the device should contain remote's view and
parent bus (rpmsg-io bus) should provide linux view via 'ranges' property.
That is just the device hw representation in the device-tree as rpmsg
device. Same for any other type of the controller: i2c, spi etc.
Thanks,
Tanmay
>>
>> So bindings should include 'ranges' property in the parent node. Then
>> linux view of the start address becomes src ept, and remote view of the
>> start address becomes dest ept. The remote view of the start address is
>> expected to be the static src endpoint on the remote side.
>>
>> Following representation of the rpmsg devices (gpio, i2c, spi or any other):
>>
>> rpmsg {
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> rpmsg-io {
>> compatible = "rpmsg-io-bus";
>> ranges = <remote_view_addr(dst ept) linux_view_addr(src ept) size>;
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> gpio@remote_view_addr(or dst ept) {
>> compatible = "rpmsg-io";
>> reg = <remote_view_addr addr_space_size>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> };
>>
>> ...
>>
>> };
>>
>> };
>>
>> Example device-tree:
>>
>> rpmsg {
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> rpmsg-io {
>> compatible = "rpmsg-io-bus";
>> ranges = <0x10000 0x50000 0x1000>,
>> <0x20000 0x60000 0x1000>;
>> #address-cells = <1>;
>> #size-cells = <1>;
>>
>> gpio@10000 {
>> compatible = "rpmsg-io";
>> reg = <0x10000 0x1000>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> };
>>
>> gpio@20000 {
>> compatible = "rpmsg-io";
>> reg = <0x20000 0x1000>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> interrupt-controller;
>> #interrupt-cells = <2>;
>> };
>>
>> };
>>
>> };
>>
>>
>> Thanks,
>> Tanmay
>>
>>
>>>> To be more specific this will look like following:
>>>>
>>>> Host (Linux) Remote (baremetal/RTOS)
>>>>
>>>> rpmsg ch/device 1:
>>>> - rpmsg ept 1 <------> rpmsg ept 1 gpio-controller 0
>>>>
>>>> rpmsg ch/device 2:
>>>> - rpmsg ept 2 <------> rpmsg ept 2 gpio-controller 1
>>>>
>>>>
>>>> The question is, how to decide src ept, and dest ept on both sides?
>>>> I still think it should be static endpoints.
>>>>
>>>> I will get back with more reasoning on that.
>>>>
>>>>> On the remote side, we have to hardcode Which rpmsg controller is mapped
>>>>> to which endpoint.
>>>>>
>>>>>> Or did I misunderstand your questions?
>>>>>>
>>>>>> Thanks,
>>>>>> Arnaud
>>>>>>
>>>>>
>>>>>
>>>>> I gave this patch more time yesterday, and I think the 'reg' property
>>>>> should represent remote endpoint, instead of the gpio-controller index.
>>>>>
>>>>> So in this approach remote implementation is expected to provide
>>>>> hard-coded (static) endpoints for each gpio-controller instance, and
>>>>> that same number should be represented with the 'reg' property.
>>>>>
>>>>> On remote side:
>>>>>
>>>>> #define RPMSG_GPIO_0_CONTROLLER_EPT (RPMSG_RESERVED_ADDRESSES + 1) // 1024
>>>>>
>>>>> ept_1024_callback() {
>>>>>
>>>>> // handle appropriate gpio port ()
>>>>>
>>>>> }
>>>>>
>>>>> On linux side:
>>>>>
>>>>> So new representation of controller:
>>>>>
>>>>> rpmsg_gpio_0: gpio@1024 {
>>>>> compatible = "rpmsg-gpio";
>>>>> reg = <1024>;
>>>>> gpio-controller;
>>>>> #gpio-cells = <2>;
>>>>> #interrupt-cells = <2>;
>>>>> interrupt-controller;
>>>>> };
>>>>>
>>>>> rpmsg_gpio_1: gpio@1025 {
>>>>> compatible = "rpmsg-gpio";
>>>>> reg = <1025>;
>>>>> gpio-controller;
>>>>> #gpio-cells = <2>;
>>>>> #interrupt-cells = <2>;
>>>>> interrupt-controller;
>>>>> };
>>>>>
>>>>> gpios = <&rpmsg_gpio_0 (GPIO NUM or PIN) flags>,
>>>>> <&rpmsg_gpio_1 (GPIO NUM or PIN) flags>;
>>>>>
>>>>> Now in the linux driver:
>>>>>
>>>>> You can easily retrieve destination endpoint when we want to send the
>>>>> command to the gpio controller via device's "reg" property.
>>>>>
>>>>> This approach also provides built-in security as well. Because now
>>>>> gpio-controller instance is hardcoded with the endpoint callback, it
>>>>> can't be modified/addressed without changing the 'reg' property.
>>>>>
>>>>> Just like you wouldn't change device address for the instance of the
>>>>> gpio-controller right?
>>>>>
>>>>> This approach can be easily adapted to all the other rpmsg controllers
>>>>> as well.
>>>>>
>>>>> So, dynamic endpoint allocation doesn't make sense in this case. Dynamic
>>>>> endpoint allocation makes more sense for user-space apps which don't
>>>>> really care about endpoints and only payloads.
>>>>>
>>>>> But, here we are multiplexing device-addresses with endpoints, and so it
>>>>> has to be fixed, and presented via 'reg' property. So, firmware can't
>>>>> change device-address without Linux knowing it.
>>>>>
>>>>> Thanks,
>>>>> Tanmay
>>>>>
>>>>>
>>>>>>
>>>>>>>>>>>> This way device groups are isolated with each channel/namespace, and
>>>>>>>>>>>> instances within each device groups are also respected with specific
>>>>>>>>>>>> endpoints.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Beleswar
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: amlogic: t7: Fix pwm_ao_c pinmux definitions
From: Ronald Claveau via B4 Relay @ 2026-05-12 17:47 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Ronald Claveau
In-Reply-To: <20260512-add-kvim4-sysled-v1-0-7178719a43e7@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
The pwm_ao_c pin node was incomplete: it was missing the group name
suffix, conflating two distinct pin groups (pwm_ao_c_d and pwm_ao_c_e)
into a single, ambiguous entry.
Split the node into two separate pinmux entries:
- pwm_ao_c_d_pins: uses group "pwm_ao_c_d"
- pwm_ao_c_e_pins: uses group "pwm_ao_c_e"
Both alternate pins are not yet referenced by any peripheral node,
so this has no functional impact on existing boards. No backport needed.
Fixes: ee6e05a49b93 ("arm64: dts: amlogic: t7: Add PWM pinctrl nodes")
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 7fe72c94ed623..62f6b9baad28b 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -400,9 +400,17 @@ mux {
};
};
- pwm_ao_c_pins: pwm-ao-c {
+ pwm_ao_c_d_pins: pwm-ao-c-d {
mux {
- groups = "pwm_ao_c";
+ groups = "pwm_ao_c_d";
+ function = "pwm_ao_c";
+ bias-disable;
+ };
+ };
+
+ pwm_ao_c_e_pins: pwm-ao-c-e {
+ mux {
+ groups = "pwm_ao_c_e";
function = "pwm_ao_c";
bias-disable;
};
--
2.49.0
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: amlogic: t7: khadas-vim4: add PWM-driven status LED
From: Ronald Claveau via B4 Relay @ 2026-05-12 17:47 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Ronald Claveau
In-Reply-To: <20260512-add-kvim4-sysled-v1-0-7178719a43e7@aliel.fr>
From: Ronald Claveau <linux-kernel-dev@aliel.fr>
The VIM4 board exposes a status LED wired to the PWM_AO_C_D output.
Enable the pwm_ao_cd controller with its pinmux, and declare a
pwm-leds node with a heartbeat trigger.
Also, move the xtal-clk node to restore alphabetical ordering.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 30 +++++++++++++++++-----
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
index 69d6118ba57e7..c41525a34b721 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts
@@ -45,13 +45,6 @@ secmon_reserved_bl32: secmon@5300000 {
};
};
- xtal: xtal-clk {
- compatible = "fixed-clock";
- clock-frequency = <24000000>;
- clock-output-names = "xtal";
- #clock-cells = <0>;
- };
-
dc_in: regulator-dc-in {
compatible = "regulator-fixed";
regulator-name = "DC_IN";
@@ -60,6 +53,16 @@ dc_in: regulator-dc-in {
regulator-always-on;
};
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ status {
+ linux,default-trigger="heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm_ao_cd 0 30040 0>;
+ };
+ };
+
sd_3v3: regulator-sdcard-3v3 {
compatible = "regulator-fixed";
regulator-name = "SD_3V3";
@@ -155,6 +158,13 @@ wifi32k: wifi32k {
clock-frequency = <32768>;
pwms = <&pwm_ab 0 30518 0>;
};
+
+ xtal: xtal-clk {
+ compatible = "fixed-clock";
+ clock-frequency = <24000000>;
+ clock-output-names = "xtal";
+ #clock-cells = <0>;
+ };
};
&pwm_ab {
@@ -163,6 +173,12 @@ &pwm_ab {
pinctrl-names = "default";
};
+&pwm_ao_cd {
+ status = "okay";
+ pinctrl-0 = <&pwm_ao_c_d_pins>;
+ pinctrl-names = "default";
+};
+
/* SDIO */
&sd_emmc_a {
status = "okay";
--
2.49.0
^ permalink raw reply related
* [PATCH 0/2] Khadas VIM4 PWM status LED support
From: Ronald Claveau via B4 Relay @ 2026-05-12 17:47 UTC (permalink / raw)
To: Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, devicetree, linux-kernel,
Ronald Claveau
This series adds support for the PWM-driven status LED on the Khadas
VIM4 board (Amlogic T7).
The VIM4 exposes a heartbeat LED wired to the PWM_AO_C output, routed
through pin group pwm_ao_c_d. Before wiring it up in the board DTS,
the SoC pinmux definitions had to be corrected: the original
pwm_ao_c node was conflating two distinct pin groups (pwm_ao_c_d and
pwm_ao_c_e) into a single ambiguous entry.
Patch 1 fixes the pwm_ao_c pinmux entries in the T7 DTSI by splitting
them into two properly named nodes. Neither alternate is in use yet,
so there is no functional impact on existing boards.
Patch 2 enables the pwm_ao_cd controller on the VIM4 and adds a
pwm-leds node with a heartbeat trigger. The xtal-clk node is also
moved to restore alphabetical ordering among root node children.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Ronald Claveau (2):
arm64: dts: amlogic: t7: Fix pwm_ao_c pinmux definitions
arm64: dts: amlogic: t7: khadas-vim4: add PWM-driven status LED
.../dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dts | 30 +++++++++++++++++-----
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 12 +++++++--
2 files changed, 33 insertions(+), 9 deletions(-)
---
base-commit: 31f32e8cdf59291e467250dfc57d1a8c718f63d2
change-id: 20260512-add-kvim4-sysled-8cc159524561
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* Re: [PATCH net-next v6 11/12] net: airoha: Support multiple LAN/WAN interfaces for hw MAC address configuration
From: Benjamin Larsson @ 2026-05-12 17:49 UTC (permalink / raw)
To: Lorenzo Bianconi, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Christian Marangi, linux-arm-kernel, linux-mediatek, netdev,
devicetree, Madhur Agrawal
In-Reply-To: <20260511-airoha-eth-multi-serdes-v6-11-c899462c4f75@kernel.org>
Hi.
On 11/05/2026 12:49, Lorenzo Bianconi wrote:
> The EN7581 and AN7583 SoCs provide registers to configure hardware LAN/WAN
> MAC addresses, used to determine whether received traffic is destined for
> this host or should be forwarded to another device.
> The SoC hardware design assumes all interfaces configured as LAN (or WAN)
> share a common upper MAC address, which is programmed into the
> REG_FE_{LAN,WAN}_MAC_H register. The lower bytes of 'local' addresses can
> be expressed as a range via the REG_FE_MAC_LMIN and REG_FE_MAC_LMAX
> registers.
> Previously, only a single interface was considered when programming these
> registers. Extend the logic to derive the correct minimum and maximum
> values for REG_FE_MAC_LMIN/REG_FE_MAC_LMAX when two or more interfaces are
> configured as LAN or WAN.
>
> Tested-by: Madhur Agrawal <madhur.agrawal@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
> ---
> drivers/net/ethernet/airoha/airoha_eth.c | 75 +++++++++++++++++++++++++++-----
> drivers/net/ethernet/airoha/airoha_eth.h | 2 +-
> drivers/net/ethernet/airoha/airoha_ppe.c | 4 +-
> 3 files changed, 66 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 16c0ff9999da..533ffe20f833 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -71,20 +71,67 @@ static void airoha_qdma_irq_disable(struct airoha_irq_bank *irq_bank,
> airoha_qdma_set_irqmask(irq_bank, index, mask, 0);
> }
>
> -static void airoha_set_macaddr(struct airoha_gdm_dev *dev, const u8 *addr)
> +static int airoha_set_macaddr(struct airoha_gdm_dev *dev, const u8 *addr)
> {
> struct airoha_eth *eth = dev->eth;
> - u32 val, reg;
> + u8 ref_addr[ETH_ALEN] = {};
> + u32 reg, val, lmin, lmax;
> + int i;
> +
> + lmin = (addr[3] << 16) | (addr[4] << 8) | addr[5];
> + lmax = lmin;
> +
> + for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
> + struct airoha_gdm_port *port = eth->ports[i];
> + int j;
> +
> + if (!port)
> + continue;
> +
> + for (j = 0; j < ARRAY_SIZE(port->devs); j++) {
> + struct airoha_gdm_dev *iter_dev;
> + struct net_device *netdev;
> +
> + iter_dev = port->devs[j];
> + if (!iter_dev || iter_dev == dev)
> + continue;
> +
> + if (airoha_is_lan_gdm_dev(iter_dev) !=
> + airoha_is_lan_gdm_dev(dev))
> + continue;
> +
> + netdev = iter_dev->dev;
> + if (netdev->reg_state != NETREG_REGISTERED)
> + continue;
> +
> + ether_addr_copy(ref_addr, netdev->dev_addr);
> + val = (netdev->dev_addr[3] << 16) |
> + (netdev->dev_addr[4] << 8) | netdev->dev_addr[5];
> + if (val < lmin)
> + lmin = val;
> + if (val > lmax)
> + lmax = val;
> + }
> + }
> +
> + if (!is_zero_ether_addr(ref_addr) && memcmp(ref_addr, addr, 3)) {
> + /* According to the HW design, hw mac address MS bits
> + * must be the same for each net_device with the same
> + * LAN/WAN configuration.
> + */
> + return -EINVAL;
> + }
Maybe this information should be relayed to the user somehow?
MvH
Benjamin Larsson
^ permalink raw reply
* [PATCH 0/2] ARM: dts: aspeed: Add ASRock Rack B650D4U support
From: Prasanth Kumar Padarthi @ 2026-05-12 17:50 UTC (permalink / raw)
To: joel, andrew
Cc: robh, krzk+dt, conor+dt, devicetree, linux-aspeed,
linux-arm-kernel, Prasanth Kumar Padarthi
This series adds initial device tree support for the ASRock Rack
B650D4U BMC, which is based on the ASPEED AST2600 SoC.
The B650D4U is a server motherboard for AMD Ryzen processors. Hardware
details were extracted via reverse engineering of vendor firmware.
Hardware features included:
- UART5 Console
- MAC0 (RGMII) for dedicated management LAN
- I2C7 for FRU EEPROM
- FMC/SPI 64MB Flash layout
Validation:
Logic has been verified against the AST2600 v1.5 datasheet. The DTS
successfully compiles and was tested using QEMU (ast2600-evb) to verify
serial console output and board identification.
QEMU Boot Log Snippet:
---
[ 0.000000] OF: fdt: Machine model: ASRock Rack B650D4U BMC
[ 1.085143] 1e784000.serial: ttyS4 at MMIO 0x1e784000 (irq = 31) is a 16550A
[ 1.090566] printk: legacy console [ttyS4] enabled
---
Full logs and reverse-engineering data are maintained at:
https://github.com/prasanthp20/asrock-b650d4u-bmc-support/blob/main/qemu-boot.log
Prasanth Kumar Padarthi (2):
dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
ARM: dts: aspeed: Add ASRock Rack B650D4U BMC
.../bindings/arm/aspeed/aspeed.yaml | 1 +
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-asrock-b650d4u.dts | 61 +++++++++++++++++++
3 files changed, 63 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
--
2.47.3
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: aspeed: Add ASRock Rack B650D4U
From: Prasanth Kumar Padarthi @ 2026-05-12 17:50 UTC (permalink / raw)
To: joel, andrew
Cc: robh, krzk+dt, conor+dt, devicetree, linux-aspeed,
linux-arm-kernel, Prasanth Kumar Padarthi
In-Reply-To: <20260512175019.47548-1-prasanth.padarthi10@gmail.com>
Add the compatible string for the ASRock Rack B650D4U BMC,
which is an AST2600-based server motherboard.
Signed-off-by: Prasanth Kumar Padarthi <prasanth.padarthi10@gmail.com>
---
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 2f92b8ab0..656397850 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -77,6 +77,7 @@ properties:
- ampere,mtmitchell-bmc
- aspeed,ast2600-evb
- aspeed,ast2600-evb-a1
+ - asrock,b650d4u-bmc
- asus,x4tf-bmc
- facebook,bletchley-bmc
- facebook,catalina-bmc
--
2.47.3
^ permalink raw reply related
* [PATCH 2/2] ARM: dts: aspeed: Add ASRock Rack B650D4U BMC
From: Prasanth Kumar Padarthi @ 2026-05-12 17:50 UTC (permalink / raw)
To: joel, andrew
Cc: robh, krzk+dt, conor+dt, devicetree, linux-aspeed,
linux-arm-kernel, Prasanth Kumar Padarthi
In-Reply-To: <20260512175019.47548-1-prasanth.padarthi10@gmail.com>
Add initial device tree support for the ASRock Rack B650D4U BMC.
The B650D4U is a server motherboard utilizing the ASPEED AST2600
SoC for management.
Signed-off-by: Prasanth Kumar Padarthi <prasanth.padarthi10@gmail.com>
---
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-asrock-b650d4u.dts | 61 +++++++++++++++++++
2 files changed, 62 insertions(+)
create mode 100644 arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index c4f064e4b..124d4f8f8 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -13,6 +13,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-asrock-romed8hm3.dtb \
aspeed-bmc-asrock-spc621d8hm3.dtb \
aspeed-bmc-asrock-x570d4u.dtb \
+ aspeed-bmc-asrock-b650d4u.dtb \
aspeed-bmc-asus-x4tf.dtb \
aspeed-bmc-bytedance-g220a.dtb \
aspeed-bmc-delta-ahe50dc.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
new file mode 100644
index 000000000..d0b9c1e1f
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asrock-b650d4u.dts
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/gpio/aspeed-gpio.h> // Recommended for GPIO mapping
+
+/ {
+ model = "ASRock Rack B650D4U BMC";
+ compatible = "asrock,b650d4u-bmc", "aspeed,ast2600";
+
+ aliases {
+ serial4 = &uart5;
+ };
+
+ chosen {
+ stdout-path = "serial4:115200n8";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x40000000>;
+ };
+};
+
+/* BMC Console UART */
+&uart5 {
+ status = "okay";
+};
+
+/* SPI Flash Management */
+&fmc {
+ status = "okay";
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ };
+};
+
+/* Dedicated Management LAN */
+&mac0 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii1_default &pinctrl_mdio1_default>;
+};
+
+/* I2C Bus for FRU/EEPROM Storage */
+&i2c7 {
+ status = "okay";
+ eeprom@57 {
+ compatible = "atmel,24c02";
+ reg = <0x57>;
+ pagesize = <16>;
+ };
+};
+
+/* System Watchdog */
+&wdt1 {
+ status = "okay";
+ aspeed,reset-type = "soc";
+};
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 1/3] iio: adc: xilinx-ams: fix out-of-bounds channel lookup in event handling
From: Salih Erim @ 2026-05-12 18:05 UTC (permalink / raw)
To: Jonathan Cameron, Guilherme Ivo Bozi
Cc: Conall O'Griofa, Michal Simek, David Lechner, Nuno Sá,
Andy Shevchenko, linux-iio, linux-arm-kernel, linux-kernel
In-Reply-To: <20260512165444.4ae39d90@jic23-huawei>
Hi Jonathan,
>> I could not observe any indentation issues locally or from the raw mbox.
> FWIW they look good to me as well. Salih, I'd guess you have a local issue.
> b4 (on git.kernel.org) is really handy for ensuring none of those occur!
You are right, apologies for the noise. The tabs were converted to
spaces by my email client during export. I will use b4 for patch
retrieval going forward.
There is still the u32 dead code issue in patch 3/3
(event < 0 check on a u32 parameter in ams_event_to_channel()),
Guilherme has acknowledged.
I am currently testing the series on ZCU102 hardware. Will follow up
with my Reviewed-by and Tested-by tags on the v4.
Salih
>
> Jonathan
>
>>
>>>
>>> Salih
>>>
>>
>> --
>> Guilherme Ivo
>
^ permalink raw reply
* Re: [PATCH v3 4/7] gpio: regmap: Add set_config callback
From: Andy Shevchenko @ 2026-05-12 18:12 UTC (permalink / raw)
To: Yu-Chun Lin
Cc: linusw, brgl, robh, krzk+dt, conor+dt, afaerber, wbg,
mathieu.dubois-briand, mwalle, lars, Michael.Hennerich, jic23,
nuno.sa, andy, dlechner, tychang, linux-gpio, devicetree,
linux-kernel, linux-arm-kernel, linux-realtek-soc, linux-iio,
cy.huang, stanley_chang, james.tai
In-Reply-To: <20260512033317.1602537-5-eleanor.lin@realtek.com>
On Tue, May 12, 2026 at 11:33:14AM +0800, Yu-Chun Lin wrote:
> Add a new set_config callback to struct gpio_regmap_config to allow drivers
> to implement hardware-specific configuration such as debounce settings,
> or other platform-specific GPIO properties.
Okay, if it's needed...
Reviewed-by: Andy Shevchenko <andriy.shevchenko@intel.com>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/1] dt-bindings: display: imx: add deprecated property 'port' and 'display-timings'
From: Frank Li @ 2026-05-12 18:21 UTC (permalink / raw)
To: Conor Dooley
Cc: Philipp Zabel, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam,
open list:DRM DRIVERS FOR FREESCALE IMX 5/6,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
open list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
moderated list:ARM/FREESCALE IMX / MXC ARM ARCHITECTURE,
open list
In-Reply-To: <20260512-surgery-operative-046a90f84ef8@spud>
On Tue, May 12, 2026 at 05:47:11PM +0100, Conor Dooley wrote:
> On Mon, May 11, 2026 at 06:09:24PM -0400, Frank Li wrote:
> > Add deprecated property 'port' and 'display-timings' for i.MX5 SoCs (over
> > 15 years) to fix below CHECK_DTBS warnings:
> > arm/boot/dts/nxp/imx/imx51-apf51dev.dtb: disp1 (fsl,imx-parallel-display): 'display-timings', 'port' do not match any of the regexes: '^pinctrl-[0-9]+$'
> > from schema $id: http://devicetree.org/schemas/display/imx/fsl,imx-parallel-display.yaml
>
> Instead of documenting the deprecated properties, could this
> device/devicetree be converted to non-deprecated properties?
Change dts will cause break back compatiblity. This is too old chips and
I have not information panel's detail information.
Frank
>
> >
> > Signed-off-by: Frank Li <Frank.Li@nxp.com>
> > ---
> > .../display/imx/fsl,imx-parallel-display.yaml | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml b/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
> > index bbcfe7e2958b7..b0c5869771fae 100644
> > --- a/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
> > +++ b/Documentation/devicetree/bindings/display/imx/fsl,imx-parallel-display.yaml
> > @@ -42,6 +42,17 @@ properties:
> > unevaluatedProperties: false
> > description: output port connected to a panel
> >
> > + port:
> > + $ref: /schemas/graph.yaml#/properties/port
> > + unevaluatedProperties: false
> > + deprecated: true
> > + description: input port connected to the IPU display interface, see port@0
> > +
> > + display-timings:
> > + $ref: /schemas/display/panel/display-timings.yaml#
> > + unevaluatedProperties: false
> > + deprecated: true
> > +
> > required:
> > - compatible
> >
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: aspeed: Add ASRock Rack B650D4U BMC
From: Andrew Lunn @ 2026-05-12 18:35 UTC (permalink / raw)
To: Prasanth Kumar Padarthi
Cc: joel, andrew, robh, krzk+dt, conor+dt, devicetree, linux-aspeed,
linux-arm-kernel
In-Reply-To: <20260512175019.47548-3-prasanth.padarthi10@gmail.com>
> +/* Dedicated Management LAN */
> +&mac0 {
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_rgmii1_default &pinctrl_mdio1_default>;
What does this connect to? A PHY? NCSI?
Andrew
^ 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