* Re: (subset) [PATCH 00/27] clk: remove deprecated API divider_round_rate() and friends
From: Vinod Koul @ 2026-02-04 15:44 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney
Cc: linux-clk, linux-kernel, Chen Wang, Inochi Amaoto, sophgo,
Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec, Samuel Holland,
linux-arm-kernel, linux-sunxi, Alexandre Belloni, linux-rtc,
Andreas Färber, Manivannan Sadhasivam, linux-actions,
Keguang Zhang, linux-mips, Taichi Sugaya, Takao Orito,
Jacky Huang, Shan-Chun Hung, Vladimir Zapolskiy,
Piotr Wojtaszczyk, Bjorn Andersson, linux-arm-msm, Orson Zhai,
Baolin Wang, Chunyan Zhang, Maxime Coquelin, Alexandre Torgue,
linux-stm32, Michal Simek, Rob Clark, Dmitry Baryshkov,
David Airlie, Simona Vetter, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, dri-devel, freedreno, Neil Armstrong,
linux-phy
In-Reply-To: <20260108-clk-divider-round-rate-v1-0-535a3ed73bf3@redhat.com>
On Thu, 08 Jan 2026 16:16:18 -0500, Brian Masney wrote:
> Here's a series that gets rid of the deprecated APIs
> divider_round_rate(), divider_round_rate_parent(), and
> divider_ro_round_rate_parent() since these functions are just wrappers
> for the determine_rate variant.
>
> Note that when I converted some of these drivers from round_rate to
> determine_rate, this was mistakenly converted to the following in some
> cases:
>
> [...]
Applied, thanks!
[25/27] phy: ti: phy-j721e-wiz: convert from divider_round_rate() to divider_determine_rate()
commit: dbeea86fecef7cf2b93aded4525d74f6277376ef
Best regards,
--
~Vinod
^ permalink raw reply
* Re: [PATCH v2 08/12] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: André Draszik @ 2026-02-04 16:55 UTC (permalink / raw)
To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, Krzysztof Kozlowski, Alexandre Belloni,
Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <20260126-s2mu005-pmic-v2-8-78f1a75f547a@disroot.org>
Hi,
On Mon, 2026-01-26 at 00:37 +0530, 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 | 410 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 423 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..1be2745c475bf
> --- /dev/null
> +++ b/drivers/leds/flash/leds-s2m-flash.c
> @@ -0,0 +1,410 @@
> +// 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 {
> + struct device *dev;
> + struct regmap *regmap;
> + struct led_classdev_flash cdev;
> + struct v4l2_flash *v4l2_flash;
> + struct mutex lock;
Please add a (brief) comment describing what the mutex protects.
> + const struct s2m_fled_spec *spec;
> + unsigned int pmic_revision;
> + u8 channel;
> + u8 flash_brightness;
> + u8 flash_timeout;
> +};
> +
> +struct s2m_fled_spec {
> + u8 num_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);
> + const struct led_flash_ops *flash_ops;
> +};
> +
> +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)
> +{
> + return container_of(cdev, struct s2m_fled, cdev);
> +}
> +
> +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 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;
> + u8 channel = priv->channel;
> + unsigned int reg_enable;
> + int ret;
> +
> + mutex_lock(&priv->lock);
> +
> + /*
> + * Get the LED enable register address. Revision EVT0 has the
> + * register at CTRL4, while EVT1 and higher have it at CTRL6.
> + */
> + if (priv->pmic_revision == 0)
> + reg_enable = S2MU005_REG_FLED_CTRL4;
> + else
> + reg_enable = S2MU005_REG_FLED_CTRL6;
You could REG_FIELD() and friends for this and everywhere else with
similar if / else.
> +
> + if (value == LED_OFF) {
> + ret = regmap_clear_bits(regmap, reg_enable,
> + S2MU005_FLED_TORCH_EN(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(channel),
> + 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, reg_enable, S2MU005_FLED_TORCH_EN(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;
> + u8 channel = priv->channel;
> + unsigned int reg_enable;
> + int ret;
> +
> + mutex_lock(&priv->lock);
> +
> + /*
> + * Get the LED enable register address. Revision EVT0 has the
> + * register at CTRL4, while EVT1 and higher have it at CTRL6.
> + */
> + if (priv->pmic_revision == 0)
> + reg_enable = S2MU005_REG_FLED_CTRL4;
> + else
> + reg_enable = S2MU005_REG_FLED_CTRL6;
> +
> + ret = regmap_clear_bits(regmap, reg_enable, S2MU005_FLED_FLASH_EN(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(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(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, reg_enable, S2MU005_FLED_FLASH_EN(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;
> + u8 channel = priv->channel;
> + 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 const struct s2m_fled_spec s2mu005_fled_spec = {
> + .num_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 device *dev, struct fwnode_handle *fwnp,
> + struct s2m_fled *priv)
> +{
> + 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;
> +
> + 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(dev, &priv->cdev, &init_data);
> + if (ret < 0) {
> + dev_err(dev, "failed to create LED flash device\n");
> + return ret;
dev_err_probe()?
> + }
> +
> + 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(dev, fwnp, &priv->cdev,
> + &s2m_fled_v4l2_flash_ops, &v4l2_cfg);
> + if (IS_ERR(priv->v4l2_flash)) {
> + dev_err(dev, "failed to create V4L2 flash device\n");
> + v4l2_flash_release(priv->v4l2_flash);
> + return PTR_ERR(priv->v4l2_flash);
dev_err_probe()?
> + }
> +
> + return devm_add_action_or_reset(dev, (void *)v4l2_flash_release,
> + priv->v4l2_flash);
maybe add dev_err_probe() here, and drop the extra message in s2m_fled_probe().
> +}
> +
> +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);
> + struct s2m_fled *priv;
> + struct fwnode_handle *child;
> + struct regmap *regmap;
> + const struct s2m_fled_spec *spec;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv) * MAX_CHANNELS, GFP_KERNEL);
> + if (!priv)
> + return dev_err_probe(dev, -ENOMEM, "failed to allocate driver private\n");
> +
> + platform_set_drvdata(pdev, priv);
> + regmap = pmic_drvdata->regmap_pmic;
> +
> + switch (platform_get_device_id(pdev)->driver_data) {
> + case S2MU005:
> + spec = &s2mu005_fled_spec;
> + /* Enable the LED channels. */
> + ret = regmap_set_bits(regmap, S2MU005_REG_FLED_CTRL1,
> + S2MU005_FLED_CH_EN);
> + if (ret < 0)
> + return dev_err_probe(dev, ret, "failed to enable LED channels\n");
> + break;
> + default:
> + return dev_err_probe(dev, -ENODEV,
> + "device type %d is not supported by driver\n",
> + pmic_drvdata->device_type);
> + }
> +
> + device_for_each_child_node(dev, child) {
> + u32 reg;
> +
> + if (fwnode_property_read_u32(child, "reg", ®))
> + goto next_child;
> +
> + if (reg >= spec->num_channels) {
> + dev_warn(dev, "channel %d is non-existent\n", reg);
> + goto next_child;
> + }
> +
> + if (priv[reg].dev) {
> + dev_warn(dev, "duplicate node for channel %d\n", reg);
> + goto next_child;
> + }
> +
> + priv[reg].dev = dev;
> + priv[reg].regmap = regmap;
> + priv[reg].channel = (u8)reg;
> + priv[reg].spec = spec;
> + priv[reg].pmic_revision = pmic_drvdata->revision;
> +
> + ret = devm_mutex_init(dev, &priv[reg].lock);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create mutex lock\n");
> +
> + ret = s2m_fled_init_channel(dev, child, &priv[reg]);
> + if (ret < 0)
> + dev_warn(dev, "channel init failed (%d)\n", ret);
s2m_fled_init_channel() already prints a message on (most) errors, and then
there's another one here. Also, is it really OK to continue ignoring the
error?
> +
> +next_child:
> + fwnode_handle_put(child);
> + }
> +
> + return 0;
> +}
> +
> +static const struct platform_device_id s2m_fled_id_table[] = {
> + { "s2mu005-flash", S2MU005 },
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(platform, s2m_fled_id_table);
> +
> +#ifdef CONFIG_OF
I believe the general recommendation is to not use ifdef CONFIG_OF
Cheers,
Andre
> +/*
> + * 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.
> + */
> +static const struct of_device_id s2m_fled_of_match_table[] = {
> + {
> + .compatible = "samsung,s2mu005-flash",
> + .data = (void *)S2MU005,
> + }, {
> + /* sentinel */
> + },
> +};
> +MODULE_DEVICE_TABLE(of, s2m_fled_of_match_table);
> +#endif
> +
> +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");
^ permalink raw reply
* Re: [PATCH v2 08/12] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: André Draszik @ 2026-02-05 10:54 UTC (permalink / raw)
To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, Krzysztof Kozlowski, Alexandre Belloni,
Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <20260126-s2mu005-pmic-v2-8-78f1a75f547a@disroot.org>
Hi,
On Mon, 2026-01-26 at 00:37 +0530, Kaustabh Chakraborty wrote:
[...]
> diff --git a/drivers/leds/flash/leds-s2m-flash.c b/drivers/leds/flash/leds-s2m-flash.c
> new file mode 100644
> index 0000000000000..1be2745c475bf
[...]
> +
> +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);
> + struct s2m_fled *priv;
> + struct fwnode_handle *child;
[...]
> +
> + device_for_each_child_node(dev, child) {
If you switch to device_for_each_child_node_scoped(), you can get rid
of the goto and the struct fwnode_handle *child declaration at the top,
and you plug your leak in your early error return a few lines below.
> + u32 reg;
> +
> + if (fwnode_property_read_u32(child, "reg", ®))
> + goto next_child;
> +
> + if (reg >= spec->num_channels) {
> + dev_warn(dev, "channel %d is non-existent\n", reg);
> + goto next_child;
> + }
> +
> + if (priv[reg].dev) {
> + dev_warn(dev, "duplicate node for channel %d\n", reg);
> + goto next_child;
> + }
> +
> + priv[reg].dev = dev;
> + priv[reg].regmap = regmap;
> + priv[reg].channel = (u8)reg;
> + priv[reg].spec = spec;
> + priv[reg].pmic_revision = pmic_drvdata->revision;
> +
> + ret = devm_mutex_init(dev, &priv[reg].lock);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create mutex lock\n");
> +
> + ret = s2m_fled_init_channel(dev, child, &priv[reg]);
> + if (ret < 0)
> + dev_warn(dev, "channel init failed (%d)\n", ret);
> +
> +next_child:
> + fwnode_handle_put(child);
> + }
> +
> + return 0;
> +}
Cheers,
Andre'
^ permalink raw reply
* Re: [PATCH v2 06/12] mfd: sec: add support for S2MU005 PMIC
From: Kaustabh Chakraborty @ 2026-02-05 15:32 UTC (permalink / raw)
To: André Draszik, Kaustabh Chakraborty, Lee Jones, Pavel Machek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham,
Chanwoo Choi, Sebastian Reichel, Krzysztof Kozlowski,
Alexandre Belloni, Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <69e2c1b1a2f3d2ed5e5da995cc5ee49bb3627597.camel@linaro.org>
On 2026-02-04 15:23 +00:00, André Draszik wrote:
> Hi,
>
> On Mon, 2026-01-26 at 00:37 +0530, Kaustabh Chakraborty wrote:
>> Samsung's S2MU005 PMIC includes subdevices for a charger, an MUIC (Micro
>> USB Interface Controller), and flash and RGB LED controllers.
>>
>> S2MU005's interrupt registers can be properly divided into three regmap
>> IRQ chips, one each for the charger, flash LEDs, and the MUIC.
>>
>> Add initial support for S2MU005 in the PMIC driver, along with it's three
>> interrupt chips.
>>
>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> ---
>> drivers/mfd/sec-common.c | 16 ++
>> drivers/mfd/sec-i2c.c | 12 ++
>> drivers/mfd/sec-irq.c | 74 ++++++++
>> include/linux/mfd/samsung/core.h | 1 +
>> include/linux/mfd/samsung/irq.h | 66 ++++++++
>> include/linux/mfd/samsung/s2mu005.h | 328 ++++++++++++++++++++++++++++++++++++
>> 6 files changed, 497 insertions(+)
>>
[...]
>> diff --git a/drivers/mfd/sec-i2c.c b/drivers/mfd/sec-i2c.c
>> index 3132b849b4bc4..3f1d70cc3292b 100644
>> --- a/drivers/mfd/sec-i2c.c
>> +++ b/drivers/mfd/sec-i2c.c
>> @@ -17,6 +17,7 @@
>> #include <linux/mfd/samsung/s2mps14.h>
>> #include <linux/mfd/samsung/s2mps15.h>
>> #include <linux/mfd/samsung/s2mpu02.h>
>> +#include <linux/mfd/samsung/s2mu005.h>
>> #include <linux/mfd/samsung/s5m8767.h>
>> #include <linux/mod_devicetable.h>
>> #include <linux/module.h>
>> @@ -130,6 +131,11 @@ static const struct regmap_config s2mpu05_regmap_config = {
>> .val_bits = 8,
>> };
>>
>> +static const struct regmap_config s2mu005_regmap_config = {
>> + .reg_bits = 8,
>> + .val_bits = 8,
>> +};
>
> No cache? And what is the .max_register value?
>
This was in the previous revision, but I ended up removing it because
(at least I thought at that time) interfered with interrupts firing in
some way. The actual issue was unrelated, so I will add it back.
However, there is also another thing I see in logs:
sec-pmic-i2c 2-003d: using zero-initialized flat cache, this may cause unexpected behavior
This is due to REGCACHE_FLAT, I am not sure if I should just ignore
this.
^ permalink raw reply
* Re: [PATCH v2 08/12] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: Kaustabh Chakraborty @ 2026-02-05 16:16 UTC (permalink / raw)
To: André Draszik, Kaustabh Chakraborty, Lee Jones, Pavel Machek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham,
Chanwoo Choi, Sebastian Reichel, Krzysztof Kozlowski,
Alexandre Belloni, Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <e34d429e27392eba894b9592724a77fa82fc8009.camel@linaro.org>
On 2026-02-04 16:55 +00:00, André Draszik wrote:
> Hi,
>
> On Mon, 2026-01-26 at 00:37 +0530, 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 | 410 ++++++++++++++++++++++++++++++++++++
>> 3 files changed, 423 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..1be2745c475bf
>> --- /dev/null
>> +++ b/drivers/leds/flash/leds-s2m-flash.c
>> @@ -0,0 +1,410 @@
>> +// 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 {
>> + struct device *dev;
>> + struct regmap *regmap;
>> + struct led_classdev_flash cdev;
>> + struct v4l2_flash *v4l2_flash;
>> + struct mutex lock;
>
> Please add a (brief) comment describing what the mutex protects.
The mutex object prevents the concurrent access of flash control
registers by the LED and V4L2 subsystems. -- will add this.
>> +
>> + /*
>> + * Get the LED enable register address. Revision EVT0 has the
>> + * register at CTRL4, while EVT1 and higher have it at CTRL6.
>> + */
>> + if (priv->pmic_revision == 0)
>> + reg_enable = S2MU005_REG_FLED_CTRL4;
>> + else
>> + reg_enable = S2MU005_REG_FLED_CTRL6;
>
> You could REG_FIELD() and friends for this and everywhere else with
> similar if / else.
>
REG_FIELD(), from what I understood, is for selecting a bit field inside
a single register. However this code chooses between two separate
registers. I believe your interpretation was incorrect? Please clarify.
>> +static int s2m_fled_init_channel(struct device *dev, struct fwnode_handle *fwnp,
>> + struct s2m_fled *priv)
>> +{
>> + 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;
>> +
>> + 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(dev, &priv->cdev, &init_data);
>> + if (ret < 0) {
>> + dev_err(dev, "failed to create LED flash device\n");
>> + return ret;
>
> dev_err_probe()?
>
>> + }
>> +
>> + 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(dev, fwnp, &priv->cdev,
>> + &s2m_fled_v4l2_flash_ops, &v4l2_cfg);
>> + if (IS_ERR(priv->v4l2_flash)) {
>> + dev_err(dev, "failed to create V4L2 flash device\n");
>> + v4l2_flash_release(priv->v4l2_flash);
>> + return PTR_ERR(priv->v4l2_flash);
>
> dev_err_probe()?
>
>> + }
>> +
>> + return devm_add_action_or_reset(dev, (void *)v4l2_flash_release,
>> + priv->v4l2_flash);
>
> maybe add dev_err_probe() here, and drop the extra message in s2m_fled_probe().
>
>> +}
>> +
>> +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);
>> + struct s2m_fled *priv;
>> + struct fwnode_handle *child;
>> + struct regmap *regmap;
>> + const struct s2m_fled_spec *spec;
>> + int ret;
>> +
>> + priv = devm_kzalloc(dev, sizeof(*priv) * MAX_CHANNELS, GFP_KERNEL);
>> + if (!priv)
>> + return dev_err_probe(dev, -ENOMEM, "failed to allocate driver private\n");
>> +
>> + platform_set_drvdata(pdev, priv);
>> + regmap = pmic_drvdata->regmap_pmic;
>> +
>> + switch (platform_get_device_id(pdev)->driver_data) {
>> + case S2MU005:
>> + spec = &s2mu005_fled_spec;
>> + /* Enable the LED channels. */
>> + ret = regmap_set_bits(regmap, S2MU005_REG_FLED_CTRL1,
>> + S2MU005_FLED_CH_EN);
>> + if (ret < 0)
>> + return dev_err_probe(dev, ret, "failed to enable LED channels\n");
>> + break;
>> + default:
>> + return dev_err_probe(dev, -ENODEV,
>> + "device type %d is not supported by driver\n",
>> + pmic_drvdata->device_type);
>> + }
>> +
>> + device_for_each_child_node(dev, child) {
>> + u32 reg;
>> +
>> + if (fwnode_property_read_u32(child, "reg", ®))
>> + goto next_child;
>> +
>> + if (reg >= spec->num_channels) {
>> + dev_warn(dev, "channel %d is non-existent\n", reg);
>> + goto next_child;
>> + }
>> +
>> + if (priv[reg].dev) {
>> + dev_warn(dev, "duplicate node for channel %d\n", reg);
>> + goto next_child;
>> + }
>> +
>> + priv[reg].dev = dev;
>> + priv[reg].regmap = regmap;
>> + priv[reg].channel = (u8)reg;
>> + priv[reg].spec = spec;
>> + priv[reg].pmic_revision = pmic_drvdata->revision;
>> +
>> + ret = devm_mutex_init(dev, &priv[reg].lock);
>> + if (ret)
>> + return dev_err_probe(dev, ret, "failed to create mutex lock\n");
>> +
>> + ret = s2m_fled_init_channel(dev, child, &priv[reg]);
>> + if (ret < 0)
>> + dev_warn(dev, "channel init failed (%d)\n", ret);
>
> s2m_fled_init_channel() already prints a message on (most) errors, and then
> there's another one here. Also, is it really OK to continue ignoring the
> error?
>
The LED channels are supposed to be independent, so if one fails, the
others may still work.
But errors in s2m_fled_init_channel() is not-hardware related, so this
reasoning doesn't make sense. So I shall implement your changes.
^ permalink raw reply
* Re: [PATCH v2 07/12] mfd: sec: store hardware revision in sec_pmic_dev and add S2MU005 support
From: Kaustabh Chakraborty @ 2026-02-05 16:26 UTC (permalink / raw)
To: Kaustabh Chakraborty, André Draszik, Lee Jones, Pavel Machek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham,
Chanwoo Choi, Sebastian Reichel, Krzysztof Kozlowski,
Alexandre Belloni, Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <DG69QZBG97G3.1458CJYT0YG9C@disroot.org>
On 2026-02-04 20:35 +05:30, Kaustabh Chakraborty wrote:
> On 2026-02-04 14:17 +00:00, André Draszik wrote:
>> Hi Kaustabh,
>>
>> On Mon, 2026-01-26 at 00:37 +0530, Kaustabh Chakraborty wrote:
>>> The device revision matters in cases when in some PMICs, the correct
>>> register offsets very in different revisions. Instead of just debug
>>
>> s/very/vary
>>
>>> printing the value, store it in the driver data struct.
>>
>> Please mention that you're not doing that for s2mpg1x, though.
>>
>>>
>>> Unlike other devices, S2MU005 has its hardware revision ID in register
>>> offset 0x73. Allow handling different devices and add support for S2MU005.
>>>
>>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>>> ---
>>> drivers/mfd/sec-common.c | 41 ++++++++++++++++++++++++++++++----------
>>> include/linux/mfd/samsung/core.h | 1 +
>>> 2 files changed, 32 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/mfd/sec-common.c b/drivers/mfd/sec-common.c
>>> index bc2a1f2c6dc7a..069a1ba9aa1f1 100644
>>> --- a/drivers/mfd/sec-common.c
>>> +++ b/drivers/mfd/sec-common.c
>>> @@ -16,6 +16,7 @@
>>> #include <linux/mfd/samsung/irq.h>
>>> #include <linux/mfd/samsung/s2mps11.h>
>>> #include <linux/mfd/samsung/s2mps13.h>
>>> +#include <linux/mfd/samsung/s2mu005.h>
>>> #include <linux/module.h>
>>> #include <linux/of.h>
>>> #include <linux/pm.h>
>>> @@ -111,17 +112,38 @@ static const struct mfd_cell s2mu005_devs[] = {
>>> MFD_CELL_OF("s2mu005-rgb", NULL, NULL, 0, 0, "samsung,s2mu005-rgb"),
>>> };
>>>
>>> -static void sec_pmic_dump_rev(struct sec_pmic_dev *sec_pmic)
>>> +static int sec_pmic_store_rev(struct sec_pmic_dev *sec_pmic)
>>> {
>>> - unsigned int val;
>>> + unsigned int reg, mask, shift;
>>> + int ret;
>>>
>>> - /* For s2mpg1x, the revision is in a different regmap */
>>> - if (sec_pmic->device_type == S2MPG10)
>>> - return;
>>> + switch (sec_pmic->device_type) {
>>> + case S2MPG10:
>>> + /* For s2mpg1x, the revision is in a different regmap */
>>> + return 0;
>>> + case S2MU005:
>>> + reg = S2MU005_REG_ID;
>>> + mask = S2MU005_ID_MASK;
>>> + shift = S2MU005_ID_SHIFT;
>>> + break;
>>> + default:
>>> + /* For other device types, the REG_ID is always the first register. */
>>> + reg = S2MPS11_REG_ID;
>>> + mask = ~0;
>>> + shift = 0;
>>> + }
>>> +
>>> + ret = regmap_read(sec_pmic->regmap_pmic, reg, &sec_pmic->revision);
>>> + if (ret) {
>>> + dev_err(sec_pmic->dev, "Failed to read PMIC revision (%d)\n", ret);
>>> + return ret;
>>> + }
>>> +
>>> + sec_pmic->revision &= mask;
>>> + sec_pmic->revision >>= shift;
>>>
>>> - /* For each device type, the REG_ID is always the first register */
>>> - if (!regmap_read(sec_pmic->regmap_pmic, S2MPS11_REG_ID, &val))
>>> - dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", val);
>>> + dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", sec_pmic->revision);
>>> + return 0;
>>> }
>>>
>>> static void sec_pmic_configure(struct sec_pmic_dev *sec_pmic)
>>> @@ -262,9 +284,8 @@ int sec_pmic_probe(struct device *dev, int device_type, unsigned int irq,
>>> return ret;
>>>
>>> sec_pmic_configure(sec_pmic);
>>> - sec_pmic_dump_rev(sec_pmic);
>>>
>>> - return ret;
>>> + return sec_pmic_store_rev(sec_pmic);
>>> }
>>> EXPORT_SYMBOL_GPL(sec_pmic_probe);
>>>
>>> diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
>>> index 43e0c5e55f5d3..56aa33d7e3d60 100644
>>> --- a/include/linux/mfd/samsung/core.h
>>> +++ b/include/linux/mfd/samsung/core.h
>>> @@ -70,6 +70,7 @@ struct sec_pmic_dev {
>>>
>>> int device_type;
>>> int irq;
>>> + unsigned int revision;
>>
>> kerneldoc needs to be updated.
>
> Seems like it needs cleanup anyway, I will send a patch for that
> separately (if this patch gets dropped in the next rev, see below).
>
>>
>> Given the LED driver is the only driver & device so far which needs the
>> PMIC revision, maybe for now that driver could determine the revision
>> itself instead of adding this new member for everybody?
>
> Hmm, implementing that would make this patch redundant. I'll do so.
It however seems weird to not handle it here; we're already reading the
revision value; it also makes sense to store it in the MFD driver
itself.
Either way, the patch won't be redundant, because the reading part at
least needs to be implemented here.
>
>>
>> Cheers,
>> Andre'
>>
>>> };
>>>
>>> struct sec_platform_data {
^ permalink raw reply
* Re: [PATCH 2/3] hwrng: optee - simplify OP-TEE context match
From: Herbert Xu @ 2026-02-06 10:57 UTC (permalink / raw)
To: rouven.czerwinski
Cc: Jens Wiklander, Sumit Garg, Olivia Mackall,
Clément Léger, Alexandre Belloni, op-tee, linux-kernel,
linux-crypto, linux-rtc
In-Reply-To: <20260126-optee-simplify-context-match-v1-2-d4104e526cb6@linaro.org>
On Mon, Jan 26, 2026 at 11:11:25AM +0100, Rouven Czerwinski via B4 Relay wrote:
> From: Rouven Czerwinski <rouven.czerwinski@linaro.org>
>
> Simplify the TEE implementor ID match by returning the boolean
> expression directly instead of going through an if/else.
>
> Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> ---
> drivers/char/hw_random/optee-rng.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v1 03/10] dt-bindings: iio: adc: cpcap-adc: document Mot ADC
From: Rob Herring (Arm) @ 2026-02-06 13:31 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: devicetree, linux-rtc, Lee Jones, Andy Shevchenko, Pavel Machek,
Alexandre Belloni, linux-input, Tony Lindgren, Dixit Parmar,
Mark Brown, Jonathan Cameron, Liam Girdwood, linux-leds,
Nuno Sá, Conor Dooley, Krzysztof Kozlowski, linux-iio,
David Lechner, Dmitry Torokhov, linux-kernel
In-Reply-To: <20260125134302.45958-4-clamor95@gmail.com>
On Sun, 25 Jan 2026 15:42:55 +0200, Svyatoslav Ryhel wrote:
> Add compatible for ADC used in Mot board. Separate compatible is required
> since ADC in the Mot board uses a unique set of configurations.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> ---
> .../devicetree/bindings/iio/adc/motorola,cpcap-adc.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 05/10] dt-bindings: leds: leds-cpcap: convert to schema
From: Rob Herring (Arm) @ 2026-02-06 13:33 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, Tony Lindgren, Andy Shevchenko,
Krzysztof Kozlowski, Mark Brown, Dmitry Torokhov, linux-rtc,
linux-iio, David Lechner, linux-input, linux-leds,
Alexandre Belloni, linux-kernel, Pavel Machek, Dixit Parmar,
Nuno Sá, devicetree, Lee Jones, Conor Dooley, Liam Girdwood
In-Reply-To: <20260125134302.45958-6-clamor95@gmail.com>
On Sun, 25 Jan 2026 15:42:57 +0200, Svyatoslav Ryhel wrote:
> Convert leds devicetree bindings for the Motorola CPCAP MFD 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>
> ---
> .../devicetree/bindings/leds/leds-cpcap.txt | 29 -------------
> .../bindings/leds/motorola,cpcap-leds.yaml | 42 +++++++++++++++++++
> 2 files changed, 42 insertions(+), 29 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/leds/leds-cpcap.txt
> create mode 100644 Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 02/12] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Rob Herring @ 2026-02-06 13:38 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260126-s2mu005-pmic-v2-2-78f1a75f547a@disroot.org>
On Mon, Jan 26, 2026 at 12:37:09AM +0530, Kaustabh Chakraborty wrote:
> Certain Samsung S2M series PMICs have a three-channel LED device with
> independent brightness control for each channel, typically used as
> status indicators in mobile phones. Document the devicetree schema from
> this device.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> .../bindings/leds/samsung,s2mu005-rgb.yaml | 34 ++++++++++++++++++++++
> 1 file changed, 34 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
> new file mode 100644
> index 0000000000000..6806b6d869ff7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
> @@ -0,0 +1,34 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/samsung,s2mu005-rgb.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: RGB LED Controller for Samsung S2M series PMICs
> +
> +maintainers:
> + - Kaustabh Chakraborty <kauschluss@disroot.org>
> +
> +description: |
> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
> + 8-bit brightness control for each channel, typically used as status
> + indicators in mobile phones.
> +
> + 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: common.yaml#
This looks a bit lacking. Don't you need 3 child nodes for each or
reference to the multi-color schema?
> +
> +properties:
> + compatible:
> + enum:
> + - samsung,s2mu005-rgb
> +
> +required:
> + - compatible
> +
> +unevaluatedProperties: false
>
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: extcon: document Samsung S2M series PMIC extcon device
From: Rob Herring @ 2026-02-06 13:49 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260126-s2mu005-pmic-v2-3-78f1a75f547a@disroot.org>
On Mon, Jan 26, 2026 at 12:37:10AM +0530, Kaustabh Chakraborty wrote:
> Certain Samsung S2M series PMICs have a MUIC device which reports
> various cable states by measuring the ID-GND resistance with an internal
> ADC. Document the devicetree schema for this device.
>
> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> ---
> .../bindings/extcon/samsung,s2mu005-muic.yaml | 35 ++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml b/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml
> new file mode 100644
> index 0000000000000..05828b7b5be13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml
> @@ -0,0 +1,35 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/extcon/samsung,s2mu005-muic.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Extcon Device for Samsung S2M series PMICs
> +
> +maintainers:
> + - Kaustabh Chakraborty <kauschluss@disroot.org>
> +
> +description: |
> + The Samsung S2M series PMIC extcon device is a USB port accessory
extcon is a Linuxism. Use usb-connector binding.
> + detector. It reports multiple states depending on the ID-GND
> + resistance measured by an internal ADC.
> +
> + 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.
> +
> +properties:
> + compatible:
> + enum:
> + - samsung,s2mu005-muic
> +
> + port:
> + $ref: /schemas/graph.yaml#/properties/port
What does the port connect to?
> +
> +required:
> + - compatible
> + - port
> +
> +additionalProperties: false
>
> --
> 2.52.0
>
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: extcon: document Samsung S2M series PMIC extcon device
From: Kaustabh Chakraborty @ 2026-02-06 13:52 UTC (permalink / raw)
To: Rob Herring, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260206134915.GA171264-robh@kernel.org>
On 2026-02-06 07:49 -06:00, Rob Herring wrote:
> On Mon, Jan 26, 2026 at 12:37:10AM +0530, Kaustabh Chakraborty wrote:
>> Certain Samsung S2M series PMICs have a MUIC device which reports
>> various cable states by measuring the ID-GND resistance with an internal
>> ADC. Document the devicetree schema for this device.
>>
>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> ---
>> .../bindings/extcon/samsung,s2mu005-muic.yaml | 35 ++++++++++++++++++++++
>> 1 file changed, 35 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml b/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml
>> new file mode 100644
>> index 0000000000000..05828b7b5be13
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/extcon/samsung,s2mu005-muic.yaml
>> @@ -0,0 +1,35 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/extcon/samsung,s2mu005-muic.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Extcon Device for Samsung S2M series PMICs
>> +
>> +maintainers:
>> + - Kaustabh Chakraborty <kauschluss@disroot.org>
>> +
>> +description: |
>> + The Samsung S2M series PMIC extcon device is a USB port accessory
>
> extcon is a Linuxism. Use usb-connector binding.
>
>> + detector. It reports multiple states depending on the ID-GND
>> + resistance measured by an internal ADC.
>> +
>> + 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.
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - samsung,s2mu005-muic
>> +
>> + port:
>> + $ref: /schemas/graph.yaml#/properties/port
>
> What does the port connect to?
I have it connected to the USB PHY in device tree.
>
>> +
>> +required:
>> + - compatible
>> + - port
>> +
>> +additionalProperties: false
>>
>> --
>> 2.52.0
>>
^ permalink raw reply
* Re: [PATCH v2 02/12] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-02-06 13:56 UTC (permalink / raw)
To: Rob Herring, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260206133837.GA157817-robh@kernel.org>
On 2026-02-06 07:38 -06:00, Rob Herring wrote:
> On Mon, Jan 26, 2026 at 12:37:09AM +0530, Kaustabh Chakraborty wrote:
>> Certain Samsung S2M series PMICs have a three-channel LED device with
>> independent brightness control for each channel, typically used as
>> status indicators in mobile phones. Document the devicetree schema from
>> this device.
>>
>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>> ---
>> .../bindings/leds/samsung,s2mu005-rgb.yaml | 34 ++++++++++++++++++++++
>> 1 file changed, 34 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>> new file mode 100644
>> index 0000000000000..6806b6d869ff7
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>> @@ -0,0 +1,34 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/leds/samsung,s2mu005-rgb.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: RGB LED Controller for Samsung S2M series PMICs
>> +
>> +maintainers:
>> + - Kaustabh Chakraborty <kauschluss@disroot.org>
>> +
>> +description: |
>> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>> + 8-bit brightness control for each channel, typically used as status
>> + indicators in mobile phones.
>> +
>> + 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: common.yaml#
>
> This looks a bit lacking. Don't you need 3 child nodes for each or
> reference to the multi-color schema?
rgb {
compatible = "samsung,s2mu005-rgb";
label = "notification:rgb:indicator";
color = <LED_COLOR_ID_RGB>;
function = LED_FUNCTION_INDICATOR;
linux,default-trigger = "pattern";
};
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - samsung,s2mu005-rgb
>> +
>> +required:
>> + - compatible
>> +
>> +unevaluatedProperties: false
>>
>> --
>> 2.52.0
>>
^ permalink raw reply
* Re: [PATCH v2 02/12] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-02-06 14:03 UTC (permalink / raw)
To: Kaustabh Chakraborty, Rob Herring
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <DG7XJ6T9I7HU.1UVHH2QWX31O1@disroot.org>
On 2026-02-06 19:26 +05:30, Kaustabh Chakraborty wrote:
> On 2026-02-06 07:38 -06:00, Rob Herring wrote:
>> On Mon, Jan 26, 2026 at 12:37:09AM +0530, Kaustabh Chakraborty wrote:
>>> Certain Samsung S2M series PMICs have a three-channel LED device with
>>> independent brightness control for each channel, typically used as
>>> status indicators in mobile phones. Document the devicetree schema from
>>> this device.
>>>
>>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>>> ---
>>> .../bindings/leds/samsung,s2mu005-rgb.yaml | 34 ++++++++++++++++++++++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>>> new file mode 100644
>>> index 0000000000000..6806b6d869ff7
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>>> @@ -0,0 +1,34 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/leds/samsung,s2mu005-rgb.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: RGB LED Controller for Samsung S2M series PMICs
>>> +
>>> +maintainers:
>>> + - Kaustabh Chakraborty <kauschluss@disroot.org>
>>> +
>>> +description: |
>>> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>>> + 8-bit brightness control for each channel, typically used as status
>>> + indicators in mobile phones.
>>> +
>>> + 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: common.yaml#
>>
>> This looks a bit lacking. Don't you need 3 child nodes for each or
>> reference to the multi-color schema?
>
> rgb {
> compatible = "samsung,s2mu005-rgb";
> label = "notification:rgb:indicator";
> color = <LED_COLOR_ID_RGB>;
> function = LED_FUNCTION_INDICATOR;
> linux,default-trigger = "pattern";
> };
>
Message got deleted somehow? Anyways, the device has three channels but
a single LED, but is controlled by a single driver interface only. The
channels are not independent.
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - samsung,s2mu005-rgb
>>> +
>>> +required:
>>> + - compatible
>>> +
>>> +unevaluatedProperties: false
>>>
>>> --
>>> 2.52.0
>>>
^ permalink raw reply
* Re: [PATCH v2 02/12] dt-bindings: leds: document Samsung S2M series PMIC RGB LED device
From: Jacek Anaszewski @ 2026-02-08 13:05 UTC (permalink / raw)
To: Kaustabh Chakraborty, Rob Herring
Cc: Lee Jones, Pavel Machek, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <DG7XJ6T9I7HU.1UVHH2QWX31O1@disroot.org>
Hi Kaustabh,
On 2/6/26 14:56, Kaustabh Chakraborty wrote:
> On 2026-02-06 07:38 -06:00, Rob Herring wrote:
>> On Mon, Jan 26, 2026 at 12:37:09AM +0530, Kaustabh Chakraborty wrote:
>>> Certain Samsung S2M series PMICs have a three-channel LED device with
>>> independent brightness control for each channel, typically used as
>>> status indicators in mobile phones. Document the devicetree schema from
>>> this device.
>>>
>>> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
>>> ---
>>> .../bindings/leds/samsung,s2mu005-rgb.yaml | 34 ++++++++++++++++++++++
>>> 1 file changed, 34 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>>> new file mode 100644
>>> index 0000000000000..6806b6d869ff7
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/samsung,s2mu005-rgb.yaml
>>> @@ -0,0 +1,34 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/leds/samsung,s2mu005-rgb.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: RGB LED Controller for Samsung S2M series PMICs
>>> +
>>> +maintainers:
>>> + - Kaustabh Chakraborty <kauschluss@disroot.org>
>>> +
>>> +description: |
>>> + The Samsung S2M series PMIC RGB LED is a three-channel LED device with
>>> + 8-bit brightness control for each channel, typically used as status
>>> + indicators in mobile phones.
>>> +
>>> + 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: common.yaml#
>>
>> This looks a bit lacking. Don't you need 3 child nodes for each or
>> reference to the multi-color schema?
>
> rgb {
> compatible = "samsung,s2mu005-rgb";
> label = "notification:rgb:indicator";
> color = <LED_COLOR_ID_RGB>;
> function = LED_FUNCTION_INDICATOR;
> linux,default-trigger = "pattern";
> };
Having label together with color and function doesn't make sense.
Please read label documentation in [0].
[0] Documentation/devicetree/bindings/leds/common.yaml
--
Best regards,
Jacek Anaszewski
^ permalink raw reply
* [PATCH] rtc: ds1390: fix number of bytes read from RTC
From: Andreas Gabriel-Platschek @ 2026-02-09 5:34 UTC (permalink / raw)
To: alexandre.belloni; +Cc: linux-rtc, linux-kernel, Andreas Gabriel-Platschek
The spi_write_then_read() reads 8 bytes starting from
DS1390_REG_SECONDS (== 0x01), so the last byte read would already
be part of the alarm (Tenths and Hundredths of Seconds) feature.
However 7 bytes are engouh -- seconds (0x01), minutes (0x02), hours (0x03),
day (0x04), date (0x05), month/century (0x06) and year (0x07).
Signed-off-by: Andreas Gabriel-Platschek <andi.platschek@gmail.com>
---
drivers/rtc/rtc-ds1390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-ds1390.c b/drivers/rtc/rtc-ds1390.c
index f46428ca77cc..f7afd6bdeb4a 100644
--- a/drivers/rtc/rtc-ds1390.c
+++ b/drivers/rtc/rtc-ds1390.c
@@ -134,7 +134,7 @@ static int ds1390_read_time(struct device *dev, struct rtc_time *dt)
chip->txrx_buf[0] = DS1390_REG_SECONDS;
/* do the i/o */
- status = spi_write_then_read(spi, chip->txrx_buf, 1, chip->txrx_buf, 8);
+ status = spi_write_then_read(spi, chip->txrx_buf, 1, chip->txrx_buf, 7);
if (status != 0)
return status;
--
2.47.3
^ permalink raw reply related
* Re: [PATCH 1/3] optee: simplify OP-TEE context match
From: Sumit Garg @ 2026-02-10 5:22 UTC (permalink / raw)
To: rouven.czerwinski
Cc: Jens Wiklander, Olivia Mackall, Herbert Xu,
Clément Léger, Alexandre Belloni, op-tee, linux-kernel,
linux-crypto, linux-rtc
In-Reply-To: <20260126-optee-simplify-context-match-v1-1-d4104e526cb6@linaro.org>
On Mon, Jan 26, 2026 at 11:11:24AM +0100, Rouven Czerwinski via B4 Relay wrote:
> From: Rouven Czerwinski <rouven.czerwinski@linaro.org>
>
> Simplify the TEE implementor ID match by returning the boolean
> expression directly instead of going through an if/else.
>
> Signed-off-by: Rouven Czerwinski <rouven.czerwinski@linaro.org>
> ---
> drivers/tee/optee/device.c | 5 +----
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
Reviewed-by: Sumit Garg <sumit.garg@oss.qualcomm.com>
-Sumit
> diff --git a/drivers/tee/optee/device.c b/drivers/tee/optee/device.c
> index 950b4661d5df..4c85b04d6004 100644
> --- a/drivers/tee/optee/device.c
> +++ b/drivers/tee/optee/device.c
> @@ -13,10 +13,7 @@
>
> static int optee_ctx_match(struct tee_ioctl_version_data *ver, const void *data)
> {
> - if (ver->impl_id == TEE_IMPL_ID_OPTEE)
> - return 1;
> - else
> - return 0;
> + return (ver->impl_id == TEE_IMPL_ID_OPTEE);
> }
>
> static int get_devices(struct tee_context *ctx, u32 session,
>
> --
> 2.52.0
>
>
>
^ permalink raw reply
* Re: [PATCH v2 06/12] mfd: sec: add support for S2MU005 PMIC
From: André Draszik @ 2026-02-10 9:55 UTC (permalink / raw)
To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, Krzysztof Kozlowski, Alexandre Belloni,
Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <DG74Y3QSCLIO.32Q8ZKCTISXXB@disroot.org>
On Thu, 2026-02-05 at 21:02 +0530, Kaustabh Chakraborty wrote:
> On 2026-02-04 15:23 +00:00, André Draszik wrote:
> > Hi,
> >
> > On Mon, 2026-01-26 at 00:37 +0530, Kaustabh Chakraborty wrote:
> > > Samsung's S2MU005 PMIC includes subdevices for a charger, an MUIC (Micro
> > > USB Interface Controller), and flash and RGB LED controllers.
> > >
> > > S2MU005's interrupt registers can be properly divided into three regmap
> > > IRQ chips, one each for the charger, flash LEDs, and the MUIC.
> > >
> > > Add initial support for S2MU005 in the PMIC driver, along with it's three
> > > interrupt chips.
> > >
> > > Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> > > ---
> > > drivers/mfd/sec-common.c | 16 ++
> > > drivers/mfd/sec-i2c.c | 12 ++
> > > drivers/mfd/sec-irq.c | 74 ++++++++
> > > include/linux/mfd/samsung/core.h | 1 +
> > > include/linux/mfd/samsung/irq.h | 66 ++++++++
> > > include/linux/mfd/samsung/s2mu005.h | 328 ++++++++++++++++++++++++++++++++++++
> > > 6 files changed, 497 insertions(+)
> > >
>
> [...]
>
> > > diff --git a/drivers/mfd/sec-i2c.c b/drivers/mfd/sec-i2c.c
> > > index 3132b849b4bc4..3f1d70cc3292b 100644
> > > --- a/drivers/mfd/sec-i2c.c
> > > +++ b/drivers/mfd/sec-i2c.c
> > > @@ -17,6 +17,7 @@
> > > #include <linux/mfd/samsung/s2mps14.h>
> > > #include <linux/mfd/samsung/s2mps15.h>
> > > #include <linux/mfd/samsung/s2mpu02.h>
> > > +#include <linux/mfd/samsung/s2mu005.h>
> > > #include <linux/mfd/samsung/s5m8767.h>
> > > #include <linux/mod_devicetable.h>
> > > #include <linux/module.h>
> > > @@ -130,6 +131,11 @@ static const struct regmap_config s2mpu05_regmap_config = {
> > > .val_bits = 8,
> > > };
> > >
> > > +static const struct regmap_config s2mu005_regmap_config = {
> > > + .reg_bits = 8,
> > > + .val_bits = 8,
> > > +};
> >
> > No cache? And what is the .max_register value?
> >
>
> This was in the previous revision, but I ended up removing it because
> (at least I thought at that time) interfered with interrupts firing in
> some way. The actual issue was unrelated, so I will add it back.
>
> However, there is also another thing I see in logs:
>
> sec-pmic-i2c 2-003d: using zero-initialized flat cache, this may cause unexpected behavior
>
> This is due to REGCACHE_FLAT, I am not sure if I should just ignore
> this.
I think the error might be because you should also specify num_reg_defaults_raw:
.max_register = xxx,
.num_reg_defaults_raw = xxx + 1,
Cheers,
Andre'
^ permalink raw reply
* Re: [PATCH v2 08/12] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: André Draszik @ 2026-02-10 10:03 UTC (permalink / raw)
To: Kaustabh Chakraborty, Lee Jones, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Sebastian Reichel, Krzysztof Kozlowski, Alexandre Belloni,
Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <DG75VP6IIUXD.1VA6YSMNTPJQ6@disroot.org>
On Thu, 2026-02-05 at 21:46 +0530, Kaustabh Chakraborty wrote:
> On 2026-02-04 16:55 +00:00, André Draszik wrote:
> > Hi,
> >
> > On Mon, 2026-01-26 at 00:37 +0530, 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 | 410 ++++++++++++++++++++++++++++++++++++
> > > 3 files changed, 423 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..1be2745c475bf
> > > --- /dev/null
> > > +++ b/drivers/leds/flash/leds-s2m-flash.c
> > > @@ -0,0 +1,410 @@
> > > +// 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 {
> > > + struct device *dev;
> > > + struct regmap *regmap;
> > > + struct led_classdev_flash cdev;
> > > + struct v4l2_flash *v4l2_flash;
> > > + struct mutex lock;
> >
> > Please add a (brief) comment describing what the mutex protects.
>
> The mutex object prevents the concurrent access of flash control
> registers by the LED and V4L2 subsystems. -- will add this.
>
> > > +
> > > + /*
> > > + * Get the LED enable register address. Revision EVT0 has the
> > > + * register at CTRL4, while EVT1 and higher have it at CTRL6.
> > > + */
> > > + if (priv->pmic_revision == 0)
> > > + reg_enable = S2MU005_REG_FLED_CTRL4;
> > > + else
> > > + reg_enable = S2MU005_REG_FLED_CTRL6;
> >
> > You could REG_FIELD() and friends for this and everywhere else with
> > similar if / else.
> >
>
> REG_FIELD(), from what I understood, is for selecting a bit field inside
> a single register. However this code chooses between two separate
> registers. I believe your interpretation was incorrect? Please clarify.
The first argument to REG_FIELD is the register itself, so reg fields can
be used to describe this difference. See e.g. drivers/leds/rgb/leds-mt6370-rgb.c
Of course, you could have a member variable instead to hold the register
index if all bits are the same in both revisions. Either way would avoid
having to constantly check the revision during runtime.
Cheers,
Andre'
^ permalink raw reply
* Re: [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Brian Masney @ 2026-02-10 12:42 UTC (permalink / raw)
To: Thomas Bogendoerfer, Claudiu Beznea
Cc: linux-mips, linux-kernel, Michael Turquette, Stephen Boyd,
linux-clk, Thomas Gleixner, Adrian Hunter, Ulf Hansson, linux-mmc,
Linus Walleij, linux-gpio, Alexandre Belloni, linux-rtc,
Greg Kroah-Hartman, Jiri Slaby, linux-serial, Guenter Roeck,
Wim Van Sebroeck, linux-watchdog, Lukas Bulwahn
In-Reply-To: <20260112-mips-pic32-header-move-v2-0-927d516b1ff9@redhat.com>
Hi Thomas,
On Mon, Jan 12, 2026 at 05:47:54PM -0500, Brian Masney wrote:
> There are currently some pic32 MIPS drivers that are in tree, and are
> only configured to be compiled on the MIPS pic32 platform. There's a
> risk of breaking some of these drivers when migrating drivers away from
> legacy APIs. It happened to me with a pic32 clk driver.
>
> Let's go ahead and move the pic32.h from the asm to the platform_data
> include directory in the tree. This will make it easier, and cleaner to
> enable COMPILE_TEST for some of these pic32 drivers. To do this requires
> updating some includes, which I do at the beginning of this series.
>
> This series was compile tested on a centos-stream-10 arm64 host in two
> different configurations:
>
> - native arm64 build with COMPILE_TEST (via make allmodconfig)
> - MIPS cross compile on arm64 with:
> ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
>
> Note that there is a separate MIPS compile error in linux-next, and I
> reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
>
> I included a patch at the end that shows enabling COMPILE_TEST for a
> pic32 clk driver.
>
> Merge Strategy
> ==============
> - Patches 1-15 can go through the MIPS tree.
> - Patch 16 I can repost to Claudiu after patches 1-15 are in Linus's
> tree after the next merge window. There is a separate patch set that
> fixes a compiler error I unintentionally introduced via the clk tree.
> https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/
Sorry about the duplicate message. I just wanted to reply to the series
with MIPS in the header so this message isn't lost.
Can you back out these two patches from your tree in linux-next, and not
send these to Linus?
clk: microchip: core: allow driver to be compiled with COMPILE_TEST
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=026d70dcfe5de1543bb8edb8e50d22dc16863e6b
clk: microchip: fix typo in reference to a config option
https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a6ab150deb4b740334721d18e02ad400a9d888f5
See
https://lore.kernel.org/oe-kbuild-all/202602100954.BAVYq6aC-lkp@intel.com/
All of the other patches with the include changes are good. I have
patches queued to send out in two weeks to other subsystems once the
include changes land in Linus's tree.
Thanks,
Brian
^ permalink raw reply
* Re: [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Thomas Bogendoerfer @ 2026-02-10 15:50 UTC (permalink / raw)
To: Brian Masney
Cc: Claudiu Beznea, linux-mips, linux-kernel, Michael Turquette,
Stephen Boyd, linux-clk, Thomas Gleixner, Adrian Hunter,
Ulf Hansson, linux-mmc, Linus Walleij, linux-gpio,
Alexandre Belloni, linux-rtc, Greg Kroah-Hartman, Jiri Slaby,
linux-serial, Guenter Roeck, Wim Van Sebroeck, linux-watchdog,
Lukas Bulwahn
In-Reply-To: <aYsnsecPa8bWMbaA@redhat.com>
On Tue, Feb 10, 2026 at 07:42:25AM -0500, Brian Masney wrote:
> Hi Thomas,
>
> On Mon, Jan 12, 2026 at 05:47:54PM -0500, Brian Masney wrote:
> > There are currently some pic32 MIPS drivers that are in tree, and are
> > only configured to be compiled on the MIPS pic32 platform. There's a
> > risk of breaking some of these drivers when migrating drivers away from
> > legacy APIs. It happened to me with a pic32 clk driver.
> >
> > Let's go ahead and move the pic32.h from the asm to the platform_data
> > include directory in the tree. This will make it easier, and cleaner to
> > enable COMPILE_TEST for some of these pic32 drivers. To do this requires
> > updating some includes, which I do at the beginning of this series.
> >
> > This series was compile tested on a centos-stream-10 arm64 host in two
> > different configurations:
> >
> > - native arm64 build with COMPILE_TEST (via make allmodconfig)
> > - MIPS cross compile on arm64 with:
> > ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
> >
> > Note that there is a separate MIPS compile error in linux-next, and I
> > reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
> >
> > I included a patch at the end that shows enabling COMPILE_TEST for a
> > pic32 clk driver.
> >
> > Merge Strategy
> > ==============
> > - Patches 1-15 can go through the MIPS tree.
> > - Patch 16 I can repost to Claudiu after patches 1-15 are in Linus's
> > tree after the next merge window. There is a separate patch set that
> > fixes a compiler error I unintentionally introduced via the clk tree.
> > https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/
>
> Sorry about the duplicate message. I just wanted to reply to the series
> with MIPS in the header so this message isn't lost.
>
> Can you back out these two patches from your tree in linux-next, and not
> send these to Linus?
>
> clk: microchip: core: allow driver to be compiled with COMPILE_TEST
> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=026d70dcfe5de1543bb8edb8e50d22dc16863e6b
>
> clk: microchip: fix typo in reference to a config option
> https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/commit/?id=a6ab150deb4b740334721d18e02ad400a9d888f5
I've reverted both patches in mips-next.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH v2 08/12] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: Kaustabh Chakraborty @ 2026-02-10 18:37 UTC (permalink / raw)
To: André Draszik, Kaustabh Chakraborty, Lee Jones, Pavel Machek,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, MyungJoo Ham,
Chanwoo Choi, Sebastian Reichel, Krzysztof Kozlowski,
Alexandre Belloni, Jonathan Corbet, Shuah Khan
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc
In-Reply-To: <9dad174d88c814d3ad2086a31e8dfc222fd431e4.camel@linaro.org>
On 2026-02-10 10:03 +00:00, André Draszik wrote:
> On Thu, 2026-02-05 at 21:46 +0530, Kaustabh Chakraborty wrote:
>> On 2026-02-04 16:55 +00:00, André Draszik wrote:
>> > Hi,
>> >
>> > On Mon, 2026-01-26 at 00:37 +0530, 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 | 410 ++++++++++++++++++++++++++++++++++++
>> > > 3 files changed, 423 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..1be2745c475bf
>> > > --- /dev/null
>> > > +++ b/drivers/leds/flash/leds-s2m-flash.c
>> > > @@ -0,0 +1,410 @@
>> > > +// 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 {
>> > > + struct device *dev;
>> > > + struct regmap *regmap;
>> > > + struct led_classdev_flash cdev;
>> > > + struct v4l2_flash *v4l2_flash;
>> > > + struct mutex lock;
>> >
>> > Please add a (brief) comment describing what the mutex protects.
>>
>> The mutex object prevents the concurrent access of flash control
>> registers by the LED and V4L2 subsystems. -- will add this.
>>
>> > > +
>> > > + /*
>> > > + * Get the LED enable register address. Revision EVT0 has the
>> > > + * register at CTRL4, while EVT1 and higher have it at CTRL6.
>> > > + */
>> > > + if (priv->pmic_revision == 0)
>> > > + reg_enable = S2MU005_REG_FLED_CTRL4;
>> > > + else
>> > > + reg_enable = S2MU005_REG_FLED_CTRL6;
>> >
>> > You could REG_FIELD() and friends for this and everywhere else with
>> > similar if / else.
>> >
>>
>> REG_FIELD(), from what I understood, is for selecting a bit field inside
>> a single register. However this code chooses between two separate
>> registers. I believe your interpretation was incorrect? Please clarify.
>
> The first argument to REG_FIELD is the register itself, so reg fields can
> be used to describe this difference. See e.g. drivers/leds/rgb/leds-mt6370-rgb.c
> Of course, you could have a member variable instead to hold the register
> index if all bits are the same in both revisions. Either way would avoid
> having to constantly check the revision during runtime.
Wow, this is a great way of abstraction, thanks. I will try to implement
this in all drivers, let's see.
>
> Cheers,
> Andre'
^ permalink raw reply
* [PATCH v1 0/2] rtc: max77686: convert to i2c_new_ancillary_device
From: Svyatoslav Ryhel @ 2026-02-11 18:49 UTC (permalink / raw)
To: Chanwoo Choi, Krzysztof Kozlowski, Lee Jones, Rob Herring,
Conor Dooley, Alexandre Belloni
Cc: linux-kernel, devicetree, linux-rtc
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.
I have tested this patch on LG Optimus Vu P895 with max77663 PMIC and
non-default RTC position. RTC is registered correctly.
Svyatoslav Ryhel (2):
dt-bindings: mfd: maxim,max77686: document optional RTC address
rtc: max77686: convert to i2c_new_ancillary_device
.../devicetree/bindings/mfd/maxim,max77686.yaml | 15 +++++++++++++--
drivers/rtc/rtc-max77686.c | 14 ++++++++++++--
2 files changed, 25 insertions(+), 4 deletions(-)
--
2.51.0
^ permalink raw reply
* [PATCH v1 1/2] dt-bindings: mfd: maxim,max77686: document optional RTC address
From: Svyatoslav Ryhel @ 2026-02-11 18:49 UTC (permalink / raw)
To: Chanwoo Choi, Krzysztof Kozlowski, Lee Jones, Rob Herring,
Conor Dooley, Alexandre Belloni
Cc: linux-kernel, devicetree, linux-rtc
In-Reply-To: <20260211184941.6756-1-clamor95@gmail.com>
Document an optional second I2C address for the PMIC's RTC device, to be
used if the RTC is located at a non-default I2C address
Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
---
.../devicetree/bindings/mfd/maxim,max77686.yaml | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml
index c13d51e462ba..2d4aad8feaeb 100644
--- a/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml
+++ b/Documentation/devicetree/bindings/mfd/maxim,max77686.yaml
@@ -32,7 +32,17 @@ properties:
maxItems: 1
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
voltage-regulators:
$ref: /schemas/regulator/maxim,max77686.yaml
@@ -59,7 +69,8 @@ examples:
max77686: pmic@9 {
compatible = "maxim,max77686";
- reg = <0x09>;
+ reg = <0x09>, <0x06>;
+ reg-names = "pmic", "rtc";
interrupt-parent = <&gpx0>;
interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
--
2.51.0
^ permalink raw reply related
* [PATCH v1 2/2] rtc: max77686: convert to i2c_new_ancillary_device
From: Svyatoslav Ryhel @ 2026-02-11 18:49 UTC (permalink / raw)
To: Chanwoo Choi, Krzysztof Kozlowski, Lee Jones, Rob Herring,
Conor Dooley, Alexandre Belloni
Cc: linux-kernel, devicetree, linux-rtc
In-Reply-To: <20260211184941.6756-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
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