* [PATCH v4 1/4] dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
From: nick.hawkins @ 2026-04-06 14:38 UTC (permalink / raw)
To: catalin.marinas, will, robh, krzk+dt, conor+dt
Cc: nick.hawkins, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260406143821.1843621-1-nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Add the HPE GSC ARM64 BMC SoC compatibles to the existing
hpe,gxp.yaml binding.
The initial board compatible is hpe,gsc-dl340gen12 for the DL340 Gen12
server platform.
Add the arm64 DTS path to the existing ARM/HPE GXP MAINTAINERS entry,
renamed to ARM/HPE GXP/GSC ARCHITECTURE.
Signed-off-by: Nick Hawkins <nick.hawkins@hpe.com>
---
Documentation/devicetree/bindings/arm/hpe,gxp.yaml | 7 ++++++-
MAINTAINERS | 3 ++-
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
index 224bbcb93f95..6f057cd58571 100644
--- a/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
+++ b/Documentation/devicetree/bindings/arm/hpe,gxp.yaml
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/arm/hpe,gxp.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: HPE BMC GXP platforms
+title: HPE BMC GXP and GSC platforms
maintainers:
- Nick Hawkins <nick.hawkins@hpe.com>
@@ -15,6 +15,11 @@ properties:
oneOf:
+ - description: GSC Based Boards
+ items:
+ - enum:
+ - hpe,gsc-dl340gen12
+ - const: hpe,gsc
- description: GXP Based Boards
items:
- enum:
- hpe,gxp-dl360gen10
- const: hpe,gxp
required:
- compatible
diff --git a/MAINTAINERS b/MAINTAINERS
index 2265e2c9bfbe..80c66de5e342 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2859,7 +2859,7 @@ T: git git://git.kernel.org/pub/scm/linux/kernel/git/kristoffer/linux-hpc.git
F: arch/arm/mach-sa1100/include/mach/jornada720.h
F: arch/arm/mach-sa1100/jornada720.c
-ARM/HPE GXP ARCHITECTURE
+ARM/HPE GXP/GSC ARCHITECTURE
M: Jean-Marie Verdun <verdun@hpe.com>
M: Nick Hawkins <nick.hawkins@hpe.com>
S: Maintained
@@ -2870,6 +2870,7 @@ F: Documentation/devicetree/bindings/spi/hpe,gxp-spifi.yaml
F: Documentation/devicetree/bindings/timer/hpe,gxp-timer.yaml
F: Documentation/hwmon/gxp-fan-ctrl.rst
F: arch/arm/boot/dts/hpe/
+F: arch/arm64/boot/dts/hpe/
F: drivers/clocksource/timer-gxp.c
F: drivers/hwmon/gxp-fan-ctrl.c
F: drivers/i2c/busses/i2c-gxp.c
--
2.34.1
^ permalink raw reply related
* [PATCH v4 0/4] arm64: Add HPE GSC platform support
From: nick.hawkins @ 2026-04-06 14:38 UTC (permalink / raw)
To: catalin.marinas, will, robh, krzk+dt, conor+dt
Cc: nick.hawkins, linux-arm-kernel, devicetree, linux-kernel
From: Nick Hawkins <nick.hawkins@hpe.com>
From: Nick Hawkins <nick.hawkins@hpe.com>
Add initial platform support for the HPE GSC ARM64 BMC SoC.
Changes since v3:
- Patch 1: Moved GSC entry before GXP in hpe,gxp.yaml to maintain
alphabetical ordering by fallback compatible (Krzysztof Kozlowski)
- Patch 2: Added Reviewed-by from Krzysztof Kozlowski
- Patch 3: Changed SPDX in gsc-dl340gen12.dts from GPL-2.0-only to
GPL-2.0 to be consistent with gsc.dtsi (Krzysztof Kozlowski);
reordered nodes within soc by ascending unit-address, placing UARTs
before GIC per DTS coding style (Krzysztof Kozlowski);
moved interrupt-parent before interrupts in timer and all UART nodes
per DTS coding style (Krzysztof Kozlowski);
reordered root-level nodes alphabetically: clock-33333333 before cpus
before timer per DTS coding style (Krzysztof Kozlowski);
reordered properties within all nodes to follow DTS coding style:
compatible, reg first, then remaining alphabetically (Krzysztof
Kozlowski)
- Patch 4: New patch adding CONFIG_ARCH_HPE=y to arm64 defconfig
(Krzysztof Kozlowski)
Nick Hawkins (4):
dt-bindings: arm: hpe,gxp: Add HPE GSC platform compatible
arm64: Kconfig: Add ARCH_HPE platform
arm64: dts: hpe: Add HPE GSC SoC and DL340 Gen12 board DTS
arm64: defconfig: Enable ARCH_HPE
.../devicetree/bindings/arm/hpe,gxp.yaml | 7 +-
MAINTAINERS | 3 +-
arch/arm64/Kconfig.platforms | 11 ++
arch/arm64/boot/dts/hpe/Makefile | 2 +
arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts | 18 +++
arch/arm64/boot/dts/hpe/gsc.dtsi | 104 ++++++++++++++++++
arch/arm64/configs/defconfig | 1 +
7 files changed, 144 insertions(+), 2 deletions(-)
create mode 100644 arch/arm64/boot/dts/hpe/Makefile
create mode 100644 arch/arm64/boot/dts/hpe/gsc-dl340gen12.dts
create mode 100644 arch/arm64/boot/dts/hpe/gsc.dtsi
--
2.34.1
^ permalink raw reply
* Re: [PATCH v5 2/2] phy: qcom-mipi-csi2: Add a CSI2 MIPI DPHY driver
From: Abel Vesa @ 2026-04-06 14:28 UTC (permalink / raw)
To: Bryan O'Donoghue
Cc: Vinod Koul, Kishon Vijay Abraham I, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
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 26-03-26 01:04:44, Bryan O'Donoghue wrote:
> Add a new MIPI CSI2 driver in DPHY mode initially. The entire set of
> existing CAMSS CSI PHY init sequences are imported in order to save time
> and effort in later patches.
>
> The following devices are supported in this drop:
> "qcom,x1e80100-csi2-phy"
>
> In-line with other PHY drivers the process node is included in the name.
> Data-lane and clock lane positioning and polarity selection via newly
> amended struct phy_configure_opts_mipi_dphy{} is supported.
>
> The Qualcomm 3PH class of PHYs can do both DPHY and CPHY mode. For now only
> DPHY is supported.
>
> In porting some of the logic over from camss-csiphy*.c to here its also
> possible to rationalise some of the code.
>
> In particular use of regulator_bulk and clk_bulk as well as dropping the
> seemingly useless and unused interrupt handler.
>
> The PHY sequences and a lot of the logic that goes with them are well
> proven in CAMSS and mature so the main thing to watch out for here is how
> to get the right sequencing of regulators, clocks and register-writes.
>
> The register init sequence table is imported verbatim from the existing
> CAMSS csiphy driver. A follow-up series will rework the table to extract
> the repetitive per-lane pattern into a loop.
>
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
> MAINTAINERS | 11 +
> drivers/phy/qualcomm/Kconfig | 13 +
> drivers/phy/qualcomm/Makefile | 5 +
> drivers/phy/qualcomm/phy-qcom-mipi-csi2-3ph-dphy.c | 361 +++++++++++++++++++++
> drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c | 298 +++++++++++++++++
> drivers/phy/qualcomm/phy-qcom-mipi-csi2.h | 95 ++++++
> 6 files changed, 783 insertions(+)
>
[...]
> diff --git a/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
> new file mode 100644
> index 0000000000000..47acf0d586a15
> --- /dev/null
> +++ b/drivers/phy/qualcomm/phy-qcom-mipi-csi2-core.c
> @@ -0,0 +1,298 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2025, Linaro Ltd.
> + */
> +#include <linux/clk.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/io.h>
> +#include <linux/kernel.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/pm_opp.h>
> +#include <linux/phy/phy.h>
> +#include <linux/phy/phy-mipi-dphy.h>
> +#include <linux/platform_device.h>
> +#include <linux/pm_domain.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/reset.h>
> +#include <linux/slab.h>
> +
> +#include <dt-bindings/phy/phy-qcom-mipi-csi2.h>
> +
> +#include "phy-qcom-mipi-csi2.h"
> +
> +static int
> +phy_qcom_mipi_csi2_set_clock_rates(struct mipi_csi2phy_device *csi2phy,
> + s64 link_freq)
> +{
> + struct device *dev = csi2phy->dev;
> + unsigned long opp_rate = link_freq / 4;
> + struct dev_pm_opp *opp;
> + long timer_rate;
> + int ret;
> +
> + opp = dev_pm_opp_find_freq_ceil(dev, &opp_rate);
> + if (IS_ERR(opp)) {
> + dev_err(csi2phy->dev, "Couldn't find ceiling for %lld Hz\n",
> + link_freq);
> + return PTR_ERR(opp);
> + }
> +
> + for (int i = 0; i < csi2phy->num_pds; i++) {
> + unsigned int perf = dev_pm_opp_get_required_pstate(opp, i);
> +
> + ret = dev_pm_genpd_set_performance_state(csi2phy->pds[i], perf);
> + if (ret) {
> + dev_err(csi2phy->dev, "Couldn't set perf state %u\n",
> + perf);
> + dev_pm_opp_put(opp);
> + return ret;
> + }
> + }
> + dev_pm_opp_put(opp);
> +
> + ret = dev_pm_opp_set_rate(dev, opp_rate);
> + if (ret) {
> + dev_err(csi2phy->dev, "dev_pm_opp_set_rate() fail\n");
> + return ret;
> + }
> +
> + timer_rate = clk_round_rate(csi2phy->timer_clk, link_freq / 4);
> + if (timer_rate < 0)
> + return timer_rate;
> +
> + ret = clk_set_rate(csi2phy->timer_clk, timer_rate);
> + if (ret)
> + return ret;
> +
> + csi2phy->timer_clk_rate = timer_rate;
> +
> + return 0;
> +}
> +
> +static int phy_qcom_mipi_csi2_configure(struct phy *phy,
> + union phy_configure_opts *opts)
> +{
> + struct mipi_csi2phy_device *csi2phy = phy_get_drvdata(phy);
> + struct phy_configure_opts_mipi_dphy *dphy_cfg = &opts->mipi_dphy;
> + struct mipi_csi2phy_stream_cfg *stream_cfg = &csi2phy->stream_cfg;
> + int ret;
> + int i;
> +
> + ret = phy_mipi_dphy_config_validate(dphy_cfg);
> + if (ret)
> + return ret;
> +
> + if (dphy_cfg->lanes < 1 || dphy_cfg->lanes > CSI2_MAX_DATA_LANES)
> + return -EINVAL;
> +
> + stream_cfg->link_freq = dphy_cfg->hs_clk_rate;
> + stream_cfg->num_data_lanes = dphy_cfg->lanes;
> +
> + for (i = 0; i < stream_cfg->num_data_lanes; i++) {
> + stream_cfg->lane_cfg.data[i].pol = dphy_cfg->lane_polarities[i];
> + stream_cfg->lane_cfg.data[i].pos = dphy_cfg->lane_positions[i];
> + }
> +
> + stream_cfg->lane_cfg.clk.pol = dphy_cfg->clock_lane_polarity;
> + stream_cfg->lane_cfg.clk.pos = dphy_cfg->clock_lane_position;
> +
> + return 0;
> +}
> +
> +static int phy_qcom_mipi_csi2_power_on(struct phy *phy)
> +{
> + struct mipi_csi2phy_device *csi2phy = phy_get_drvdata(phy);
> + const struct mipi_csi2phy_hw_ops *ops = csi2phy->soc_cfg->ops;
> + struct device *dev = &phy->dev;
> + int ret;
> +
> + ret = regulator_bulk_enable(csi2phy->soc_cfg->num_supplies,
> + csi2phy->supplies);
> + if (ret)
> + return ret;
> +
> + ret = phy_qcom_mipi_csi2_set_clock_rates(csi2phy, csi2phy->stream_cfg.link_freq);
> + if (ret)
> + goto poweroff_phy;
> +
> + ret = clk_bulk_prepare_enable(csi2phy->soc_cfg->num_clk,
> + csi2phy->clks);
> + if (ret) {
> + dev_err(dev, "failed to enable clocks, %d\n", ret);
> + goto poweroff_phy;
> + }
> +
> + ops->reset(csi2phy);
> +
> + ops->hw_version_read(csi2phy);
> +
> + return ops->lanes_enable(csi2phy, &csi2phy->stream_cfg);
> +
> +poweroff_phy:
> + regulator_bulk_disable(csi2phy->soc_cfg->num_supplies,
> + csi2phy->supplies);
> +
> + return ret;
> +}
> +
> +static int phy_qcom_mipi_csi2_power_off(struct phy *phy)
> +{
> + struct mipi_csi2phy_device *csi2phy = phy_get_drvdata(phy);
> + int i;
> +
> + for (i = 0; i < csi2phy->num_pds; i++)
> + dev_pm_genpd_set_performance_state(csi2phy->pds[i], 0);
> +
> + clk_bulk_disable_unprepare(csi2phy->soc_cfg->num_clk,
> + csi2phy->clks);
> + regulator_bulk_disable(csi2phy->soc_cfg->num_supplies,
> + csi2phy->supplies);
> +
> + return 0;
> +}
> +
> +static const struct phy_ops phy_qcom_mipi_csi2_ops = {
> + .configure = phy_qcom_mipi_csi2_configure,
> + .power_on = phy_qcom_mipi_csi2_power_on,
> + .power_off = phy_qcom_mipi_csi2_power_off,
> + .owner = THIS_MODULE,
> +};
> +
> +static struct phy *qcom_csi2_phy_xlate(struct device *dev,
> + const struct of_phandle_args *args)
> +{
> + struct mipi_csi2phy_device *csi2phy = dev_get_drvdata(dev);
> +
> + if (args->args[0] != PHY_QCOM_CSI2_MODE_DPHY) {
> + dev_err(csi2phy->dev, "mode %d -EOPNOTSUPP\n", args->args[0]);
> + return ERR_PTR(-EOPNOTSUPP);
> + }
> +
> + csi2phy->phy_mode = args->args[0];
> +
> + return csi2phy->phy;
> +}
> +
> +static int phy_qcom_mipi_csi2_probe(struct platform_device *pdev)
> +{
> + unsigned int i, num_clk, num_supplies, num_pds;
> + struct mipi_csi2phy_device *csi2phy;
> + struct phy_provider *phy_provider;
> + struct device *dev = &pdev->dev;
> + struct phy *generic_phy;
> + int ret;
> +
> + csi2phy = devm_kzalloc(dev, sizeof(*csi2phy), GFP_KERNEL);
> + if (!csi2phy)
> + return -ENOMEM;
> +
> + csi2phy->dev = dev;
> + dev_set_drvdata(dev, csi2phy);
> +
> + csi2phy->soc_cfg = device_get_match_data(&pdev->dev);
> +
> + if (!csi2phy->soc_cfg)
> + return -EINVAL;
> +
> + num_clk = csi2phy->soc_cfg->num_clk;
> + csi2phy->clks = devm_kzalloc(dev, sizeof(*csi2phy->clks) * num_clk, GFP_KERNEL);
> + if (!csi2phy->clks)
> + return -ENOMEM;
> +
> + num_pds = csi2phy->soc_cfg->num_genpd_names;
> + if (!num_pds)
> + return -EINVAL;
> +
> + csi2phy->pds = devm_kzalloc(dev, sizeof(*csi2phy->pds) * num_pds, GFP_KERNEL);
> + if (!csi2phy->pds)
> + return -ENOMEM;
> +
> + for (i = 0; i < num_pds; i++) {
> + csi2phy->pds[i] = dev_pm_domain_attach_by_name(dev,
> + csi2phy->soc_cfg->genpd_names[i]);
You need to do detach these on error, otherwise you get:
sysfs: cannot create duplicate filename '/devices/genpd:0:acec000.phy'
CPU: 1 UID: 0 PID: 93 Comm: kworker/u49:2 Not tainted 7.0.0-rc6-00062-gd691cf9ea708 #12 PREEMPT
Hardware name: Dell Inc. XPS 13 9345/05H2K4, BIOS 2.11.0 09/21/2025
Workqueue: events_unbound deferred_probe_work_func
show_stack+0x18/0x24 (C)
dump_stack_lvl+0x60/0x80
dump_stack+0x18/0x24
sysfs_warn_dup+0x64/0x80
sysfs_create_dir_ns+0xf4/0x120
kobject_add_internal+0x98/0x260
kobject_add+0x9c/0x108
device_add+0xc4/0x7ac
device_register+0x20/0x34
genpd_dev_pm_attach_by_id+0xdc/0x1cc
genpd_dev_pm_attach_by_name+0x3c/0x78
dev_pm_domain_attach_by_name+0x20/0x2c
phy_qcom_mipi_csi2_probe+0xe0/0x420 [phy_qcom_mipi_csi2]
platform_probe+0x5c/0xa4
really_probe+0xbc/0x2c0
__driver_probe_device+0x78/0x120
driver_probe_device+0x3c/0x154
__device_attach_driver+0xb8/0x140
bus_for_each_drv+0x88/0xe8
__device_attach+0xa0/0x190
device_initial_probe+0x50/0x54
bus_probe_device+0x38/0xac
device_add+0x5c4/0x7ac
of_device_add+0x44/0x60
of_platform_device_create_pdata+0x8c/0x11c
of_platform_bus_create+0x190/0x38c
of_platform_populate+0x74/0x108
devm_of_platform_populate+0x58/0xc0
camss_probe+0x3c/0xce0 [qcom_camss]
platform_probe+0x5c/0xa4
really_probe+0xbc/0x2c0
__driver_probe_device+0x78/0x120
driver_probe_device+0x3c/0x154
__device_attach_driver+0xb8/0x140
bus_for_each_drv+0x88/0xe8
__device_attach+0xa0/0x190
device_initial_probe+0x50/0x54
bus_probe_device+0x38/0xac
deferred_probe_work_func+0x90/0xc8
process_one_work+0x154/0x294
worker_thread+0x18c/0x300
kthread+0x118/0x124
ret_from_fork+0x10/0x20
kobject: kobject_add_internal failed for genpd:0:acec000.phy with -EEXIST, don't try to register things with the same name in the same directory.
qcom-mipi-csi2-phy acec000.phy: error -EEXIST: Failed to attach mx
qcom-mipi-csi2-phy acec000.phy: probe with driver qcom-mipi-csi2-phy failed with error -17
^ permalink raw reply
* Re: [PATCH v6 2/2] dt-bindings: embedded-controller: Add synology microp devices
From: Markus Probst @ 2026-04-06 14:22 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Hans de Goede, Ilpo Järvinen, Bryan O'Donoghue,
Lee Jones, Pavel Machek, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, platform-driver-x86, linux-leds,
devicetree, linux-kernel, rust-for-linux
In-Reply-To: <20260406-ancient-amethyst-poodle-1ba0b2@quoll>
[-- Attachment #1: Type: text/plain, Size: 6406 bytes --]
On Mon, 2026-04-06 at 09:59 +0200, Krzysztof Kozlowski wrote:
> On Sun, Apr 05, 2026 at 07:36:29PM +0200, Markus Probst wrote:
> > Add the Synology Microp devicetree bindings. Those devices are
> > microcontrollers found on Synology NAS devices. They are connected to a
> > serial port on the host device.
> >
> > Those devices are used to control certain LEDs, fan speeds, a beeper, to
> > handle buttons, fan failures and to properly shutdown and reboot the
> > device.
> >
> > This includes the following compatible ids:
> > - synology,ds923p-microp
> > - synology,ds918p-microp
> > - synology,ds214play-microp
> > - synology,ds225p-microp
> > - synology,ds425p-microp
> > - synology,ds710p-microp
> > - synology,ds1010p-microp
> > - synology,ds723p-microp
> > - synology,ds1522p-microp
> > - synology,rs422p-microp
> > - synology,ds725p-microp
> > - synology,ds118-microp
> > - synology,ds124-microp
> > - synology,ds223-microp
> > - synology,ds223j-microp
> > - synology,ds1823xsp-microp
> > - synology,rs822p-microp
> > - synology,rs1221p-microp
> > - synology,rs1221rpp-microp
> > - synology,ds925p-microp
> > - synology,ds1525p-microp
> > - synology,ds1825p-microp
>
> Drop, we see this in the diff.
A prior review commit suggested I should add them [1].
So only synology,ds923p-microp in the Subject then?
[1]
https://lore.kernel.org/all/20260330-delicate-sassy-mayfly-ebcca7@quoll/
>
> >
> > Signed-off-by: Markus Probst <markus.probst@posteo.de>
> > ---
> > .../synology,ds923p-microp.yaml | 112 +++++++++++++++++++++
> > MAINTAINERS | 1 +
> > 2 files changed, 113 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
> > new file mode 100644
> > index 000000000000..4518e9b74be1
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/embedded-controller/synology,ds923p-microp.yaml
> > @@ -0,0 +1,112 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/embedded-controller/synology,ds923p-microp.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Synology NAS on-board Microcontroller
> > +
> > +maintainers:
> > + - Markus Probst <markus.probst@posteo.de>
> > +
> > +description: |
> > + Synology Microp is a microcontroller found in Synology NAS devices.
> > + It is connected to a serial port on the host device.
> > +
> > + It is necessary to properly shutdown and reboot the NAS device and
> > + provides additional functionality such as led control, fan speed control,
> > + a beeper and buttons on the NAS device.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - synology,ds923p-microp
> > + - synology,ds918p-microp
> > + - synology,ds214play-microp
> > + - synology,ds225p-microp
> > + - synology,ds425p-microp
> > + - synology,ds710p-microp
> > + - synology,ds1010p-microp
> > + - synology,ds723p-microp
> > + - synology,ds1522p-microp
> > + - synology,rs422p-microp
> > + - synology,ds725p-microp
> > + - synology,ds118-microp
> > + - synology,ds124-microp
> > + - synology,ds223-microp
> > + - synology,ds223j-microp
> > + - synology,ds1823xsp-microp
> > + - synology,rs822p-microp
> > + - synology,rs1221p-microp
> > + - synology,rs1221rpp-microp
> > + - synology,ds925p-microp
> > + - synology,ds1525p-microp
> > + - synology,ds1825p-microp
>
> So we already talked about this and you were told to use compatibility.
> Your driver clearly states several of these are compatible, so I am
> confused that I do not see it expressed here.
The driver does not have all functionality implemented yet.
A few examples of differences not yet visible in the driver:
- synology,ds214play-microp is the only model in the current list to
have an cpu fan
- 4 of the models are arm based and need a different shutdown behaviour
- different amount of fans (already present in the binding via fan-
failure-gpios)
I could try to group them together, but Synology does not document the
exact difference between them.
As Rob mentioned [2], I need to be able to handle unexpected
differences without qurik properties.
[2]
https://lore.kernel.org/all/CAL_JsqJUVh1YnhmYYj4ara5BheaLOL1oayjtWNuPH53q1d4xXA@mail.gmail.com/
>
> > +
> > + fan-failure-gpios:
> > + description: GPIOs needed to determine which fans stopped working on a fan failure event.
> > + minItems: 2
> > + maxItems: 3
> > +
> > +required:
> > + - compatible
> > +
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - synology,ds214play-microp
> > + - synology,ds225p-microp
> > + - synology,ds710p-microp
> > + - synology,ds723p-microp
> > + - synology,ds725p-microp
> > + - synology,ds118-microp
> > + - synology,ds124-microp
> > + - synology,ds223-microp
> > + - synology,ds223j-microp
> > + - synology,ds1823xsp-microp
> > + - synology,rs822p-microp
> > + - synology,rs1221p-microp
> > + - synology,rs1221rpp-microp
> > + - synology,ds1825p-microp
> > + then:
> > + properties:
> > + fan-failure-gpios: false
> > + else:
> > + required:
> > + - fan-failure-gpios
> > +
> > +additionalProperties: false
> > +
> > +examples:
> > + - |
> > + #include <dt-bindings/leds/common.h>
> > + #include <dt-bindings/gpio/gpio.h>
> > +
> > + embedded-controller {
> > + compatible = "synology,ds923p-microp";
> > +
> > + fan-failure-gpios = <&gpio 68 GPIO_ACTIVE_HIGH>, <&gpio 69 GPIO_ACTIVE_HIGH>;
>
> Keep only one example, they are basically the same. Difference in one
> property does not need a new example.
Ok, it seemed like a nice convenient way to automatically test the if
blocks.
Thanks
- Markus Probst
>
> Best regards,
> Krzysztof
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 870 bytes --]
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 14:20 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <83971700-ea17-4fd5-8985-68c798222800@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Monday, April 6, 2026 4:57 PM
...
> >
> > I also have to mention that the oversampling commit would then implement
> > AD4691_MANUAL_CHANNEL macro which would miss the OVERSAMPLING
> > infomask, and offload_manual_channels will be declared using it.
> > More than this, that commit would also add other
> ad4691_manual_channels[]
> > and ad4693_manual_channels[] arrays that would use that MACRO as well.
> >
> > Then, chip_info would have ad4691/93_channels assigned to it by default,
> > and indio_dev->channels will later be assigned at probe, depending on the
> > mode and offload.
> >
> > If different chip_info structs would be wanted still, then my best guess is
> > to have different info structures (perhaps new types) in chip_info by default.
> > Something like *sw_info and *offload_info.
>
> Yes, this is how I would do it too.
>
Ok then, will have different chip infos and each one will have respective channels
to them. Thanks for this, too!
^ permalink raw reply
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 14:16 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <420dba4a-0c31-47bc-b84a-5d29702b115e@baylibre.com>
> -----Original Message-----
> From: David Lechner <dlechner@baylibre.com>
> Sent: Monday, April 6, 2026 4:44 PM
...
> >
> > This is bad documentation on my part. "channel byte" isn't used anymore,
> > this is previous version behaviour. Right now, only 16-bits worth of actual
> > channel data are used.
> >
> Then why do we need the shift if there is no other data? Can't we rework
> the SPI message so that there is no shift?
I thought the shift is needed since DMA size is 32 bits, and value comes on the
upper word 16 bits, not on the lower ones as for CNV Burst.
Manual Mode layout: TX [CMD_HI CMD_LO DUMMY DUMMY], RX [DATA_HI DATA_LO DUMMY DUMMY]
CNV Burst layout: TX [REG_HI REG_LO DUMMY DUMMY], RX [DUMMY DUMMY DATA_HI DATA_LO]
^ permalink raw reply
* Re: [PATCH 0/4] ASoC: Add support for GPIOs driven amplifiers
From: Mark Brown @ 2026-04-06 14:08 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Herve Codina, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Saravana Kannan, Jaroslav Kysela, Takashi Iwai,
linux-sound, devicetree, linux-kernel, Christophe Leroy,
Thomas Petazzoni
In-Reply-To: <32fc8606-d475-4cc0-b2a1-c5549aef402f@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Sun, Apr 05, 2026 at 07:00:20PM +0200, Christophe Leroy (CS GROUP) wrote:
> Le 30/03/2026 à 18:41, Herve Codina a écrit :
> > I could merge everything in one .c file but only a few part of source code
> > will be common to simple-amplifier and audio-gpio-amp. IMHO the resulting
> > merged code will look like two different drivers merged in one .c file.
> Following explanation from Herve I have the feeling that combining the two
> drivers into a single one will bring more complexity for little benefit.
> Do you still think it is worth having a combined driver allthough they
> address quite different setups ?
Yes, it's just a difference in the binding not in the runtime stuff.
The two will inevitably grow together over time, keeping them separate
is just creating a long term bikeshedding problem wondering which to use
for a given situation.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: David Lechner @ 2026-04-06 13:56 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414BB41577A8B5A0432463FF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
On 4/6/26 8:30 AM, Sabau, Radu bogdan wrote:
>
>
>> -----Original Message-----
>> From: Sabau, Radu bogdan
>> Sent: Monday, April 6, 2026 2:08 PM
>>
>> ...
>>
>>>>> #define AD4691_CHANNEL(ch)
>>>> \
>>>>> { \
>>>>> .type = IIO_VOLTAGE, \
>>>>> @@ -122,11 +155,9 @@ struct ad4691_chip_info {
>>>>> .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
>>>> \
>>>>> .channel = ch, \
>>>>> .scan_index = ch, \
>>>>> - .scan_type = { \
>>>>> - .sign = 'u', \
>>>>> - .realbits = 16, \
>>>>> - .storagebits = 16, \
>>>>> - }, \
>>>>> + .has_ext_scan_type = 1,
>>>> \
>>>>> + .ext_scan_type = ad4691_scan_types, \
>>>>> + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
>>>> \
>>>>
>>>> Usually, we just make two separte ad4691_chip_info structs for offload
>>>> vs. not offload.
>>>>
>>>> ext_scan_type is generally only used when the scan type can change
>>>> dynamically after probe.
>>>>
>>>
>>> So, just to be clear, you are saying I should have different chip_info structs
>>> and change the triggered-buffer for offload ones if offload is present?
>>> I am asking since offload has different scan types as well, and this would
>>> mean 3 different chip_info structs for each chip -> total of 12 chip_info
>> structs,
>>> each with a different channel array, or perhaps there is a more compact way
>>> to have this implemented.
>>> I could make the channel arrays use the same macro and have the scan_type
>>> reversed to storage and shift done as parameters.
>>>
>>
>> I have given this a thought and I think this could be done in a more compact
>> way:
>>
>> 1. Parametrize AD4691_CHANNEL to accept storagebits and shift, then define
>> 4 channel
>> arrays:
>>
>> - ad4691_channels[] - 16ch + timestamp (triggered-buffer path)
>> - ad4693_channels[] - 8ch + timestamp (triggered-buffer path)
>> - ad4691_offload_cnv_channels[] - 16 entries, storagebits=32, shift =
>> 0
>> - ad4691_offload_manual_channels[] - 16 entries, storagebits=32,
>> shift=16
>>
>> The two offload arrays are shared across both chip families. Since
>> num_channels
>> bound the interation in the IIO core, the 8ch chips simply use the first 8
>> entries of
>> the 16-entry offload arrays. Triggered-buffer path would need different
>> channel
>> arrays since the timestamp index would be different, and offload doesn't use
>> timestamp.
>>
>> 2. chip_info could then stay at 2 structs, and have channels selected at probe
>> for the
>> indio_dev, or have 4 chip info structs each having its own channels assigned,
>> and only
>> num_channels could be changed at probe.
>>
>
> I also have to mention that the oversampling commit would then implement
> AD4691_MANUAL_CHANNEL macro which would miss the OVERSAMPLING
> infomask, and offload_manual_channels will be declared using it.
> More than this, that commit would also add other ad4691_manual_channels[]
> and ad4693_manual_channels[] arrays that would use that MACRO as well.
>
> Then, chip_info would have ad4691/93_channels assigned to it by default,
> and indio_dev->channels will later be assigned at probe, depending on the
> mode and offload.
>
> If different chip_info structs would be wanted still, then my best guess is
> to have different info structures (perhaps new types) in chip_info by default.
> Something like *sw_info and *offload_info.
Yes, this is how I would do it too.
> Each one would contain all the pre-defined channel arrays in them
> (channels and manual_channels) and so have ad4691_sw_info and ad4691_offload_info.
> After so, chip_info will also contain besides these 2 info structures, num_channels and max_rate.
> At probe indio_dev assignments will be made from the chip_info entirely.
>
> What's your guys take on this? I am keen to hearing your thoughts about this.
>
> Thanks,
> Radu
>
^ permalink raw reply
* Re: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: David Lechner @ 2026-04-06 13:53 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414CB6B07EA81FB5A42436AF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
On 4/6/26 5:39 AM, Sabau, Radu bogdan wrote:
>> -----Original Message-----
>> From: David Lechner <dlechner@baylibre.com>
>> Sent: Saturday, April 4, 2026 6:57 PM
>
> ...
>
>>> +
>>> #define AD4691_CHANNEL(ch)
>> \
>>> { \
>>> .type = IIO_VOLTAGE, \
>>> @@ -122,11 +155,9 @@ struct ad4691_chip_info {
>>> .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
>> \
>>> .channel = ch, \
>>> .scan_index = ch, \
>>> - .scan_type = { \
>>> - .sign = 'u', \
>>> - .realbits = 16, \
>>> - .storagebits = 16, \
>>> - }, \
>>> + .has_ext_scan_type = 1,
>> \
>>> + .ext_scan_type = ad4691_scan_types, \
>>> + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
>> \
>>
>> Usually, we just make two separte ad4691_chip_info structs for offload
>> vs. not offload.
>>
>> ext_scan_type is generally only used when the scan type can change
>> dynamically after probe.
>>
>
> So, just to be clear, you are saying I should have different chip_info structs
> and change the triggered-buffer for offload ones if offload is present?
> I am asking since offload has different scan types as well, and this would
> mean 3 different chip_info structs for each chip -> total of 12 chip_info structs,
> each with a different channel array, or perhaps there is a more compact way
> to have this implemented.
> I could make the channel arrays use the same macro and have the scan_type
> reversed to storage and shift done as parameters.
>
> Please let me know your thoughts on this.
If it gets too complex, we can dynamically create the chip info
struct during probe. But in general we prefer to statically define
them even if it gets a little verbose. Macros usually help here.
>>> }
>>>
>>> @@ -883,6 +1184,20 @@ static ssize_t sampling_frequency_store(struct
>> device *dev,
>>> if (iio_buffer_enabled(indio_dev))
>>> return -EBUSY;
>>>
>>> + if (st->manual_mode && st->offload) {
>>> + struct spi_offload_trigger_config config = {
>>> + .type = SPI_OFFLOAD_TRIGGER_PERIODIC,
>>> + .periodic = { .frequency_hz = freq },
>>> + };
>>
>> Same comment as other patches. This needs to account for oversampling
>> ratio.
>>
>
> I am thinking that since we would have different chip_info structs, manual
> mode channels could omit the oversampling attribute, since it is not supported
> by the chip on this mode.
Yes, this would be ideal.
>> SPI_OFFLOAD_TRIGGER_PERIODIC);
>>> + if (IS_ERR(offload->trigger))
>>> + return dev_err_probe(dev, PTR_ERR(offload->trigger),
>>> + "Failed to get periodic offload
>> trigger\n");
>>> +
>>> + offload->trigger_hz = st->info->max_rate;
>>
>> I think I mentioned this elsewhere, but can we really get max_rate in manual
>> mode
>> due to the extra SPI overhead? Probably safer to start with a lower rate.
>
> You are right a slower rate would be nicer, from my tests 311kHz worked perfect
> with a 10MHz SPI frequency, but perhaps these numbers are a bit "odd".
>
> How do you feel about 100kHz for a starting sample rate?
Sounds reasonable.
>> IIO_BUFFER_DIRECTION_IN);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + indio_dev->buffer->attrs = ad4691_buffer_attrs;
>>
>> Should including ad4691_buffer_attrs depend on st->manual_mode?
>>
>> I thought it was only used when PWM is connected to CNV.
>>
>
> For offload manual mode, I thought buffer sampling frequency should also be available,
> since the offload trigger's frequency is accessible.
Ah right. Not sure what I was thinking when I wrote that.
>
>>> +
>>> + return 0;
>>> +}
>>> +
>>> static int ad4691_probe(struct spi_device *spi)
>>> {
>>> struct device *dev = &spi->dev;
>>> + struct spi_offload *spi_offload;
>>> struct iio_dev *indio_dev;
>>> struct ad4691_state *st;
>>> int ret;
>>> @@ -1232,6 +1626,13 @@ static int ad4691_probe(struct spi_device *spi)
>>> if (ret)
>>> return ret;
>>>
>>> + spi_offload = devm_spi_offload_get(dev, spi,
>> &ad4691_offload_config);
>>> + ret = PTR_ERR_OR_ZERO(spi_offload);
>>> + if (ret == -ENODEV)
>>> + spi_offload = NULL;
>>> + else if (ret)
>>> + return dev_err_probe(dev, ret, "Failed to get SPI offload\n");
>>> +
>>> indio_dev->name = st->info->name;
>>> indio_dev->info = &ad4691_info;
>>> indio_dev->modes = INDIO_DIRECT_MODE;
>>> @@ -1239,7 +1640,10 @@ static int ad4691_probe(struct spi_device *spi)
>>> indio_dev->channels = st->info->channels;
>>> indio_dev->num_channels = st->info->num_channels;
>>
>> As mentioned earlier, we generally want separate channel structs
>> for SPI offload. These will also have different num_channels because
>> there is no timestamp channel in SPI offload.
>
> If different chip_info structs will be used, wouldn't they already have specific
> channels attached to them?
>
Yes.
^ permalink raw reply
* Re: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: David Lechner @ 2026-04-06 13:44 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB84145906CC191F6AB8D2D3DAF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
On 4/6/26 4:34 AM, Sabau, Radu bogdan wrote:
>> -----Original Message-----
>> From: David Lechner <dlechner@baylibre.com>
>> Sent: Saturday, April 4, 2026 6:34 PM
>
> ...
>
>>> +Selected when a ``pwms`` property is present in the device tree. The PWM
>> drives
>>> +the CNV pin independently of SPI at the configured conversion rate, and a
>> GP
>>> +pin (identified by ``interrupt-names``) asserts DATA_READY at end-of-burst
>> to
>>> +signal that the AVG_IN result registers are ready to be read.
>>> +
>>> +The IRQ handler stops the PWM, fires the IIO trigger, and the trigger
>> handler
>>
>> If we stop the PWM after an IRQ, then we don't get a consistent sample rate.
>> Ideally, we would leave the PWM running and just pick a rate slow enough
>> that
>> there is plenty of time to read the data. Otherwise, this mode doesn't seem
>> particularly useful.
>
> Should there also be a condition when setting the sampling frequency, that will
> protect from setting too fast sample rates?
I haven't figured out a good way to do this since the real max rate
depends on a lot of different things and when not using offloading,
the time it takes to do SPI xfers is non-deterministic.
>>> +IIO DMA buffer:
>>> +
>>> +* **CNV Burst offload**: the SPI engine reads AVG_IN registers with a 2-
>> byte
>>> + address phase followed by a 2-byte data phase; the 16-bit result lands in
>>> + the lower half of the 32-bit word (``shift=0``).
>>> +* **Manual offload**: each 32-bit SPI word carries the channel byte in the
>>> + first byte; the 16-bit result is returned in the upper half of the 32-bit
>>
>> I would expect the "first" byte to be in the "upper half" of the 32-bits as
>> well. This layout could be explained better.
>>
>> Also, since extra data has to be read in this mode, does this affect the max
>> conversion rate?
>
> This is bad documentation on my part. "channel byte" isn't used anymore,
> this is previous version behaviour. Right now, only 16-bits worth of actual
> channel data are used.
>
Then why do we need the shift if there is no other data? Can't we rework
the SPI message so that there is no shift?
^ permalink raw reply
* Re: [PATCH v6 3/4] iio: adc: ad4691: add triggered buffer support
From: David Lechner @ 2026-04-06 13:39 UTC (permalink / raw)
To: Sabau, Radu bogdan, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB84143905DD2E10BAC2151EEFF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
On 4/6/26 4:22 AM, Sabau, Radu bogdan wrote:
>> -----Original Message-----
>> From: David Lechner <dlechner@baylibre.com>
>> Sent: Saturday, April 4, 2026 6:12 PM
>
> ...
>
>>> +
>>> +/*
>>> + * Valid ACC_DEPTH values where the effective divisor equals the count.
>>> + * From Table 13: ACC_DEPTH = 2^N yields right-shift = N, divisor = 2^N.
>>> + */
>>> +static const int ad4691_oversampling_ratios[] = { 1, 2, 4, 8, 16, 32 };
>>
>> It would be nice to add oversampling in a separate commit as that is a
>> separate feature.
>
> Do you think this would be suitable after the offload commit?
>
Yes, I think that would be OK.
^ permalink raw reply
* [PATCH] arm64: dts: qcom: fix temp-alarm probe failure for PMH0104 on Glymur
From: Kamal Wadhwa @ 2026-04-06 13:35 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jishnu Prakash, Jyothi Kumar Seerapu, Maulik Shah,
Pankaj Patil, Raviteja Laggyshetty
Cc: Sibi Sankar, Dmitry Baryshkov, linux-arm-msm, devicetree,
linux-kernel, Manaf Meethalavalappu Pallikunhi, Kamal Wadhwa
The temp-alarm driver probe is failing for the pmh0104 PMICs on glymur.
[ 3.999713] spmi-temp-alarm c426000.spmi:pmic@8:temp-alarm@a00: error -ENODEV: failed to register sensor
[ 4.015066] spmi-temp-alarm c426000.spmi:pmic@9:temp-alarm@a00: error -ENODEV: failed to register sensor
[ 4.033908] spmi-temp-alarm c437000.spmi:pmic@b:temp-alarm@a00: error -ENODEV: failed to register sensor
This happens because thermal zone associated with the temp alarm was
defined under the thermal zones parent node which had a typo (used `_` in
place of `-`). Correct the typo to fix probe failure.
Fixes: 41b6e8db400c ("arm64: dts: qcom: Introduce Glymur base dtsi")
Signed-off-by: Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi b/arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi
index 7a1e5f355c175913a38d536a1ca13d870049b741..6b4747025b9f85d5fe58ee6ecfbe8d07b38d29fd 100644
--- a/arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/pmh0104-glymur.dtsi
@@ -7,7 +7,7 @@
#include <dt-bindings/spmi/spmi.h>
/{
- thermal_zones {
+ thermal-zones {
pmh0104_i0_thermal: pmh0104-i0-thermal {
polling-delay-passive = <100>;
thermal-sensors = <&pmh0104_i_e0_temp_alarm>;
---
base-commit: bd0f139e5fc11182777b81cefc3893ea508544ec
change-id: 20260401-glymur-pmh0104-temp-alarm-fix-72e6c1080d6e
Best regards,
--
Kamal Wadhwa <kamal.wadhwa@oss.qualcomm.com>
^ permalink raw reply related
* RE: [PATCH v6 4/4] iio: adc: ad4691: add SPI offload support
From: Sabau, Radu bogdan @ 2026-04-06 13:30 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Uwe Kleine-König,
Liam Girdwood, Mark Brown, Linus Walleij, Bartosz Golaszewski,
Philipp Zabel, Jonathan Corbet, Shuah Khan
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-pwm@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org
In-Reply-To: <LV9PR03MB8414C570998C4C1EE59ABFBBF75DA@LV9PR03MB8414.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Sabau, Radu bogdan
> Sent: Monday, April 6, 2026 2:08 PM
>
> ...
>
> > > > #define AD4691_CHANNEL(ch)
> > > \
> > > > { \
> > > > .type = IIO_VOLTAGE, \
> > > > @@ -122,11 +155,9 @@ struct ad4691_chip_info {
> > > > .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_SCALE),
> > > \
> > > > .channel = ch, \
> > > > .scan_index = ch, \
> > > > - .scan_type = { \
> > > > - .sign = 'u', \
> > > > - .realbits = 16, \
> > > > - .storagebits = 16, \
> > > > - }, \
> > > > + .has_ext_scan_type = 1,
> > > \
> > > > + .ext_scan_type = ad4691_scan_types, \
> > > > + .num_ext_scan_type = ARRAY_SIZE(ad4691_scan_types),
> > > \
> > >
> > > Usually, we just make two separte ad4691_chip_info structs for offload
> > > vs. not offload.
> > >
> > > ext_scan_type is generally only used when the scan type can change
> > > dynamically after probe.
> > >
> >
> > So, just to be clear, you are saying I should have different chip_info structs
> > and change the triggered-buffer for offload ones if offload is present?
> > I am asking since offload has different scan types as well, and this would
> > mean 3 different chip_info structs for each chip -> total of 12 chip_info
> structs,
> > each with a different channel array, or perhaps there is a more compact way
> > to have this implemented.
> > I could make the channel arrays use the same macro and have the scan_type
> > reversed to storage and shift done as parameters.
> >
>
> I have given this a thought and I think this could be done in a more compact
> way:
>
> 1. Parametrize AD4691_CHANNEL to accept storagebits and shift, then define
> 4 channel
> arrays:
>
> - ad4691_channels[] - 16ch + timestamp (triggered-buffer path)
> - ad4693_channels[] - 8ch + timestamp (triggered-buffer path)
> - ad4691_offload_cnv_channels[] - 16 entries, storagebits=32, shift =
> 0
> - ad4691_offload_manual_channels[] - 16 entries, storagebits=32,
> shift=16
>
> The two offload arrays are shared across both chip families. Since
> num_channels
> bound the interation in the IIO core, the 8ch chips simply use the first 8
> entries of
> the 16-entry offload arrays. Triggered-buffer path would need different
> channel
> arrays since the timestamp index would be different, and offload doesn't use
> timestamp.
>
> 2. chip_info could then stay at 2 structs, and have channels selected at probe
> for the
> indio_dev, or have 4 chip info structs each having its own channels assigned,
> and only
> num_channels could be changed at probe.
>
I also have to mention that the oversampling commit would then implement
AD4691_MANUAL_CHANNEL macro which would miss the OVERSAMPLING
infomask, and offload_manual_channels will be declared using it.
More than this, that commit would also add other ad4691_manual_channels[]
and ad4693_manual_channels[] arrays that would use that MACRO as well.
Then, chip_info would have ad4691/93_channels assigned to it by default,
and indio_dev->channels will later be assigned at probe, depending on the
mode and offload.
If different chip_info structs would be wanted still, then my best guess is
to have different info structures (perhaps new types) in chip_info by default.
Something like *sw_info and *offload_info.
Each one would contain all the pre-defined channel arrays in them
(channels and manual_channels) and so have ad4691_sw_info and ad4691_offload_info.
After so, chip_info will also contain besides these 2 info structures, num_channels and max_rate.
At probe indio_dev assignments will be made from the chip_info entirely.
What's your guys take on this? I am keen to hearing your thoughts about this.
Thanks,
Radu
^ permalink raw reply
* Re: [RFC PATCH 0/3] media: qcom: camss: CAMSS Offline Processing Engine support
From: Loic Poulain @ 2026-04-06 13:22 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Bryan O'Donoghue, vladimir.zapolskiy, kieran.bingham, robh,
krzk+dt, andersson, konradybcio, linux-media, linux-arm-msm,
devicetree, linux-kernel, johannes.goede, mchehab
In-Reply-To: <20260405194851.GA3972481@killaraus.ideasonboard.com>
Hi Laurent,
On Sun, Apr 5, 2026 at 9:48 PM Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>
> On Tue, Mar 24, 2026 at 05:16:21PM +0100, Loic Poulain wrote:
> > On Tue, Mar 24, 2026 at 1:54 PM Bryan O'Donoghue wrote:
> > > On 23/03/2026 12:58, Loic Poulain wrote:
> > > > This first version is intentionally minimalistic. It provides a working
> > > > configuration using a fixed set of static processing parameters, mainly
> > > > to achieve correct and good-quality debayering.
> > >
> > > You need the other 50% of the kernel side - the generation of bayer
> > > statistics in the IFE, as well as generation of parameters to feed back
> > > into the OPE - which requires a user-space implementation too, so a lot
> > > of work there too.
> > >
> > > I'd also say when we have an ICP we should be using it via the HFI
> > > protocol, thus burying all of the IPE/OPE BPS and CDM complexity in the
> > > firmware.
> > >
> > > Understood Agatti has no ICP so you're limited to direct OPE/IFE
> > > register access here. For HFI capable platforms - the majority - HFI is
> > > the way to go.
> >
> > Fully agree, this is exactly the point where we should sync and work
> > together on a proper solution.
>
> I don't necessarily agree with that. There are pros and cons for using
> HFI on platforms that have an ICP. If correctly written, a firmware can
> improve the throughput in multi-camera use cases by reprogramming the
> time-multiplexed OPE faster. On the other hand, in use cases that don't
> require pushing the platform to its limits, dealing with a closed-source
> firmware often causes lots of issues.
Yes, we need to further explore the ICP (MCU-based offload) solution
before drawing any conclusions, especially to assess how complex it is
to leverage or bypass. That said, the current platform (Agatti/OPE)
does not support it anyway.
> We should aim at supporting both direct ISP access and HFI with the same
> userspace API, even on a single platform. Which option to start with is
> an open question that we should discuss.
>
> > As a follow‑up to this RFC, I already have several ongoing pieces that
> > aim to generalize the CAMSS ISP support, and I’d very much like to
> > discuss them with you:
> >
> > - camss-isp-m2m: Generic M2M scheduling framework handling job dispatch
> > based on buffer readiness and enabled endpoints (frame input, output,
> > statistics, parameters).
>
> This should be generic, not limited to camss. v4l2-isp is a good
> candidate.
>
> > - camss-isp-pipeline: Helper layer to construct complex media/ISP graphs
> > from a structural description (endpoints, links, etc.).
>
> That also doesn't seem specific to camss.
Yes, architecturally this is not CAMSS‑specific. However, the current
implementation may rely on certain assumptions or shortcuts that do
not hold across all general offline ISP use cases. With some effort,
it should be possible to generalize them [1] [2] .
[1] https://github.com/loicpoulain/linux/blob/camss-isp-dev/drivers/media/platform/qcom/camss/camss-isp-pipeline.c
[2] https://github.com/loicpoulain/linux/blob/camss-isp-dev/drivers/media/platform/qcom/camss/camss-isp-m2m.c
>
> > - camss-isp-params: Generic helper for handling ISP parameter buffers
> > (using v4l2-isp-params).
>
> I'm curious to know what camss-specific helpers you envision there.
Nothing too complex initially, just a parser built on the v4l2‑isp
helpers, along with a few handler callbacks [3]. This is something
I’ll discuss with Bryan, as we definitely want to reuse the same
format and parser for both inline and offline ISPs (as well as for
stats).
[3] https://github.com/loicpoulain/linux/blob/camss-isp-dev/drivers/media/platform/qcom/camss/camss-isp-params.c
>
> > - camss-isp-stats: Generic helper framework for CAMSS statistics devices.
>
> Same.
>
> > - camss-(isp-)ope: OPE‑specific logic only (register configuration, IRQ
> > handling, parameter‑to‑register translation).
> >
> > This approach should significantly reduce the amount of
> > platform‑specific code required for future ISP blocks. It should also
> > allow you to integrate a camss-isp-hamoa (or similar) backend, or even
> > a camss-isp-hfi implementation for the M2M functions, without
> > duplicating the infrastructure.
> >
> > So yes, let’s sync and agree on a shared/open development model and an
> > overall direction, possibly even a common tree, to ensure we stay
> > aligned and can collaborate effectively.
>
> Let's schedule a call to kickstart those discussions. Many people are on
> Easter vacation this week, next week could be a good candidate.
>
> > > I'll publish an RFC for Hamoa for that soonish so we can make sure both
> > > coexist.
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: sound: renesas,fsi: Add support for multiple clocks
From: Bui Duc Phuc @ 2026-04-06 12:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: kuninori.morimoto.gx, broonie, lgirdwood, robh, krzk+dt, conor+dt,
geert+renesas, magnus.damm, perex, tiwai, linux-sound,
linux-renesas-soc, devicetree, linux-kernel
In-Reply-To: <20260405-ultramarine-orangutan-of-wholeness-bbcc6b@quoll>
Hi Mark, Krzysztof,
Thank you for your reviews. I will fix these in v2:
- Subject Line: Change to ASoC: dt-bindings: renesas,fsi: add support
for multiple clocks to match subsystem style.
- Commit Message: Reformat to 72-75 characters per line and remove
manual line breaks after every sentence.
- YAML Bindings: Properly constrain clocks and clock-names by
following the writing-schema and existing
Renesas sound examples.
I will submit the v2 series shortly.
Best regards,
Phuc
On Sun, Apr 5, 2026 at 2:32 PM Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On Fri, Apr 03, 2026 at 06:26:53PM +0700, phucduc.bui@gmail.com wrote:
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > The FSI on r8a7740 requires the SPU clock to be enabled
> > before accessing its registers.
> > Without this clock, register access may lead to a system
> > hang.
> > Add support for the "spu" clock so it can be managed by
> > the driver.
> > The binding is also extended to allow additional clocks,
> > as FSIB may require more clock inputs, while FSIA
> > typically uses fewer.
>
> Please wrap commit message according to Linux coding style / submission
> process (neither too early nor over the limit):
> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>
> And not after every sentece, BTW.
>
> > Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> > ---
> > .../devicetree/bindings/sound/renesas,fsi.yaml | 12 ++++++++++--
> > 1 file changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> > index df91991699a7..225cd8d369bb 100644
> > --- a/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> > +++ b/Documentation/devicetree/bindings/sound/renesas,fsi.yaml
> > @@ -38,7 +38,11 @@ properties:
> > maxItems: 1
> >
> > clocks:
> > - maxItems: 1
> > + minItems: 1
> > + maxItems: 8
>
> Needs valid descriptions.
>
> > +
> > + clock-names:
> > + description: List of necessary clock names.
>
> Instead constrain it. See also writing-bindings, writing-schema or
> example-schema documents.
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: Devicetree spec: Specifying /cpus/cpu@* unit address format?
From: Rob Herring @ 2026-04-06 12:48 UTC (permalink / raw)
To: David Gibson, Vivian Wang
Cc: devicetree-spec, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Alexandre Ghiti, Chen Wang, Inochi Amaoto,
devicetree, linux-riscv, sophgo
In-Reply-To: <adHofcKAr7C5YCSA@zatzit>
On Sat, Apr 4, 2026 at 11:43 PM David Gibson
<david@gibson.dropbear.id.au> wrote:
>
> On Fri, Apr 03, 2026 at 06:06:17PM +0800, Vivian Wang wrote:
> > (Also posted at: https://github.com/devicetree-org/devicetree-specification/issues/86 )
> >
> > Hi all,
> >
> > Presently, there seems to be some confusion in the community about the
> > format of unit addresses for "/cpus/cpu@*" nodes for a CPU with ID > 9, e.g.
> >
> > cpu@??? {
> > reg = <10>;
> > /* reg = <0xa>; */ /* This should be equivalent */
> > }
> >
> >
> > Should this be a decimal "cpu@10", or hexadecimal "cpu@a"? I can't find
> > any explicit specification.
>
> It should be hex. That's a general convention for unit addresses.
> Before flattened trees, OF essentially never used decimal
> representations of things.
The only decimal usage in FDT were mistakes.
Rather than worrying about what the spec says, please worry about what
the tools check. Unfortunately, this is still only checked for
specific bus types and the default is not checked.
Rob
^ permalink raw reply
* Re: [PATCH v2 8/8] mips: dts: Add PCIe to EcoNet EN751221
From: Thomas Bogendoerfer @ 2026-04-06 12:37 UTC (permalink / raw)
To: Caleb James DeLisle
Cc: linux-mips, naseefkm, mturquette, sboyd, robh, krzk+dt, conor+dt,
ryder.lee, jianjun.wang, lpieralisi, kwilczynski, mani, bhelgaas,
vkoul, neil.armstrong, p.zabel, matthias.bgg,
angelogioacchino.delregno, nbd, ansuelsmth, linux-clk, devicetree,
linux-kernel, linux-pci, linux-mediatek, linux-phy,
linux-arm-kernel
In-Reply-To: <20260309131818.74467-9-cjd@cjdns.fr>
On Mon, Mar 09, 2026 at 01:18:18PM +0000, Caleb James DeLisle wrote:
> Add PCIe based on EN7528 PCIe driver, also add two MT76 wifi devices
> to SmartFiber XP8421-B.
>
> Signed-off-by: Caleb James DeLisle <cjd@cjdns.fr>
> ---
> arch/mips/boot/dts/econet/en751221.dtsi | 114 ++++++++++++++++++
> .../econet/en751221_smartfiber_xp8421-b.dts | 21 ++++
> arch/mips/econet/Kconfig | 2 +
> 3 files changed, 137 insertions(+)
>
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH v2] MIPS: dts: loongson64g-package: Switch to Loongson UART driver
From: Thomas Bogendoerfer @ 2026-04-06 12:32 UTC (permalink / raw)
To: Rong Zhang
Cc: Greg Kroah-Hartman, Jiri Slaby, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Huacai Chen, Jiaxun Yang, linux-kernel,
linux-serial, linux-mips, devicetree, Yao Zi, Icenowy Zheng,
Rong Zhang
In-Reply-To: <20260315184401.413975-1-rongrong@oss.cipunited.com>
On Mon, Mar 16, 2026 at 02:44:00AM +0800, Rong Zhang wrote:
> Loongson64g is Loongson 3A4000, whose UART controller is compatible with
> Loongson 2K1500, which is NS16550A-compatible with an additional
> fractional frequency divisor register.
>
> Update the compatible strings to reflect this, so that 3A4000 can
> benefit from the fractional frequency divisor provided by loongson-uart.
> This is required on some devices, otherwise their UART can't work at
> some high baud rates, e.g., 115200.
>
> Tested on Loongson-LS3A4000-7A1000-NUC-SE with a 25MHz UART clock.
> Without fractional frequency divisor, the actual baud rate was 111607
> (25MHz / 16 / 14, measured value: 111545) and some USB-to-UART
> converters couldn't work with it at all. With fractional frequency
> divisor, the measured baud rate becomes 115207, which is quite accurate.
>
> Signed-off-by: Rong Zhang <rongrong@oss.cipunited.com>
> ---
> This patch targets the MIPS tree.
>
> The series for the serial tree to update dt-bindings and enable building
> 8250_loongson (loongson-uart) on MIPS Loongson64 is sent separately, as
> it's independant of this patch and can be applied in any order (the
> compatible strings here still contain "ns16550a", so no regression will
> be introduced).
>
> Changes in v2:
> - Separated from v1 (patch 3): https://lore.kernel.org/r/20260314234143.651298-1-rongrong@oss.cipunited.com/
> (thanks Krzysztof Kozlowski)
> ---
> arch/mips/boot/dts/loongson/loongson64g-package.dtsi | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH v7 0/3] Add MACB/GEM instances on EyeQ5, and their PHYs
From: Thomas Bogendoerfer @ 2026-04-06 12:31 UTC (permalink / raw)
To: Théo Lebrun
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-mips,
devicetree, linux-kernel, Vladimir Kondratiev, Gregory CLEMENT,
Benoît Monin, Tawfik Bayouk, Thomas Petazzoni, Luca Ceresoli,
Conor Dooley, Andrew Lunn
In-Reply-To: <20260225-macb-phy-v7-0-d3c9842ec931@bootlin.com>
On Wed, Feb 25, 2026 at 05:55:21PM +0100, Théo Lebrun wrote:
> EyeQ5 SoCs integrate two GEM instances. A system-controller register
> region named "OLB" has some control over the Ethernet PHY integration.
>
> Extend the current OLB ecosystem with a new generic PHY driver.
> - OLB is carried by one main platform driver: clk-eyeq.
> - It instantiates auxiliary devices: reset-eyeq & pinctrl-eyeq5.
> - We add a new one: phy-eyeq5-eth.
>
> Here we update dt-bindings to indicate OLB is a PHY provider. Then we
> add MACB/GEM instances in the devicetree, and the PHYs on the eval
> board.
>
> About related patches:
>
> - PHY patches are incoming to add the driver. Patches used to be [2] in
> the same series.
>
> - clk patches are incoming to make clk-eyeq instantiate this new
> auxiliary device. They also ensure we get a dev->of_node assigned.
> Patches used to be [2] in the same series.
>
> Have a nice day,
> Thanks!
> Théo
>
> [0]: https://lore.kernel.org/lkml/20250627-macb-v2-15-ff8207d0bb77@bootlin.com/
> [1]: https://lore.kernel.org/lkml/20251022-macb-eyeq5-v2-0-7c140abb0581@bootlin.com/
>
> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
> ---
> Changes in v7:
> - Separate PHY / clk / MIPS patches into three series.
> - Rebase onto v7.0-rc1 and test on EyeQ5. Nothing to report.
> - Link to v6: https://lore.kernel.org/r/20260127-macb-phy-v6-0-cdd840588188@bootlin.com
>
> Changes in v6:
> - Rebase upon v6.19-rc7; nothing to report.
> - Add new patch "phy: sort Kconfig and Makefile".
> - phy-eyeq5-eth: drop useless explicit __iomem cast to
> dev_get_platdata() return value.
> - I did *not* drop the Kconfig `default MACH_EYEQ5` nor driver
> `dev_dbg()`. I think both are useful and should be kept. See
> last revision discussion here:
> https://lore.kernel.org/lkml/DFGSMN8268O0.33TYCQDBVHUHZ@bootlin.com/
> - Link to v5: https://lore.kernel.org/r/20251215-macb-phy-v5-0-a9dfea39da34@bootlin.com
>
> Changes in v5:
> - phy-eyeq5-eth:
> - fix #includes: add delay, gfp_types, module and drop array_size,
> bug, cleanup, container_of, lockdep, mutex.
> - eq5_phy_xlate(): avoid magic value, use EQ5_PHY_COUNT.
> - use dev_err_probe() in error cases of devm_phy_create() and
> devm_of_phy_provider_register().
> - 3x Reviewed-by: Luca Ceresoli.
> - Add Neil Armstrong to Cc as new PHY subsystem reviewer.
> - Rebase on v6.19-rc1, tested on hardware, no changes.
> - Link to v4: https://lore.kernel.org/r/20251124-macb-phy-v4-0-955c625a81a7@bootlin.com
>
> Changes in v4:
> - Append my SoB to Jerome's patch:
> [PATCH v4 3/7] clk: eyeq: use the auxiliary device creation helper
> - Rebase on net-next & linux-{clk,mips,phy}. Nothing to report.
> - Link to v3: https://lore.kernel.org/r/20251119-macb-phy-v3-0-e9a7be186a33@bootlin.com
>
> Changes in v3:
> - Take Philipp Zabel's Reviewed-by & Acked-by trailers on reset patch.
> - Take Thomas Bogendoerfer's two Acked-by trailers on DT patches.
> - Rebase on net-next & test on target. Nothing to report.
> - Link to v2: https://lore.kernel.org/r/20251101-macb-phy-v2-0-c1519eef16d3@bootlin.com
>
> Changes in v2:
> - Take Acked-by: Conor Dooley on dt-bindings-patch.
> - s/%ld/%tu/ for printing ptrdiff_t; warnings on 32-bit archs.
> Reported by NIPA's netdev/build_32bit test.
> https://patchwork.kernel.org/project/netdevbpf/patch/20251021-macb-eyeq5-v1-7-3b0b5a9d2f85@bootlin.com/
> https://netdev.bots.linux.dev/static/nipa/1014126/14277857/build_32bit/stderr
> - Link to v1: https://lore.kernel.org/r/20251022-macb-phy-v1-0-f29f28fae721@bootlin.com
>
> Changes since MACB V1:
> - Drop the old "mobileye,olb" properties from DT patches; found while
> running dtbs_check and dt_binding_check.
> - Drop all patches targeting net-next. That is MACB dt-bindings patch
> and MACB driver code. See there here [1].
> - Link to v1: https://lore.kernel.org/lkml/20251021-macb-eyeq5-v1-0-3b0b5a9d2f85@bootlin.com/
>
> Past versions of MACB patches:
> - March 2025: [PATCH net-next 00/13] Support the Cadence MACB/GEM
> instances on Mobileye EyeQ5 SoCs
> https://lore.kernel.org/lkml/20250321-macb-v1-0-537b7e37971d@bootlin.com/
> - June 2025: [PATCH net-next v2 00/18] Support the Cadence MACB/GEM
> instances on Mobileye EyeQ5 SoCs
> https://lore.kernel.org/lkml/20250627-macb-v2-0-ff8207d0bb77@bootlin.com/
> - August 2025: [PATCH net v3 00/16] net: macb: various fixes & cleanup
> https://lore.kernel.org/lkml/20250808-macb-fixes-v3-0-08f1fcb5179f@bootlin.com/
>
> ---
> Théo Lebrun (3):
> dt-bindings: soc: mobileye: OLB is an Ethernet PHY provider on EyeQ5
> MIPS: mobileye: eyeq5: add two Cadence GEM Ethernet controllers
> MIPS: mobileye: eyeq5-epm: add two Cadence GEM Ethernet PHYs
>
> .../bindings/soc/mobileye/mobileye,eyeq5-olb.yaml | 7 +++-
> arch/mips/boot/dts/mobileye/eyeq5-epm5.dts | 26 +++++++++++++
> arch/mips/boot/dts/mobileye/eyeq5.dtsi | 45 ++++++++++++++++++++++
> 3 files changed, 77 insertions(+), 1 deletion(-)
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20251022-macb-phy-21bc4e1dfbb7
seried applied to mips-next
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Bui Duc Phuc @ 2026-04-06 12:32 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <87v7e5t16l.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san, Mark,
Thank you for your review.
> If it is needed for register access,
Yes, enabling this clock is essential as it functions as a bus bridge clock.
Currently, the SPU clock is still enabled by the bootloader. In legacy
kernels (v4.2 and earlier) using the Armadillo board-file/defconfig, this
clock remained active after boot, allowing the FSI to function correctly.
However, after migrating to a full Device Tree (DTS) implementation,
the kernel's unused clock cleanup mechanism disables the SPU clock
because it isn't explicitly claimed. This leads to a system hang every
time aplay is executed, as the FSI registers become inaccessible
without this clock.
> you need to call it on
> fsi_hw_startup/shutdown() which cares suspend/resume too.
I previously attempted to manage the clock within fsi_hw_startup/
shutdown, but the system would hang when stopping aplay
(e.g., via Ctrl+C). This happens because certain cleanup operations,
such as fsi_irq_disable(), are performed after fsi_hw_shutdown()
finishes. These operations require register access, which triggers a
system hang if the SPU clock has already been disabled. Therefore,
I moved the clock management to fsi_dai_startup/shutdown to ensure
the clock remains active throughout the entire lifecycle of the stream.
Furthermore, my testing shows that using dai_startup/shutdown
eliminates the need for explicit Suspend/Resume handling for this clock.
Since the ALSA framework typically invokes the hw_ callbacks during
power management transitions rather than the dai_ ones, the SPU clock
state remains stable, preventing any illegal register access during
these transitions.
> As Mark mentioned, it should be optional.
> Otherwise it breaks compatibility.
You are right. I will implement it this way in v2.
> And we already have fsi_clk_init() for clock initialize.
> spu should be handled in it.
> Now, it is called if clock master (A.
> (A) if (fsi_is_clk_master(fsi)) {
> if (fsi->clk_cpg)
> fsi_clk_init(dev, fsi, 0, 1, 1,
> fsi_clk_set_rate_cpg);
> else
> fsi_clk_init(dev, fsi, 1, 1, 0,
> fsi_clk_set_rate_external);
> }
You are right. Currently, our FSIA is configured as a slave,
so it never executes the clk_init() function.
> I think it (A) can be checked inside fsi_clk_init().
> fsi_clk_init() is now called when .set_fmt, but it can be called
> at _probe() timing ?
Yes. I can handle the implementation/coding side of this.
> Should we also be managing the clock during system suspend, or if the
> power consumption doesn't really matter should we just keep it enabled
> all the time and not worry about starting and stopping it?
Regarding the SPU clock management, I haven't measured the exact
power consumption of this block yet. However, to keep the code simple
and ensure maximum stability for register access (avoiding system
hangs during cleanup), I am open to enabling it once in fsi_probe()
if you find the dynamic management in dai_startup/shutdown
unnecessary.
> This is going to unconditionally require a clock called "spu" on all
> devices using this driver, not just the one SoC you mentioned as
> requiring it. Presumably this worked at least somewhere (possibly the
> clock is always on, or they're just lucky that something else enables
> it) and this will cause regressions for those platforms?
> This should either (ideally) be conditional, or use _optional.
Thank you for your suggestion. I will switch to using
devm_clk_get_optional() in the v2
Best regards,
Phuc
On Mon, Apr 6, 2026 at 6:52 AM Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
>
> Hi
>
> Thank you for the patch
>
> > From: bui duc phuc <phucduc.bui@gmail.com>
> >
> > The FSI on r8a7740 requires the SPU clock to be enabled
> > before accessing its registers.
> > Without this clock, register access may lead to a system
> > hang.
> > Retrieve the "spu" clock in probe and enable it during
> > DAI startup. Disable the clock on shutdown to match the
> > audio stream lifecycle.
> > This ensures safe register access and prevents system
> > hangs during audio playback.
> > This is required even if the FSI functional clock is
> > enabled, as internal units depend on the SPU clock.
> >
> > Signed-off-by: bui duc phuc <phucduc.bui@gmail.com>
> > ---
> (snip)
> > @@ -1554,6 +1555,11 @@ static int fsi_dai_startup(struct snd_pcm_substream *substream,
> > struct snd_soc_dai *dai)
> > {
> > struct fsi_priv *fsi = fsi_get_priv(substream);
> > + int ret;
> > +
> > + ret = clk_prepare_enable(fsi->master->clk_spu);
> > + if (ret)
> > + return ret;
> >
> > fsi_clk_invalid(fsi);
>
> If it is needed for register access, you need to call it on
> fsi_hw_startup/shutdown() which cares suspend/resume too.
>
> And I guess it need to count user, because we have FSI-A / FSI-B ?
>
> > @@ -1963,6 +1970,13 @@ static int fsi_probe(struct platform_device *pdev)
> > master->core = core;
> > spin_lock_init(&master->lock);
> >
> > + /* SPU clock is required for FSI register access */
> > + master->clk_spu = devm_clk_get(&pdev->dev, "spu");
> > + if (IS_ERR(master->clk_spu)) {
> > + dev_err(&pdev->dev, "Failed to get spu clock\n");
> > + return PTR_ERR(master->clk_spu);
> > + }
>
> As Mark mentioned, it should be optional. Otherwise it breaks compatibility.
> And we already have fsi_clk_init() for clock initialize.
> spu should be handled in it.
>
> Now, it is called if clock master (A.
>
> (A) if (fsi_is_clk_master(fsi)) {
> if (fsi->clk_cpg)
> fsi_clk_init(dev, fsi, 0, 1, 1,
> fsi_clk_set_rate_cpg);
> else
> fsi_clk_init(dev, fsi, 1, 1, 0,
> fsi_clk_set_rate_external);
> }
>
> I think it (A) can be checked inside fsi_clk_init().
> fsi_clk_init() is now called when .set_fmt, but it can be called
> at _probe() timing ?
>
> Thank you for your help !!
>
> Best regards
> ---
> Kuninori Morimoto
^ permalink raw reply
* Re: [PATCH v2 2/4] platform: arm64: dell-xps-ec: new driver
From: Bjorn Andersson @ 2026-04-06 12:32 UTC (permalink / raw)
To: Aleksandrs Vinarskis
Cc: Bryan O'Donoghue, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Hans de Goede,
Ilpo Järvinen, linux-arm-msm, devicetree, linux-kernel,
platform-driver-x86, laurentiu.tudor1, Abel Vesa, Tobias Heider,
Val Packett
In-Reply-To: <P9IQ5Penud7CH3Yfn0bw0RXJfIhFhFGksRjP-aZwLoAxmajMfeOtLEItrcWOXwVjHE_zObIA8SYjcPVR9dkAk9KgDYLun0DJJ6dBIU-IRDI=@vinarskis.com>
On Sun, Apr 05, 2026 at 08:48:25PM +0000, Aleksandrs Vinarskis wrote:
> On Sunday, April 5th, 2026 at 02:29, Bryan O'Donoghue <bryan.odonoghue@linaro.org> wrote:
>
> > On 04/04/2026 13:55, Aleksandrs Vinarskis wrote:
> > > Introduce EC driver for Dell XPS 13 9345 (codename 'tributo') which may
> > > partially of fully compatible with Snapdragon-based Dell Latitude,
> > > Inspiron ('thena'). Primary function of this driver is unblock EC's
> > > thermal management, specifically to provide it with necessary
> > > information to control device fans, peripherals power.
> > >
> > > The driver was developed primarily by analyzing ACPI DSDT's _DSM and
> > > i2c dumps of communication between SoC and EC. Changes to Windows
> > > driver's behavior include increasing temperature feed loop from ~50ms
> > > to 100ms here.
> > >
> > > While Xps's EC is rather complex and controls practically all device
> > > peripherals including touch row's brightness and special keys such as
> > > mic mute, these do not go over this particular i2c interface.
> > >
> > > Not yet implemented features:
> > > - On lid-close IRQ event is registered. Windows performs what to
> > > appears to be thermistor constants readout, though its not obvious
> > > what it used for.
> > > - According to ACPI's _DSM there is a method to readout fans' RPM.
> > > - Initial thermistor constants were sniffed from Windows, these can be
> > > likely fine tuned for better cooling performance.
> > > - There is additional temperature reading that Windows sents to EC but
> > > more rare than others, likely SoC T_j / TZ98 or TZ4. This is the only
> > > thermal zone who's reading can exceed 115C without triggering thermal
> > > shutdown.
> > > - Given similarities between 'tributo' and 'thena' platforms, including
> > > EC i2c address, driver can be potentially extended to support both.
> > >
> > > Signed-off-by: Aleksandrs Vinarskis <alex@vinarskis.com>
> > > ---
> > > MAINTAINERS | 1 +
> > > drivers/platform/arm64/Kconfig | 12 ++
> > > drivers/platform/arm64/Makefile | 1 +
> > > drivers/platform/arm64/dell-xps-ec.c | 267 +++++++++++++++++++++++++++++++++++
> > > 4 files changed, 281 insertions(+)
> > >
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index a5d175559f4468dfe363b319a1b08d3425f4d712..c150f57b60706224e5b24b0dfb3d8a9b81f36398 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -7240,6 +7240,7 @@ DELL XPS EMBEDDED CONTROLLER DRIVER
> > > M: Aleksandrs Vinarskis <alex@vinarskis.com>
> > > S: Maintained
> > > F: Documentation/devicetree/bindings/embedded-controller/dell,xps13-9345-ec.yaml
> > > +F: drivers/platform/arm64/dell-xps-ec.c
> > >
> > > DELTA AHE-50DC FAN CONTROL MODULE DRIVER
> > > M: Zev Weiss <zev@bewilderbeest.net>
> > > diff --git a/drivers/platform/arm64/Kconfig b/drivers/platform/arm64/Kconfig
> > > index 10f905d7d6bfa5fad30a0689d3a20481268c781e..0bc8f016032bb05cb3a7cc50bdf1092da04153bc 100644
> > > --- a/drivers/platform/arm64/Kconfig
> > > +++ b/drivers/platform/arm64/Kconfig
> > > @@ -33,6 +33,18 @@ config EC_ACER_ASPIRE1
> > > laptop where this information is not properly exposed via the
> > > standard ACPI devices.
> > >
> > > +config EC_DELL_XPS
> > > + tristate "Dell XPS 9345 Embedded Controller driver"
> > > + depends on ARCH_QCOM || COMPILE_TEST
> > > + depends on I2C
> > > + depends on IIO
> > > + help
> > > + Driver for the Embedded Controller in the Qualcomm Snapdragon-based
> > > + Dell XPS 13 9345, which handles thermal management and fan speed
> > > + control.
> > > +
> > > + Say M or Y here to include this support.
> > > +
> > > config EC_HUAWEI_GAOKUN
> > > tristate "Huawei Matebook E Go Embedded Controller driver"
> > > depends on ARCH_QCOM || COMPILE_TEST
> > > diff --git a/drivers/platform/arm64/Makefile b/drivers/platform/arm64/Makefile
> > > index 60c131cff6a15bb51a49c9edab95badf513ee0f6..6768dc6c2310837374e67381cfc729bed1fdaaef 100644
> > > --- a/drivers/platform/arm64/Makefile
> > > +++ b/drivers/platform/arm64/Makefile
> > > @@ -6,6 +6,7 @@
> > > #
> > >
> > > obj-$(CONFIG_EC_ACER_ASPIRE1) += acer-aspire1-ec.o
> > > +obj-$(CONFIG_EC_DELL_XPS) += dell-xps-ec.o
> > > obj-$(CONFIG_EC_HUAWEI_GAOKUN) += huawei-gaokun-ec.o
> > > obj-$(CONFIG_EC_LENOVO_YOGA_C630) += lenovo-yoga-c630.o
> > > obj-$(CONFIG_EC_LENOVO_THINKPAD_T14S) += lenovo-thinkpad-t14s.o
> > > diff --git a/drivers/platform/arm64/dell-xps-ec.c b/drivers/platform/arm64/dell-xps-ec.c
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..bf1495fbe473ccdb82b95a66b56e8525f782cc8e
> > > --- /dev/null
> > > +++ b/drivers/platform/arm64/dell-xps-ec.c
> > > @@ -0,0 +1,267 @@
> > > +// SPDX-License-Identifier: GPL-2.0-only
> > > +/*
> > > + * Copyright (c) 2026, Aleksandrs Vinarskis <alex@vinarskis.com>
> > > + */
> > > +
> > > +#include <linux/array_size.h>
> > > +#include <linux/dev_printk.h>
> > > +#include <linux/device.h>
> > > +#include <linux/devm-helpers.h>
> > > +#include <linux/err.h>
> > > +#include <linux/i2c.h>
> > > +#include <linux/iio/consumer.h>
> > > +#include <linux/interrupt.h>
> > > +#include <linux/jiffies.h>
> > > +#include <linux/module.h>
> > > +#include <linux/pm.h>
> > > +#include <linux/unaligned.h>
> > > +#include <linux/workqueue.h>
> > > +
> > > +#define DELL_XPS_EC_SUSPEND_CMD 0xb9
> > > +#define DELL_XPS_EC_SUSPEND_MSG_LEN 64
> > > +
> > > +#define DELL_XPS_EC_TEMP_CMD0 0xfb
> > > +#define DELL_XPS_EC_TEMP_CMD1 0x20
> > > +#define DELL_XPS_EC_TEMP_CMD3 0x02
> > > +#define DELL_XPS_EC_TEMP_MSG_LEN 6
> > > +#define DELL_XPS_EC_TEMP_POLL_JIFFIES msecs_to_jiffies(100)
> > > +
> > > +/*
> > > + * Format:
> > > + * - header/unknown (2 bytes)
> > > + * - per-thermistor entries (3 bytes): thermistor_id, param1, param2
> > > + */
> > > +static const u8 dell_xps_ec_thermistor_profile[] = {
> > > + 0xff, 0x54,
> > > + 0x01, 0x00, 0x2b, /* sys_therm0 */
> > > + 0x02, 0x44, 0x2a, /* sys_therm1 */
> > > + 0x03, 0x44, 0x2b, /* sys_therm2 */
> > > + 0x04, 0x44, 0x28, /* sys_therm3 */
> > > + 0x05, 0x55, 0x2a, /* sys_therm4 */
> > > + 0x06, 0x44, 0x26, /* sys_therm5 */
> > > + 0x07, 0x44, 0x2b, /* sys_therm6 */
> > > +};
> > > +
> > > +/*
> > > + * Mapping from IIO channel name to EC command byte
> > > + */
> > > +static const struct {
> > > + const char *name;
> > > + u8 cmd;
> > > +} dell_xps_ec_therms[] = {
> > > + /* TODO: 0x01 is sent only occasionally, likely TZ98 or TZ4 */
> > > + { "sys_therm0", 0x02 },
> > > + { "sys_therm1", 0x03 },
> > > + { "sys_therm2", 0x04 },
> > > + { "sys_therm3", 0x05 },
> > > + { "sys_therm4", 0x06 },
> > > + { "sys_therm5", 0x07 },
> > > + { "sys_therm6", 0x08 },
> > > +};
> >
> > You could probably retrieve these strings from the dt if you really need
> > them.
> >
> > I don't think you need static consts in your driver though you could
> > just as easily do `sprintf("sys_therm%d\n", i) where you use
> > ec_therms[i].name - the name is only used to print errors and you have
> > the index of the channel when you do.
> >
> > It would be nicer to get the strings from DT - certainly make the string
> > names mandatory but, then let the DT specify those names.
> >
> > Either that or just do the sprintf("sys_therm%d\n", i); for the index,
> > whichever you wish yourself.
>
> Hi Bryan,
>
> Will answer here to all three comments about `sys_thermX`.
>
> The reason I have added them as static consts here, and defined them in
> the schema is because the order of the channels matters:
> 1. On my XPS (UEFI v2.11.0) changes in sys_therm2 immediately result in
> changes in fan speeds. Other channels seemingly have no affect, at
> least when spoofed one by one, implying that EC cares which value
> is which.
> 2. As I do not know internals of the EC firmware, even if today the other
> thermistor channels ordering is seemingly not relevant, we cannot be
> sure it will not change with EC firmware upgrade.
>
> I have reconstructed the order of channels by comparing i2c data dumps
> and real-time temps on Windows, eg. sys_therm0 is sent to EC under id 0x02
> and represents the TZ71 (around dram on XPS). There is no other reason to
> have the names of the channels in this driver except for enforcing the
> channel mapping, so `sprintf("sys_therm%d\n", i)` wouldn't be useful.
>
> By allowing source and sink to define the names and not enforcing it in
> schema we lose ability to force the correct order, there is no way of
> knowing whether "lpddr5-therm" or "ssd-therm" goes first. By forcing
> "sys_thermX" convention, one would need to figure which one is which,
> for example by referring to laptop schematics. I assume, "thena"'s
> schematics has thermistors labeled as "sys_thermX"?
>
> I do agree that labels of the ADC nodes could be more useful for the
> user. So far I followed the example of sc8280xp platforms that define
> ADC channels with "sys_thermX". Perhaps, we could separate the
> io-channel-names and ADC node labels then? eg:
>
The general guidance for such naming questions is to follow naming from
the schematics, whenever available.
> + io-channel-names = "sys_therm0",
> + "sys_therm1",
> ...
>
> + &pmk8550_vadc {
> + sys_therm0: channel@14c {
> + reg = <PM8350_ADC7_GPIO3_100K_PU(1)>;
> + qcom,hw-settle-time = <200>;
> + qcom,ratiometric;
> + label = "lpddr5x-therm";
>
> Though not sure if such approach is 'legal'?
I might be missing something, but that does look legal. Your node's
label follows (what I assume to be) the naming in the schematics and you
provide a human-friendly label.
PS. Once we have these adc channels in place, I presume there's also a
TM that would allow us to wire them up as cooling-maps, to throttle the
CPUs? Similar to "skin-temp-thermal" in x13s.
Regards,
Bjorn
^ permalink raw reply
* [PATCH RFC 3/3] dt-bindings: dsp: fsl,dsp: remove descriptions for common properties
From: Laurentiu Mihalcea @ 2026-04-06 12:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Viresh Kumar,
Tushar Khandelwal, Shengjiu Wang, Daniel Baluta
Cc: devicetree, linux-kernel
In-Reply-To: <20260406122025.4515-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
"mboxes", "power-domains", and "memory-region" are common properties,
which should be already documented. As such, descriptions referencing
old .txt binding files provide no additional information. Thus, remove
them.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
Documentation/devicetree/bindings/dsp/fsl,dsp.yaml | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
index 65ed26aa3308..d483a229c292 100644
--- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
@@ -44,17 +44,10 @@ properties:
minItems: 3
power-domains:
- description:
- List of phandle and PM domain specifier as documented in
- Documentation/devicetree/bindings/power/power_domain.txt
minItems: 1
maxItems: 4
mboxes:
- description:
- List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB
- or - 1 channel for TX, 1 channel for RX, 1 channel for RXDB
- (see mailbox/fsl,mu.txt)
maxItems: 3
mbox-names:
@@ -64,9 +57,6 @@ properties:
- const: rxdb
memory-region:
- description:
- phandle to a node describing reserved memory (System RAM memory)
- used by DSP (see bindings/reserved-memory/reserved-memory.txt)
maxItems: 4
firmware-name:
--
2.43.0
^ permalink raw reply related
* [PATCH RFC 2/3] dt-bindings: dsp: fsl,dsp: remove reserved memory definitions
From: Laurentiu Mihalcea @ 2026-04-06 12:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Viresh Kumar,
Tushar Khandelwal, Shengjiu Wang, Daniel Baluta
Cc: devicetree, linux-kernel
In-Reply-To: <20260406122025.4515-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
There's no need to define the DT nodes referenced by the node's phandle.
Remove them.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../devicetree/bindings/dsp/fsl,dsp.yaml | 17 -----------------
1 file changed, 17 deletions(-)
diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
index 7970f90781c2..65ed26aa3308 100644
--- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
@@ -153,23 +153,6 @@ examples:
- |
#include <dt-bindings/clock/imx8mp-clock.h>
#include <dt-bindings/reset/imx8mp-reset-audiomix.h>
- dsp_reserved: dsp@92400000 {
- reg = <0x92400000 0x1000000>;
- no-map;
- };
- dsp_vdev0vring0: vdev0vring0@942f0000 {
- reg = <0x942f0000 0x8000>;
- no-map;
- };
- dsp_vdev0vring1: vdev0vring1@942f8000 {
- reg = <0x942f8000 0x8000>;
- no-map;
- };
- dsp_vdev0buffer: vdev0buffer@94300000 {
- compatible = "shared-dma-pool";
- reg = <0x94300000 0x100000>;
- no-map;
- };
dsp: dsp@3b6e8000 {
compatible = "fsl,imx8mp-hifi4";
--
2.43.0
^ permalink raw reply related
* [PATCH RFC 1/3] dt-bindings: dsp: fsl,dsp: drop references to SOF programming model
From: Laurentiu Mihalcea @ 2026-04-06 12:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Viresh Kumar,
Tushar Khandelwal, Shengjiu Wang, Daniel Baluta
Cc: devicetree, linux-kernel
In-Reply-To: <20260406122025.4515-1-laurentiumihalcea111@gmail.com>
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Compatible names ending in "-dsp" are associated with the SOF programming
model, which, at the moment has no devicetree users in the upstream
kernel. Furthermore, the binding either doesn't document all of the
required properties (e.g. "port" children are missing,
"memory-region-names" is undocumented) or the properties that are
documented are wrong (e.g. fsl,imx8ulp-hifi4 needs 2 reserved memory
regions, not 1).
Since the two programming models (SOF and non-SOF) have some differences,
it would make more sense for the 8 series DSP bindings to follow the same
pattern used for MX95's CM7 (i.e. one or more binding files, including the
common fsl,sof-cpu.yaml).
Given all of this, and since, at the moment, there's no plan to upstream
the devicetrees making use of this programming model anytime soon, drop all
the references to the SOF programming model from the binding docuemnt as an
attempt to clean it up.
Signed-off-by: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
---
.../devicetree/bindings/dsp/fsl,dsp.yaml | 67 ++-----------------
.../bindings/mailbox/arm,mhuv2.yaml | 8 +--
2 files changed, 9 insertions(+), 66 deletions(-)
diff --git a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
index e610b7636a08..7970f90781c2 100644
--- a/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
+++ b/Documentation/devicetree/bindings/dsp/fsl,dsp.yaml
@@ -17,10 +17,6 @@ description: |
properties:
compatible:
enum:
- - fsl,imx8qxp-dsp
- - fsl,imx8qm-dsp
- - fsl,imx8mp-dsp
- - fsl,imx8ulp-dsp
- fsl,imx8qxp-hifi4
- fsl,imx8qm-hifi4
- fsl,imx8mp-hifi4
@@ -59,18 +55,18 @@ properties:
List of <&phandle type channel> - 2 channels for TXDB, 2 channels for RXDB
or - 1 channel for TX, 1 channel for RX, 1 channel for RXDB
(see mailbox/fsl,mu.txt)
- minItems: 3
- maxItems: 4
+ maxItems: 3
mbox-names:
- minItems: 3
- maxItems: 4
+ items:
+ - const: tx
+ - const: rx
+ - const: rxdb
memory-region:
description:
phandle to a node describing reserved memory (System RAM memory)
used by DSP (see bindings/reserved-memory/reserved-memory.txt)
- minItems: 1
maxItems: 4
firmware-name:
@@ -110,7 +106,6 @@ allOf:
compatible:
contains:
enum:
- - fsl,imx8qxp-dsp
- fsl,imx8qxp-hifi4
then:
properties:
@@ -123,7 +118,6 @@ allOf:
compatible:
contains:
enum:
- - fsl,imx8qm-dsp
- fsl,imx8qm-hifi4
then:
properties:
@@ -135,9 +129,7 @@ allOf:
compatible:
contains:
enum:
- - fsl,imx8mp-dsp
- fsl,imx8mp-hifi4
- - fsl,imx8ulp-dsp
- fsl,imx8ulp-hifi4
then:
properties:
@@ -149,39 +141,6 @@ allOf:
compatible:
contains:
enum:
- - fsl,imx8qxp-hifi4
- - fsl,imx8qm-hifi4
- - fsl,imx8mp-hifi4
- - fsl,imx8ulp-hifi4
- then:
- properties:
- memory-region:
- minItems: 4
- mboxes:
- maxItems: 3
- mbox-names:
- items:
- - const: tx
- - const: rx
- - const: rxdb
- else:
- properties:
- memory-region:
- maxItems: 1
- mboxes:
- minItems: 4
- mbox-names:
- items:
- - const: txdb0
- - const: txdb1
- - const: rxdb0
- - const: rxdb1
- - if:
- properties:
- compatible:
- contains:
- enum:
- - fsl,imx8mp-dsp
- fsl,imx8mp-hifi4
then:
required:
@@ -191,22 +150,6 @@ allOf:
additionalProperties: false
examples:
- - |
- #include <dt-bindings/firmware/imx/rsrc.h>
- #include <dt-bindings/clock/imx8-clock.h>
- dsp@596e8000 {
- compatible = "fsl,imx8qxp-dsp";
- reg = <0x596e8000 0x88000>;
- clocks = <&adma_lpcg IMX_ADMA_LPCG_DSP_IPG_CLK>,
- <&adma_lpcg IMX_ADMA_LPCG_OCRAM_IPG_CLK>,
- <&adma_lpcg IMX_ADMA_LPCG_DSP_CORE_CLK>;
- clock-names = "ipg", "ocram", "core";
- power-domains = <&pd IMX_SC_R_MU_13B>,
- <&pd IMX_SC_R_MU_2A>;
- mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
- mboxes = <&lsio_mu13 2 0>, <&lsio_mu13 2 1>, <&lsio_mu13 3 0>, <&lsio_mu13 3 1>;
- memory-region = <&dsp_reserved>;
- };
- |
#include <dt-bindings/clock/imx8mp-clock.h>
#include <dt-bindings/reset/imx8mp-reset-audiomix.h>
diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
index 3828d77f6316..d6ab66f6f3d5 100644
--- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
+++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml
@@ -192,16 +192,16 @@ examples:
};
mhu_client: dsp@596e8000 {
- compatible = "fsl,imx8qxp-dsp";
+ compatible = "fsl,imx8qxp-hifi4";
reg = <0 0x596e8000 0 0x88000>;
clocks = <&adma_lpcg 0>, <&adma_lpcg 1>, <&adma_lpcg 2>;
clock-names = "ipg", "ocram", "core";
power-domains = <&pd 0>, <&pd 1>;
- mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1";
+ mbox-names = "tx", "rx", "rxdb";
mboxes = <&mhu_tx 2 0>, //data-transfer protocol with 5 windows, mhu-tx
- <&mhu_tx 3 0>, //data-transfer protocol with 7 windows, mhu-tx
<&mhu_rx 2 27>, //doorbell protocol channel 2, doorbell 27, mhu-rx
<&mhu_rx 0 0>; //data-transfer protocol with 1 window, mhu-rx
- memory-region = <&dsp_reserved>;
+ memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>,
+ <&dsp_vdev0vring1>, <&dsp_reserved>;
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH RFC 0/3] dt-bindings: dsp: fsl,dsp: small cleanup
From: Laurentiu Mihalcea @ 2026-04-06 12:20 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Viresh Kumar,
Tushar Khandelwal, Shengjiu Wang, Daniel Baluta
Cc: devicetree, linux-kernel
From: Laurentiu Mihalcea <laurentiu.mihalcea@nxp.com>
Hello everyone,
So, with this patch series, we attempt to tidy up the fsl,dsp binding a
bit. Most importantly (and the reason why this was sent as an RFC), I'd
like to remove the compatibles corresponding to the SOF programming model
(i.e. the compatibles ending in "-dsp") from the binding. The reasons are
explained in the commit message, but basically the problem we're dealing
with is that we have a binding file in which two relatively different
programming models have been crammed together.
Since at the moment there's no plan to upstream the devicetrees making use
of the SOF programming model, we are stuck having to also take the SOF
programming model into consideration when making changes to the binding
(even if said changes only target the RPROC programming model).
Now, since there's no devicetree users in the upstream kernel for the SOF
programming model, I'd like to permanently remove it from the fsl,dsp
binding. If the SOF devicetrees are ever upstreamed then I think the
bindings should follow the model of fsl,imx95-cm7.yaml (i.e. one binding
per chip or group of chips, including the common fsl,sof-cpu)
As for the other projects, u-boot seems to have a devicetree node using
the "fsl,imx8mp-dsp" compatible (node has status "disabled", though)
defined at "arch/arm/dts/imx8mp.dtsi". The node configuration seems to
follow that which was used in the upstream kernel and modified via
commit f048f2126fcc ("arm64: dts: imx8mp: Configure dsp node for rproc
usage") to use the RPROC programming model.
If need be, I can send a patch to u-boot in which we configure the DT
node for RPROC like we did in Linux.
Let me know if this series would be acceptable given the current
situation.
Thanks!
Laurentiu Mihalcea (3):
dt-bindings: dsp: fsl,dsp: drop references to SOF programming model
dt-bindings: dsp: fsl,dsp: remove reserved memory definitions
dt-bindings: dsp: fsl,dsp: remove descriptions for common properties
.../devicetree/bindings/dsp/fsl,dsp.yaml | 94 +------------------
.../bindings/mailbox/arm,mhuv2.yaml | 8 +-
2 files changed, 9 insertions(+), 93 deletions(-)
--
2.43.0
^ 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