* Re: [PATCH 2/2] dts: riscv: spacemit: k3: Add i2c nodes
From: Yixun Lan @ 2026-03-27 2:39 UTC (permalink / raw)
To: Andi Shyti
Cc: Troy Mitchell, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
linux-i2c, devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <acWxqkR8Z0rwe4hI@zenone.zhora.eu>
Hi Andi,
On 23:23 Thu 26 Mar , Andi Shyti wrote:
> Hi Yixun,
>
> > > + i2c2: i2c@d4012000 {
> > > + compatible = "spacemit,k3-i2c", "spacemit,k1-i2c";
> > > + reg = <0x0 0xd4012000 0x0 0x38>;
> > > + #address-cells = <1>;
> > > + #size-cells = <0>;
> > > + interrupts = <38 IRQ_TYPE_LEVEL_HIGH>;
> > > + clocks = <&syscon_apbc CLK_APBC_TWSI2>,
> > > + <&syscon_apbc CLK_APBC_TWSI2_BUS>;
> > > + clock-names = "func", "bus";
> > > + clock-frequency = <400000>;
> > > + resets = <&syscon_apbc RESET_APBC_TWSI2>;
> > > + status = "disabled";
> > > + };
> > I think we should add a comment here to explain why there isn't i2c3.
> > Otherwise, LGTM.
>
> are you going to add a comment here?
>
I will explain and re-spin a v2, and add a short comment for this:
- i2c3 is reserved for secure domain which not available from linux
- i2c7 simply does not exist from hardware perspective, K3 SoC want to
keep align with K1 to use same index of I2C controller for the pmic
> > Reviewed-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>
--
Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH v12 2/7] qcom-tgu: Add TGU driver
From: Jie Gan @ 2026-03-27 2:35 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260317032639.2393221-3-songwei.chai@oss.qualcomm.com>
On 3/17/2026 11:26 AM, Songwei Chai wrote:
> Add driver to support device TGU (Trigger Generation Unit).
> TGU is a Data Engine which can be utilized to sense a plurality of
> signals and create a trigger into the CTI or generate interrupts to
> processors. Add probe/enable/disable functions for tgu.
>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 9 +
> drivers/Makefile | 1 +
> drivers/hwtracing/Kconfig | 2 +
> drivers/hwtracing/qcom/Kconfig | 18 ++
> drivers/hwtracing/qcom/Makefile | 3 +
> drivers/hwtracing/qcom/tgu.c | 183 ++++++++++++++++++
> drivers/hwtracing/qcom/tgu.h | 51 +++++
> 7 files changed, 267 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> create mode 100644 drivers/hwtracing/qcom/Kconfig
> create mode 100644 drivers/hwtracing/qcom/Makefile
> create mode 100644 drivers/hwtracing/qcom/tgu.c
> create mode 100644 drivers/hwtracing/qcom/tgu.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> new file mode 100644
> index 000000000000..ead237bb7d89
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -0,0 +1,9 @@
> +What: /sys/bus/amba/devices/<tgu-name>/enable_tgu
> +Date: March 2026
> +KernelVersion 7.1
missed ":" in all patches.
Thanks,
Jie
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (RW) Set/Get the enable/disable status of TGU
> + Accepts only one of the 2 values - 0 or 1.
> + 0 : disable TGU.
> + 1 : enable TGU.
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 53fbd2e0acdd..82b712a12a26 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -177,6 +177,7 @@ obj-$(CONFIG_RAS) += ras/
> obj-$(CONFIG_USB4) += thunderbolt/
> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
> obj-y += hwtracing/intel_th/
> +obj-y += hwtracing/qcom/
> obj-$(CONFIG_STM) += hwtracing/stm/
> obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
> obj-y += android/
> diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
> index 911ee977103c..8a640218eed8 100644
> --- a/drivers/hwtracing/Kconfig
> +++ b/drivers/hwtracing/Kconfig
> @@ -7,4 +7,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>
> source "drivers/hwtracing/ptt/Kconfig"
>
> +source "drivers/hwtracing/qcom/Kconfig"
> +
> endmenu
> diff --git a/drivers/hwtracing/qcom/Kconfig b/drivers/hwtracing/qcom/Kconfig
> new file mode 100644
> index 000000000000..d6f6d4b0f28e
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Kconfig
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# QCOM specific hwtracing drivers
> +#
> +menu "Qualcomm specific hwtracing drivers"
> +
> +config QCOM_TGU
> + tristate "QCOM Trigger Generation Unit driver"
> + help
> + This driver provides support for Trigger Generation Unit that is
> + used to detect patterns or sequences on a given set of signals.
> + TGU is used to monitor a particular bus within a given region to
> + detect illegal transaction sequences or slave responses. It is also
> + used to monitor a data stream to detect protocol violations and to
> + provide a trigger point for centering data around a specific event
> + within the trace data buffer.
> +
> +endmenu
> diff --git a/drivers/hwtracing/qcom/Makefile b/drivers/hwtracing/qcom/Makefile
> new file mode 100644
> index 000000000000..5a0a868c1ea0
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_QCOM_TGU) += tgu.o
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> new file mode 100644
> index 000000000000..58c19f12f3d7
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -0,0 +1,183 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/amba/bus.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm_runtime.h>
> +
> +#include "tgu.h"
> +
> +static void tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + /* Enable TGU to program the triggers */
> + writel(1, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +}
> +
> +static int tgu_enable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (drvdata->enabled)
> + return -EBUSY;
> +
> + tgu_write_all_hw_regs(drvdata);
> + drvdata->enabled = true;
> +
> + return 0;
> +}
> +
> +static void tgu_do_disable(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + writel(0, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +
> + drvdata->enabled = false;
> +}
> +
> +static void tgu_disable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (!drvdata->enabled)
> + return;
> +
> + tgu_do_disable(drvdata);
> +}
> +
> +static ssize_t enable_tgu_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + bool enabled;
> +
> + guard(spinlock)(&drvdata->lock);
> + enabled = drvdata->enabled;
> +
> + return sysfs_emit(buf, "%d\n", !!enabled);
> +}
> +
> +/* enable_tgu_store - Configure Trace and Gating Unit (TGU) triggers. */
> +static ssize_t enable_tgu_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t size)
> +{
> + unsigned long val;
> + int ret;
> +
> + ret = kstrtoul(buf, 0, &val);
> + if (ret || val > 1)
> + return -EINVAL;
> +
> + if (val) {
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
> + ret = tgu_enable(dev);
> + if (ret) {
> + pm_runtime_put(dev);
> + return ret;
> + }
> + } else {
> + tgu_disable(dev);
> + pm_runtime_put(dev);
> + }
> +
> + return size;
> +}
> +static DEVICE_ATTR_RW(enable_tgu);
> +
> +static struct attribute *tgu_common_attrs[] = {
> + &dev_attr_enable_tgu.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group tgu_common_grp = {
> + .attrs = tgu_common_attrs,
> + NULL,
> +};
> +
> +static const struct attribute_group *tgu_attr_groups[] = {
> + &tgu_common_grp,
> + NULL,
> +};
> +
> +static int tgu_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> + struct device *dev = &adev->dev;
> + struct tgu_drvdata *drvdata;
> + int ret;
> +
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> +
> + drvdata->dev = &adev->dev;
> + dev_set_drvdata(dev, drvdata);
> +
> + drvdata->base = devm_ioremap_resource(dev, &adev->res);
> + if (IS_ERR(drvdata->base))
> + return PTR_ERR(drvdata->base);
> +
> + spin_lock_init(&drvdata->lock);
> +
> + ret = sysfs_create_groups(&dev->kobj, tgu_attr_groups);
> + if (ret) {
> + dev_err(dev, "failed to create sysfs groups: %d\n", ret);
> + return ret;
> + }
> +
> + drvdata->enabled = false;
> +
> + pm_runtime_put(&adev->dev);
> +
> + return 0;
> +}
> +
> +static void tgu_remove(struct amba_device *adev)
> +{
> + struct device *dev = &adev->dev;
> +
> + sysfs_remove_groups(&dev->kobj, tgu_attr_groups);
> +
> + tgu_disable(dev);
> +}
> +
> +static const struct amba_id tgu_ids[] = {
> + {
> + .id = 0x000f0e00,
> + .mask = 0x000fffff,
> + },
> + { 0, 0, NULL },
> +};
> +
> +MODULE_DEVICE_TABLE(amba, tgu_ids);
> +
> +static struct amba_driver tgu_driver = {
> + .drv = {
> + .name = "qcom-tgu",
> + .suppress_bind_attrs = true,
> + },
> + .probe = tgu_probe,
> + .remove = tgu_remove,
> + .id_table = tgu_ids,
> +};
> +
> +module_amba_driver(tgu_driver);
> +
> +MODULE_AUTHOR("Songwei Chai <songwei.chai@oss.qualcomm.com>");
> +MODULE_AUTHOR("Jinlong Mao <jinlong.mao@oss.qualcomm.com>");
> +MODULE_DESCRIPTION("Qualcomm Trigger Generation Unit driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hwtracing/qcom/tgu.h b/drivers/hwtracing/qcom/tgu.h
> new file mode 100644
> index 000000000000..dd7533b9d735
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef _QCOM_TGU_H
> +#define _QCOM_TGU_H
> +
> +/* Register addresses */
> +#define TGU_CONTROL 0x0000
> +#define TGU_LAR 0xfb0
> +#define TGU_UNLOCK_OFFSET 0xc5acce55
> +
> +static inline void TGU_LOCK(void __iomem *addr)
> +{
> + do {
> + /* Wait for things to settle */
> + mb();
> + writel_relaxed(0x0, addr + TGU_LAR);
> + } while (0);
> +}
> +
> +static inline void TGU_UNLOCK(void __iomem *addr)
> +{
> + do {
> + writel_relaxed(TGU_UNLOCK_OFFSET, addr + TGU_LAR);
> + /* Make sure everyone has seen this */
> + mb();
> + } while (0);
> +}
> +
> +/**
> + * struct tgu_drvdata - Data structure for a TGU (Trigger Generator Unit)
> + * @base: Memory-mapped base address of the TGU device
> + * @dev: Pointer to the associated device structure
> + * @lock: Spinlock for handling concurrent access to private data
> + * @enabled: Flag indicating whether the TGU device is enabled
> + *
> + * This structure defines the data associated with a TGU device,
> + * including its base address, device pointers, clock, spinlock for
> + * synchronization, trigger data pointers, maximum limits for various
> + * trigger-related parameters, and enable status.
> + */
> +struct tgu_drvdata {
> + void __iomem *base;
> + struct device *dev;
> + spinlock_t lock;
> + bool enabled;
> +};
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v12 7/7] qcom-tgu: Add reset node to initialize
From: Jie Gan @ 2026-03-27 2:26 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260317032639.2393221-8-songwei.chai@oss.qualcomm.com>
On 3/17/2026 11:26 AM, Songwei Chai wrote:
> Add reset node to initialize the value of
> priority/condition_decode/condition_select/timer/counter nodes.
>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 7 ++
> drivers/hwtracing/qcom/tgu.c | 77 +++++++++++++++++++
> 2 files changed, 84 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> index 5370882333bc..1dcb8fb71cd9 100644
> --- a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -42,3 +42,10 @@ KernelVersion 7.1
> Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> Description:
> (RW) Set/Get the counter value with specific step for TGU.
> +
> +What: /sys/bus/amba/devices/<tgu-name>/reset_tgu
> +Date: March 2026
> +KernelVersion 7.1
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (Write) Write 1 to reset the dataset for TGU.
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> index 4539415571f6..e28e6d27cf56 100644
> --- a/drivers/hwtracing/qcom/tgu.c
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -410,8 +410,85 @@ static ssize_t enable_tgu_store(struct device *dev,
> }
> static DEVICE_ATTR_RW(enable_tgu);
>
> +/* reset_tgu_store - Reset Trace and Gating Unit (TGU) configuration. */
> +static ssize_t reset_tgu_store(struct device *dev,
> + struct device_attribute *attr, const char *buf,
> + size_t size)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + struct value_table *vt = drvdata->value_table;
> + u32 *cond_decode = drvdata->value_table->condition_decode;
> + bool need_pm_put = false;
> + unsigned long value;
> + int i, j, ret;
> +
> + if (kstrtoul(buf, 0, &value) || value != 1)
> + return -EINVAL;
> +
> + spin_lock(&drvdata->lock);
> + if (!drvdata->enabled) {
> + spin_unlock(&drvdata->lock);
> + ret = pm_runtime_resume_and_get(drvdata->dev);
> + if (ret)
> + return ret;
> + need_pm_put = true;
> + spin_lock(&drvdata->lock);
> + }
> +
> + tgu_do_disable(drvdata);
need_pm_put flag is not set when reset a enabled device. I think we also
need do pm_runtime_put after we did tgu_do_disable for an enabled device
because we have pm_runtime_resume_and_get while enabling it.
Thanks,
Jie
> +
> + if (vt->priority) {
> + size_t size = MAX_PRIORITY * drvdata->num_step *
> + drvdata->num_reg * sizeof(unsigned int);
> + memset(vt->priority, 0, size);
> + }
> +
> + if (vt->condition_decode) {
> + size_t size = drvdata->num_condition_decode *
> + drvdata->num_step * sizeof(unsigned int);
> + memset(vt->condition_decode, 0, size);
> + }
> +
> + /* Initialize all condition registers to NOT(value=0x1000000) */
> + for (i = 0; i < drvdata->num_step; i++) {
> + for (j = 0; j < drvdata->num_condition_decode; j++) {
> + cond_decode[calculate_array_location(drvdata, i,
> + TGU_CONDITION_DECODE, j)] = 0x1000000;
> + }
> + }
> +
> + if (vt->condition_select) {
> + size_t size = drvdata->num_condition_select *
> + drvdata->num_step * sizeof(unsigned int);
> + memset(vt->condition_select, 0, size);
> + }
> +
> + if (vt->timer) {
> + size_t size = (drvdata->num_step) * (drvdata->num_timer) *
> + sizeof(unsigned int);
> + memset(vt->timer, 0, size);
> + }
> +
> + if (vt->counter) {
> + size_t size = (drvdata->num_step) * (drvdata->num_counter) *
> + sizeof(unsigned int);
> + memset(vt->counter, 0, size);
> + }
> +
> + spin_unlock(&drvdata->lock);
> +
> + dev_dbg(dev, "Qualcomm-TGU reset complete\n");
> +
> + if (need_pm_put)
> + pm_runtime_put(drvdata->dev);
> +
> + return size;
> +}
> +static DEVICE_ATTR_WO(reset_tgu);
> +
> static struct attribute *tgu_common_attrs[] = {
> &dev_attr_enable_tgu.attr,
> + &dev_attr_reset_tgu.attr,
> NULL,
> };
>
^ permalink raw reply
* Re: [PATCH v5 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Hangxiang Ma @ 2026-03-27 2:23 UTC (permalink / raw)
To: Bryan O'Donoghue, Vinod Koul, Kishon Vijay Abraham I,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong
Cc: Bryan O'Donoghue, Vladimir Zapolskiy, linux-arm-msm,
linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <20260326-x1e-csi2-phy-v5-2-0c0fc7f5c01b@linaro.org>
On 3/26/2026 9:04 AM, Bryan O'Donoghue wrote:
> +#include <linux/delay.h>
> +#include <linux/interrupt.h>
> +#include <linux/io.h>
> +#include <linux/time64.h>
> +
> +#include "phy-qcom-mipi-csi2.h"
> +
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRLn(offset, n) ((offset) + 0x4 * (n))
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL0_PHY_SW_RESET BIT(0)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL5_CLK_ENABLE BIT(7)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_COMMON_PWRDN_B BIT(0)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL6_SHOW_REV_ID BIT(1)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_CTRL10_IRQ_CLEAR_CMD BIT(0)
> +#define CSIPHY_3PH_CMN_CSI_COMMON_STATUSn(offset, n) ((offset) + 0xb0 + 0x4 * (n))
>
Hi Bryan, one minor observation on the following macro:
CSIPHY_3PH_CMN_CSI_COMMON_STATUSn
The 0xb0 offset implicitly assumes a fixed distance between the
common_ctrl and common_status register blocks. This holds for the PHYs
covered by this series, but on some other platforms (e.g. Kaanapali,
Pakala) the offset differs.
That said, I think keeping this fixed value is reasonable for the scope
of the current PHY series, and it does help keep the macro set simple.
It might just be worth documenting this assumption (e.g. via a comment
or in the commit message).
Alternatively, if future PHY variants need to support different layouts,
this could be made more extensible by moving the status base offset into
the per-PHY data (similar to other register layout parameters). But I
don’t think that needs to block the current series.
Related patch before:
<https://lore.kernel.org/all/20260112-camss-extended-csiphy-macro-v2-1-ee7342f2aaf5@oss.qualcomm.com/>
Best Regards,
Hangxiang
^ permalink raw reply
* Re: [PATCH v12 2/7] qcom-tgu: Add TGU driver
From: Jie Gan @ 2026-03-27 2:16 UTC (permalink / raw)
To: Songwei Chai, andersson, alexander.shishkin, mike.leach,
konrad.dybcio, suzuki.poulose, james.clark, krzk+dt, conor+dt
Cc: linux-kernel, linux-arm-kernel, linux-arm-msm, coresight,
devicetree, gregkh
In-Reply-To: <20260317032639.2393221-3-songwei.chai@oss.qualcomm.com>
On 3/17/2026 11:26 AM, Songwei Chai wrote:
> Add driver to support device TGU (Trigger Generation Unit).
> TGU is a Data Engine which can be utilized to sense a plurality of
> signals and create a trigger into the CTI or generate interrupts to
> processors. Add probe/enable/disable functions for tgu.
>
> Signed-off-by: Songwei Chai <songwei.chai@oss.qualcomm.com>
> ---
> .../ABI/testing/sysfs-bus-amba-devices-tgu | 9 +
> drivers/Makefile | 1 +
> drivers/hwtracing/Kconfig | 2 +
> drivers/hwtracing/qcom/Kconfig | 18 ++
> drivers/hwtracing/qcom/Makefile | 3 +
> drivers/hwtracing/qcom/tgu.c | 183 ++++++++++++++++++
> drivers/hwtracing/qcom/tgu.h | 51 +++++
> 7 files changed, 267 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> create mode 100644 drivers/hwtracing/qcom/Kconfig
> create mode 100644 drivers/hwtracing/qcom/Makefile
> create mode 100644 drivers/hwtracing/qcom/tgu.c
> create mode 100644 drivers/hwtracing/qcom/tgu.h
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> new file mode 100644
> index 000000000000..ead237bb7d89
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-bus-amba-devices-tgu
> @@ -0,0 +1,9 @@
> +What: /sys/bus/amba/devices/<tgu-name>/enable_tgu
> +Date: March 2026
> +KernelVersion 7.1
> +Contact: Jinlong Mao <jinlong.mao@oss.qualcomm.com>, Songwei Chai <songwei.chai@oss.qualcomm.com>
> +Description:
> + (RW) Set/Get the enable/disable status of TGU
> + Accepts only one of the 2 values - 0 or 1.
> + 0 : disable TGU.
> + 1 : enable TGU.
> diff --git a/drivers/Makefile b/drivers/Makefile
> index 53fbd2e0acdd..82b712a12a26 100644
> --- a/drivers/Makefile
> +++ b/drivers/Makefile
> @@ -177,6 +177,7 @@ obj-$(CONFIG_RAS) += ras/
> obj-$(CONFIG_USB4) += thunderbolt/
> obj-$(CONFIG_CORESIGHT) += hwtracing/coresight/
> obj-y += hwtracing/intel_th/
> +obj-y += hwtracing/qcom/
> obj-$(CONFIG_STM) += hwtracing/stm/
> obj-$(CONFIG_HISI_PTT) += hwtracing/ptt/
> obj-y += android/
> diff --git a/drivers/hwtracing/Kconfig b/drivers/hwtracing/Kconfig
> index 911ee977103c..8a640218eed8 100644
> --- a/drivers/hwtracing/Kconfig
> +++ b/drivers/hwtracing/Kconfig
> @@ -7,4 +7,6 @@ source "drivers/hwtracing/intel_th/Kconfig"
>
> source "drivers/hwtracing/ptt/Kconfig"
>
> +source "drivers/hwtracing/qcom/Kconfig"
> +
> endmenu
> diff --git a/drivers/hwtracing/qcom/Kconfig b/drivers/hwtracing/qcom/Kconfig
> new file mode 100644
> index 000000000000..d6f6d4b0f28e
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Kconfig
> @@ -0,0 +1,18 @@
> +# SPDX-License-Identifier: GPL-2.0-only
> +#
> +# QCOM specific hwtracing drivers
> +#
> +menu "Qualcomm specific hwtracing drivers"
> +
> +config QCOM_TGU
> + tristate "QCOM Trigger Generation Unit driver"
> + help
> + This driver provides support for Trigger Generation Unit that is
> + used to detect patterns or sequences on a given set of signals.
> + TGU is used to monitor a particular bus within a given region to
> + detect illegal transaction sequences or slave responses. It is also
> + used to monitor a data stream to detect protocol violations and to
> + provide a trigger point for centering data around a specific event
> + within the trace data buffer.
> +
> +endmenu
> diff --git a/drivers/hwtracing/qcom/Makefile b/drivers/hwtracing/qcom/Makefile
> new file mode 100644
> index 000000000000..5a0a868c1ea0
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +obj-$(CONFIG_QCOM_TGU) += tgu.o
> diff --git a/drivers/hwtracing/qcom/tgu.c b/drivers/hwtracing/qcom/tgu.c
> new file mode 100644
> index 000000000000..58c19f12f3d7
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.c
> @@ -0,0 +1,183 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/amba/bus.h>
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm_runtime.h>
> +
> +#include "tgu.h"
> +
> +static void tgu_write_all_hw_regs(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + /* Enable TGU to program the triggers */
> + writel(1, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +}
> +
> +static int tgu_enable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (drvdata->enabled)
> + return -EBUSY;
> +
> + tgu_write_all_hw_regs(drvdata);
> + drvdata->enabled = true;
> +
> + return 0;
> +}
> +
> +static void tgu_do_disable(struct tgu_drvdata *drvdata)
> +{
> + TGU_UNLOCK(drvdata->base);
> + writel(0, drvdata->base + TGU_CONTROL);
> + TGU_LOCK(drvdata->base);
> +
> + drvdata->enabled = false;
> +}
> +
> +static void tgu_disable(struct device *dev)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> +
> + guard(spinlock)(&drvdata->lock);
> + if (!drvdata->enabled)
> + return;
> +
> + tgu_do_disable(drvdata);
> +}
> +
> +static ssize_t enable_tgu_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct tgu_drvdata *drvdata = dev_get_drvdata(dev);
> + bool enabled;
> +
> + guard(spinlock)(&drvdata->lock);
> + enabled = drvdata->enabled;
> +
> + return sysfs_emit(buf, "%d\n", !!enabled);
> +}
> +
> +/* enable_tgu_store - Configure Trace and Gating Unit (TGU) triggers. */
> +static ssize_t enable_tgu_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf,
> + size_t size)
> +{
> + unsigned long val;
> + int ret;
> +
> + ret = kstrtoul(buf, 0, &val);
> + if (ret || val > 1)
> + return -EINVAL;
> +
> + if (val) {
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
> + ret = tgu_enable(dev);
> + if (ret) {
> + pm_runtime_put(dev);
> + return ret;
> + }
> + } else {
> + tgu_disable(dev);
> + pm_runtime_put(dev);
Sorry I didnt observe this issue with my previous check.
echo 0 to the disabled device will result in the pm_runtime reference
number goes to negative. We dont need pm_runtime_put(dev) when we try to
disable a diabled device.
Thanks,
Jie
> + }
> +
> + return size;
> +}
> +static DEVICE_ATTR_RW(enable_tgu);
> +
> +static struct attribute *tgu_common_attrs[] = {
> + &dev_attr_enable_tgu.attr,
> + NULL,
> +};
> +
> +static const struct attribute_group tgu_common_grp = {
> + .attrs = tgu_common_attrs,
> + NULL,
> +};
> +
> +static const struct attribute_group *tgu_attr_groups[] = {
> + &tgu_common_grp,
> + NULL,
> +};
> +
> +static int tgu_probe(struct amba_device *adev, const struct amba_id *id)
> +{
> + struct device *dev = &adev->dev;
> + struct tgu_drvdata *drvdata;
> + int ret;
> +
> + drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
> + if (!drvdata)
> + return -ENOMEM;
> +
> + drvdata->dev = &adev->dev;
> + dev_set_drvdata(dev, drvdata);
> +
> + drvdata->base = devm_ioremap_resource(dev, &adev->res);
> + if (IS_ERR(drvdata->base))
> + return PTR_ERR(drvdata->base);
> +
> + spin_lock_init(&drvdata->lock);
> +
> + ret = sysfs_create_groups(&dev->kobj, tgu_attr_groups);
> + if (ret) {
> + dev_err(dev, "failed to create sysfs groups: %d\n", ret);
> + return ret;
> + }
> +
> + drvdata->enabled = false;
> +
> + pm_runtime_put(&adev->dev);
> +
> + return 0;
> +}
> +
> +static void tgu_remove(struct amba_device *adev)
> +{
> + struct device *dev = &adev->dev;
> +
> + sysfs_remove_groups(&dev->kobj, tgu_attr_groups);
> +
> + tgu_disable(dev);
> +}
> +
> +static const struct amba_id tgu_ids[] = {
> + {
> + .id = 0x000f0e00,
> + .mask = 0x000fffff,
> + },
> + { 0, 0, NULL },
> +};
> +
> +MODULE_DEVICE_TABLE(amba, tgu_ids);
> +
> +static struct amba_driver tgu_driver = {
> + .drv = {
> + .name = "qcom-tgu",
> + .suppress_bind_attrs = true,
> + },
> + .probe = tgu_probe,
> + .remove = tgu_remove,
> + .id_table = tgu_ids,
> +};
> +
> +module_amba_driver(tgu_driver);
> +
> +MODULE_AUTHOR("Songwei Chai <songwei.chai@oss.qualcomm.com>");
> +MODULE_AUTHOR("Jinlong Mao <jinlong.mao@oss.qualcomm.com>");
> +MODULE_DESCRIPTION("Qualcomm Trigger Generation Unit driver");
> +MODULE_LICENSE("GPL");
> diff --git a/drivers/hwtracing/qcom/tgu.h b/drivers/hwtracing/qcom/tgu.h
> new file mode 100644
> index 000000000000..dd7533b9d735
> --- /dev/null
> +++ b/drivers/hwtracing/qcom/tgu.h
> @@ -0,0 +1,51 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef _QCOM_TGU_H
> +#define _QCOM_TGU_H
> +
> +/* Register addresses */
> +#define TGU_CONTROL 0x0000
> +#define TGU_LAR 0xfb0
> +#define TGU_UNLOCK_OFFSET 0xc5acce55
> +
> +static inline void TGU_LOCK(void __iomem *addr)
> +{
> + do {
> + /* Wait for things to settle */
> + mb();
> + writel_relaxed(0x0, addr + TGU_LAR);
> + } while (0);
> +}
> +
> +static inline void TGU_UNLOCK(void __iomem *addr)
> +{
> + do {
> + writel_relaxed(TGU_UNLOCK_OFFSET, addr + TGU_LAR);
> + /* Make sure everyone has seen this */
> + mb();
> + } while (0);
> +}
> +
> +/**
> + * struct tgu_drvdata - Data structure for a TGU (Trigger Generator Unit)
> + * @base: Memory-mapped base address of the TGU device
> + * @dev: Pointer to the associated device structure
> + * @lock: Spinlock for handling concurrent access to private data
> + * @enabled: Flag indicating whether the TGU device is enabled
> + *
> + * This structure defines the data associated with a TGU device,
> + * including its base address, device pointers, clock, spinlock for
> + * synchronization, trigger data pointers, maximum limits for various
> + * trigger-related parameters, and enable status.
> + */
> +struct tgu_drvdata {
> + void __iomem *base;
> + struct device *dev;
> + spinlock_t lock;
> + bool enabled;
> +};
> +
> +#endif
^ permalink raw reply
* Re: [PATCH v2 0/4] Add RZ/G3L GFX support
From: Adrián Larumbe @ 2026-03-27 2:14 UTC (permalink / raw)
To: Biju
Cc: David Airlie, Simona Vetter, Steven Price, Boris Brezillon,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Biju Das, dri-devel, devicetree, linux-kernel,
linux-renesas-soc, Prabhakar Mahadev Lad
In-Reply-To: <20260320164158.487406-1-biju.das.jz@bp.renesas.com>
Applied to drm-misc-next.
On 20.03.2026 16:41, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> The Renesas RZ/G3L SoC includes the Arm Mali-G31 GPU as a 3D Graphics
> Engine (GE3D). The Arm Mali-G31 GPU is a graphics acceleration platform
> that is based on open standards. It supports 2D graphics, 3D graphics, and
> General Purpose computing on GPU (GPGPU). Add the binding and driver
> support for suspend/resume functionality along with some improvements in
> panfrost driver.
>
> v1->v2:
> * Dropped duplicate err assignment
> * Changed the format string of dev_err to "%d" and simplify the dev_err()
> line by using err rather than the same PTR_ERR().
> * Collected tags
>
> Biju Das (4):
> dt-bindings: gpu: mali-bifrost: Add compatible for RZ/G3L SoC
> drm/panfrost: Drop redundant optional clock checks in runtime PM
> drm/panfrost: Add bus_ace optional clock support for RZ/G2L
> drm/panfrost: Add GPU_PM_RT support for RZ/G3L SoC
>
> .../bindings/gpu/arm,mali-bifrost.yaml | 2 ++
> drivers/gpu/drm/panfrost/panfrost_device.c | 34 ++++++++++++++-----
> drivers/gpu/drm/panfrost/panfrost_device.h | 1 +
> drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
> 4 files changed, 30 insertions(+), 8 deletions(-)
>
> --
> 2.43.0
Adrian Larumbe
^ permalink raw reply
* RE: [PATCH v3 net-next 02/14] dt-bindings: net: dsa: add NETC switch
From: Wei Fang @ 2026-03-27 2:09 UTC (permalink / raw)
To: Frank Li
Cc: Claudiu Manoil, Vladimir Oltean, Clark Wang,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, f.fainelli@gmail.com,
chleroy@kernel.org, horms@kernel.org, linux@armlinux.org.uk,
andrew@lunn.ch, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <acWR0QwRSnupmCvI@lizhi-Precision-Tower-5810>
> On Thu, Mar 26, 2026 at 02:29:05PM +0800, Wei Fang wrote:
> > Add bindings for NETC switch. This switch is a PCIe function of NETC
> > IP, it supports advanced QoS with 8 traffic classes and 4 drop
> > resilience levels, and a full range of TSN standards capabilities.
> > The switch CPU
>
> Nit: double space before TSN.
Thanks for catching this, I will fix it.
>
> > port connects to an internal ENETC port, which is also a PCIe function
> > of NETC IP. So these two ports use a light-weight "pseudo MAC" instead
> > of a back-to-back MAC, because the "pseudo MAC" provides the
> > delineation between switch and ENETC, this translates to lower power
> > (less logic and
>
> what's means "this translates", do you means "this help reduce power and
> latency."
This sentence is excerpted from the NETC Block Guide. It is equivalent to
"it means".
>
> > memory) and lower delay (as there is no serialization delay across
> > this link).
> >
> > Signed-off-by: Wei Fang <wei.fang@nxp.com>
> > ---
> > .../bindings/net/dsa/nxp,netc-switch.yaml | 130 ++++++++++++++++++
> > 1 file changed, 130 insertions(+)
> > create mode 100644
> > Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> >
> > diff --git
> > a/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> > b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> > new file mode 100644
> > index 000000000000..e34a4e3504c3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/nxp,netc-switch.yaml
> > @@ -0,0 +1,130 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/net/dsa/nxp,netc-switch.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: NETC Switch family
> > +
> > +description:
>
> Nit use ">" for multi paragraph.
Okay, I suppose I also need to add '>' to the below description of
"dsa,member" property.
>
> others look good
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
>
> > + The NETC presents itself as a multi-function PCIe Root Complex
> > + Integrated Endpoint (RCiEP) and provides full 802.1Q Ethernet
> > + switch functionality, advanced QoS with 8 traffic classes and 4
> > + drop resilience levels, and a full range of TSN standards capabilities.
> > +
> > + The CPU port of the switch connects to an internal ENETC. The
> > + switch and the internal ENETC are fully integrated into the NETC
> > + IP, a back-to-back MAC is not required. Instead, a light-weight
> > + "pseudo MAC" provides the delineation between the switch and ENETC.
> > + This translates to lower power (less logic and memory) and lower
> > + delay (as there is no serialization delay across this link).
> > +
> > +maintainers:
> > + - Wei Fang <wei.fang@nxp.com>
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - pci1131,eef2
> > +
> > + reg:
> > + maxItems: 1
> > +
> > + dsa,member:
> > + description:
> > + The property indicates DSA cluster and switch index. For NETC switch,
> > + the valid range of the switch index is 1 ~ 7, the index is reflected
> > + in the switch tag as an indication of the switch ID where the frame
> > + originated. The value 0 is reserved for ENETC VEPA switch, whose ID
> > + is hardwired to zero.
> > +
> > +$ref: dsa.yaml#
> > +
> > +patternProperties:
> > + "^(ethernet-)?ports$":
> > + type: object
> > + additionalProperties: true
> > + patternProperties:
> > + "^(ethernet-)?port@[0-9a-f]$":
> > + type: object
> > +
> > + $ref: dsa-port.yaml#
> > +
> > + properties:
> > + clocks:
> > + items:
> > + - description: MAC transmit/receive reference clock.
> > +
> > + clock-names:
> > + items:
> > + - const: ref
> > +
> > + mdio:
> > + $ref: /schemas/net/mdio.yaml#
> > + unevaluatedProperties: false
> > + description:
> > + Optional child node for switch port, otherwise use NETC
> EMDIO.
> > +
> > + unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > + - reg
> > + - dsa,member
> > +
> > +allOf:
> > + - $ref: /schemas/pci/pci-device.yaml
> > +
> > +unevaluatedProperties: false
> > +
> > +examples:
> > + - |
> > + pcie {
> > + #address-cells = <3>;
> > + #size-cells = <2>;
> > +
> > + ethernet-switch@0,2 {
> > + compatible = "pci1131,eef2";
> > + reg = <0x200 0 0 0 0>;
> > + dsa,member = <0 1>;
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&pinctrl_switch>;
> > +
> > + ports {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + port@0 {
> > + reg = <0>;
> > + phy-handle = <ðphy0>;
> > + phy-mode = "mii";
> > + };
> > +
> > + port@1 {
> > + reg = <1>;
> > + phy-handle = <ðphy1>;
> > + phy-mode = "mii";
> > + };
> > +
> > + port@2 {
> > + reg = <2>;
> > + clocks = <&scmi_clk 103>;
> > + clock-names = "ref";
> > + phy-handle = <ðphy2>;
> > + phy-mode = "rgmii-id";
> > + };
> > +
> > + port@3 {
> > + reg = <3>;
> > + ethernet = <&enetc3>;
> > + phy-mode = "internal";
> > +
> > + fixed-link {
> > + speed = <2500>;
> > + full-duplex;
> > + pause;
> > + };
> > + };
> > + };
> > + };
> > + };
> > --
> > 2.34.1
> >
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-03-27 2:08 UTC (permalink / raw)
To: Andi Shyti
Cc: Krzysztof Kozlowski, Binbin Zhou, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-i2c, devicetree,
loongarch
In-Reply-To: <acTeJvyLty4K9kFn@zenone.zhora.eu>
On 2026/3/26 下午3:21, Andi Shyti wrote:
> Hi Hongliang,
>
>> Consider the clock framework relies on the device tree, and can only be used
>> on
>> Loongson 2K platform with dts parameter mechanism, It cannot be used on
>> Loongson
>> 3A+7A platform with the acpi parameter mechanism.
>> The i2c-ls2x driver is compatible with both Loongson 2K and 3A+7A platform,
>> parse
>> the same parameters regardless of dts or acpi parameter passing, So
>> clock-input
>> and clock-div attributes are defined to describe input clock of i2c
>> controller and
>> divisor of input clock. It can be used on both 2K and 3A+7A platform.
> Thanks for the explanation, but please do consider Krzysztof's
> review. Without him agreeing on the change I can't take your
> patch.
>
> If you have questions, please ask.
OK, thank you
> Andi
^ permalink raw reply
* Re: [PATCH v1 1/2] dt-bindings: i2c: ls2x-i2c: Add clock- related properties
From: Hongliang Wang @ 2026-03-27 2:06 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Binbin Zhou, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-i2c, devicetree, loongarch
In-Reply-To: <4516aba8-e776-41e1-ad26-c6f817b11b58@kernel.org>
On 2026/3/26 下午8:23, Krzysztof Kozlowski wrote:
> On 26/03/2026 12:48, Hongliang Wang wrote:
>> Hi Krzysztof and Andi,
>>
>> Sorry, I didn't express myself clearly. The purpose of defining clock-input and
>> clock-div properties is to use them in both acpi and dts. If these properties
>> cannot be used in dts, can I first use them in acpi? and second, use clock
>> framework in dts.
> I already asked you:
> 1. Stop requesting read receipts on your email
OK, I have set my email and removed the read receipts.
> 2. Don't top post.
OK
>
> I already told you also why these cannot be in DTS. Respond to technical
> arguments, not top-post of what you want.
OK
>
> Best regards,
> Krzysztof
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH 2/2] dts: riscv: spacemit: k3: Add i2c nodes
From: Yixun Lan @ 2026-03-27 2:05 UTC (permalink / raw)
To: Andi Shyti
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Troy Mitchell,
linux-i2c, devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <acWx_31uT2ffcaSN@zenone.zhora.eu>
Hi Andi,
On 23:24 Thu 26 Mar , Andi Shyti wrote:
> Hi agagin,
>
> On Thu, Mar 26, 2026 at 11:22:31PM +0100, Andi Shyti wrote:
> > On Wed, Mar 25, 2026 at 09:49:25AM +0000, Yixun Lan wrote:
> > > Populate all I2C devicetree nodes for SpacemiT K3 SoC.
> > >
> > > Signed-off-by: Yixun Lan <dlan@kernel.org>
> >
> > this second patch does not apply on my i2c branch. I'm missing
> > some other patches on k3.
> >
> > Can you please rebase it on top of my i2c/i2c-host branch,
> > otherwise I will need to wait for the merge window to open in
> > order to take this.
>
> sorry, this has to go through some other path, I'm going to take
> patch 1.
Right, I will take care of it, DT patch should go via SpacemiT SoC tree.
--
Yixun Lan (dlan)
^ permalink raw reply
* [PATCH] ARM: dts: aspeed: g6: Add missing uart nodes
From: Jammy Huang @ 2026-03-27 1:58 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Jammy Huang
Add nodes for uart10/11/12/13.
Signed-off-by: Jammy Huang <jammy_huang@aspeedtech.com>
---
arch/arm/boot/dts/aspeed/aspeed-g6.dtsi | 56 +++++++++++++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
index 189bc3bbb47..0ffe386fa9d 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
+++ b/arch/arm/boot/dts/aspeed/aspeed-g6.dtsi
@@ -835,6 +835,62 @@ uart9: serial@1e790300 {
status = "disabled";
};
+ uart10: serial@1e790400 {
+ compatible = "ns16550a";
+ reg = <0x1e790400 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 61 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_UART10CLK>;
+ no-loopback-test;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart10_default>;
+
+ status = "disabled";
+ };
+
+ uart11: serial@1e790500 {
+ compatible = "ns16550a";
+ reg = <0x1e790500 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_UART11CLK>;
+ no-loopback-test;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart11_default>;
+
+ status = "disabled";
+ };
+
+ uart12: serial@1e790600 {
+ compatible = "ns16550a";
+ reg = <0x1e790600 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 63 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_UART12CLK>;
+ no-loopback-test;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart12g1_default>;
+
+ status = "disabled";
+ };
+
+ uart13: serial@1e790700 {
+ compatible = "ns16550a";
+ reg = <0x1e790700 0x20>;
+ reg-shift = <2>;
+ reg-io-width = <4>;
+ interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&syscon ASPEED_CLK_GATE_UART13CLK>;
+ no-loopback-test;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart13g1_default>;
+
+ status = "disabled";
+ };
+
i2c: bus@1e78a000 {
compatible = "simple-bus";
#address-cells = <1>;
---
base-commit: 5ee8dbf54602dc340d6235b1d6aa17c0f283f48c
change-id: 20260327-upstream_g6_dts_uart-78a5ce3b2873
Best regards,
--
Jammy Huang <jammy_huang@aspeedtech.com>
^ permalink raw reply related
* Re: [PATCH net-next v2 4/4] net: phy: Introduce Airoha AN8801/R Gigabit Ethernet PHY driver
From: Jakub Kicinski @ 2026-03-27 1:43 UTC (permalink / raw)
To: Louis-Alexis Eyraud
Cc: Andrew Lunn, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
AngeloGioacchino Del Regno, Heiner Kallweit, Russell King,
kevin-kw.huang, macpaul.lin, matthias.bgg, kernel, netdev,
devicetree, linux-arm-kernel, linux-mediatek, linux-kernel
In-Reply-To: <3688a285-7f98-4afa-80ad-697094cd7b97@lunn.ch>
On Thu, 26 Mar 2026 13:47:43 +0100 Andrew Lunn wrote:
> > + if (phydev->link && prev_speed != phydev->speed) {
> > + val = phydev->speed == SPEED_1000 ?
> > + AN8801_BPBUS_LINK_MODE_1000 : 0;
> > +
> > + return an8801_buckpbus_reg_rmw(phydev,
> > + AN8801_BPBUS_REG_LINK_MODE,
> > + AN8801_BPBUS_LINK_MODE_1000,
> > + val);
> > + };
>
> This is unusual. What is it doing? Please add a comment.
Also - nit spurious ; after if () {}
^ permalink raw reply
* Re: [PATCH v5 0/3] iio: adc: ltc2309: add support driver for ltc2305
From: Kyle Hsieh @ 2026-03-27 1:32 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Lars-Peter Clausen, Michael Hennerich, David Lechner,
Nuno Sá, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Beguin, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260325195035.26214c91@jic23-huawei>
On Thu, Mar 26, 2026 at 3:50 AM Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Wed, 25 Mar 2026 10:24:19 +0800
> Kyle Hsieh <kylehsieh1995@gmail.com> wrote:
>
> > The series add support for ltc2305 controller from
> > Linear Technology Corporation(lltc).
> > This is low noise, low power, 2 channels 12-bit successive
> > approximation ADCs.
> >
> > Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> Applied to the togreg branch of iio.git.
>
> To hussle things along a touch I skipped the normal pushing
> it out as testing first (what could possibly go wrong ;)
>
> Jonathan
Hi Jonathan,
I'm glad to see this series moving forward.
Thanks for your help!
Best regards,
Kyle
>
> > ---
> > Changes in v5:
> > - Split the patch series to refactor LTC2309 channel enums first.
> > - Explicitly assign hex values to channel enums based on datasheet.
> > - Add support for LTC2305 on top of the refactored driver.
> > - Link to v4: https://lore.kernel.org/r/20260311-add_ltc2305_driver-v4-0-bc350d347f33@gmail.com
> >
> > Changes in v4:
> > - Fix build warning in ltc2309_probe(): initialize 'chip_info'.
> > - Link to v3: https://lore.kernel.org/r/20260126-add_ltc2305_driver-v3-0-951349a87f97@gmail.com
> >
> > Changes in v3:
> > - Modify ltc2305 channel mask to compatible ltc2309.
> > - Link to v2: https://lore.kernel.org/r/20251224-add_ltc2305_driver-v2-0-061f78cf45a3@gmail.com
> >
> > Changes in v2:
> > - Reordered chip descriptions and code from low to high order.
> > - Renamed chip info structure to use ltc2309 driver prefix.
> > - Switched to i2c_get_match_data().
> > - Removed unused variables.
> > - Added chip info to i2c_device_id table.
> > - Link to v1: https://lore.kernel.org/r/20251223-add_ltc2305_driver-v1-0-dfa0827fd620@gmail.com
> >
> > ---
> > Kyle Hsieh (3):
> > dt-bindings: adc: ltc2497: add support for ltc2305
> > iio: adc: ltc2309: explicitly assign hex values to channel enums
> > iio: adc: ltc2309: add support for ltc2305
> >
> > .../devicetree/bindings/iio/adc/lltc,ltc2497.yaml | 7 ++
> > drivers/iio/adc/ltc2309.c | 81 ++++++++++++++++------
> > 2 files changed, 67 insertions(+), 21 deletions(-)
> > ---
> > base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> > change-id: 20251223-add_ltc2305_driver-728fa9161bc7
> >
> > Best regards,
>
^ permalink raw reply
* Re: [PATCH net-next v15 0/3] Add support for Nuvoton MA35D1 GMAC
From: patchwork-bot+netdevbpf @ 2026-03-27 1:20 UTC (permalink / raw)
To: Joey Lu
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, mcoquelin.stm32, richardcochran, alexandre.torgue,
joabreu, ychuang3, schung, yclu4, peppe.cavallaro,
linux-arm-kernel, netdev, devicetree, linux-kernel, openbmc,
linux-stm32
In-Reply-To: <20260323101756.81849-1-a0987203069@gmail.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 23 Mar 2026 18:17:53 +0800 you wrote:
> This patch series is submitted to add GMAC support for Nuvoton MA35D1
> SoC platform. This work involves implementing a GMAC driver glue layer
> based on Synopsys DWMAC driver framework to leverage MA35D1's dual GMAC
> interface capabilities.
>
> Overview:
> 1. Added a GMAC driver glue layer for MA35D1 SoC, providing support for
> the platform's two GMAC interfaces.
> 2. Added device tree settings, with specific configurations for our
> development boards:
> a. SOM board: Configured for two RGMII interfaces.
> b. IoT board: Configured with one RGMII and one RMII interface.
> 3. Added dt-bindings for the GMAC interfaces.
>
> [...]
Here is the summary with links:
- [net-next,v15,1/3] dt-bindings: net: nuvoton: Add schema for Nuvoton MA35 family GMAC
https://git.kernel.org/netdev/net-next/c/8454478ef9ab
- [net-next,v15,2/3] arm64: dts: nuvoton: Add Ethernet nodes
(no matching commit)
- [net-next,v15,3/3] net: stmmac: dwmac-nuvoton: Add dwmac glue for Nuvoton MA35 family
https://git.kernel.org/netdev/net-next/c/4d7c557f58ef
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-03-27 1:03 UTC (permalink / raw)
To: Vladimir Zapolskiy, Bryan O'Donoghue, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong
Cc: linux-arm-msm, linux-phy, linux-media, devicetree, linux-kernel
In-Reply-To: <99287afe-90cb-44d5-91db-14c6b0f729fd@linaro.org>
On 26/03/2026 14:49, Vladimir Zapolskiy wrote:
> Here the description of hardware is done, and my point is that the new
> PHY_QCOM_CSI2_MODE_SPLIT_DPHY phy type is simply not needed, since it's
> possible to give a proper description of hardware without this invention.
Perhaps I'm not understanding you.
If we use PHY_TYPE_DPHY
include/dt-bindings/phy/phy.h:#define PHY_TYPE_DPHY 10
We _must_ then add SPLIT_MODE to phy.h if/when we implement that
support. Which means successfully arguing the toss of weather SPLIT_MODE
is a Qualcommism - a vendor specific mode or not.
<&phy PHY_TYPE_DPHY> committed to an upstream dts will then need to be
supported perpetually.
So for example qrb5615 - kona/rb5 support split mode.
Pretend go with <&phy PHY_TYPE_DPHY>; and retrofit individual PHY
support to this platform.
Grand so far.
The pretend we want to switch from one sensor to a split-mode sensor on
the existing mezzanine.
Then we need a representation of split mode in phy.h to represent that
in DT.
<&phy PHY_TYPE_DPHY_SPLIT_MODE>;
Except split-mode is not an appropriate mode to define in phy.h since it
is vendor specific - even if a few vendors support it, its not a generic
PHY mode.
Hence we would have an enormously difficult time justifying adding that
mode to phy.h and rightly so.
>> https://review.lineageos.org/c/LineageOS/
>> android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/
>> cam_csiphy/cam_csiphy_core.c#b285
>>
>> There is disjunction all over this file depending on the mode.
>>
>> https://review.lineageos.org/c/LineageOS/
>> android_kernel_motorola_sm6375/+/423960/1/drivers/cam_sensor_module/
>> cam_csiphy/cam_csiphy_core.c#b767
OTOH
- SPLIT_MODE will certainly require _both_ separate init sequences
and specific logical disjunction for additional configuration steps
lane-assignment and masking, etc.
- That phy.h isn't the right location for SPLIT_MODE as its vendor
specific. Just look at the modes we have for the USB PHYs
same logic => include/dt-bindings/phy/phy-qcom-qmp.h same
raison d'être
- And that specifying PHY_TYPE_DPHY now binds us into an ABI that we
cannot subsequently change - it will not be possible to introduce
include/dt-bindings/phy/phy-qcom-mipi-csi2.h later on with our mode
So therefore include/dt-bindings/phy/phy-qcom-mipi-csi2.h + PHY modes is
the logical outcome.
---
bod
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series
From: Roman Gushchin @ 2026-03-27 0:46 UTC (permalink / raw)
To: Conor Dooley
Cc: Guenter Roeck, Zaixiang Xu, robh, krzk+dt, conor+dt, linux-hwmon,
devicetree, linux-kernel
In-Reply-To: <20260327-clubbing-crushed-e73c4c994737@spud>
Hello,
The pseudo-commit message is intentional, Chris Mason initially
prompted it, and I'm honestly just using his format. The intention
here is to ensure the LLM reviews the correct commit and at least
understands what it's doing. Idk if it's really useful with Sashiko,
but it's there and hopefully not too distracting.
Re previous versions: it's not implemented yet, but I plan to add this
eventually.
Thanks!
On Thu, Mar 26, 2026 at 5:03 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Thu, Mar 26, 2026 at 04:55:39PM -0700, Guenter Roeck wrote:
> > On 3/26/26 10:45, Conor Dooley wrote:
> > > On Thu, Mar 26, 2026 at 05:42:30PM +0000, Conor Dooley wrote:
> > > > On Wed, Mar 25, 2026 at 06:05:22PM -0700, Guenter Roeck wrote:
> > > > > On 3/25/26 11:20, Conor Dooley wrote:
> > > > > > On Wed, Mar 25, 2026 at 05:08:08PM +0800, Zaixiang Xu wrote:
> > > > > > > Add YAML devicetree binding schema for Sensirion SHT30 series.
> > > > > > > Use fallback compatibles for compatible chips and add optional
> > > > > > > interrupts and vdd-supply properties.
> > > > > > >
> > > > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > > > > Closes: https://lore.kernel.org/r/202603212044.BRPaiz86-lkp@intel.com/
> > > > > >
> > > > > > The robot did not report that this binding was missing.
> > > > > > It also told you not to add these tags.
> > > > > >
> > > > > > You also ignored my and Krzysztof's reviews.
> > > > > >
> > > > > > NAK.
> > > > > >
> > > > >
> > > > > Maybe we should just point to AI feedback:
> > > > >
> > > > > https://sashiko.dev/#/patchset/1774429690-129139-1-git-send-email-zaixiang.xu.dev%40gmail.com
> > > > >
> > > > > and only get involved after AI does not report any problems.
> > > > >
> > > >
> > > > The presentation of info in that is weird, it creates a pseudo-commit
> > > > message, and then goes on to talk about things that the pseudo-commit
> > > > message has had culled.
> > >
> > > How good is this LLM stuff at figuring out if previous review feedback
> > > has been resolved? Or is it not capable of looking at earlier revisions?
> >
> >
> > Both are interesting questions. For the first one, I had noticed that, but
> > to me it seemed that the pseudo-commit message is an attempt to create a concise
> > version of the commit message, and I have not seen evidence that the later
> > comments did not also apply to the real commit message.
>
> Yeah, the comments did apply to the real commit message. I was just
> confusing to me to see what looked to me like a commit message not
> contain the info that was being referred to later on. I thought that the
> LLM was hallucinating the comments until I went back to this mail and
> realised the text was here.
>
> >
> > Anyway, copying Roman for feedback on both.
> >
> > Thanks,
> > Guenter
> >
^ permalink raw reply
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-27 0:09 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <20260325-pinctrl-mux-v4-3-043c2c82e623@nxp.com>
[-- Attachment #1: Type: text/plain, Size: 6834 bytes --]
On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
> Refactor pinctrl_generic_pins_function_dt_subnode_to_map() by separating DT
> parsing logic from map creation. Introduce a new helper
> pinctrl_generic_to_map() to handle mapping to kernel data structures, while
> keeping DT property parsing in the subnode function.
>
> Improve code structure and enables easier reuse for platforms using
> different DT properties (e.g. pinmux) without modifying the
> dt_node_to_map-style callback API. Avoid unnecessary coupling to
> pinctrl_generic_pins_function_dt_node_to_map(), which provides
> functionality not needed when the phandle target is unambiguous.
>
> Maximize code reuse and provide a cleaner extension point for future
> pinctrl drivers.
>
> Signed-off-by: Frank Li <Frank.Li@nxp.com>
> ---
> change in v4
> - new patch
> ---
> drivers/pinctrl/pinconf.h | 18 ++++++++
> drivers/pinctrl/pinctrl-generic.c | 91 ++++++++++++++++++++++++---------------
> 2 files changed, 74 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/pinctrl/pinconf.h b/drivers/pinctrl/pinconf.h
> index 2880adef476e68950ffdd540ea42cdee6a16ec27..ffdabddb9660324ed8886a2e8dcacff7e1c6c529 100644
> --- a/drivers/pinctrl/pinconf.h
> +++ b/drivers/pinctrl/pinconf.h
> @@ -166,6 +166,13 @@ int pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> struct device_node *np,
> struct pinctrl_map **maps,
> unsigned int *num_maps);
> +
> +int
> +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> + struct device_node *np, struct pinctrl_map **maps,
> + unsigned int *num_maps, unsigned int *num_reserved_maps,
> + const char **group_name, unsigned int ngroups,
> + const char **functions, unsigned int *pins);
> #else
> static inline int
> pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> @@ -175,4 +182,15 @@ pinctrl_generic_pins_function_dt_node_to_map(struct pinctrl_dev *pctldev,
> {
> return -ENOTSUPP;
> }
> +
> +static inline int
> +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> + struct device_node *np, struct pinctrl_map **maps,
> + unsigned int *num_maps, unsigned int *num_reserved_maps,
> + const char **group_name, unsigned int ngroups,
> + const char **functions, unsigned int *pins,
> + void *function_data)
> +{
> + return -ENOTSUPP;
> +}
> #endif
> diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> --- a/drivers/pinctrl/pinctrl-generic.c
> +++ b/drivers/pinctrl/pinctrl-generic.c
> @@ -17,29 +17,18 @@
> #include "pinctrl-utils.h"
> #include "pinmux.h"
>
> -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> - struct device_node *parent,
> - struct device_node *np,
> - struct pinctrl_map **maps,
> - unsigned int *num_maps,
> - unsigned int *num_reserved_maps,
> - const char **group_names,
> - unsigned int ngroups)
> +int
> +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> + struct device_node *np, struct pinctrl_map **maps,
> + unsigned int *num_maps, unsigned int *num_reserved_maps,
> + const char **group_names, unsigned int ngroups,
> + const char **functions, unsigned int *pins)
npins needs to be an argument to this function also, otherwise
pinctrl_generic_add_group() uses it uninitialised...
> {
> struct device *dev = pctldev->dev;
> - const char **functions;
> + int npins, ret, reserve = 1;
...because you're declaring it here when it's something set by the dt
parsing code in pinctrl_generic_pins_function_dt_subnode_to_map()...
> + unsigned int num_configs;
> const char *group_name;
> unsigned long *configs;
> - unsigned int num_configs, pin, *pins;
> - int npins, ret, reserve = 1;
> -
> - npins = of_property_count_u32_elems(np, "pins");
> -
> - if (npins < 1) {
> - dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> - parent, np, npins);
> - return npins;
> - }
>
> group_name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn.%pOFn", parent, np);
> if (!group_name)
> @@ -51,22 +40,6 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> if (!pins)
> return -ENOMEM;
>
> - functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> - if (!functions)
> - return -ENOMEM;
> -
> - for (int i = 0; i < npins; i++) {
> - ret = of_property_read_u32_index(np, "pins", i, &pin);
> - if (ret)
> - return ret;
> -
> - pins[i] = pin;
> -
> - ret = of_property_read_string(np, "function", &functions[i]);
> - if (ret)
> - return ret;
> - }
> -
> ret = pinctrl_utils_reserve_map(pctldev, maps, num_reserved_maps, num_maps, reserve);
> if (ret)
> return ret;
> @@ -103,6 +76,54 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> return 0;
> };
>
> +static int
> +pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> + struct device_node *parent,
> + struct device_node *np,
> + struct pinctrl_map **maps,
> + unsigned int *num_maps,
> + unsigned int *num_reserved_maps,
> + const char **group_names,
> + unsigned int ngroups)
> +{
> + struct device *dev = pctldev->dev;
> + unsigned int pin, *pins;
> + const char **functions;
> + int npins, ret;
> +
> + npins = of_property_count_u32_elems(np, "pins");
...down here.
> +
> + if (npins < 1) {
> + dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> + parent, np, npins);
> + return npins;
> + }
> +
> + pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> + if (!pins)
> + return -ENOMEM;
> +
> + functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> + if (!functions)
> + return -ENOMEM;
> +
> + for (int i = 0; i < npins; i++) {
> + ret = of_property_read_u32_index(np, "pins", i, &pin);
> + if (ret)
> + return ret;
> +
> + pins[i] = pin;
> +
> + ret = of_property_read_string(np, "function", &functions[i]);
> + if (ret)
> + return ret;
> + }
> +
> + return pinctrl_generic_to_map(pctldev, parent, np, maps, num_maps,
> + num_reserved_maps, group_names, ngroups,
> + functions, pins);
> +}
> +
> /*
> * For platforms that do not define groups or functions in the driver, but
> * instead use the devicetree to describe them. This function will, unlike
>
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 3/7] pinctrl: extract pinctrl_generic_to_map() from pinctrl_generic_pins_function_dt_node_to_map()
From: Conor Dooley @ 2026-03-27 0:06 UTC (permalink / raw)
To: Frank Li
Cc: Peter Rosin, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafał Miłecki, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, linux-kernel, linux-gpio,
devicetree, imx, linux-arm-kernel, Haibo Chen
In-Reply-To: <acWNOhnBvA5l9NW3@lizhi-Precision-Tower-5810>
[-- Attachment #1: Type: text/plain, Size: 5910 bytes --]
On Thu, Mar 26, 2026 at 03:47:06PM -0400, Frank Li wrote:
> On Thu, Mar 26, 2026 at 06:55:01PM +0000, Conor Dooley wrote:
> > On Thu, Mar 26, 2026 at 06:52:12PM +0000, Conor Dooley wrote:
> > > On Wed, Mar 25, 2026 at 07:04:12PM -0400, Frank Li wrote:
> > >
> > > > diff --git a/drivers/pinctrl/pinctrl-generic.c b/drivers/pinctrl/pinctrl-generic.c
> > > > index efb39c6a670331775855efdc8566102b5c6202ef..20a216ae63e91b69985ea4cfcd0b57103c6ca950 100644
> > > > --- a/drivers/pinctrl/pinctrl-generic.c
> > > > +++ b/drivers/pinctrl/pinctrl-generic.c
> > > > @@ -17,29 +17,18 @@
> > > > #include "pinctrl-utils.h"
> > > > #include "pinmux.h"
> > > >
> > > > -static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> > >
> > > > +int
> > > > +pinctrl_generic_to_map(struct pinctrl_dev *pctldev, struct device_node *parent,
> > >
> > > Can you drop this stylistic change please? The
> >
> > Whoops, cut myself off. To be clear, what I am asking for is to keep the
> > "int" etc on the same line as the function name. This function is new,
> > but you did it for the existing function too and the comparison is here.
> >
> > >
> > > > + struct device_node *np, struct pinctrl_map **maps,
> > > > + unsigned int *num_maps, unsigned int *num_reserved_maps,
> > > > + const char **group_names, unsigned int ngroups,
> > > > + const char **functions, unsigned int *pins)
> > > > {
> > > > struct device *dev = pctldev->dev;
> > > > - const char **functions;
> > > > + int npins, ret, reserve = 1;
> > > > + unsigned int num_configs;
> > > > const char *group_name;
> > > > unsigned long *configs;
> > > > - unsigned int num_configs, pin, *pins;
> > > > - int npins, ret, reserve = 1;
> > > > -
> > > > - npins = of_property_count_u32_elems(np, "pins");
> > > > -
> > > > - if (npins < 1) {
> > > > - dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> > > > - parent, np, npins);
> > > > - return npins;
> > > > - }
> > > >
> > > > group_name = devm_kasprintf(dev, GFP_KERNEL, "%pOFn.%pOFn", parent, np);
> > > > if (!group_name)
> > > > @@ -51,22 +40,6 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> > > > if (!pins)
> > > > return -ENOMEM;
> > >
> > > This looks suspect. You've left the pins allocation behind:
> > > pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> > > if (!pins)
> > > return -ENOMEM;
> > > but pinctrl_generic_pins_function_dt_subnode_to_map() has already
> > > populated this array before calling the function.
>
> what's means?
It means you broke my driver by not removing this allocation from
pinctrl_generic_to_map().
>
> pinctrl_generic_pins_function_dt_subnode_to_map()
> {
> pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> ...
> pinctrl_generic_to_map();
> }
>
> pinctrl_generic_pins_function_dt_subnode_to_map() have not use this array.
I have no idea what this statement means.
>
> Frank
> > >
> > > Also, this should probably be
> > > Suggested-by: Conor Dooley <conor.dooley@microchip.com>
> > >
> > > Cheers,
> > > Conor.
> > >
> > > >
> > > > - functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> > > > - if (!functions)
> > > > - return -ENOMEM;
> > > > -
> > > > - for (int i = 0; i < npins; i++) {
> > > > - ret = of_property_read_u32_index(np, "pins", i, &pin);
> > > > - if (ret)
> > > > - return ret;
> > > > -
> > > > - pins[i] = pin;
> > > > -
> > > > - ret = of_property_read_string(np, "function", &functions[i]);
> > > > - if (ret)
> > > > - return ret;
> > > > - }
> > > > -
> > > > ret = pinctrl_utils_reserve_map(pctldev, maps, num_reserved_maps, num_maps, reserve);
> > > > if (ret)
> > > > return ret;
> > > > @@ -103,6 +76,54 @@ static int pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *p
> > > > return 0;
> > > > };
> > > >
> > > > +static int
> > > > +pinctrl_generic_pins_function_dt_subnode_to_map(struct pinctrl_dev *pctldev,
> > > > + struct device_node *parent,
> > > > + struct device_node *np,
> > > > + struct pinctrl_map **maps,
> > > > + unsigned int *num_maps,
> > > > + unsigned int *num_reserved_maps,
> > > > + const char **group_names,
> > > > + unsigned int ngroups)
> > > > +{
> > > > + struct device *dev = pctldev->dev;
> > > > + unsigned int pin, *pins;
> > > > + const char **functions;
> > > > + int npins, ret;
> > > > +
> > > > + npins = of_property_count_u32_elems(np, "pins");
> > > > +
> > > > + if (npins < 1) {
> > > > + dev_err(dev, "invalid pinctrl group %pOFn.%pOFn %d\n",
> > > > + parent, np, npins);
> > > > + return npins;
> > > > + }
> > > > +
> > > > + pins = devm_kcalloc(dev, npins, sizeof(*pins), GFP_KERNEL);
> > > > + if (!pins)
> > > > + return -ENOMEM;
> > > > +
> > > > + functions = devm_kcalloc(dev, npins, sizeof(*functions), GFP_KERNEL);
> > > > + if (!functions)
> > > > + return -ENOMEM;
> > > > +
> > > > + for (int i = 0; i < npins; i++) {
> > > > + ret = of_property_read_u32_index(np, "pins", i, &pin);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + pins[i] = pin;
> > > > +
> > > > + ret = of_property_read_string(np, "function", &functions[i]);
> > > > + if (ret)
> > > > + return ret;
> > > > + }
> > > > +
> > > > + return pinctrl_generic_to_map(pctldev, parent, np, maps, num_maps,
> > > > + num_reserved_maps, group_names, ngroups,
> > > > + functions, pins);
> > > > +}
> > > > +
> > > > /*
> > > > * For platforms that do not define groups or functions in the driver, but
> > > > * instead use the devicetree to describe them. This function will, unlike
> > > >
> > > > --
> > > > 2.43.0
> > > >
> >
> >
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series
From: Conor Dooley @ 2026-03-27 0:03 UTC (permalink / raw)
To: Guenter Roeck
Cc: Zaixiang Xu, robh, krzk+dt, conor+dt, linux-hwmon, devicetree,
linux-kernel, Roman Gushchin
In-Reply-To: <ba8848a3-03f0-4113-8db4-d6dd46a57959@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 2281 bytes --]
On Thu, Mar 26, 2026 at 04:55:39PM -0700, Guenter Roeck wrote:
> On 3/26/26 10:45, Conor Dooley wrote:
> > On Thu, Mar 26, 2026 at 05:42:30PM +0000, Conor Dooley wrote:
> > > On Wed, Mar 25, 2026 at 06:05:22PM -0700, Guenter Roeck wrote:
> > > > On 3/25/26 11:20, Conor Dooley wrote:
> > > > > On Wed, Mar 25, 2026 at 05:08:08PM +0800, Zaixiang Xu wrote:
> > > > > > Add YAML devicetree binding schema for Sensirion SHT30 series.
> > > > > > Use fallback compatibles for compatible chips and add optional
> > > > > > interrupts and vdd-supply properties.
> > > > > >
> > > > > > Reported-by: kernel test robot <lkp@intel.com>
> > > > > > Closes: https://lore.kernel.org/r/202603212044.BRPaiz86-lkp@intel.com/
> > > > >
> > > > > The robot did not report that this binding was missing.
> > > > > It also told you not to add these tags.
> > > > >
> > > > > You also ignored my and Krzysztof's reviews.
> > > > >
> > > > > NAK.
> > > > >
> > > >
> > > > Maybe we should just point to AI feedback:
> > > >
> > > > https://sashiko.dev/#/patchset/1774429690-129139-1-git-send-email-zaixiang.xu.dev%40gmail.com
> > > >
> > > > and only get involved after AI does not report any problems.
> > > >
> > >
> > > The presentation of info in that is weird, it creates a pseudo-commit
> > > message, and then goes on to talk about things that the pseudo-commit
> > > message has had culled.
> >
> > How good is this LLM stuff at figuring out if previous review feedback
> > has been resolved? Or is it not capable of looking at earlier revisions?
>
>
> Both are interesting questions. For the first one, I had noticed that, but
> to me it seemed that the pseudo-commit message is an attempt to create a concise
> version of the commit message, and I have not seen evidence that the later
> comments did not also apply to the real commit message.
Yeah, the comments did apply to the real commit message. I was just
confusing to me to see what looked to me like a commit message not
contain the info that was being referred to later on. I thought that the
LLM was hallucinating the comments until I went back to this mail and
realised the text was here.
>
> Anyway, copying Roman for feedback on both.
>
> Thanks,
> Guenter
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 2/4] dt-bindings: hwmon: Add Sensirion SHT30 series
From: Guenter Roeck @ 2026-03-26 23:55 UTC (permalink / raw)
To: Conor Dooley
Cc: Zaixiang Xu, robh, krzk+dt, conor+dt, linux-hwmon, devicetree,
linux-kernel, Roman Gushchin
In-Reply-To: <20260326-opposing-footsie-33a0deb2ba90@spud>
On 3/26/26 10:45, Conor Dooley wrote:
> On Thu, Mar 26, 2026 at 05:42:30PM +0000, Conor Dooley wrote:
>> On Wed, Mar 25, 2026 at 06:05:22PM -0700, Guenter Roeck wrote:
>>> On 3/25/26 11:20, Conor Dooley wrote:
>>>> On Wed, Mar 25, 2026 at 05:08:08PM +0800, Zaixiang Xu wrote:
>>>>> Add YAML devicetree binding schema for Sensirion SHT30 series.
>>>>> Use fallback compatibles for compatible chips and add optional
>>>>> interrupts and vdd-supply properties.
>>>>>
>>>>> Reported-by: kernel test robot <lkp@intel.com>
>>>>> Closes: https://lore.kernel.org/r/202603212044.BRPaiz86-lkp@intel.com/
>>>>
>>>> The robot did not report that this binding was missing.
>>>> It also told you not to add these tags.
>>>>
>>>> You also ignored my and Krzysztof's reviews.
>>>>
>>>> NAK.
>>>>
>>>
>>> Maybe we should just point to AI feedback:
>>>
>>> https://sashiko.dev/#/patchset/1774429690-129139-1-git-send-email-zaixiang.xu.dev%40gmail.com
>>>
>>> and only get involved after AI does not report any problems.
>>>
>>
>> The presentation of info in that is weird, it creates a pseudo-commit
>> message, and then goes on to talk about things that the pseudo-commit
>> message has had culled.
>
> How good is this LLM stuff at figuring out if previous review feedback
> has been resolved? Or is it not capable of looking at earlier revisions?
Both are interesting questions. For the first one, I had noticed that, but
to me it seemed that the pseudo-commit message is an attempt to create a concise
version of the commit message, and I have not seen evidence that the later
comments did not also apply to the real commit message.
Anyway, copying Roman for feedback on both.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v4 0/2] Add support for Texas Instruments INA4230 power monitor
From: Guenter Roeck @ 2026-03-26 23:49 UTC (permalink / raw)
To: Alexey Charkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-hwmon, devicetree, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260326-ina4230-v4-0-c1e312c09de7@flipper.net>
On 3/26/26 12:58, Alexey Charkov wrote:
> TI INA4230 is a 4-channel power monitor with I2C interface, similar in
> operation to INA3221 (3-channel) and INA219 (single-channel) but with
> a different register layout, different alerting mechanism and slightly
> different support for directly reading calculated current/power/energy
> values (pre-multiplied by the device itself and needing only to be scaled
> by the driver depending on its selected LSB unit values).
>
> In this initial implementation, the driver supports reading voltage,
> current, power and energy values, but does not yet support alerts, which
> can be added separately if needed. Also the overflows during hardware
> calculations are not yet handled, nor is the support for the device's
> internal 32-bit energy counter reset.
>
> An example device tree using this binding and driver is available at [1]
> (not currently upstreamed, as the device in question is in engineering
> phase and not yet publicly available)
>
> [1] https://github.com/flipperdevices/flipper-linux-kernel/blob/flipper-devel/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dts
>
> Signed-off-by: Alexey Charkov <alchark@flipper.net>
More feedback from Sashiko:
https://sashiko.dev/#/patchset/20260326-ina4230-v4-0-c1e312c09de7%40flipper.net
I can not comment on the devicetree feedback, but the driver
concerns seem real. Please take a look.
Thanks,
Guenter
> ---
> Changes in v4:
> - Aligned the maximum value of ti,maximum-expected-current-microamp property
> in the binding with the one expected by the driver (Guenter Roeck)
> "2147A ought to be enough for anybody (c)"
> - Actually requested the optional vs-supply regulator in the driver (Guenter Roeck)
> - Program the ALERT_POL bit according to the value of ti,alert-polarity-active-high
> even though the alerts themselves are not yet implemented (Guenter Roeck)
> - Added a check for manually disabled channels in the is_enabled() function to
> avoid reading invalid data from them (Guenter Roeck)
> - Dropped support for the single-shot mode as its operation is not clearly
> documented in the datasheet and there is no pressing need to support it (Guenter Roeck)
> - NB: AI feedback regarding regmap_noinc_read() producing incorrect byte order on LE
> hosts is incorrect, as its implementation does a byte-wise read and doesn't care
> about the regmap value width or endianness flags, so it produces a 4-byte output
> buffer in the same byte order as the device returns, which is BE in this case
> - NB: AI feedback regarding fail-path pm_runtime_put_noidle() potentially being
> unbalanced if the probe loop failed early is technically correct but practically
> irrelevant, as the driver will simply fail to load, and the usage count won't
> decrease beyond zero anyway. The alternatives are cumbersome for no real benefit
> - Link to v3: https://lore.kernel.org/r/20260310-ina4230-v3-0-06ab3a77c570@flipper.net
>
> Changes in v3:
> - Updated the description of the ti,maximum-expected-current-microamp property
> in the binding to clarify how it is used, and drop the irrelevant mention of
> the PMbus (Guenter Roeck)
> - Use div64_u64() instead of do_div() for the final division in the calibration value
> calculation to avoid overflows in the denominator (Guenter Roeck)
> - Avoid overflow while scaling the voltage values on 32-bit platforms (Guenter Roeck)
> - Use regmap_noinc_read() instead of regmap_raw_read() for reading the energy values
> to ensure that the regmap / bus driver don't wander off to adjacent registers
> during the read operation (on INA4230 the whole 32 bits should be read from
> the same register offset) (Guenter Roeck)
> - Remove redundant call to ina4230_set_calibration() in the current read path,
> as the calibration value is already set when enabling the channel and restored
> across PM changes via regcache_sync() (Guenter Roeck)
> - Add missing write_enable() function to make hwmon_in_enable writes work as
> advertised in is_visible() (Guenter Roeck)
> - Add a check for disabled channels before calling pm_runtime_put_noidle() on them
> to avoid refcount underflow due to imbalanced get_sync/put_noidle calls (Guenter Roeck)
> - Dropped unused include of linux/debugfs.h
> - Add missing return checks on regmap_write() calls
> - uO -> uOhm in the error message to avoid confusion
> - Move probe-time calibration after enabling runtime PM to avoid it being reverted
> by the PM sync
> - Link to v2: https://lore.kernel.org/r/20260302-ina4230-v2-0-55b49d19d2ab@flipper.net
>
> Changes in v2:
> - Replace u64/u64 division with do_div() (kernel test robot)
> - Add an example with ti,maximum-expected-current-microamp property in
> bindings (Krzysztof Kozlowski)
> - Include the newly added binding in MAINTAINERS file (Krzysztof Kozlowski)
> - Use dev_err_probe() where appropriate in the driver (Krzysztof Kozlowski)
> - Switch to devm_regmap_field_bulk_alloc() instead of an open-coded loop
> - Add a bounds check for the calculated calibration value,
> and a corresponding error message
> - Link to v1: https://lore.kernel.org/r/20260225-ina4230-v1-0-92b1de981d46@flipper.net
>
> ---
> Alexey Charkov (2):
> dt-bindings: hwmon: Add TI INA4230 4-channel I2C power monitor
> hwmon: Add support for TI INA4230 power monitor
>
> .../devicetree/bindings/hwmon/ti,ina4230.yaml | 134 +++
> MAINTAINERS | 7 +
> drivers/hwmon/Kconfig | 11 +
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/ina4230.c | 1032 ++++++++++++++++++++
> 5 files changed, 1185 insertions(+)
> ---
> base-commit: 66ba480978ce390e631e870b740a3406e3eb6b01
> change-id: 20260219-ina4230-74a02409153d
>
> Best regards,
^ permalink raw reply
* Re: [PATCH net-next 3/4] net: dsa: initial MT7628 tagging driver
From: Daniel Golle @ 2026-03-26 23:24 UTC (permalink / raw)
To: Joris Vaisvila
Cc: netdev, horms, pabeni, kuba, edumazet, davem, olteanv,
Andrew Lunn, devicetree, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260326204413.3317584-4-joey@tinyisr.com>
On Thu, Mar 26, 2026 at 10:44:12PM +0200, Joris Vaisvila wrote:
> Add support for the MT7628 embedded switch's tag.
> [...]
> +++ b/net/dsa/tag_mt7628.c
> [...]
> +
> +#define MT7628_TAG_NAME "mt7628"
> +
> +#define MT7628_TAG_TX_PORT_BIT_MASK GENMASK(5, 0)
> +#define MT7628_TAG_RX_PORT_MASK GENMASK(2, 0)
'MASK' vs. 'BIT_MASK'... Maybe just
#define MT7628_TAG_TX_PORT GENMASK(5, 0)
#define MT7628_TAG_RX_PORT GENMASK(2, 0)
> +#define MT7628_TAG_LEN 4
> +
> +static struct sk_buff *mt7628_tag_xmit(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + struct dsa_port *dp;
> + u16 xmit_vlan;
> + __be16 *tag;
> +
> + dp = dsa_user_to_port(dev);
> + xmit_vlan = dsa_tag_8021q_standalone_vid(dp);
> +
> + skb_push(skb, MT7628_TAG_LEN);
> + dsa_alloc_etype_header(skb, MT7628_TAG_LEN);
> +
> + tag = dsa_etype_header_pos_tx(skb);
> +
> + tag[0] = htons(ETH_P_8021Q |
> + FIELD_PREP(MT7628_TAG_TX_PORT_BIT_MASK,
> + dsa_xmit_port_mask(skb, dev)));
> + tag[1] = htons(xmit_vlan);
> +
> + return skb;
> +}
> +
> +static struct sk_buff *mt7628_tag_rcv(struct sk_buff *skb,
> + struct net_device *dev)
> +{
> + int src_port;
> + __be16 *phdr;
> + u16 tpid;
> +
> + if (unlikely(!pskb_may_pull(skb, MT7628_TAG_LEN)))
> + return NULL;
> +
> + phdr = dsa_etype_header_pos_rx(skb);
> + tpid = ntohs(*phdr);
Why not directly
src_port = FIELD_GET(MT7628_TAG_RX_PORT, ntohs(*phdr));
tpid isn't used for anything else (at this point).
Or even getting rid of both stack variables:
skb->dev = dsa_conduit_find_user(dev, 0, FIELD_GET(MT7628_TAG_RX_PORT,
ntohs(*phdr)));
(though the compiler probably treats both forms equally or
almost equally)
> + skb_pull_rcsum(skb, MT7628_TAG_LEN);
> + dsa_strip_etype_header(skb, MT7628_TAG_LEN);
> +
> + src_port = tpid & MT7628_TAG_RX_PORT_MASK;
As you are using FIELD_PREP above for something which also could as well
just be an & operation, I would say you should then also use FIELD_GET here,
just to maintain an consistent style. And potentially move up to get rid
of the stack variables, see above.
> +
> + skb->dev = dsa_conduit_find_user(dev, 0, src_port);
> + if (!skb->dev)
> + return NULL;
> + dsa_default_offload_fwd_mark(skb);
> + return skb;
> +}
^ permalink raw reply
* Re: [PATCH net-next 1/4] dt-bindings: net: dsa: add MT7628 ESW
From: Daniel Golle @ 2026-03-26 23:11 UTC (permalink / raw)
To: Joris Vaisvila
Cc: netdev, horms, pabeni, kuba, edumazet, davem, olteanv,
Andrew Lunn, devicetree, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
In-Reply-To: <20260326204413.3317584-2-joey@tinyisr.com>
On Thu, Mar 26, 2026 at 10:44:10PM +0200, Joris Vaisvila wrote:
> Add bindings for MT7628 SoC's Embedded Switch.
> [...]
> diff --git a/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
> new file mode 100644
> index 000000000000..d3c9df30ed5a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/dsa/mediatek,mt7628-esw.yaml
> @@ -0,0 +1,101 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/net/dsa/mediatek,mt7628-esw.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Mediatek MT7628 Embedded Ethernet Switch
> +
> +maintainers:
> + - Joris Vaisvila <joey@tinyisr.com>
> +
> +description:
> + The MT7628 SoC's built-in Ethernet Switch is a five port switch with
> + integrated 10/100 PHYs. The switch registers are directly mapped in the SoC's
> + memory. The switch has an internally connected 1G CPU port and 5 user ports
> + connected to the built-in Fast Ethernet PHYs.
> +
> [...]
> + port@6 {
> + reg = <6>;
> + ethernet = <ðernet>;
> + phy-mode = "rgmii";
Is this actually RGMII internally? Or some unknown internal way to
wire the switch CPU port to the CPU MAC? In this case, "internal"
should be used here as well.
^ permalink raw reply
* [PATCH v4 2/2] arm64: dts: rockchip: add mipi csi-2 receiver nodes to rk3588
From: Michael Riesch via B4 Relay @ 2026-03-26 23:10 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart, Frank Li,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Kever Yang, Collabora Kernel Team
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
In-Reply-To: <20260305-rk3588-csi2rx-v4-0-81c6bcfefa63@collabora.com>
From: Michael Riesch <michael.riesch@collabora.com>
The Rockchip RK3588 features six MIPI CSI-2 receiver units:
- MIPI0: connected to MIPI DCPHY0 (not supported)
- MIPI1: connected to MIPI DCPHY1 (not supported)
- MIPI2: connected to MIPI DPHY0
- MIPI3: connected to MIPI DPHY0-1 (not supported)
- MIPI4: connected to MIPI DPHY1
- MIPI5: connected to MIPI DPHY1-1 (not supported)
As the MIPI DCPHYs as well as the split DPHY mode of the DPHYs
are not yet supported, add only the device tree nodes for the
MIPI2 and MIPI4 units.
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 52 +++++++++++++++++++++++++++
1 file changed, 52 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
index 7fe9593d8c19..6c593b0255c3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi
@@ -1430,6 +1430,58 @@ av1d: video-codec@fdc70000 {
resets = <&cru SRST_A_AV1>, <&cru SRST_P_AV1>, <&cru SRST_A_AV1_BIU>, <&cru SRST_P_AV1_BIU>;
};
+ csi2: csi@fdd30000 {
+ compatible = "rockchip,rk3588-mipi-csi2", "rockchip,rk3568-mipi-csi2";
+ reg = <0x0 0xfdd30000 0x0 0x10000>;
+ interrupts = <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "err1", "err2";
+ clocks = <&cru PCLK_CSI_HOST_2>;
+ phys = <&csi_dphy0>;
+ power-domains = <&power RK3588_PD_VI>;
+ resets = <&cru SRST_P_CSI_HOST_2>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi2_in: port@0 {
+ reg = <0>;
+ };
+
+ csi2_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
+ csi4: csi@fdd50000 {
+ compatible = "rockchip,rk3588-mipi-csi2", "rockchip,rk3568-mipi-csi2";
+ reg = <0x0 0xfdd50000 0x0 0x10000>;
+ interrupts = <GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH 0>;
+ interrupt-names = "err1", "err2";
+ clocks = <&cru PCLK_CSI_HOST_4>;
+ phys = <&csi_dphy1>;
+ power-domains = <&power RK3588_PD_VI>;
+ resets = <&cru SRST_P_CSI_HOST_4>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ csi4_in: port@0 {
+ reg = <0>;
+ };
+
+ csi4_out: port@1 {
+ reg = <1>;
+ };
+ };
+ };
+
vop: vop@fdd90000 {
compatible = "rockchip,rk3588-vop";
reg = <0x0 0xfdd90000 0x0 0x4200>, <0x0 0xfdd95000 0x0 0x1000>;
--
2.39.5
^ permalink raw reply related
* [PATCH v4 0/2] media: synopsys: csi2rx: add support for rk3588 variant
From: Michael Riesch via B4 Relay @ 2026-03-26 23:09 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Sakari Ailus, Laurent Pinchart, Frank Li,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Kever Yang, Collabora Kernel Team
Cc: linux-media, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel, Michael Riesch
Habidere,
The Rockchip RK3588 features six MIPI CSI-2 receiver units:
- MIPI0: connected to MIPI DCPHY0
- MIPI1: connected to MIPI DCPHY1
- MIPI2: connected to MIPI DPHY0
- MIPI3: connected to MIPI DPHY0-1 (only with split DPHY0)
- MIPI4: connected to MIPI DPHY1
- MIPI5: connected to MIPI DPHY1-1 (only with split DPHY1)
The MIPI DCPHYs (at least the CSI-2 features of them) as well
as the split DPHY mode of the DPHYs are not yet supported by
mainline. However, we can already provide support for the
MIPI2 and MIPI4 units.
When support for the split DPHY mode is introduced, the DPHY
nodes should have the property
#phy-cells = <1>;
and the MIPI CSI-2 receiver nodes should have the property
phys = <&csi_dphy{0,1} {0,1}>;
in case the split mode is desired. Since this is a board
specific hardware design, the properties need to be changed
in the board device tree (or any overlays).
As reasonable default, however, we can define, e.g.,
#phy-cells = <0>;
and
phys = <&csi_dphy{0,1}>;
in the SoC device tree include.
This series introduces initial support for this default
configuration.
Looking forward to your comments!
Signed-off-by: Michael Riesch <michael.riesch@collabora.com>
---
Changes in v4:
- rebased onto media-commiters/next again (as Frank's patches
are now there)
- changed "oneOf entries to enum in dt binding (Rob)
- Link to v3: https://lore.kernel.org/r/20260305-rk3588-csi2rx-v3-0-754473981f39@collabora.com
Changes in v3:
- rebased onto Sakari's cleanup branch (as Frank's patches were
merged) (Sakari)
- added Rob's Acked-by
- Link to v2: https://lore.kernel.org/r/20260305-rk3588-csi2rx-v2-0-79d01b615486@collabora.com
Changes in v2:
- use fallback compatible instead of separate compatible (Krzysztof)
- dropped patch 2 and 4 (as a consequence thereof)
- Link to v1: https://lore.kernel.org/r/20260305-rk3588-csi2rx-v1-0-0cd8d2bf28c0@collabora.com
---
Michael Riesch (2):
media: dt-bindings: rockchip,rk3568-mipi-csi2: add rk3588 compatible
arm64: dts: rockchip: add mipi csi-2 receiver nodes to rk3588
.../bindings/media/rockchip,rk3568-mipi-csi2.yaml | 11 +++--
arch/arm64/boot/dts/rockchip/rk3588-base.dtsi | 52 ++++++++++++++++++++++
2 files changed, 60 insertions(+), 3 deletions(-)
---
base-commit: 4fbeef21f5387234111b5d52924e77757626faa5
change-id: 20260305-rk3588-csi2rx-a11f7c15a40a
Best regards,
--
Michael Riesch <michael.riesch@collabora.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox