* 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 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 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 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 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 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 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 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: 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 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: (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 06/12] mfd: sec: add support for S2MU005 PMIC
From: André Draszik @ 2026-02-04 15:23 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-6-78f1a75f547a@disroot.org>
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-common.c b/drivers/mfd/sec-common.c
> index 0021f9ae8484f..bc2a1f2c6dc7a 100644
> --- a/drivers/mfd/sec-common.c
> +++ b/drivers/mfd/sec-common.c
> @@ -99,6 +99,18 @@ static const struct mfd_cell s2mpu05_devs[] = {
> MFD_CELL_RES("s2mps15-rtc", s2mpu05_rtc_resources),
> };
>
> +static const struct resource s2mu005_muic_resources[] = {
> + DEFINE_RES_IRQ_NAMED(S2MU005_IRQ_MUIC_ATTACH, "attach"),
> + DEFINE_RES_IRQ_NAMED(S2MU005_IRQ_MUIC_DETACH, "detach"),
> +};
> +
> +static const struct mfd_cell s2mu005_devs[] = {
> + MFD_CELL_OF("s2mu005-charger", NULL, NULL, 0, 0, "samsung,s2mu005-charger"),
> + MFD_CELL_OF("s2mu005-flash", NULL, NULL, 0, 0, "samsung,s2mu005-flash"),
> + MFD_CELL_OF("s2mu005-muic", s2mu005_muic_resources, NULL, 0, 0, "samsung,s2mu005-muic"),
> + MFD_CELL_OF("s2mu005-rgb", NULL, NULL, 0, 0, "samsung,s2mu005-rgb"),
> +};
> +
> static void sec_pmic_dump_rev(struct sec_pmic_dev *sec_pmic)
> {
> unsigned int val;
> @@ -235,6 +247,10 @@ int sec_pmic_probe(struct device *dev, int device_type, unsigned int irq,
> sec_devs = s2mpu05_devs;
> num_sec_devs = ARRAY_SIZE(s2mpu05_devs);
> break;
> + case S2MU005:
> + sec_devs = s2mu005_devs;
> + num_sec_devs = ARRAY_SIZE(s2mu005_devs);
> + break;
> default:
> return dev_err_probe(sec_pmic->dev, -EINVAL,
> "Unsupported device type %d\n",
> 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?
> +
> static const struct regmap_config s5m8767_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> @@ -203,6 +209,11 @@ static const struct sec_pmic_i2c_platform_data s2mpu05_data = {
> .device_type = S2MPU05,
> };
>
> +static const struct sec_pmic_i2c_platform_data s2mu005_data = {
> + .regmap_cfg = &s2mu005_regmap_config,
> + .device_type = S2MU005,
> +};
> +
> static const struct sec_pmic_i2c_platform_data s5m8767_data = {
> .regmap_cfg = &s5m8767_regmap_config,
> .device_type = S5M8767X,
> @@ -217,6 +228,7 @@ static const struct of_device_id sec_pmic_i2c_of_match[] = {
> { .compatible = "samsung,s2mps15-pmic", .data = &s2mps15_data, },
> { .compatible = "samsung,s2mpu02-pmic", .data = &s2mpu02_data, },
> { .compatible = "samsung,s2mpu05-pmic", .data = &s2mpu05_data, },
> + { .compatible = "samsung,s2mu005-pmic", .data = &s2mu005_data, },
> { .compatible = "samsung,s5m8767-pmic", .data = &s5m8767_data, },
> { },
> };
> diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
> index 4c0faf4c99893..44a1eb074a082 100644
> --- a/drivers/mfd/sec-irq.c
> +++ b/drivers/mfd/sec-irq.c
> @@ -15,6 +15,7 @@
> #include <linux/mfd/samsung/s2mps14.h>
> #include <linux/mfd/samsung/s2mpu02.h>
> #include <linux/mfd/samsung/s2mpu05.h>
> +#include <linux/mfd/samsung/s2mu005.h>
> #include <linux/mfd/samsung/s5m8767.h>
> #include <linux/regmap.h>
> #include "sec-core.h"
> @@ -164,6 +165,65 @@ static const struct regmap_irq s2mpu05_irqs[] = {
> REGMAP_IRQ_REG(S2MPU05_IRQ_TSD, 2, S2MPU05_IRQ_TSD_MASK),
> };
>
> +static const struct regmap_irq s2mu005_irqs[] = {
> + REGMAP_IRQ_REG(S2MU005_IRQ_CHGR_DETBAT, 0, S2MU005_IRQ_CHGR_DETBAT_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_CHGR_BAT, 0, S2MU005_IRQ_CHGR_BAT_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_CHGR_IVR, 0, S2MU005_IRQ_CHGR_IVR_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_CHGR_EVENT, 0, S2MU005_IRQ_CHGR_EVENT_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_CHGR_CHG, 0, S2MU005_IRQ_CHGR_CHG_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_CHGR_VMID, 0, S2MU005_IRQ_CHGR_VMID_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_CHGR_WCIN, 0, S2MU005_IRQ_CHGR_WCIN_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_CHGR_VBUS, 0, S2MU005_IRQ_CHGR_VBUS_MASK),
> +
> + REGMAP_IRQ_REG(S2MU005_IRQ_FLED_LBPROT, 1, S2MU005_IRQ_FLED_LBPROT_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_FLED_OPENCH2, 1, S2MU005_IRQ_FLED_OPENCH2_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_FLED_OPENCH1, 1, S2MU005_IRQ_FLED_OPENCH1_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_FLED_SHORTCH2, 1, S2MU005_IRQ_FLED_SHORTCH2_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_FLED_SHORTCH1, 1, S2MU005_IRQ_FLED_SHORTCH1_MASK),
> +
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_ATTACH, 2, S2MU005_IRQ_MUIC_ATTACH_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_DETACH, 2, S2MU005_IRQ_MUIC_DETACH_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_KP, 2, S2MU005_IRQ_MUIC_KP_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_LKP, 2, S2MU005_IRQ_MUIC_LKP_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_LKR, 2, S2MU005_IRQ_MUIC_LKR_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_RIDCHG, 2, S2MU005_IRQ_MUIC_RIDCHG_MASK),
> +
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_VBUSON, 3, S2MU005_IRQ_MUIC_VBUSON_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_RSVD, 3, S2MU005_IRQ_MUIC_RSVD_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_ADC, 3, S2MU005_IRQ_MUIC_ADC_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_STUCK, 3, S2MU005_IRQ_MUIC_STUCK_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_STUCKRCV, 3, S2MU005_IRQ_MUIC_STUCKRCV_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_MHDL, 3, S2MU005_IRQ_MUIC_MHDL_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_AVCHG, 3, S2MU005_IRQ_MUIC_AVCHG_MASK),
> + REGMAP_IRQ_REG(S2MU005_IRQ_MUIC_VBUSOFF, 3, S2MU005_IRQ_MUIC_VBUSOFF_MASK),
> +};
> +
> +static unsigned int s2mu005_irq_get_reg(struct regmap_irq_chip_data *data,
> + unsigned int base, int index)
> +{
> + const unsigned int irqf_regs[] = {
> + S2MU005_REG_CHGR_INT1,
> + S2MU005_REG_FLED_INT1,
> + S2MU005_REG_MUIC_INT1,
> + S2MU005_REG_MUIC_INT2,
> + };
> + const unsigned int mask_regs[] = {
> + S2MU005_REG_CHGR_INT1M,
> + S2MU005_REG_FLED_INT1M,
> + S2MU005_REG_MUIC_INT1M,
> + S2MU005_REG_MUIC_INT2M,
> + };
> +
> + switch (base) {
> + case irqf_regs[0]:
> + return irqf_regs[index];
> + case mask_regs[0]:
> + return mask_regs[index];
> + }
> +
> + return base;
> +}
> +
> static const struct regmap_irq s5m8767_irqs[] = {
> REGMAP_IRQ_REG(S5M8767_IRQ_PWRR, 0, S5M8767_IRQ_PWRR_MASK),
> REGMAP_IRQ_REG(S5M8767_IRQ_PWRF, 0, S5M8767_IRQ_PWRF_MASK),
> @@ -259,6 +319,17 @@ static const struct regmap_irq_chip s2mpu05_irq_chip = {
> .ack_base = S2MPU05_REG_INT1,
> };
>
> +static const struct regmap_irq_chip s2mu005_irq_chip = {
> + .name = "s2mu005",
> + .irqs = s2mu005_irqs,
> + .num_irqs = ARRAY_SIZE(s2mu005_irqs),
> + .num_regs = 4,
> + .status_base = S2MU005_REG_CHGR_INT1,
> + .mask_base = S2MU005_REG_CHGR_INT1M,
> + .ack_base = S2MU005_REG_CHGR_INT1,
> + .get_irq_reg = s2mu005_irq_get_reg,
> +};
> +
> static const struct regmap_irq_chip s5m8767_irq_chip = {
> .name = "s5m8767",
> .irqs = s5m8767_irqs,
> @@ -358,6 +429,9 @@ struct regmap_irq_chip_data *sec_irq_init(struct sec_pmic_dev *sec_pmic)
> case S2MPU05:
> sec_irq_chip = &s2mpu05_irq_chip;
> break;
> + case S2MU005:
> + sec_irq_chip = &s2mu005_irq_chip;
> + break;
> default:
> return dev_err_ptr_probe(sec_pmic->dev, -EINVAL, "Unsupported device type %d\n",
> sec_pmic->device_type);
> diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
> index c7c3c8cd8d5f9..43e0c5e55f5d3 100644
> --- a/include/linux/mfd/samsung/core.h
> +++ b/include/linux/mfd/samsung/core.h
> @@ -46,6 +46,7 @@ enum sec_device_type {
> S2MPS15X,
> S2MPU02,
> S2MPU05,
> + S2MU005,
> };
>
> /**
> diff --git a/include/linux/mfd/samsung/irq.h b/include/linux/mfd/samsung/irq.h
> index 8402a5f8e18ab..936369a733a1c 100644
> --- a/include/linux/mfd/samsung/irq.h
> +++ b/include/linux/mfd/samsung/irq.h
> @@ -303,6 +303,72 @@ enum s2mpu05_irq {
> #define S2MPU05_IRQ_INT140C_MASK BIT(1)
> #define S2MPU05_IRQ_TSD_MASK BIT(2)
>
> +enum s2mu005_irq {
> + S2MU005_IRQ_CHGR_DETBAT,
> + S2MU005_IRQ_CHGR_BAT,
> + S2MU005_IRQ_CHGR_IVR,
> + S2MU005_IRQ_CHGR_EVENT,
> + S2MU005_IRQ_CHGR_CHG,
> + S2MU005_IRQ_CHGR_VMID,
> + S2MU005_IRQ_CHGR_WCIN,
> + S2MU005_IRQ_CHGR_VBUS,
> +
> + S2MU005_IRQ_FLED_LBPROT,
> + S2MU005_IRQ_FLED_OPENCH2,
> + S2MU005_IRQ_FLED_OPENCH1,
> + S2MU005_IRQ_FLED_SHORTCH2,
> + S2MU005_IRQ_FLED_SHORTCH1,
> +
> + S2MU005_IRQ_MUIC_ATTACH,
> + S2MU005_IRQ_MUIC_DETACH,
> + S2MU005_IRQ_MUIC_KP,
> + S2MU005_IRQ_MUIC_LKP,
> + S2MU005_IRQ_MUIC_LKR,
> + S2MU005_IRQ_MUIC_RIDCHG,
> +
> + S2MU005_IRQ_MUIC_VBUSON,
> + S2MU005_IRQ_MUIC_RSVD,
> + S2MU005_IRQ_MUIC_ADC,
> + S2MU005_IRQ_MUIC_STUCK,
> + S2MU005_IRQ_MUIC_STUCKRCV,
> + S2MU005_IRQ_MUIC_MHDL,
> + S2MU005_IRQ_MUIC_AVCHG,
> + S2MU005_IRQ_MUIC_VBUSOFF,
> +
> + S2MU005_IRQ_NR,
> +};
> +
> +#define S2MU005_IRQ_CHGR_DETBAT_MASK BIT(0)
> +#define S2MU005_IRQ_CHGR_BAT_MASK BIT(1)
> +#define S2MU005_IRQ_CHGR_IVR_MASK BIT(2)
> +#define S2MU005_IRQ_CHGR_EVENT_MASK BIT(3)
> +#define S2MU005_IRQ_CHGR_CHG_MASK BIT(4)
> +#define S2MU005_IRQ_CHGR_VMID_MASK BIT(5)
> +#define S2MU005_IRQ_CHGR_WCIN_MASK BIT(6)
> +#define S2MU005_IRQ_CHGR_VBUS_MASK BIT(7)
> +
> +#define S2MU005_IRQ_FLED_LBPROT_MASK BIT(2)
> +#define S2MU005_IRQ_FLED_OPENCH2_MASK BIT(4)
> +#define S2MU005_IRQ_FLED_OPENCH1_MASK BIT(5)
> +#define S2MU005_IRQ_FLED_SHORTCH2_MASK BIT(6)
> +#define S2MU005_IRQ_FLED_SHORTCH1_MASK BIT(7)
> +
> +#define S2MU005_IRQ_MUIC_ATTACH_MASK BIT(0)
> +#define S2MU005_IRQ_MUIC_DETACH_MASK BIT(1)
> +#define S2MU005_IRQ_MUIC_KP_MASK BIT(2)
> +#define S2MU005_IRQ_MUIC_LKP_MASK BIT(3)
> +#define S2MU005_IRQ_MUIC_LKR_MASK BIT(4)
> +#define S2MU005_IRQ_MUIC_RIDCHG_MASK BIT(5)
> +
> +#define S2MU005_IRQ_MUIC_VBUSON_MASK BIT(0)
> +#define S2MU005_IRQ_MUIC_RSVD_MASK BIT(1)
> +#define S2MU005_IRQ_MUIC_ADC_MASK BIT(2)
> +#define S2MU005_IRQ_MUIC_STUCK_MASK BIT(3)
> +#define S2MU005_IRQ_MUIC_STUCKRCV_MASK BIT(4)
> +#define S2MU005_IRQ_MUIC_MHDL_MASK BIT(5)
> +#define S2MU005_IRQ_MUIC_AVCHG_MASK BIT(6)
> +#define S2MU005_IRQ_MUIC_VBUSOFF_MASK BIT(7)
> +
> enum s5m8767_irq {
> S5M8767_IRQ_PWRR,
> S5M8767_IRQ_PWRF,
> diff --git a/include/linux/mfd/samsung/s2mu005.h b/include/linux/mfd/samsung/s2mu005.h
> new file mode 100644
> index 0000000000000..32ad35dda661d
> --- /dev/null
> +++ b/include/linux/mfd/samsung/s2mu005.h
> @@ -0,0 +1,328 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2015 Samsung Electronics Co., Ltd
> + * Copyright (c) 2025 Kaustabh Chakraborty <kauschluss@disroot.org>
> + */
> +
> +#ifndef __LINUX_MFD_S2MU005_H
> +#define __LINUX_MFD_S2MU005_H
> +
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
> +
> +/* S2MU005 registers */
> +enum s2mu005_reg {
> + S2MU005_REG_CHGR_INT1,
> + S2MU005_REG_CHGR_INT1M,
> +
> + S2MU005_REG_FLED_INT1,
> + S2MU005_REG_FLED_INT1M,
> +
> + S2MU005_REG_MUIC_INT1,
> + S2MU005_REG_MUIC_INT2,
> + S2MU005_REG_MUIC_INT1M,
> + S2MU005_REG_MUIC_INT2M,
> +
> + S2MU005_REG_CHGR_STATUS0,
> + S2MU005_REG_CHGR_STATUS1,
> + S2MU005_REG_CHGR_STATUS2,
> + S2MU005_REG_CHGR_STATUS3,
> + S2MU005_REG_CHGR_STATUS4,
> + S2MU005_REG_CHGR_STATUS5,
> + S2MU005_REG_CHGR_CTRL0,
> + S2MU005_REG_CHGR_CTRL1,
> + S2MU005_REG_CHGR_CTRL2,
> + S2MU005_REG_CHGR_CTRL3,
> + S2MU005_REG_CHGR_CTRL4,
> + S2MU005_REG_CHGR_CTRL5,
> + S2MU005_REG_CHGR_CTRL6,
> + S2MU005_REG_CHGR_CTRL7,
> + S2MU005_REG_CHGR_CTRL8,
> + S2MU005_REG_CHGR_CTRL9,
> + S2MU005_REG_CHGR_CTRL10,
> + S2MU005_REG_CHGR_CTRL11,
> + S2MU005_REG_CHGR_CTRL12,
> + S2MU005_REG_CHGR_CTRL13,
> + S2MU005_REG_CHGR_CTRL14,
> + S2MU005_REG_CHGR_CTRL15,
> + S2MU005_REG_CHGR_CTRL16,
> + S2MU005_REG_CHGR_CTRL17,
> + S2MU005_REG_CHGR_CTRL18,
> + S2MU005_REG_CHGR_CTRL19,
> + S2MU005_REG_CHGR_TEST0,
> + S2MU005_REG_CHGR_TEST1,
> + S2MU005_REG_CHGR_TEST2,
> + S2MU005_REG_CHGR_TEST3,
> + S2MU005_REG_CHGR_TEST4,
> + S2MU005_REG_CHGR_TEST5,
> + S2MU005_REG_CHGR_TEST6,
> + S2MU005_REG_CHGR_TEST7,
> + S2MU005_REG_CHGR_TEST8,
> + S2MU005_REG_CHGR_TEST9,
> + S2MU005_REG_CHGR_TEST10,
> +
> + S2MU005_REG_FLED_STATUS,
> + S2MU005_REG_FLED_CH0_CTRL0,
> + S2MU005_REG_FLED_CH0_CTRL1,
> + S2MU005_REG_FLED_CH0_CTRL2,
> + S2MU005_REG_FLED_CH0_CTRL3,
> + S2MU005_REG_FLED_CH1_CTRL0,
> + S2MU005_REG_FLED_CH1_CTRL1,
> + S2MU005_REG_FLED_CH1_CTRL2,
> + S2MU005_REG_FLED_CH1_CTRL3,
> + S2MU005_REG_FLED_CTRL0,
> + S2MU005_REG_FLED_CTRL1,
> + S2MU005_REG_FLED_CTRL2,
> + S2MU005_REG_FLED_CTRL3,
> + S2MU005_REG_FLED_CTRL4,
> + S2MU005_REG_FLED_CTRL5,
> + S2MU005_REG_FLED_CTRL6,
> +
> + S2MU005_REG_RGB_EN,
> + S2MU005_REG_RGB_CH0_CTRL,
> + S2MU005_REG_RGB_CH1_CTRL,
> + S2MU005_REG_RGB_CH2_CTRL,
> + S2MU005_REG_RGB_CH0_RAMP,
> + S2MU005_REG_RGB_CH0_STAY,
> + S2MU005_REG_RGB_CH1_RAMP,
> + S2MU005_REG_RGB_CH1_STAY,
> + S2MU005_REG_RGB_CH2_RAMP,
> + S2MU005_REG_RGB_CH2_STAY,
> + S2MU005_REG_RGB_TEST0,
> + S2MU005_REG_RGB_CTRL0,
> +
> + S2MU005_REG_MUIC_ADC,
> + S2MU005_REG_MUIC_DEV1,
> + S2MU005_REG_MUIC_DEV2,
> + S2MU005_REG_MUIC_DEV3,
> + S2MU005_REG_MUIC_BUTTON1,
> + S2MU005_REG_MUIC_BUTTON2,
> + S2MU005_REG_MUIC_RESET,
> + S2MU005_REG_MUIC_CHGTYPE,
> + S2MU005_REG_MUIC_DEVAPPLE,
> + S2MU005_REG_MUIC_BCDRESCAN,
> + S2MU005_REG_MUIC_TEST1,
> + S2MU005_REG_MUIC_TEST2,
> + S2MU005_REG_MUIC_TEST3,
> +
> + S2MU005_REG_ID = 0x73,
> +
> + S2MU005_REG_MUIC_CTRL1 = 0xb2,
> + S2MU005_REG_MUIC_TIMERSET1,
> + S2MU005_REG_MUIC_TIMERSET2,
> + S2MU005_REG_MUIC_SWCTRL,
> + S2MU005_REG_MUIC_TIMERSET3,
> + S2MU005_REG_MUIC_CTRL2,
> + S2MU005_REG_MUIC_CTRL3,
> +
> + S2MU005_REG_MUIC_LDOADC_L = 0xbf,
> + S2MU005_REG_MUIC_LDOADC_H,
> +};
> +
> +#define S2MU005_REG_FLED_CH_CTRL0(x) (S2MU005_REG_FLED_CH0_CTRL0 + 4 * (x))
> +#define S2MU005_REG_FLED_CH_CTRL1(x) (S2MU005_REG_FLED_CH0_CTRL1 + 4 * (x))
> +#define S2MU005_REG_FLED_CH_CTRL2(x) (S2MU005_REG_FLED_CH0_CTRL2 + 4 * (x))
> +#define S2MU005_REG_FLED_CH_CTRL3(x) (S2MU005_REG_FLED_CH0_CTRL3 + 4 * (x))
> +
> +#define S2MU005_REG_RGB_CH_CTRL(x) (S2MU005_REG_RGB_CH0_CTRL + 1 * (x))
> +#define S2MU005_REG_RGB_CH_RAMP(x) (S2MU005_REG_RGB_CH0_RAMP + 2 * (x))
> +#define S2MU005_REG_RGB_CH_STAY(x) (S2MU005_REG_RGB_CH0_STAY + 2 * (x))
> +
> +/* S2MU005_REG_CHGR_STATUS0 */
> +#define S2MU005_CHGR_VBUS BIT(7)
> +#define S2MU005_CHGR_WCIN BIT(6)
> +#define S2MU005_CHGR_VMID BIT(5)
> +#define S2MU005_CHGR_CHG BIT(4)
> +#define S2MU005_CHGR_STAT GENMASK(3, 0)
> +
> +#define S2MU005_CHGR_STAT_DONE FIELD_PREP(S2MU005_CHGR_STAT, 8)
> +#define S2MU005_CHGR_STAT_TOPOFF FIELD_PREP(S2MU005_CHGR_STAT, 7)
> +#define S2MU005_CHGR_STAT_DONE_FLAG FIELD_PREP(S2MU005_CHGR_STAT, 6)
> +#define S2MU005_CHGR_STAT_CV FIELD_PREP(S2MU005_CHGR_STAT, 5)
> +#define S2MU005_CHGR_STAT_CC FIELD_PREP(S2MU005_CHGR_STAT, 4)
> +#define S2MU005_CHGR_STAT_COOL_CHG FIELD_PREP(S2MU005_CHGR_STAT, 3)
> +#define S2MU005_CHGR_STAT_PRE_CHG FIELD_PREP(S2MU005_CHGR_STAT, 2)
> +
> +/* S2MU005_REG_CHGR_STATUS1 */
> +#define S2MU005_CHGR_DETBAT BIT(7)
> +#define S2MU005_CHGR_VBUSOVP GENMASK(6, 4)
> +
> +#define S2MU005_CHGR_VBUS_OVP_OVERVOLT FIELD_PREP(S2MU005_CHGR_OVP, 2)
With definitions like these you can't compare to FIELD_GET on the register value
anymore, i.e. this doesn't work:
reg = readl();
val = FIELD_GET(S2MU005_CHGR_VBUSOVP, reg);
if (val == S2MU005_CHGR_VBUS_OVP_OVERVOLT)
...
or FIELD_PREP() or FIELD_MODIFY() won't work as expected.
I would expect such code to work using usual semantics.
Just define your field values without FIELD_PREP(), e.g.
#define S2MU005_CHGR_VBUS_OVP_OVERVOLT 2
Cheers,
Andre'
> +
> +/* S2MU005_REG_CHGR_STATUS2 */
> +#define S2MU005_CHGR_BAT GENMASK(6, 4)
> +
> +#define S2MU005_CHGR_BAT_VOLT_DET FIELD_PREP(S2MU005_CHGR_BAT, 7)
> +#define S2MU005_CHGR_BAT_FAST_CHG_DET FIELD_PREP(S2MU005_CHGR_BAT, 6)
> +#define S2MU005_CHGR_BAT_COOL_CHG_DET FIELD_PREP(S2MU005_CHGR_BAT, 5)
> +#define S2MU005_CHGR_BAT_LOW_CHG FIELD_PREP(S2MU005_CHGR_BAT, 2)
> +#define S2MU005_CHGR_BAT_SELF_DISCHG FIELD_PREP(S2MU005_CHGR_BAT, 1)
> +#define S2MU005_CHGR_BAT_OVP_DET FIELD_PREP(S2MU005_CHGR_BAT, 0)
> +
> +/* S2MU005_REG_CHGR_STATUS3 */
> +#define S2MU005_CHGR_EVT GENMASK(3, 0)
> +
> +#define S2MU005_CHGR_EVT_WDT_RST FIELD_PREP(S2MU005_CHGR_EVT, 6)
> +#define S2MU005_CHGR_EVT_WDT_SUSP FIELD_PREP(S2MU005_CHGR_EVT, 5)
> +#define S2MU005_CHGR_EVT_VSYS_VUVLO FIELD_PREP(S2MU005_CHGR_EVT, 4)
> +#define S2MU005_CHGR_EVT_VSYS_VOVP FIELD_PREP(S2MU005_CHGR_EVT, 3)
> +#define S2MU005_CHGR_EVT_THERM_FOLDBACK FIELD_PREP(S2MU005_CHGR_EVT, 2)
> +#define S2MU005_CHGR_EVT_THERM_SHUTDOWN FIELD_PREP(S2MU005_CHGR_EVT, 1)
> +
> +/* S2MU005_REG_CHGR_CTRL0 */
> +#define S2MU005_CHGR_CHG_EN BIT(4)
> +#define S2MU005_CHGR_OP_MODE GENMASK(2, 0)
> +
> +#define S2MU005_CHGR_OP_MODE_OTG FIELD_PREP(S2MU005_CHGR_OP_MODE, BIT(2))
> +#define S2MU005_CHGR_OP_MODE_CHG FIELD_PREP(S2MU005_CHGR_OP_MODE, BIT(1))
> +
> +/* S2MU005_REG_CHGR_CTRL1 */
> +#define S2MU005_CHGR_VIN_DROP GENMASK(6, 4)
> +
> +/* S2MU005_REG_CHGR_CTRL2 */
> +#define S2MU005_CHGR_IN_CURR_LIM GENMASK(5, 0)
> +
> +/* S2MU005_REG_CHGR_CTRL4 */
> +#define S2MU005_CHGR_OTG_OCP_ON BIT(5)
> +#define S2MU005_CHGR_OTG_OCP_OFF BIT(4)
> +#define S2MU005_CHGR_OTG_OCP GENMASK(3, 2)
> +
> +/* S2MU005_REG_CHGR_CTRL5 */
> +#define S2MU005_CHGR_VMID_BOOST GENMASK(4, 0)
> +
> +/* S2MU005_REG_CHGR_CTRL6 */
> +#define S2MU005_CHGR_COOL_CHG_CURR GENMASK(5, 0)
> +
> +/* S2MU005_REG_CHGR_CTRL7 */
> +#define S2MU005_CHGR_FAST_CHG_CURR GENMASK(5, 0)
> +
> +/* S2MU005_REG_CHGR_CTRL8 */
> +#define S2MU005_CHGR_VF_VBAT GENMASK(6, 1)
> +
> +/* S2MU005_REG_CHGR_CTRL10 */
> +#define S2MU005_CHGR_TOPOFF_CURR(x) (GENMASK(3, 0) << 4 * (x))
> +
> +/* S2MU005_REG_CHGR_CTRL11 */
> +#define S2MU005_CHGR_OSC_BOOST GENMASK(6, 5)
> +#define S2MU005_CHGR_OSC_BUCK GENMASK(4, 3)
> +
> +/* S2MU005_REG_CHGR_CTRL12 */
> +#define S2MU005_CHGR_WDT GENMASK(2, 0)
> +
> +#define S2MU005_CHGR_WDT_ON FIELD_PREP(S2MU005_CHGR_WDT, BIT(2))
> +#define S2MU005_CHGR_WDT_OFF FIELD_PREP(S2MU005_CHGR_WDT, BIT(1))
> +
> +/* S2MU005_REG_CHGR_CTRL15 */
> +#define S2MU005_CHGR_OTG_EN GENMASK(3, 2)
> +
> +/* S2MU005_REG_FLED_STATUS */
> +#define S2MU005_FLED_FLASH_STATUS(x) (BIT(7) >> 2 * (x))
> +#define S2MU005_FLED_TORCH_STATUS(x) (BIT(6) >> 2 * (x))
> +
> +/* S2MU005_REG_FLED_CHx_CTRL0 */
> +#define S2MU005_FLED_FLASH_IOUT GENMASK(3, 0)
> +
> +/* S2MU005_REG_FLED_CHx_CTRL1 */
> +#define S2MU005_FLED_TORCH_IOUT GENMASK(3, 0)
> +
> +/* S2MU005_REG_FLED_CHx_CTRL2 */
> +#define S2MU005_FLED_TORCH_TIMEOUT GENMASK(3, 0)
> +
> +/* S2MU005_REG_FLED_CHx_CTRL3 */
> +#define S2MU005_FLED_FLASH_TIMEOUT GENMASK(3, 0)
> +
> +/* S2MU005_REG_FLED_CTRL1 */
> +#define S2MU005_FLED_CH_EN BIT(7)
> +
> +/*
> + * S2MU005_REG_FLED_CTRL4 - Rev. EVT0
> + * S2MU005_REG_FLED_CTRL6 - Rev. EVT1 and later
> + */
> +#define S2MU005_FLED_FLASH_EN(x) (GENMASK(7, 6) >> 4 * (x))
> +#define S2MU005_FLED_TORCH_EN(x) (GENMASK(5, 4) >> 4 * (x))
> +
> +/* S2MU005_REG_RGB_EN */
> +#define S2MU005_RGB_RESET BIT(6)
> +#define S2MU005_RGB_SLOPE GENMASK(5, 0)
> +
> +#define S2MU005_RGB_SLOPE_CONST (BIT(4) | BIT(2) | BIT(0))
> +#define S2MU005_RGB_SLOPE_SMOOTH (BIT(5) | BIT(3) | BIT(1))
> +
> +/* S2MU005_REG_RGB_CHx_RAMP */
> +#define S2MU005_RGB_CH_RAMP_UP GENMASK(7, 4)
> +#define S2MU005_RGB_CH_RAMP_DN GENMASK(3, 0)
> +
> +/* S2MU005_REG_RGB_CHx_STAY */
> +#define S2MU005_RGB_CH_STAY_HI GENMASK(7, 4)
> +#define S2MU005_RGB_CH_STAY_LO GENMASK(3, 0)
> +
> +/* S2MU005_REG_MUIC_DEV1 */
> +#define S2MU005_MUIC_OTG BIT(7)
> +#define S2MU005_MUIC_DCP BIT(6)
> +#define S2MU005_MUIC_CDP BIT(5)
> +#define S2MU005_MUIC_T1_T2_CHG BIT(4)
> +#define S2MU005_MUIC_UART BIT(3)
> +#define S2MU005_MUIC_SDP BIT(2)
> +#define S2MU005_MUIC_LANHUB BIT(1)
> +#define S2MU005_MUIC_AUDIO BIT(0)
> +
> +/* S2MU005_REG_MUIC_DEV2 */
> +#define S2MU005_MUIC_SDP_1P8S BIT(7)
> +#define S2MU005_MUIC_AV BIT(6)
> +#define S2MU005_MUIC_TTY BIT(5)
> +#define S2MU005_MUIC_PPD BIT(4)
> +#define S2MU005_MUIC_JIG_UART_OFF BIT(3)
> +#define S2MU005_MUIC_JIG_UART_ON BIT(2)
> +#define S2MU005_MUIC_JIG_USB_OFF BIT(1)
> +#define S2MU005_MUIC_JIG_USB_ON BIT(0)
> +
> +/* S2MU005_REG_MUIC_DEV3 */
> +#define S2MU005_MUIC_U200_CHG BIT(7)
> +#define S2MU005_MUIC_VBUS_AV BIT(4)
> +#define S2MU005_MUIC_VBUS_R255 BIT(1)
> +#define S2MU005_MUIC_MHL BIT(0)
> +
> +/* S2MU005_REG_MUIC_DEVAPPLE */
> +#define S2MU005_MUIC_APPLE_CHG_0P5A BIT(7)
> +#define S2MU005_MUIC_APPLE_CHG_1P0A BIT(6)
> +#define S2MU005_MUIC_APPLE_CHG_2P0A BIT(5)
> +#define S2MU005_MUIC_APPLE_CHG_2P4A BIT(4)
> +#define S2MU005_MUIC_SDP_DCD_OUT BIT(3)
> +#define S2MU005_MUIC_RID_WAKEUP BIT(2)
> +#define S2MU005_MUIC_VBUS_WAKEUP BIT(1)
> +#define S2MU005_MUIC_BCV1P2_OR_OPEN BIT(0)
> +
> +/* S2MU005_REG_ID */
> +#define S2MU005_ID_MASK GENMASK(3, 0)
> +#define S2MU005_ID_SHIFT 0
> +
> +/* S2MU005_REG_MUIC_SWCTRL */
> +#define S2MU005_MUIC_DM_DP GENMASK(7, 2)
> +#define S2MU005_MUIC_JIG BIT(0)
> +
> +#define S2MU005_MUIC_DM_DP_UART FIELD_PREP(S2MU005_MUIC_DM_DP, 0x12)
> +#define S2MU005_MUIC_DM_DP_USB FIELD_PREP(S2MU005_MUIC_DM_DP, 0x09)
> +
> +/* S2MU005_REG_MUIC_CTRL1 */
> +#define S2MU005_MUIC_OPEN BIT(4)
> +#define S2MU005_MUIC_RAW_DATA BIT(3)
> +#define S2MU005_MUIC_MAN_SW BIT(2)
> +#define S2MU005_MUIC_WAIT BIT(1)
> +#define S2MU005_MUIC_IRQ BIT(0)
> +
> +/* S2MU005_REG_MUIC_CTRL3 */
> +#define S2MU005_MUIC_ONESHOT_ADC BIT(2)
> +
> +/* S2MU005_REG_MUIC_LDOADC_L and S2MU005_REG_MUIC_LDOADC_H */
> +#define S2MU005_MUIC_VSET GENMASK(4, 0)
> +
> +#define S2MU005_MUIC_VSET_3P0V FIELD_PREP(S2MU005_MUIC_VSET, 0x1f)
> +#define S2MU005_MUIC_VSET_2P6V FIELD_PREP(S2MU005_MUIC_VSET, 0x0e)
> +#define S2MU005_MUIC_VSET_2P4V FIELD_PREP(S2MU005_MUIC_VSET, 0x0c)
> +#define S2MU005_MUIC_VSET_2P2V FIELD_PREP(S2MU005_MUIC_VSET, 0x0a)
> +#define S2MU005_MUIC_VSET_2P0V FIELD_PREP(S2MU005_MUIC_VSET, 0x08)
> +#define S2MU005_MUIC_VSET_1P5V FIELD_PREP(S2MU005_MUIC_VSET, 0x03)
> +#define S2MU005_MUIC_VSET_1P4V FIELD_PREP(S2MU005_MUIC_VSET, 0x02)
> +#define S2MU005_MUIC_VSET_1P2V FIELD_PREP(S2MU005_MUIC_VSET, 0x00)
> +
> +#endif /* __LINUX_MFD_S2MU005_H */
^ 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-04 15:05 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: <f6d1340062448cf52e4c034d250524e030877898.camel@linaro.org>
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.
>
> Cheers,
> Andre'
>
>> };
>>
>> struct sec_platform_data {
^ permalink raw reply
* Re: [PATCH v2 07/12] mfd: sec: store hardware revision in sec_pmic_dev and add S2MU005 support
From: André Draszik @ 2026-02-04 14:17 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-7-78f1a75f547a@disroot.org>
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.
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?
Cheers,
Andre'
> };
>
> struct sec_platform_data {
^ permalink raw reply
* Re: [PATCH v1 07/10] dt-bindings: input: cpcap-pwrbutton: convert to schema
From: Svyatoslav Ryhel @ 2026-02-03 15:03 UTC (permalink / raw)
To: Rob Herring
Cc: David Lechner, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <20260203150136.GA2294714-robh@kernel.org>
вт, 3 лют. 2026 р. о 17:01 Rob Herring <robh@kernel.org> пише:
>
> On Sun, Feb 01, 2026 at 09:07:07AM +0200, Svyatoslav Ryhel wrote:
> > сб, 31 січ. 2026 р. о 22:02 David Lechner <dlechner@baylibre.com> пише:
> > >
> > > On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> > > > Convert power button 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>
> > > > ---
> > > > .../bindings/input/cpcap-pwrbutton.txt | 20 ------------
> > > > .../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
> > > > 2 files changed, 32 insertions(+), 20 deletions(-)
> > > > delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > > > create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > > > deleted file mode 100644
> > > > index 0dd0076daf71..000000000000
> > > > --- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > > > +++ /dev/null
> > > > @@ -1,20 +0,0 @@
> > > > -Motorola CPCAP on key
> > > > -
> > > > -This module is part of the CPCAP. For more details about the whole
> > > > -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> > > > -
> > > > -This module provides a simple power button event via an Interrupt.
> > > > -
> > > > -Required properties:
> > > > -- compatible: should be one of the following
> > > > - - "motorola,cpcap-pwrbutton"
> > > > -- interrupts: irq specifier for CPCAP's ON IRQ
> > > > -
> > > > -Example:
> > > > -
> > > > -&cpcap {
> > > > - cpcap_pwrbutton: pwrbutton {
> > > > - compatible = "motorola,cpcap-pwrbutton";
> > > > - interrupts = <23 IRQ_TYPE_NONE>;
> > > > - };
> > > > -};
> > > > diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > > > new file mode 100644
> > > > index 000000000000..643f6b2b1f13
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > > > @@ -0,0 +1,32 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > > +%YAML 1.2
> > > > +---
> > > > +$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
> > > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > > +
> > > > +title: Motorola CPCAP PMIC power key
> > > > +
> > > > +maintainers:
> > > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > > +
> > > > +description:
> > > > + This module is part of the Motorola CPCAP MFD device. For more details
> > > > + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> > > > + power key is represented as a sub-node of the PMIC node on the device
> > > > + tree.
> > > > +
> > > > +properties:
> > > > + compatible:
> > > > + const: motorola,cpcap-pwrbutton
> > > > +
> > > > + interrupts:
> > > > + minItems: 1
> > >
> > > Should this be maxItems: 1?
> > >
> > > > + description: CPCAP's ON interrupt
> > >
> > > Or I suppose:
> > >
> > > items:
> > > - description: ...
> > >
> >
> > Both options are perfectly fine for me, and I lean towards using
> > "items: desc" but I would like to hear what schema maintainers would
> > say, which layout is preferred in this case.
>
> Either is fine. 'description' is fine if you have something specific
> about the interrupt to say. Saying what the interrupt is for is
> specific. So 'description' is good in this case.
>
Noted, thank you.
> Rob
^ permalink raw reply
* Re: [PATCH v1 07/10] dt-bindings: input: cpcap-pwrbutton: convert to schema
From: Rob Herring @ 2026-02-03 15:01 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: David Lechner, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <CAPVz0n25ukBJ6=hmmR9nd4MBoPkHaHQ+ZHMXYxghYZdkB28_sg@mail.gmail.com>
On Sun, Feb 01, 2026 at 09:07:07AM +0200, Svyatoslav Ryhel wrote:
> сб, 31 січ. 2026 р. о 22:02 David Lechner <dlechner@baylibre.com> пише:
> >
> > On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> > > Convert power button 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>
> > > ---
> > > .../bindings/input/cpcap-pwrbutton.txt | 20 ------------
> > > .../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
> > > 2 files changed, 32 insertions(+), 20 deletions(-)
> > > delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > > create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > > deleted file mode 100644
> > > index 0dd0076daf71..000000000000
> > > --- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > > +++ /dev/null
> > > @@ -1,20 +0,0 @@
> > > -Motorola CPCAP on key
> > > -
> > > -This module is part of the CPCAP. For more details about the whole
> > > -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> > > -
> > > -This module provides a simple power button event via an Interrupt.
> > > -
> > > -Required properties:
> > > -- compatible: should be one of the following
> > > - - "motorola,cpcap-pwrbutton"
> > > -- interrupts: irq specifier for CPCAP's ON IRQ
> > > -
> > > -Example:
> > > -
> > > -&cpcap {
> > > - cpcap_pwrbutton: pwrbutton {
> > > - compatible = "motorola,cpcap-pwrbutton";
> > > - interrupts = <23 IRQ_TYPE_NONE>;
> > > - };
> > > -};
> > > diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > > new file mode 100644
> > > index 000000000000..643f6b2b1f13
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > > @@ -0,0 +1,32 @@
> > > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: Motorola CPCAP PMIC power key
> > > +
> > > +maintainers:
> > > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > > +
> > > +description:
> > > + This module is part of the Motorola CPCAP MFD device. For more details
> > > + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> > > + power key is represented as a sub-node of the PMIC node on the device
> > > + tree.
> > > +
> > > +properties:
> > > + compatible:
> > > + const: motorola,cpcap-pwrbutton
> > > +
> > > + interrupts:
> > > + minItems: 1
> >
> > Should this be maxItems: 1?
> >
> > > + description: CPCAP's ON interrupt
> >
> > Or I suppose:
> >
> > items:
> > - description: ...
> >
>
> Both options are perfectly fine for me, and I lean towards using
> "items: desc" but I would like to hear what schema maintainers would
> say, which layout is preferred in this case.
Either is fine. 'description' is fine if you have something specific
about the interrupt to say. Saying what the interrupt is for is
specific. So 'description' is good in this case.
Rob
^ permalink raw reply
* Re: [PATCH 4/4] rtc: ds1307: Add support for reading RX8901CE battery VL status
From: Fredrik M Olsson @ 2026-02-03 14:26 UTC (permalink / raw)
To: Alexandre Belloni, Fredrik M Olsson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nobuhiro Iwamatsu,
linux-rtc, devicetree, linux-kernel, kernel
In-Reply-To: <20260131000549071abafa@mail.local>
On 1/31/26 01:05, Alexandre Belloni wrote:
> [Some people who received this message don't often get email from alexandre.belloni@bootlin.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On 19/12/2025 13:10:38+0100, Fredrik M Olsson wrote:
>> Adds support for:
>> - Reading the battery voltage low status using the RTC_VL_READ ioctl,
>> which also reports invalid time information if the VLF flag is set.
>>
>> Signed-off-by: Fredrik M Olsson <fredrik.m.olsson@axis.com>
>> ---
>> drivers/rtc/rtc-ds1307.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
>> 1 file changed, 43 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/rtc/rtc-ds1307.c b/drivers/rtc/rtc-ds1307.c
>> index 99d95e520108..ca062ed0c867 100644
>> --- a/drivers/rtc/rtc-ds1307.c
>> +++ b/drivers/rtc/rtc-ds1307.c
>> @@ -133,8 +133,11 @@ enum ds_type {
>> #define RX8901_REG_INTF 0x0e
>> #define RX8901_REG_INTF_VLF BIT(1)
>> #define RX8901_REG_PWSW_CFG 0x37
>> +#define RX8901_REG_PWSW_CFG_VBATLDETEN BIT(4)
>> #define RX8901_REG_PWSW_CFG_INIEN BIT(6)
>> #define RX8901_REG_PWSW_CFG_CHGEN BIT(7)
>> +#define RX8901_REG_BUF_INTF 0x46
>> +#define RX8901_REG_BUF_INTF_VBATLF BIT(3)
>>
>> #define MCP794XX_REG_CONTROL 0x07
>> # define MCP794XX_BIT_ALM0_EN 0x10
>> @@ -458,6 +461,39 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
>> return 0;
>> }
>>
>> +#ifdef CONFIG_RTC_INTF_DEV
>> +static int rx8901_ioctl(struct device *dev, unsigned int cmd, unsigned long arg)
>> +{
>> + struct ds1307 *ds1307 = dev_get_drvdata(dev);
>> + unsigned int regflag, tmp = 0;
>> + int ret = 0;
>> +
>> + switch (cmd) {
>> + case RTC_VL_READ:
>> + ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, ®flag);
>> + if (ret)
>> + return ret;
>> +
>> + if (regflag & RX8901_REG_INTF_VLF)
>> + tmp |= RTC_VL_DATA_INVALID;
>> +
>> + ret = regmap_read(ds1307->regmap, RX8901_REG_BUF_INTF, ®flag);
>> + if (ret)
>> + return ret;
>> +
>> + if (regflag & RX8901_REG_BUF_INTF_VBATLF)
>> + tmp |= RTC_VL_BACKUP_LOW;
>> +
>> + return put_user(tmp, (unsigned int __user *)arg);
>> + default:
>> + return -ENOIOCTLCMD;
>> + }
>> + return ret;
>> +}
>> +#else
>> +#define rx8901_ioctl NULL
>> +#endif
>> +
>> static int ds1337_read_alarm(struct device *dev, struct rtc_wkalrm *t)
>> {
>> struct ds1307 *ds1307 = dev_get_drvdata(dev);
>> @@ -599,10 +635,13 @@ static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
>> return setup;
>> }
>>
>> -static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms, bool diode)
>> +static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms __always_unused, bool diode)
>> {
>> - /* make sure that the backup battery is enabled */
>> - u8 setup = RX8901_REG_PWSW_CFG_INIEN;
>> + /*
>> + * make sure that the backup battery is enabled and that battery
>> + * voltage detection is performed
>> + */
>> + u8 setup = RX8901_REG_PWSW_CFG_INIEN | RX8901_REG_PWSW_CFG_VBATLDETEN;
>>
>> if (diode)
>> setup |= RX8901_REG_PWSW_CFG_CHGEN;
>> @@ -1005,6 +1044,7 @@ static const struct rtc_class_ops rx8130_rtc_ops = {
>> static const struct rtc_class_ops rx8901_rtc_ops = {
>> .read_time = ds1307_get_time,
>> .set_time = ds1307_set_time,
>> + .ioctl = rx8901_ioctl,
>> };
>>
>
> This seems to be an unrelated changed that hasn't been squashed in the
> proper patch.
>
Okay I will squash this change into patch 3 for v2.
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
--
/Fredrik
^ permalink raw reply
* Re: [PATCH 3/4] rtc: ds1307: Add Driver for Epson RX8901CE
From: Fredrik M Olsson @ 2026-02-03 14:23 UTC (permalink / raw)
To: Alexandre Belloni, Fredrik M Olsson
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Nobuhiro Iwamatsu,
linux-rtc, devicetree, linux-kernel, kernel
In-Reply-To: <20260131000350d1fac76c@mail.local>
On 1/31/26 01:03, Alexandre Belloni wrote:
> [Some people who received this message don't often get email from alexandre.belloni@bootlin.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hello,
>
> On 19/12/2025 13:10:37+0100, Fredrik M Olsson wrote:
>> #define MCP794XX_REG_CONTROL 0x07
>> # define MCP794XX_BIT_ALM0_EN 0x10
>> # define MCP794XX_BIT_ALM1_EN 0x20
>> @@ -226,6 +233,19 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
>> dev_warn_once(dev, "oscillator failed, set time!\n");
>> return -EINVAL;
>> }
>> + } else if (ds1307->type == rx_8901) {
>> + unsigned int regflag;
>> +
>> + ret = regmap_read(ds1307->regmap, RX8901_REG_INTF, ®flag);
>> + if (ret) {
>> + dev_err(dev, "%s error %d\n", "read", ret);
>
> The multiple dev_err you are adding should be dev_dbg as there is no
> other actions for the user than to restart the operation when it fails
> so there is not actual value apart when debugging.
>
Okay thanks I will update that for v2.
>> + return ret;
>> + }
>> +
>> + if (regflag & RX8901_REG_INTF_VLF) {
>> + dev_warn_once(dev, "oscillator failed, set time!\n");
>> + return -EINVAL;
>> + }
>> }
>>
>> /* read the RTC date and time registers all at once */
>> @@ -307,7 +327,7 @@ static int ds1307_get_time(struct device *dev, struct rtc_time *t)
>> tmp = regs[DS1307_REG_HOUR] & 0x3f;
>> t->tm_hour = bcd2bin(tmp);
>> /* rx8130 is bit position, not BCD */
>> - if (ds1307->type == rx_8130)
>> + if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
>> t->tm_wday = fls(regs[DS1307_REG_WDAY] & 0x7f) - 1;
>> else
>> t->tm_wday = bcd2bin(regs[DS1307_REG_WDAY] & 0x07) - 1;
>> @@ -358,7 +378,7 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
>> regs[DS1307_REG_MIN] = bin2bcd(t->tm_min);
>> regs[DS1307_REG_HOUR] = bin2bcd(t->tm_hour);
>> /* rx8130 is bit position, not BCD */
>> - if (ds1307->type == rx_8130)
>> + if (ds1307->type == rx_8130 || ds1307->type == rx_8901)
>> regs[DS1307_REG_WDAY] = 1 << t->tm_wday;
>> else
>> regs[DS1307_REG_WDAY] = bin2bcd(t->tm_wday + 1);
>> @@ -422,6 +442,17 @@ static int ds1307_set_time(struct device *dev, struct rtc_time *t)
>> dev_err(dev, "%s error %d\n", "write", result);
>> return result;
>> }
>> + } else if (ds1307->type == rx_8901) {
>> + /*
>> + * clear Voltage Loss Flag as data is available now (writing 1
>> + * to the other bits in the INTF register has no effect)
>> + */
>> + result = regmap_write(ds1307->regmap, RX8901_REG_INTF,
>> + 0xff ^ RX8901_REG_INTF_VLF);
>> + if (result) {
>> + dev_err(dev, "%s error %d\n", "write", result);
>> + return result;
>> + }
>> }
>>
>> return 0;
>> @@ -568,6 +599,17 @@ static u8 do_trickle_setup_rx8130(struct ds1307 *ds1307, u32 ohms, bool diode)
>> return setup;
>> }
>>
>> +static u8 do_trickle_setup_rx8901(struct ds1307 *ds1307, u32 ohms, bool diode)
>> +{
>> + /* make sure that the backup battery is enabled */
>> + u8 setup = RX8901_REG_PWSW_CFG_INIEN;
>
> You can't do this as this will cause issues in the future for people
> wanting to keep this bit disabled (the main reason being that you don't
> want to draw power from the battery while your device sits on a shelf).
> You have to handle the RTC_PARAM_BACKUP_SWITCH_MODE parameter and then
> switch it from userspace.
Here my intention was to do something similar to what was done before
for the rx8130 device [1], which as I understand it require similar
setup initialization as the rx8901 device does. Is using the
RTC_PARAM_BACKUP_SWITCH_MODE the new way of performing this initialization?
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
[1] 0026f1604c9b (rtc: ds1307: enable rx8130's backup battery, make it
chargeable optionally)
--
/Fredrik
^ permalink raw reply
* Re: [PATCH v1 08/10] dt-bindings: mfg: motorola-cpcap: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:09 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <fca2c04b-fe1c-4685-9c80-b0d7d37ced60@baylibre.com>
сб, 31 січ. 2026 р. о 22:07 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/25/26 7:43 AM, Svyatoslav Ryhel wrote:
> > Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> > Audio codec bindings adjusted with common ports node for port@0 and
> > port@1. Added compatible for Mot board CPCAP. Other bindings remain the
> > same.
> >
>
> ...
>
> > +examples:
>
> Ah, I guess this covers all of the missing examples. The other commit
> messages should say that was the plan so we know why the examples were
> omitted in the other patches.
>
Subdevices schema state that they are part of MFD and link to the main
MFD schema. MFD device description mandates to have a complete device
example so having examples for each subdevice is redundant.
^ permalink raw reply
* Re: [PATCH v1 07/10] dt-bindings: input: cpcap-pwrbutton: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:07 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <8bd89524-dfc3-43b0-b0f2-cdb1cd51e1ac@baylibre.com>
сб, 31 січ. 2026 р. о 22:02 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> > Convert power button 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>
> > ---
> > .../bindings/input/cpcap-pwrbutton.txt | 20 ------------
> > .../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
> > 2 files changed, 32 insertions(+), 20 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > deleted file mode 100644
> > index 0dd0076daf71..000000000000
> > --- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> > +++ /dev/null
> > @@ -1,20 +0,0 @@
> > -Motorola CPCAP on key
> > -
> > -This module is part of the CPCAP. For more details about the whole
> > -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> > -
> > -This module provides a simple power button event via an Interrupt.
> > -
> > -Required properties:
> > -- compatible: should be one of the following
> > - - "motorola,cpcap-pwrbutton"
> > -- interrupts: irq specifier for CPCAP's ON IRQ
> > -
> > -Example:
> > -
> > -&cpcap {
> > - cpcap_pwrbutton: pwrbutton {
> > - compatible = "motorola,cpcap-pwrbutton";
> > - interrupts = <23 IRQ_TYPE_NONE>;
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > new file mode 100644
> > index 000000000000..643f6b2b1f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> > @@ -0,0 +1,32 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Motorola CPCAP PMIC power key
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + This module is part of the Motorola CPCAP MFD device. For more details
> > + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> > + power key is represented as a sub-node of the PMIC node on the device
> > + tree.
> > +
> > +properties:
> > + compatible:
> > + const: motorola,cpcap-pwrbutton
> > +
> > + interrupts:
> > + minItems: 1
>
> Should this be maxItems: 1?
>
> > + description: CPCAP's ON interrupt
>
> Or I suppose:
>
> items:
> - description: ...
>
Both options are perfectly fine for me, and I lean towards using
"items: desc" but I would like to hear what schema maintainers would
say, which layout is preferred in this case.
>
> > +
> > +required:
> > + - compatible
> > + - interrupts
> > +
> > +additionalProperties: false
> > +
>
> example: ...
>
> > +...
>
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:01 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <8cedbb9c-9f72-43ae-a23e-705b3feb85fb@baylibre.com>
сб, 31 січ. 2026 р. о 21:55 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/31/26 1:46 PM, David Lechner wrote:
> > On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> >> Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> >> from TXT to YAML format. Main functionality preserved and added compatible
> >> for CPCAP regulator set found in the Mot board.
> >>
>
> ...
>
> >> +properties:
> >> + compatible:
> >> + enum:
> >> + - motorola,cpcap-regulator
> >> + - motorola,mapphone-cpcap-regulator
> >> + - motorola,mot-cpcap-regulator
>
> This is what caused me to get confused on the order of the later patches.
>
> motorola,mot-cpcap-regulator is a new compatible, so would be better as
> a separate patch.
>
Rob already cleared this up
^ permalink raw reply
* Re: [PATCH v1 01/10] dt-bindings: regulator: cpcap-regulator: convert to schema
From: Svyatoslav Ryhel @ 2026-02-01 7:01 UTC (permalink / raw)
To: David Lechner
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov, Lee Jones,
Pavel Machek, Liam Girdwood, Mark Brown, Alexandre Belloni,
Dixit Parmar, Tony Lindgren, linux-iio, devicetree, linux-kernel,
linux-input, linux-leds, linux-rtc
In-Reply-To: <d7938728-fded-4d5e-b23d-a8346e3fab46@baylibre.com>
сб, 31 січ. 2026 р. о 21:46 David Lechner <dlechner@baylibre.com> пише:
>
> On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> > Convert devicetree bindings for the Motorola CPCAP MFD regulator subnode
> > from TXT to YAML format. Main functionality preserved and added compatible
> > for CPCAP regulator set found in the Mot board.
> >
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > ---
> > .../bindings/regulator/cpcap-regulator.txt | 35 -------------
> > .../regulator/motorola,cpcap-regulator.yaml | 51 +++++++++++++++++++
> > 2 files changed, 51 insertions(+), 35 deletions(-)
> > delete mode 100644 Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > create mode 100644 Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt b/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > deleted file mode 100644
> > index 36f5e2f5cc0f..000000000000
> > --- a/Documentation/devicetree/bindings/regulator/cpcap-regulator.txt
> > +++ /dev/null
> > @@ -1,35 +0,0 @@
> > -Motorola CPCAP PMIC voltage regulators
> > -------------------------------------
> > -
> > -Requires node properties:
> > -- "compatible" value one of:
> > - "motorola,cpcap-regulator"
> > - "motorola,mapphone-cpcap-regulator"
> > - "motorola,xoom-cpcap-regulator"
> > -
> > -Required regulator properties:
> > -- "regulator-name"
> > -- "regulator-enable-ramp-delay"
> > -- "regulator-min-microvolt"
> > -- "regulator-max-microvolt"
> > -
> > -Optional regulator properties:
> > -- "regulator-boot-on"
> > -
> > -See Documentation/devicetree/bindings/regulator/regulator.txt
> > -for more details about the regulator properties.
> > -
> > -Example:
> > -
> > -cpcap_regulator: regulator {
> > - compatible = "motorola,cpcap-regulator";
> > -
> > - cpcap_regulators: regulators {
> > - sw5: SW5 {
>
> Old example is missing the required regulator-names property.
>
> > - regulator-min-microvolt = <5050000>;
> > - regulator-max-microvolt = <5050000>;
> > - regulator-enable-ramp-delay = <50000>;
> > - regulator-boot-on;
> > - };
> > - };
> > -};
> > diff --git a/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> > new file mode 100644
> > index 000000000000..b73d32a86904
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/regulator/motorola,cpcap-regulator.yaml
> > @@ -0,0 +1,51 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/regulator/motorola,cpcap-regulator.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Motorola CPCAP PMIC regulators
> > +
> > +maintainers:
> > + - Svyatoslav Ryhel <clamor95@gmail.com>
> > +
> > +description:
> > + This module is part of the Motorola CPCAP MFD device. For more details
> > + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> > + regulator controller is represented as a sub-node of the PMIC node
> > + on the device tree.
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - motorola,cpcap-regulator
> > + - motorola,mapphone-cpcap-regulator
> > + - motorola,mot-cpcap-regulator
> > + - motorola,xoom-cpcap-regulator
> > +
> > + regulators:
> > + type: object
> > +
> > + patternProperties:
> > + "$[A-Z0-9]+^":
>
> Why not put the valid names here? Or does the node name not actually matter?
> (in which case lower case could be allowed too.)
>
> "^(SW1|SW2|...)$":
>
> And $,^ are swapped.
>
This is an interesting suggestion, maybe schema maintainers can
suggest how to approach this? Node name and case matters, list of
possible names is in the description.
> > + $ref: /schemas/regulator/regulator.yaml#
> > + type: object
> > + description:
> > + Valid regulator names are SW1, SW2, SW3, SW4, SW5, VCAM, VCSI,
> > + VDAC, VDIG, VFUSE, VHVIO, VSDIO, VPLL, VRF1, VRF2, VRFREF, VWLAN1,
> > + VWLAN2, VSIM, VSIMCARD, VVIB, VUSB, VAUDIO
> > +
>
> If these apply to the regulator-name property, it can be written instead as:
>
Regulator name does not matter, any name is acceptible.
> properties:
> regulator-name:
> enum:
> - SW1
> - SW2
> ...
>
>
> Not sure if it is strictly needed, but this would document the optional
> property:
>
> regulator-boot-on: true
>
this is covered by common regulator schema, along with other possible
regulator properties
> > + required:
> > + - regulator-name
> > + - regulator-enable-ramp-delay
> > + - regulator-min-microvolt
> > + - regulator-max-microvolt
> > +
> > + unevaluatedProperties: false
> > +
> > +required:
> > + - compatible
> > +
> > +additionalProperties: false
> > +
>
> Example should go here.
>
> > +...
>
^ permalink raw reply
* Re: [PATCH v1 08/10] dt-bindings: mfg: motorola-cpcap: convert to schema
From: David Lechner @ 2026-01-31 20:07 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-9-clamor95@gmail.com>
On 1/25/26 7:43 AM, Svyatoslav Ryhel wrote:
> Convert devicetree bindings for the Motorola CPCAP MFD from TXT to YAML.
> Audio codec bindings adjusted with common ports node for port@0 and
> port@1. Added compatible for Mot board CPCAP. Other bindings remain the
> same.
>
...
> +examples:
Ah, I guess this covers all of the missing examples. The other commit
messages should say that was the plan so we know why the examples were
omitted in the other patches.
^ permalink raw reply
* Re: [PATCH v1 07/10] dt-bindings: input: cpcap-pwrbutton: convert to schema
From: David Lechner @ 2026-01-31 20:02 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-8-clamor95@gmail.com>
On 1/25/26 7:42 AM, Svyatoslav Ryhel wrote:
> Convert power button 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>
> ---
> .../bindings/input/cpcap-pwrbutton.txt | 20 ------------
> .../input/motorola,cpcap-pwrbutton.yaml | 32 +++++++++++++++++++
> 2 files changed, 32 insertions(+), 20 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> create mode 100644 Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
>
> diff --git a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt b/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> deleted file mode 100644
> index 0dd0076daf71..000000000000
> --- a/Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt
> +++ /dev/null
> @@ -1,20 +0,0 @@
> -Motorola CPCAP on key
> -
> -This module is part of the CPCAP. For more details about the whole
> -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> -
> -This module provides a simple power button event via an Interrupt.
> -
> -Required properties:
> -- compatible: should be one of the following
> - - "motorola,cpcap-pwrbutton"
> -- interrupts: irq specifier for CPCAP's ON IRQ
> -
> -Example:
> -
> -&cpcap {
> - cpcap_pwrbutton: pwrbutton {
> - compatible = "motorola,cpcap-pwrbutton";
> - interrupts = <23 IRQ_TYPE_NONE>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> new file mode 100644
> index 000000000000..643f6b2b1f13
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/motorola,cpcap-pwrbutton.yaml
> @@ -0,0 +1,32 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/input/motorola,cpcap-pwrbutton.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC power key
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + This module is part of the Motorola CPCAP MFD device. For more details
> + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. The
> + power key is represented as a sub-node of the PMIC node on the device
> + tree.
> +
> +properties:
> + compatible:
> + const: motorola,cpcap-pwrbutton
> +
> + interrupts:
> + minItems: 1
Should this be maxItems: 1?
> + description: CPCAP's ON interrupt
Or I suppose:
items:
- description: ...
> +
> +required:
> + - compatible
> + - interrupts
> +
> +additionalProperties: false
> +
example: ...
> +...
^ permalink raw reply
* Re: [PATCH v1 05/10] dt-bindings: leds: leds-cpcap: convert to schema
From: David Lechner @ 2026-01-31 19:59 UTC (permalink / raw)
To: Svyatoslav Ryhel, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Lee Jones, Pavel Machek, Liam Girdwood, Mark Brown,
Alexandre Belloni, Dixit Parmar, Tony Lindgren
Cc: linux-iio, devicetree, linux-kernel, linux-input, linux-leds,
linux-rtc
In-Reply-To: <20260125134302.45958-6-clamor95@gmail.com>
On 1/25/26 7:42 AM, 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
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-cpcap.txt b/Documentation/devicetree/bindings/leds/leds-cpcap.txt
> deleted file mode 100644
> index ebf7cdc7f70c..000000000000
> --- a/Documentation/devicetree/bindings/leds/leds-cpcap.txt
> +++ /dev/null
> @@ -1,29 +0,0 @@
> -Motorola CPCAP PMIC LEDs
> -------------------------
> -
> -This module is part of the CPCAP. For more details about the whole
> -chip see Documentation/devicetree/bindings/mfd/motorola-cpcap.txt.
> -
> -Requires node properties:
> -- compatible: should be one of
> - * "motorola,cpcap-led-mdl" (Main Display Lighting)
> - * "motorola,cpcap-led-kl" (Keyboard Lighting)
> - * "motorola,cpcap-led-adl" (Aux Display Lighting)
> - * "motorola,cpcap-led-red" (Red Triode)
> - * "motorola,cpcap-led-green" (Green Triode)
> - * "motorola,cpcap-led-blue" (Blue Triode)
> - * "motorola,cpcap-led-cf" (Camera Flash)
> - * "motorola,cpcap-led-bt" (Bluetooth)
> - * "motorola,cpcap-led-cp" (Camera Privacy LED)
> -- label: see Documentation/devicetree/bindings/leds/common.txt
> -- vdd-supply: A phandle to the regulator powering the LED
> -
> -Example:
> -
> -&cpcap {
> - cpcap_led_red: red-led {
> - compatible = "motorola,cpcap-led-red";
> - label = "cpcap:red";
> - vdd-supply = <&sw5>;
> - };
> -};
> diff --git a/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
> new file mode 100644
> index 000000000000..8dfc98a1ef99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/leds/motorola,cpcap-leds.yaml
> @@ -0,0 +1,42 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/leds/motorola,cpcap-leds.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Motorola CPCAP PMIC leds
> +
> +maintainers:
> + - Svyatoslav Ryhel <clamor95@gmail.com>
> +
> +description:
> + This module is part of the Motorola CPCAP MFD device. For more details
> + see Documentation/devicetree/bindings/mfd/motorola,cpcap.yaml. Leds are
s/Leds/LEDs/
> + represented as sub-nodes of the PMIC node on the device tree.
> +
> +allOf:
> + - $ref: /schemas/leds/common.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - motorola,cpcap-led-adl # Display Lighting
> + - motorola,cpcap-led-blue # Blue Triode
> + - motorola,cpcap-led-bt # Bluetooth
> + - motorola,cpcap-led-cf # Camera Flash
> + - motorola,cpcap-led-cp # Camera Privacy LED
> + - motorola,cpcap-led-green # Green Triode
> + - motorola,cpcap-led-kl # Keyboard Lighting
> + - motorola,cpcap-led-mdl # Main Display Lighting
> + - motorola,cpcap-led-red # Red Triode
> +
> + vdd-supply: true
> +
> +required:
> + - compatible
> + - label
> + - vdd-supply
> +
> +unevaluatedProperties: false
> +
Should keep the example here.
> +...
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox