* Re: [QUESTION] rtc: zynqmp: CALIB_RD reset behavior differs between ZynqMP and Versal
From: Tomas Melin @ 2026-03-11 5:22 UTC (permalink / raw)
To: Takumi Ando, Alexandre Belloni, linux-rtc
Cc: michal.simek, Yasushi SHOJI, kanta tamura
In-Reply-To: <CAJACUaqHDJOZY-jgriGRX=DE=e3rvBgvycjO1exxQ7k1XdywpA@mail.gmail.com>
Hi,
On 11/03/2026 05:19, Takumi Ando wrote:
> [You don't often get email from takumi@spacecubics.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Tomas, Alexandre,
>
> Thank you for the explanations.
>
> So if I understand correctly, both on Zynq UltraScale+ and Versal,
> CALIB_RD may return a non-zero (or otherwise undefined) value after
> reset, meaning that it cannot reliably be used to determine whether
> the calibration register has already been initialized.
>
> While the fractional calibration should indeed be handled from
> userspace (e.g. via the RTC offset interface), it seems that the
> Max_Tick field should still always be programmed according to the
> value provided in Device Tree, since it depends only on the RTC
> oscillator frequency.
Both max_tick and fract_data might change, it depends on how big
the calibrator drift/offset is and if it is negative/positive.
>
> Would it make sense for the driver to always program Max_Tick from the
> Device Tree "calibration" property while preserving the fractional
> calibration bits currently stored in hardware?
As Alexandre mentioned, user space needs to ensure calibration is what
it should be.
thanks,
Tomas
>
> If this approach sounds reasonable, I would like to prepare a patch
> for upstream.
>
> Best regards,
>
> 2026年3月6日(金) 20:13 Alexandre Belloni <alexandre.belloni@bootlin.com>:
>> On 06/03/2026 12:09:40+0200, Tomas Melin wrote:
>>>> On Zynq UltraScale+ Devices Register Reference (UG1087) [2],
>>>> CALIB_RD resets to 0, so the current logic works correctly there.
>>>> However, this assumption does not appear to hold for Versal.
>>> For Ultrascale+ the calibration register also gives random values after
>>> reset, perhaps you have noticed this:
>>> https://adaptivesupport.amd.com/s/article/000036886?language=en_US. Maybe
>>> the same can occur also on Versal.
>>>
>>> AFAIK there is no way of knowing if the value is correct or not after reset,
>>> so user space helpers might be needed to maintain the calibration value at a
>>> desired value.
>>>
>> Userspace is always needed to put the proper calibration, there is no
>> way for the kernel to know what value to put there. In the support case
>> above, the crystal will never be exactly 32768Hz and this value will
>> change over time and also depends on the temperature. The value always
>> needs to be computed, if your device can do NTP, chrony will provide the
>> proper offsets. If you don't have a way to measure the deviation, then
>> userspace can always forcefully set /sys/class/rtc/rtcX/offset if it
>> doesn't hold the correct value.
>> There is no need for devmem here.
>>
>> --
>> Alexandre Belloni, co-owner and COO, Bootlin
>> Embedded Linux and Kernel engineering
>> https://bootlin.com/
>
>
> --
> Takumi Ando
> Space Cubics Inc.
^ permalink raw reply
* Re: [QUESTION] rtc: zynqmp: CALIB_RD reset behavior differs between ZynqMP and Versal
From: Takumi Ando @ 2026-03-11 3:19 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, linux-rtc
Cc: michal.simek, Yasushi SHOJI, kanta tamura
In-Reply-To: <202603061113298cbba29d@mail.local>
Hi Tomas, Alexandre,
Thank you for the explanations.
So if I understand correctly, both on Zynq UltraScale+ and Versal,
CALIB_RD may return a non-zero (or otherwise undefined) value after
reset, meaning that it cannot reliably be used to determine whether
the calibration register has already been initialized.
While the fractional calibration should indeed be handled from
userspace (e.g. via the RTC offset interface), it seems that the
Max_Tick field should still always be programmed according to the
value provided in Device Tree, since it depends only on the RTC
oscillator frequency.
Would it make sense for the driver to always program Max_Tick from the
Device Tree "calibration" property while preserving the fractional
calibration bits currently stored in hardware?
If this approach sounds reasonable, I would like to prepare a patch
for upstream.
Best regards,
2026年3月6日(金) 20:13 Alexandre Belloni <alexandre.belloni@bootlin.com>:
>
> On 06/03/2026 12:09:40+0200, Tomas Melin wrote:
> > > On Zynq UltraScale+ Devices Register Reference (UG1087) [2],
> > > CALIB_RD resets to 0, so the current logic works correctly there.
> > > However, this assumption does not appear to hold for Versal.
> >
> > For Ultrascale+ the calibration register also gives random values after
> > reset, perhaps you have noticed this:
> > https://adaptivesupport.amd.com/s/article/000036886?language=en_US. Maybe
> > the same can occur also on Versal.
> >
> > AFAIK there is no way of knowing if the value is correct or not after reset,
> > so user space helpers might be needed to maintain the calibration value at a
> > desired value.
> >
>
> Userspace is always needed to put the proper calibration, there is no
> way for the kernel to know what value to put there. In the support case
> above, the crystal will never be exactly 32768Hz and this value will
> change over time and also depends on the temperature. The value always
> needs to be computed, if your device can do NTP, chrony will provide the
> proper offsets. If you don't have a way to measure the deviation, then
> userspace can always forcefully set /sys/class/rtc/rtcX/offset if it
> doesn't hold the correct value.
> There is no need for devmem here.
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
Takumi Ando
Space Cubics Inc.
^ permalink raw reply
* Re: [PATCH v3 10/13] leds: rgb: add support for Samsung S2M series PMIC RGB LED device
From: Lee Jones @ 2026-03-10 11:48 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260225-s2mu005-pmic-v3-10-b4afee947603@disroot.org>
On Wed, 25 Feb 2026, Kaustabh Chakraborty wrote:
> Add support for the RGB LEDs found in certain Samsung S2M series PMICs.
> The device has three LED channels, controlled as a single device. These
> LEDs are typically used as status indicators in mobile phones.
>
> The driver includes initial support for the S2MU005 PMIC RGB LEDs.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> drivers/leds/rgb/Kconfig | 11 +
> drivers/leds/rgb/Makefile | 1 +
> drivers/leds/rgb/leds-s2m-rgb.c | 458 ++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 470 insertions(+)
Start by applying all of the comments I made on the 'flash' device.
I'll take a more in-depth look at this one on the next version.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3 09/13] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: Lee Jones @ 2026-03-10 11:38 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260225-s2mu005-pmic-v3-9-b4afee947603@disroot.org>
On Wed, 25 Feb 2026, Kaustabh Chakraborty wrote:
> Add support for flash LEDs found in certain Samsung S2M series PMICs.
> The device has two channels for LEDs, typically for the back and front
> cameras in mobile devices. Both channels can be independently
> controlled, and can be operated in torch or flash modes.
>
> The driver includes initial support for the S2MU005 PMIC flash LEDs.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> drivers/leds/flash/Kconfig | 12 +
> drivers/leds/flash/Makefile | 1 +
> drivers/leds/flash/leds-s2m-flash.c | 429 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 442 insertions(+)
>
> diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
> index 5e08102a67841..be62e05277429 100644
> --- a/drivers/leds/flash/Kconfig
> +++ b/drivers/leds/flash/Kconfig
> @@ -114,6 +114,18 @@ config LEDS_RT8515
> To compile this driver as a module, choose M here: the module
> will be called leds-rt8515.
>
> +config LEDS_S2M_FLASH
> + tristate "Samsung S2M series PMICs flash/torch LED support"
> + depends on LEDS_CLASS
> + depends on MFD_SEC_CORE
> + depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
> + select REGMAP_IRQ
> + help
> + This option enables support for the flash/torch LEDs found in
> + certain Samsung S2M series PMICs, such as the S2MU005. It has
> + a LED channel dedicated for every physical LED. The LEDs can
> + be controlled in flash and torch modes.
> +
> config LEDS_SGM3140
> tristate "LED support for the SGM3140"
> depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
> diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
> index 712fb737a428e..44e6c1b4beb37 100644
> --- a/drivers/leds/flash/Makefile
> +++ b/drivers/leds/flash/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_LEDS_MAX77693) += leds-max77693.o
> obj-$(CONFIG_LEDS_QCOM_FLASH) += leds-qcom-flash.o
> obj-$(CONFIG_LEDS_RT4505) += leds-rt4505.o
> obj-$(CONFIG_LEDS_RT8515) += leds-rt8515.o
> +obj-$(CONFIG_LEDS_S2M_FLASH) += leds-s2m-flash.o
> obj-$(CONFIG_LEDS_SGM3140) += leds-sgm3140.o
> obj-$(CONFIG_LEDS_SY7802) += leds-sy7802.o
> obj-$(CONFIG_LEDS_TPS6131X) += leds-tps6131x.o
> diff --git a/drivers/leds/flash/leds-s2m-flash.c b/drivers/leds/flash/leds-s2m-flash.c
> new file mode 100644
> index 0000000000000..536a529889a9c
> --- /dev/null
> +++ b/drivers/leds/flash/leds-s2m-flash.c
> @@ -0,0 +1,429 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Flash and Torch LED Driver for Samsung S2M series PMICs.
> + *
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd
> + * Copyright (c) 2025 Kaustabh Chakraborty <kauschluss@disroot.org>
> + */
> +
> +#include <linux/container_of.h>
> +#include <linux/led-class-flash.h>
> +#include <linux/mfd/samsung/core.h>
> +#include <linux/mfd/samsung/s2mu005.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +#include <media/v4l2-flash-led-class.h>
> +
> +#define MAX_CHANNELS 2
> +
> +struct s2m_fled {
This is not the fled, change this to _led and call pointers to it 'led'.
> + struct device *dev;
> + struct regmap *regmap;
> + struct led_classdev_flash cdev;
This is the 'fled'. Please change all pointer to it to 'fled'.
> + struct v4l2_flash *v4l2_flash;
> + /*
> + * The mutex object prevents the concurrent access of flash control
> + * registers by the LED and V4L2 subsystems.
> + */
> + struct mutex lock;
> + const struct s2m_fled_spec *spec;
This should not be in here.
> + unsigned int reg_enable;
> + u8 channel;
> + u8 flash_brightness;
> + u8 flash_timeout;
> +};
> +
> +struct s2m_fled_spec {
> + u8 nr_channels;
> + u32 torch_max_brightness;
> + u32 flash_min_current_ua;
> + u32 flash_max_current_ua;
> + u32 flash_min_timeout_us;
> + u32 flash_max_timeout_us;
> + int (*torch_brightness_set_blocking)(struct led_classdev *led_cdev,
> + enum led_brightness brightness);
I'm really not a fan of pointers to functions at the driver level.
If there are differences between devices, which I cannot see here, store
an identifier and use that to choose which call-back function is the
most appropriate.
> + const struct led_flash_ops *flash_ops;
Why do we need to store these?
The same principles apply to the function pointer above.
> +};
> +
> +static struct led_classdev_flash *to_cdev_flash(struct led_classdev *cdev)
> +{
> + return container_of(cdev, struct led_classdev_flash, led_cdev);
> +}
> +
> +static struct s2m_fled *to_led_priv(struct led_classdev_flash *cdev)
There is nothing private about s2m_{f}led.
'led' is the most common nomenclature. So: led->channel, etc.
Remove 'priv' throughout.
> +{
> + return container_of(cdev, struct s2m_fled, cdev);
return container_of(fled, struct s2m_led, fled);
> +}
> +
> +static int s2m_fled_flash_brightness_set(struct led_classdev_flash *cdev,
> + u32 brightness)
> +{
> + struct s2m_fled *priv = to_led_priv(cdev);
> + struct led_flash_setting *setting = &cdev->brightness;
> +
> + priv->flash_brightness = (brightness - setting->min) / setting->step;
> +
> + return 0;
> +}
> +
> +static int s2m_fled_flash_timeout_set(struct led_classdev_flash *cdev,
> + u32 timeout)
> +{
> + struct s2m_fled *priv = to_led_priv(cdev);
> + struct led_flash_setting *setting = &cdev->timeout;
> +
> + priv->flash_timeout = (timeout - setting->min) / setting->step;
> +
> + return 0;
> +}
> +
> +#if IS_ENABLED(CONFIG_V4L2_FLASH_LED_CLASS)
> +static int s2m_fled_flash_external_strobe_set(struct v4l2_flash *v4l2_flash,
> + bool enable)
> +{
> + struct s2m_fled *priv = to_led_priv(v4l2_flash->fled_cdev);
> +
> + mutex_lock(&priv->lock);
> +
> + priv->cdev.ops->strobe_set(&priv->cdev, enable);
> +
> + mutex_unlock(&priv->lock);
> +
> + return 0;
> +}
> +
> +static const struct v4l2_flash_ops s2m_fled_v4l2_flash_ops = {
> + .external_strobe_set = s2m_fled_flash_external_strobe_set,
> +};
> +#else
> +static const struct v4l2_flash_ops s2m_fled_v4l2_flash_ops;
> +#endif
> +
> +static void s2m_fled_v4l2_flash_release(void *v4l2_flash)
> +{
> + v4l2_flash_release(v4l2_flash);
> +}
> +
> +static int s2mu005_fled_torch_brightness_set(struct led_classdev *cdev,
> + enum led_brightness value)
> +{
> + struct s2m_fled *priv = to_led_priv(to_cdev_flash(cdev));
> + struct regmap *regmap = priv->regmap;
> + int ret;
> +
> + mutex_lock(&priv->lock);
> +
> + if (value == LED_OFF) {
These defines are deprecated.
From include/linux/leds.h:
/* This is obsolete/useless. We now support variable maximum brightness. */
enum led_brightness {
LED_OFF = 0,
LED_ON = 1,
LED_HALF = 127,
LED_FULL = 255,
};
> + ret = regmap_clear_bits(regmap, priv->reg_enable,
> + S2MU005_FLED_TORCH_EN(priv->channel));
> + if (ret < 0)
> + dev_err(priv->dev, "failed to disable torch LED\n");
> + goto unlock;
> + }
> +
> + ret = regmap_update_bits(regmap, S2MU005_REG_FLED_CH_CTRL1(priv->channel),
j> + S2MU005_FLED_TORCH_IOUT,
> + FIELD_PREP(S2MU005_FLED_TORCH_IOUT, value - 1));
> + if (ret < 0) {
> + dev_err(priv->dev, "failed to set torch current\n");
> + goto unlock;
> + }
> +
> + ret = regmap_set_bits(regmap, priv->reg_enable,
> + S2MU005_FLED_TORCH_EN(priv->channel));
> + if (ret < 0) {
> + dev_err(priv->dev, "failed to enable torch LED\n");
> + goto unlock;
> + }
> +
> +unlock:
> + mutex_unlock(&priv->lock);
> +
> + return ret;
> +}
> +
> +static int s2mu005_fled_flash_strobe_set(struct led_classdev_flash *cdev,
> + bool state)
> +{
> + struct s2m_fled *priv = to_led_priv(cdev);
> + struct regmap *regmap = priv->regmap;
> + int ret;
> +
> + mutex_lock(&priv->lock);
> +
> + ret = regmap_clear_bits(regmap, priv->reg_enable,
> + S2MU005_FLED_FLASH_EN(priv->channel));
> + if (ret < 0) {
> + dev_err(priv->dev, "failed to disable flash LED\n");
> + goto unlock;
> + }
> +
> + if (!state)
> + goto unlock;
> +
> + ret = regmap_update_bits(regmap, S2MU005_REG_FLED_CH_CTRL0(priv->channel),
> + S2MU005_FLED_FLASH_IOUT,
> + FIELD_PREP(S2MU005_FLED_FLASH_IOUT,
> + priv->flash_brightness));
> + if (ret < 0) {
> + dev_err(priv->dev, "failed to set flash brightness\n");
> + goto unlock;
> + }
> +
> + ret = regmap_update_bits(regmap, S2MU005_REG_FLED_CH_CTRL3(priv->channel),
> + S2MU005_FLED_FLASH_TIMEOUT,
> + FIELD_PREP(S2MU005_FLED_FLASH_TIMEOUT,
> + priv->flash_timeout));
> + if (ret < 0) {
> + dev_err(priv->dev, "failed to set flash timeout\n");
> + goto unlock;
> + }
> +
> + ret = regmap_set_bits(regmap, priv->reg_enable,
> + S2MU005_FLED_FLASH_EN(priv->channel));
> + if (ret < 0) {
> + dev_err(priv->dev, "failed to enable flash LED\n");
> + goto unlock;
> + }
> +
> +unlock:
> + mutex_unlock(&priv->lock);
> +
> + return 0;
> +}
> +
> +static int s2mu005_fled_flash_strobe_get(struct led_classdev_flash *cdev,
> + bool *state)
> +{
> + struct s2m_fled *priv = to_led_priv(cdev);
> + struct regmap *regmap = priv->regmap;
Since this is only used once, I don't see anything to gain from
utilising a local variable here.
> + u8 channel = priv->channel;
Same here.
> + u32 val;
> + int ret;
> +
> + mutex_lock(&priv->lock);
> +
> + ret = regmap_read(regmap, S2MU005_REG_FLED_STATUS, &val);
> + if (ret < 0) {
> + dev_err(priv->dev, "failed to fetch LED status");
> + goto unlock;
> + }
> +
> + *state = !!(val & S2MU005_FLED_FLASH_STATUS(channel));
> +
> +unlock:
> + mutex_unlock(&priv->lock);
> +
> + return ret;
> +}
> +
> +static const struct led_flash_ops s2mu005_fled_flash_ops = {
> + .flash_brightness_set = s2m_fled_flash_brightness_set,
> + .timeout_set = s2m_fled_flash_timeout_set,
> + .strobe_set = s2mu005_fled_flash_strobe_set,
> + .strobe_get = s2mu005_fled_flash_strobe_get,
> +};
> +
> +static int s2mu005_fled_init(struct s2m_fled *priv)
> +{
> + unsigned int val;
> + int ret;
> +
> + /* Enable the LED channels. */
> + ret = regmap_set_bits(priv->regmap, S2MU005_REG_FLED_CTRL1,
> + S2MU005_FLED_CH_EN);
Feel free to use up to 100-char to eradicate these wraps.
> + if (ret < 0)
> + return dev_err_probe(priv->dev, ret, "failed to enable LED channels\n");
> +
> + /*
> + * Get the LED enable register address. Revision EVT0 has the
> + * register at CTRL4, while EVT1 and higher have it at CTRL6.
> + */
> + ret = regmap_read(priv->regmap, S2MU005_REG_ID, &val);
> + if (ret < 0)
> + return dev_err_probe(priv->dev, ret, "failed to read revision\n");
> +
> + if (FIELD_GET(S2MU005_ID_MASK, val) == 0)
A comment above to explain what this means please.
And/or define the zero to something obvious.
> + priv->reg_enable = S2MU005_REG_FLED_CTRL4;
> + else
> + priv->reg_enable = S2MU005_REG_FLED_CTRL6;
> +
> + return 0;
> +}
> +
> +static const struct s2m_fled_spec s2mu005_fled_spec = {
> + .nr_channels = 2,
> + .torch_max_brightness = 16,
> + .flash_min_current_ua = 25000,
> + .flash_max_current_ua = 375000, /* 400000 causes flickering */
> + .flash_min_timeout_us = 62000,
> + .flash_max_timeout_us = 992000,
> + .torch_brightness_set_blocking = s2mu005_fled_torch_brightness_set,
> + .flash_ops = &s2mu005_fled_flash_ops,
> +};
> +
> +static int s2m_fled_init_channel(struct s2m_fled *priv,
> + struct fwnode_handle *fwnp)
Unwrap all of these that fit into 100-chars.
> +{
> + struct led_classdev *led = &priv->cdev.led_cdev;
> + struct led_init_data init_data = {};
> + struct v4l2_flash_config v4l2_cfg = {};
> + int ret;
> +
> + led->max_brightness = priv->spec->torch_max_brightness;
> + led->brightness_set_blocking = priv->spec->torch_brightness_set_blocking;
> + led->flags |= LED_DEV_CAP_FLASH;
> +
> + priv->cdev.timeout.min = priv->spec->flash_min_timeout_us;
> + priv->cdev.timeout.step = priv->spec->flash_min_timeout_us;
> + priv->cdev.timeout.max = priv->spec->flash_max_timeout_us;
> + priv->cdev.timeout.val = priv->spec->flash_max_timeout_us;
> +
> + priv->cdev.brightness.min = priv->spec->flash_min_current_ua;
> + priv->cdev.brightness.step = priv->spec->flash_min_current_ua;
> + priv->cdev.brightness.max = priv->spec->flash_max_current_ua;
> + priv->cdev.brightness.val = priv->spec->flash_max_current_ua;
Moving things around in priv/data tells me that something isn't right.
I think the spec should be removed from what is currently called priv.
> + s2m_fled_flash_timeout_set(&priv->cdev, priv->cdev.timeout.val);
> + s2m_fled_flash_brightness_set(&priv->cdev, priv->cdev.brightness.val);
> +
> + priv->cdev.ops = priv->spec->flash_ops;
> +
> + init_data.fwnode = fwnp;
> + ret = devm_led_classdev_flash_register_ext(priv->dev, &priv->cdev,
> + &init_data);
> + if (ret < 0)
> + return dev_err_probe(priv->dev, ret, "failed to create LED flash device\n");
> +
> + v4l2_cfg.intensity.min = priv->spec->flash_min_current_ua;
> + v4l2_cfg.intensity.step = priv->spec->flash_min_current_ua;
> + v4l2_cfg.intensity.max = priv->spec->flash_max_current_ua;
> + v4l2_cfg.intensity.val = priv->spec->flash_max_current_ua;
> +
> + v4l2_cfg.has_external_strobe = true;
> +
> + priv->v4l2_flash = v4l2_flash_init(priv->dev, fwnp, &priv->cdev,
> + &s2m_fled_v4l2_flash_ops, &v4l2_cfg);
> + if (IS_ERR(priv->v4l2_flash)) {
> + v4l2_flash_release(priv->v4l2_flash);
> + return dev_err_probe(priv->dev, PTR_ERR(priv->v4l2_flash),
> + "failed to create V4L2 flash device\n");
> + }
> +
> + ret = devm_add_action_or_reset(priv->dev, (void *)s2m_fled_v4l2_flash_release,
> + priv->v4l2_flash);
> + if (ret < 0)
> + return dev_err_probe(priv->dev, ret, "failed to add cleanup action\n");
v4l2_flash_release()?
> + return 0;
> +}
> +
> +static int s2m_fled_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct sec_pmic_dev *pmic_drvdata = dev_get_drvdata(dev->parent);
s/pmic_drvdata/ddata/
> + struct s2m_fled *priv;
> + bool channel_initialized[MAX_CHANNELS] = { false };
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv) * MAX_CHANNELS, GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + platform_set_drvdata(pdev, priv);
Where is this used?
> + priv->dev = dev;
This is already available to you in what is currently called:
priv->cdev->led_cdev->dev
Also, isn't this an array?
> + priv->regmap = pmic_drvdata->regmap_pmic;
> +
> + switch (platform_get_device_id(pdev)->driver_data) {
> + case S2MU005:
> + priv->spec = &s2mu005_fled_spec;
> + ret = s2mu005_fled_init(priv);
> + if (ret)
> + return ret;
> + break;
> + default:
> + return dev_err_probe(dev, -ENODEV,
> + "device type %d is not supported by driver\n",
> + pmic_drvdata->device_type);
> + }
> +
> + if (priv->spec->nr_channels > MAX_CHANNELS)
> + return dev_err_probe(dev, -EINVAL,
> + "number of channels specified (%u) exceeds the limit (%u)\n",
> + priv->spec->nr_channels, MAX_CHANNELS);
> +
> + device_for_each_child_node_scoped(dev, child) {
> + u32 reg;
> +
> + if (fwnode_property_read_u32(child, "reg", ®))
> + continue;
> +
> + if (reg >= priv->spec->nr_channels) {
> + dev_warn(dev, "channel %d is non-existent\n", reg);
> + continue;
> + }
> +
> + if (channel_initialized[reg]) {
Do you really need a whole variable just for this?
If this a risk? If it really is, why not check (priv[reg].dev)?
> + dev_warn(dev, "duplicate node for channel %d\n", reg);
> + continue;
> + }
> +
> + priv[reg].dev = priv->dev;
What on earth is going on here?
> + priv[reg].regmap = priv->regmap;
> + priv[reg].spec = priv->spec;
> + priv[reg].reg_enable = priv->reg_enable;
And why do you need ${reg} copies of the same data?
Sounds like a waste of resources, no?
> + priv[reg].channel = (u8)reg;
> +
> + ret = devm_mutex_init(dev, &priv[reg].lock);
Why not just look the whole device? Rather than per channel?
To channels have no shared resources?
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create mutex lock\n");
You can drop the ' lock' part.
> +
> + ret = s2m_fled_init_channel(priv + reg, child);
> + if (ret < 0)
> + return ret;
> +
> + channel_initialized[reg] = true;
> + }
> +
> + return 0;
> +}
> +
> +static const struct platform_device_id s2m_fled_id_table[] = {
> + { "s2mu005-flash", S2MU005 },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(platform, s2m_fled_id_table);
> +
> +/*
> + * Device is instantiated through parent MFD device and device matching
> + * is done through platform_device_id.
> + *
> + * However if device's DT node contains proper compatible and driver is
> + * built as a module, then the *module* matching will be done through DT
> + * aliases. This requires of_device_id table. In the same time this will
> + * not change the actual *device* matching so do not add .of_match_table.
> + */
All of this is already implied.
No need to have this comment on all MFD sub-devices.
> +static const struct of_device_id s2m_fled_of_match_table[] = {
> + {
> + .compatible = "samsung,s2mu005-flash",
> + .data = (void *)S2MU005,
These usually fit on a single line.
> + }, {
> + /* sentinel */
> + },
> +};
> +MODULE_DEVICE_TABLE(of, s2m_fled_of_match_table);
> +
> +static struct platform_driver s2m_fled_driver = {
> + .driver = {
> + .name = "s2m-flash",
> + },
> + .probe = s2m_fled_probe,
> + .id_table = s2m_fled_id_table,
> +};
> +module_platform_driver(s2m_fled_driver);
> +
> +MODULE_DESCRIPTION("Flash/Torch LED Driver For Samsung S2M Series PMICs");
> +MODULE_AUTHOR("Kaustabh Chakraborty <kauschluss@disroot.org>");
> +MODULE_LICENSE("GPL");
>
> --
> 2.52.0
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 4/6] mfd: sprd-sc27xx: Switch to devm_mfd_add_devices()
From: Lee Jones @ 2026-03-09 18:58 UTC (permalink / raw)
To: Otto Pflüger
Cc: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel, linux-rtc,
devicetree, linux-kernel, linux-leds, linux-pm
In-Reply-To: <20260222-sc27xx-mfd-cells-v1-4-69526fe74c77@abscue.de>
On Sun, 22 Feb 2026, Otto Pflüger wrote:
> To allow instantiating subdevices such as the regulator and poweroff
> devices that do not have corresponding device tree nodes with a
> "compatible" property, use devm_mfd_add_devices() with MFD cells instead
> of devm_of_platform_populate(). Since different PMICs in the SC27xx
> series contain different components, use separate MFD cell tables for
> each PMIC model. Define cells for all components that have upstream
> drivers at this point.
We're not passing one device registration API's data (MFD)
through another (Device Tree).
Pass an identifier through and match on that instead.
Look at how all of the other drivers in MFD do it.
> Signed-off-by: Otto Pflüger <otto.pflueger@abscue.de>
> ---
> drivers/mfd/sprd-sc27xx-spi.c | 33 ++++++++++++++++++++++++++++++++-
> 1 file changed, 32 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/sprd-sc27xx-spi.c b/drivers/mfd/sprd-sc27xx-spi.c
> index d6b4350779e6..57941bec4c2e 100644
> --- a/drivers/mfd/sprd-sc27xx-spi.c
> +++ b/drivers/mfd/sprd-sc27xx-spi.c
> @@ -48,6 +48,31 @@ struct sprd_pmic_data {
> u32 irq_base;
> u32 num_irqs;
> u32 charger_det;
> + const struct mfd_cell *cells;
> + int num_cells;
> +};
> +
> +static const struct mfd_cell sc2730_devices[] = {
> + MFD_CELL_OF("sc2730-adc", NULL, NULL, 0, 0, "sprd,sc2730-adc"),
> + MFD_CELL_OF("sc2730-bltc", NULL, NULL, 0, 0, "sprd,sc2730-bltc"),
> + MFD_CELL_OF("sc2730-efuse", NULL, NULL, 0, 0, "sprd,sc2730-efuse"),
> + MFD_CELL_OF("sc2730-eic", NULL, NULL, 0, 0, "sprd,sc2730-eic"),
> + MFD_CELL_OF("sc2730-fgu", NULL, NULL, 0, 0, "sprd,sc2730-fgu"),
> + MFD_CELL_OF("sc2730-rtc", NULL, NULL, 0, 0, "sprd,sc2730-rtc"),
> + MFD_CELL_OF("sc2730-vibrator", NULL, NULL, 0, 0, "sprd,sc2730-vibrator"),
> +};
> +
> +static const struct mfd_cell sc2731_devices[] = {
> + MFD_CELL_OF("sc2731-adc", NULL, NULL, 0, 0, "sprd,sc2731-adc"),
> + MFD_CELL_OF("sc2731-bltc", NULL, NULL, 0, 0, "sprd,sc2731-bltc"),
> + MFD_CELL_OF("sc2731-charger", NULL, NULL, 0, 0, "sprd,sc2731-charger"),
> + MFD_CELL_OF("sc2731-efuse", NULL, NULL, 0, 0, "sprd,sc2731-efuse"),
> + MFD_CELL_OF("sc2731-eic", NULL, NULL, 0, 0, "sprd,sc2731-eic"),
> + MFD_CELL_OF("sc2731-fgu", NULL, NULL, 0, 0, "sprd,sc2731-fgu"),
> + MFD_CELL_NAME("sc2731-poweroff"),
> + MFD_CELL_NAME("sc2731-regulator"),
> + MFD_CELL_OF("sc2731-rtc", NULL, NULL, 0, 0, "sprd,sc2731-rtc"),
> + MFD_CELL_OF("sc2731-vibrator", NULL, NULL, 0, 0, "sprd,sc2731-vibrator"),
> };
>
> /*
> @@ -59,12 +84,16 @@ static const struct sprd_pmic_data sc2730_data = {
> .irq_base = SPRD_SC2730_IRQ_BASE,
> .num_irqs = SPRD_SC2730_IRQ_NUMS,
> .charger_det = SPRD_SC2730_CHG_DET,
> + .cells = sc2730_devices,
> + .num_cells = ARRAY_SIZE(sc2730_devices),
> };
>
> static const struct sprd_pmic_data sc2731_data = {
> .irq_base = SPRD_SC2731_IRQ_BASE,
> .num_irqs = SPRD_SC2731_IRQ_NUMS,
> .charger_det = SPRD_SC2731_CHG_DET,
> + .cells = sc2731_devices,
> + .num_cells = ARRAY_SIZE(sc2731_devices),
> };
>
> enum usb_charger_type sprd_pmic_detect_charger_type(struct device *dev)
> @@ -204,7 +233,9 @@ static int sprd_pmic_probe(struct spi_device *spi)
> return ret;
> }
>
> - ret = devm_of_platform_populate(&spi->dev);
> + ret = devm_mfd_add_devices(&spi->dev, PLATFORM_DEVID_AUTO,
> + pdata->cells, pdata->num_cells, NULL, 0,
> + regmap_irq_get_domain(ddata->irq_data));
> if (ret) {
> dev_err(&spi->dev, "Failed to populate sub-devices %d\n", ret);
> return ret;
>
> --
> 2.51.0
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: (subset) [PATCH 2/6] dt-bindings: leds: sc2731: Add compatible for SC2730
From: Lee Jones @ 2026-03-09 18:54 UTC (permalink / raw)
To: Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Orson Zhai, Baolin Wang, Chunyan Zhang, Lee Jones, Pavel Machek,
Liam Girdwood, Mark Brown, Sebastian Reichel, Otto Pflüger
Cc: linux-rtc, devicetree, linux-kernel, linux-leds, linux-pm
In-Reply-To: <20260222-sc27xx-mfd-cells-v1-2-69526fe74c77@abscue.de>
On Sun, 22 Feb 2026 14:16:46 +0100, Otto Pflüger wrote:
> The LED controller found in the SC2730 PMIC is compatible with the one
> found in the SC2731 PMIC.
>
>
Applied, thanks!
[2/6] dt-bindings: leds: sc2731: Add compatible for SC2730
commit: fc2dfc3392ec52f12d8d6f16a8b13cca838d8bee
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: rtc: microcrystal,rv3028: Allow to specify vdd-supply
From: Krzysztof Kozlowski @ 2026-03-09 15:14 UTC (permalink / raw)
To: Frieder Schrempf, Alexandre Belloni, Conor Dooley, devicetree,
Krzysztof Kozlowski, linux-kernel, linux-rtc, Rob Herring
Cc: Frieder Schrempf
In-Reply-To: <20260309085749.25747-2-frieder@fris.de>
On 09/03/2026 09:57, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> In case the VDD supply voltage regulator of the RTC needs to be
> specified explicitly, allow to set vdd-supply.
>
> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 0/2] Kontron i.MX8MP OSM Devicetree Fixups
From: Frank Li @ 2026-03-09 14:59 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Alexandre Belloni, Conor Dooley, devicetree, Frieder Schrempf,
imx, Krzysztof Kozlowski, linux-arm-kernel, linux-kernel,
linux-rtc, Rob Herring, Sascha Hauer, Shawn Guo, Annette Kobou,
Fabio Estevam, Pengutronix Kernel Team
In-Reply-To: <20260309085749.25747-1-frieder@fris.de>
On Mon, Mar 09, 2026 at 09:57:41AM +0100, Frieder Schrempf wrote:
> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>
> This contains three fixes and one cosmetic change for
> the Kontron i.MX8MP OSM devices.
>
> Changes for v3:
> * Drop applied patches
> * Add missing bindings patch for RV3028 RTC
>
> Changes for v2:
> * Add Frank's R-b tags (thanks)
> * Enhance commit message of patch 2
>
> Annette Kobou (1):
> arm64: dts: imx8mp-kontron: Fix boot order for PMIC and RTC
>
> Frieder Schrempf (1):
> dt-bindings: rtc: microcrystal,rv3028: Allow to specify vdd-supply
Please include this patch in imx@lists.linux.dev next time. I will not
track this patches status. If it Acked or applied, let me know.
Frank
>
> .../devicetree/bindings/rtc/microcrystal,rv3028.yaml | 2 ++
> arch/arm64/boot/dts/freescale/imx8mp-kontron-osm-s.dtsi | 6 ++++++
> 2 files changed, 8 insertions(+)
>
> --
> 2.53.0
>
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: rtc: microcrystal,rv3028: Allow to specify vdd-supply
From: Frieder Schrempf @ 2026-03-09 8:57 UTC (permalink / raw)
To: Alexandre Belloni, Conor Dooley, devicetree, Krzysztof Kozlowski,
linux-kernel, linux-rtc, Rob Herring
Cc: Frieder Schrempf
In-Reply-To: <20260309085749.25747-1-frieder@fris.de>
From: Frieder Schrempf <frieder.schrempf@kontron.de>
In case the VDD supply voltage regulator of the RTC needs to be
specified explicitly, allow to set vdd-supply.
Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
---
Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
index cda8ad7c12037..2ea3b40419530 100644
--- a/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
+++ b/Documentation/devicetree/bindings/rtc/microcrystal,rv3028.yaml
@@ -32,6 +32,8 @@ properties:
- 9000
- 15000
+ vdd-supply: true
+
required:
- compatible
- reg
--
2.53.0
^ permalink raw reply related
* [PATCH v3 0/2] Kontron i.MX8MP OSM Devicetree Fixups
From: Frieder Schrempf @ 2026-03-09 8:57 UTC (permalink / raw)
To: Alexandre Belloni, Conor Dooley, devicetree, Frank Li,
Frieder Schrempf, imx, Krzysztof Kozlowski, linux-arm-kernel,
linux-kernel, linux-rtc, Rob Herring, Sascha Hauer, Shawn Guo
Cc: Annette Kobou, Fabio Estevam, Pengutronix Kernel Team
From: Frieder Schrempf <frieder.schrempf@kontron.de>
This contains three fixes and one cosmetic change for
the Kontron i.MX8MP OSM devices.
Changes for v3:
* Drop applied patches
* Add missing bindings patch for RV3028 RTC
Changes for v2:
* Add Frank's R-b tags (thanks)
* Enhance commit message of patch 2
Annette Kobou (1):
arm64: dts: imx8mp-kontron: Fix boot order for PMIC and RTC
Frieder Schrempf (1):
dt-bindings: rtc: microcrystal,rv3028: Allow to specify vdd-supply
.../devicetree/bindings/rtc/microcrystal,rv3028.yaml | 2 ++
arch/arm64/boot/dts/freescale/imx8mp-kontron-osm-s.dtsi | 6 ++++++
2 files changed, 8 insertions(+)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v3 04/13] dt-bindings: power: supply: document Samsung S2M series PMIC charger device
From: Kaustabh Chakraborty @ 2026-03-08 12:13 UTC (permalink / raw)
To: Rob Herring, Kaustabh Chakraborty
Cc: Krzysztof Kozlowski, Lee Jones, Pavel Machek, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260306005057.GA877725-robh@kernel.org>
On 2026-03-05 18:50 -06:00, Rob Herring wrote:
> On Fri, Feb 27, 2026 at 07:56:58PM +0530, Kaustabh Chakraborty wrote:
>> On 2026-02-25 11:44 +01:00, Krzysztof Kozlowski wrote:
>> > On Wed, Feb 25, 2026 at 12:45:06AM +0530, Kaustabh Chakraborty wrote:
>> >> +
>> >> + This is a part of device tree bindings for S2M and S5M family of Power
>> >> + Management IC (PMIC).
>> >> +
>> >> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> >> + additional information and example.
>> >> +
>> >> +allOf:
>> >> + - $ref: power-supply.yaml#
>> >> +
>> >> +properties:
>> >> + compatible:
>> >> + enum:
>> >> + - samsung,s2mu005-charger
>> >
>> > Review from v1 still applies. I think you ignored several reviews, so I
>> > will mark entire patchset as changes requested.
>>
>> Somehow I missed this one... anyways I address them here:
>>
>> Why do you need a dedicated child node for this? It's got one property,
>> other than the compatible, that you're using. It could easily just go
>> in the parent without a dedicated node etc.
>>
>> The dt node also references a simple-battery node, that's why it's
>> required.
>
> That can go in the parent.
So the parent MFD has the following?
allOf:
- $ref: power-supply.yaml#
I'm kind of not sold on this one.
Moreover, I was planning to introduce a port to/from the MUIC in the
next revision so that would've been included here too.
>
> Rob
^ permalink raw reply
* Re: [PATCH v3 2/6] dt-binding: pinctrl: pinctrl-max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-07 13:30 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, linux-gpio,
devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260307-smiling-coyote-of-economy-317afe@quoll>
сб, 7 бер. 2026 р. о 14:48 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On Fri, Mar 06, 2026 at 03:33:47PM +0200, Svyatoslav Ryhel wrote:
> > Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> > TXT to YAML format. This patch does not change any functionality; the
> > bindings remain the same.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
> > .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> > 2 files changed, 97 insertions(+), 127 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > new file mode 100644
> > index 000000000000..7364a8bdd7d3
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> > @@ -0,0 +1,97 @@
> > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Pinmux controller function for Maxim MAX77620 Power management IC
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + Device has 8 GPIO pins which can be configured as GPIO as well as the
> > + special IO functions.
> > +
> > +allOf:
> > + - $ref: /schemas/pinctrl/pincfg-node.yaml
> > + - $ref: /schemas/pinctrl/pinmux-node.yaml
> > +
> > +patternProperties:
> > + "^(pin_gpio|gpio)[0-7_]+$":
>
> Underscores are not allowed in general, so pattern needs fixes. Does
> anything actually rely on this name? Is this ABI? I don't see old
> binding and driver using the name, thus this should be just ^pin-[0-7]$
> (+ is also not correct if you have max 8 gpios)
>
Old txt schema uses pin_gpio[0-7] hence it is here, but greping trees
did not reveal use of pin_gpio so it may be dropped.
No this is not ABI, name may be any. Including gpio0-1-2-3, gpio2-4
etc which is why + is there. or maybe you know better way to cover
those names?
There are device trees which use gpio5_6 with the underscore
(tegra210-smaug.dts; tegra210-p2894.dtsi for example). Should the
schema account for those?
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v3 4/6] dt-bindings: mfd: max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-07 13:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, linux-gpio,
devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260307-huge-excellent-tench-0afefc@quoll>
сб, 7 бер. 2026 р. о 14:46 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On Fri, Mar 06, 2026 at 03:33:49PM +0200, Svyatoslav Ryhel wrote:
> > + #include <dt-bindings/interrupt-controller/arm-gic.h>
> > + #include <dt-bindings/mfd/max77620.h>
> > +
> > + i2c {
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + pmic@3c {
> > + compatible = "maxim,max77620";
> > + reg = <0x3c>;
> > +
> > + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
>
> This is odd interrupt. It's I2C device, so how can it be GIC?
>
I have used layout from Tegra device. I will switch to smth simpler.
> > + #interrupt-cells = <2>;
> > + interrupt-controller;
> > +
> > + #gpio-cells = <2>;
> > + gpio-controller;
> > +
> > + #thermal-sensor-cells = <0>;
> > +
> > + system-power-controller;
> > +
> > + pinctrl-names = "default";
> > + pinctrl-0 = <&max77620_default>;
> > +
> > + max77620_default: pinmux {
> > + gpio0 {
> > + pins = "gpio0";
> > + function = "gpio";
> > + };
> > +
> > + gpio1 {
> > + pins = "gpio1";
> > + function = "fps-out";
> > + maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
> > + };
>
> Messed indentation.
>
Acknowledged.
> > +
> > + gpio2 {
> > + pins = "gpio2";
> > + function = "fps-out";
> > + maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
> > + };
> > +
> > + gpio3 {
> > + pins = "gpio3";
> > + function = "gpio";
> > + };
> > +
> > + gpio4 {
> > + pins = "gpio4";
> > + function = "32k-out1";
> > + };
> > +
> > + gpio5_6 {
>
> No underscoers in node names. Use hyphen.
>
Acknowledged.
> > + pins = "gpio5", "gpio6";
> > + function = "gpio";
> > + drive-push-pull = <1>;
> > + };
> > +
> > + gpio7 {
> > + pins = "gpio7";
> > + function = "gpio";
> > + };
> > + };
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v3 3/6] dt-bindings: gpio: trivial-gpio: remove max77620 compatible
From: Svyatoslav Ryhel @ 2026-03-07 13:11 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, linux-gpio,
devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260307-azure-quokka-of-abracadabra-cebde4@quoll>
сб, 7 бер. 2026 р. о 14:43 Krzysztof Kozlowski <krzk@kernel.org> пише:
>
> On Fri, Mar 06, 2026 at 03:33:48PM +0200, Svyatoslav Ryhel wrote:
> > Binding for MAX77620 GPIO function is covered by the MAX77620 schema. GPIO
> > controller function in MAX77620 has no dedicated node and is folded into
> > the parent node itself.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > Documentation/devicetree/bindings/gpio/trivial-gpio.yaml | 2 --
> > 1 file changed, 2 deletions(-)
>
> This should be squashed with the converting patch for this compatible.
>
Acknowledged. Thank you.
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v3 2/6] dt-binding: pinctrl: pinctrl-max77620: convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-07 12:48 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, linux-gpio,
devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260306133351.31589-3-clamor95@gmail.com>
On Fri, Mar 06, 2026 at 03:33:47PM +0200, Svyatoslav Ryhel wrote:
> Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
> .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> 2 files changed, 97 insertions(+), 127 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> new file mode 100644
> index 000000000000..7364a8bdd7d3
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> @@ -0,0 +1,97 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/pinctrl/maxim,max77620-pinctrl.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Pinmux controller function for Maxim MAX77620 Power management IC
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + Device has 8 GPIO pins which can be configured as GPIO as well as the
> + special IO functions.
> +
> +allOf:
> + - $ref: /schemas/pinctrl/pincfg-node.yaml
> + - $ref: /schemas/pinctrl/pinmux-node.yaml
> +
> +patternProperties:
> + "^(pin_gpio|gpio)[0-7_]+$":
Underscores are not allowed in general, so pattern needs fixes. Does
anything actually rely on this name? Is this ABI? I don't see old
binding and driver using the name, thus this should be just ^pin-[0-7]$
(+ is also not correct if you have max 8 gpios)
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 4/6] dt-bindings: mfd: max77620: convert to DT schema
From: Krzysztof Kozlowski @ 2026-03-07 12:46 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, linux-gpio,
devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260306133351.31589-5-clamor95@gmail.com>
On Fri, Mar 06, 2026 at 03:33:49PM +0200, Svyatoslav Ryhel wrote:
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/mfd/max77620.h>
> +
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pmic@3c {
> + compatible = "maxim,max77620";
> + reg = <0x3c>;
> +
> + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
This is odd interrupt. It's I2C device, so how can it be GIC?
> + #interrupt-cells = <2>;
> + interrupt-controller;
> +
> + #gpio-cells = <2>;
> + gpio-controller;
> +
> + #thermal-sensor-cells = <0>;
> +
> + system-power-controller;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&max77620_default>;
> +
> + max77620_default: pinmux {
> + gpio0 {
> + pins = "gpio0";
> + function = "gpio";
> + };
> +
> + gpio1 {
> + pins = "gpio1";
> + function = "fps-out";
> + maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
> + };
Messed indentation.
> +
> + gpio2 {
> + pins = "gpio2";
> + function = "fps-out";
> + maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
> + };
> +
> + gpio3 {
> + pins = "gpio3";
> + function = "gpio";
> + };
> +
> + gpio4 {
> + pins = "gpio4";
> + function = "32k-out1";
> + };
> +
> + gpio5_6 {
No underscoers in node names. Use hyphen.
> + pins = "gpio5", "gpio6";
> + function = "gpio";
> + drive-push-pull = <1>;
> + };
> +
> + gpio7 {
> + pins = "gpio7";
> + function = "gpio";
> + };
> + };
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 3/6] dt-bindings: gpio: trivial-gpio: remove max77620 compatible
From: Krzysztof Kozlowski @ 2026-03-07 12:42 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, linux-gpio,
devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260306133351.31589-4-clamor95@gmail.com>
On Fri, Mar 06, 2026 at 03:33:48PM +0200, Svyatoslav Ryhel wrote:
> Binding for MAX77620 GPIO function is covered by the MAX77620 schema. GPIO
> controller function in MAX77620 has no dedicated node and is folded into
> the parent node itself.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> Documentation/devicetree/bindings/gpio/trivial-gpio.yaml | 2 --
> 1 file changed, 2 deletions(-)
This should be squashed with the converting patch for this compatible.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/6] Remove use of i2c_match_id in RTC
From: Alexandre Belloni @ 2026-03-07 0:09 UTC (permalink / raw)
To: Andrew Davis; +Cc: linux-rtc, linux-kernel
In-Reply-To: <5c4c2470-70ee-4dd4-b769-9f26206145d4@ti.com>
On 06/03/2026 09:01:00-0600, Andrew Davis wrote:
> On 3/5/26 5:07 PM, Alexandre Belloni wrote:
> > On 05/03/2026 13:35:39-0600, Andrew Davis wrote:
> > > Hello all,
> > >
> > > RTC subsystem is one of the last still using i2c_match_id().
> > > This is a v2 but nothing is changed from last time. If I'm
> > > not sending this to the right folks let me know.
> >
> > Do you mean that you intend to remove i2c_match_id from the kernel?
> >
>
> Yes, once I remove all users in the various subsystems (like RTC),
> I'll remove it from the I2C headers.
>
> It should be replaced with functions like i2c_get_match_data()
> for reasons given in the commit messages.
Ok, this should have been made clear in the original cover letter, the
series would have looked a bit less like unnecessary churn.
>
> Andrew
>
> > >
> > > Thanks,
> > > Andrew
> > >
> > > Andrew Davis (6):
> > > rtc: abx80x: Remove use of i2c_match_id()
> > > rtc: m41t80: Remove use of i2c_match_id()
> > > rtc: pcf2127: Remove use of i2c_match_id()
> > > rtc: rs5c372: Remove use of i2c_match_id()
> > > rtc: rv8803: Remove use of i2c_match_id()
> > > rtc: rx8025: Remove use of i2c_match_id()
> > >
> > > drivers/rtc/rtc-abx80x.c | 3 +--
> > > drivers/rtc/rtc-m41t80.c | 8 +-------
> > > drivers/rtc/rtc-pcf2127.c | 23 +++++++----------------
> > > drivers/rtc/rtc-rs5c372.c | 7 +------
> > > drivers/rtc/rtc-rv8803.c | 8 +-------
> > > drivers/rtc/rtc-rx8025.c | 4 +---
> > > 6 files changed, 12 insertions(+), 41 deletions(-)
> > >
> > > --
> > > 2.39.2
> > >
> >
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 2/6] dt-binding: pinctrl: pinctrl-max77620: convert to DT schema
From: Rob Herring (Arm) @ 2026-03-06 15:33 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Mark Brown, Bartosz Golaszewski, Rafael J. Wysocki, linux-rtc,
Alexandre Belloni, Lee Jones, Zhang Rui, Krzysztof Kozlowski,
devicetree, linux-kernel, Liam Girdwood, linux-pm, Linus Walleij,
Chanwoo Choi, Conor Dooley, linux-gpio, Daniel Lezcano,
Lukasz Luba
In-Reply-To: <20260306133351.31589-3-clamor95@gmail.com>
On Fri, 06 Mar 2026 15:33:47 +0200, Svyatoslav Ryhel wrote:
> Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../pinctrl/maxim,max77620-pinctrl.yaml | 97 +++++++++++++
> .../bindings/pinctrl/pinctrl-max77620.txt | 127 ------------------
> 2 files changed, 97 insertions(+), 127 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml
> delete mode 100644 Documentation/devicetree/bindings/pinctrl/pinctrl-max77620.txt
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml: patternProperties:^(pin_gpio|gpio)[0-7_]+$:properties:pins: 'enum' should not be valid under {'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum', 'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/pinctrl/maxim,max77620-pinctrl.yaml: patternProperties:^(pin_gpio|gpio)[0-7_]+$:properties:pins: 'enum' should not be valid under {'enum': ['const', 'enum', 'exclusiveMaximum', 'exclusiveMinimum', 'minimum', 'maximum', 'multipleOf', 'pattern']}
hint: Scalar and array keywords cannot be mixed
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260306133351.31589-3-clamor95@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 0/6] Remove use of i2c_match_id in RTC
From: Andrew Davis @ 2026-03-06 15:01 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel
In-Reply-To: <20260305230725ffa875be@mail.local>
On 3/5/26 5:07 PM, Alexandre Belloni wrote:
> On 05/03/2026 13:35:39-0600, Andrew Davis wrote:
>> Hello all,
>>
>> RTC subsystem is one of the last still using i2c_match_id().
>> This is a v2 but nothing is changed from last time. If I'm
>> not sending this to the right folks let me know.
>
> Do you mean that you intend to remove i2c_match_id from the kernel?
>
Yes, once I remove all users in the various subsystems (like RTC),
I'll remove it from the I2C headers.
It should be replaced with functions like i2c_get_match_data()
for reasons given in the commit messages.
Andrew
>>
>> Thanks,
>> Andrew
>>
>> Andrew Davis (6):
>> rtc: abx80x: Remove use of i2c_match_id()
>> rtc: m41t80: Remove use of i2c_match_id()
>> rtc: pcf2127: Remove use of i2c_match_id()
>> rtc: rs5c372: Remove use of i2c_match_id()
>> rtc: rv8803: Remove use of i2c_match_id()
>> rtc: rx8025: Remove use of i2c_match_id()
>>
>> drivers/rtc/rtc-abx80x.c | 3 +--
>> drivers/rtc/rtc-m41t80.c | 8 +-------
>> drivers/rtc/rtc-pcf2127.c | 23 +++++++----------------
>> drivers/rtc/rtc-rs5c372.c | 7 +------
>> drivers/rtc/rtc-rv8803.c | 8 +-------
>> drivers/rtc/rtc-rx8025.c | 4 +---
>> 6 files changed, 12 insertions(+), 41 deletions(-)
>>
>> --
>> 2.39.2
>>
>
^ permalink raw reply
* Re: [PATCH v3 1/6] regulator: dt-binding: regulator-max77620: convert to DT schema
From: Mark Brown @ 2026-03-06 13:39 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Chanwoo Choi, Alexandre Belloni, linux-gpio, devicetree,
linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260306133351.31589-2-clamor95@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 285 bytes --]
On Fri, Mar 06, 2026 at 03:33:46PM +0200, Svyatoslav Ryhel wrote:
> Convert regulator-max77620 devicetree bindings for the MAX77620 PMIC from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
Acked-by: Mark Brown <broonie@kernel.org>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v3 6/6] rtc: max77686: convert to i2c_new_ancillary_device
From: Svyatoslav Ryhel @ 2026-03-06 13:33 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260306133351.31589-1-clamor95@gmail.com>
Convert RTC I2C device creation from devm_i2c_new_dummy_device() to
i2c_new_ancillary_device() to enable the use of a device tree-specified
RTC address instead of a hardcoded value. If the device tree does not
provide an address, use hardcoded values as a fallback.
This addresses an issue with the MAX77663 PMIC, which can have the RTC at
different I2C positions (either 0x48, like the MAX77714, or 0x68, like
the MAX77620). The MAX77620 value is used as the default. The I2C position
of the MAX77663 is factory-set and cannot be detected from the chip
itself.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
drivers/rtc/rtc-max77686.c | 14 ++++++++++++--
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-max77686.c b/drivers/rtc/rtc-max77686.c
index 69ea3ce75b5a..3cdfd78a07cc 100644
--- a/drivers/rtc/rtc-max77686.c
+++ b/drivers/rtc/rtc-max77686.c
@@ -686,6 +686,11 @@ static int max77686_rtc_init_reg(struct max77686_rtc_info *info)
return ret;
}
+static void max77686_rtc_release_dev(void *client)
+{
+ i2c_unregister_device(client);
+}
+
static int max77686_init_rtc_regmap(struct max77686_rtc_info *info)
{
struct device *parent = info->dev->parent;
@@ -713,12 +718,17 @@ static int max77686_init_rtc_regmap(struct max77686_rtc_info *info)
goto add_rtc_irq;
}
- client = devm_i2c_new_dummy_device(info->dev, parent_i2c->adapter,
- info->drv_data->rtc_i2c_addr);
+ client = i2c_new_ancillary_device(parent_i2c, "rtc",
+ info->drv_data->rtc_i2c_addr);
if (IS_ERR(client))
return dev_err_probe(info->dev, PTR_ERR(client),
"Failed to allocate I2C device for RTC\n");
+ ret = devm_add_action_or_reset(info->dev, max77686_rtc_release_dev,
+ client);
+ if (ret)
+ return ret;
+
info->rtc_regmap = devm_regmap_init_i2c(client,
info->drv_data->regmap_config);
if (IS_ERR(info->rtc_regmap))
--
2.51.0
^ permalink raw reply related
* [PATCH v3 5/6] dt-bindings: mfd: max77620: document optional RTC address for MAX77663
From: Svyatoslav Ryhel @ 2026-03-06 13:33 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260306133351.31589-1-clamor95@gmail.com>
Document an optional second I2C address for the MAX77663 PMIC's RTC
device, to be used if the MAX77663 RTC is located at a non-default I2C
address.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../bindings/mfd/maxim,max77620.yaml | 22 ++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
index 42cbad56595f..246c7f9e572d 100644
--- a/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
@@ -17,7 +17,17 @@ properties:
- maxim,max77663
reg:
- maxItems: 1
+ description:
+ Can contain an optional second I2C address pointing to the PMIC's
+ RTC device. If no RTC address is provided, a default address specific
+ to this PMIC will be used.
+ minItems: 1
+ maxItems: 2
+
+ reg-names:
+ items:
+ - const: pmic
+ - const: rtc
interrupts:
maxItems: 1
@@ -192,6 +202,16 @@ allOf:
maxim,suspend-fps-time-period-us:
enum: [40, 80, 160, 320, 640, 1280, 2560, 5120]
+ - if:
+ properties:
+ compatible:
+ not:
+ contains:
+ const: maxim,max77663
+ then:
+ properties:
+ reg-names: false
+
required:
- compatible
- reg
--
2.51.0
^ permalink raw reply related
* [PATCH v3 4/6] dt-bindings: mfd: max77620: convert to DT schema
From: Svyatoslav Ryhel @ 2026-03-06 13:33 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260306133351.31589-1-clamor95@gmail.com>
Convert max77620 devicetree bindings from TXT to YAML format. This patch
does not change any functionality; the bindings remain the same. The
thermal bindings are incorporated into the binding.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../devicetree/bindings/mfd/max77620.txt | 162 -------
.../bindings/mfd/maxim,max77620.yaml | 422 ++++++++++++++++++
.../bindings/thermal/max77620_thermal.txt | 70 ---
3 files changed, 422 insertions(+), 232 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mfd/max77620.txt
create mode 100644 Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
delete mode 100644 Documentation/devicetree/bindings/thermal/max77620_thermal.txt
diff --git a/Documentation/devicetree/bindings/mfd/max77620.txt b/Documentation/devicetree/bindings/mfd/max77620.txt
deleted file mode 100644
index 5a642a51d58e..000000000000
--- a/Documentation/devicetree/bindings/mfd/max77620.txt
+++ /dev/null
@@ -1,162 +0,0 @@
-MAX77620 Power management IC from Maxim Semiconductor.
-
-Required properties:
--------------------
-- compatible: Must be one of
- "maxim,max77620"
- "maxim,max20024"
- "maxim,max77663"
-- reg: I2C device address.
-
-Optional properties:
--------------------
-- interrupts: The interrupt on the parent the controller is
- connected to.
-- interrupt-controller: Marks the device node as an interrupt controller.
-- #interrupt-cells: is <2> and their usage is compliant to the 2 cells
- variant of <../interrupt-controller/interrupts.txt>
- IRQ numbers for different interrupt source of MAX77620
- are defined at dt-bindings/mfd/max77620.h.
-
-- system-power-controller: Indicates that this PMIC is controlling the
- system power, see [1] for more details.
-
-[1] Documentation/devicetree/bindings/power/power-controller.txt
-
-Optional subnodes and their properties:
-=======================================
-
-Flexible power sequence configurations:
---------------------------------------
-The Flexible Power Sequencer (FPS) allows each regulator to power up under
-hardware or software control. Additionally, each regulator can power on
-independently or among a group of other regulators with an adjustable power-up
-and power-down delays (sequencing). GPIO1, GPIO2, and GPIO3 can be programmed
-to be part of a sequence allowing external regulators to be sequenced along
-with internal regulators. 32KHz clock can be programmed to be part of a
-sequence.
-
-The flexible sequencing structure consists of two hardware enable inputs
-(EN0, EN1), and 3 master sequencing timers called FPS0, FPS1 and FPS2.
-Each master sequencing timer is programmable through its configuration
-register to have a hardware enable source (EN1 or EN2) or a software enable
-source (SW). When enabled/disabled, the master sequencing timer generates
-eight sequencing events on different time periods called slots. The time
-period between each event is programmable within the configuration register.
-Each regulator, GPIO1, GPIO2, GPIO3, and 32KHz clock has a flexible power
-sequence slave register which allows its enable source to be specified as
-a flexible power sequencer timer or a software bit. When a FPS source of
-regulators, GPIOs and clocks specifies the enable source to be a flexible
-power sequencer, the power up and power down delays can be specified in
-the regulators, GPIOs and clocks flexible power sequencer configuration
-registers.
-
-When FPS event cleared (set to LOW), regulators, GPIOs and 32KHz
-clock are set into following state at the sequencing event that
-corresponds to its flexible sequencer configuration register.
- Sleep state: In this state, regulators, GPIOs
- and 32KHz clock get disabled at
- the sequencing event.
- Global Low Power Mode (GLPM): In this state, regulators are set in
- low power mode at the sequencing event.
-
-The configuration parameters of FPS is provided through sub-node "fps"
-and their child for FPS specific. The child node name for FPS are "fps0",
-"fps1", and "fps2" for FPS0, FPS1 and FPS2 respectively.
-
-The FPS configurations like FPS source, power up and power down slots for
-regulators, GPIOs and 32kHz clocks are provided in their respective
-configuration nodes which is explained in respective sub-system DT
-binding document.
-
-There is need for different FPS configuration parameters based on system
-state like when system state changed from active to suspend or active to
-power off (shutdown).
-
-Optional properties:
--------------------
--maxim,fps-event-source: u32, FPS event source like external
- hardware input to PMIC i.e. EN0, EN1 or
- software (SW).
- The macros are defined on
- dt-bindings/mfd/max77620.h
- for different control source.
- - MAX77620_FPS_EVENT_SRC_EN0
- for hardware input pin EN0.
- - MAX77620_FPS_EVENT_SRC_EN1
- for hardware input pin EN1.
- - MAX77620_FPS_EVENT_SRC_SW
- for software control.
-
--maxim,shutdown-fps-time-period-us: u32, FPS time period in microseconds
- when system enters in to shutdown
- state.
-
--maxim,suspend-fps-time-period-us: u32, FPS time period in microseconds
- when system enters in to suspend state.
-
--maxim,device-state-on-disabled-event: u32, describe the PMIC state when FPS
- event cleared (set to LOW) whether it
- should go to sleep state or low-power
- state. Following are valid values:
- - MAX77620_FPS_INACTIVE_STATE_SLEEP
- to set the PMIC state to sleep.
- - MAX77620_FPS_INACTIVE_STATE_LOW_POWER
- to set the PMIC state to low
- power.
- Absence of this property or other value
- will not change device state when FPS
- event get cleared.
-
-Here supported time periods by device in microseconds are as follows:
-MAX77620 supports 40, 80, 160, 320, 640, 1280, 2560 and 5120 microseconds.
-MAX20024 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds.
-MAX77663 supports 20, 40, 80, 160, 320, 640, 1280 and 2540 microseconds.
-
--maxim,power-ok-control: configure map power ok bit
- 1: Enables POK(Power OK) to control nRST_IO and GPIO1
- POK function.
- 0: Disables POK control.
- if property missing, do not configure MPOK bit.
- If POK mapping is enabled for GPIO1/nRST_IO then,
- GPIO1/nRST_IO pins are HIGH only if all rails
- that have POK control enabled are HIGH.
- If any of the rails goes down(which are enabled for POK
- control) then, GPIO1/nRST_IO goes LOW.
- this property is valid for max20024 only.
-
-For DT binding details of different sub modules like GPIO, pincontrol,
-regulator, power, please refer respective device-tree binding document
-under their respective sub-system directories.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-
-max77620@3c {
- compatible = "maxim,max77620";
- reg = <0x3c>;
-
- interrupt-parent = <&intc>;
- interrupts = <0 86 IRQ_TYPE_NONE>;
-
- interrupt-controller;
- #interrupt-cells = <2>;
-
- fps {
- fps0 {
- maxim,shutdown-fps-time-period-us = <1280>;
- maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN1>;
- };
-
- fps1 {
- maxim,shutdown-fps-time-period-us = <1280>;
- maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>;
- };
-
- fps2 {
- maxim,shutdown-fps-time-period-us = <1280>;
- maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_SW>;
- };
- };
-};
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
new file mode 100644
index 000000000000..42cbad56595f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77620.yaml
@@ -0,0 +1,422 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mfd/maxim,max77620.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MAX77620 Power management IC from Maxim Semiconductor
+
+maintainers:
+ - Svyatoslav Ryhel <clamor95@gmail.com>
+
+properties:
+ compatible:
+ enum:
+ - maxim,max20024
+ - maxim,max77620
+ - maxim,max77663
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ interrupt-controller: true
+
+ "#interrupt-cells":
+ const: 2
+
+ gpio-controller: true
+
+ "#gpio-cells":
+ const: 2
+ description:
+ Device has 8 GPIO pins which can be configured as GPIO as well as
+ the special IO functions. The first cell is the pin number, and the
+ second cell is used to specify the gpio polarity (GPIO_ACTIVE_HIGH or
+ GPIO_ACTIVE_LOW).
+
+ system-power-controller: true
+
+ "#thermal-sensor-cells":
+ const: 0
+ description:
+ Maxim Semiconductor MAX77620 supports alarm interrupts when its
+ die temperature crosses 120C and 140C. These threshold temperatures
+ are not configurable. Device does not provide the real temperature
+ of die other than just indicating whether temperature is above or
+ below threshold level.
+
+ fps:
+ type: object
+ additionalProperties: false
+ description: |
+ The Flexible Power Sequencer (FPS) allows each regulator to power up
+ under hardware or software control. Additionally, each regulator can
+ power on independently or among a group of other regulators with an
+ adjustable power-up and power-down delays (sequencing). GPIO1, GPIO2,
+ and GPIO3 can be programmed to be part of a sequence allowing external
+ regulators to be sequenced along with internal regulators. 32KHz clock
+ can be programmed to be part of a sequence.
+
+ The flexible sequencing structure consists of two hardware enable inputs
+ (EN0, EN1), and 3 master sequencing timers called FPS0, FPS1 and FPS2.
+ Each master sequencing timer is programmable through its configuration
+ register to have a hardware enable source (EN1 or EN2) or a software enable
+ source (SW). When enabled/disabled, the master sequencing timer generates
+ eight sequencing events on different time periods called slots. The time
+ period between each event is programmable within the configuration register.
+ Each regulator, GPIO1, GPIO2, GPIO3, and 32KHz clock has a flexible power
+ sequence slave register which allows its enable source to be specified as
+ a flexible power sequencer timer or a software bit. When a FPS source of
+ regulators, GPIOs and clocks specifies the enable source to be a flexible
+ power sequencer, the power up and power down delays can be specified in
+ the regulators, GPIOs and clocks flexible power sequencer configuration
+ registers.
+
+ When FPS event cleared (set to LOW), regulators, GPIOs and 32KHz clock
+ are set into following state at the sequencing event that corresponds
+ to its flexible sequencer configuration register.
+
+ Sleep state: In this state, regulators, GPIOs and 32KHz clock get disabled
+ at the sequencing event.
+ Global Low Power Mode (GLPM): In this state, regulators are set in low
+ power mode at the sequencing event.
+
+ The configuration parameters of FPS is provided through sub-node "fps"
+ and their child for FPS specific. The child node name for FPS are "fps0",
+ "fps1", and "fps2" for FPS0, FPS1 and FPS2 respectively.
+
+ The FPS configurations like FPS source, power up and power down slots for
+ regulators, GPIOs and 32kHz clocks are provided in their respective
+ configuration nodes which is explained in respective sub-system DT
+ binding document.
+
+ There is need for different FPS configuration parameters based on system
+ state like when system state changed from active to suspend or active to
+ power off (shutdown).
+
+ patternProperties:
+ "^fps[0-2]$":
+ type: object
+ additionalProperties: false
+
+ properties:
+ maxim,fps-event-source:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ FPS event source like external hardware input to PMIC i.e. EN0, EN1
+ or software (SW).
+
+ The macros are defined on dt-bindings/mfd/max77620.h for different
+ control source.
+ - MAX77620_FPS_EVENT_SRC_EN0 for hardware input pin EN0.
+ - MAX77620_FPS_EVENT_SRC_EN1 for hardware input pin EN1.
+ - MAX77620_FPS_EVENT_SRC_SW for software control.
+
+ maxim,shutdown-fps-time-period-us:
+ description:
+ FPS time period in microseconds when system enters in to shutdown state.
+
+ maxim,suspend-fps-time-period-us:
+ description:
+ FPS time period in microseconds when system enters in to suspend state.
+
+ maxim,device-state-on-disabled-event:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Describe the PMIC state when FPS event cleared (set to LOW) whether it
+ should go to sleep state or low-power state. Following are valid values:
+ - MAX77620_FPS_INACTIVE_STATE_SLEEP to set the PMIC state to sleep.
+ - MAX77620_FPS_INACTIVE_STATE_LOW_POWER to set the PMIC state to low
+ power.
+ Absence of this property or other value will not change device state
+ when FPS event get cleared.
+
+ maxim,power-ok-control:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description: |
+ Configure map power ok bit
+
+ 1: Enables POK(Power OK) to control nRST_IO and GPIO1 POK function.
+ 0: Disables POK control.
+
+ If property missing, do not configure MPOK bit. If POK mapping is
+ enabled for GPIO1/nRST_IO then, GPIO1/nRST_IO pins are HIGH only if
+ all rails that have POK control enabled are HIGH. If any of the rails
+ goes down (which are enabled for POK control) then, GPIO1/nRST_IO
+ goes LOW.
+ enum: [0, 1]
+
+ pinmux:
+ $ref: /schemas/pinctrl/maxim,max77620-pinctrl.yaml
+
+ regulators:
+ $ref: /schemas/regulator/maxim,max77620-regulator.yaml
+
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - maxim,max20024
+ - maxim,max77663
+ then:
+ properties:
+ "#thermal-sensor-cells": false
+ fps:
+ patternProperties:
+ "^fps[0-2]$":
+ properties:
+ maxim,shutdown-fps-time-period-us:
+ enum: [20, 40, 80, 160, 320, 640, 1280, 2540]
+ maxim,suspend-fps-time-period-us:
+ enum: [20, 40, 80, 160, 320, 640, 1280, 2540]
+ maxim,power-ok-control: false
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: maxim,max77620
+ then:
+ properties:
+ fps:
+ patternProperties:
+ "^fps[0-2]$":
+ properties:
+ maxim,shutdown-fps-time-period-us:
+ enum: [40, 80, 160, 320, 640, 1280, 2560, 5120]
+ maxim,suspend-fps-time-period-us:
+ enum: [40, 80, 160, 320, 640, 1280, 2560, 5120]
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+ #include <dt-bindings/mfd/max77620.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@3c {
+ compatible = "maxim,max77620";
+ reg = <0x3c>;
+
+ interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ #thermal-sensor-cells = <0>;
+
+ system-power-controller;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&max77620_default>;
+
+ max77620_default: pinmux {
+ gpio0 {
+ pins = "gpio0";
+ function = "gpio";
+ };
+
+ gpio1 {
+ pins = "gpio1";
+ function = "fps-out";
+ maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
+ };
+
+ gpio2 {
+ pins = "gpio2";
+ function = "fps-out";
+ maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
+ };
+
+ gpio3 {
+ pins = "gpio3";
+ function = "gpio";
+ };
+
+ gpio4 {
+ pins = "gpio4";
+ function = "32k-out1";
+ };
+
+ gpio5_6 {
+ pins = "gpio5", "gpio6";
+ function = "gpio";
+ drive-push-pull = <1>;
+ };
+
+ gpio7 {
+ pins = "gpio7";
+ function = "gpio";
+ };
+ };
+
+ fps {
+ fps0 {
+ maxim,shutdown-fps-time-period-us = <1280>;
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN0>;
+ };
+
+ fps1 {
+ maxim,shutdown-fps-time-period-us = <1280>;
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_EN1>;
+ };
+
+ fps2 {
+ maxim,shutdown-fps-time-period-us = <1280>;
+ maxim,fps-event-source = <MAX77620_FPS_EVENT_SRC_SW>;
+ };
+ };
+
+ regulators {
+ in-sd0-supply = <&vdd_5v0_vbus>;
+ in-sd1-supply = <&vdd_5v0_vbus>;
+ in-sd2-supply = <&vdd_5v0_vbus>;
+ in-sd3-supply = <&vdd_5v0_vbus>;
+
+ in-ldo0-1-supply = <&vdd_1v8_vio>;
+ in-ldo2-supply = <&vdd_3v3_vbat>;
+ in-ldo3-5-supply = <&vdd_3v3_vbat>;
+ in-ldo4-6-supply = <&vdd_3v3_vbat>;
+ in-ldo7-8-supply = <&vdd_1v8_vio>;
+
+ sd0 {
+ regulator-name = "vdd_cpu";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1250000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ sd1 {
+ regulator-name = "vdd_core";
+ regulator-min-microvolt = <950000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
+ };
+
+ vdd_1v8_vio: sd2 {
+ regulator-name = "vdd_1v8_gen";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ sd3 {
+ regulator-name = "vddio_ddr";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo0 {
+ regulator-name = "avdd_pll";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_1>;
+ };
+
+ ldo1 {
+ regulator-name = "vdd_ddr_hs";
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo2 {
+ regulator-name = "avdd_usb";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo3 {
+ regulator-name = "vdd_sdmmc3";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3000000>;
+ regulator-always-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo4 {
+ regulator-name = "vdd_rtc";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
+ };
+
+ ldo5 {
+ regulator-name = "vdd_ddr_rx";
+ regulator-min-microvolt = <2850000>;
+ regulator-max-microvolt = <2850000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_0>;
+ };
+
+ ldo6 {
+ regulator-name = "avdd_osc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ regulator-boot-on;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo7 {
+ regulator-name = "vdd_1v2_mhl";
+ regulator-min-microvolt = <1050000>;
+ regulator-max-microvolt = <1250000>;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+
+ ldo8 {
+ regulator-name = "avdd_dsi_csi";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+
+ maxim,active-fps-source = <MAX77620_FPS_SRC_NONE>;
+ };
+ };
+ };
+ };
+...
diff --git a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt b/Documentation/devicetree/bindings/thermal/max77620_thermal.txt
deleted file mode 100644
index 82ed5d487966..000000000000
--- a/Documentation/devicetree/bindings/thermal/max77620_thermal.txt
+++ /dev/null
@@ -1,70 +0,0 @@
-Thermal driver for MAX77620 Power management IC from Maxim Semiconductor.
-
-Maxim Semiconductor MAX77620 supports alarm interrupts when its
-die temperature crosses 120C and 140C. These threshold temperatures
-are not configurable. Device does not provide the real temperature
-of die other than just indicating whether temperature is above or
-below threshold level.
-
-Required properties:
--------------------
-#thermal-sensor-cells: For more details, please refer to
- <devicetree/bindings/thermal/thermal-sensor.yaml>
- The value must be 0.
-
-For more details, please refer generic thermal DT binding document
-<devicetree/bindings/thermal/thermal*.yaml>.
-
-Please refer <devicetree/bindings/mfd/max77620.txt> for mfd DT binding
-document for the MAX77620.
-
-Example:
---------
-#include <dt-bindings/mfd/max77620.h>
-#include <dt-bindings/thermal/thermal.h>
-...
-
-i2c@7000d000 {
- spmic: max77620@3c {
- compatible = "maxim,max77620";
- :::::
- #thermal-sensor-cells = <0>;
- :::
- };
-};
-
-cool_dev: cool-dev {
- compatible = "cooling-dev";
- #cooling-cells = <2>;
-};
-
-thermal-zones {
- PMIC-Die {
- polling-delay = <0>;
- polling-delay-passive = <0>;
- thermal-sensors = <&spmic>;
-
- trips {
- pmic_die_warn_temp_thresh: hot-die {
- temperature = <120000>;
- type = "hot";
- hysteresis = <0>;
- };
-
- pmic_die_cirt_temp_thresh: cirtical-die {
- temperature = <140000>;
- type = "critical";
- hysteresis = <0>;
- };
- };
-
- cooling-maps {
- map0 {
- trip = <&pmic_die_warn_temp_thresh>;
- cooling-device = <&cool_dev THERMAL_NO_LIMIT
- THERMAL_NO_LIMIT>;
- contribution = <100>;
- };
- };
- };
-};
--
2.51.0
^ permalink raw reply related
* [PATCH v3 3/6] dt-bindings: gpio: trivial-gpio: remove max77620 compatible
From: Svyatoslav Ryhel @ 2026-03-06 13:33 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Liam Girdwood,
Mark Brown, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Chanwoo Choi, Alexandre Belloni, Svyatoslav Ryhel
Cc: linux-gpio, devicetree, linux-kernel, linux-pm, linux-rtc
In-Reply-To: <20260306133351.31589-1-clamor95@gmail.com>
Binding for MAX77620 GPIO function is covered by the MAX77620 schema. GPIO
controller function in MAX77620 has no dedicated node and is folded into
the parent node itself.
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
Documentation/devicetree/bindings/gpio/trivial-gpio.yaml | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml b/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml
index 3f4bbd57fc52..fe9b14a72d69 100644
--- a/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml
+++ b/Documentation/devicetree/bindings/gpio/trivial-gpio.yaml
@@ -27,7 +27,6 @@ properties:
- gateworks,pld-gpio
- ibm,ppc4xx-gpio
- loongson,ls1x-gpio
- - maxim,max77620
- nintendo,hollywood-gpio
- nxp,pca9570
- nxp,pca9571
@@ -86,7 +85,6 @@ allOf:
compatible:
contains:
enum:
- - maxim,max77620
- rockchip,rk3328-grf-gpio
- ti,lp3943-gpio
- ti,palmas-gpio
--
2.51.0
^ 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