* Re: [PATCH v2 2/7] ASoC: loongson: Add Loongson-2K0300 I2S controller support
From: Binbin Zhou @ 2026-06-15 1:06 UTC (permalink / raw)
To: Huacai Chen
Cc: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Jaroslav Kysela,
Takashi Iwai, Xuerui Wang, loongarch, devicetree, linux-sound
In-Reply-To: <CAAhV-H6G5vTH_58_pKvBnvjdr2eVTWTctUqmPAX3aMjsFDjsQg@mail.gmail.com>
On Sat, Jun 13, 2026 at 11:18 AM Huacai Chen <chenhuacai@kernel.org> wrote:
>
> Hi, Binbin,
>
> On Thu, Jun 4, 2026 at 10:11 AM Binbin Zhou <zhoubinbin@loongson.cn> wrote:
> >
> > The Loongson-2K0300 I2S interface differs significantly from the
> > Loongson-2K1000. Although both utilize external DMA controllers, the
> > Loongson-2K0300 does not require additional registers for routing
> > configuration.
> >
> > Due to hardware design flaw, an extra controller reset sequence is
> > required during probe.
> >
> > Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> > ---
> > sound/soc/loongson/loongson_i2s_plat.c | 42 +++++++++++++++++++++-----
> > 1 file changed, 35 insertions(+), 7 deletions(-)
> >
> > diff --git a/sound/soc/loongson/loongson_i2s_plat.c b/sound/soc/loongson/loongson_i2s_plat.c
> > index ac054b6ce632..b4d807ee7f8f 100644
> > --- a/sound/soc/loongson/loongson_i2s_plat.c
> > +++ b/sound/soc/loongson/loongson_i2s_plat.c
> > @@ -2,7 +2,7 @@
> > //
> > // Loongson I2S controller master mode dirver(platform device)
> > //
> > -// Copyright (C) 2023-2024 Loongson Technology Corporation Limited
> > +// Copyright (C) 2023-2026 Loongson Technology Corporation Limited
> > //
> > // Author: Yingkun Meng <mengyingkun@loongson.cn>
> > // Binbin Zhou <zhoubinbin@loongson.cn>
> > @@ -21,6 +21,7 @@
> > #include "loongson_i2s.h"
> > #include "loongson_dma.h"
> >
> > +/* Loongson-2K1000 APBDMA routing */
> > #define LOONGSON_I2S_RX_DMA_OFFSET 21
> > #define LOONGSON_I2S_TX_DMA_OFFSET 18
> >
> > @@ -30,6 +31,11 @@
> > #define LOONGSON_DMA3_CONF 0x3
> > #define LOONGSON_DMA4_CONF 0x4
> >
> > +struct loongson_i2s_plat_config {
> > + int rev_id;
> > + int (*i2s_dma_config)(struct platform_device *pdev);
> > +};
> > +
> > static int loongson_i2s_apbdma_config(struct platform_device *pdev)
> > {
> > int val;
> > @@ -47,8 +53,18 @@ static int loongson_i2s_apbdma_config(struct platform_device *pdev)
> > return 0;
> > }
> >
> > +static struct loongson_i2s_plat_config ls2k1000_i2s_plat_config = {
> > + .rev_id = 0,
> > + .i2s_dma_config = loongson_i2s_apbdma_config,
> > +};
> > +
> > +static struct loongson_i2s_plat_config ls2k0300_i2s_plat_config = {
> > + .rev_id = 1,
> > +};
> Put ls2k0300_i2s_plat_config before ls2k1000_i2s_plat_config?
OK, I will do it in the next version.
>
> Huacai
>
> > +
> > static int loongson_i2s_plat_probe(struct platform_device *pdev)
> > {
> > + const struct loongson_i2s_plat_config *plat_config;
> > struct device *dev = &pdev->dev;
> > struct loongson_i2s *i2s;
> > struct resource *res;
> > @@ -59,12 +75,17 @@ static int loongson_i2s_plat_probe(struct platform_device *pdev)
> > if (!i2s)
> > return -ENOMEM;
> >
> > - ret = loongson_i2s_apbdma_config(pdev);
> > - if (ret)
> > - return ret;
> > + plat_config = device_get_match_data(dev);
> > + if (!plat_config)
> > + return -EINVAL;
> >
> > - res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > - i2s->reg_base = devm_ioremap_resource(&pdev->dev, res);
> > + if (plat_config->i2s_dma_config) {
> > + ret = plat_config->i2s_dma_config(pdev);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + i2s->reg_base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
> > if (IS_ERR(i2s->reg_base))
> > return dev_err_probe(dev, PTR_ERR(i2s->reg_base),
> > "devm_ioremap_resource failed\n");
> > @@ -87,11 +108,17 @@ static int loongson_i2s_plat_probe(struct platform_device *pdev)
> > if (IS_ERR(i2s_clk))
> > return dev_err_probe(dev, PTR_ERR(i2s_clk), "clock property invalid\n");
> > i2s->clk_rate = clk_get_rate(i2s_clk);
> > + i2s->rev_id = plat_config->rev_id;
> >
> > dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
> > dev_set_name(dev, LS_I2S_DRVNAME);
> > dev_set_drvdata(dev, i2s);
> >
> > + if (i2s->rev_id == 1) {
> > + regmap_update_bits(i2s->regmap, LS_I2S_CTRL, I2S_CTRL_RESET, I2S_CTRL_RESET);
> > + fsleep(200);
> > + }
> > +
> > ret = devm_snd_soc_register_component(dev, &loongson_i2s_edma_component,
> > &loongson_i2s_dai, 1);
> > if (ret)
> > @@ -102,7 +129,8 @@ static int loongson_i2s_plat_probe(struct platform_device *pdev)
> > }
> >
> > static const struct of_device_id loongson_i2s_ids[] = {
> > - { .compatible = "loongson,ls2k1000-i2s" },
> > + { .compatible = "loongson,ls2k0300-i2s", .data = &ls2k0300_i2s_plat_config },
> > + { .compatible = "loongson,ls2k1000-i2s", .data = &ls2k1000_i2s_plat_config },
> > { /* sentinel */ },
> > };
> > MODULE_DEVICE_TABLE(of, loongson_i2s_ids);
> > --
> > 2.52.0
> >
> >
--
Thanks.
Binbin
^ permalink raw reply
* RE: [PATCH v9 2/2] leds: ltc3220: Add Support for LTC3220 18 channel LED Driver
From: Escala, Edelweise @ 2026-06-15 1:12 UTC (permalink / raw)
To: Lee Jones
Cc: Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260611114741.GP4151951@google.com>
Hi Lee,
Yes I'll take care of these.
> -----Original Message-----
> From: Lee Jones <lee@kernel.org>
> Sent: Thursday, June 11, 2026 7:48 PM
> To: Escala, Edelweise <Edelweise.Escala@analog.com>
> Cc: Pavel Machek <pavel@kernel.org>; Rob Herring <robh@kernel.org>; Krzysztof
> Kozlowski <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; linux-
> leds@vger.kernel.org; devicetree@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v9 2/2] leds: ltc3220: Add Support for LTC3220 18 channel
> LED Driver
>
> [External]
>
> /* Sashiko Automation: Issues Found (10 Findings) */
>
> Would you mind taking care of these before I conduct my next review please?
>
> On Thu, 28 May 2026, Edelweise Escala wrote:
>
> > Add driver for the LTC3220 18-channel LED driver with I2C interface,
> > individual brightness control, and hardware-assisted blink/gradation
> > features.
> >
> > Signed-off-by: Edelweise Escala <edelweise.escala@analog.com>
> > ---
> > MAINTAINERS | 1 +
> > drivers/leds/Kconfig | 13 ++
> > drivers/leds/Makefile | 1 +
> > drivers/leds/leds-ltc3220.c | 440
> > ++++++++++++++++++++++++++++++++++++++++++++
> > 4 files changed, 455 insertions(+)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index
> > c8a242577d2f..0f553ada61d9 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -15229,6 +15229,7 @@ L: linux-leds@vger.kernel.org
> > S: Maintained
> > W: https://ez.analog.com/linux-software-drivers
> > F: Documentation/devicetree/bindings/leds/adi,ltc3220.yaml
> > +F: drivers/leds/leds-ltc3220.c
> >
> > LTC4282 HARDWARE MONITOR DRIVER
> > M: Nuno Sa <nuno.sa@analog.com>
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index
> > f4a0a3c8c870..31b1e3ff094c 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -1000,6 +1000,19 @@ config LEDS_ST1202
> > Say Y to enable support for LEDs connected to LED1202
> > LED driver chips accessed via the I2C bus.
> >
> > +config LEDS_LTC3220
> > + tristate "LED Driver for Analog Devices Inc. LTC3220"
> > + depends on I2C && LEDS_CLASS
> > + select REGMAP_I2C
> > + help
> > + Say Y to enable support for the Analog Devices LTC3220
> > + 18-channel LED controller with I2C interface.
> > + The driver supports individual LED brightness control (64 steps),
> > + hardware-assisted blinking and gradation effects.
> > +
> > + To compile this driver as a module, choose M here: the module will
> > + be called leds-ltc3220.
> > +
> > config LEDS_TPS6105X
> > tristate "LED support for TI TPS6105X"
> > depends on LEDS_CLASS
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile index
> > 7db3768912ca..a68244bd50fb 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -61,6 +61,7 @@ obj-$(CONFIG_LEDS_LP8788) += leds-
> lp8788.o
> > obj-$(CONFIG_LEDS_LP8860) += leds-lp8860.o
> > obj-$(CONFIG_LEDS_LP8864) += leds-lp8864.o
> > obj-$(CONFIG_LEDS_LT3593) += leds-lt3593.o
> > +obj-$(CONFIG_LEDS_LTC3220) += leds-ltc3220.o
> > obj-$(CONFIG_LEDS_MAX5970) += leds-max5970.o
> > obj-$(CONFIG_LEDS_MAX77650) += leds-max77650.o
> > obj-$(CONFIG_LEDS_MAX77705) += leds-max77705.o
> > diff --git a/drivers/leds/leds-ltc3220.c b/drivers/leds/leds-ltc3220.c
> > new file mode 100644 index 000000000000..a633ac5ca6ae
> > --- /dev/null
> > +++ b/drivers/leds/leds-ltc3220.c
> > @@ -0,0 +1,440 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * LTC3220 18-Channel LED Driver
> > + *
> > + * Copyright 2026 Analog Devices Inc.
> > + *
> > + * Author: Edelweise Escala <edelweise.escala@analog.com> */
> > +
> > +#include <linux/bitfield.h>
> > +#include <linux/delay.h>
>
> [Severity: Low]
> Is this include needed?
>
> It doesn't appear that any delay functions like msleep() or usleep_range() are
> used in the driver implementation.
>
I'll probably need delay again for the reset comment later.
>
> > +#include <linux/device.h>
> > +#include <linux/gpio/consumer.h>
> > +#include <linux/i2c.h>
> > +#include <linux/leds.h>
> > +#include <linux/mod_devicetable.h>
> > +#include <linux/module.h>
> > +#include <linux/regmap.h>
> > +#include <linux/types.h>
>
> [Severity: Low]
> Should this file include <linux/property.h>?
>
> The driver uses fwnode property APIs such as
> device_for_each_child_node_scoped(),
> fwnode_property_read_u32(), and fwnode_property_present(), which are
> defined in <linux/property.h>.
>
>
I'll check this.
> > +
> > +/* LTC3220 Registers */
> > +#define LTC3220_COMMAND_REG 0x00
> > +#define LTC3220_QUICK_WRITE_MASK BIT(0)
> > +#define LTC3220_SHUTDOWN_MASK BIT(3)
> > +
> > +#define LTC3220_ULED_REG(x) (0x01 + (x))
> > +#define LTC3220_LED_CURRENT_MASK GENMASK(5,
> 0)
> > +#define LTC3220_LED_MODE_MASK GENMASK(7,
> 6)
> > +
> > +#define LTC3220_GRAD_BLINK_REG 0x13
> > +#define LTC3220_GRADATION_MASK GENMASK(2, 0)
> > +#define LTC3220_GRADATION_DIRECTION_MASK BIT(0)
> > +#define LTC3220_GRADATION_PERIOD_MASK
> GENMASK(2, 1)
> > +#define LTC3220_BLINK_MASK GENMASK(4,
> 3)
> > +
> > +#define LTC3220_NUM_LEDS 18
> > +
> > +#define LTC3220_GRADATION_START_VALUE 128
>
> [Severity: Low]
> Is this macro used anywhere in the driver?
>
> It appears to be dead code as it is never referenced.
>
>
Will remove
> > +#define LTC3220_GRADATION_RAMP_TIME_240MS 240
> > +#define LTC3220_GRADATION_RAMP_TIME_480MS 480
> > +
> > +#define LTC3220_BLINK_ON_156MS 156
> > +#define LTC3220_BLINK_ON_625MS 625
> > +#define LTC3220_BLINK_PERIOD_1250MS 1250
> > +#define LTC3220_BLINK_PERIOD_2500MS 2500
> > +
> > +#define LTC3220_BLINK_SHORT_ON_TIME BIT(0)
> > +#define LTC3220_BLINK_LONG_PERIOD BIT(1)
> > +
> > +enum ltc3220_led_mode {
> > + LTC3220_NORMAL_MODE,
> > + LTC3220_BLINK_MODE,
> > + LTC3220_GRADATION_MODE,
> > +};
> > +
> > +enum ltc3220_blink_mode {
> > + LTC3220_BLINK_MODE_625MS_1250MS,
> > + LTC3220_BLINK_MODE_156MS_1250MS,
> > + LTC3220_BLINK_MODE_625MS_2500MS,
> > + LTC3220_BLINK_MODE_156MS_2500MS
> > +};
> > +
> > +enum ltc3220_gradation_mode {
> > + LTC3220_GRADATION_MODE_DISABLED,
> > + LTC3220_GRADATION_MODE_240MS_RAMP_TIME,
> > + LTC3220_GRADATION_MODE_480MS_RAMP_TIME,
> > + LTC3220_GRADATION_MODE_960MS_RAMP_TIME
> > +};
> > +
> > +static bool ltc3220_volatile_reg(struct device *dev, unsigned int
> > +reg) {
> > + return reg == LTC3220_GRAD_BLINK_REG; }
>
> [Severity: High]
> Does this register need to be marked volatile?
>
> Marking a register as volatile tells regmap to bypass the cache and read from the
> physical hardware. If the LTC3220 is a write-only I2C device, the physical read will
> fail, causing regmap_update_bits() to fail entirely in
> ltc3220_pattern_set() and ltc3220_blink_set().
>
> Even if the device supports reads, this register is exclusively controlled by
> software and does not change autonomously, so could it be cached normally to
> avoid unnecessary I2C reads?
>
>
Will check if it will work if I remove this, I had an issue with the gradation and blink register when I did not add volatile regisgters
> > +
> > +static const struct regmap_config ltc3220_regmap_config = {
> > + .reg_bits = 8,
> > + .val_bits = 8,
> > + .max_register = LTC3220_GRAD_BLINK_REG,
> > + .cache_type = REGCACHE_FLAT_S,
> > + .volatile_reg = ltc3220_volatile_reg, };
> > +
> > +struct ltc3220_uled_cfg {
> > + struct led_classdev led_cdev;
> > + u8 reg_value;
> > + u8 led_index;
> > +};
> > +
> > +struct ltc3220 {
> > + struct ltc3220_uled_cfg uled_cfg[LTC3220_NUM_LEDS];
> > + struct regmap *regmap;
> > + bool is_aggregated;
> > +};
> > +
> > +/*
> > + * Set LED brightness. Hardware supports 0-63 brightness levels.
> > + * Mode switching (blink/gradation) is handled through dedicated callbacks.
> > + */
> > +static int ltc3220_set_led_data(struct led_classdev *led_cdev,
> > + enum led_brightness brightness)
> > +{
> > + struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct
> ltc3220_uled_cfg,
> > + led_cdev);
> > + struct ltc3220 *ltc3220 = container_of(uled_cfg, struct ltc3220,
> > + uled_cfg[uled_cfg->led_index]);
>
> [Severity: Low]
> Will this dynamic variable index inside container_of() cause a build failure?
>
> The driver attempts to retrieve the parent structure using uled_cfg[uled_cfg-
> >led_index]. The container_of macro relies on offsetof(), which strictly requires
> the member argument to be a constant expression.
>
> Since uled_cfg->led_index is a runtime variable, this violates the C standard and
> can abort compilation on compilers like Clang with an error about a non-constant
> integer expression.
>
>
Will fix this as well as other container of issues
> > + int ret;
> > +
> > + ret = regmap_write(ltc3220->regmap, LTC3220_ULED_REG(uled_cfg-
> >led_index),
> > + brightness);
> > + if (ret)
> > + return ret;
> > +
> > + uled_cfg->reg_value = brightness;
> > +
> > + /*
> > + * When aggregated LED mode is enabled, writing to LED 1 updates all
> > + * LEDs simultaneously via quick-write mode. Update cached values for
> > + * all LEDs to reflect the synchronized state.
> > + * See Documentation/devicetree/bindings/leds/adi,ltc3220.yaml for
> how
> > + * to configure aggregated LED mode.
> > + */
> > + if (ltc3220->is_aggregated && uled_cfg->led_index == 0) {
> > + for (int i = 0; i < LTC3220_NUM_LEDS; i++)
> > + ltc3220->uled_cfg[i].reg_value = brightness;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static enum led_brightness ltc3220_get_led_data(struct led_classdev
> > +*led_cdev) {
> > + struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct
> ltc3220_uled_cfg,
> > + led_cdev);
> > +
> > + return uled_cfg->reg_value;
> > +}
> > +
> > +/*
> > + * LTC3220 pattern support for hardware-assisted breathing/gradation.
> > + * The hardware supports 3 gradation ramp time 240ms, 480ms, 960ms)
> > + * and can ramp up or down.
> > + *
> > + * Pattern array interpretation:
> > + * pattern[0].brightness = start brightness (0-63)
> > + * pattern[0].delta_t = ramp time in milliseconds
> > + * pattern[1].brightness = end brightness (0-63)
> > + * pattern[1].delta_t = (optional, can be 0 or same as pattern[0].delta_t)
> > + */
> > +static int ltc3220_pattern_set(struct led_classdev *led_cdev,
> > + struct led_pattern *pattern,
> > + u32 len, int repeat)
> > +{
> > + struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct
> ltc3220_uled_cfg,
> > + led_cdev);
> > + struct ltc3220 *ltc3220 = container_of(uled_cfg, struct ltc3220,
> > + uled_cfg[uled_cfg->led_index]);
>
> [Severity: Low]
> Will this dynamic variable index inside container_of() cause a build failure?
>
> The driver attempts to retrieve the parent structure using uled_cfg[uled_cfg-
> >led_index]. The container_of macro relies on offsetof(), which strictly requires
> the member argument to be a constant expression.
>
> Since uled_cfg->led_index is a runtime variable, this violates the C standard and
> can abort compilation on compilers like Clang with an error about a non-constant
> integer expression.
>
>
> > + u8 gradation_period;
> > + u8 start_brightness;
> > + u8 end_brightness;
> > + u8 gradation_val;
> > + bool is_increasing;
> > + int ret;
> > +
> > + if (len != 2)
> > + return -EINVAL;
> > +
> > + start_brightness = pattern[0].brightness &
> LTC3220_LED_CURRENT_MASK;
> > + end_brightness = pattern[1].brightness &
> LTC3220_LED_CURRENT_MASK;
> > +
> > + is_increasing = end_brightness > start_brightness;
> > +
> > + if (pattern[0].delta_t == 0)
> > + gradation_period = LTC3220_GRADATION_MODE_DISABLED;
> > + else if (pattern[0].delta_t <=
> LTC3220_GRADATION_RAMP_TIME_240MS)
> > + gradation_period =
> LTC3220_GRADATION_MODE_240MS_RAMP_TIME;
> > + else if (pattern[0].delta_t <=
> LTC3220_GRADATION_RAMP_TIME_480MS)
> > + gradation_period =
> LTC3220_GRADATION_MODE_480MS_RAMP_TIME;
> > + else
> > + gradation_period =
> LTC3220_GRADATION_MODE_960MS_RAMP_TIME;
> > +
> > + gradation_val = FIELD_PREP(LTC3220_GRADATION_PERIOD_MASK,
> gradation_period);
> > + gradation_val |= FIELD_PREP(LTC3220_GRADATION_DIRECTION_MASK,
> > +is_increasing);
> > +
> > + ret = regmap_update_bits(ltc3220->regmap,
> LTC3220_GRAD_BLINK_REG,
> > + LTC3220_GRADATION_MASK, gradation_val);
> > + if (ret)
> > + return ret;
> > +
> > + ret = ltc3220_set_led_data(led_cdev, start_brightness);
> > + if (ret)
> > + return ret;
> > +
> > + ret = regmap_write(ltc3220->regmap, LTC3220_ULED_REG(uled_cfg-
> >led_index),
> > + FIELD_PREP(LTC3220_LED_MODE_MASK,
> LTC3220_GRADATION_MODE) |
> > + end_brightness);
> > + if (ret)
> > + return ret;
> > +
> > + uled_cfg->reg_value = end_brightness;
> > +
> > + return 0;
> > +}
> > +
> > +static int ltc3220_pattern_clear(struct led_classdev *led_cdev) {
> > + struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct
> ltc3220_uled_cfg,
> > + led_cdev);
> > + struct ltc3220 *ltc3220 = container_of(uled_cfg, struct ltc3220,
> > + uled_cfg[uled_cfg->led_index]);
>
> [Severity: Low]
> Will this dynamic variable index inside container_of() cause a build failure?
>
> The driver attempts to retrieve the parent structure using uled_cfg[uled_cfg-
> >led_index]. The container_of macro relies on offsetof(), which strictly requires
> the member argument to be a constant expression.
>
> Since uled_cfg->led_index is a runtime variable, this violates the C standard and
> can abort compilation on compilers like Clang with an error about a non-constant
> integer expression.
>
>
> > + int ret;
> > +
> > + ret = regmap_update_bits(ltc3220->regmap,
> LTC3220_ULED_REG(uled_cfg->led_index),
> > + LTC3220_LED_MODE_MASK,
> LTC3220_NORMAL_MODE);
> > + if (ret)
> > + return ret;
> > +
> > + return ltc3220_set_led_data(led_cdev, LED_OFF); }
> > +
> > +/*
> > + * LTC3220 has a global blink configuration that affects all LEDs.
> > + * This implementation allows per-LED blink requests, but the blink
> > +timing
> > + * will be shared across all LEDs. The delay values are mapped to the
> > + * hardware's discrete blink rates.
> > + */
> > +static int ltc3220_blink_set(struct led_classdev *led_cdev,
> > + unsigned long *delay_on,
> > + unsigned long *delay_off)
> > +{
> > + struct ltc3220_uled_cfg *uled_cfg = container_of(led_cdev, struct
> ltc3220_uled_cfg,
> > + led_cdev);
> > + struct ltc3220 *ltc3220 = container_of(uled_cfg, struct ltc3220,
> > + uled_cfg[uled_cfg->led_index]);
>
> [Severity: Low]
> Will this dynamic variable index inside container_of() cause a build failure?
>
> The driver attempts to retrieve the parent structure using uled_cfg[uled_cfg-
> >led_index]. The container_of macro relies on offsetof(), which strictly requires
> the member argument to be a constant expression.
>
> Since uled_cfg->led_index is a runtime variable, this violates the C standard and
> can abort compilation on compilers like Clang with an error about a non-constant
> integer expression.
>
>
> > + u8 blink_mode = 0;
> > + int ret;
> > +
> > + if (*delay_on <= LTC3220_BLINK_ON_156MS)
> > + blink_mode = LTC3220_BLINK_SHORT_ON_TIME;
> > +
> > + if (*delay_on + *delay_off > LTC3220_BLINK_PERIOD_1250MS)
> > + blink_mode |= LTC3220_BLINK_LONG_PERIOD;
> > +
> > + switch (blink_mode) {
> > + case LTC3220_BLINK_MODE_625MS_1250MS:
> > + *delay_on = LTC3220_BLINK_ON_625MS;
> > + *delay_off = LTC3220_BLINK_PERIOD_1250MS -
> LTC3220_BLINK_ON_625MS;
> > + break;
> > + case LTC3220_BLINK_MODE_156MS_1250MS:
> > + *delay_on = LTC3220_BLINK_ON_156MS;
> > + *delay_off = LTC3220_BLINK_PERIOD_1250MS -
> LTC3220_BLINK_ON_156MS;
> > + break;
> > + case LTC3220_BLINK_MODE_625MS_2500MS:
> > + *delay_on = LTC3220_BLINK_ON_625MS;
> > + *delay_off = LTC3220_BLINK_PERIOD_2500MS -
> LTC3220_BLINK_ON_625MS;
> > + break;
> > + case LTC3220_BLINK_MODE_156MS_2500MS:
> > + *delay_on = LTC3220_BLINK_ON_156MS;
> > + *delay_off = LTC3220_BLINK_PERIOD_2500MS -
> LTC3220_BLINK_ON_156MS;
> > + break;
> > + }
> > +
> > + ret = regmap_update_bits(ltc3220->regmap,
> LTC3220_GRAD_BLINK_REG,
> > + LTC3220_BLINK_MASK,
> FIELD_PREP(LTC3220_BLINK_MASK, blink_mode));
> > + if (ret)
> > + return ret;
> > +
> > + return regmap_update_bits(ltc3220->regmap,
> LTC3220_ULED_REG(uled_cfg->led_index),
> > + LTC3220_LED_MODE_MASK,
> > + FIELD_PREP(LTC3220_LED_MODE_MASK,
> LTC3220_BLINK_MODE)); }
>
> [Severity: Medium]
> Will the hardware blink activate at 0 brightness if the LED was previously off?
>
> When the LED is off, its current bits in LTC3220_ULED_REG are 0. The driver
> updates the mode bits to LTC3220_BLINK_MODE using regmap_update_bits() but
> does not update the brightness bits.
>
> Because the core expects the driver to handle brightness configuration for
> hardware blinking, could this hardware blink execute at 0 brightness, leaving the
> LED unlit?
>
Will make sure to have brightness when setting blinking
>
> > +
> > +static void ltc3220_reset_gpio_action(void *data) {
> > + struct gpio_desc *reset_gpio = data;
> > +
> > + gpiod_set_value_cansleep(reset_gpio, 1); }
> > +
> > +static int ltc3220_reset(struct ltc3220 *ltc3220, struct i2c_client
> > +*client) {
> > + struct gpio_desc *reset_gpio;
> > + int ret;
> > +
> > + reset_gpio = devm_gpiod_get_optional(&client->dev, "reset",
> GPIOD_OUT_HIGH);
> > + if (IS_ERR(reset_gpio))
> > + return dev_err_probe(&client->dev, PTR_ERR(reset_gpio),
> "Failed on
> > +reset GPIO\n");
> > +
> > + if (reset_gpio) {
> > + gpiod_set_value_cansleep(reset_gpio, 0);
>
> [Severity: High]
> Does this sequence lack the necessary delays to ensure a successful reset?
>
> The driver asserts the reset GPIO by requesting it with GPIOD_OUT_HIGH and
> immediately de-asserts it with gpiod_set_value_cansleep(reset_gpio, 0). There is
> no delay between these calls, creating a near-zero width pulse that may fail to
> meet the IC's minimum reset pulse width requirement.
>
> It also lacks a wakeup delay before subsequent I2C commands might be sent.
>
Will add delays
>
> > +
> > + return devm_add_action_or_reset(&client->dev,
> ltc3220_reset_gpio_action,
> > + reset_gpio);
>
> [Severity: High]
> Does returning early here skip software initialization and regmap cache setup?
>
> If the reset_gpio is successfully acquired, this function immediately returns 0,
> entirely skipping the subsequent regmap_write() calls intended to initialize the
> hardware registers.
>
> Because the driver does not define a .reg_defaults table, skipping these writes
> leaves the regmap cache uninitialized, which can break subsequent read-modify-
> write logic via regmap_update_bits().
>
>
> > + }
> > +
> > + ret = regmap_write(ltc3220->regmap, LTC3220_COMMAND_REG, 0);
> > + if (ret)
> > + return ret;
> > +
> > + for (int i = 0; i < LTC3220_NUM_LEDS; i++) {
> > + ret = regmap_write(ltc3220->regmap, LTC3220_ULED_REG(i), 0);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return regmap_write(ltc3220->regmap, LTC3220_GRAD_BLINK_REG, 0); }
> > +
> > +static int ltc3220_suspend(struct device *dev) {
> > + struct ltc3220 *ltc3220 = i2c_get_clientdata(to_i2c_client(dev));
> > +
> > + return regmap_update_bits(ltc3220->regmap,
> LTC3220_COMMAND_REG,
> > + LTC3220_SHUTDOWN_MASK,
> LTC3220_SHUTDOWN_MASK); }
> > +
> > +static int ltc3220_resume(struct device *dev) {
> > + struct ltc3220 *ltc3220 = i2c_get_clientdata(to_i2c_client(dev));
> > +
> > + return regmap_update_bits(ltc3220->regmap,
> LTC3220_COMMAND_REG,
> > + LTC3220_SHUTDOWN_MASK, 0);
> > +}
>
> [Severity: High]
> Are the hardware registers left permanently off after resume?
>
> In ltc3220_suspend(), the driver sets the LTC3220_SHUTDOWN_MASK bit. On
> many such chips, asserting the shutdown bit resets internal registers. Additionally,
> power to the IC may be lost during system suspend.
>
> In ltc3220_resume(), the driver clears the shutdown bit but does not call
> regcache_mark_dirty() and regcache_sync(). Could this leave the physical LED
> outputs permanently off, while the kernel's regmap cache and LED classdev state
> incorrectly reflect that the LEDs are still configured and illuminated?
>
Will add regcache_sync() call to ltc3220_resume()
> > +
> > +static DEFINE_SIMPLE_DEV_PM_OPS(ltc3220_pm_ops, ltc3220_suspend,
> > +ltc3220_resume);
> > +
> > +static int ltc3220_probe(struct i2c_client *client) {
> > + struct ltc3220 *ltc3220;
> > + bool aggregated_led_found = false;
> > + int num_leds = 0;
> > + u8 led_index = 0;
> > + int ret;
> > +
> > + ltc3220 = devm_kzalloc(&client->dev, sizeof(*ltc3220), GFP_KERNEL);
> > + if (!ltc3220)
> > + return -ENOMEM;
> > +
> > + ltc3220->regmap = devm_regmap_init_i2c(client,
> <c3220_regmap_config);
> > + if (IS_ERR(ltc3220->regmap))
> > + return dev_err_probe(&client->dev, PTR_ERR(ltc3220->regmap),
> > + "Failed to initialize regmap\n");
> > +
> > + i2c_set_clientdata(client, ltc3220);
> > +
> > + ret = ltc3220_reset(ltc3220, client);
> > + if (ret)
> > + return dev_err_probe(&client->dev, ret, "Failed to reset
> > +device\n");
> > +
> > + device_for_each_child_node_scoped(&client->dev, child) {
> > + struct led_init_data init_data = {};
> > + struct ltc3220_uled_cfg *led;
> > + u32 source;
> > +
> > + ret = fwnode_property_read_u32(child, "reg", &source);
> > + if (ret)
> > + return dev_err_probe(&client->dev, ret, "Couldn't read
> LED
> > +address\n");
> > +
> > + if (!source || source > LTC3220_NUM_LEDS)
> > + return dev_err_probe(&client->dev, -EINVAL, "LED
> address out of
> > +range\n");
> > +
> > + init_data.fwnode = child;
> > + init_data.devicename = "ltc3220";
> > +
> > + if (fwnode_property_present(child, "led-sources")) {
> > + if (source != 1)
> > + return dev_err_probe(&client->dev, -EINVAL,
> > + "Aggregated LED out of
> range\n");
> > +
> > + if (aggregated_led_found)
> > + return dev_err_probe(&client->dev, -EINVAL,
> > + "One Aggregated LED
> only\n");
> > +
> > + aggregated_led_found = true;
> > + ltc3220->is_aggregated = true;
> > +
> > + ret = regmap_update_bits(ltc3220->regmap,
> > + LTC3220_COMMAND_REG,
> > +
> LTC3220_QUICK_WRITE_MASK,
> > +
> LTC3220_QUICK_WRITE_MASK);
> > + if (ret)
> > + return dev_err_probe(&client->dev, ret,
> > + "Failed to set quick write
> mode\n");
> > + }
> > +
> > + num_leds++;
> > +
> > + /* LED node reg/index/address goes from 1 to 18 */
> > + led_index = source - 1;
> > + led = <c3220->uled_cfg[led_index];
> > +
> > + if (led->led_cdev.dev)
> > + return dev_err_probe(&client->dev, -EINVAL,
> > + "Duplicate LED reg %u found",
> source);
> > +
> > + led->led_index = led_index;
> > + led->reg_value = 0;
> > + led->led_cdev.brightness_set_blocking = ltc3220_set_led_data;
> > + led->led_cdev.brightness_get = ltc3220_get_led_data;
> > + led->led_cdev.max_brightness = 63;
> > + led->led_cdev.blink_set = ltc3220_blink_set;
> > + led->led_cdev.pattern_set = ltc3220_pattern_set;
> > + led->led_cdev.pattern_clear = ltc3220_pattern_clear;
> > +
> > + ret = devm_led_classdev_register_ext(&client->dev, &led-
> >led_cdev, &init_data);
> > + if (ret)
> > + return dev_err_probe(&client->dev, ret, "Failed to
> register LED class\n");
> > + }
> > +
> > + /*
> > + * Aggregated LED mode uses hardware quick-write to control all 18 LEDs
> > + * simultaneously. This is mutually exclusive with individual LED control.
> > + * See Documentation/devicetree/bindings/leds/adi,ltc3220.yaml for
> details
> > + * on how to configure aggregated LED mode.
> > + */
> > + if (aggregated_led_found && num_leds > 1)
> > + return dev_err_probe(&client->dev, -EINVAL,
> > + "Aggregated LED must be the only LED
> node\n");
>
> [Severity: Medium]
> Are the LED sysfs interfaces exposed to userspace before the driver probe is fully
> validated?
>
> Inside the loop above, devm_led_classdev_register_ext() is called, which
> immediately exposes sysfs interfaces. If the validation check here fails and
> returns an error, userspace could have already discovered and interacted with the
> LED devices before they are unexpectedly torn down by devres.
>
> Could these validation checks be completed before registering the interfaces?
>
Restructured ltc3220_probe() to use two passes:
- First pass: Validate all device tree configuration and set up LED structures
- Second pass: Register LED class devices only after validation succeeds
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id ltc3220_of_match[] = {
> > + { .compatible = "adi,ltc3220" },
> > + { }
> > +};
> > +MODULE_DEVICE_TABLE(of, ltc3220_of_match);
> > +
> > +static struct i2c_driver ltc3220_led_driver = {
> > + .driver = {
> > + .name = "ltc3220",
> > + .of_match_table = ltc3220_of_match,
> > + .pm = pm_sleep_ptr(<c3220_pm_ops),
> > + },
> > + .probe = ltc3220_probe,
> > +};
> > +module_i2c_driver(ltc3220_led_driver);
> > +
> > +MODULE_AUTHOR("Edelweise Escala <edelweise.escala@analog.com>");
> > +MODULE_DESCRIPTION("LED driver for LTC3220 controllers");
> > +MODULE_LICENSE("GPL");
> >
> > --
> > 2.43.0
> >
>
> --
> Lee Jones
Thank you!
Best Regards,
Edelweise Escala
^ permalink raw reply
* Re: [PATCH v3] riscv: dts: spacemit: Use symbolic PDMA request numbers on K1
From: Yixun Lan @ 2026-06-15 1:15 UTC (permalink / raw)
To: Guodong Xu
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, linux-kernel, dmaengine, devicetree, linux-riscv,
spacemit
In-Reply-To: <20260611-b4-k1-pdma-req-macros-v3-1-ae8416052571@gmail.com>
Hi Guodong,
The patch itself looks good to me, only few minor comments
On 09:17 Thu 11 Jun , Guodong Xu wrote:
> Add a local DTS header, k1-pdma.h, that gives symbolic names to the K1
> PDMA request numbers. These request numbers are hardware-fixed; their
> allocation can be found in K1 manual.
>
..
> Replace the hard-coded numbers in the SPI3 "dmas" property with the
> K1_PDMA_SPI3_RX/TX macros.
>
As it's too obvious that people can tell from the diff, then I feel it's
unnecessary to repeat in commit message..
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
> ---
> Add a local DTS header naming the K1 PDMA request lines and convert the
> current user (the K1 SPI3 node) to the new K1_PDMA_* macros.
..
> The request
> numbers come from the SpacemiT K1 User Manual [1], Chapter 9.4.3 DMA
> Connectivity & Assignments.
>
I'd suggest to put above into commit message, as more detailed description.
Here is my attempt to slightly reconstruct the commit message:
The PDMA request numbers (DRQ) are fixed values specific to the SoC from a
hardware perspective. The detailed definition can be found in K1 User Manual,
Chapter 9.4.3 DMA Connectivity & Assignments. Add a DTS header file to define
the symbolic names for the DRQs of non-secure DMA peripherals.
> [1]: https://www.spacemit.com/community/document/info?lang=en&nodepath=hardware/key_stone/k1/k1_docs/k1_usermanual/9.Top_System.md
>
> Changes in v3:
> - Move the request-number macros from include/dt-bindings/dma/ to a local
> DTS header arch/riscv/boot/dts/spacemit/k1-pdma.h (Conor).
> - Squash the header and its user into a single patch.
> - Link to v2: https://patch.msgid.link/20260609-b4-k1-pdma-req-macros-v2-0-5d5d7b997b54@gmail.com
>
> Changes in v2:
> - Drop the #dma-cells description change in spacemit,k1-pdma.yaml; the request
> numbers are hardware-fixed and unused by the driver (Conor)
> - Link to v1: https://patch.msgid.link/20260607-b4-k1-pdma-req-macros-v1-0-5b2a3955007c@gmail.com
>
> BR,
> Guodong Xu
> ---
> arch/riscv/boot/dts/spacemit/k1-pdma.h | 56 ++++++++++++++++++++++++++++++++++
> arch/riscv/boot/dts/spacemit/k1.dtsi | 4 ++-
> 2 files changed, 59 insertions(+), 1 deletion(-)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k1-pdma.h b/arch/riscv/boot/dts/spacemit/k1-pdma.h
> new file mode 100644
> index 0000000000000..65112d5847add
> --- /dev/null
> +++ b/arch/riscv/boot/dts/spacemit/k1-pdma.h
> @@ -0,0 +1,56 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * This header provides DMA request number for non-secure peripherals of
> + * SpacemiT K1 PDMA.
slightly less redundant,
DMA request number (DRQ) defintion for non-secure peripherals
> + *
> + * Copyright (c) 2026 Guodong Xu <docular.xu@gmail.com>
> + */
> +
> +#ifndef _DTS_SPACEMIT_K1_PDMA_H
> +#define _DTS_SPACEMIT_K1_PDMA_H
> +
> +#define K1_PDMA_UART0_TX 3
> +#define K1_PDMA_UART0_RX 4
> +#define K1_PDMA_UART2_TX 5
> +#define K1_PDMA_UART2_RX 6
> +#define K1_PDMA_UART3_TX 7
> +#define K1_PDMA_UART3_RX 8
> +#define K1_PDMA_UART4_TX 9
> +#define K1_PDMA_UART4_RX 10
> +#define K1_PDMA_I2C0_TX 11
> +#define K1_PDMA_I2C0_RX 12
> +#define K1_PDMA_I2C1_TX 13
> +#define K1_PDMA_I2C1_RX 14
> +#define K1_PDMA_I2C2_TX 15
> +#define K1_PDMA_I2C2_RX 16
> +#define K1_PDMA_I2C4_TX 17
> +#define K1_PDMA_I2C4_RX 18
> +#define K1_PDMA_SPI3_TX 19
> +#define K1_PDMA_SPI3_RX 20
> +#define K1_PDMA_I2S0_TX 21
> +#define K1_PDMA_I2S0_RX 22
> +#define K1_PDMA_I2S1_TX 23
> +#define K1_PDMA_I2S1_RX 24
> +#define K1_PDMA_UART5_TX 25
> +#define K1_PDMA_UART5_RX 26
> +#define K1_PDMA_UART6_TX 27
> +#define K1_PDMA_UART6_RX 28
> +#define K1_PDMA_UART7_TX 29
> +#define K1_PDMA_UART7_RX 30
> +#define K1_PDMA_UART8_TX 31
> +#define K1_PDMA_UART8_RX 32
> +#define K1_PDMA_UART9_TX 33
> +#define K1_PDMA_UART9_RX 34
> +#define K1_PDMA_I2C5_TX 35
> +#define K1_PDMA_I2C5_RX 36
> +#define K1_PDMA_I2C6_TX 37
> +#define K1_PDMA_I2C6_RX 38
> +#define K1_PDMA_I2C7_TX 39
> +#define K1_PDMA_I2C7_RX 40
> +#define K1_PDMA_I2C8_TX 41
> +#define K1_PDMA_I2C8_RX 42
> +#define K1_PDMA_CAN0_RX 43
> +#define K1_PDMA_QSPI_RX 44
> +#define K1_PDMA_QSPI_TX 45
> +
> +#endif /* _DTS_SPACEMIT_K1_PDMA_H */
> diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
> index 08a0f28d011fe..7d414e15d2cc2 100644
> --- a/arch/riscv/boot/dts/spacemit/k1.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
> @@ -6,6 +6,8 @@
> #include <dt-bindings/clock/spacemit,k1-syscon.h>
> #include <dt-bindings/phy/phy.h>
>
> +#include "k1-pdma.h"
> +
> /dts-v1/;
> / {
> #address-cells = <2>;
> @@ -1094,7 +1096,7 @@ spi3: spi@d401c000 {
> clock-names = "core", "bus";
> resets = <&syscon_apbc RESET_SSP3>;
> interrupts = <55>;
> - dmas = <&pdma 20>, <&pdma 19>;
> + dmas = <&pdma K1_PDMA_SPI3_RX>, <&pdma K1_PDMA_SPI3_TX>;
> dma-names = "rx", "tx";
> status = "disabled";
> };
>
> ---
> base-commit: 793cc54475b49b5b558902b5c13e4bfe66530a50
> change-id: 20260607-b4-k1-pdma-req-macros-8d276d0126df
>
> Best regards,
> --
> Guodong Xu <docular.xu@gmail.com>
>
--
Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: spi: nuvoton,ma35d1-qspi: Add Nuvoton MA35D1 QSPI
From: Chi-Wen Weng @ 2026-06-15 1:18 UTC (permalink / raw)
To: Conor Dooley
Cc: broonie, robh, krzk+dt, conor+dt, linux-arm-kernel, linux-spi,
devicetree, linux-kernel, cwweng
In-Reply-To: <20260612-diagram-florist-01a0e8f923d8@spud>
Hi Conor,
Thanks for the clarification.
I will make the driver read num-cs in v4 and fall back to the hardware
default of 2 when the property is not present. I will also keep the
binding default in sync with that behavior.
Best regards,
Chi-Wen
Conor Dooley 於 2026/6/12 下午 11:48 寫道:
> On Fri, Jun 12, 2026 at 08:33:01AM +0800, Chi-Wen Weng wrote:
>> Hi Conor,
>>
>> Thanks for the review.
>>
>> I will add a default value for num-cs in v4:
>>
>> num-cs:
>> maximum: 2
>> default: 2
>>
>> The controller has two native chip selects and the driver currently uses
>> that hardware default.
> The driver should handle the property and fall back to the default.
> It's not complex to support, so surely there's no reason not to?
>
> Cheers,
> Conor.
>
>> Best regards,
>> Chi-Wen
>>
>> Conor Dooley 於 2026/6/12 上午 01:34 寫道:
>>> On Thu, Jun 11, 2026 at 05:12:45PM +0800, Chi-Wen Weng wrote:
>>>> From: Chi-Wen Weng <cwweng@nuvoton.com>
>>>>
>>>> Add a devicetree binding for the Quad SPI controller found in
>>>> Nuvoton MA35D1 SoCs.
>>>>
>>>> The controller supports SPI memory devices such as SPI NOR and SPI NAND
>>>> flashes. It has one register range, one clock input and one reset line,
>>>> and supports up to two chip selects.
>>>>
>>>> Signed-off-by: Chi-Wen Weng <cwweng@nuvoton.com>
>>>> ---
>>>> .../bindings/spi/nuvoton,ma35d1-qspi.yaml | 62 +++++++++++++++++++
>>>> 1 file changed, 62 insertions(+)
>>>> create mode 100644 Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>>>> new file mode 100644
>>>> index 000000000000..d3b36e612eb0
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/spi/nuvoton,ma35d1-qspi.yaml
>>>> @@ -0,0 +1,62 @@
>>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>>> +%YAML 1.2
>>>> +---
>>>> +$id: http://devicetree.org/schemas/spi/nuvoton,ma35d1-qspi.yaml#
>>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>>> +
>>>> +title: Nuvoton MA35D1 Quad SPI Controller
>>>> +
>>>> +maintainers:
>>>> + - Chi-Wen Weng <cwweng@nuvoton.com>
>>>> +
>>>> +allOf:
>>>> + - $ref: /schemas/spi/spi-controller.yaml#
>>>> +
>>>> +properties:
>>>> + compatible:
>>>> + const: nuvoton,ma35d1-qspi
>>>> +
>>>> + reg:
>>>> + maxItems: 1
>>>> +
>>>> + interrupts:
>>>> + maxItems: 1
>>>> +
>>>> + clocks:
>>>> + maxItems: 1
>>>> +
>>>> + resets:
>>>> + maxItems: 1
>>>> +
>>>> + num-cs:
>>>> + maximum: 2
>>> Missing a default of 2, unless you make the property required.
>>> FWIW, your driver doesn't appear to read this value.
>>>
>>> pw-bot: changes-requested
>>>
>>> Cheers,
>>> Conor.
>>>
>>>> +
>>>> +required:
>>>> + - compatible
>>>> + - reg
>>>> + - clocks
>>>> + - resets
>>>> +
>>>> +unevaluatedProperties: false
>>>> +
>>>> +examples:
>>>> + - |
>>>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>> + #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
>>>> + #include <dt-bindings/reset/nuvoton,ma35d1-reset.h>
>>>> +
>>>> + soc {
>>>> + #address-cells = <2>;
>>>> + #size-cells = <2>;
>>>> +
>>>> + spi@40680000 {
>>>> + compatible = "nuvoton,ma35d1-qspi";
>>>> + reg = <0 0x40680000 0 0x100>;
>>>> + interrupts = <GIC_SPI 57 IRQ_TYPE_LEVEL_HIGH>;
>>>> + clocks = <&clk QSPI0_GATE>;
>>>> + resets = <&sys MA35D1_RESET_QSPI0>;
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + };
>>>> + };
>>>> +
>>>> --
>>>> 2.25.1
>>>>
^ permalink raw reply
* Re: [PATCH v4 10/16] riscv: dts: spacemit: k3: Add Zic64b ISA extension
From: Yixun Lan @ 2026-06-15 1:20 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen Wang, Inochi Amaoto, linux-doc, linux-riscv, linux-kernel,
kvm, kvm-riscv, Paul Walmsley, Conor Dooley, devicetree, spacemit,
sophgo, linux-kselftest, Palmer Dabbelt
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-10-3f01a2449488@gmail.com>
Hi Guodong,
On 16:12 Thu 11 Jun , Guodong Xu wrote:
> The K3 X100 cores have 64-byte cache blocks, already described by their
> cbom/cbop/cboz-block-size of 64, so they implement Zic64b, a mandatory
> RVA23 extension. Declare it in each core's riscv,isa-extensions.
>
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Reviewed-by: Yixun Lan <dlan@kernel.org>
> ---
> v4: No change.
> v3: New patch.
> ---
> arch/riscv/boot/dts/spacemit/k3.dtsi | 48 ++++++++++++++++++------------------
> 1 file changed, 24 insertions(+), 24 deletions(-)
>
> diff --git a/arch/riscv/boot/dts/spacemit/k3.dtsi b/arch/riscv/boot/dts/spacemit/k3.dtsi
> index 4ac457399b583..b5aa983f0bfa1 100644
> --- a/arch/riscv/boot/dts/spacemit/k3.dtsi
> +++ b/arch/riscv/boot/dts/spacemit/k3.dtsi
> @@ -35,9 +35,9 @@ cpu_0: cpu@0 {
> "svinval", "svnapot", "svpbmt", "za64rs",
> "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> - "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> - "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
> - "zicond", "zicsr", "zifencei", "zihintntl",
> + "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
> + "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
> + "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
> "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> @@ -76,9 +76,9 @@ cpu_1: cpu@1 {
> "svinval", "svnapot", "svpbmt", "za64rs",
> "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> - "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> - "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
> - "zicond", "zicsr", "zifencei", "zihintntl",
> + "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
> + "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
> + "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
> "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> @@ -117,9 +117,9 @@ cpu_2: cpu@2 {
> "svinval", "svnapot", "svpbmt", "za64rs",
> "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> - "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> - "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
> - "zicond", "zicsr", "zifencei", "zihintntl",
> + "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
> + "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
> + "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
> "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> @@ -158,9 +158,9 @@ cpu_3: cpu@3 {
> "svinval", "svnapot", "svpbmt", "za64rs",
> "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> - "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> - "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
> - "zicond", "zicsr", "zifencei", "zihintntl",
> + "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
> + "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
> + "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
> "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> @@ -199,9 +199,9 @@ cpu_4: cpu@4 {
> "svinval", "svnapot", "svpbmt", "za64rs",
> "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> - "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> - "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
> - "zicond", "zicsr", "zifencei", "zihintntl",
> + "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
> + "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
> + "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
> "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> @@ -240,9 +240,9 @@ cpu_5: cpu@5 {
> "svinval", "svnapot", "svpbmt", "za64rs",
> "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> - "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> - "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
> - "zicond", "zicsr", "zifencei", "zihintntl",
> + "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
> + "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
> + "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
> "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> @@ -281,9 +281,9 @@ cpu_6: cpu@6 {
> "svinval", "svnapot", "svpbmt", "za64rs",
> "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> - "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> - "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
> - "zicond", "zicsr", "zifencei", "zihintntl",
> + "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
> + "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
> + "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
> "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
> @@ -322,9 +322,9 @@ cpu_7: cpu@7 {
> "svinval", "svnapot", "svpbmt", "za64rs",
> "zawrs", "zba", "zbb", "zbc", "zbs", "zca",
> "zcb", "zcd", "zcmop", "zfa", "zfbfmin",
> - "zfh", "zfhmin", "zicbom", "zicbop", "zicboz",
> - "ziccamoa", "ziccif", "zicclsm", "ziccrse", "zicntr",
> - "zicond", "zicsr", "zifencei", "zihintntl",
> + "zfh", "zfhmin", "zic64b", "zicbom", "zicbop",
> + "zicboz", "ziccamoa", "ziccif", "zicclsm", "ziccrse",
> + "zicntr", "zicond", "zicsr", "zifencei", "zihintntl",
> "zihintpause", "zihpm", "zimop", "zkt", "zvbb",
> "zvbc", "zvfbfmin", "zvfbfwma", "zvfh",
> "zvfhmin", "zvkb", "zvkg", "zvkn", "zvknc",
>
> --
> 2.43.0
>
--
Yixun Lan (dlan)
^ permalink raw reply
* Re: [PATCH v6 2/2] i2c: ls2x: Add clocks property parsing and adjust bus speed
From: Hongliang Wang @ 2026-06-15 1:27 UTC (permalink / raw)
To: Andi Shyti
Cc: Binbin Zhou, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Wolfram Sang, linux-i2c, devicetree, loongarch, Huacai Chen,
stable
In-Reply-To: <ai8o9vxUX6rbZNV4@zenone.zhora.eu>
Hi, Andi
On 2026/6/15 上午6:20, Andi Shyti wrote:
> Hi Hongliang,
>
> On Mon, Jun 08, 2026 at 10:45:33AM +0800, Hongliang Wang wrote:
>> The i2c-ls2x driver supports dts and acpi parameter passing.
>>
>> In dts, uses clock framework, by parsing clocks property to
>> get i2c bus reference clock, and define the div of reference
>> clock by device data.
>>
>> In acpi, by passing clocks property to describe i2c bus reference
>> clock and clock-div property to describe the div of reference clock.
>>
>> Based on i2c bus reference clock(clock_a), i2c bus speed(clock_s)
>> and div, calculate the prcescale of i2c divider register. The
>> calculation formula is
>>
>> prcescale = (clock_a*10)/(div*clock_s)-1
>>
>> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
> I think Huacai has not reviewed this patch, his review was only
> for patch 1. Am I right?
>
> Andi
Sorry, it was my mistake, I will send a new version later.
Best regards,
Hongliang Wang
^ permalink raw reply
* Re: [PATCH V12 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Chris Morgan @ 2026-06-15 2:12 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <20260614171847.3c412ca3@jic23-huawei>
On Sun, Jun 14, 2026 at 05:18:47PM +0100, Jonathan Cameron wrote:
> On Thu, 11 Jun 2026 15:26:00 -0500
> Chris Morgan <macroalpha82@gmail.com> wrote:
>
> > From: Chris Morgan <macromorgan@hotmail.com>
> >
> > Add the core component of a new inv_icm42607 driver. This includes
> > a few setup functions and the full register definition in the
> > header file, as well as the bits necessary to compile and probe the
> > device when used on an i2c bus.
> >
> > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> Hi Chris,
>
> Given this is nearly ready to merge I took a look at Sashiko and
> seems it has found a few more things.
>
> Other than those, looks good to me.
>
> Jonathan
Thanks. I'm going to resubmit again probably tomorrow (even though
it's merge window, again unless you don't want it).
I've removed the buffer from the main st struct, since it's really
no longer needed given the lack of buffer support. Additionally
I've removed the registers completely that sashiko was complaining
about, since it only applies to the 42607c and isn't used by this
driver right now anyway (only needed for APEX/WoM). I also altered
the power management logic a bit to prevent it from delaying on
shutdown, except for when the gyro changes state which the datasheet
says is needed. If Sashiko continues to complain about power management
for the temp sensor that can be ignored, as I've confirmed so long as
both the gyro and accel are off the whole chip is "off". Along with
making a change from 42607x to just 42607 in a few places those are
the only major changes.
Chris
>
> > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > new file mode 100644
> > index 000000000000..c85d3b74166f
> > --- /dev/null
> > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
>
> > +#define INV_ICM42607_REG_INTF_CONFIG0 0x35
> > +#define INV_ICM42607_INTF_CONFIG0_FIFO_COUNT_FORMAT BIT(6)
> > +#define INV_ICM42607_INTF_CONFIG0_FIFO_COUNT_ENDIAN BIT(5)
> > +#define INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN BIT(4)
> > +#define INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK GENMASK(1, 0)
> > +#define INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_SPI_DIS \
> > + FIELD_PREP(INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK, 2)
> Define this as simply 2.
>
> > +#define INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_I2C_DIS \
> > + FIELD_PREP(INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK, 3)
> and 3
> not the FIELD_PREPified version
>
> Sashiko correctly called out that it is field_prepped again at
> the callsite. As the mask includes lowest bit this is will 'work'
> but definitely isn't what you intended!
>
>
> > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > new file mode 100644
> > index 000000000000..5d40f1ee53d6
> > --- /dev/null
> > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
>
> > +static bool inv_icm42607_is_readable_reg(struct device *dev, unsigned int reg)
> > +{
> > + switch (reg) {
> > + case INV_ICM42607_REG_MCLK_RDY ... INV_ICM42607_REG_INT_CONFIG:
> > + case INV_ICM42607_REG_TEMP_DATA1 ... INV_ICM42607_REG_TMST_FSYNCL:
> > + case INV_ICM42607_REG_APEX_DATA4 ... INV_ICM42607_REG_INTF_CONFIG1:
> > + case INV_ICM42607_REG_INT_STATUS_DRDY ... INV_ICM42607_REG_FIFO_DATA:
> Sashiko pointed out that the WOM_ registers, 4b to 4d are in the defines, but
> not readable or writeable which seems like an omission.
>
> So far only matters for debug, but perhaps better to add them from the start.
>
> > + case INV_ICM42607_REG_WHOAMI:
> > + return true;
> > + }
> > +
> > + return false;
> > +}
> > +
> > +static bool inv_icm42607_is_writeable_reg(struct device *dev, unsigned int reg)
> > +{
> > + switch (reg) {
> > + case INV_ICM42607_REG_DEVICE_CONFIG ... INV_ICM42607_REG_INT_CONFIG:
> > + case INV_ICM42607_REG_PWR_MGMT0 ... INV_ICM42607_REG_INT_SOURCE4:
> > + case INV_ICM42607_REG_INTF_CONFIG0 ... INV_ICM42607_REG_INTF_CONFIG1:
> > + return true;
> > + }
> > +
> > + return false;
> > +}
^ permalink raw reply
* Re: [PATCH v6 2/2] i2c: ls2x: Add clocks property parsing and adjust bus speed
From: Huacai Chen @ 2026-06-15 2:28 UTC (permalink / raw)
To: Hongliang Wang
Cc: Andi Shyti, Binbin Zhou, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Wolfram Sang, linux-i2c, devicetree, loongarch,
Huacai Chen, stable
In-Reply-To: <338facef-6893-c8d9-0efc-b4fc3aea756b@loongson.cn>
On Mon, Jun 15, 2026 at 9:29 AM Hongliang Wang
<wanghongliang@loongson.cn> wrote:
>
> Hi, Andi
>
> On 2026/6/15 上午6:20, Andi Shyti wrote:
> > Hi Hongliang,
> >
> > On Mon, Jun 08, 2026 at 10:45:33AM +0800, Hongliang Wang wrote:
> >> The i2c-ls2x driver supports dts and acpi parameter passing.
> >>
> >> In dts, uses clock framework, by parsing clocks property to
> >> get i2c bus reference clock, and define the div of reference
> >> clock by device data.
> >>
> >> In acpi, by passing clocks property to describe i2c bus reference
> >> clock and clock-div property to describe the div of reference clock.
> >>
> >> Based on i2c bus reference clock(clock_a), i2c bus speed(clock_s)
> >> and div, calculate the prcescale of i2c divider register. The
> >> calculation formula is
> >>
> >> prcescale = (clock_a*10)/(div*clock_s)-1
> >>
> >> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
> > I think Huacai has not reviewed this patch, his review was only
> > for patch 1. Am I right?
> >
> > Andi
> Sorry, it was my mistake, I will send a new version later.
Why? I really gave some suggestions in previous versions and you accepted.
If an explicitly R-b is needed for each one, then
Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
Huacai
>
> Best regards,
> Hongliang Wang
>
>
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: qcom: Add the tlmm driver for Maili platform
From: Jingyi Wang @ 2026-06-15 2:34 UTC (permalink / raw)
To: Sneh Mankad, Bjorn Andersson, Linus Walleij, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: aiqun.yu, tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
linux-gpio, devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <feea89d3-3f71-4ad3-b5ac-35ac57f2fefa@oss.qualcomm.com>
On 6/10/2026 4:08 PM, Sneh Mankad wrote:
>
>
> On 22-May-26 1:12 PM, Jingyi Wang wrote:
>> Add support for Maili TLMM configuration and control via the pinctrl
>> framework.
>>
>> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
>> ---
>> drivers/pinctrl/qcom/Kconfig.msm | 10 +
>> drivers/pinctrl/qcom/Makefile | 1 +
>> drivers/pinctrl/qcom/pinctrl-maili.c | 1630 ++++++++++++++++++++++++++++++++++
>> 3 files changed, 1641 insertions(+)
>>
<...>
>
> Can you please move "MODULE_DEVICE_TABLE(of, maili_tlmm_of_match);" to immediately follow
> the maili_tlmm_of_match[] array definition, grouping the array definition with its associated alias declaration?
> Please refer [1].
>
> [1] https://lore.kernel.org/linux-arm-msm/20260505093444.61336-2-krzysztof.kozlowski@oss.qualcomm.com/
>
> Thanks,
> Sneh
Will update.
Thanks,
Jingyi
^ permalink raw reply
* [PATCH v8 0/2] Add Meta(Facebook) ventura2 BMC(AST2600)
From: Kyle Hsieh @ 2026-06-15 2:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Kyle Hsieh, Krzysztof Kozlowski
Summary:
Add linux device tree entry related to Meta(Facebook) ventura2.
specific devices connected to BMC(AST2600) SoC.
Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
---
Changes in v8:
- Addressed review comments from Andrew Lunn:
* Added a detailed comment to the Marvell 88E6393X EEPROM node to clarify its hardware I2C multiplexer isolation and out-of-band firmware update mechanism, explaining why there is no concurrent access or multi-master scenario.
- Link to v7: https://lore.kernel.org/r/20260611-ventura2_initial_dts-v7-0-a61d8902bc5f@gmail.com
Changes in v7:
- Updated the commit message to include a detailed description of the Ventura2 platform's purpose and its key hardware features.
- Fix comments from Andrew Jeffery:
* Ensured consistent blank lines to separate child nodes from parent properties and from each other throughout the DTS.
* Sorted fan nodes in ascending order.
* Replaced '//' comments with '/* */' block comments.
- Fix feedback from Sashiko AI:
* Added 'idle-state = <6>;' to the PCA9548 mux on i2c4.
- Link to v6: https://lore.kernel.org/r/20260610-ventura2_initial_dts-v6-0-375d8e9d7ebf@gmail.com
Changes in v6:
- Addressed automated feedback from Sashiko bot:
* Clarified comments that io_expander0 and io_expander8 physically share the same interrupt line (Wired-OR) by hardware design.
* Removed leading zeros from unit addresses in DAC nodes (dac@c, dac@e, dac@f).
* Removed unused properties from the adc@48 node.
- Link to v5: https://lore.kernel.org/r/20260608-ventura2_initial_dts-v5-0-37ee5bcf58b6@gmail.com
Changes in v5:
- Addressed review comments:
* Added comments explaining the necessity of 'legacy_' prefixes (hardware label collision), pre-allocated I2C aliases (future expansions), and the 'ledd1' naming convention (schematic alignment).
* Removed the empty `&mdio0` node to comply with upstream networking subsystem guidelines.
* Removed the redundant `&peci0` node.
* Sorted `&kcs3` and `&lpc_ctrl` nodes in strict alphabetical order.
- Hardware/DT alignment updates:
* Removed unpopulated sensors (adi,adt7461, infineon,tda38640, ti,ina230, ti,ina238) to accurately reflect the current board population.
* Added the secondary flash node (flash@1 labeled "e810") under the &spi2 bus.
- Link to v4: https://lore.kernel.org/r/20260424-ventura2_initial_dts-v4-0-806b00ea4314@gmail.com
Changes in v4:
- Fixed capitalization: "ventura2" -> "Ventura2".
- Reordered I2C child nodes in ascending order of unit addresses.
- Enable PECI, LPC control, and KCS3 interfaces for host communication.
- Configure MCTP controller on I2C4 and enable MCTP support for specific mux channels.
- Add Infineon TDA38640 and TI INA230 power monitor nodes.
- GPIO and Pinmux cleanup for PVT:
- Aligned gpio-line-names as requested.
- Remove unused or non-existent GPIO line names to align with Ventura2 PVT.
- Update specific GPIO pins to empty strings where signals were removed or consolidated.
- Adjust SGPIOM frequency to 200kHz and update signal line names.
- Enable UART3 and add serial2 alias.
- Link to v3: https://lore.kernel.org/r/20260113-ventura2_initial_dts-v3-0-2dbfda6a5b47@gmail.com
Changes in v3:
- Add annotation for marvel 88e6393x
- Modify the gpio-line-name
- Modify the node order alphabetically
- Modify dt-bindings document for rmc instead of bmc
- Move the gpio-line-names to original node
- Link to v2: https://lore.kernel.org/r/20251224-ventura2_initial_dts-v2-0-f193ba5d4073@gmail.com
Changes in v2:
- Remove unused mdio
- Link to v1: https://lore.kernel.org/r/20251222-ventura2_initial_dts-v1-0-1f06166c78a3@gmail.com
---
Kyle Hsieh (2):
dt-bindings: arm: aspeed: add Meta ventura2 board
ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
.../devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-facebook-ventura2.dts | 2903 ++++++++++++++++++++
3 files changed, 2905 insertions(+)
---
base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
change-id: 20251222-ventura2_initial_dts-909b3277d665
Best regards,
--
Kyle Hsieh <kylehsieh1995@gmail.com>
^ permalink raw reply
* [PATCH v8 1/2] dt-bindings: arm: aspeed: add Meta ventura2 board
From: Kyle Hsieh @ 2026-06-15 2:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Kyle Hsieh, Krzysztof Kozlowski
In-Reply-To: <20260615-ventura2_initial_dts-v8-0-c89f92c80447@gmail.com>
Document the new compatibles used on Facebook ventura2.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
---
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
index 9298c1a75dd1..d48607c86e8e 100644
--- a/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+++ b/Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
@@ -92,6 +92,7 @@ properties:
- facebook,harma-bmc
- facebook,minerva-cmc
- facebook,santabarbara-bmc
+ - facebook,ventura2-rmc
- facebook,yosemite4-bmc
- facebook,yosemite5-bmc
- ibm,balcones-bmc
--
2.34.1
^ permalink raw reply related
* [PATCH v8 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Kyle Hsieh @ 2026-06-15 2:46 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Kyle Hsieh
In-Reply-To: <20260615-ventura2_initial_dts-v8-0-c89f92c80447@gmail.com>
Ventura2 is a Rack Management Controller. It is a modular
device designed to manage liquid cooling systems and monitor hardware
states within an IT rack. The system uses an AST2600 BMC for management.
RMCv2 serves several critical roles:
- Detects liquid leakage at both tray and rack levels.
- Communicates with and controls liquid cooling equipment.
- Manages leakage events and executes system recovery protocols.
Key hardware features include:
- An extensive I2C and IO expander topology to support comprehensive
sensor monitoring and backward compatibility with legacy trays.
- MCTP over I2C support for asynchronous device communications.
- A dual-flash design for BMC firmware redundancy.
Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
---
arch/arm/boot/dts/aspeed/Makefile | 1 +
.../dts/aspeed/aspeed-bmc-facebook-ventura2.dts | 2903 ++++++++++++++++++++
2 files changed, 2904 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/Makefile b/arch/arm/boot/dts/aspeed/Makefile
index 9adf9278dc94..6b96997629d4 100644
--- a/arch/arm/boot/dts/aspeed/Makefile
+++ b/arch/arm/boot/dts/aspeed/Makefile
@@ -32,6 +32,7 @@ dtb-$(CONFIG_ARCH_ASPEED) += \
aspeed-bmc-facebook-minipack.dtb \
aspeed-bmc-facebook-santabarbara.dtb \
aspeed-bmc-facebook-tiogapass.dtb \
+ aspeed-bmc-facebook-ventura2.dtb \
aspeed-bmc-facebook-wedge40.dtb \
aspeed-bmc-facebook-wedge100.dtb \
aspeed-bmc-facebook-wedge400-data64.dtb \
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
new file mode 100644
index 000000000000..c64726bb0450
--- /dev/null
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-facebook-ventura2.dts
@@ -0,0 +1,2903 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (c) 2023 Facebook Inc.
+/dts-v1/;
+
+#include "aspeed-g6.dtsi"
+#include <dt-bindings/i2c/i2c.h>
+#include <dt-bindings/gpio/aspeed-gpio.h>
+
+/ {
+ model = "Facebook Ventura2 RMC";
+ compatible = "facebook,ventura2-rmc", "aspeed,ast2600";
+ aliases {
+ serial2 = &uart3;
+ serial4 = &uart5;
+
+ /*
+ * Pre-allocate I2C bus aliases for userspace predictability.
+ * Several I2C channels are intentionally left empty in this DTS
+ * as they are strictly reserved for future hardware feature expansions
+ * and add-on boards that will interface with these busses.
+ */
+ /*
+ * i2c switch 0-0077, pca9548, 8 child channels assigned
+ * with bus number 16-23.
+ */
+ i2c16 = &i2c0mux0ch0;
+ i2c17 = &i2c0mux0ch1;
+ i2c18 = &i2c0mux0ch2;
+ i2c19 = &i2c0mux0ch3;
+ i2c20 = &i2c0mux0ch4;
+ i2c21 = &i2c0mux0ch5;
+ i2c22 = &i2c0mux0ch6;
+ i2c23 = &i2c0mux0ch7;
+
+ /*
+ * i2c switch 1-0077, pca9548, 8 child channels assigned
+ * with bus number 24-31.
+ */
+ i2c24 = &i2c1mux0ch0;
+ i2c25 = &i2c1mux0ch1;
+ i2c26 = &i2c1mux0ch2;
+ i2c27 = &i2c1mux0ch3;
+ i2c28 = &i2c1mux0ch4;
+ i2c29 = &i2c1mux0ch5;
+ i2c30 = &i2c1mux0ch6;
+ i2c31 = &i2c1mux0ch7;
+
+ /*
+ * i2c switch 4-0077, pca9548, 8 child channels assigned
+ * with bus number 32-39.
+ */
+ i2c32 = &i2c4mux0ch0;
+ i2c33 = &i2c4mux0ch1;
+ i2c34 = &i2c4mux0ch2;
+ i2c35 = &i2c4mux0ch3;
+ i2c36 = &i2c4mux0ch4;
+ i2c37 = &i2c4mux0ch5;
+ i2c38 = &i2c4mux0ch6;
+ i2c39 = &i2c4mux0ch7;
+
+ /*
+ * i2c switch 5-0077, pca9548, 8 child channels assigned
+ * with bus number 40-47.
+ */
+ i2c40 = &i2c5mux0ch0;
+ i2c41 = &i2c5mux0ch1;
+ i2c42 = &i2c5mux0ch2;
+ i2c43 = &i2c5mux0ch3;
+ i2c44 = &i2c5mux0ch4;
+ i2c45 = &i2c5mux0ch5;
+ i2c46 = &i2c5mux0ch6;
+ i2c47 = &i2c5mux0ch7;
+
+ /*
+ * i2c switch 8-0077, pca9548, 8 child channels assigned
+ * with bus number 48-55.
+ */
+ i2c48 = &i2c8mux0ch0;
+ i2c49 = &i2c8mux0ch1;
+ i2c50 = &i2c8mux0ch2;
+ i2c51 = &i2c8mux0ch3;
+ i2c52 = &i2c8mux0ch4;
+ i2c53 = &i2c8mux0ch5;
+ i2c54 = &i2c8mux0ch6;
+ i2c55 = &i2c8mux0ch7;
+
+ /*
+ * i2c switch 11-0077, pca9548, 8 child channels assigned
+ * with bus number 56-63.
+ */
+ i2c56 = &i2c11mux0ch0;
+ i2c57 = &i2c11mux0ch1;
+ i2c58 = &i2c11mux0ch2;
+ i2c59 = &i2c11mux0ch3;
+ i2c60 = &i2c11mux0ch4;
+ i2c61 = &i2c11mux0ch5;
+ i2c62 = &i2c11mux0ch6;
+ i2c63 = &i2c11mux0ch7;
+
+ /*
+ * i2c switch 13-0077, pca9548, 8 child channels assigned
+ * with bus number 64-71.
+ */
+ i2c64 = &i2c13mux0ch0;
+ i2c65 = &i2c13mux0ch1;
+ i2c66 = &i2c13mux0ch2;
+ i2c67 = &i2c13mux0ch3;
+ i2c68 = &i2c13mux0ch4;
+ i2c69 = &i2c13mux0ch5;
+ i2c70 = &i2c13mux0ch6;
+ i2c71 = &i2c13mux0ch7;
+
+ /*
+ * i2c switch 15-0077, pca9548, 8 child channels assigned
+ * with bus number 72-79.
+ */
+ i2c72 = &i2c15mux0ch0;
+ i2c73 = &i2c15mux0ch1;
+ i2c74 = &i2c15mux0ch2;
+ i2c75 = &i2c15mux0ch3;
+ i2c76 = &i2c15mux0ch4;
+ i2c77 = &i2c15mux0ch5;
+ i2c78 = &i2c15mux0ch6;
+ i2c79 = &i2c15mux0ch7;
+ };
+
+ chosen {
+ stdout-path = "serial4:57600n8";
+ };
+
+ fan_leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ /* The 'ledd' intentionally matches the hardware schematic */
+ label = "fcb0fan0_ledd1_blue";
+ default-state = "off";
+ gpios = <&fan_io_expander0 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-1 {
+ label = "fcb0fan1_ledd2_blue";
+ default-state = "off";
+ gpios = <&fan_io_expander0 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-2 {
+ label = "fcb0fan2_ledd3_blue";
+ default-state = "off";
+ gpios = <&fan_io_expander1 0 GPIO_ACTIVE_LOW>;
+ };
+
+ led-3 {
+ label = "fcb0fan3_ledd4_blue";
+ default-state = "off";
+ gpios = <&fan_io_expander1 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led-4 {
+ label = "fcb0fan0_ledd1_amber";
+ default-state = "off";
+ gpios = <&fan_io_expander0 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-5 {
+ label = "fcb0fan1_ledd2_amber";
+ default-state = "off";
+ gpios = <&fan_io_expander0 5 GPIO_ACTIVE_LOW>;
+ };
+
+ led-6 {
+ label = "fcb0fan2_ledd3_amber";
+ default-state = "off";
+ gpios = <&fan_io_expander1 4 GPIO_ACTIVE_LOW>;
+ };
+
+ led-7 {
+ label = "fcb0fan3_ledd4_amber";
+ default-state = "off";
+ gpios = <&fan_io_expander1 5 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ iio-hwmon {
+ compatible = "iio-hwmon";
+ io-channels = <&adc0 0>, <&adc0 1>, <&adc0 2>, <&adc0 3>,
+ <&adc0 4>, <&adc0 5>, <&adc0 6>, <&adc0 7>,
+ <&adc1 2>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led-0 {
+ label = "bmc_heartbeat_amber";
+ gpios = <&gpio0 ASPEED_GPIO(P, 7) GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ led-1 {
+ label = "fp_id_amber";
+ default-state = "off";
+ gpios = <&gpio0 ASPEED_GPIO(B, 5) GPIO_ACTIVE_HIGH>;
+ };
+
+ led-2 {
+ label = "bmc_ready_noled";
+ default-state = "on";
+ gpios = <&gpio0 ASPEED_GPIO(B, 3) (GPIO_ACTIVE_HIGH|GPIO_TRANSITORY)>;
+ };
+
+ led-3 {
+ label = "power_blue";
+ default-state = "off";
+ gpios = <&gpio0 ASPEED_GPIO(P, 4) GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x80000000 0x80000000>;
+ };
+
+ p1v8_bmc_aux: regulator-p1v8-bmc-aux {
+ compatible = "regulator-fixed";
+ regulator-name = "p1v8_bmc_aux";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ p2v5_bmc_aux: regulator-p2v5-bmc-aux {
+ compatible = "regulator-fixed";
+ regulator-name = "p2v5_bmc_aux";
+ regulator-min-microvolt = <2500000>;
+ regulator-max-microvolt = <2500000>;
+ regulator-always-on;
+ };
+
+ p5v_dac_aux: regulator-p5v-bmc-aux {
+ compatible = "regulator-fixed";
+ regulator-name = "p5v_dac_aux";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ spi1_gpio: spi {
+ compatible = "spi-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sck-gpios = <&gpio0 ASPEED_GPIO(Z, 3) GPIO_ACTIVE_HIGH>;
+ mosi-gpios = <&gpio0 ASPEED_GPIO(Z, 4) GPIO_ACTIVE_HIGH>;
+ miso-gpios = <&gpio0 ASPEED_GPIO(Z, 5) GPIO_ACTIVE_HIGH>;
+ cs-gpios = <&gpio0 ASPEED_GPIO(Z, 0) GPIO_ACTIVE_LOW>;
+ num-chipselects = <1>;
+
+ tpm@0 {
+ compatible = "infineon,slb9670", "tcg,tpm_tis-spi";
+ spi-max-frequency = <33000000>;
+ reg = <0>;
+ };
+ };
+};
+
+&adc0 {
+ vref-supply = <&p1v8_bmc_aux>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc0_default &pinctrl_adc1_default
+ &pinctrl_adc2_default &pinctrl_adc3_default
+ &pinctrl_adc4_default &pinctrl_adc5_default
+ &pinctrl_adc6_default &pinctrl_adc7_default>;
+};
+
+&adc1 {
+ vref-supply = <&p2v5_bmc_aux>;
+ status = "okay";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_adc8_default &pinctrl_adc10_default>;
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&fmc {
+ status = "okay";
+
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "bmc";
+ spi-max-frequency = <50000000>;
+ #include "openbmc-flash-layout-128.dtsi"
+ };
+
+ flash@1 {
+ status = "okay";
+ m25p,fast-read;
+ label = "alt-bmc";
+ spi-max-frequency = <50000000>;
+ };
+};
+
+&gpio0 {
+ gpio-line-names =
+ /*A0-A7*/ "","","","","","","","",
+ /*B0-B7*/ "BATTERY_DETECT","","","BMC_READY_R",
+ "","FM_ID_LED","","",
+ /*C0-C7*/ "","","","","","","","",
+ /*D0-D7*/ "","","","","","","","",
+ /*E0-E7*/ "","","","","","","","",
+ /*F0-F7*/ "","","","","","","","",
+ /*G0-G7*/ "FM_MUX1_SEL_R","","","",
+ "","","","",
+ /*H0-H7*/ "","","","","","","","",
+ /*I0-I7*/ "","","","","","","","",
+ /*J0-J7*/ "","","","","","","","",
+ /*K0-K7*/ "","","","","","","","",
+ /*L0-L7*/ "","","","","","","","",
+ /*M0-M7*/ "","","","","STBY_POWER_PG_3V3","","","",
+ /*N0-N7*/ "LED_POSTCODE_0","LED_POSTCODE_1",
+ "LED_POSTCODE_2","LED_POSTCODE_3",
+ "LED_POSTCODE_4","LED_POSTCODE_5",
+ "LED_POSTCODE_6","LED_POSTCODE_7",
+ /*O0-O7*/ "","","","","","","","debug-card-mux",
+ /*P0-P7*/ "PWR_BTN_BMC_BUF_N","","ID_RST_BTN_BMC_N","",
+ "PWR_LED","","","BMC_HEARTBEAT_N",
+ /*Q0-Q7*/ "","","","","","","","",
+ /*R0-R7*/ "","","","","","","","",
+ /*S0-S7*/ "","","SYS_BMC_PWRBTN_R_N","","","","","",
+ /*T0-T7*/ "","","","","","","","",
+ /*U0-U7*/ "","","","","","","","",
+ /*V0-V7*/ "","","","","","","","",
+ /*W0-W7*/ "","","","","","","","",
+ /*X0-X7*/ "","","","","","","","",
+ /*Y0-Y7*/ "","","","","","","","",
+ /*Z0-Z7*/ "","","","","","","","";
+};
+
+&gpio1 {
+ gpio-line-names =
+ /*18A0-18A7*/ "","","","","","","","",
+ /*18B0-18B7*/ "","","","",
+ "FM_BOARD_BMC_REV_ID0","FM_BOARD_BMC_REV_ID1",
+ "FM_BOARD_BMC_REV_ID2","",
+ /*18C0-18C7*/ "SPI_BMC_BIOS_ROM_IRQ0_R_N","","","","","","","",
+ /*18D0-18D7*/ "","","","","","","","",
+ /*18E0-18E3*/ "FM_BMC_PROT_LS_EN","AC_PWR_BMC_BTN_R_N","","";
+};
+
+&i2c0 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ i2c0mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ i2c0mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ i2c0mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ };
+
+ i2c0mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c0mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c0mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c0mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+
+ fan_io_expander0: gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ fan_io_expander1: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ adc@1d {
+ compatible = "ti,adc128d818";
+ reg = <0x1d>;
+ ti,mode = /bits/ 8 <1>;
+ };
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+ };
+
+ i2c0mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ fanctl0: fan-controller@20 {
+ compatible = "maxim,max31790";
+ reg = <0x20>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@2 {
+ reg = <2>;
+ sensor-type = "TACH";
+ };
+
+ channel@5 {
+ reg = <5>;
+ sensor-type = "TACH";
+ };
+ };
+
+ fanctl1: fan-controller@23 {
+ compatible = "nuvoton,nct7363";
+ reg = <0x23>;
+ #pwm-cells = <2>;
+
+ fan-0 {
+ pwms = <&fanctl1 10 20000>;
+ tach-ch = /bits/ 8 <0x00>;
+ };
+
+ fan-1 {
+ pwms = <&fanctl1 6 20000>;
+ tach-ch = /bits/ 8 <0x01>;
+ };
+
+ fan-3 {
+ pwms = <&fanctl1 10 20000>;
+ tach-ch = /bits/ 8 <0x03>;
+ };
+
+ fan-9 {
+ pwms = <&fanctl1 0 20000>;
+ tach-ch = /bits/ 8 <0x09>;
+ };
+
+ fan-10 {
+ pwms = <&fanctl1 4 20000>;
+ tach-ch = /bits/ 8 <0x0A>;
+ };
+
+ fan-11 {
+ pwms = <&fanctl1 0 20000>;
+ tach-ch = /bits/ 8 <0x0B>;
+ };
+
+ fan-13 {
+ pwms = <&fanctl1 4 20000>;
+ tach-ch = /bits/ 8 <0x0D>;
+ };
+
+ fan-15 {
+ pwms = <&fanctl1 6 20000>;
+ tach-ch = /bits/ 8 <0x0F>;
+ };
+ };
+ };
+ };
+};
+
+&i2c1 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ i2c1mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c1mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c1mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c1mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c1mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c1mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c1mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c1mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c2 {
+ status = "okay";
+ bus-frequency = <400000>;
+};
+
+&i2c3 {
+ status = "okay";
+ bus-frequency = <400000>;
+
+ dac@c {
+ reg = <0x0c>;
+ compatible = "adi,ad5612";
+ vcc-supply = <&p5v_dac_aux>;
+ };
+
+ dac@e {
+ reg = <0x0e>;
+ compatible = "adi,ad5612";
+ vcc-supply = <&p5v_dac_aux>;
+ };
+
+ dac@f {
+ reg = <0x0f>;
+ compatible = "adi,ad5612";
+ vcc-supply = <&p5v_dac_aux>;
+ };
+
+ io_expander6: gpio@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&io_expander7>;
+ interrupts = <6 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ prsnt_io_expander0: gpio@40 {
+ compatible = "nxp,pca9698";
+ reg = <0x40>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <48 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN1_TRAY1_PRSNT", "CAN1_TRAY2_PRSNT",
+ "CAN1_TRAY3_PRSNT", "CAN1_TRAY4_PRSNT",
+ "CAN1_TRAY5_PRSNT", "CAN1_TRAY6_PRSNT",
+ "CAN1_TRAY7_PRSNT", "CAN1_TRAY8_PRSNT",
+ "CAN1_TRAY9_PRSNT", "CAN1_TRAY10_PRSNT",
+ "CAN1_TRAY11_PRSNT", "CAN1_TRAY12_PRSNT",
+ "CAN1_TRAY13_PRSNT", "CAN1_TRAY14_PRSNT",
+ "CAN1_TRAY15_PRSNT", "CAN1_TRAY16_PRSNT",
+ "CAN1_TRAY17_PRSNT", "CAN1_TRAY18_PRSNT",
+ "CAN1_TRAY19_PRSNT", "CAN1_TRAY20_PRSNT",
+ "CAN1_TRAY21_PRSNT", "CAN1_TRAY22_PRSNT",
+ "CAN1_TRAY23_PRSNT", "CAN1_TRAY24_PRSNT",
+ "CAN1_TRAY25_PRSNT", "CAN1_TRAY26_PRSNT",
+ "CAN1_TRAY27_PRSNT", "CAN1_TRAY28_PRSNT",
+ "CAN1_TRAY29_PRSNT", "CAN1_TRAY30_PRSNT",
+ "CAN1_TRAY31_PRSNT", "CAN1_TRAY32_PRSNT",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ prsnt_io_expander1: gpio@41 {
+ compatible = "nxp,pca9698";
+ reg = <0x41>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <56 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN2_TRAY1_PRSNT", "CAN2_TRAY2_PRSNT",
+ "CAN2_TRAY3_PRSNT", "CAN2_TRAY4_PRSNT",
+ "CAN2_TRAY5_PRSNT", "CAN2_TRAY6_PRSNT",
+ "CAN2_TRAY7_PRSNT", "CAN2_TRAY8_PRSNT",
+ "CAN2_TRAY9_PRSNT", "CAN2_TRAY10_PRSNT",
+ "CAN2_TRAY11_PRSNT", "CAN2_TRAY12_PRSNT",
+ "CAN2_TRAY13_PRSNT", "CAN2_TRAY14_PRSNT",
+ "CAN2_TRAY15_PRSNT", "CAN2_TRAY16_PRSNT",
+ "CAN2_TRAY17_PRSNT", "CAN2_TRAY18_PRSNT",
+ "CAN2_TRAY19_PRSNT", "CAN2_TRAY20_PRSNT",
+ "CAN2_TRAY21_PRSNT", "CAN2_TRAY22_PRSNT",
+ "CAN2_TRAY23_PRSNT", "CAN2_TRAY24_PRSNT",
+ "CAN2_TRAY25_PRSNT", "CAN2_TRAY26_PRSNT",
+ "CAN2_TRAY27_PRSNT", "CAN2_TRAY28_PRSNT",
+ "CAN2_TRAY29_PRSNT", "CAN2_TRAY30_PRSNT",
+ "CAN2_TRAY31_PRSNT", "CAN2_TRAY32_PRSNT",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ prsnt_io_expander2: gpio@42 {
+ compatible = "nxp,pca9698";
+ reg = <0x42>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <64 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN3_TRAY1_PRSNT", "CAN3_TRAY2_PRSNT",
+ "CAN3_TRAY3_PRSNT", "CAN3_TRAY4_PRSNT",
+ "CAN3_TRAY5_PRSNT", "CAN3_TRAY6_PRSNT",
+ "CAN3_TRAY7_PRSNT", "CAN3_TRAY8_PRSNT",
+ "CAN3_TRAY9_PRSNT", "CAN3_TRAY10_PRSNT",
+ "CAN3_TRAY11_PRSNT", "CAN3_TRAY12_PRSNT",
+ "CAN3_TRAY13_PRSNT", "CAN3_TRAY14_PRSNT",
+ "CAN3_TRAY15_PRSNT", "CAN3_TRAY16_PRSNT",
+ "CAN3_TRAY17_PRSNT", "CAN3_TRAY18_PRSNT",
+ "CAN3_TRAY19_PRSNT", "CAN3_TRAY20_PRSNT",
+ "CAN3_TRAY21_PRSNT", "CAN3_TRAY22_PRSNT",
+ "CAN3_TRAY23_PRSNT", "CAN3_TRAY24_PRSNT",
+ "CAN3_TRAY25_PRSNT", "CAN3_TRAY26_PRSNT",
+ "CAN3_TRAY27_PRSNT", "CAN3_TRAY28_PRSNT",
+ "CAN3_TRAY29_PRSNT", "CAN3_TRAY30_PRSNT",
+ "CAN3_TRAY31_PRSNT", "CAN3_TRAY32_PRSNT",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ prsnt_io_expander3: gpio@43 {
+ compatible = "nxp,pca9698";
+ reg = <0x43>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <72 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN4_TRAY1_PRSNT", "CAN4_TRAY2_PRSNT",
+ "CAN4_TRAY3_PRSNT", "CAN4_TRAY4_PRSNT",
+ "CAN4_TRAY5_PRSNT", "CAN4_TRAY6_PRSNT",
+ "CAN4_TRAY7_PRSNT", "CAN4_TRAY8_PRSNT",
+ "CAN4_TRAY9_PRSNT", "CAN4_TRAY10_PRSNT",
+ "CAN4_TRAY11_PRSNT", "CAN4_TRAY12_PRSNT",
+ "CAN4_TRAY13_PRSNT", "CAN4_TRAY14_PRSNT",
+ "CAN4_TRAY15_PRSNT", "CAN4_TRAY16_PRSNT",
+ "CAN4_TRAY17_PRSNT", "CAN4_TRAY18_PRSNT",
+ "CAN4_TRAY19_PRSNT", "CAN4_TRAY20_PRSNT",
+ "CAN4_TRAY21_PRSNT", "CAN4_TRAY22_PRSNT",
+ "CAN4_TRAY23_PRSNT", "CAN4_TRAY24_PRSNT",
+ "CAN4_TRAY25_PRSNT", "CAN4_TRAY26_PRSNT",
+ "CAN4_TRAY27_PRSNT", "CAN4_TRAY28_PRSNT",
+ "CAN4_TRAY29_PRSNT", "CAN4_TRAY30_PRSNT",
+ "CAN4_TRAY31_PRSNT", "CAN4_TRAY32_PRSNT",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ prsnt_io_expander4: gpio@44 {
+ compatible = "nxp,pca9698";
+ reg = <0x44>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <80 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN5_TRAY1_PRSNT", "CAN5_TRAY2_PRSNT",
+ "CAN5_TRAY3_PRSNT", "CAN5_TRAY4_PRSNT",
+ "CAN5_TRAY5_PRSNT", "CAN5_TRAY6_PRSNT",
+ "CAN5_TRAY7_PRSNT", "CAN5_TRAY8_PRSNT",
+ "CAN5_TRAY9_PRSNT", "CAN5_TRAY10_PRSNT",
+ "CAN5_TRAY11_PRSNT", "CAN5_TRAY12_PRSNT",
+ "CAN5_TRAY13_PRSNT", "CAN5_TRAY14_PRSNT",
+ "CAN5_TRAY15_PRSNT", "CAN5_TRAY16_PRSNT",
+ "CAN5_TRAY17_PRSNT", "CAN5_TRAY18_PRSNT",
+ "CAN5_TRAY19_PRSNT", "CAN5_TRAY20_PRSNT",
+ "CAN5_TRAY21_PRSNT", "CAN5_TRAY22_PRSNT",
+ "CAN5_TRAY23_PRSNT", "CAN5_TRAY24_PRSNT",
+ "CAN5_TRAY25_PRSNT", "CAN5_TRAY26_PRSNT",
+ "CAN5_TRAY27_PRSNT", "CAN5_TRAY28_PRSNT",
+ "CAN5_TRAY29_PRSNT", "CAN5_TRAY30_PRSNT",
+ "CAN5_TRAY31_PRSNT", "CAN5_TRAY32_PRSNT",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ prsnt_io_expander5: gpio@45 {
+ compatible = "nxp,pca9698";
+ reg = <0x45>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <88 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN6_TRAY1_PRSNT", "CAN6_TRAY2_PRSNT",
+ "CAN6_TRAY3_PRSNT", "CAN6_TRAY4_PRSNT",
+ "CAN6_TRAY5_PRSNT", "CAN6_TRAY6_PRSNT",
+ "CAN6_TRAY7_PRSNT", "CAN6_TRAY8_PRSNT",
+ "CAN6_TRAY9_PRSNT", "CAN6_TRAY10_PRSNT",
+ "CAN6_TRAY11_PRSNT", "CAN6_TRAY12_PRSNT",
+ "CAN6_TRAY13_PRSNT", "CAN6_TRAY14_PRSNT",
+ "CAN6_TRAY15_PRSNT", "CAN6_TRAY16_PRSNT",
+ "CAN6_TRAY17_PRSNT", "CAN6_TRAY18_PRSNT",
+ "CAN6_TRAY19_PRSNT", "CAN6_TRAY20_PRSNT",
+ "CAN6_TRAY21_PRSNT", "CAN6_TRAY22_PRSNT",
+ "CAN6_TRAY23_PRSNT", "CAN6_TRAY24_PRSNT",
+ "CAN6_TRAY25_PRSNT", "CAN6_TRAY26_PRSNT",
+ "CAN6_TRAY27_PRSNT", "CAN6_TRAY28_PRSNT",
+ "CAN6_TRAY29_PRSNT", "CAN6_TRAY30_PRSNT",
+ "CAN6_TRAY31_PRSNT", "CAN6_TRAY32_PRSNT",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ prsnt_io_expander6: gpio@46 {
+ compatible = "nxp,pca9698";
+ reg = <0x46>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <96 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN7_TRAY1_PRSNT", "CAN7_TRAY2_PRSNT",
+ "CAN7_TRAY3_PRSNT", "CAN7_TRAY4_PRSNT",
+ "CAN7_TRAY5_PRSNT", "CAN7_TRAY6_PRSNT",
+ "CAN7_TRAY7_PRSNT", "CAN7_TRAY8_PRSNT",
+ "CAN7_TRAY9_PRSNT", "CAN7_TRAY10_PRSNT",
+ "CAN7_TRAY11_PRSNT", "CAN7_TRAY12_PRSNT",
+ "CAN7_TRAY13_PRSNT", "CAN7_TRAY14_PRSNT",
+ "CAN7_TRAY15_PRSNT", "CAN7_TRAY16_PRSNT",
+ "CAN7_TRAY17_PRSNT", "CAN7_TRAY18_PRSNT",
+ "CAN7_TRAY19_PRSNT", "CAN7_TRAY20_PRSNT",
+ "CAN7_TRAY21_PRSNT", "CAN7_TRAY22_PRSNT",
+ "CAN7_TRAY23_PRSNT", "CAN7_TRAY24_PRSNT",
+ "CAN7_TRAY25_PRSNT", "CAN7_TRAY26_PRSNT",
+ "CAN7_TRAY27_PRSNT", "CAN7_TRAY28_PRSNT",
+ "CAN7_TRAY29_PRSNT", "CAN7_TRAY30_PRSNT",
+ "CAN7_TRAY31_PRSNT", "CAN7_TRAY32_PRSNT",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ prsnt_io_expander7: gpio@47 {
+ compatible = "nxp,pca9698";
+ reg = <0x47>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <104 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN8_TRAY1_PRSNT", "CAN8_TRAY2_PRSNT",
+ "CAN8_TRAY3_PRSNT", "CAN8_TRAY4_PRSNT",
+ "CAN8_TRAY5_PRSNT", "CAN8_TRAY6_PRSNT",
+ "CAN8_TRAY7_PRSNT", "CAN8_TRAY8_PRSNT",
+ "CAN8_TRAY9_PRSNT", "CAN8_TRAY10_PRSNT",
+ "CAN8_TRAY11_PRSNT", "CAN8_TRAY12_PRSNT",
+ "CAN8_TRAY13_PRSNT", "CAN8_TRAY14_PRSNT",
+ "CAN8_TRAY15_PRSNT", "CAN8_TRAY16_PRSNT",
+ "CAN8_TRAY17_PRSNT", "CAN8_TRAY18_PRSNT",
+ "CAN8_TRAY19_PRSNT", "CAN8_TRAY20_PRSNT",
+ "CAN8_TRAY21_PRSNT", "CAN8_TRAY22_PRSNT",
+ "CAN8_TRAY23_PRSNT", "CAN8_TRAY24_PRSNT",
+ "CAN8_TRAY25_PRSNT", "CAN8_TRAY26_PRSNT",
+ "CAN8_TRAY27_PRSNT", "CAN8_TRAY28_PRSNT",
+ "CAN8_TRAY29_PRSNT", "CAN8_TRAY30_PRSNT",
+ "CAN8_TRAY31_PRSNT", "CAN8_TRAY32_PRSNT",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ pwrgd_io_expander0: gpio@48 {
+ compatible = "nxp,pca9698";
+ reg = <0x48>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <50 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN1_TRAY1_PWRGD", "CAN1_TRAY2_PWRGD",
+ "CAN1_TRAY3_PWRGD", "CAN1_TRAY4_PWRGD",
+ "CAN1_TRAY5_PWRGD", "CAN1_TRAY6_PWRGD",
+ "CAN1_TRAY7_PWRGD", "CAN1_TRAY8_PWRGD",
+ "CAN1_TRAY9_PWRGD", "CAN1_TRAY10_PWRGD",
+ "CAN1_TRAY11_PWRGD", "CAN1_TRAY12_PWRGD",
+ "CAN1_TRAY13_PWRGD", "CAN1_TRAY14_PWRGD",
+ "CAN1_TRAY15_PWRGD", "CAN1_TRAY16_PWRGD",
+ "CAN1_TRAY17_PWRGD", "CAN1_TRAY18_PWRGD",
+ "CAN1_TRAY19_PWRGD", "CAN1_TRAY20_PWRGD",
+ "CAN1_TRAY21_PWRGD", "CAN1_TRAY22_PWRGD",
+ "CAN1_TRAY23_PWRGD", "CAN1_TRAY24_PWRGD",
+ "CAN1_TRAY25_PWRGD", "CAN1_TRAY26_PWRGD",
+ "CAN1_TRAY27_PWRGD", "CAN1_TRAY28_PWRGD",
+ "CAN1_TRAY29_PWRGD", "CAN1_TRAY30_PWRGD",
+ "CAN1_TRAY31_PWRGD", "CAN1_TRAY32_PWRGD",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ pwrgd_io_expander1: gpio@49 {
+ compatible = "nxp,pca9698";
+ reg = <0x49>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <58 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN2_TRAY1_PWRGD", "CAN2_TRAY2_PWRGD",
+ "CAN2_TRAY3_PWRGD", "CAN2_TRAY4_PWRGD",
+ "CAN2_TRAY5_PWRGD", "CAN2_TRAY6_PWRGD",
+ "CAN2_TRAY7_PWRGD", "CAN2_TRAY8_PWRGD",
+ "CAN2_TRAY9_PWRGD", "CAN2_TRAY10_PWRGD",
+ "CAN2_TRAY11_PWRGD", "CAN2_TRAY12_PWRGD",
+ "CAN2_TRAY13_PWRGD", "CAN2_TRAY14_PWRGD",
+ "CAN2_TRAY15_PWRGD", "CAN2_TRAY16_PWRGD",
+ "CAN2_TRAY17_PWRGD", "CAN2_TRAY18_PWRGD",
+ "CAN2_TRAY19_PWRGD", "CAN2_TRAY20_PWRGD",
+ "CAN2_TRAY21_PWRGD", "CAN2_TRAY22_PWRGD",
+ "CAN2_TRAY23_PWRGD", "CAN2_TRAY24_PWRGD",
+ "CAN2_TRAY25_PWRGD", "CAN2_TRAY26_PWRGD",
+ "CAN2_TRAY27_PWRGD", "CAN2_TRAY28_PWRGD",
+ "CAN2_TRAY29_PWRGD", "CAN2_TRAY30_PWRGD",
+ "CAN2_TRAY31_PWRGD", "CAN2_TRAY32_PWRGD",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ pwrgd_io_expander2: gpio@4a {
+ compatible = "nxp,pca9698";
+ reg = <0x4a>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <66 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN3_TRAY1_PWRGD", "CAN3_TRAY2_PWRGD",
+ "CAN3_TRAY3_PWRGD", "CAN3_TRAY4_PWRGD",
+ "CAN3_TRAY5_PWRGD", "CAN3_TRAY6_PWRGD",
+ "CAN3_TRAY7_PWRGD", "CAN3_TRAY8_PWRGD",
+ "CAN3_TRAY9_PWRGD", "CAN3_TRAY10_PWRGD",
+ "CAN3_TRAY11_PWRGD", "CAN3_TRAY12_PWRGD",
+ "CAN3_TRAY13_PWRGD", "CAN3_TRAY14_PWRGD",
+ "CAN3_TRAY15_PWRGD", "CAN3_TRAY16_PWRGD",
+ "CAN3_TRAY17_PWRGD", "CAN3_TRAY18_PWRGD",
+ "CAN3_TRAY19_PWRGD", "CAN3_TRAY20_PWRGD",
+ "CAN3_TRAY21_PWRGD", "CAN3_TRAY22_PWRGD",
+ "CAN3_TRAY23_PWRGD", "CAN3_TRAY24_PWRGD",
+ "CAN3_TRAY25_PWRGD", "CAN3_TRAY26_PWRGD",
+ "CAN3_TRAY27_PWRGD", "CAN3_TRAY28_PWRGD",
+ "CAN3_TRAY29_PWRGD", "CAN3_TRAY30_PWRGD",
+ "CAN3_TRAY31_PWRGD", "CAN3_TRAY32_PWRGD",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ pwrgd_io_expander3: gpio@4b {
+ compatible = "nxp,pca9698";
+ reg = <0x4b>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <74 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN4_TRAY1_PWRGD", "CAN4_TRAY2_PWRGD",
+ "CAN4_TRAY3_PWRGD", "CAN4_TRAY4_PWRGD",
+ "CAN4_TRAY5_PWRGD", "CAN4_TRAY6_PWRGD",
+ "CAN4_TRAY7_PWRGD", "CAN4_TRAY8_PWRGD",
+ "CAN4_TRAY9_PWRGD", "CAN4_TRAY10_PWRGD",
+ "CAN4_TRAY11_PWRGD", "CAN4_TRAY12_PWRGD",
+ "CAN4_TRAY13_PWRGD", "CAN4_TRAY14_PWRGD",
+ "CAN4_TRAY15_PWRGD", "CAN4_TRAY16_PWRGD",
+ "CAN4_TRAY17_PWRGD", "CAN4_TRAY18_PWRGD",
+ "CAN4_TRAY19_PWRGD", "CAN4_TRAY20_PWRGD",
+ "CAN4_TRAY21_PWRGD", "CAN4_TRAY22_PWRGD",
+ "CAN4_TRAY23_PWRGD", "CAN4_TRAY24_PWRGD",
+ "CAN4_TRAY25_PWRGD", "CAN4_TRAY26_PWRGD",
+ "CAN4_TRAY27_PWRGD", "CAN4_TRAY28_PWRGD",
+ "CAN4_TRAY29_PWRGD", "CAN4_TRAY30_PWRGD",
+ "CAN4_TRAY31_PWRGD", "CAN4_TRAY32_PWRGD",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ pwrgd_io_expander4: gpio@4c {
+ compatible = "nxp,pca9698";
+ reg = <0x4c>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <82 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN5_TRAY1_PWRGD", "CAN5_TRAY2_PWRGD",
+ "CAN5_TRAY3_PWRGD", "CAN5_TRAY4_PWRGD",
+ "CAN5_TRAY5_PWRGD", "CAN5_TRAY6_PWRGD",
+ "CAN5_TRAY7_PWRGD", "CAN5_TRAY8_PWRGD",
+ "CAN5_TRAY9_PWRGD", "CAN5_TRAY10_PWRGD",
+ "CAN5_TRAY11_PWRGD", "CAN5_TRAY12_PWRGD",
+ "CAN5_TRAY13_PWRGD", "CAN5_TRAY14_PWRGD",
+ "CAN5_TRAY15_PWRGD", "CAN5_TRAY16_PWRGD",
+ "CAN5_TRAY17_PWRGD", "CAN5_TRAY18_PWRGD",
+ "CAN5_TRAY19_PWRGD", "CAN5_TRAY20_PWRGD",
+ "CAN5_TRAY21_PWRGD", "CAN5_TRAY22_PWRGD",
+ "CAN5_TRAY23_PWRGD", "CAN5_TRAY24_PWRGD",
+ "CAN5_TRAY25_PWRGD", "CAN5_TRAY26_PWRGD",
+ "CAN5_TRAY27_PWRGD", "CAN5_TRAY28_PWRGD",
+ "CAN5_TRAY29_PWRGD", "CAN5_TRAY30_PWRGD",
+ "CAN5_TRAY31_PWRGD", "CAN5_TRAY32_PWRGD",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ pwrgd_io_expander5: gpio@4d {
+ compatible = "nxp,pca9698";
+ reg = <0x4d>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <90 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN6_TRAY1_PWRGD", "CAN6_TRAY2_PWRGD",
+ "CAN6_TRAY3_PWRGD", "CAN6_TRAY4_PWRGD",
+ "CAN6_TRAY5_PWRGD", "CAN6_TRAY6_PWRGD",
+ "CAN6_TRAY7_PWRGD", "CAN6_TRAY8_PWRGD",
+ "CAN6_TRAY9_PWRGD", "CAN6_TRAY10_PWRGD",
+ "CAN6_TRAY11_PWRGD", "CAN6_TRAY12_PWRGD",
+ "CAN6_TRAY13_PWRGD", "CAN6_TRAY14_PWRGD",
+ "CAN6_TRAY15_PWRGD", "CAN6_TRAY16_PWRGD",
+ "CAN6_TRAY17_PWRGD", "CAN6_TRAY18_PWRGD",
+ "CAN6_TRAY19_PWRGD", "CAN6_TRAY20_PWRGD",
+ "CAN6_TRAY21_PWRGD", "CAN6_TRAY22_PWRGD",
+ "CAN6_TRAY23_PWRGD", "CAN6_TRAY24_PWRGD",
+ "CAN6_TRAY25_PWRGD", "CAN6_TRAY26_PWRGD",
+ "CAN6_TRAY27_PWRGD", "CAN6_TRAY28_PWRGD",
+ "CAN6_TRAY29_PWRGD", "CAN6_TRAY30_PWRGD",
+ "CAN6_TRAY31_PWRGD", "CAN6_TRAY32_PWRGD",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ pwrgd_io_expander6: gpio@4e {
+ compatible = "nxp,pca9698";
+ reg = <0x4e>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <98 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN7_TRAY1_PWRGD", "CAN7_TRAY2_PWRGD",
+ "CAN7_TRAY3_PWRGD", "CAN7_TRAY4_PWRGD",
+ "CAN7_TRAY5_PWRGD", "CAN7_TRAY6_PWRGD",
+ "CAN7_TRAY7_PWRGD", "CAN7_TRAY8_PWRGD",
+ "CAN7_TRAY9_PWRGD", "CAN7_TRAY10_PWRGD",
+ "CAN7_TRAY11_PWRGD", "CAN7_TRAY12_PWRGD",
+ "CAN7_TRAY13_PWRGD", "CAN7_TRAY14_PWRGD",
+ "CAN7_TRAY15_PWRGD", "CAN7_TRAY16_PWRGD",
+ "CAN7_TRAY17_PWRGD", "CAN7_TRAY18_PWRGD",
+ "CAN7_TRAY19_PWRGD", "CAN7_TRAY20_PWRGD",
+ "CAN7_TRAY21_PWRGD", "CAN7_TRAY22_PWRGD",
+ "CAN7_TRAY23_PWRGD", "CAN7_TRAY24_PWRGD",
+ "CAN7_TRAY25_PWRGD", "CAN7_TRAY26_PWRGD",
+ "CAN7_TRAY27_PWRGD", "CAN7_TRAY28_PWRGD",
+ "CAN7_TRAY29_PWRGD", "CAN7_TRAY30_PWRGD",
+ "CAN7_TRAY31_PWRGD", "CAN7_TRAY32_PWRGD",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ pwrgd_io_expander7: gpio@4f {
+ compatible = "nxp,pca9698";
+ reg = <0x4f>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <106 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN8_TRAY1_PWRGD", "CAN8_TRAY2_PWRGD",
+ "CAN8_TRAY3_PWRGD", "CAN8_TRAY4_PWRGD",
+ "CAN8_TRAY5_PWRGD", "CAN8_TRAY6_PWRGD",
+ "CAN8_TRAY7_PWRGD", "CAN8_TRAY8_PWRGD",
+ "CAN8_TRAY9_PWRGD", "CAN8_TRAY10_PWRGD",
+ "CAN8_TRAY11_PWRGD", "CAN8_TRAY12_PWRGD",
+ "CAN8_TRAY13_PWRGD", "CAN8_TRAY14_PWRGD",
+ "CAN8_TRAY15_PWRGD", "CAN8_TRAY16_PWRGD",
+ "CAN8_TRAY17_PWRGD", "CAN8_TRAY18_PWRGD",
+ "CAN8_TRAY19_PWRGD", "CAN8_TRAY20_PWRGD",
+ "CAN8_TRAY21_PWRGD", "CAN8_TRAY22_PWRGD",
+ "CAN8_TRAY23_PWRGD", "CAN8_TRAY24_PWRGD",
+ "CAN8_TRAY25_PWRGD", "CAN8_TRAY26_PWRGD",
+ "CAN8_TRAY27_PWRGD", "CAN8_TRAY28_PWRGD",
+ "CAN8_TRAY29_PWRGD", "CAN8_TRAY30_PWRGD",
+ "CAN8_TRAY31_PWRGD", "CAN8_TRAY32_PWRGD",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ large_leak_io_expander0: gpio@50 {
+ compatible = "nxp,pca9698";
+ reg = <0x50>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <54 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN1_TRAY1_LARGE_LEAK", "CAN1_TRAY2_LARGE_LEAK",
+ "CAN1_TRAY3_LARGE_LEAK", "CAN1_TRAY4_LARGE_LEAK",
+ "CAN1_TRAY5_LARGE_LEAK", "CAN1_TRAY6_LARGE_LEAK",
+ "CAN1_TRAY7_LARGE_LEAK", "CAN1_TRAY8_LARGE_LEAK",
+ "CAN1_TRAY9_LARGE_LEAK", "CAN1_TRAY10_LARGE_LEAK",
+ "CAN1_TRAY11_LARGE_LEAK", "CAN1_TRAY12_LARGE_LEAK",
+ "CAN1_TRAY13_LARGE_LEAK", "CAN1_TRAY14_LARGE_LEAK",
+ "CAN1_TRAY15_LARGE_LEAK", "CAN1_TRAY16_LARGE_LEAK",
+ "CAN1_TRAY17_LARGE_LEAK", "CAN1_TRAY18_LARGE_LEAK",
+ "CAN1_TRAY19_LARGE_LEAK", "CAN1_TRAY20_LARGE_LEAK",
+ "CAN1_TRAY21_LARGE_LEAK", "CAN1_TRAY22_LARGE_LEAK",
+ "CAN1_TRAY23_LARGE_LEAK", "CAN1_TRAY24_LARGE_LEAK",
+ "CAN1_TRAY25_LARGE_LEAK", "CAN1_TRAY26_LARGE_LEAK",
+ "CAN1_TRAY27_LARGE_LEAK", "CAN1_TRAY28_LARGE_LEAK",
+ "CAN1_TRAY29_LARGE_LEAK", "CAN1_TRAY30_LARGE_LEAK",
+ "CAN1_TRAY31_LARGE_LEAK", "CAN1_TRAY32_LARGE_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ large_leak_io_expander1: gpio@51 {
+ compatible = "nxp,pca9698";
+ reg = <0x51>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <62 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN2_TRAY1_LARGE_LEAK", "CAN2_TRAY2_LARGE_LEAK",
+ "CAN2_TRAY3_LARGE_LEAK", "CAN2_TRAY4_LARGE_LEAK",
+ "CAN2_TRAY5_LARGE_LEAK", "CAN2_TRAY6_LARGE_LEAK",
+ "CAN2_TRAY7_LARGE_LEAK", "CAN2_TRAY8_LARGE_LEAK",
+ "CAN2_TRAY9_LARGE_LEAK", "CAN2_TRAY10_LARGE_LEAK",
+ "CAN2_TRAY11_LARGE_LEAK", "CAN2_TRAY12_LARGE_LEAK",
+ "CAN2_TRAY13_LARGE_LEAK", "CAN2_TRAY14_LARGE_LEAK",
+ "CAN2_TRAY15_LARGE_LEAK", "CAN2_TRAY16_LARGE_LEAK",
+ "CAN2_TRAY17_LARGE_LEAK", "CAN2_TRAY18_LARGE_LEAK",
+ "CAN2_TRAY19_LARGE_LEAK", "CAN2_TRAY20_LARGE_LEAK",
+ "CAN2_TRAY21_LARGE_LEAK", "CAN2_TRAY22_LARGE_LEAK",
+ "CAN2_TRAY23_LARGE_LEAK", "CAN2_TRAY24_LARGE_LEAK",
+ "CAN2_TRAY25_LARGE_LEAK", "CAN2_TRAY26_LARGE_LEAK",
+ "CAN2_TRAY27_LARGE_LEAK", "CAN2_TRAY28_LARGE_LEAK",
+ "CAN2_TRAY29_LARGE_LEAK", "CAN2_TRAY30_LARGE_LEAK",
+ "CAN2_TRAY31_LARGE_LEAK", "CAN2_TRAY32_LARGE_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ large_leak_io_expander2: gpio@52 {
+ compatible = "nxp,pca9698";
+ reg = <0x52>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <70 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN3_TRAY1_LARGE_LEAK", "CAN3_TRAY2_LARGE_LEAK",
+ "CAN3_TRAY3_LARGE_LEAK", "CAN3_TRAY4_LARGE_LEAK",
+ "CAN3_TRAY5_LARGE_LEAK", "CAN3_TRAY6_LARGE_LEAK",
+ "CAN3_TRAY7_LARGE_LEAK", "CAN3_TRAY8_LARGE_LEAK",
+ "CAN3_TRAY9_LARGE_LEAK", "CAN3_TRAY10_LARGE_LEAK",
+ "CAN3_TRAY11_LARGE_LEAK", "CAN3_TRAY12_LARGE_LEAK",
+ "CAN3_TRAY13_LARGE_LEAK", "CAN3_TRAY14_LARGE_LEAK",
+ "CAN3_TRAY15_LARGE_LEAK", "CAN3_TRAY16_LARGE_LEAK",
+ "CAN3_TRAY17_LARGE_LEAK", "CAN3_TRAY18_LARGE_LEAK",
+ "CAN3_TRAY19_LARGE_LEAK", "CAN3_TRAY20_LARGE_LEAK",
+ "CAN3_TRAY21_LARGE_LEAK", "CAN3_TRAY22_LARGE_LEAK",
+ "CAN3_TRAY23_LARGE_LEAK", "CAN3_TRAY24_LARGE_LEAK",
+ "CAN3_TRAY25_LARGE_LEAK", "CAN3_TRAY26_LARGE_LEAK",
+ "CAN3_TRAY27_LARGE_LEAK", "CAN3_TRAY28_LARGE_LEAK",
+ "CAN3_TRAY29_LARGE_LEAK", "CAN3_TRAY30_LARGE_LEAK",
+ "CAN3_TRAY31_LARGE_LEAK", "CAN3_TRAY32_LARGE_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ large_leak_io_expander3: gpio@53 {
+ compatible = "nxp,pca9698";
+ reg = <0x53>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <78 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN4_TRAY1_LARGE_LEAK", "CAN4_TRAY2_LARGE_LEAK",
+ "CAN4_TRAY3_LARGE_LEAK", "CAN4_TRAY4_LARGE_LEAK",
+ "CAN4_TRAY5_LARGE_LEAK", "CAN4_TRAY6_LARGE_LEAK",
+ "CAN4_TRAY7_LARGE_LEAK", "CAN4_TRAY8_LARGE_LEAK",
+ "CAN4_TRAY9_LARGE_LEAK", "CAN4_TRAY10_LARGE_LEAK",
+ "CAN4_TRAY11_LARGE_LEAK", "CAN4_TRAY12_LARGE_LEAK",
+ "CAN4_TRAY13_LARGE_LEAK", "CAN4_TRAY14_LARGE_LEAK",
+ "CAN4_TRAY15_LARGE_LEAK", "CAN4_TRAY16_LARGE_LEAK",
+ "CAN4_TRAY17_LARGE_LEAK", "CAN4_TRAY18_LARGE_LEAK",
+ "CAN4_TRAY19_LARGE_LEAK", "CAN4_TRAY20_LARGE_LEAK",
+ "CAN4_TRAY21_LARGE_LEAK", "CAN4_TRAY22_LARGE_LEAK",
+ "CAN4_TRAY23_LARGE_LEAK", "CAN4_TRAY24_LARGE_LEAK",
+ "CAN4_TRAY25_LARGE_LEAK", "CAN4_TRAY26_LARGE_LEAK",
+ "CAN4_TRAY27_LARGE_LEAK", "CAN4_TRAY28_LARGE_LEAK",
+ "CAN4_TRAY29_LARGE_LEAK", "CAN4_TRAY30_LARGE_LEAK",
+ "CAN4_TRAY31_LARGE_LEAK", "CAN4_TRAY32_LARGE_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ large_leak_io_expander4: gpio@54 {
+ compatible = "nxp,pca9698";
+ reg = <0x54>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <86 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN5_TRAY1_LARGE_LEAK", "CAN5_TRAY2_LARGE_LEAK",
+ "CAN5_TRAY3_LARGE_LEAK", "CAN5_TRAY4_LARGE_LEAK",
+ "CAN5_TRAY5_LARGE_LEAK", "CAN5_TRAY6_LARGE_LEAK",
+ "CAN5_TRAY7_LARGE_LEAK", "CAN5_TRAY8_LARGE_LEAK",
+ "CAN5_TRAY9_LARGE_LEAK", "CAN5_TRAY10_LARGE_LEAK",
+ "CAN5_TRAY11_LARGE_LEAK", "CAN5_TRAY12_LARGE_LEAK",
+ "CAN5_TRAY13_LARGE_LEAK", "CAN5_TRAY14_LARGE_LEAK",
+ "CAN5_TRAY15_LARGE_LEAK", "CAN5_TRAY16_LARGE_LEAK",
+ "CAN5_TRAY17_LARGE_LEAK", "CAN5_TRAY18_LARGE_LEAK",
+ "CAN5_TRAY19_LARGE_LEAK", "CAN5_TRAY20_LARGE_LEAK",
+ "CAN5_TRAY21_LARGE_LEAK", "CAN5_TRAY22_LARGE_LEAK",
+ "CAN5_TRAY23_LARGE_LEAK", "CAN5_TRAY24_LARGE_LEAK",
+ "CAN5_TRAY25_LARGE_LEAK", "CAN5_TRAY26_LARGE_LEAK",
+ "CAN5_TRAY27_LARGE_LEAK", "CAN5_TRAY28_LARGE_LEAK",
+ "CAN5_TRAY29_LARGE_LEAK", "CAN5_TRAY30_LARGE_LEAK",
+ "CAN5_TRAY31_LARGE_LEAK", "CAN5_TRAY32_LARGE_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ large_leak_io_expander5: gpio@55 {
+ compatible = "nxp,pca9698";
+ reg = <0x55>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <94 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN6_TRAY1_LARGE_LEAK", "CAN6_TRAY2_LARGE_LEAK",
+ "CAN6_TRAY3_LARGE_LEAK", "CAN6_TRAY4_LARGE_LEAK",
+ "CAN6_TRAY5_LARGE_LEAK", "CAN6_TRAY6_LARGE_LEAK",
+ "CAN6_TRAY7_LARGE_LEAK", "CAN6_TRAY8_LARGE_LEAK",
+ "CAN6_TRAY9_LARGE_LEAK", "CAN6_TRAY10_LARGE_LEAK",
+ "CAN6_TRAY11_LARGE_LEAK", "CAN6_TRAY12_LARGE_LEAK",
+ "CAN6_TRAY13_LARGE_LEAK", "CAN6_TRAY14_LARGE_LEAK",
+ "CAN6_TRAY15_LARGE_LEAK", "CAN6_TRAY16_LARGE_LEAK",
+ "CAN6_TRAY17_LARGE_LEAK", "CAN6_TRAY18_LARGE_LEAK",
+ "CAN6_TRAY19_LARGE_LEAK", "CAN6_TRAY20_LARGE_LEAK",
+ "CAN6_TRAY21_LARGE_LEAK", "CAN6_TRAY22_LARGE_LEAK",
+ "CAN6_TRAY23_LARGE_LEAK", "CAN6_TRAY24_LARGE_LEAK",
+ "CAN6_TRAY25_LARGE_LEAK", "CAN6_TRAY26_LARGE_LEAK",
+ "CAN6_TRAY27_LARGE_LEAK", "CAN6_TRAY28_LARGE_LEAK",
+ "CAN6_TRAY29_LARGE_LEAK", "CAN6_TRAY30_LARGE_LEAK",
+ "CAN6_TRAY31_LARGE_LEAK", "CAN6_TRAY32_LARGE_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ large_leak_io_expander6: gpio@56 {
+ compatible = "nxp,pca9698";
+ reg = <0x56>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <102 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN7_TRAY1_LARGE_LEAK", "CAN7_TRAY2_LARGE_LEAK",
+ "CAN7_TRAY3_LARGE_LEAK", "CAN7_TRAY4_LARGE_LEAK",
+ "CAN7_TRAY5_LARGE_LEAK", "CAN7_TRAY6_LARGE_LEAK",
+ "CAN7_TRAY7_LARGE_LEAK", "CAN7_TRAY8_LARGE_LEAK",
+ "CAN7_TRAY9_LARGE_LEAK", "CAN7_TRAY10_LARGE_LEAK",
+ "CAN7_TRAY11_LARGE_LEAK", "CAN7_TRAY12_LARGE_LEAK",
+ "CAN7_TRAY13_LARGE_LEAK", "CAN7_TRAY14_LARGE_LEAK",
+ "CAN7_TRAY15_LARGE_LEAK", "CAN7_TRAY16_LARGE_LEAK",
+ "CAN7_TRAY17_LARGE_LEAK", "CAN7_TRAY18_LARGE_LEAK",
+ "CAN7_TRAY19_LARGE_LEAK", "CAN7_TRAY20_LARGE_LEAK",
+ "CAN7_TRAY21_LARGE_LEAK", "CAN7_TRAY22_LARGE_LEAK",
+ "CAN7_TRAY23_LARGE_LEAK", "CAN7_TRAY24_LARGE_LEAK",
+ "CAN7_TRAY25_LARGE_LEAK", "CAN7_TRAY26_LARGE_LEAK",
+ "CAN7_TRAY27_LARGE_LEAK", "CAN7_TRAY28_LARGE_LEAK",
+ "CAN7_TRAY29_LARGE_LEAK", "CAN7_TRAY30_LARGE_LEAK",
+ "CAN7_TRAY31_LARGE_LEAK", "CAN7_TRAY32_LARGE_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ large_leak_io_expander7: gpio@57 {
+ compatible = "nxp,pca9698";
+ reg = <0x57>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <110 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN8_TRAY1_LARGE_LEAK", "CAN8_TRAY2_LARGE_LEAK",
+ "CAN8_TRAY3_LARGE_LEAK", "CAN8_TRAY4_LARGE_LEAK",
+ "CAN8_TRAY5_LARGE_LEAK", "CAN8_TRAY6_LARGE_LEAK",
+ "CAN8_TRAY7_LARGE_LEAK", "CAN8_TRAY8_LARGE_LEAK",
+ "CAN8_TRAY9_LARGE_LEAK", "CAN8_TRAY10_LARGE_LEAK",
+ "CAN8_TRAY11_LARGE_LEAK", "CAN8_TRAY12_LARGE_LEAK",
+ "CAN8_TRAY13_LARGE_LEAK", "CAN8_TRAY14_LARGE_LEAK",
+ "CAN8_TRAY15_LARGE_LEAK", "CAN8_TRAY16_LARGE_LEAK",
+ "CAN8_TRAY17_LARGE_LEAK", "CAN8_TRAY18_LARGE_LEAK",
+ "CAN8_TRAY19_LARGE_LEAK", "CAN8_TRAY20_LARGE_LEAK",
+ "CAN8_TRAY21_LARGE_LEAK", "CAN8_TRAY22_LARGE_LEAK",
+ "CAN8_TRAY23_LARGE_LEAK", "CAN8_TRAY24_LARGE_LEAK",
+ "CAN8_TRAY25_LARGE_LEAK", "CAN8_TRAY26_LARGE_LEAK",
+ "CAN8_TRAY27_LARGE_LEAK", "CAN8_TRAY28_LARGE_LEAK",
+ "CAN8_TRAY29_LARGE_LEAK", "CAN8_TRAY30_LARGE_LEAK",
+ "CAN8_TRAY31_LARGE_LEAK", "CAN8_TRAY32_LARGE_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ small_leak_io_expander0: gpio@58 {
+ compatible = "nxp,pca9698";
+ reg = <0x58>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <52 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN1_TRAY1_SMALL_LEAK", "CAN1_TRAY2_SMALL_LEAK",
+ "CAN1_TRAY3_SMALL_LEAK", "CAN1_TRAY4_SMALL_LEAK",
+ "CAN1_TRAY5_SMALL_LEAK", "CAN1_TRAY6_SMALL_LEAK",
+ "CAN1_TRAY7_SMALL_LEAK", "CAN1_TRAY8_SMALL_LEAK",
+ "CAN1_TRAY9_SMALL_LEAK", "CAN1_TRAY10_SMALL_LEAK",
+ "CAN1_TRAY11_SMALL_LEAK", "CAN1_TRAY12_SMALL_LEAK",
+ "CAN1_TRAY13_SMALL_LEAK", "CAN1_TRAY14_SMALL_LEAK",
+ "CAN1_TRAY15_SMALL_LEAK", "CAN1_TRAY16_SMALL_LEAK",
+ "CAN1_TRAY17_SMALL_LEAK", "CAN1_TRAY18_SMALL_LEAK",
+ "CAN1_TRAY19_SMALL_LEAK", "CAN1_TRAY20_SMALL_LEAK",
+ "CAN1_TRAY21_SMALL_LEAK", "CAN1_TRAY22_SMALL_LEAK",
+ "CAN1_TRAY23_SMALL_LEAK", "CAN1_TRAY24_SMALL_LEAK",
+ "CAN1_TRAY25_SMALL_LEAK", "CAN1_TRAY26_SMALL_LEAK",
+ "CAN1_TRAY27_SMALL_LEAK", "CAN1_TRAY28_SMALL_LEAK",
+ "CAN1_TRAY29_SMALL_LEAK", "CAN1_TRAY30_SMALL_LEAK",
+ "CAN1_TRAY31_SMALL_LEAK", "CAN1_TRAY32_SMALL_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ small_leak_io_expander1: gpio@59 {
+ compatible = "nxp,pca9698";
+ reg = <0x59>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <60 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN2_TRAY1_SMALL_LEAK", "CAN2_TRAY2_SMALL_LEAK",
+ "CAN2_TRAY3_SMALL_LEAK", "CAN2_TRAY4_SMALL_LEAK",
+ "CAN2_TRAY5_SMALL_LEAK", "CAN2_TRAY6_SMALL_LEAK",
+ "CAN2_TRAY7_SMALL_LEAK", "CAN2_TRAY8_SMALL_LEAK",
+ "CAN2_TRAY9_SMALL_LEAK", "CAN2_TRAY10_SMALL_LEAK",
+ "CAN2_TRAY11_SMALL_LEAK", "CAN2_TRAY12_SMALL_LEAK",
+ "CAN2_TRAY13_SMALL_LEAK", "CAN2_TRAY14_SMALL_LEAK",
+ "CAN2_TRAY15_SMALL_LEAK", "CAN2_TRAY16_SMALL_LEAK",
+ "CAN2_TRAY17_SMALL_LEAK", "CAN2_TRAY18_SMALL_LEAK",
+ "CAN2_TRAY19_SMALL_LEAK", "CAN2_TRAY20_SMALL_LEAK",
+ "CAN2_TRAY21_SMALL_LEAK", "CAN2_TRAY22_SMALL_LEAK",
+ "CAN2_TRAY23_SMALL_LEAK", "CAN2_TRAY24_SMALL_LEAK",
+ "CAN2_TRAY25_SMALL_LEAK", "CAN2_TRAY26_SMALL_LEAK",
+ "CAN2_TRAY27_SMALL_LEAK", "CAN2_TRAY28_SMALL_LEAK",
+ "CAN2_TRAY29_SMALL_LEAK", "CAN2_TRAY30_SMALL_LEAK",
+ "CAN2_TRAY31_SMALL_LEAK", "CAN2_TRAY32_SMALL_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ small_leak_io_expander2: gpio@5a {
+ compatible = "nxp,pca9698";
+ reg = <0x5a>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <68 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN3_TRAY1_SMALL_LEAK", "CAN3_TRAY2_SMALL_LEAK",
+ "CAN3_TRAY3_SMALL_LEAK", "CAN3_TRAY4_SMALL_LEAK",
+ "CAN3_TRAY5_SMALL_LEAK", "CAN3_TRAY6_SMALL_LEAK",
+ "CAN3_TRAY7_SMALL_LEAK", "CAN3_TRAY8_SMALL_LEAK",
+ "CAN3_TRAY9_SMALL_LEAK", "CAN3_TRAY10_SMALL_LEAK",
+ "CAN3_TRAY11_SMALL_LEAK", "CAN3_TRAY12_SMALL_LEAK",
+ "CAN3_TRAY13_SMALL_LEAK", "CAN3_TRAY14_SMALL_LEAK",
+ "CAN3_TRAY15_SMALL_LEAK", "CAN3_TRAY16_SMALL_LEAK",
+ "CAN3_TRAY17_SMALL_LEAK", "CAN3_TRAY18_SMALL_LEAK",
+ "CAN3_TRAY19_SMALL_LEAK", "CAN3_TRAY20_SMALL_LEAK",
+ "CAN3_TRAY21_SMALL_LEAK", "CAN3_TRAY22_SMALL_LEAK",
+ "CAN3_TRAY23_SMALL_LEAK", "CAN3_TRAY24_SMALL_LEAK",
+ "CAN3_TRAY25_SMALL_LEAK", "CAN3_TRAY26_SMALL_LEAK",
+ "CAN3_TRAY27_SMALL_LEAK", "CAN3_TRAY28_SMALL_LEAK",
+ "CAN3_TRAY29_SMALL_LEAK", "CAN3_TRAY30_SMALL_LEAK",
+ "CAN3_TRAY31_SMALL_LEAK", "CAN3_TRAY32_SMALL_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ small_leak_io_expander3: gpio@5b {
+ compatible = "nxp,pca9698";
+ reg = <0x5b>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <76 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN4_TRAY1_SMALL_LEAK", "CAN4_TRAY2_SMALL_LEAK",
+ "CAN4_TRAY3_SMALL_LEAK", "CAN4_TRAY4_SMALL_LEAK",
+ "CAN4_TRAY5_SMALL_LEAK", "CAN4_TRAY6_SMALL_LEAK",
+ "CAN4_TRAY7_SMALL_LEAK", "CAN4_TRAY8_SMALL_LEAK",
+ "CAN4_TRAY9_SMALL_LEAK", "CAN4_TRAY10_SMALL_LEAK",
+ "CAN4_TRAY11_SMALL_LEAK", "CAN4_TRAY12_SMALL_LEAK",
+ "CAN4_TRAY13_SMALL_LEAK", "CAN4_TRAY14_SMALL_LEAK",
+ "CAN4_TRAY15_SMALL_LEAK", "CAN4_TRAY16_SMALL_LEAK",
+ "CAN4_TRAY17_SMALL_LEAK", "CAN4_TRAY18_SMALL_LEAK",
+ "CAN4_TRAY19_SMALL_LEAK", "CAN4_TRAY20_SMALL_LEAK",
+ "CAN4_TRAY21_SMALL_LEAK", "CAN4_TRAY22_SMALL_LEAK",
+ "CAN4_TRAY23_SMALL_LEAK", "CAN4_TRAY24_SMALL_LEAK",
+ "CAN4_TRAY25_SMALL_LEAK", "CAN4_TRAY26_SMALL_LEAK",
+ "CAN4_TRAY27_SMALL_LEAK", "CAN4_TRAY28_SMALL_LEAK",
+ "CAN4_TRAY29_SMALL_LEAK", "CAN4_TRAY30_SMALL_LEAK",
+ "CAN4_TRAY31_SMALL_LEAK", "CAN4_TRAY32_SMALL_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ small_leak_io_expander4: gpio@5c {
+ compatible = "nxp,pca9698";
+ reg = <0x5c>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <84 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN5_TRAY1_SMALL_LEAK", "CAN5_TRAY2_SMALL_LEAK",
+ "CAN5_TRAY3_SMALL_LEAK", "CAN5_TRAY4_SMALL_LEAK",
+ "CAN5_TRAY5_SMALL_LEAK", "CAN5_TRAY6_SMALL_LEAK",
+ "CAN5_TRAY7_SMALL_LEAK", "CAN5_TRAY8_SMALL_LEAK",
+ "CAN5_TRAY9_SMALL_LEAK", "CAN5_TRAY10_SMALL_LEAK",
+ "CAN5_TRAY11_SMALL_LEAK", "CAN5_TRAY12_SMALL_LEAK",
+ "CAN5_TRAY13_SMALL_LEAK", "CAN5_TRAY14_SMALL_LEAK",
+ "CAN5_TRAY15_SMALL_LEAK", "CAN5_TRAY16_SMALL_LEAK",
+ "CAN5_TRAY17_SMALL_LEAK", "CAN5_TRAY18_SMALL_LEAK",
+ "CAN5_TRAY19_SMALL_LEAK", "CAN5_TRAY20_SMALL_LEAK",
+ "CAN5_TRAY21_SMALL_LEAK", "CAN5_TRAY22_SMALL_LEAK",
+ "CAN5_TRAY23_SMALL_LEAK", "CAN5_TRAY24_SMALL_LEAK",
+ "CAN5_TRAY25_SMALL_LEAK", "CAN5_TRAY26_SMALL_LEAK",
+ "CAN5_TRAY27_SMALL_LEAK", "CAN5_TRAY28_SMALL_LEAK",
+ "CAN5_TRAY29_SMALL_LEAK", "CAN5_TRAY30_SMALL_LEAK",
+ "CAN5_TRAY31_SMALL_LEAK", "CAN5_TRAY32_SMALL_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ small_leak_io_expander5: gpio@5d {
+ compatible = "nxp,pca9698";
+ reg = <0x5d>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <92 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN6_TRAY1_SMALL_LEAK", "CAN6_TRAY2_SMALL_LEAK",
+ "CAN6_TRAY3_SMALL_LEAK", "CAN6_TRAY4_SMALL_LEAK",
+ "CAN6_TRAY5_SMALL_LEAK", "CAN6_TRAY6_SMALL_LEAK",
+ "CAN6_TRAY7_SMALL_LEAK", "CAN6_TRAY8_SMALL_LEAK",
+ "CAN6_TRAY9_SMALL_LEAK", "CAN6_TRAY10_SMALL_LEAK",
+ "CAN6_TRAY11_SMALL_LEAK", "CAN6_TRAY12_SMALL_LEAK",
+ "CAN6_TRAY13_SMALL_LEAK", "CAN6_TRAY14_SMALL_LEAK",
+ "CAN6_TRAY15_SMALL_LEAK", "CAN6_TRAY16_SMALL_LEAK",
+ "CAN6_TRAY17_SMALL_LEAK", "CAN6_TRAY18_SMALL_LEAK",
+ "CAN6_TRAY19_SMALL_LEAK", "CAN6_TRAY20_SMALL_LEAK",
+ "CAN6_TRAY21_SMALL_LEAK", "CAN6_TRAY22_SMALL_LEAK",
+ "CAN6_TRAY23_SMALL_LEAK", "CAN6_TRAY24_SMALL_LEAK",
+ "CAN6_TRAY25_SMALL_LEAK", "CAN6_TRAY26_SMALL_LEAK",
+ "CAN6_TRAY27_SMALL_LEAK", "CAN6_TRAY28_SMALL_LEAK",
+ "CAN6_TRAY29_SMALL_LEAK", "CAN6_TRAY30_SMALL_LEAK",
+ "CAN6_TRAY31_SMALL_LEAK", "CAN6_TRAY32_SMALL_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ small_leak_io_expander6: gpio@5e {
+ compatible = "nxp,pca9698";
+ reg = <0x5e>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <100 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN7_TRAY1_SMALL_LEAK", "CAN7_TRAY2_SMALL_LEAK",
+ "CAN7_TRAY3_SMALL_LEAK", "CAN7_TRAY4_SMALL_LEAK",
+ "CAN7_TRAY5_SMALL_LEAK", "CAN7_TRAY6_SMALL_LEAK",
+ "CAN7_TRAY7_SMALL_LEAK", "CAN7_TRAY8_SMALL_LEAK",
+ "CAN7_TRAY9_SMALL_LEAK", "CAN7_TRAY10_SMALL_LEAK",
+ "CAN7_TRAY11_SMALL_LEAK", "CAN7_TRAY12_SMALL_LEAK",
+ "CAN7_TRAY13_SMALL_LEAK", "CAN7_TRAY14_SMALL_LEAK",
+ "CAN7_TRAY15_SMALL_LEAK", "CAN7_TRAY16_SMALL_LEAK",
+ "CAN7_TRAY17_SMALL_LEAK", "CAN7_TRAY18_SMALL_LEAK",
+ "CAN7_TRAY19_SMALL_LEAK", "CAN7_TRAY20_SMALL_LEAK",
+ "CAN7_TRAY21_SMALL_LEAK", "CAN7_TRAY22_SMALL_LEAK",
+ "CAN7_TRAY23_SMALL_LEAK", "CAN7_TRAY24_SMALL_LEAK",
+ "CAN7_TRAY25_SMALL_LEAK", "CAN7_TRAY26_SMALL_LEAK",
+ "CAN7_TRAY27_SMALL_LEAK", "CAN7_TRAY28_SMALL_LEAK",
+ "CAN7_TRAY29_SMALL_LEAK", "CAN7_TRAY30_SMALL_LEAK",
+ "CAN7_TRAY31_SMALL_LEAK", "CAN7_TRAY32_SMALL_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ small_leak_io_expander7: gpio@5f {
+ compatible = "nxp,pca9698";
+ reg = <0x5f>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <108 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "CAN8_TRAY1_SMALL_LEAK", "CAN8_TRAY2_SMALL_LEAK",
+ "CAN8_TRAY3_SMALL_LEAK", "CAN8_TRAY4_SMALL_LEAK",
+ "CAN8_TRAY5_SMALL_LEAK", "CAN8_TRAY6_SMALL_LEAK",
+ "CAN8_TRAY7_SMALL_LEAK", "CAN8_TRAY8_SMALL_LEAK",
+ "CAN8_TRAY9_SMALL_LEAK", "CAN8_TRAY10_SMALL_LEAK",
+ "CAN8_TRAY11_SMALL_LEAK", "CAN8_TRAY12_SMALL_LEAK",
+ "CAN8_TRAY13_SMALL_LEAK", "CAN8_TRAY14_SMALL_LEAK",
+ "CAN8_TRAY15_SMALL_LEAK", "CAN8_TRAY16_SMALL_LEAK",
+ "CAN8_TRAY17_SMALL_LEAK", "CAN8_TRAY18_SMALL_LEAK",
+ "CAN8_TRAY19_SMALL_LEAK", "CAN8_TRAY20_SMALL_LEAK",
+ "CAN8_TRAY21_SMALL_LEAK", "CAN8_TRAY22_SMALL_LEAK",
+ "CAN8_TRAY23_SMALL_LEAK", "CAN8_TRAY24_SMALL_LEAK",
+ "CAN8_TRAY25_SMALL_LEAK", "CAN8_TRAY26_SMALL_LEAK",
+ "CAN8_TRAY27_SMALL_LEAK", "CAN8_TRAY28_SMALL_LEAK",
+ "CAN8_TRAY29_SMALL_LEAK", "CAN8_TRAY30_SMALL_LEAK",
+ "CAN8_TRAY31_SMALL_LEAK", "CAN8_TRAY32_SMALL_LEAK",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+};
+
+&i2c4 {
+ status = "okay";
+ multi-master;
+ mctp-controller;
+
+ mctp0: mctp@10 {
+ compatible = "mctp-i2c-controller";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ };
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ idle-state = <6>;
+
+ i2c4mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ io_expander3: gpio@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&io_expander7>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "RST_I2CRST_MUX1_N",
+ "RST_I2CRST_MUX2_N", "RST_I2CRST_MUX3_N",
+ "RST_I2CRST_MUX4_N", "RST_I2CRST_MUX5_N",
+ "RST_I2CRST_MUX6_N", "RST_I2CRST_MUX7_N",
+ "RST_I2CRST_MUX8_N", "",
+ "TRAY30_PWRGD_BUF_R", "TRAY31_PWRGD_BUF_R",
+ "TRAY32_PWRGD_BUF_R", "TRAY37_PWRGD_BUF_R";
+ };
+ };
+
+ i2c4mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ temp-sensor@48 {
+ compatible = "ti,tmp75";
+ reg = <0x48>;
+ };
+
+ temp-sensor@4a {
+ compatible = "ti,tmp75";
+ reg = <0x4a>;
+ };
+
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c4mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c4mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c4mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c4mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c4mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ mctp-controller;
+ };
+
+ i2c4mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c5 {
+ status = "okay";
+
+ io_expander4: gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&io_expander7>;
+ interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "R_COME_THERMTRIP_L", "R_PWRGD_PCH_PWROK",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "TRAY38_PWRGD_BUF_R",
+ "TRAY39_PWRGD_BUF_R", "TRAY40_PWRGD_BUF_R";
+ };
+
+ io_expander5: gpio@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&io_expander7>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "PWRGD_P5V_AUX_R2", "",
+ "PWRGD_P1V5_AUX_R", "PWRGD_P1V05_AUX_R",
+ "PWRGD_P52V_HSC_PWROK_R", "PWRGD_P24V_AUX_2_R",
+ "PWRGD_P24V_AUX_R", "PWRGD_P12V_AUX_R2",
+ "PWRGD_P12V_SCM_R", "P24V_AUX_INA230_ALERT_N_R",
+ "", "PRSNT_CAN1_MCIO_N",
+ "PRSNT_CAN2_MCIO_N", "PRSNT_AALC_MCIO_N",
+ "PRSNT_RACKMON_MCIO_N", "PRSNT_RIO_RACKMON_N";
+ };
+
+ temp-sensor@4f {
+ compatible = "ti,tmp75";
+ reg = <0x4f>;
+ };
+
+ eeprom@54 {
+ compatible = "atmel,24c128";
+ reg = <0x54>;
+ };
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ i2c5mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ };
+
+ i2c5mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ };
+
+ i2c5mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c5mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c5mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c5mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c5mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+
+ i2c5mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+
+ eeprom@56 {
+ compatible = "atmel,24c128";
+ reg = <0x56>;
+ };
+ };
+ };
+};
+
+&i2c6 {
+ status = "okay";
+
+ dac@c {
+ reg = <0x0c>;
+ compatible = "adi,ad5612";
+ vcc-supply = <&p5v_dac_aux>;
+ };
+
+ dac@e {
+ reg = <0x0e>;
+ compatible = "adi,ad5612";
+ vcc-supply = <&p5v_dac_aux>;
+ };
+
+ dac@f {
+ reg = <0x0f>;
+ compatible = "adi,ad5612";
+ vcc-supply = <&p5v_dac_aux>;
+ };
+
+ io_expander0: gpio@20 {
+ compatible = "nxp,pca9555";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&io_expander7>;
+ /*
+ * Note: io_expander0 and io_expander8 physically share the
+ * same interrupt line (Wired-OR) to io_expander7 pin 0.
+ */
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "PRSNT_FANBP_0_PWR_N",
+ "PRSNT_FANBP_0_SIG_N", "PRSNT_POE_PWR_N",
+ "PRSNT_POE_SIG_N", "",
+ "PWRGD_P3V3_ISO_POE_BMC_R", "",
+ "", "",
+ "DEV_DIS_N", "PCI_DIS_N";
+ };
+
+ io_expander1: gpio@21 {
+ compatible = "nxp,pca9555";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&io_expander7>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "PWRGD_CPU_LVC3_BMC", "R_FM_BIOS_POST_CMPLT_BMC",
+ "", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "PCIE_SSD1_PRSNT_N",
+ "", "TRAY23_PWRGD_BUF_R",
+ "TRAY24_PWRGD_BUF_R", "TRAY29_PWRGD_BUF_R";
+ };
+
+ io_expander2: gpio@22 {
+ compatible = "nxp,pca9555";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&io_expander7>;
+ interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "BOARD_ID_0", "BOARD_ID_1",
+ "BOARD_ID_2", "BOARD_ID_3",
+ "SKU_ID_3", "SKU_ID_2",
+ "SKU_ID_1", "SKU_ID_0",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ io_expander7: gpio@23 {
+ compatible = "nxp,pca9555";
+ reg = <0x23>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <32 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "IOEXP1_INT_N", "IOEXP2_INT_N",
+ "IOEXP3_INT_N", "IOEXP4_INT_N",
+ "IOEXP5_INT_N", "IOEXP6_INT_N",
+ "IOEXP7_INT_N", "",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ io_expander8: gpio@24 {
+ compatible = "nxp,pca9555";
+ reg = <0x24>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&io_expander7>;
+ /* Shared interrupt line with io_expander0 */
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "PRSNT_MGMT_J54_N", "PRSNT_RACKMON_J47_N",
+ "PRSNT_MGMT_DEBUG_J53_N", "PRSNT_MINISAS_TOP_J49_N",
+ "PRSNT_MINISAS_TOP_J50_N", "PRSNT_MINISAS_BOT_J51_N",
+ "PRSNT_MINISAS_BOT_J52_N", "JTAG_PLD_JTAGEN",
+ "PU_PLD_CONFIG_N", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ /*
+ * This EEPROM is physically isolated by a hardware I2C multiplexer.
+ * By default, it is connected directly to the Marvell switch for
+ * routine configuration loading. The BMC only routes the EEPROM to
+ * its own I2C bus for out-of-band firmware updates while the switch
+ * is held in reset by the CPLD, ensuring no concurrent access.
+ */
+ eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ };
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+};
+
+&i2c7 {
+ status = "okay";
+ bus-frequency = <100000>;
+ multi-master;
+ aspeed,hw-timeout-ms = <1000>;
+
+ ipmb@10 {
+ compatible = "ipmb-dev";
+ reg = <(0x10 | I2C_OWN_SLAVE_ADDRESS)>;
+ i2c-protocol;
+ };
+};
+
+&i2c8 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ i2c8mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c8mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c8mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c8mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c8mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c8mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c8mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c8mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c9 {
+ status = "okay";
+
+ temperature-sensor@4b {
+ compatible = "ti,tmp75";
+ reg = <0x4b>;
+ };
+
+ eeprom@50 {
+ compatible = "atmel,24c128";
+ reg = <0x50>;
+ };
+
+ eeprom@51 {
+ compatible = "atmel,24c128";
+ reg = <0x51>;
+ };
+
+ eeprom@56 {
+ compatible = "atmel,24c64";
+ reg = <0x56>;
+ };
+};
+
+&i2c10 {
+ status = "okay";
+ /*
+ * This board physically routes two sets of presence signals to support
+ * both new and older tray designs concurrently.
+ * The 'legacy_' prefix is used to distinguish these backward-compatible
+ * PCA9555 expanders from the new CAN-based PCA9698 expanders (e.g., gpio@40)
+ * and to prevent device tree label collisions.
+ */
+ legacy_prsnt_io_expander0: gpio@11 {
+ compatible = "nxp,pca9555";
+ reg = <0x11>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <40 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_PRSNT1_N_BUF_R", "TRAY_PRSNT2_N_BUF_R",
+ "TRAY_PRSNT3_N_BUF_R", "TRAY_PRSNT4_N_BUF_R",
+ "TRAY_PRSNT5_N_BUF_R", "TRAY_PRSNT6_N_BUF_R",
+ "TRAY_PRSNT7_N_BUF_R", "TRAY_PRSNT8_N_BUF_R",
+ "TRAY_PRSNT9_N_BUF_R", "TRAY_PRSNT10_N_BUF_R",
+ "TRAY_PRSNT11_N_BUF_R", "TRAY_PRSNT12_N_BUF_R",
+ "TRAY_PRSNT13_N_BUF_R", "TRAY_PRSNT14_N_BUF_R",
+ "TRAY_PRSNT15_N_BUF_R", "TRAY_PRSNT16_N_BUF_R";
+ };
+
+ legacy_prsnt_io_expander1: gpio@12 {
+ compatible = "nxp,pca9555";
+ reg = <0x12>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <40 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_PRSNT17_N_BUF_R", "TRAY_PRSNT18_N_BUF_R",
+ "TRAY_PRSNT19_N_BUF_R", "TRAY_PRSNT20_N_BUF_R",
+ "TRAY_PRSNT21_N_BUF_R", "TRAY_PRSNT22_N_BUF_R",
+ "TRAY_PRSNT23_N_BUF_R", "TRAY_PRSNT24_N_BUF_R",
+ "TRAY_PRSNT25_N_BUF_R", "TRAY_PRSNT26_N_BUF_R",
+ "TRAY_PRSNT27_N_BUF_R", "TRAY_PRSNT28_N_BUF_R",
+ "TRAY_PRSNT29_N_BUF_R", "TRAY_PRSNT30_N_BUF_R",
+ "TRAY_PRSNT31_N_BUF_R", "TRAY_PRSNT32_N_BUF_R";
+ };
+
+ legacy_prsnt_io_expander2: gpio@13 {
+ compatible = "nxp,pca9555";
+ reg = <0x13>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <40 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_PRSNT33_N_BUF_R", "TRAY_PRSNT34_N_BUF_R",
+ "TRAY_PRSNT35_N_BUF_R", "TRAY_PRSNT36_N_BUF_R",
+ "TRAY_PRSNT37_N_BUF_R", "TRAY_PRSNT38_N_BUF_R",
+ "TRAY_PRSNT39_N_BUF_R", "TRAY_PRSNT40_N_BUF_R",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ power-monitor@14 {
+ compatible = "infineon,xdp710";
+ reg = <0x14>;
+ };
+
+ legacy_pwrgd_io_expander1: gpio@15 {
+ compatible = "nxp,pca9555";
+ reg = <0x15>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_PWRGD17_N_BUF_R", "TRAY_PWRGD18_N_BUF_R",
+ "TRAY_PWRGD19_N_BUF_R", "TRAY_PWRGD20_N_BUF_R",
+ "TRAY_PWRGD21_N_BUF_R", "TRAY_PWRGD22_N_BUF_R",
+ "TRAY_PWRGD23_N_BUF_R", "TRAY_PWRGD24_N_BUF_R",
+ "TRAY_PWRGD25_N_BUF_R", "TRAY_PWRGD26_N_BUF_R",
+ "TRAY_PWRGD27_N_BUF_R", "TRAY_PWRGD28_N_BUF_R",
+ "TRAY_PWRGD29_N_BUF_R", "TRAY_PWRGD30_N_BUF_R",
+ "TRAY_PWRGD31_N_BUF_R", "TRAY_PWRGD32_N_BUF_R";
+ };
+
+ legacy_pwrgd_io_expander2: gpio@16 {
+ compatible = "nxp,pca9555";
+ reg = <0x16>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_PWRGD33_N_BUF_R", "TRAY_PWRGD34_N_BUF_R",
+ "TRAY_PWRGD35_N_BUF_R", "TRAY_PWRGD36_N_BUF_R",
+ "TRAY_PWRGD37_N_BUF_R", "TRAY_PWRGD38_N_BUF_R",
+ "TRAY_PWRGD39_N_BUF_R", "TRAY_PWRGD40_N_BUF_R",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ legacy_leak_io_expander0: gpio@17 {
+ compatible = "nxp,pca9555";
+ reg = <0x17>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <46 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_LEAK_DETECT1_N_BUF_R", "TRAY_LEAK_DETECT2_N_BUF_R",
+ "TRAY_LEAK_DETECT3_N_BUF_R", "TRAY_LEAK_DETECT4_N_BUF_R",
+ "TRAY_LEAK_DETECT5_N_BUF_R", "TRAY_LEAK_DETECT6_N_BUF_R",
+ "TRAY_LEAK_DETECT7_N_BUF_R", "TRAY_LEAK_DETECT8_N_BUF_R",
+ "TRAY_LEAK_DETECT9_N_BUF_R", "TRAY_LEAK_DETECT10_N_BUF_R",
+ "TRAY_LEAK_DETECT11_N_BUF_R", "TRAY_LEAK_DETECT12_N_BUF_R",
+ "TRAY_LEAK_DETECT13_N_BUF_R", "TRAY_LEAK_DETECT14_N_BUF_R",
+ "TRAY_LEAK_DETECT15_N_BUF_R", "TRAY_LEAK_DETECT16_N_BUF_R";
+ };
+
+ legacy_leak_io_expander1: gpio@18 {
+ compatible = "nxp,pca9555";
+ reg = <0x18>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <46 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_LEAK_DETECT17_N_BUF_R", "TRAY_LEAK_DETECT18_N_BUF_R",
+ "TRAY_LEAK_DETECT19_N_BUF_R", "TRAY_LEAK_DETECT20_N_BUF_R",
+ "TRAY_LEAK_DETECT21_N_BUF_R", "TRAY_LEAK_DETECT22_N_BUF_R",
+ "TRAY_LEAK_DETECT23_N_BUF_R", "TRAY_LEAK_DETECT24_N_BUF_R",
+ "TRAY_LEAK_DETECT25_N_BUF_R", "TRAY_LEAK_DETECT26_N_BUF_R",
+ "TRAY_LEAK_DETECT27_N_BUF_R", "TRAY_LEAK_DETECT28_N_BUF_R",
+ "TRAY_LEAK_DETECT29_N_BUF_R", "TRAY_LEAK_DETECT30_N_BUF_R",
+ "TRAY_LEAK_DETECT31_N_BUF_R", "TRAY_LEAK_DETECT32_N_BUF_R";
+ };
+
+ legacy_leak_io_expander2: gpio@19 {
+ compatible = "nxp,pca9555";
+ reg = <0x19>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <46 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_LEAK_DETECT33_N_BUF_R", "TRAY_LEAK_DETECT34_N_BUF_R",
+ "TRAY_LEAK_DETECT35_N_BUF_R", "TRAY_LEAK_DETECT36_N_BUF_R",
+ "TRAY_LEAK_DETECT37_N_BUF_R", "TRAY_LEAK_DETECT38_N_BUF_R",
+ "TRAY_LEAK_DETECT39_N_BUF_R", "TRAY_LEAK_DETECT40_N_BUF_R",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ legacy_small_leak_io_expander0: gpio@1a {
+ compatible = "nxp,pca9555";
+ reg = <0x1a>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_SMALL_LEAK1_N_BUF_R", "TRAY_SMALL_LEAK2_N_BUF_R",
+ "TRAY_SMALL_LEAK3_N_BUF_R", "TRAY_SMALL_LEAK4_N_BUF_R",
+ "TRAY_SMALL_LEAK5_N_BUF_R", "TRAY_SMALL_LEAK6_N_BUF_R",
+ "TRAY_SMALL_LEAK7_N_BUF_R", "TRAY_SMALL_LEAK8_N_BUF_R",
+ "TRAY_SMALL_LEAK9_N_BUF_R", "TRAY_SMALL_LEAK10_N_BUF_R",
+ "TRAY_SMALL_LEAK11_N_BUF_R", "TRAY_SMALL_LEAK12_N_BUF_R",
+ "TRAY_SMALL_LEAK13_N_BUF_R", "TRAY_SMALL_LEAK14_N_BUF_R",
+ "TRAY_SMALL_LEAK15_N_BUF_R", "TRAY_SMALL_LEAK16_N_BUF_R";
+ };
+
+ legacy_small_leak_io_expander1: gpio@1b {
+ compatible = "nxp,pca9555";
+ reg = <0x1b>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_SMALL_LEAK17_N_BUF_R", "TRAY_SMALL_LEAK18_N_BUF_R",
+ "TRAY_SMALL_LEAK19_N_BUF_R", "TRAY_SMALL_LEAK20_N_BUF_R",
+ "TRAY_SMALL_LEAK21_N_BUF_R", "TRAY_SMALL_LEAK22_N_BUF_R",
+ "TRAY_SMALL_LEAK23_N_BUF_R", "TRAY_SMALL_LEAK24_N_BUF_R",
+ "TRAY_SMALL_LEAK25_N_BUF_R", "TRAY_SMALL_LEAK26_N_BUF_R",
+ "TRAY_SMALL_LEAK27_N_BUF_R", "TRAY_SMALL_LEAK28_N_BUF_R",
+ "TRAY_SMALL_LEAK29_N_BUF_R", "TRAY_SMALL_LEAK30_N_BUF_R",
+ "TRAY_SMALL_LEAK31_N_BUF_R", "TRAY_SMALL_LEAK32_N_BUF_R";
+ };
+
+ legacy_small_leak_io_expander2: gpio@1c {
+ compatible = "nxp,pca9555";
+ reg = <0x1c>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <44 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_SMALL_LEAK33_N_BUF_R", "TRAY_SMALL_LEAK34_N_BUF_R",
+ "TRAY_SMALL_LEAK35_N_BUF_R", "TRAY_SMALL_LEAK36_N_BUF_R",
+ "TRAY_SMALL_LEAK37_N_BUF_R", "TRAY_SMALL_LEAK38_N_BUF_R",
+ "TRAY_SMALL_LEAK39_N_BUF_R", "TRAY_SMALL_LEAK40_N_BUF_R",
+ "", "",
+ "", "",
+ "", "",
+ "", "";
+ };
+
+ legacy_pwrgd_io_expander0: gpio@28 {
+ compatible = "nxp,pca9555";
+ reg = <0x28>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&sgpiom0>;
+ interrupts = <42 IRQ_TYPE_LEVEL_LOW>;
+
+ gpio-line-names =
+ "TRAY_PWRGD1_N_BUF_R", "TRAY_PWRGD2_N_BUF_R",
+ "TRAY_PWRGD3_N_BUF_R", "TRAY_PWRGD4_N_BUF_R",
+ "TRAY_PWRGD5_N_BUF_R", "TRAY_PWRGD6_N_BUF_R",
+ "TRAY_PWRGD7_N_BUF_R", "TRAY_PWRGD8_N_BUF_R",
+ "TRAY_PWRGD9_N_BUF_R", "TRAY_PWRGD10_N_BUF_R",
+ "TRAY_PWRGD11_N_BUF_R", "TRAY_PWRGD12_N_BUF_R",
+ "TRAY_PWRGD13_N_BUF_R", "TRAY_PWRGD14_N_BUF_R",
+ "TRAY_PWRGD15_N_BUF_R", "TRAY_PWRGD16_N_BUF_R";
+ };
+
+ adc@35 {
+ compatible = "maxim,max11617";
+ reg = <0x35>;
+ };
+
+ power-monitor@44 {
+ compatible = "lltc,ltc4287";
+ reg = <0x44>;
+ shunt-resistor-micro-ohms = <500>;
+ };
+
+ adc@48 {
+ compatible = "ti,ads1015";
+ reg = <0x48>;
+ };
+
+ temp-sensor@4c {
+ compatible = "ti,tmp75";
+ reg = <0x4c>;
+ };
+
+ temp-sensor@4d {
+ compatible = "ti,tmp75";
+ reg = <0x4d>;
+ };
+
+ temp-sensor@4e {
+ compatible = "ti,tmp75";
+ reg = <0x4e>;
+ };
+
+ power-monitor@4f {
+ compatible = "ti,ina230";
+ reg = <0x4f>;
+ shunt-resistor = <1000>;
+ };
+
+ power-monitor@69 {
+ compatible = "pmbus";
+ reg = <0x69>;
+ };
+
+ fpga_io_expander64: gpio@64 {
+ compatible = "nxp,pca9555";
+ reg = <0x64>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "", "",
+ "", "",
+ "", "",
+ "LEAK_CONFIG0", "LEAK_CONFIG1",
+ "FPGA_PWRGD_P24V_AUX_R", "FPGA_PWRGD_P24V_AUX_2_R",
+ "FPGA_PWRGD_P12V_SCM_R", "FPGA_PWRGD_P12V_AUX_R2",
+ "FPGA_PRSNT_FANBP_0_SIG_R_PLD_N", "FPGA_PRSNT_FANBP_0_PWR_R_PLD_N",
+ "FPGA_P24V_AUX_INA230_ALERT_N_R", "FPGA_SMB_TMC75_TEMP_ALERT_N_R";
+ };
+
+ fpga_io_expander65: gpio@65 {
+ compatible = "nxp,pca9555";
+ reg = <0x65>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "FPGA_PCI_DIS_N", "FPGA_DEV_DIS_N",
+ "FPGA_PWRGD_P3V3_AUX_R", "FPGA_PWRGD_P5V_AUX_R2",
+ "FPGA_PWRGD_P1V05_AUX_R", "FPGA_P48V_HSC_ALERT_N",
+ "FPGA_PWRGD_P1V5_AUX_R", "FPGA_PWRGD_P52V_HSC_PWROK_R",
+ "FPGA_R_COME_THERMTRIP_L", "FPGA_PRSNT_POE_SIG_PLD_N",
+ "FPGA_PRSNT_POE_PWR_PLD_N", "FPGA_PRSNT_RIO_RACKMON_N",
+ "FPGA_PRSNT_CAN2_MCIO_N", "FPGA_PRSNT_CAN1_MCIO_N",
+ "FPGA_PRSNT_RACKMON_MCIO_N", "FPGA_PRSNT_AALC_MCIO_N";
+ };
+
+ fpga_io_expander66: gpio@66 {
+ compatible = "nxp,pca9555";
+ reg = <0x66>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "FPGA_R_FM_CPU_ERR0_LVT3_L", "FPGA_FPGA_R_FM_PCHHOT_L",
+ "FPGA_R_FM_BIOS_POST_CMPLT_L", "FPGA_R_FM_SOC_BMC_RST_L",
+ "FPGA_R_CPU_MSMI_CATERR_N", "FPGA_R_H_MEMHOT_OUT_FET_L",
+ "FPGA_R_PWRGD_P3V3_STBY", "FPGA_R_PWRGD_PCH_PWROK",
+ "FPGA_TRAY23_PWRGD_BUF_R", "FPGA_TRAY24_PWRGD_BUF_R",
+ "FPGA_P24V_AUX_2_INA230_ALERT_N_R", "FPGA_R_IRQ_BMC_PCH_SMI_N",
+ "FPGA_R_FM_CPU_DIMM_EVENT_COD_BUF", "FPGA_R_BIOS_MSG_DIS_L",
+ "FPGA_R_ISO_FM_USB_OC0_L", "FPGA_SPI_LVC_EN";
+ };
+
+ fpga_io_expander67: gpio@67 {
+ compatible = "nxp,pca9555";
+ reg = <0x67>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ gpio-line-names =
+ "FPGA_TRAY29_PWRGD_BUF_R", "FPGA_TRAY30_PWRGD_BUF_R",
+ "FPGA_TRAY31_PWRGD_BUF_R", "FPGA_TRAY32_PWRGD_BUF_R",
+ "FPGA_TRAY37_PWRGD_BUF_R", "FPGA_TRAY38_PWRGD_BUF_R",
+ "FPGA_TRAY39_PWRGD_BUF_R", "FPGA_TRAY40_PWRGD_BUF_R",
+ "FPGA_ISO_CARRIER_BOARD_PWR_OK", "FPGA_UART_MUX_SEL",
+ "", "",
+ "", "",
+ "", "";
+ };
+};
+
+&i2c11 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ i2c11mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c11mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c11mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c11mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c11mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c11mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c11mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c11mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c12 {
+ status = "okay";
+ bus-frequency = <400000>;
+};
+
+&i2c13 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ i2c13mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c13mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c13mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c13mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c13mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c13mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c13mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c13mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&i2c14 {
+ status = "okay";
+};
+
+&i2c15 {
+ status = "okay";
+
+ i2c-mux@77 {
+ compatible = "nxp,pca9548";
+ reg = <0x77>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ i2c-mux-idle-disconnect;
+
+ i2c15mux0ch0: i2c@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ status = "okay";
+ };
+
+ i2c15mux0ch1: i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+ status = "okay";
+ };
+
+ i2c15mux0ch2: i2c@2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <2>;
+ status = "okay";
+ };
+
+ i2c15mux0ch3: i2c@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ status = "okay";
+ };
+
+ i2c15mux0ch4: i2c@4 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <4>;
+ status = "okay";
+ };
+
+ i2c15mux0ch5: i2c@5 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <5>;
+ status = "okay";
+ };
+
+ i2c15mux0ch6: i2c@6 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <6>;
+ status = "okay";
+ };
+
+ i2c15mux0ch7: i2c@7 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <7>;
+ status = "okay";
+ };
+ };
+};
+
+&kcs3 {
+ aspeed,lpc-io-reg = <0xca2>;
+ status = "okay";
+};
+
+&lpc_ctrl {
+ status = "okay";
+};
+
+&mac2 {
+ status = "okay";
+ phy-mode = "rmii";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii3_default>;
+
+ /*
+ * The Marvell 88E6393X is initialized at boot via EEPROM
+ * configuration and hardware straps.
+ * The BMC connects via an RMII fixed-link; link parameters are fixed
+ * by board design.
+ */
+ fixed-link {
+ speed = <100>;
+ full-duplex;
+ };
+};
+
+&mac3 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rmii4_default>;
+ use-ncsi;
+};
+
+&peci0 {
+ status = "okay";
+};
+
+&sgpiom0 {
+ status = "okay";
+ ngpios = <128>;
+ bus-frequency = <100000>;
+ gpio-line-names =
+ /*"input pin","output pin"*/
+ /*A0 - A7*/
+ "power-chassis-good","FM_PLD_HEARTBEAT_LVC3_R",
+ "host0-ready","R_BMC_PTH_RST_BTN_L",
+ "CONTROL_VT2_SUPPLY1_CLOSE","FM_MDIO_SW_SEL_PLD",
+ "CONTROL_VT2_SUPPLY2_CLOSE","FM_88E6393X_BIN_UPDATE_EN_N",
+ "CONTROL_VT2_SUPPLY3_CLOSE","Sequence_TransFR_Alert",
+ "RETURN_CNTL1_FB","WATER_VALVE1_OPEN",
+ "RETURN_CNTL2_FB","WATER_VALVE2_OPEN",
+ "RETURN_CNTL3_FB","WATER_VALVE3_OPEN",
+ /*B0 - B7*/
+ "IT_STOP_PUMP_R_CPLD","WATER_VALVE1_CLOSE",
+ "IT_STOP_PUMP_SPARE_R_CPLD","WATER_VALVE2_CLOSE",
+ "IT_STOP_PUMP_2_R_CPLD","WATER_VALVE3_CLOSE",
+ "IT_STOP_PUMP_SPARE_2_R_CPLD","REPORT_VT2_SUPPLY1_CLOSE",
+ "RPU_2_READY_SPARE_PLD_R","REPORT_VT2_SUPPLY2_CLOSE",
+ "RPU_2_READY_PLD_R","REPORT_VT2_SUPPLY3_CLOSE",
+ "RPU_READY_SPARE_PLD_R","PCIE_SSD1_PRSNT_N",
+ "RPU_READY_PLD_R","",
+ /*C0 - C7*/
+ "IOEXP8_INT_N","",
+ "SUPPLY_CNTL1_FB","",
+ "SUPPLY_CNTL2_FB","",
+ "SUPPLY_CNTL3_FB","",
+ "PRSNT_TRAY1_TO_40_R_BUF_N","",
+ "PWRGD_TRAY1_TO_40_R_BUF","",
+ "SMALL_LEAK_TRAY1_TO_40_R_BUF_N","",
+ "LEAK_DETECT_TRAY1_TO_40_R_BUF_N","",
+ /*D0 - D7*/
+ "PRSNT_CANBUSP1_TRAY1_TO_32_N","",
+ "PWRGD_CANBUSP1_TRAY1_TO_32_PWROK","",
+ "SMALL_LEAK_CANBUSP1_TRAY1_TO_32_N","",
+ "LEAK_DETECT_CANBUSP1_TRAY1_TO_32_N","",
+ "PRSNT_CANBUSP2_TRAY1_TO_32_N","",
+ "PWRGD_CANBUSP2_TRAY1_TO_32_PWROK","",
+ "SMALL_LEAK_CANBUSP2_TRAY1_TO_32_N","",
+ "LEAK_DETECT_CANBUSP2_TRAY1_TO_32_N","",
+ /*E0 - E7*/
+ "PRSNT_CANBUSP3_TRAY1_TO_32_N","",
+ "PWRGD_CANBUSP3_TRAY1_TO_32_PWROK","",
+ "SMALL_LEAK_CANBUSP3_TRAY1_TO_32_N","",
+ "LEAK_DETECT_CANBUSP3_TRAY1_TO_32_N","",
+ "PRSNT_CANBUSP4_TRAY1_TO_32_N","",
+ "PWRGD_CANBUSP4_TRAY1_TO_32_PWROK","",
+ "SMALL_LEAK_CANBUSP4_TRAY1_TO_32_N","",
+ "LEAK_DETECT_CANBUSP4_TRAY1_TO_32_N","",
+ /*F0 - F7*/
+ "PRSNT_CANBUSP5_TRAY1_TO_32_N","",
+ "PWRGD_CANBUSP5_TRAY1_TO_32_PWROK","",
+ "SMALL_LEAK_CANBUSP5_TRAY1_TO_32_N","",
+ "LEAK_DETECT_CANBUSP5_TRAY1_TO_32_N","",
+ "PRSNT_CANBUSP6_TRAY1_TO_32_N","",
+ "PWRGD_CANBUSP6_TRAY1_TO_32_PWROK","",
+ "SMALL_LEAK_CANBUSP6_TRAY1_TO_32_N","",
+ "LEAK_DETECT_CANBUSP6_TRAY1_TO_32_N","",
+ /*G0 - G7*/
+ "PRSNT_CANBUSP7_TRAY1_TO_32_N","",
+ "PWRGD_CANBUSP7_TRAY1_TO_32_PWROK","",
+ "SMALL_LEAK_CANBUSP7_TRAY1_TO_32_N","",
+ "LEAK_DETECT_CANBUSP7_TRAY1_TO_32_N","",
+ "PRSNT_CANBUSP8_TRAY1_TO_32_N","",
+ "PWRGD_CANBUSP8_TRAY1_TO_32_PWROK","",
+ "SMALL_LEAK_CANBUSP8_TRAY1_TO_32_N","",
+ "LEAK_DETECT_CANBUSP8_TRAY1_TO_32_N","",
+ /*H0 - H7*/
+ "CHASSIS0_LEAK_Q_N_R","",
+ "CHASSIS1_LEAK_Q_N_R","",
+ "CHASSIS2_LEAK_Q_N_R","",
+ "CHASSIS3_LEAK_Q_N_R","",
+ "CHASSIS4_LEAK_Q_N_R","",
+ "CHASSIS5_LEAK_Q_N_R","",
+ "CHASSIS6_LEAK_Q_N_R","",
+ "CHASSIS7_LEAK_Q_N_R","",
+ /*I0 - I7*/
+ "CHASSIS8_LEAK_Q_N_R","",
+ "CHASSIS9_LEAK_Q_N_R","",
+ "CHASSIS10_LEAK_Q_N_R","",
+ "CHASSIS11_LEAK_Q_N_R","",
+ "AALC_RPU_READY","",
+ "","",
+ "","",
+ "","",
+ /*J0 - J7*/
+ "","",
+ "","",
+ "","",
+ "","",
+ "","",
+ "","",
+ "","",
+ "","",
+ /*K0 - K7*/
+ "","",
+ "","",
+ "","",
+ "","",
+ "","",
+ "","",
+ "","",
+ "","",
+ /*L0 - L7*/
+ "IT_GEAR_RPU_2_LINK_PRSNT_SPARE_N_R","",
+ "IT_GEAR_RPU_2_LINK_PRSNT_N_R","",
+ "IT_GEAR_RPU_LINK_PRSNT_SPARE_N_R","",
+ "IT_GEAR_RPU_LINK_PRSNT_N_R","",
+ "","",
+ "","",
+ "","",
+ "","",
+ /*M0 - M7*/
+ "","",
+ "","",
+ "PRSNT_SENSOR_N","",
+ "PRSNT3_VT2_PLD_N","",
+ "PRSNT2_VT2_PLD_N","",
+ "PRSNT1_VT2_PLD_N","",
+ "PRSNT3_RETURN_PLD_N","",
+ "PRSNT2_RETURN_PLD_N","",
+ /*N0 - N7*/
+ "PRSNT1_RETURN_PLD_N","",
+ "PRSNT3_SUPPLY_PLD_N","",
+ "PRSNT2_SUPPLY_PLD_N","",
+ "PRSNT1_SUPPLY_PLD_N","",
+ "PRSNT_LEAK11_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK10_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK9_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK8_SENSOR_R_PLD_N","",
+ /*O0 - O7*/
+ "PRSNT_LEAK7_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK6_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK5_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK4_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK3_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK2_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK1_SENSOR_R_PLD_N","",
+ "PRSNT_LEAK0_SENSOR_R_PLD_N","",
+ /*P0 - P7*/
+ "","",
+ "","",
+ "","",
+ "","",
+ "","SGPIO_REG_VALID_0",
+ "","SGPIO_REG_VALID_1",
+ "","SGPIO_REG_VALID_2",
+ "","SGPIO_REG_VALID_3";
+};
+
+&spi2 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_spi2_default &pinctrl_spi2cs1_default>;
+
+ flash@0 {
+ status = "okay";
+ m25p,fast-read;
+ label = "pnor";
+ spi-max-frequency = <12000000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ };
+
+ flash@1 {
+ status = "okay";
+ m25p,fast-read;
+ label = "e810";
+ spi-max-frequency = <12000000>;
+ spi-tx-bus-width = <2>;
+ spi-rx-bus-width = <2>;
+ };
+};
+
+&uart3 {
+ status = "okay";
+};
+
+&wdt1 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdtrst1_default>;
+ aspeed,reset-type = "soc";
+ aspeed,external-signal;
+ aspeed,ext-push-pull;
+ aspeed,ext-active-high;
+ aspeed,ext-pulse-duration = <256>;
+};
+
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio irq property
From: Xianwei Zhao @ 2026-06-15 2:47 UTC (permalink / raw)
To: Conor Dooley
Cc: Linus Walleij, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Neil Armstrong, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
linux-amlogic, linux-gpio, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260611-ungloved-snowplow-522e7c0b7a51@spud>
Hi Conor,
Thanks for your review.
On 2026/6/12 01:39, Conor Dooley wrote:
> Subject:
> Re: [PATCH RFC 1/2] dt-bindings: pinctl: amlogic,pinctrl-a4: Add gpio
> irq property
> From:
> Conor Dooley <conor@kernel.org>
> Date:
> 2026/6/12 01:39
>
> To:
> xianwei.zhao@amlogic.com
> CC:
> Linus Walleij <linusw@kernel.org>, Rob Herring <robh@kernel.org>,
> Krzysztof Kozlowski <krzk+dt@kernel.org>, Conor Dooley
> <conor+dt@kernel.org>, Neil Armstrong <neil.armstrong@linaro.org>, Kevin
> Hilman <khilman@baylibre.com>, Jerome Brunet <jbrunet@baylibre.com>,
> Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
> linux-amlogic@lists.infradead.org, linux-gpio@vger.kernel.org,
> devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-arm-kernel@lists.infradead.org
>
>
>
> On Thu, Jun 11, 2026 at 07:54:33AM +0000, Xianwei Zhao via B4 Relay wrote:
>> From: Xianwei Zhao<xianwei.zhao@amlogic.com>
>>
>> Add the hw-irq property for each GPIO bank and enable interrupt-parent
>> for pinctrl so that gpiod_to_irq() can translate GPIO lines to IRQs.
> Uhhhhh, what? Why can't you just use the normal interrupts property?
>
The interrupt cannot be used directly because the GPIO bank only
provides an IRQ base, which does not have a one-to-one mapping with the
actual hardware interrupts.
On Amlogic SoCs, GPIO interrupts are handled through a mux. Multiple
GPIO pins are mapped to a limited number of real interrupt sources. The
implementation can be found here:
https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-meson-gpio.c
To use a GPIO interrupt, an unused hardware interrupt must first be
allocated, and then the corresponding mux register must be configured.
This allocation and mapping are already implemented in the existing driver.
In that driver, the mapping is performed dynamically rather than simply
calculating:
irq = irq_start + gpio_offset
If the interrupt is used directly, only the GPIO index can be obtained.
The real interrupt number cannot be derived by simply adding an offset,
because the hardware interrupt must be allocated first. Pre-allocating
all interrupts during initialization would prevent later GPIOs from
obtaining available interrupt sources.
Perhaps other names would be more appropriate here, such as "irq_start".
>> Signed-off-by: Xianwei Zhao<xianwei.zhao@amlogic.com>
>> ---
>> Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
>> index b69db1b95345..65ec9121300e 100644
>> --- a/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
>> +++ b/Documentation/devicetree/bindings/pinctrl/amlogic,pinctrl-a4.yaml
>> @@ -37,6 +37,8 @@ properties:
>>
>> ranges: true
>>
>> + interrupt-parent: true
>> +
>> patternProperties:
>> "^gpio@[0-9a-f]+$":
>> type: object
>> @@ -65,6 +67,9 @@ patternProperties:
>> gpio-ranges:
>> maxItems: 1
>>
>> + hw-irq:
>> + $ref: /schemas/types.yaml#/definitions/uint32
>> +
>> required:
>> - reg
>> - reg-names
>>
>> --
>> 2.52.0
^ permalink raw reply
* Re: [net-next v1 2/6] net: stmmac: Checking whether priv->phylink if NULL in NCSI case
From: Minda Chen @ 2026-06-15 1:25 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Jose Abreu, Maxime Coquelin, Russell King,
Giuseppe Cavallaro, Alexandre Torgue, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
devicetree@vger.kernel.org
In-Reply-To: <f3a32c42-27b2-496f-b236-02c33bee1773@lunn.ch>
>
> > +static inline bool stmmac_phylink_expects_phy(struct phylink *link) {
> > + if (link)
> > + return phylink_expects_phy(link);
> > +
> > + return false;
> > +}
> > +
> > +static inline int stmmac_phylink_pcs_pre_init(struct phylink *link,
> > +struct phylink_pcs *pcs) {
> > + if (link)
> > + return phylink_pcs_pre_init(link, pcs);
> > +
> > + return 0;
> > +}
> > +
> > +static inline void stmmac_phylink_start(struct phylink *link) {
> > + if (link)
> > + phylink_start(link);
> > +}
> > +
> > +static inline void stmmac_phylink_stop(struct phylink *link) {
> > + if (link)
> > + phylink_stop(link);
> > +}
>
> Please take a step back and think about the Linux big picture architecture.
>
> What is stmmac specific here? If you were to add NCSI support to another driver
> which uses phylink, would it need to replicate all this?
>
> When you consider how the MAC is configured, does it need to know it is
> connected to an NCSI? Can the MAC tell the difference between NSCI, fixed-link,
> a PHY or an SFP? Or does the MAC just need to know RGMII, the link is up, send
> frames?
>
> Please look at adding generic support for NSCI in phylink, and see if the existing
> phylink mac ops covers everything needed for configuring the MAC.
>
> Andrew
Thanks. I will try to use fix-PHY link.
^ permalink raw reply
* [PATCH v2 0/2] hwmon: (pmbus/lm25066) Support SMBus Current Limit configuration
From: Potin Lai @ 2026-06-15 3:07 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Zev Weiss
Cc: linux-hwmon, devicetree, linux-kernel, Cosmo Chou, Mike Hsieh,
Potin Lai, Potin Lai
This series adds support for configuring the current limit behavior via
software override on LM25066-compatible devices (excluding LM25056) using
the DEVICE_SETUP (0xD9) register.
When the 'ti,current-limit' property is specified in the device tree,
the driver configures the DEVICE_SETUP register's Current Limit Configuration
bit (bit 2) to activate SMBus/software override and sets the Current Limit
Setting bit (bit 4) to "low" or "high" threshold accordingly.
Since LM25056 does not support software override (bit 2 of DEVICE_SETUP is
reserved), it is explicitly excluded from this support in both the device
tree binding schema and the driver.
---
Changes in v2:
- Replaced the boolean properties ('ti,cl-smbus-high' and 'ti,cl-smbus-low')
with a single string property 'ti,current-limit' ('low' or 'high')
- Excluded lm25056 in the driver from parsing/setting the current limit property.
- Link to v1: https://patch.msgid.link/20260611-lm25066-cl-config-v1-0-02e567bf3d91@gmail.com
To: Guenter Roeck <linux@roeck-us.net>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Zev Weiss <zev@bewilderbeest.net>
Cc: linux-hwmon@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Cosmo Chou <cosmo.chou@quantatw.com>
Cc: Mike Hsieh <Mike_Hsieh@quantatw.com>
Cc: Potin Lai <potin.lai@quantatw.com>
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
---
Potin Lai (2):
dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
hwmon: (pmbus/lm25066) add current limit configuration support
.../bindings/hwmon/pmbus/ti,lm25066.yaml | 18 +++++++++++
drivers/hwmon/pmbus/lm25066.c | 37 ++++++++++++++++++++++
2 files changed, 55 insertions(+)
---
base-commit: 05f7e89ab9731565d8a62e3b5d1ec206485eeb0b
change-id: 20260611-lm25066-cl-config-f81925f7337e
Best regards,
--
Potin Lai <potin.lai.pt@gmail.com>
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Potin Lai @ 2026-06-15 3:07 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Zev Weiss
Cc: linux-hwmon, devicetree, linux-kernel, Cosmo Chou, Mike Hsieh,
Potin Lai, Potin Lai
In-Reply-To: <20260615-lm25066-cl-config-v2-0-59be46e67d5a@gmail.com>
Add a 'ti,current-limit' string property to configure the device's Current
Limit (CL) behavior to "high" or "low".
LM25056 does not support setting the current limit via software, so
disallow this property for it.
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
---
.../devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
index a20f140dc79a..53ee98e871ff 100644
--- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
@@ -46,12 +46,30 @@ properties:
additionalProperties: false
+ ti,current-limit:
+ description: |
+ Configure the current limit setting. When present, this property
+ overrides the hardware setting of the physical CL pin by configuring
+ the register.
+ $ref: /schemas/types.yaml#/definitions/string
+ enum:
+ - low
+ - high
+
required:
- compatible
- reg
allOf:
- $ref: /schemas/hwmon/hwmon-common.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: ti,lm25056
+ then:
+ properties:
+ ti,current-limit: false
unevaluatedProperties: false
--
2.52.0
^ permalink raw reply related
* [PATCH v2 2/2] hwmon: (pmbus/lm25066) add current limit configuration support
From: Potin Lai @ 2026-06-15 3:07 UTC (permalink / raw)
To: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Zev Weiss
Cc: linux-hwmon, devicetree, linux-kernel, Cosmo Chou, Mike Hsieh,
Potin Lai, Potin Lai
In-Reply-To: <20260615-lm25066-cl-config-v2-0-59be46e67d5a@gmail.com>
Add support for the 'ti,current-limit' devicetree property. When
present, this property overrides the hardware configuration pins via the
DEVICE_SETUP (0xD9) register to set the Current Limit Configuration bit
(bit 2) and Current Limit Setting bit (bit 4) to "high" or "low".
The Bit 4 mapping to High/Low current limit is handled dynamically on
probe because it is swapped for lm25066 compared to other supported
chips (lm5064, lm5066, and lm5066i).
LM25056 is excluded since it does not support configuring the current
limit via software (bit 2 of DEVICE_SETUP register is reserved).
Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
---
drivers/hwmon/pmbus/lm25066.c | 37 +++++++++++++++++++++++++++++++++++++
1 file changed, 37 insertions(+)
diff --git a/drivers/hwmon/pmbus/lm25066.c b/drivers/hwmon/pmbus/lm25066.c
index dd7275a67a0a..c8e7aa7c3acd 100644
--- a/drivers/hwmon/pmbus/lm25066.c
+++ b/drivers/hwmon/pmbus/lm25066.c
@@ -34,6 +34,7 @@ enum chips { lm25056, lm25066, lm5064, lm5066, lm5066i };
#define LM25066_READ_AVG_PIN 0xdf
#define LM25066_DEV_SETUP_CL BIT(4) /* Current limit */
+#define LM25066_DEV_SETUP_CL_CFG BIT(2) /* Current limit configuration */
#define LM25066_SAMPLES_FOR_AVG_MAX 4096
@@ -484,6 +485,42 @@ static int lm25066_probe(struct i2c_client *client)
data->id = (enum chips)(unsigned long)i2c_get_match_data(client);
+ if (data->id != lm25056) {
+ int config_new = config;
+ const char *cl_setting;
+ int ret;
+
+ if (!of_property_read_string(client->dev.of_node,
+ "ti,current-limit", &cl_setting)) {
+ config_new |= LM25066_DEV_SETUP_CL_CFG;
+ if (strcmp(cl_setting, "high") == 0) {
+ if (data->id == lm25066)
+ config_new |= LM25066_DEV_SETUP_CL;
+ else
+ config_new &= ~LM25066_DEV_SETUP_CL;
+ } else if (strcmp(cl_setting, "low") == 0) {
+ if (data->id == lm25066)
+ config_new &= ~LM25066_DEV_SETUP_CL;
+ else
+ config_new |= LM25066_DEV_SETUP_CL;
+ } else {
+ dev_err(&client->dev,
+ "invalid current-limit setting: %s\n",
+ cl_setting);
+ return -EINVAL;
+ }
+ }
+
+ if (config_new != config) {
+ ret = i2c_smbus_write_byte_data(client,
+ LM25066_DEVICE_SETUP,
+ config_new);
+ if (ret < 0)
+ return ret;
+ config = config_new;
+ }
+ }
+
info = &data->info;
info->pages = 1;
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: sashiko-bot @ 2026-06-15 3:16 UTC (permalink / raw)
To: Potin Lai; +Cc: conor+dt, linux-hwmon, robh, devicetree
In-Reply-To: <20260615-lm25066-cl-config-v2-1-59be46e67d5a@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Device Tree Schema Type Conflict: The new `ti,current-limit` property is defined as a string, which conflicts with its existing global definition as a `uint32`.
--
commit 2d0e259557c772018da03b728b427c7fa9a267ca
Author: Potin Lai <potin.lai.pt@gmail.com>
dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
This commit adds a 'ti,current-limit' string property to configure the
device's Current Limit (CL) behavior to "high" or "low". It also disables
this property for the LM25056 variant, which does not support software
configuration for the current limit.
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> index a20f140dc79a6..53ee98e871ffc 100644
> --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> @@ -46,12 +46,30 @@ properties:
>
> additionalProperties: false
>
> + ti,current-limit:
> + description: |
> + Configure the current limit setting. When present, this property
> + overrides the hardware setting of the physical CL pin by configuring
> + the register.
> + $ref: /schemas/types.yaml#/definitions/string
> + enum:
> + - low
> + - high
[Severity: Low]
Does this introduce a global schema type conflict?
Device Tree schema tooling requires property names to have consistent primitive
types globally. The property ti,current-limit is already defined as a uint32 in
other Texas Instruments bindings (such as power/supply/bq2415x.yaml).
Redefining it here as a string breaks make dt_binding_check validation. Would
it be possible to rename this property (for example, ti,current-limit-setting)
to resolve the collision?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-lm25066-cl-config-v2-0-59be46e67d5a@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH RFC 0/2] pinctrl: Add support gpiod_to_irq
From: Xianwei Zhao @ 2026-06-15 3:17 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, linux-amlogic,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <CAD++jLk3YdMUSkk71rgT=taQZnEhqgMgGP0dKBPx7_5Bsxmu+g@mail.gmail.com>
Hi Linus,
Thank you for your advice and review.
On 2026/6/11 20:51, Linus Walleij wrote:
> Hi Xianwei,
>
> thanks for your patches!
>
> On Thu, Jun 11, 2026 at 9:54 AM Xianwei Zhao via B4 Relay
> <devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
>
>> Some users need to obtain an IRQ directly from a GPIO descriptor through gpiod_to_irq().
>> Add the required DT binding and implementation to support this use case.
>> Since this introduces a new DT property, the property is kept optional to
>> maintain compatibility with existing SoCs and DTS files.
> To me it looks like you have just re-implemented hierarchical
> irqs.
>
> Look into the section "Infrastructure helpers for GPIO irqchips"
> in Documentation/driver-api/gpio/driver.rst, especially towards
> the end.
>
> Solve this by using GPIOLIB_IRQCHIP and a custom
> child_to_parent_hwirq() callback to translate the GPIO into
> an IRQ.
>
> To just implement gpiod_to_irq() without any irqchip abstraction
> is also broken: you can't force all users to just use this way
> to get an IRQ it's excessively restricting.
>
> Add
>
> interrupt-controller: true
>
> "#interrupt-cells":
> const: 2
>
> to the pinctrl node as well so that DT users can simply request
> the IRQ from the irqchip inside of the pin controller. It will
> be hierarchical and lightweight but an irqchip nevertheless.
>
> The GPIOLIB_IRQCHIP approach will help you to get this
> right.
>
I read the document (Documentation/driver-api/gpio/driver.rst) you
pointed me to and found that the corresponding implementation has
already been added in this file:
https://github.com/torvalds/linux/blob/master/drivers/irqchip/irq-meson-gpio.c
However, it is implemented as a standalone irqchip and is not integrated
with the GPIO controller.
In this patch, I implemented the GPIO-to-IRQ conversion through
gpiod_to_irq(). Users can still obtain the interrupt directly through
the interrupt property, for example:
interrupts-extended = <&gpio_intc 16 1>;
The purpose of this change is to make GPIO-to-IRQ conversion easier for
users who do not want to know the actual interrupt number. The interrupt
mapping is not fixed and varies between different SoCs, so users should
not need to handle the hardware interrupt allocation details.
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 2/2] hwmon: (pmbus/lm25066) add current limit configuration support
From: sashiko-bot @ 2026-06-15 3:21 UTC (permalink / raw)
To: Potin Lai; +Cc: linux-hwmon, robh, devicetree, conor+dt
In-Reply-To: <20260615-lm25066-cl-config-v2-2-59be46e67d5a@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] Telemetry coefficient selection mismatch due to unhandled hardware bit swap for current limit configuration.
--
commit 7163f92448b58cfee498d1fa9089543f75ba9068
Author: Potin Lai <potin.lai.pt@gmail.com>
hwmon: (pmbus/lm25066) add current limit configuration support
This patch adds support for the ti,current-limit devicetree property
to configure the current limit via the DEVICE_SETUP register. It dynamically
handles the Bit 4 mapping for High/Low current limits, which is swapped
for the lm25066 compared to other chips in the family.
> diff --git a/drivers/hwmon/pmbus/lm25066.c b/drivers/hwmon/pmbus/lm25066.c
> index dd7275a67a0ab..c8e7aa7c3acd3 100644
> --- a/drivers/hwmon/pmbus/lm25066.c
> +++ b/drivers/hwmon/pmbus/lm25066.c
[ ... ]
> @@ -484,6 +485,42 @@ static int lm25066_probe(struct i2c_client *client)
>
> data->id = (enum chips)(unsigned long)i2c_get_match_data(client);
>
> + if (data->id != lm25056) {
> + int config_new = config;
> + const char *cl_setting;
> + int ret;
> +
> + if (!of_property_read_string(client->dev.of_node,
> + "ti,current-limit", &cl_setting)) {
> + config_new |= LM25066_DEV_SETUP_CL_CFG;
> + if (strcmp(cl_setting, "high") == 0) {
> + if (data->id == lm25066)
> + config_new |= LM25066_DEV_SETUP_CL;
> + else
> + config_new &= ~LM25066_DEV_SETUP_CL;
> + } else if (strcmp(cl_setting, "low") == 0) {
> + if (data->id == lm25066)
> + config_new &= ~LM25066_DEV_SETUP_CL;
> + else
> + config_new |= LM25066_DEV_SETUP_CL;
[Severity: High]
This isn't a bug introduced by this patch, but does the telemetry coefficient
selection further down in lm25066_probe() also need to account for this
hardware bit logic swap?
Later in lm25066_probe(), the coefficient selection unconditionally assumes
Bit 4 (LM25066_DEV_SETUP_CL) being set means the High limit
(coeff[PSC_CURRENT_IN_L]) for all chips:
if (config & LM25066_DEV_SETUP_CL) {
info->m[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN_L].m;
info->b[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN_L].b;
info->m[PSC_POWER] = coeff[PSC_POWER_L].m;
info->b[PSC_POWER] = coeff[PSC_POWER_L].b;
} else {
info->m[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].m;
info->b[PSC_CURRENT_IN] = coeff[PSC_CURRENT_IN].b;
...
}
For chips like the LM5064, if they are configured for the High current limit,
Bit 4 will be 0 based on the DT parsing logic above.
Could this cause the driver to erroneously select the normal coefficients
(Low current limit) instead of the _L coefficients, potentially throwing the
reported current and power telemetry off by a factor of ~2x?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260615-lm25066-cl-config-v2-0-59be46e67d5a@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Guenter Roeck @ 2026-06-15 3:28 UTC (permalink / raw)
To: sashiko-reviews, Potin Lai; +Cc: conor+dt, linux-hwmon, robh, devicetree
In-Reply-To: <20260615031628.ADC9C1F000E9@smtp.kernel.org>
On 6/14/26 20:16, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Device Tree Schema Type Conflict: The new `ti,current-limit` property is defined as a string, which conflicts with its existing global definition as a `uint32`.
> --
>
> commit 2d0e259557c772018da03b728b427c7fa9a267ca
> Author: Potin Lai <potin.lai.pt@gmail.com>
>
> dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
>
> This commit adds a 'ti,current-limit' string property to configure the
> device's Current Limit (CL) behavior to "high" or "low". It also disables
> this property for the LM25056 variant, which does not support software
> configuration for the current limit.
>
>> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
>> index a20f140dc79a6..53ee98e871ffc 100644
>> --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
>> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
>> @@ -46,12 +46,30 @@ properties:
>>
>> additionalProperties: false
>>
>> + ti,current-limit:
>> + description: |
>> + Configure the current limit setting. When present, this property
>> + overrides the hardware setting of the physical CL pin by configuring
>> + the register.
>> + $ref: /schemas/types.yaml#/definitions/string
>> + enum:
>> + - low
>> + - high
>
> [Severity: Low]
> Does this introduce a global schema type conflict?
>
> Device Tree schema tooling requires property names to have consistent primitive
> types globally. The property ti,current-limit is already defined as a uint32 in
> other Texas Instruments bindings (such as power/supply/bq2415x.yaml).
>
> Redefining it here as a string breaks make dt_binding_check validation. Would
> it be possible to rename this property (for example, ti,current-limit-setting)
> to resolve the collision?
>
ti,current-scale or ti,current-range might be other possibilities.
Guenter
^ permalink raw reply
* Re: [PATCH v3 05/11] of: reserved_mem: split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late()
From: Wandun @ 2026-06-15 3:33 UTC (permalink / raw)
To: Rob Herring
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, alex, saravanak, akpm, bhe,
rppt, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy, quic_obabatun
In-Reply-To: <20260612144122.GA974326-robh@kernel.org>
On 6/12/26 22:41, Rob Herring wrote:
> On Wed, May 27, 2026 at 11:29:11AM +0800, Wandun Chen wrote:
>> From: Wandun Chen <chenwandun@lixiang.com>
>>
>> Prepare for storing /memreserve/ entries in the reserved_mem array.
>> alloc_reserved_mem_array is skipped if the device tree lacks a
>> /reserved-memory node, pointer 'reserved_mem' continues to reference
>> the reserved_mem_array which lives in __initdata, storing
>> /memreserve/ entries into reserved_mem_array would result in metadata
>> loss, and an out-of-bounds memory access will occur if the device
>> tree contains more than MAX_RESERVED_REGIONS /memreserve/ entries.
>>
>> So split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late(),
>> and call alloc_reserved_mem_array() whether or not there is a
>> /reserved-memory node.
>>
>> No functional change.
>> The actual /memreserve/ population is added in a follow-up patch.
>>
>> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
>> ---
>> drivers/of/fdt.c | 7 +++++--
>> drivers/of/of_private.h | 1 +
>> drivers/of/of_reserved_mem.c | 6 +-----
>> 3 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
>> index 82f7327c59ea..83a2a474831e 100644
>> --- a/drivers/of/fdt.c
>> +++ b/drivers/of/fdt.c
>> @@ -1284,8 +1284,11 @@ void __init unflatten_device_tree(void)
>> {
>> void *fdt = initial_boot_params;
>>
>> - /* Save the statically-placed regions in the reserved_mem array */
>> - fdt_scan_reserved_mem_late();
>> + /* Attempt dynamic allocation of a new reserved_mem array */
>> + if (fdt && alloc_reserved_mem_array()) {
>> + /* Save the statically-placed regions in the reserved_mem array */
>> + fdt_scan_reserved_mem_late();
>
> Can we make this just:
>
> alloc_reserved_mem_array();
> fdt_scan_reserved_mem_late();
>
> We already check !fdt in fdt_scan_reserved_mem_late().
Thanks for you review, Rob.
The reason I kept the fdt check is that total_reserved_mem_cnt is wrong
when fdt is NULL, early_init_fdt_scan_reserved_mem() returns early in
that case, so fdt_scan_reserved_mem() never runs, and
total_reserved_mem_cnt stays at MAX_RESERVED_REGIONS. Calling
alloc_reserved_mem_array() unconditionally would allocate unnecessarily
memory.
A better fix might be to make total_reserved_mem_cnt always correct, add
a !fdt check at the top of fdt_scan_reserved_mem() that sets
total_reserved_mem_cnt to 0, and let early_init_fdt_scan_reserved_mem()
call it even when initial_boot_params is NULL. Then
alloc_reserved_mem_array() could naturally skip allcation when that
count is 0, and we can drop the outer fdt guard.
There is still separate UAF issue (fixed in patch3) if we don't check
the return value of alloc_reserved_mem_array().
With the fdt_scan_reserved_mem() fix for total_reserved_mem_cnt, the
call site in unflatten_device_tree() becomes:
if (alloc_reserved_mem_array()) {
fdt_scan_reserved_mem_late();
}
How does that sound?
Best regards,
Wandun
>
> Rob
^ permalink raw reply
* [PATCH 0/8] clk: clocking-wizard: Add static-config clock provider support
From: Shubhrajyoti Datta @ 2026-06-15 3:48 UTC (permalink / raw)
To: linux-clk, linux-kernel
Cc: git, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Shubhrajyoti Datta, devicetree, linux-arm-kernel
The Xilinx clocking-wizard IP can be used in a static-config mode
where the hardware is pre-programmed at boot and no dynamic register
access is required. In that case the driver should skip ioremap,
read the fixed multiplier/divisor pairs from the device tree, and
register fixed-factor clocks derived from clk_in1.
Currently the xlnx,static-config is not functional as it doesnot
model the output clocks. The series fixes the same.
This series:
- adds the xlnx,clk-mul-div binding to carry mul/div pairs
- makes the reg property optional for static-config nodes
- skips ioremap when xlnx,static-config is present
- moves clk_in1 acquisition before the static-config check so it
is available in both code paths
- registers fixed-factor output clocks in static-config mode
Shubhrajyoti Datta (8):
dt-bindings: clock: clocking-wizard: Add xlnx,clk-mul-div property
dt-bindings: clock: clocking-wizard: Make reg optional for
static-config
dt-bindings: clock: clocking-wizard: Make s_axi_aclk optional for
static-config
clk: clocking-wizard: Do not map the memory for static-config
clk: clocking-wizard: Move clk_in1 acquisition before static-config
check
clk: clocking-wizard: Add static-config clock provider support
clk: clocking-wizard: Skip s_axi_aclk for static-config
clk: clocking-wizard: Use dev_err_probe() when mapping registers
.../bindings/clock/xlnx,clocking-wizard.yaml | 50 ++++-
drivers/clk/xilinx/clk-xlnx-clock-wizard.c | 181 ++++++++++++++++--
2 files changed, 205 insertions(+), 26 deletions(-)
--
2.34.1
^ permalink raw reply
* [PATCH 1/8] dt-bindings: clock: clocking-wizard: Add xlnx,clk-mul-div property
From: Shubhrajyoti Datta @ 2026-06-15 3:48 UTC (permalink / raw)
To: linux-clk, linux-kernel
Cc: git, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Shubhrajyoti Datta, devicetree, linux-arm-kernel
In-Reply-To: <20260615034845.3320286-1-shubhrajyoti.datta@amd.com>
Static-config MMCM/PLL ratios are fixed at IP build time, so the kernel
cannot read per-output multiply/divide from registers and needs DT pairs
to register fixed-factor clocks. Also add the tuples by pair in example.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
---
.../bindings/clock/xlnx,clocking-wizard.yaml | 24 +++++++++++++++++++
1 file changed, 24 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
index b497c28e8094..8316654b0a91 100644
--- a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
+++ b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
@@ -57,6 +57,21 @@ properties:
description:
Number of outputs.
+ xlnx,clk-mul-div:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ description:
+ Fixed MMCM/PLL multiply/divide ratios, one (multiplier, divisor)
+ pair per clock output relative to clk_in1. The number of entries
+ must equal xlnx,nr-outputs.
+ minItems: 1
+ maxItems: 8
+ items:
+ items:
+ - description: multiplier
+ minimum: 1
+ - description: divisor
+ minimum: 1
+
required:
- compatible
- reg
@@ -66,6 +81,14 @@ required:
- xlnx,speed-grade
- xlnx,nr-outputs
+allOf:
+ - if:
+ required:
+ - xlnx,static-config
+ then:
+ required:
+ - xlnx,clk-mul-div
+
additionalProperties: false
examples:
@@ -77,6 +100,7 @@ examples:
xlnx,static-config;
xlnx,speed-grade = <1>;
xlnx,nr-outputs = <6>;
+ xlnx,clk-mul-div = <12 1>, <10 2>, <8 1>, <6 1>, <4 2>, <2 1>;
clock-names = "clk_in1", "s_axi_aclk";
clocks = <&clkc 15>, <&clkc 15>;
};
--
2.49.1
^ permalink raw reply related
* [PATCH 2/8] dt-bindings: clock: clocking-wizard: Make reg optional for static-config
From: Shubhrajyoti Datta @ 2026-06-15 3:48 UTC (permalink / raw)
To: linux-clk, linux-kernel
Cc: git, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Michal Simek,
Shubhrajyoti Datta, devicetree, linux-arm-kernel
In-Reply-To: <20260615034845.3320286-1-shubhrajyoti.datta@amd.com>
In static-config mode the IP exposes only fixed-factor clock outputs and
has no runtime-programmable registers, so reg is not required.
Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
---
.../bindings/clock/xlnx,clocking-wizard.yaml | 22 ++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
index 8316654b0a91..aa397550d107 100644
--- a/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
+++ b/Documentation/devicetree/bindings/clock/xlnx,clocking-wizard.yaml
@@ -74,7 +74,6 @@ properties:
required:
- compatible
- - reg
- "#clock-cells"
- clocks
- clock-names
@@ -88,20 +87,33 @@ allOf:
then:
required:
- xlnx,clk-mul-div
+ else:
+ required:
+ - reg
additionalProperties: false
examples:
- |
- clock-controller@b0000000 {
+ clock-controller@b0000000 {
compatible = "xlnx,clocking-wizard";
reg = <0xb0000000 0x10000>;
#clock-cells = <1>;
- xlnx,static-config;
+ clocks = <&clkc 15>, <&clkc 18>;
+ clock-names = "clk_in1", "s_axi_aclk";
+ xlnx,nr-outputs = <6>;
xlnx,speed-grade = <1>;
+ };
+
+ - |
+ clock-controller {
+ compatible = "xlnx,clocking-wizard";
+ #clock-cells = <1>;
+ clocks = <&clkc 15>, <&clkc 18>;
+ clock-names = "clk_in1", "s_axi_aclk";
xlnx,nr-outputs = <6>;
+ xlnx,speed-grade = <1>;
+ xlnx,static-config;
xlnx,clk-mul-div = <12 1>, <10 2>, <8 1>, <6 1>, <4 2>, <2 1>;
- clock-names = "clk_in1", "s_axi_aclk";
- clocks = <&clkc 15>, <&clkc 15>;
};
...
--
2.49.1
^ permalink raw reply related
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