* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Benno Lossin @ 2026-02-27 15:09 UTC (permalink / raw)
To: Danilo Krummrich, Rafael J. Wysocki
Cc: Alexandre Belloni, Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-rtc, rust-for-linux, Greg Kroah-Hartman
In-Reply-To: <DGO6MEKIIHGH.3L06QJ47CP3CU@kernel.org>
On Wed Feb 25, 2026 at 5:26 PM CET, Danilo Krummrich wrote:
> For the future we will also be able to support references within initializers to
> other pinned fields, which make things a bit more convinient, so you could do
> things like this:
>
> let irq_data = impl_pin_init!(SampleIrqData {
> io <- pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> hw_variant: VendorVariant::StV1,
> });
>
> let rtc_data = impl_pin_init!(SampleRtcData {
> irq <- irq::Registration::new(..., irq_data),
> io: &irq.io,
> ...,
> });
>
> let rtc = rtc::Device::new(dev, rtc_data)?;
>
> Note the additional `io: &irq.io,` in the rtc_data initializer. This would be
> legal as we know that `irq` is pinned within `rtc_data`, hence it is valid to
> hold a reference to one of its pinned fields.
>
> I am not sure how far we are from having this supported, I assume Benno and Gary
> can say more about this.
We added that support in 42415d163e5d ("rust: pin-init: add references
to previously initialized fields"). Note that any references created
during the initializer are only valid inside of that initializer. You
can convert into a raw pointer though and if the struct is `!Unpin` it
is sound to use that pointer at the same time as references to the
pinned value.
Cheers,
Benno
^ permalink raw reply
* Re: [PATCH v3 04/13] dt-bindings: power: supply: document Samsung S2M series PMIC charger device
From: Kaustabh Chakraborty @ 2026-02-27 14:26 UTC (permalink / raw)
To: Krzysztof Kozlowski, Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260225-secret-amusing-cuttlefish-d3bee5@quoll>
On 2026-02-25 11:44 +01:00, Krzysztof Kozlowski wrote:
> On Wed, Feb 25, 2026 at 12:45:06AM +0530, Kaustabh Chakraborty wrote:
>> +
>> + This is a part of device tree bindings for S2M and S5M family of Power
>> + Management IC (PMIC).
>> +
>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>> + additional information and example.
>> +
>> +allOf:
>> + - $ref: power-supply.yaml#
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - samsung,s2mu005-charger
>
> Review from v1 still applies. I think you ignored several reviews, so I
> will mark entire patchset as changes requested.
Somehow I missed this one... anyways I address them here:
Why do you need a dedicated child node for this? It's got one property,
other than the compatible, that you're using. It could easily just go
in the parent without a dedicated node etc.
The dt node also references a simple-battery node, that's why it's
required.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v1 7/8] rtc: cmos: Drop PNP device support
From: Alexandre Belloni @ 2026-02-26 13:02 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux ACPI, LKML, x86 Maintainers, linux-rtc
In-Reply-To: <2355012.iZASKD2KPV@rafael.j.wysocki>
On 23/02/2026 16:32:29+0100, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
>
> Previous changes effectively prevented PNP devices from being created
> for the CMOS RTC on x86 with ACPI.
>
> Although in principle a CMOS RTC PNP device may exist on an x86 system
> without ACPI (that is, an x86 system where there is no ACPI at all, not
> one booted with ACPI disabled), such systems were there in the field ~30
> years ago and most likely they would not be able to run a contemporary
> Linux kernel.
>
> For the above reasons, drop the PNP device support from the rtc-cmos
> driver.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/rtc/rtc-cmos.c | 113 +++--------------------------------------
> 1 file changed, 8 insertions(+), 105 deletions(-)
>
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 7457f42fd6f0..9ac5bab846c1 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -1370,85 +1370,6 @@ static int __maybe_unused cmos_resume(struct device *dev)
>
> static SIMPLE_DEV_PM_OPS(cmos_pm_ops, cmos_suspend, cmos_resume);
>
> -/*----------------------------------------------------------------*/
> -
> -/* On non-x86 systems, a "CMOS" RTC lives most naturally on platform_bus.
> - * ACPI systems always list these as PNPACPI devices, and pre-ACPI PCs
> - * probably list them in similar PNPBIOS tables; so PNP is more common.
> - *
> - * We don't use legacy "poke at the hardware" probing. Ancient PCs that
> - * predate even PNPBIOS should set up platform_bus devices.
> - */
> -
> -#ifdef CONFIG_PNP
> -
> -#include <linux/pnp.h>
> -
> -static int cmos_pnp_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
> -{
> - int irq;
> -
> - if (pnp_port_start(pnp, 0) == 0x70 && !pnp_irq_valid(pnp, 0)) {
> - irq = 0;
> -#ifdef CONFIG_X86
> - /* Some machines contain a PNP entry for the RTC, but
> - * don't define the IRQ. It should always be safe to
> - * hardcode it on systems with a legacy PIC.
> - */
> - if (nr_legacy_irqs())
> - irq = RTC_IRQ;
> -#endif
> - } else {
> - irq = pnp_irq(pnp, 0);
> - }
> -
> - return cmos_do_probe(&pnp->dev, pnp_get_resource(pnp, IORESOURCE_IO, 0), irq);
> -}
> -
> -static void cmos_pnp_remove(struct pnp_dev *pnp)
> -{
> - cmos_do_remove(&pnp->dev);
> -}
> -
> -static void cmos_pnp_shutdown(struct pnp_dev *pnp)
> -{
> - struct device *dev = &pnp->dev;
> - struct cmos_rtc *cmos = dev_get_drvdata(dev);
> -
> - if (system_state == SYSTEM_POWER_OFF) {
> - int retval = cmos_poweroff(dev);
> -
> - if (cmos_aie_poweroff(dev) < 0 && !retval)
> - return;
> - }
> -
> - cmos_do_shutdown(cmos->irq);
> -}
> -
> -static const struct pnp_device_id rtc_ids[] = {
> - { .id = "PNP0b00", },
> - { .id = "PNP0b01", },
> - { .id = "PNP0b02", },
> - { },
> -};
> -MODULE_DEVICE_TABLE(pnp, rtc_ids);
> -
> -static struct pnp_driver cmos_pnp_driver = {
> - .name = driver_name,
> - .id_table = rtc_ids,
> - .probe = cmos_pnp_probe,
> - .remove = cmos_pnp_remove,
> - .shutdown = cmos_pnp_shutdown,
> -
> - /* flag ensures resume() gets called, and stops syslog spam */
> - .flags = PNP_DRIVER_RES_DO_NOT_CHANGE,
> - .driver = {
> - .pm = &cmos_pm_ops,
> - },
> -};
> -
> -#endif /* CONFIG_PNP */
> -
> #ifdef CONFIG_OF
> static const struct of_device_id of_cmos_match[] = {
> {
> @@ -1543,45 +1464,27 @@ static struct platform_driver cmos_platform_driver = {
> }
> };
>
> -#ifdef CONFIG_PNP
> -static bool pnp_driver_registered;
> -#endif
> static bool platform_driver_registered;
>
> static int __init cmos_init(void)
> {
> - int retval = 0;
> + int retval;
>
> -#ifdef CONFIG_PNP
> - retval = pnp_register_driver(&cmos_pnp_driver);
> - if (retval == 0)
> - pnp_driver_registered = true;
> -#endif
> + if (cmos_rtc.dev)
> + return 0;
>
> - if (!cmos_rtc.dev) {
> - retval = platform_driver_probe(&cmos_platform_driver,
> - cmos_platform_probe);
> - if (retval == 0)
> - platform_driver_registered = true;
> - }
> + retval = platform_driver_probe(&cmos_platform_driver, cmos_platform_probe);
> + if (retval)
> + return retval;
>
> - if (retval == 0)
> - return 0;
> + platform_driver_registered = true;
>
> -#ifdef CONFIG_PNP
> - if (pnp_driver_registered)
> - pnp_unregister_driver(&cmos_pnp_driver);
> -#endif
> - return retval;
> + return 0;
> }
> module_init(cmos_init);
>
> static void __exit cmos_exit(void)
> {
> -#ifdef CONFIG_PNP
> - if (pnp_driver_registered)
> - pnp_unregister_driver(&cmos_pnp_driver);
> -#endif
> if (platform_driver_registered)
> platform_driver_unregister(&cmos_platform_driver);
> }
> --
> 2.51.0
>
>
>
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v1 4/8] ACPI: x86/rtc-cmos: Use platform device for driver binding
From: Alexandre Belloni @ 2026-02-26 13:01 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux ACPI, LKML, x86 Maintainers, linux-rtc
In-Reply-To: <13969123.uLZWGnKmhe@rafael.j.wysocki>
On 23/02/2026 16:30:21+0100, Rafael J. Wysocki wrote:
> From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
>
> Modify the rtc-cmos driver to bind to a platform device on systems with
> ACPI via acpi_match_table and advertise the CMOST RTC ACPI device IDs
> for driver auto-loading. Note that adding the requisite device IDs to
> it and exposing them via MODULE_DEVICE_TABLE() is sufficient for this
> purpose.
>
> Since the ACPI device IDs in question are the same as for the CMOS RTC
> ACPI scan handler, put them into a common header file and use the
> definition from there in both places.
>
> Additionally, to prevent a PNP device from being created for the CMOS
> RTC if a platform one is present already, make is_cmos_rtc_device()
> check cmos_rtc_platform_device_present introduced previously.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
> ---
> drivers/acpi/acpi_pnp.c | 2 +-
> drivers/acpi/x86/cmos_rtc.c | 5 +----
> drivers/rtc/rtc-cmos.c | 10 ++++++++++
> include/linux/acpi.h | 6 ++++++
> 4 files changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/acpi/acpi_pnp.c b/drivers/acpi/acpi_pnp.c
> index 85d9f78619a2..4ad8f56d1a5d 100644
> --- a/drivers/acpi/acpi_pnp.c
> +++ b/drivers/acpi/acpi_pnp.c
> @@ -368,7 +368,7 @@ static int is_cmos_rtc_device(struct acpi_device *adev)
> { "PNP0B02" },
> {""},
> };
> - return !acpi_match_device_ids(adev, ids);
> + return !cmos_rtc_platform_device_present && !acpi_match_device_ids(adev, ids);
> }
>
> bool acpi_is_pnp_device(struct acpi_device *adev)
> diff --git a/drivers/acpi/x86/cmos_rtc.c b/drivers/acpi/x86/cmos_rtc.c
> index bdd66dfd4a44..a6df5b991c96 100644
> --- a/drivers/acpi/x86/cmos_rtc.c
> +++ b/drivers/acpi/x86/cmos_rtc.c
> @@ -18,10 +18,7 @@
> #include "../internal.h"
>
> static const struct acpi_device_id acpi_cmos_rtc_ids[] = {
> - { "PNP0B00" },
> - { "PNP0B01" },
> - { "PNP0B02" },
> - {}
> + ACPI_CMOS_RTC_IDS
> };
>
> bool cmos_rtc_platform_device_present;
> diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
> index 0743c6acd6e2..7457f42fd6f0 100644
> --- a/drivers/rtc/rtc-cmos.c
> +++ b/drivers/rtc/rtc-cmos.c
> @@ -27,6 +27,7 @@
>
> #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>
> +#include <linux/acpi.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/init.h>
> @@ -1476,6 +1477,14 @@ static __init void cmos_of_init(struct platform_device *pdev)
> #else
> static inline void cmos_of_init(struct platform_device *pdev) {}
> #endif
> +
> +#ifdef CONFIG_ACPI
> +static const struct acpi_device_id acpi_cmos_rtc_ids[] = {
> + ACPI_CMOS_RTC_IDS
> +};
> +MODULE_DEVICE_TABLE(acpi, acpi_cmos_rtc_ids);
> +#endif
> +
> /*----------------------------------------------------------------*/
>
> /* Platform setup should have set up an RTC device, when PNP is
> @@ -1530,6 +1539,7 @@ static struct platform_driver cmos_platform_driver = {
> .name = driver_name,
> .pm = &cmos_pm_ops,
> .of_match_table = of_match_ptr(of_cmos_match),
> + .acpi_match_table = ACPI_PTR(acpi_cmos_rtc_ids),
> }
> };
>
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 2bdb801cee01..5ecdcdaf31aa 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -791,6 +791,12 @@ const char *acpi_get_subsystem_id(acpi_handle handle);
> int acpi_mrrm_max_mem_region(void);
> #endif
>
> +#define ACPI_CMOS_RTC_IDS \
> + { "PNP0B00", }, \
> + { "PNP0B01", }, \
> + { "PNP0B02", }, \
> + { "", }
> +
> extern bool cmos_rtc_platform_device_present;
>
> #else /* !CONFIG_ACPI */
> --
> 2.51.0
>
>
>
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Rafael J. Wysocki @ 2026-02-26 12:28 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Rafael J. Wysocki, Alexandre Belloni, Alvin Sun, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, linux-rtc,
rust-for-linux, Greg Kroah-Hartman
In-Reply-To: <DGO6MEKIIHGH.3L06QJ47CP3CU@kernel.org>
On Wed, Feb 25, 2026 at 5:26 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Wed Feb 25, 2026 at 2:33 PM CET, Rafael J. Wysocki wrote:
> > On Tue, Feb 24, 2026 at 11:23 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >> Here's also some sketched up code for what I wrote above:
> >>
> >> fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
> >> let dev = pdev.as_ref();
> >>
> >> let rtc_data = impl_pin_init!(SampleRtcData {
> >> io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> >> hw_variant: VendorVariant::StV1,
> >> irq <- irq::Registration::new(...),
> >> });
> >>
> >> let rtc = rtc::Device::new(dev, rtc_data)?;
> >>
> >> rtc::Registration::register(rtc)?;
> >>
> >> Ok(Self { rtc })
> >> }
> >>
> >> Note that if any of the RTC callbacks would ever need to call irq.synchronize(),
> >> irq.disable(), etc. the compiler would enforce correct ordering, as there would
> >> not be any other possibility to put the irq::Registration other than into the
> >> rtc_data that goes into rtc::Device::new().
> >
> > IIUC, the interrupt handler can only access the rtc_data because the
> > parent's driver_data may not exist yet when it runs. Or am I missing
> > something?
>
> In the code above the IRQ handler can also not access rtc_data, as struct
> SampleRtcData might not be fully initialized when it runs, i.e.
>
> let rtc_data = impl_pin_init!(SampleRtcData {
> io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> hw_variant: VendorVariant::StV1,
> irq <- irq::Registration::new(..., rtc_data),
> });
>
> would not compile in the first place.
>
> irq::Registration, for this purpose, has its own private data on the handler
> itself, see also [1]. In fact, the C code has the same concept with the dev_id
> argument in request_threaded_irq() [2].
>
> The difference is that the C compiler does not ensure that the IRQ handler
> actually owns the data behind the dev_id pointer. I.e. the driver has to somehow
> ensure that whatever is behind the dev_id pointer remains valid for the duration
> the IRQ handler is registered.
>
> In the Rust implementation the compiler does ensure that what is behind the
> dev_id pointer remains valid for the duration of the lifetime of the
> irq::Registration.
>
> Having that said, I assume you wonder what we would pass into the
> irq::Registration instead, if it is not rtc_data.
>
> The answer is it depends; it depends on what's actually needed, what other
> entities interact with the IRQ (e.g. some scheduled work, etc.) and maybe even
> preference to some extend.
>
> Here is one example:
>
> let irq_data = impl_pin_init!(SampleIrqData {
> io <- pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> hw_variant: VendorVariant::StV1,
> });
>
> let rtc_data = impl_pin_init!(SampleRtcData {
> irq <- irq::Registration::new(..., irq_data),
> ...,
> });
>
> let rtc = rtc::Device::new(dev, rtc_data)?;
>
> This would compile as it ensures that irq_data (struct SampleIrqData) is fully
> initialized before irq::Registration::new() is called.
>
> At a first glance this might look like we need an additional allocation, one for
> irq_data and one for rtc_data, but that is not the case. irq_data is an
> initializer that is passed to another initializer, i.e. rtc_data is still an
> initializer.
>
> The actual (single) allocation happens in rtc::Device::new().
I think that the key observation here is that C and Rust are
substantially different with respect to how things get initialized.
In C, we first allocate memory, then initialize it, and then start
services that will refer to it. All of these steps need to be taken
explicitly and separately in the right order and the compiler simply
processes the high-level language into CPU instructions. On the way
out, all of that needs to be cleaned up directly, most of the time in
reverse order. If anything is missed or forgotten, or the ordering is
messed up, troubles ensue.
In Rust, IIUC, the compiler is essentially told about what data will
be there in the memory, how to initialize it and what services to
start and all of that happens in one go when memory gets allocated
(so, apparently, a good part of the code doesn't even produce CPU
instructions at all, as it is all about feeding the information to the
compiler). So long as the compiler has complete information, it can
figure out the right ordering automatically and it will complain if
something is not right. The difficulty here is to find a way to
provide the compiler with complete information.
> In terms of accessing it through the the rtc::Device in an RTC device callback,
> we would likely use accessor methods to make it a bit more convinient, i.e.
>
> fn read_time(
> rtc: &rtc::Device<SampleRtcData>
> parent: &platform::Device<Bound>,
> time: &mut rtc::Time,
> ) -> Result {
> let io = rtc.io().access(parent)?;
>
> match rtc.hw_variant() {
> VendorVariant::Arm | VendorVariant::StV1 => {
> let my_time = io.read(...);
>
> my_time.write_into(time);
> },
> VendorVariant::StV2 => { ... },
> }
> }
>
> As mentioned above there are a few other options to implement this, depending on
> what's required, etc.
>
> For instance, if the I/O bar is actually shared between multiple entities we
> might want to initialize it within an Arc [3] (reference count it) for shared
> ownership.
>
> For the future we will also be able to support references within initializers to
> other pinned fields, which make things a bit more convinient, so you could do
> things like this:
>
> let irq_data = impl_pin_init!(SampleIrqData {
> io <- pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> hw_variant: VendorVariant::StV1,
> });
>
> let rtc_data = impl_pin_init!(SampleRtcData {
> irq <- irq::Registration::new(..., irq_data),
> io: &irq.io,
> ...,
> });
>
> let rtc = rtc::Device::new(dev, rtc_data)?;
>
> Note the additional `io: &irq.io,` in the rtc_data initializer. This would be
> legal as we know that `irq` is pinned within `rtc_data`, hence it is valid to
> hold a reference to one of its pinned fields.
>
> I am not sure how far we are from having this supported, I assume Benno and Gary
> can say more about this.
>
> I hope this helps, and thanks for asking those questions!
>
> [1] https://rust.docs.kernel.org/kernel/irq/struct.Registration.html
> [2] https://elixir.bootlin.com/linux/v6.19.3/source/kernel/irq/manage.c#L2090
> [3] https://rust.docs.kernel.org/kernel/sync/struct.Arc.html
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Rafael J. Wysocki @ 2026-02-25 21:15 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Rafael J. Wysocki, Alexandre Belloni, Alvin Sun, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, linux-rtc,
rust-for-linux, Greg Kroah-Hartman
In-Reply-To: <DGO6MEKIIHGH.3L06QJ47CP3CU@kernel.org>
On Wed, Feb 25, 2026 at 5:26 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Wed Feb 25, 2026 at 2:33 PM CET, Rafael J. Wysocki wrote:
> > On Tue, Feb 24, 2026 at 11:23 PM Danilo Krummrich <dakr@kernel.org> wrote:
> >> Here's also some sketched up code for what I wrote above:
> >>
> >> fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
> >> let dev = pdev.as_ref();
> >>
> >> let rtc_data = impl_pin_init!(SampleRtcData {
> >> io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> >> hw_variant: VendorVariant::StV1,
> >> irq <- irq::Registration::new(...),
> >> });
> >>
> >> let rtc = rtc::Device::new(dev, rtc_data)?;
> >>
> >> rtc::Registration::register(rtc)?;
> >>
> >> Ok(Self { rtc })
> >> }
> >>
> >> Note that if any of the RTC callbacks would ever need to call irq.synchronize(),
> >> irq.disable(), etc. the compiler would enforce correct ordering, as there would
> >> not be any other possibility to put the irq::Registration other than into the
> >> rtc_data that goes into rtc::Device::new().
> >
> > IIUC, the interrupt handler can only access the rtc_data because the
> > parent's driver_data may not exist yet when it runs. Or am I missing
> > something?
>
> In the code above the IRQ handler can also not access rtc_data, as struct
> SampleRtcData might not be fully initialized when it runs, i.e.
>
> let rtc_data = impl_pin_init!(SampleRtcData {
> io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> hw_variant: VendorVariant::StV1,
> irq <- irq::Registration::new(..., rtc_data),
> });
>
> would not compile in the first place.
>
> irq::Registration, for this purpose, has its own private data on the handler
> itself, see also [1]. In fact, the C code has the same concept with the dev_id
> argument in request_threaded_irq() [2].
>
> The difference is that the C compiler does not ensure that the IRQ handler
> actually owns the data behind the dev_id pointer. I.e. the driver has to somehow
> ensure that whatever is behind the dev_id pointer remains valid for the duration
> the IRQ handler is registered.
>
> In the Rust implementation the compiler does ensure that what is behind the
> dev_id pointer remains valid for the duration of the lifetime of the
> irq::Registration.
>
> Having that said, I assume you wonder what we would pass into the
> irq::Registration instead, if it is not rtc_data.
>
> The answer is it depends; it depends on what's actually needed, what other
> entities interact with the IRQ (e.g. some scheduled work, etc.) and maybe even
> preference to some extend.
>
> Here is one example:
>
> let irq_data = impl_pin_init!(SampleIrqData {
> io <- pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> hw_variant: VendorVariant::StV1,
> });
>
> let rtc_data = impl_pin_init!(SampleRtcData {
> irq <- irq::Registration::new(..., irq_data),
> ...,
> });
>
> let rtc = rtc::Device::new(dev, rtc_data)?;
>
> This would compile as it ensures that irq_data (struct SampleIrqData) is fully
> initialized before irq::Registration::new() is called.
>
> At a first glance this might look like we need an additional allocation, one for
> irq_data and one for rtc_data, but that is not the case. irq_data is an
> initializer that is passed to another initializer, i.e. rtc_data is still an
> initializer.
>
> The actual (single) allocation happens in rtc::Device::new().
>
> In terms of accessing it through the the rtc::Device in an RTC device callback,
> we would likely use accessor methods to make it a bit more convinient, i.e.
>
> fn read_time(
> rtc: &rtc::Device<SampleRtcData>
> parent: &platform::Device<Bound>,
> time: &mut rtc::Time,
> ) -> Result {
> let io = rtc.io().access(parent)?;
>
> match rtc.hw_variant() {
> VendorVariant::Arm | VendorVariant::StV1 => {
> let my_time = io.read(...);
>
> my_time.write_into(time);
> },
> VendorVariant::StV2 => { ... },
> }
> }
>
> As mentioned above there are a few other options to implement this, depending on
> what's required, etc.
>
> For instance, if the I/O bar is actually shared between multiple entities we
> might want to initialize it within an Arc [3] (reference count it) for shared
> ownership.
>
> For the future we will also be able to support references within initializers to
> other pinned fields, which make things a bit more convinient, so you could do
> things like this:
>
> let irq_data = impl_pin_init!(SampleIrqData {
> io <- pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> hw_variant: VendorVariant::StV1,
> });
>
> let rtc_data = impl_pin_init!(SampleRtcData {
> irq <- irq::Registration::new(..., irq_data),
> io: &irq.io,
> ...,
> });
>
> let rtc = rtc::Device::new(dev, rtc_data)?;
>
> Note the additional `io: &irq.io,` in the rtc_data initializer. This would be
> legal as we know that `irq` is pinned within `rtc_data`, hence it is valid to
> hold a reference to one of its pinned fields.
>
> I am not sure how far we are from having this supported, I assume Benno and Gary
> can say more about this.
>
> I hope this helps, and thanks for asking those questions!
Well, I'm using an opportunity to learn something, thank you!
> [1] https://rust.docs.kernel.org/kernel/irq/struct.Registration.html
> [2] https://elixir.bootlin.com/linux/v6.19.3/source/kernel/irq/manage.c#L2090
> [3] https://rust.docs.kernel.org/kernel/sync/struct.Arc.html
^ permalink raw reply
* Re: [PATCH v1 6/8] x86: rtc: Drop PNP device check
From: Rafael J. Wysocki @ 2026-02-25 18:10 UTC (permalink / raw)
To: Dave Hansen
Cc: Rafael J. Wysocki, Linux ACPI, LKML, x86 Maintainers, linux-rtc,
Alexandre Belloni
In-Reply-To: <6b751b23-ded2-4343-bf29-103f4a7ab6ba@intel.com>
On Wed, Feb 25, 2026 at 7:01 PM Dave Hansen <dave.hansen@intel.com> wrote:
>
> On 2/23/26 07:31, Rafael J. Wysocki wrote:
> > Previous changes effectively prevented PNP devices from being created
> > for the CMOS RTC on x86 with ACPI.
> >
> > Although in principle a CMOS RTC PNP device may exist on an x86 system
> > without ACPI (that is, an x86 system where there is no ACPI at all, not
> > one booted with ACPI disabled), such systems were there in the field ~30
> > years ago and most likely they would not be able to run a contemporary
> > Linux kernel.
> >
> > For the above reasons, drop the PNP device check from add_rtc_cmos().
>
> If someone had one of these devices, what would they see after applying
> this? Would they just not be able to detect the RTC any longer?
No, add_rtc_cmos() would just create a fallback platform device for
the CMOS RTC AFAICS and the driver would pick up that one.
> In any case, this does seem obscure enough to not worry about any more:
>
> Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # x86
Thanks!
^ permalink raw reply
* Re: [PATCH v1 3/8] ACPI: x86: cmos_rtc: Create a CMOS RTC platform device
From: Dave Hansen @ 2026-02-25 18:01 UTC (permalink / raw)
To: Rafael J. Wysocki, Linux ACPI
Cc: LKML, x86 Maintainers, linux-rtc, Alexandre Belloni
In-Reply-To: <1962427.tdWV9SEqCh@rafael.j.wysocki>
On 2/23/26 07:29, Rafael J. Wysocki wrote:
> Make the CMOS RTC ACPI scan handler create a platform device that will
> be used subsequently by rtc-cmos for driver binding on x86 systems with
> ACPI and update add_rtc_cmos() to skip registering a fallback platform
> device for the CMOS RTC when the above one has been registered.
Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # x86
^ permalink raw reply
* Re: [PATCH v1 6/8] x86: rtc: Drop PNP device check
From: Dave Hansen @ 2026-02-25 18:01 UTC (permalink / raw)
To: Rafael J. Wysocki, Linux ACPI
Cc: LKML, x86 Maintainers, linux-rtc, Alexandre Belloni
In-Reply-To: <8660687.T7Z3S40VBb@rafael.j.wysocki>
On 2/23/26 07:31, Rafael J. Wysocki wrote:
> Previous changes effectively prevented PNP devices from being created
> for the CMOS RTC on x86 with ACPI.
>
> Although in principle a CMOS RTC PNP device may exist on an x86 system
> without ACPI (that is, an x86 system where there is no ACPI at all, not
> one booted with ACPI disabled), such systems were there in the field ~30
> years ago and most likely they would not be able to run a contemporary
> Linux kernel.
>
> For the above reasons, drop the PNP device check from add_rtc_cmos().
If someone had one of these devices, what would they see after applying
this? Would they just not be able to detect the RTC any longer?
In any case, this does seem obscure enough to not worry about any more:
Acked-by: Dave Hansen <dave.hansen@linux.intel.com> # x86
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Danilo Krummrich @ 2026-02-25 16:26 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Alexandre Belloni, Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux, Greg Kroah-Hartman
In-Reply-To: <CAJZ5v0iA88G0ZRVB347dXEu2y8mT=d+aWd42cB2tpO5pLVpKuQ@mail.gmail.com>
On Wed Feb 25, 2026 at 2:33 PM CET, Rafael J. Wysocki wrote:
> On Tue, Feb 24, 2026 at 11:23 PM Danilo Krummrich <dakr@kernel.org> wrote:
>> Here's also some sketched up code for what I wrote above:
>>
>> fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
>> let dev = pdev.as_ref();
>>
>> let rtc_data = impl_pin_init!(SampleRtcData {
>> io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
>> hw_variant: VendorVariant::StV1,
>> irq <- irq::Registration::new(...),
>> });
>>
>> let rtc = rtc::Device::new(dev, rtc_data)?;
>>
>> rtc::Registration::register(rtc)?;
>>
>> Ok(Self { rtc })
>> }
>>
>> Note that if any of the RTC callbacks would ever need to call irq.synchronize(),
>> irq.disable(), etc. the compiler would enforce correct ordering, as there would
>> not be any other possibility to put the irq::Registration other than into the
>> rtc_data that goes into rtc::Device::new().
>
> IIUC, the interrupt handler can only access the rtc_data because the
> parent's driver_data may not exist yet when it runs. Or am I missing
> something?
In the code above the IRQ handler can also not access rtc_data, as struct
SampleRtcData might not be fully initialized when it runs, i.e.
let rtc_data = impl_pin_init!(SampleRtcData {
io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
hw_variant: VendorVariant::StV1,
irq <- irq::Registration::new(..., rtc_data),
});
would not compile in the first place.
irq::Registration, for this purpose, has its own private data on the handler
itself, see also [1]. In fact, the C code has the same concept with the dev_id
argument in request_threaded_irq() [2].
The difference is that the C compiler does not ensure that the IRQ handler
actually owns the data behind the dev_id pointer. I.e. the driver has to somehow
ensure that whatever is behind the dev_id pointer remains valid for the duration
the IRQ handler is registered.
In the Rust implementation the compiler does ensure that what is behind the
dev_id pointer remains valid for the duration of the lifetime of the
irq::Registration.
Having that said, I assume you wonder what we would pass into the
irq::Registration instead, if it is not rtc_data.
The answer is it depends; it depends on what's actually needed, what other
entities interact with the IRQ (e.g. some scheduled work, etc.) and maybe even
preference to some extend.
Here is one example:
let irq_data = impl_pin_init!(SampleIrqData {
io <- pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
hw_variant: VendorVariant::StV1,
});
let rtc_data = impl_pin_init!(SampleRtcData {
irq <- irq::Registration::new(..., irq_data),
...,
});
let rtc = rtc::Device::new(dev, rtc_data)?;
This would compile as it ensures that irq_data (struct SampleIrqData) is fully
initialized before irq::Registration::new() is called.
At a first glance this might look like we need an additional allocation, one for
irq_data and one for rtc_data, but that is not the case. irq_data is an
initializer that is passed to another initializer, i.e. rtc_data is still an
initializer.
The actual (single) allocation happens in rtc::Device::new().
In terms of accessing it through the the rtc::Device in an RTC device callback,
we would likely use accessor methods to make it a bit more convinient, i.e.
fn read_time(
rtc: &rtc::Device<SampleRtcData>
parent: &platform::Device<Bound>,
time: &mut rtc::Time,
) -> Result {
let io = rtc.io().access(parent)?;
match rtc.hw_variant() {
VendorVariant::Arm | VendorVariant::StV1 => {
let my_time = io.read(...);
my_time.write_into(time);
},
VendorVariant::StV2 => { ... },
}
}
As mentioned above there are a few other options to implement this, depending on
what's required, etc.
For instance, if the I/O bar is actually shared between multiple entities we
might want to initialize it within an Arc [3] (reference count it) for shared
ownership.
For the future we will also be able to support references within initializers to
other pinned fields, which make things a bit more convinient, so you could do
things like this:
let irq_data = impl_pin_init!(SampleIrqData {
io <- pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
hw_variant: VendorVariant::StV1,
});
let rtc_data = impl_pin_init!(SampleRtcData {
irq <- irq::Registration::new(..., irq_data),
io: &irq.io,
...,
});
let rtc = rtc::Device::new(dev, rtc_data)?;
Note the additional `io: &irq.io,` in the rtc_data initializer. This would be
legal as we know that `irq` is pinned within `rtc_data`, hence it is valid to
hold a reference to one of its pinned fields.
I am not sure how far we are from having this supported, I assume Benno and Gary
can say more about this.
I hope this helps, and thanks for asking those questions!
[1] https://rust.docs.kernel.org/kernel/irq/struct.Registration.html
[2] https://elixir.bootlin.com/linux/v6.19.3/source/kernel/irq/manage.c#L2090
[3] https://rust.docs.kernel.org/kernel/sync/struct.Arc.html
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Rafael J. Wysocki @ 2026-02-25 13:33 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Alexandre Belloni, Rafael J. Wysocki, Alvin Sun, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Alice Ryhl, Trevor Gross, linux-rtc,
rust-for-linux, Greg Kroah-Hartman
In-Reply-To: <DGNJKZA00MNT.2C7NAQYG597MO@kernel.org>
On Tue, Feb 24, 2026 at 11:23 PM Danilo Krummrich <dakr@kernel.org> wrote:
>
> On Tue Feb 24, 2026 at 6:28 PM CET, Alexandre Belloni wrote:
> > On 24/02/2026 17:35:23+0100, Danilo Krummrich wrote:
> >> (I did not have any specific hardware in mind when sketching this up (e.g. an
> >> IRQ could also only be needed in bus device callbacks, e.g. for loading firmware
> >> etc.). But for RTC it obviously is common that it is relevant to the class
> >> device too.)
> >>
> >> So, I assume you mean because there could already be an ioctl before the IRQ has
> >> been successfully registered, and this ioctl may wait for an IRQ?
> >>
> >> In this case the irq::Registration should go into rtc_data instead to account
> >> for this dependency. Unfortunately, this is a semantic dependency that we can't
> >> always catch at compile time.
> >>
> >> The reason we sometimes can is because, if you would need access to the
> >> irq::Registration from ioctls (e.g. for calling synchronize(), enable(),
> >> disable() etc.) it would be caught, because you couldn't access it without it
> >> being in rtc_data in the first place, and being forced to have it in rtc_data
> >> guarantees that the ordering can't be wrong.
> >
> > No, once you register the rtc, the character device will appear in
> > userspace and may be opened, at this point, probe is not allowed to fail
> > anymore which you are allowing by trying to register the IRQ so late.
>
> This does not seem to correspond to my previous reply -- may I kindly ask you to
> read it again?
>
> Here's also some sketched up code for what I wrote above:
>
> fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
> let dev = pdev.as_ref();
>
> let rtc_data = impl_pin_init!(SampleRtcData {
> io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> hw_variant: VendorVariant::StV1,
> irq <- irq::Registration::new(...),
> });
>
> let rtc = rtc::Device::new(dev, rtc_data)?;
>
> rtc::Registration::register(rtc)?;
>
> Ok(Self { rtc })
> }
>
> Note that if any of the RTC callbacks would ever need to call irq.synchronize(),
> irq.disable(), etc. the compiler would enforce correct ordering, as there would
> not be any other possibility to put the irq::Registration other than into the
> rtc_data that goes into rtc::Device::new().
IIUC, the interrupt handler can only access the rtc_data because the
parent's driver_data may not exist yet when it runs. Or am I missing
something?
^ permalink raw reply
* Re: [PATCH 0/7] rtc: sun6i: Add support for Allwinner A733 SoC
From: Junhui Liu @ 2026-02-25 12:02 UTC (permalink / raw)
To: Jernej Škrabec, Michael Turquette, Stephen Boyd,
Chen-Yu Tsai, Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard, Junhui Liu
Cc: linux-clk, linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree
In-Reply-To: <5061953.GXAFRqVoOG@jernej-laptop>
Hi Jernej,
Thanks for your review.
On Sun Feb 22, 2026 at 6:41 PM CST, Jernej Škrabec wrote:
> Hi!
>
> Dne sreda, 21. januar 2026 ob 11:59:06 Srednjeevropski standardni čas je Junhui Liu napisal(a):
>> Add support for the Allwinner A733 RTC and its internal Clock Control
>> Unit (CCU). Reuse the rtc-sun6i rtc driver while introducing a new
>> SoC-specific RTC CCU driver to handle the hardware's evolved clock
>> structure.
>>
>> To facilitate this addition and improve driver modularity, transition
>> the binding between the RTC and its internal CCU from direct
>> cross-subsystem function calls to the auxiliary bus. Also extract shared
>> IOSC and 32kHz clock logic into a standalone ccu_rtc module for reuse
>> across newer SoC generations.
>>
>> The A733 implementation supports hardware detection of three external
>> crystal frequencies (19.2MHz, 24MHz and 26MHz), which is represented in
>> the driver via read-only mux operations. Implement logic to derive a
>> normalized 32kHz reference from these DCXO sources using fixed
>> pre-dividers. Additionally, provide several new DCXO gate clocks for
>> peripherals, including SerDes, HDMI, and UFS.
>
> This work looks nice, but I have some questions/comments:
> - you're missing RTC SPI clock, which is needed for RTC, at least according
> to vendor 5.15 DT. Could it be that this bit set by vendor U-Boot so you
> missed it during testing? Manual says that it's disabled by default.
You're right! I tried disabling the RTC SPI clock in U-Boot and found
that the output of UART became garbled during booting kernel. I will add
it in the next version.
> - Vendor DT has strange RTC CCU phandles for UFS and HDMI. In first case
> uses RTC wakeup and in second DCXO, which doesn't make any sense. Did you
> do any experimentation with these clocks? It wouldn't be the first time
> that either code or manual contained some kind of error.
Regarding UFS, I am still working on getting UFS functional on the
mainline kernel. I will investigate the actual relationship between the
RTC wakeup clock and UFS during this process.
As for HDMI, I believe it actually requires the hosc_hdmi_clk
(DCXO_HDMI_GATING in the manual) provided by the RTC module.
>
> Btw, switch last two patches. With current order during bisection you would
> get a complaint that A733 RTC CCU driver is not present.
Okay, I will do it.
>
> Best regards,
> Jernej
--
Best regards,
Junhui Liu
^ permalink raw reply
* Re: [PATCH v3 04/13] dt-bindings: power: supply: document Samsung S2M series PMIC charger device
From: Krzysztof Kozlowski @ 2026-02-25 10:44 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, linux-leds, devicetree, linux-kernel,
linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <20260225-s2mu005-pmic-v3-4-b4afee947603@disroot.org>
On Wed, Feb 25, 2026 at 12:45:06AM +0530, Kaustabh Chakraborty wrote:
> +
> + This is a part of device tree bindings for S2M and S5M family of Power
> + Management IC (PMIC).
> +
> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
> + additional information and example.
> +
> +allOf:
> + - $ref: power-supply.yaml#
> +
> +properties:
> + compatible:
> + enum:
> + - samsung,s2mu005-charger
Review from v1 still applies. I think you ignored several reviews, so I
will mark entire patchset as changes requested.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Gary Guo @ 2026-02-25 3:19 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Danilo Krummrich, Rafael J. Wysocki, Alvin Sun, Miguel Ojeda,
Boqun Feng, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Alice Ryhl, Trevor Gross, linux-rtc, rust-for-linux,
Greg Kroah-Hartman
In-Reply-To: <20260224224449f141e366@mail.local>
On 2026-02-24 22:44, Alexandre Belloni wrote:
> On 24/02/2026 23:23:29+0100, Danilo Krummrich wrote:
>> On Tue Feb 24, 2026 at 6:28 PM CET, Alexandre Belloni wrote:
>> > On 24/02/2026 17:35:23+0100, Danilo Krummrich wrote:
>> >> (I did not have any specific hardware in mind when sketching this up (e.g. an
>> >> IRQ could also only be needed in bus device callbacks, e.g. for loading firmware
>> >> etc.). But for RTC it obviously is common that it is relevant to the class
>> >> device too.)
>> >>
>> >> So, I assume you mean because there could already be an ioctl before the IRQ has
>> >> been successfully registered, and this ioctl may wait for an IRQ?
>> >>
>> >> In this case the irq::Registration should go into rtc_data instead to account
>> >> for this dependency. Unfortunately, this is a semantic dependency that we can't
>> >> always catch at compile time.
>> >>
>> >> The reason we sometimes can is because, if you would need access to the
>> >> irq::Registration from ioctls (e.g. for calling synchronize(), enable(),
>> >> disable() etc.) it would be caught, because you couldn't access it without it
>> >> being in rtc_data in the first place, and being forced to have it in rtc_data
>> >> guarantees that the ordering can't be wrong.
>> >
>> > No, once you register the rtc, the character device will appear in
>> > userspace and may be opened, at this point, probe is not allowed to fail
>> > anymore which you are allowing by trying to register the IRQ so late.
>>
>> This does not seem to correspond to my previous reply -- may I kindly ask you to
>> read it again?
>>
>> Here's also some sketched up code for what I wrote above:
>>
>> fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
>> let dev = pdev.as_ref();
>>
>> let rtc_data = impl_pin_init!(SampleRtcData {
>> io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
>> hw_variant: VendorVariant::StV1,
>> irq <- irq::Registration::new(...),
>> });
>>
>> let rtc = rtc::Device::new(dev, rtc_data)?;
>>
>> rtc::Registration::register(rtc)?;
>>
>> Ok(Self { rtc })
>> }
>>
>> Note that if any of the RTC callbacks would ever need to call irq.synchronize(),
>> irq.disable(), etc. the compiler would enforce correct ordering, as there would
>> not be any other possibility to put the irq::Registration other than into the
>> rtc_data that goes into rtc::Device::new().
>
> Right but again, the issue is not about the irq or resource allocation
> ordering, it is about probe failing after the character device creation.
>
>>
>> Besides that, you above mentioned "probe is not allowed to fail anymore" after
>> the RTC device is registered and the corresponding character device becomes
>> visible to userspace.
>>
>> While there most likely isn't any good reason for probe() to fail afterwards for
>> RTC devices, it is not the case that this isn't allowed. We generally can unwind
>> from a class device registration. In fact, this is not different to remove()
>> being called (immediately).
>
> It is actually different, this was the race back then:
>
> CPU0: CPU1:
> sys_load_module()
> do_init_module()
> do_one_initcall()
> cmos_do_probe()
> rtc_device_register()
> __register_chrdev()
> cdev->owner = struct module*
> open("/dev/rtc0")
> rtc_device_unregister()
> module_put()
> free_module()
> module_free(mod->module_core)
> /* struct module *module is now
> freed */
> chrdev_open()
> spin_lock(cdev_lock)
> cdev_get()
> try_module_get()
> module_is_live()
> /* dereferences already
> freed struct module* */
>
>
> I don't think it has been solved since then.
I think it is not realistic to require module init to always complete once a char
dev is registered. What if you're trying to register multiple char devs?
I think this requires that either `rtc_device_unregister` to wait until all
opened fds on the char dev to be closed before returning, or a reference
count to the module is kept. (Or having the file ops being swapped out so
further operation on the fd doesn't hit the module anymore).
Anyhow, this looks exactly what all the driver-core revocable discussion is about.
Best,
Gary
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Alexandre Belloni @ 2026-02-24 22:44 UTC (permalink / raw)
To: Danilo Krummrich
Cc: Rafael J. Wysocki, Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux, Greg Kroah-Hartman
In-Reply-To: <DGNJKZA00MNT.2C7NAQYG597MO@kernel.org>
On 24/02/2026 23:23:29+0100, Danilo Krummrich wrote:
> On Tue Feb 24, 2026 at 6:28 PM CET, Alexandre Belloni wrote:
> > On 24/02/2026 17:35:23+0100, Danilo Krummrich wrote:
> >> (I did not have any specific hardware in mind when sketching this up (e.g. an
> >> IRQ could also only be needed in bus device callbacks, e.g. for loading firmware
> >> etc.). But for RTC it obviously is common that it is relevant to the class
> >> device too.)
> >>
> >> So, I assume you mean because there could already be an ioctl before the IRQ has
> >> been successfully registered, and this ioctl may wait for an IRQ?
> >>
> >> In this case the irq::Registration should go into rtc_data instead to account
> >> for this dependency. Unfortunately, this is a semantic dependency that we can't
> >> always catch at compile time.
> >>
> >> The reason we sometimes can is because, if you would need access to the
> >> irq::Registration from ioctls (e.g. for calling synchronize(), enable(),
> >> disable() etc.) it would be caught, because you couldn't access it without it
> >> being in rtc_data in the first place, and being forced to have it in rtc_data
> >> guarantees that the ordering can't be wrong.
> >
> > No, once you register the rtc, the character device will appear in
> > userspace and may be opened, at this point, probe is not allowed to fail
> > anymore which you are allowing by trying to register the IRQ so late.
>
> This does not seem to correspond to my previous reply -- may I kindly ask you to
> read it again?
>
> Here's also some sketched up code for what I wrote above:
>
> fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
> let dev = pdev.as_ref();
>
> let rtc_data = impl_pin_init!(SampleRtcData {
> io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
> hw_variant: VendorVariant::StV1,
> irq <- irq::Registration::new(...),
> });
>
> let rtc = rtc::Device::new(dev, rtc_data)?;
>
> rtc::Registration::register(rtc)?;
>
> Ok(Self { rtc })
> }
>
> Note that if any of the RTC callbacks would ever need to call irq.synchronize(),
> irq.disable(), etc. the compiler would enforce correct ordering, as there would
> not be any other possibility to put the irq::Registration other than into the
> rtc_data that goes into rtc::Device::new().
Right but again, the issue is not about the irq or resource allocation
ordering, it is about probe failing after the character device creation.
>
> Besides that, you above mentioned "probe is not allowed to fail anymore" after
> the RTC device is registered and the corresponding character device becomes
> visible to userspace.
>
> While there most likely isn't any good reason for probe() to fail afterwards for
> RTC devices, it is not the case that this isn't allowed. We generally can unwind
> from a class device registration. In fact, this is not different to remove()
> being called (immediately).
It is actually different, this was the race back then:
CPU0: CPU1:
sys_load_module()
do_init_module()
do_one_initcall()
cmos_do_probe()
rtc_device_register()
__register_chrdev()
cdev->owner = struct module*
open("/dev/rtc0")
rtc_device_unregister()
module_put()
free_module()
module_free(mod->module_core)
/* struct module *module is now
freed */
chrdev_open()
spin_lock(cdev_lock)
cdev_get()
try_module_get()
module_is_live()
/* dereferences already
freed struct module* */
I don't think it has been solved since then.
>
> Imagine a case where a driver registers multiple class devices, or a class
> device and an auxiliary device, etc.
>
> (But I assume your point was more that for an RTC device specifically this would
> be odd or uncommon.)
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Danilo Krummrich @ 2026-02-24 22:23 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Rafael J. Wysocki, Alvin Sun, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux, Greg Kroah-Hartman
In-Reply-To: <20260224172822de7f4569@mail.local>
On Tue Feb 24, 2026 at 6:28 PM CET, Alexandre Belloni wrote:
> On 24/02/2026 17:35:23+0100, Danilo Krummrich wrote:
>> (I did not have any specific hardware in mind when sketching this up (e.g. an
>> IRQ could also only be needed in bus device callbacks, e.g. for loading firmware
>> etc.). But for RTC it obviously is common that it is relevant to the class
>> device too.)
>>
>> So, I assume you mean because there could already be an ioctl before the IRQ has
>> been successfully registered, and this ioctl may wait for an IRQ?
>>
>> In this case the irq::Registration should go into rtc_data instead to account
>> for this dependency. Unfortunately, this is a semantic dependency that we can't
>> always catch at compile time.
>>
>> The reason we sometimes can is because, if you would need access to the
>> irq::Registration from ioctls (e.g. for calling synchronize(), enable(),
>> disable() etc.) it would be caught, because you couldn't access it without it
>> being in rtc_data in the first place, and being forced to have it in rtc_data
>> guarantees that the ordering can't be wrong.
>
> No, once you register the rtc, the character device will appear in
> userspace and may be opened, at this point, probe is not allowed to fail
> anymore which you are allowing by trying to register the IRQ so late.
This does not seem to correspond to my previous reply -- may I kindly ask you to
read it again?
Here's also some sketched up code for what I wrote above:
fn probe(pdev: &pci::Device<Core>, info: &Self::IdInfo) -> impl PinInit<Self, Error> {
let dev = pdev.as_ref();
let rtc_data = impl_pin_init!(SampleRtcData {
io: pdev.iomap_region_sized::<BAR0_SIZE>(0, c"my_rtc/bar0")?,
hw_variant: VendorVariant::StV1,
irq <- irq::Registration::new(...),
});
let rtc = rtc::Device::new(dev, rtc_data)?;
rtc::Registration::register(rtc)?;
Ok(Self { rtc })
}
Note that if any of the RTC callbacks would ever need to call irq.synchronize(),
irq.disable(), etc. the compiler would enforce correct ordering, as there would
not be any other possibility to put the irq::Registration other than into the
rtc_data that goes into rtc::Device::new().
Besides that, you above mentioned "probe is not allowed to fail anymore" after
the RTC device is registered and the corresponding character device becomes
visible to userspace.
While there most likely isn't any good reason for probe() to fail afterwards for
RTC devices, it is not the case that this isn't allowed. We generally can unwind
from a class device registration. In fact, this is not different to remove()
being called (immediately).
Imagine a case where a driver registers multiple class devices, or a class
device and an auxiliary device, etc.
(But I assume your point was more that for an RTC device specifically this would
be odd or uncommon.)
^ permalink raw reply
* [PATCH v3 13/13] power: supply: add support for Samsung S2M series PMIC charger device
From: Kaustabh Chakraborty @ 2026-02-24 19:15 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Kaustabh Chakraborty
In-Reply-To: <20260225-s2mu005-pmic-v3-0-b4afee947603@disroot.org>
Add a driver for charger controllers found in certain Samsung S2M series
PMICs. The driver has very basic support for the device, with only
charger online reporting working.
The driver includes initial support for the S2MU005 PMIC charger.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/power/supply/Kconfig | 11 ++
drivers/power/supply/Makefile | 1 +
drivers/power/supply/s2m-charger.c | 213 +++++++++++++++++++++++++++++++++++++
3 files changed, 225 insertions(+)
diff --git a/drivers/power/supply/Kconfig b/drivers/power/supply/Kconfig
index 92f9f7aae92f2..8276964793c1b 100644
--- a/drivers/power/supply/Kconfig
+++ b/drivers/power/supply/Kconfig
@@ -834,6 +834,17 @@ config CHARGER_RK817
help
Say Y to include support for Rockchip RK817 Battery Charger.
+config CHARGER_S2M
+ tristate "Samsung S2M series PMIC battery charger support"
+ depends on EXTCON_S2M
+ depends on MFD_SEC_CORE
+ select REGMAP_IRQ
+ help
+ This option enables support for charger devices found in
+ certain Samsung S2M series PMICs, such as the S2MU005. These
+ devices provide USB power supply information and also required
+ for USB OTG role switching.
+
config CHARGER_SMB347
tristate "Summit Microelectronics SMB3XX Battery Charger"
depends on I2C
diff --git a/drivers/power/supply/Makefile b/drivers/power/supply/Makefile
index 4b79d5abc49a7..6e787cdc10ce9 100644
--- a/drivers/power/supply/Makefile
+++ b/drivers/power/supply/Makefile
@@ -106,6 +106,7 @@ obj-$(CONFIG_CHARGER_BQ25890) += bq25890_charger.o
obj-$(CONFIG_CHARGER_BQ25980) += bq25980_charger.o
obj-$(CONFIG_CHARGER_BQ256XX) += bq256xx_charger.o
obj-$(CONFIG_CHARGER_RK817) += rk817_charger.o
+obj-$(CONFIG_CHARGER_S2M) += s2m-charger.o
obj-$(CONFIG_CHARGER_SMB347) += smb347-charger.o
obj-$(CONFIG_CHARGER_TPS65090) += tps65090-charger.o
obj-$(CONFIG_CHARGER_TPS65217) += tps65217_charger.o
diff --git a/drivers/power/supply/s2m-charger.c b/drivers/power/supply/s2m-charger.c
new file mode 100644
index 0000000000000..e6417018daa24
--- /dev/null
+++ b/drivers/power/supply/s2m-charger.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Battery Charger Driver for Samsung S2M series PMICs.
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd
+ * Copyright (c) 2025 Kaustabh Chakraborty <kauschluss@disroot.org>
+ */
+
+#include <linux/devm-helpers.h>
+#include <linux/extcon.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/power_supply.h>
+#include <linux/regmap.h>
+
+struct s2m_chgr {
+ struct device *dev;
+ struct regmap *regmap;
+ struct power_supply *psy;
+ struct extcon_dev *extcon;
+ struct work_struct extcon_work;
+ struct notifier_block extcon_nb;
+};
+
+static int s2mu005_chgr_get_online(struct s2m_chgr *priv, int *value)
+{
+ u32 val;
+ int ret = 0;
+
+ ret = regmap_read(priv->regmap, S2MU005_REG_CHGR_STATUS0, &val);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to read register (%d)\n", ret);
+ return ret;
+ }
+
+ *value = !!(val & S2MU005_CHGR_CHG);
+
+ return ret;
+}
+
+static int s2mu005_chgr_get_property(struct power_supply *psy,
+ enum power_supply_property psp,
+ union power_supply_propval *val)
+{
+ struct s2m_chgr *priv = power_supply_get_drvdata(psy);
+ int ret = 0;
+
+ switch (psp) {
+ case POWER_SUPPLY_PROP_ONLINE:
+ ret = s2mu005_chgr_get_online(priv, &val->intval);
+ break;
+ default:
+ return -EINVAL;
+ }
+
+ return ret;
+}
+
+static void s2mu005_chgr_extcon_work(struct work_struct *work)
+{
+ struct s2m_chgr *priv = container_of(work, struct s2m_chgr,
+ extcon_work);
+ int ret;
+
+ if (extcon_get_state(priv->extcon, EXTCON_USB_HOST) == true) {
+ ret = regmap_update_bits(priv->regmap, S2MU005_REG_CHGR_CTRL0,
+ S2MU005_CHGR_OP_MODE,
+ FIELD_PREP(S2MU005_CHGR_OP_MODE,
+ S2MU005_CHGR_OP_MODE_OTG));
+ if (ret < 0)
+ dev_err(priv->dev, "failed to set operation mode to OTG (%d)\n",
+ ret);
+
+ goto psy_update;
+ }
+
+ if (extcon_get_state(priv->extcon, EXTCON_USB) == true) {
+ ret = regmap_update_bits(priv->regmap, S2MU005_REG_CHGR_CTRL0,
+ S2MU005_CHGR_OP_MODE,
+ FIELD_PREP(S2MU005_CHGR_OP_MODE,
+ S2MU005_CHGR_OP_MODE_CHG));
+ if (ret < 0)
+ dev_err(priv->dev, "failed to set operation mode to charging (%d)\n",
+ ret);
+
+ goto psy_update;
+ }
+
+ ret = regmap_clear_bits(priv->regmap, S2MU005_REG_CHGR_CTRL0,
+ S2MU005_CHGR_OP_MODE);
+ if (ret < 0)
+ dev_err(priv->dev, "failed to clear operation mode (%d)\n", ret);
+
+psy_update:
+ power_supply_changed(priv->psy);
+}
+
+static const enum power_supply_property s2mu005_chgr_properties[] = {
+ POWER_SUPPLY_PROP_ONLINE,
+};
+
+static const struct power_supply_desc s2mu005_chgr_psy_desc = {
+ .name = "s2mu005-charger",
+ .type = POWER_SUPPLY_TYPE_USB,
+ .properties = s2mu005_chgr_properties,
+ .num_properties = ARRAY_SIZE(s2mu005_chgr_properties),
+ .get_property = s2mu005_chgr_get_property,
+};
+
+static int s2m_chgr_extcon_notifier(struct notifier_block *nb,
+ unsigned long event, void *param)
+{
+ struct s2m_chgr *priv = container_of(nb, struct s2m_chgr, extcon_nb);
+
+ schedule_work(&priv->extcon_work);
+
+ return NOTIFY_OK;
+}
+
+static int s2m_chgr_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct sec_pmic_dev *pmic_drvdata = dev_get_drvdata(dev->parent);
+ struct s2m_chgr *priv;
+ struct device_node *extcon_node;
+ struct power_supply_config psy_cfg = {};
+ const struct power_supply_desc *psy_desc;
+ work_func_t extcon_work_func;
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+ priv->dev = dev;
+ priv->regmap = pmic_drvdata->regmap_pmic;
+
+ switch (platform_get_device_id(pdev)->driver_data) {
+ case S2MU005:
+ psy_desc = &s2mu005_chgr_psy_desc;
+ extcon_work_func = s2mu005_chgr_extcon_work;
+ break;
+ default:
+ return dev_err_probe(dev, -ENODEV,
+ "device type %d is not supported by driver\n",
+ pmic_drvdata->device_type);
+ }
+
+ psy_cfg.drv_data = priv;
+ priv->psy = devm_power_supply_register(dev, psy_desc, &psy_cfg);
+ if (IS_ERR(priv->psy))
+ return dev_err_probe(dev, PTR_ERR(priv->psy),
+ "failed to register power supply subsystem\n");
+
+ /* MUIC is mandatory. If unavailable, request probe deferral */
+ extcon_node = of_get_child_by_name(dev->parent->of_node, "extcon");
+ priv->extcon = extcon_find_edev_by_node(extcon_node);
+ if (IS_ERR(priv->extcon))
+ return -EPROBE_DEFER;
+
+ ret = devm_work_autocancel(dev, &priv->extcon_work, extcon_work_func);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to initialize extcon work\n");
+
+ priv->extcon_nb.notifier_call = s2m_chgr_extcon_notifier;
+ ret = devm_extcon_register_notifier_all(dev, priv->extcon, &priv->extcon_nb);
+ if (ret)
+ dev_err_probe(dev, ret, "failed to register extcon notifier\n");
+
+ return 0;
+}
+
+static const struct platform_device_id s2m_chgr_id_table[] = {
+ { "s2mu005-charger", S2MU005 },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, s2m_chgr_id_table);
+
+/*
+ * Device is instantiated through parent MFD device and device matching
+ * is done through platform_device_id.
+ *
+ * However if device's DT node contains proper compatible and driver is
+ * built as a module, then the *module* matching will be done through DT
+ * aliases. This requires of_device_id table. In the same time this will
+ * not change the actual *device* matching so do not add .of_match_table.
+ */
+static const struct of_device_id s2m_chgr_of_match_table[] = {
+ {
+ .compatible = "samsung,s2mu005-charger",
+ .data = (void *)S2MU005,
+ }, {
+ /* sentinel */
+ },
+};
+MODULE_DEVICE_TABLE(of, s2m_chgr_of_match_table);
+
+static struct platform_driver s2m_chgr_driver = {
+ .driver = {
+ .name = "s2m-charger",
+ },
+ .probe = s2m_chgr_probe,
+ .id_table = s2m_chgr_id_table,
+};
+module_platform_driver(s2m_chgr_driver);
+
+MODULE_DESCRIPTION("Battery Charger Driver For Samsung S2M Series PMICs");
+MODULE_AUTHOR("Kaustabh Chakraborty <kauschluss@disroot.org>");
+MODULE_LICENSE("GPL");
--
2.52.0
^ permalink raw reply related
* [PATCH v3 12/13] extcon: add support for Samsung S2M series PMIC extcon devices
From: Kaustabh Chakraborty @ 2026-02-24 19:15 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Kaustabh Chakraborty
In-Reply-To: <20260225-s2mu005-pmic-v3-0-b4afee947603@disroot.org>
Add a driver for MUIC devices found in certain Samsung S2M series PMICs
These are USB port accessory detectors. These devices report multiple
cable states depending on the ID-GND resistance measured by an internal
ADC.
The driver includes initial support for the S2MU005 PMIC extcon.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/extcon/Kconfig | 10 ++
drivers/extcon/Makefile | 1 +
drivers/extcon/extcon-s2m.c | 354 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 365 insertions(+)
diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
index 68d9df7d2dae0..19c712e591955 100644
--- a/drivers/extcon/Kconfig
+++ b/drivers/extcon/Kconfig
@@ -183,6 +183,16 @@ config EXTCON_RT8973A
and switch that is optimized to protect low voltage system
from abnormal high input voltage (up to 28V).
+config EXTCON_S2M
+ tristate "Samsung S2M series PMIC EXTCON support"
+ depends on MFD_SEC_CORE
+ select REGMAP_IRQ
+ help
+ This option enables support for MUIC devices found in certain
+ Samsung S2M series PMICs, such as the S2MU005. These devices
+ have internal ADCs measuring the ID-GND resistance, thereby
+ can be used as a USB port accessory detector.
+
config EXTCON_SM5502
tristate "Silicon Mitus SM5502/SM5504/SM5703 EXTCON support"
depends on I2C
diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
index 6482f2bfd6611..e3939786f3474 100644
--- a/drivers/extcon/Makefile
+++ b/drivers/extcon/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_EXTCON_PALMAS) += extcon-palmas.o
obj-$(CONFIG_EXTCON_PTN5150) += extcon-ptn5150.o
obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += extcon-qcom-spmi-misc.o
obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
+obj-$(CONFIG_EXTCON_S2M) += extcon-s2m.o
obj-$(CONFIG_EXTCON_SM5502) += extcon-sm5502.o
obj-$(CONFIG_EXTCON_USB_GPIO) += extcon-usb-gpio.o
obj-$(CONFIG_EXTCON_USBC_CROS_EC) += extcon-usbc-cros-ec.o
diff --git a/drivers/extcon/extcon-s2m.c b/drivers/extcon/extcon-s2m.c
new file mode 100644
index 0000000000000..f57573f279755
--- /dev/null
+++ b/drivers/extcon/extcon-s2m.c
@@ -0,0 +1,354 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Extcon Driver for Samsung S2M series PMICs.
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd
+ * Copyright (C) 2025 Kaustabh Chakraborty <kauschluss@disroot.org>
+ */
+
+#include <linux/delay.h>
+#include <linux/extcon-provider.h>
+#include <linux/interrupt.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>
+
+struct s2m_muic {
+ struct device *dev;
+ struct regmap *regmap;
+ struct extcon_dev *extcon;
+ struct s2m_muic_irq_data *irq_data;
+ const unsigned int *extcon_cable;
+ bool attached;
+};
+
+struct s2m_muic_irq_data {
+ const char *name;
+ int (*const handler)(struct s2m_muic *);
+ int irq;
+};
+
+static int s2mu005_muic_detach(struct s2m_muic *priv)
+{
+ int ret;
+ int i;
+
+ ret = regmap_set_bits(priv->regmap, S2MU005_REG_MUIC_CTRL1,
+ S2MU005_MUIC_MAN_SW);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to disable manual switching\n");
+ return ret;
+ }
+
+ ret = regmap_set_bits(priv->regmap, S2MU005_REG_MUIC_CTRL3,
+ S2MU005_MUIC_ONESHOT_ADC);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to enable ADC oneshot mode\n");
+ return ret;
+ }
+
+ ret = regmap_clear_bits(priv->regmap, S2MU005_REG_MUIC_SWCTRL, ~0);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to clear switch control register\n");
+ return ret;
+ }
+
+ /* Find all set states and clear them */
+ for (i = 0; priv->extcon_cable[i]; i++) {
+ unsigned int state = priv->extcon_cable[i];
+
+ if (extcon_get_state(priv->extcon, state) == true)
+ extcon_set_state_sync(priv->extcon, state, false);
+ }
+
+ priv->attached = false;
+
+ return 0;
+}
+
+static int s2mu005_muic_attach(struct s2m_muic *priv)
+{
+ unsigned int type;
+ int ret;
+
+ /* If any device is already attached, detach it */
+ if (priv->attached) {
+ s2mu005_muic_detach(priv);
+ msleep(100);
+ }
+
+ ret = regmap_read(priv->regmap, S2MU005_REG_MUIC_DEV1, &type);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to read DEV1 register\n");
+ return ret;
+ }
+
+ /*
+ * All USB connections which require communication via its D+
+ * and D- wires need it.
+ */
+ if (type & (S2MU005_MUIC_OTG | S2MU005_MUIC_DCP | S2MU005_MUIC_SDP)) {
+ ret = regmap_update_bits(priv->regmap, S2MU005_REG_MUIC_SWCTRL,
+ S2MU005_MUIC_DM_DP,
+ FIELD_PREP(S2MU005_MUIC_DM_DP,
+ S2MU005_MUIC_DM_DP_USB));
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to configure DM/DP pins\n");
+ return ret;
+ }
+ }
+
+ /*
+ * For OTG connections, enable manual switching and ADC oneshot
+ * mode. Since the port will now be supplying power, the
+ * internal ADC (measuring the ID-GND resistance) is made to
+ * poll periodically for any changes, so as to prevent any
+ * damages due to power.
+ */
+ if (type & S2MU005_MUIC_OTG) {
+ ret = regmap_clear_bits(priv->regmap, S2MU005_REG_MUIC_CTRL1,
+ S2MU005_MUIC_MAN_SW);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to enable manual switching\n");
+ return ret;
+ }
+
+ ret = regmap_clear_bits(priv->regmap, S2MU005_REG_MUIC_CTRL3,
+ S2MU005_MUIC_ONESHOT_ADC);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to disable ADC oneshot mode\n");
+ return ret;
+ }
+ }
+
+ switch (type) {
+ case S2MU005_MUIC_OTG:
+ dev_dbg(priv->dev, "USB OTG connection detected\n");
+ extcon_set_state_sync(priv->extcon, EXTCON_USB_HOST, true);
+ priv->attached = true;
+ break;
+ case S2MU005_MUIC_CDP:
+ dev_dbg(priv->dev, "USB CDP connection detected\n");
+ extcon_set_state_sync(priv->extcon, EXTCON_USB, true);
+ extcon_set_state_sync(priv->extcon, EXTCON_CHG_USB_CDP, true);
+ priv->attached = true;
+ break;
+ case S2MU005_MUIC_SDP:
+ dev_dbg(priv->dev, "USB SDP connection detected\n");
+ extcon_set_state_sync(priv->extcon, EXTCON_USB, true);
+ extcon_set_state_sync(priv->extcon, EXTCON_CHG_USB_SDP, true);
+ priv->attached = true;
+ break;
+ case S2MU005_MUIC_DCP:
+ dev_dbg(priv->dev, "USB DCP connection detected\n");
+ extcon_set_state_sync(priv->extcon, EXTCON_USB, true);
+ extcon_set_state_sync(priv->extcon, EXTCON_CHG_USB_DCP, true);
+ priv->attached = true;
+ break;
+ case S2MU005_MUIC_UART:
+ dev_dbg(priv->dev, "UART connection detected\n");
+ extcon_set_state_sync(priv->extcon, EXTCON_JIG, true);
+ priv->attached = true;
+ break;
+ }
+
+ if (!priv->attached)
+ dev_warn(priv->dev, "failed to recognize the device attached\n");
+
+ return ret;
+}
+
+static int s2mu005_muic_init(struct s2m_muic *priv)
+{
+ int ret = 0;
+
+ ret = regmap_update_bits(priv->regmap, S2MU005_REG_MUIC_LDOADC_L,
+ S2MU005_MUIC_VSET,
+ FIELD_PREP(S2MU005_MUIC_VSET,
+ S2MU005_MUIC_VSET_3P0V));
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to set internal ADC voltage regulator\n");
+ return ret;
+ }
+
+ ret = regmap_update_bits(priv->regmap, S2MU005_REG_MUIC_LDOADC_H,
+ S2MU005_MUIC_VSET,
+ FIELD_PREP(S2MU005_MUIC_VSET,
+ S2MU005_MUIC_VSET_3P0V));
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to set internal ADC voltage regulator\n");
+ return ret;
+ }
+
+ ret = regmap_clear_bits(priv->regmap, S2MU005_REG_MUIC_CTRL1,
+ S2MU005_MUIC_IRQ);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to enable MUIC interrupts\n");
+ return ret;
+ }
+
+ return s2mu005_muic_attach(priv);
+}
+
+static const unsigned int s2mu005_muic_extcon_cable[] = {
+ EXTCON_USB,
+ EXTCON_USB_HOST,
+ EXTCON_CHG_USB_SDP,
+ EXTCON_CHG_USB_DCP,
+ EXTCON_CHG_USB_CDP,
+ EXTCON_JIG,
+ EXTCON_NONE,
+};
+
+static struct s2m_muic_irq_data s2mu005_muic_irq_data[] = {
+ {
+ .name = "attach",
+ .handler = s2mu005_muic_attach
+ }, {
+ .name = "detach",
+ .handler = s2mu005_muic_detach
+ }, {
+ /* sentinel */
+ }
+};
+
+static irqreturn_t s2m_muic_irq_func(int virq, void *data)
+{
+ struct s2m_muic *priv = data;
+ const struct s2m_muic_irq_data *irq_data = priv->irq_data;
+ int ret;
+ int i;
+
+ for (i = 0; irq_data[i].handler; i++) {
+ if (virq != irq_data[i].irq)
+ continue;
+
+ ret = irq_data[i].handler(priv);
+ if (ret < 0)
+ dev_err(priv->dev, "failed to handle interrupt for %s (%d)\n",
+ irq_data[i].name, ret);
+ break;
+ }
+
+ return IRQ_HANDLED;
+}
+
+static int s2m_muic_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct sec_pmic_dev *pmic_drvdata = dev_get_drvdata(dev->parent);
+ struct s2m_muic *priv;
+ int ret;
+ int i;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+ priv->dev = dev;
+ priv->regmap = pmic_drvdata->regmap_pmic;
+
+ switch (platform_get_device_id(pdev)->driver_data) {
+ case S2MU005:
+ priv->extcon_cable = s2mu005_muic_extcon_cable;
+ priv->irq_data = s2mu005_muic_irq_data;
+ /* Initialize MUIC */
+ ret = s2mu005_muic_init(priv);
+ break;
+ default:
+ return dev_err_probe(dev, -ENODEV,
+ "device type %d is not supported by driver\n",
+ pmic_drvdata->device_type);
+ }
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to initialize MUIC\n");
+
+ priv->extcon = devm_extcon_dev_allocate(&pdev->dev, priv->extcon_cable);
+ if (IS_ERR(priv->extcon))
+ return dev_err_probe(dev, PTR_ERR(priv->extcon),
+ "failed to allocate memory for extcon\n");
+
+ ret = devm_extcon_dev_register(dev, priv->extcon);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to register extcon device\n");
+
+ for (i = 0; priv->irq_data[i].handler; i++) {
+ int irq = platform_get_irq_byname_optional(pdev,
+ priv->irq_data[i].name);
+ if (irq == -ENXIO)
+ continue;
+ if (irq <= 0)
+ return dev_err_probe(dev, -EINVAL, "failed to get IRQ %s\n",
+ priv->irq_data[i].name);
+
+ priv->irq_data[i].irq = irq;
+ ret = devm_request_threaded_irq(dev, irq, NULL,
+ s2m_muic_irq_func, IRQF_ONESHOT,
+ priv->irq_data[i].name, priv);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to request IRQ\n");
+ }
+
+ return 0;
+}
+
+static void s2m_muic_remove(struct platform_device *pdev)
+{
+ struct s2m_muic *priv = dev_get_drvdata(&pdev->dev);
+
+ /*
+ * Disabling the MUIC device is important as it disables manual
+ * switching mode, thereby enabling auto switching mode.
+ *
+ * This is to ensure that when the board is powered off, it
+ * goes into LPM charging mode when a USB charger is connected.
+ */
+ switch (platform_get_device_id(pdev)->driver_data) {
+ case S2MU005:
+ s2mu005_muic_detach(priv);
+ break;
+ }
+}
+
+static const struct platform_device_id s2m_muic_id_table[] = {
+ { "s2mu005-muic", S2MU005 },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, s2m_muic_id_table);
+
+/*
+ * Device is instantiated through parent MFD device and device matching
+ * is done through platform_device_id.
+ *
+ * However if device's DT node contains proper compatible and driver is
+ * built as a module, then the *module* matching will be done through DT
+ * aliases. This requires of_device_id table. In the same time this will
+ * not change the actual *device* matching so do not add .of_match_table.
+ */
+static const struct of_device_id s2m_muic_of_match_table[] = {
+ {
+ .compatible = "samsung,s2mu005-muic",
+ .data = (void *)S2MU005,
+ }, {
+ /* sentinel */
+ },
+};
+MODULE_DEVICE_TABLE(of, s2m_muic_of_match_table);
+
+static struct platform_driver s2m_muic_driver = {
+ .driver = {
+ .name = "s2m-muic",
+ },
+ .probe = s2m_muic_probe,
+ .remove = s2m_muic_remove,
+ .id_table = s2m_muic_id_table,
+};
+module_platform_driver(s2m_muic_driver);
+
+MODULE_DESCRIPTION("Extcon Driver For Samsung S2M Series PMICs");
+MODULE_AUTHOR("Kaustabh Chakraborty <kauschluss@disroot.org>");
+MODULE_LICENSE("GPL");
--
2.52.0
^ permalink raw reply related
* [PATCH v3 11/13] Documentation: leds: document pattern behavior of Samsung S2M series PMIC RGB LEDs
From: Kaustabh Chakraborty @ 2026-02-24 19:15 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Kaustabh Chakraborty
In-Reply-To: <20260225-s2mu005-pmic-v3-0-b4afee947603@disroot.org>
Add documentation to describe how hardware patterns (as defined by the
documentation of led-class-multicolor) are parsed and implemented by the
Samsung S2M series PMIC RGB LED driver.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
Documentation/leds/index.rst | 1 +
Documentation/leds/leds-s2m-rgb.rst | 60 +++++++++++++++++++++++++++++++++++++
2 files changed, 61 insertions(+)
diff --git a/Documentation/leds/index.rst b/Documentation/leds/index.rst
index bebf440042787..23fa9ff7aaf4b 100644
--- a/Documentation/leds/index.rst
+++ b/Documentation/leds/index.rst
@@ -28,6 +28,7 @@ LEDs
leds-lp5812
leds-mlxcpld
leds-mt6370-rgb
+ leds-s2m-rgb
leds-sc27xx
leds-st1202
leds-qcom-lpg
diff --git a/Documentation/leds/leds-s2m-rgb.rst b/Documentation/leds/leds-s2m-rgb.rst
new file mode 100644
index 0000000000000..4f89a8c89ea86
--- /dev/null
+++ b/Documentation/leds/leds-s2m-rgb.rst
@@ -0,0 +1,60 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================================
+Samsung S2M Series PMIC RGB LED Driver
+======================================
+
+Description
+-----------
+
+The RGB LED on the S2M series PMIC hardware features a three-channel LED that
+is grouped together as a single device. Furthermore, it supports 8-bit
+brightness control for each channel. This LED is typically used as a status
+indicator in mobile devices. It also supports various parameters for hardware
+patterns.
+
+The hardware pattern can be programmed using the "pattern" trigger, using the
+hw_pattern attribute.
+
+/sys/class/leds/<led>/repeat
+----------------------------
+
+The hardware supports only indefinitely repeating patterns. The repeat
+attribute must be set to -1 for hardware patterns to function.
+
+/sys/class/leds/<led>/hw_pattern
+--------------------------------
+
+Specify a hardware pattern for the RGB LEDs.
+
+The pattern is a series of brightness levels and durations in milliseconds.
+There should be only one non-zero brightness level. Unlike the results
+described in leds-trigger-pattern, the transitions between on and off states
+are smoothed out by the hardware.
+
+Simple pattern::
+
+ "255 3000 0 1000"
+
+ 255 -+ ''''''-. .-'''''''-.
+ | '. .' '.
+ | \ / \
+ | '. .' '.
+ | '-.......-' '-
+ 0 -+-------+-------+-------+-------+-------+-------+--> time (s)
+ 0 1 2 3 4 5 6
+
+As described in leds-trigger-pattern, it is also possible to use zero-length
+entries to disable the ramping mechanism.
+
+On-Off pattern::
+
+ "255 1000 255 0 0 1000 0 0"
+
+ 255 -+ ------+ +-------+ +-------+
+ | | | | | |
+ | | | | | |
+ | | | | | |
+ | +-------+ +-------+ +-------
+ 0 -+-------+-------+-------+-------+-------+-------+--> time (s)
+ 0 1 2 3 4 5 6
--
2.52.0
^ permalink raw reply related
* [PATCH v3 10/13] leds: rgb: add support for Samsung S2M series PMIC RGB LED device
From: Kaustabh Chakraborty @ 2026-02-24 19:15 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Kaustabh Chakraborty
In-Reply-To: <20260225-s2mu005-pmic-v3-0-b4afee947603@disroot.org>
Add support for the RGB LEDs found in certain Samsung S2M series PMICs.
The device has three LED channels, controlled as a single device. These
LEDs are typically used as status indicators in mobile phones.
The driver includes initial support for the S2MU005 PMIC RGB LEDs.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/leds/rgb/Kconfig | 11 +
drivers/leds/rgb/Makefile | 1 +
drivers/leds/rgb/leds-s2m-rgb.c | 458 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 470 insertions(+)
diff --git a/drivers/leds/rgb/Kconfig b/drivers/leds/rgb/Kconfig
index 28ef4c487367c..30051342f4e4d 100644
--- a/drivers/leds/rgb/Kconfig
+++ b/drivers/leds/rgb/Kconfig
@@ -75,6 +75,17 @@ config LEDS_QCOM_LPG
If compiled as a module, the module will be named leds-qcom-lpg.
+config LEDS_S2M_RGB
+ tristate "Samsung S2M series PMICs RGB LED support"
+ depends on LEDS_CLASS
+ depends on MFD_SEC_CORE
+ select REGMAP_IRQ
+ help
+ This option enables support for the S2MU005 RGB LEDs. These
+ devices have three LED channels, with 8-bit brightness control
+ for each channel. It's usually found in mobile phones as
+ status indicators.
+
config LEDS_MT6370_RGB
tristate "LED Support for MediaTek MT6370 PMIC"
depends on MFD_MT6370
diff --git a/drivers/leds/rgb/Makefile b/drivers/leds/rgb/Makefile
index be45991f63f50..98050e1aa4255 100644
--- a/drivers/leds/rgb/Makefile
+++ b/drivers/leds/rgb/Makefile
@@ -6,4 +6,5 @@ obj-$(CONFIG_LEDS_LP5812) += leds-lp5812.o
obj-$(CONFIG_LEDS_NCP5623) += leds-ncp5623.o
obj-$(CONFIG_LEDS_PWM_MULTICOLOR) += leds-pwm-multicolor.o
obj-$(CONFIG_LEDS_QCOM_LPG) += leds-qcom-lpg.o
+obj-$(CONFIG_LEDS_S2M_RGB) += leds-s2m-rgb.o
obj-$(CONFIG_LEDS_MT6370_RGB) += leds-mt6370-rgb.o
diff --git a/drivers/leds/rgb/leds-s2m-rgb.c b/drivers/leds/rgb/leds-s2m-rgb.c
new file mode 100644
index 0000000000000..2408edce5027a
--- /dev/null
+++ b/drivers/leds/rgb/leds-s2m-rgb.c
@@ -0,0 +1,458 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * RGB 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-multicolor.h>
+#include <linux/mfd/samsung/core.h>
+#include <linux/mfd/samsung/s2mu005.h>
+#include <linux/minmax.h>
+#include <linux/module.h>
+#include <linux/mutex.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+
+struct s2m_rgb {
+ struct device *dev;
+ struct regmap *regmap;
+ struct led_classdev_mc cdev;
+ struct mutex lock;
+ const struct s2m_rgb_spec *spec;
+ u8 ramp_up;
+ u8 ramp_dn;
+ u8 stay_hi;
+ u8 stay_lo;
+};
+
+struct s2m_rgb_spec {
+ int (*params_apply)(struct s2m_rgb *priv);
+ int (*params_reset)(struct s2m_rgb *priv);
+ const u32 *lut_ramp_up;
+ const size_t lut_ramp_up_len;
+ const u32 *lut_ramp_dn;
+ const size_t lut_ramp_dn_len;
+ const u32 *lut_stay_hi;
+ const size_t lut_stay_hi_len;
+ const u32 *lut_stay_lo;
+ const size_t lut_stay_lo_len;
+ const unsigned int max_brightness;
+};
+
+static struct led_classdev_mc *to_cdev_mc(struct led_classdev *cdev)
+{
+ return container_of(cdev, struct led_classdev_mc, led_cdev);
+}
+
+static struct s2m_rgb *to_rgb_priv(struct led_classdev_mc *cdev)
+{
+ return container_of(cdev, struct s2m_rgb, cdev);
+}
+
+static int s2m_rgb_lut_calc_timing(const u32 *lut, const size_t len,
+ const u32 req_time, u8 *idx)
+{
+ int lo = 0;
+ int hi = len - 2;
+
+ /* Bounds checking */
+ if (req_time < lut[0] || req_time > lut[len - 1])
+ return -EINVAL;
+
+ /*
+ * Perform a binary search to pick the best timing from the LUT.
+ *
+ * The search algorithm picks two consecutive elements of the
+ * LUT and tries to search the pair between which the requested
+ * time lies.
+ */
+ while (lo <= hi) {
+ *idx = (lo + hi) / 2;
+
+ if ((lut[*idx] <= req_time) && (req_time <= lut[*idx + 1]))
+ break;
+
+ if ((req_time < lut[*idx]) && (req_time < lut[*idx + 1]))
+ hi = *idx - 1;
+ else
+ lo = *idx + 1;
+ }
+
+ /*
+ * The searched timing is always less than the requested time. At
+ * times, the succeeding timing in the LUT is closer thus more
+ * accurate. Adjust the resulting value if that's the case.
+ */
+ if (abs(req_time - lut[*idx]) > abs(lut[*idx + 1] - req_time))
+ (*idx)++;
+
+ return 0;
+}
+
+static int s2m_rgb_brightness_set(struct led_classdev *cdev,
+ enum led_brightness value)
+{
+ struct s2m_rgb *priv = to_rgb_priv(to_cdev_mc(cdev));
+ int ret;
+
+ mutex_lock(&priv->lock);
+
+ led_mc_calc_color_components(&priv->cdev, value);
+
+ if (value == LED_OFF)
+ ret = priv->spec->params_reset(priv);
+ else
+ ret = priv->spec->params_apply(priv);
+
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
+static int s2m_rgb_pattern_set(struct led_classdev *cdev,
+ struct led_pattern *pattern, u32 len, int repeat)
+{
+ struct s2m_rgb *priv = to_rgb_priv(to_cdev_mc(cdev));
+ int brightness_peak = 0;
+ u32 time_hi = 0;
+ u32 time_lo = 0;
+ bool ramp_up_en;
+ bool ramp_dn_en;
+ int ret;
+ int i;
+
+ /*
+ * The typical pattern supported by this device can be
+ * represented with the following graph:
+ *
+ * 255 T ''''''-. .-'''''''-.
+ * | '. .' '.
+ * | \ / \
+ * | '. .' '.
+ * | '-...........-' '-
+ * 0 +----------------------------------------------------> time (s)
+ *
+ * <---- HIGH ----><-- LOW --><-------- HIGH --------->
+ * <-----><-------><---------><-------><-----><------->
+ * stay_hi ramp_dn stay_lo ramp_up stay_hi ramp_dn
+ *
+ * There are two states, named HIGH and LOW. HIGH has a non-zero
+ * brightness level, while LOW is of zero brightness. The
+ * pattern provided should mention only one zero and non-zero
+ * brightness level. The hardware always starts the pattern from
+ * the HIGH state, as shown in the graph.
+ *
+ * The HIGH state can be divided in three somewhat equal timings:
+ * ramp_up, stay_hi, and ramp_dn. The LOW state has only one
+ * timing: stay_lo.
+ */
+
+ /* Only indefinitely looping patterns are supported. */
+ if (repeat != -1)
+ return -EINVAL;
+
+ /* Pattern should consist of at least two tuples. */
+ if (len < 2)
+ return -EINVAL;
+
+ for (i = 0; i < len; i++) {
+ int brightness = pattern[i].brightness;
+ u32 delta_t = pattern[i].delta_t;
+
+ if (brightness) {
+ /*
+ * The pattern shold define only one non-zero
+ * brightness in the HIGH state. The device
+ * doesn't have any provisions to handle
+ * multiple peak brightness levels.
+ */
+ if (brightness_peak && brightness_peak != brightness)
+ return -EINVAL;
+
+ brightness_peak = brightness;
+ time_hi += delta_t;
+ ramp_dn_en = !!delta_t;
+ } else {
+ time_lo += delta_t;
+ ramp_up_en = !!delta_t;
+ }
+ }
+
+ mutex_lock(&priv->lock);
+
+ /*
+ * The timings ramp_up, stay_hi, and ramp_dn of the HIGH state
+ * are roughly equal. Firstly, calculate and set timings for
+ * ramp_up and ramp_dn (making sure they're exactly equal).
+ */
+ priv->ramp_up = 0;
+ priv->ramp_dn = 0;
+
+ if (ramp_up_en) {
+ ret = s2m_rgb_lut_calc_timing(priv->spec->lut_ramp_up,
+ priv->spec->lut_ramp_up_len,
+ time_hi / 3, &priv->ramp_up);
+ if (ret < 0)
+ goto param_fail;
+ }
+
+ if (ramp_dn_en) {
+ ret = s2m_rgb_lut_calc_timing(priv->spec->lut_ramp_dn,
+ priv->spec->lut_ramp_dn_len,
+ time_hi / 3, &priv->ramp_dn);
+ if (ret < 0)
+ goto param_fail;
+ }
+
+ /*
+ * Subtract the allocated ramp timings from time_hi (and also
+ * making sure it doesn't underflow!). The remaining time is
+ * allocated to stay_hi.
+ */
+ time_hi -= min(time_hi, priv->spec->lut_ramp_up[priv->ramp_up]);
+ time_hi -= min(time_hi, priv->spec->lut_ramp_dn[priv->ramp_dn]);
+
+ ret = s2m_rgb_lut_calc_timing(priv->spec->lut_stay_hi,
+ priv->spec->lut_stay_hi_len, time_hi,
+ &priv->stay_hi);
+ if (ret < 0)
+ goto param_fail;
+
+ ret = s2m_rgb_lut_calc_timing(priv->spec->lut_stay_lo,
+ priv->spec->lut_stay_lo_len, time_lo,
+ &priv->stay_lo);
+ if (ret < 0)
+ goto param_fail;
+
+ led_mc_calc_color_components(&priv->cdev, brightness_peak);
+ ret = priv->spec->params_apply(priv);
+ if (ret < 0)
+ goto param_fail;
+
+ mutex_unlock(&priv->lock);
+
+ return 0;
+
+param_fail:
+ mutex_unlock(&priv->lock);
+ priv->ramp_up = 0;
+ priv->ramp_dn = 0;
+ priv->stay_hi = 0;
+ priv->stay_lo = 0;
+
+ return ret;
+}
+
+static int s2m_rgb_pattern_clear(struct led_classdev *cdev)
+{
+ struct s2m_rgb *priv = to_rgb_priv(to_cdev_mc(cdev));
+ int ret;
+
+ mutex_lock(&priv->lock);
+
+ ret = priv->spec->params_reset(priv);
+
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
+static int s2mu005_rgb_apply_params(struct s2m_rgb *priv)
+{
+ struct regmap *regmap = priv->regmap;
+ unsigned int ramp_val = 0;
+ unsigned int stay_val = 0;
+ int ret;
+ int i;
+
+ ramp_val |= FIELD_PREP(S2MU005_RGB_CH_RAMP_UP, priv->ramp_up);
+ ramp_val |= FIELD_PREP(S2MU005_RGB_CH_RAMP_DN, priv->ramp_dn);
+
+ stay_val |= FIELD_PREP(S2MU005_RGB_CH_STAY_HI, priv->stay_hi);
+ stay_val |= FIELD_PREP(S2MU005_RGB_CH_STAY_LO, priv->stay_lo);
+
+ ret = regmap_write(regmap, S2MU005_REG_RGB_EN, S2MU005_RGB_RESET);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to reset RGB LEDs\n");
+ return ret;
+ }
+
+ for (i = 0; i < priv->cdev.num_colors; i++) {
+ ret = regmap_write(regmap, S2MU005_REG_RGB_CH_CTRL(i),
+ priv->cdev.subled_info[i].brightness);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to set LED brightness\n");
+ return ret;
+ }
+
+ ret = regmap_write(regmap, S2MU005_REG_RGB_CH_RAMP(i), ramp_val);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to set ramp timings\n");
+ return ret;
+ }
+
+ ret = regmap_write(regmap, S2MU005_REG_RGB_CH_STAY(i), stay_val);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to set stay timings\n");
+ return ret;
+ }
+ }
+
+ ret = regmap_update_bits(regmap, S2MU005_REG_RGB_EN, S2MU005_RGB_SLOPE,
+ S2MU005_RGB_SLOPE_SMOOTH);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to set ramp slope\n");
+ return ret;
+ }
+
+ return 0;
+}
+
+static int s2mu005_rgb_reset_params(struct s2m_rgb *priv)
+{
+ struct regmap *regmap = priv->regmap;
+ int ret;
+
+ ret = regmap_write(regmap, S2MU005_REG_RGB_EN, S2MU005_RGB_RESET);
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to reset RGB LEDs\n");
+ return ret;
+ }
+
+ priv->ramp_up = 0;
+ priv->ramp_dn = 0;
+ priv->stay_hi = 0;
+ priv->stay_lo = 0;
+
+ return 0;
+}
+
+static const u32 s2mu005_rgb_lut_ramp[] = {
+ 0, 100, 200, 300, 400, 500, 600, 700,
+ 800, 1000, 1200, 1400, 1600, 1800, 2000, 2200,
+};
+
+static const u32 s2mu005_rgb_lut_stay_hi[] = {
+ 100, 200, 300, 400, 500, 750, 1000, 1250,
+ 1500, 1750, 2000, 2250, 2500, 2750, 3000, 3250,
+};
+
+static const u32 s2mu005_rgb_lut_stay_lo[] = {
+ 0, 500, 1000, 1500, 2000, 2500, 3000, 3500,
+ 4000, 4500, 5000, 6000, 7000, 8000, 10000, 12000,
+};
+
+static const struct s2m_rgb_spec s2mu005_rgb_spec = {
+ .params_apply = s2mu005_rgb_apply_params,
+ .params_reset = s2mu005_rgb_reset_params,
+ .lut_ramp_up = s2mu005_rgb_lut_ramp,
+ .lut_ramp_up_len = ARRAY_SIZE(s2mu005_rgb_lut_ramp),
+ .lut_ramp_dn = s2mu005_rgb_lut_ramp,
+ .lut_ramp_dn_len = ARRAY_SIZE(s2mu005_rgb_lut_ramp),
+ .lut_stay_hi = s2mu005_rgb_lut_stay_hi,
+ .lut_stay_hi_len = ARRAY_SIZE(s2mu005_rgb_lut_stay_hi),
+ .lut_stay_lo = s2mu005_rgb_lut_stay_lo,
+ .lut_stay_lo_len = ARRAY_SIZE(s2mu005_rgb_lut_stay_lo),
+ .max_brightness = 255,
+};
+
+static struct mc_subled s2mu005_rgb_subled_info[] = {
+ {
+ .channel = 0,
+ .color_index = LED_COLOR_ID_BLUE,
+ }, {
+ .channel = 1,
+ .color_index = LED_COLOR_ID_GREEN,
+ }, {
+ .channel = 2,
+ .color_index = LED_COLOR_ID_RED,
+ },
+};
+
+static int s2m_rgb_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct sec_pmic_dev *pmic_drvdata = dev_get_drvdata(dev->parent);
+ struct s2m_rgb *priv;
+ struct led_init_data init_data = {};
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+ priv->dev = dev;
+ priv->regmap = pmic_drvdata->regmap_pmic;
+
+ switch (platform_get_device_id(pdev)->driver_data) {
+ case S2MU005:
+ priv->spec = &s2mu005_rgb_spec;
+ priv->cdev.subled_info = s2mu005_rgb_subled_info;
+ priv->cdev.num_colors = ARRAY_SIZE(s2mu005_rgb_subled_info);
+ break;
+ default:
+ return dev_err_probe(dev, -ENODEV,
+ "device type %d is not supported by driver\n",
+ pmic_drvdata->device_type);
+ }
+
+ priv->cdev.led_cdev.max_brightness = priv->spec->max_brightness;
+ priv->cdev.led_cdev.brightness_set_blocking = s2m_rgb_brightness_set;
+ priv->cdev.led_cdev.pattern_set = s2m_rgb_pattern_set;
+ priv->cdev.led_cdev.pattern_clear = s2m_rgb_pattern_clear;
+
+ ret = devm_mutex_init(dev, &priv->lock);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to create mutex lock\n");
+
+ init_data.fwnode = of_fwnode_handle(dev->of_node);
+ ret = devm_led_classdev_multicolor_register_ext(dev, &priv->cdev,
+ &init_data);
+ if (ret < 0)
+ return dev_err_probe(dev, ret, "failed to create LED device\n");
+
+ return 0;
+}
+
+static const struct platform_device_id s2m_rgb_id_table[] = {
+ { "s2mu005-rgb", S2MU005 },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, s2m_rgb_id_table);
+
+/*
+ * Device is instantiated through parent MFD device and device matching
+ * is done through platform_device_id.
+ *
+ * However if device's DT node contains proper compatible and driver is
+ * built as a module, then the *module* matching will be done through DT
+ * aliases. This requires of_device_id table. In the same time this will
+ * not change the actual *device* matching so do not add .of_match_table.
+ */
+static const struct of_device_id s2m_rgb_of_match_table[] = {
+ {
+ .compatible = "samsung,s2mu005-rgb",
+ .data = (void *)S2MU005,
+ }, {
+ /* sentinel */
+ },
+};
+MODULE_DEVICE_TABLE(of, s2m_rgb_of_match_table);
+
+static struct platform_driver s2m_rgb_driver = {
+ .driver = {
+ .name = "s2m-rgb",
+ },
+ .probe = s2m_rgb_probe,
+ .id_table = s2m_rgb_id_table,
+};
+module_platform_driver(s2m_rgb_driver);
+
+MODULE_DESCRIPTION("RGB LED Driver For Samsung S2M Series PMICs");
+MODULE_AUTHOR("Kaustabh Chakraborty <kauschluss@disroot.org>");
+MODULE_LICENSE("GPL");
--
2.52.0
^ permalink raw reply related
* [PATCH v3 09/13] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: Kaustabh Chakraborty @ 2026-02-24 19:15 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Kaustabh Chakraborty
In-Reply-To: <20260225-s2mu005-pmic-v3-0-b4afee947603@disroot.org>
Add support for flash LEDs found in certain Samsung S2M series PMICs.
The device has two channels for LEDs, typically for the back and front
cameras in mobile devices. Both channels can be independently
controlled, and can be operated in torch or flash modes.
The driver includes initial support for the S2MU005 PMIC flash LEDs.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/leds/flash/Kconfig | 12 +
drivers/leds/flash/Makefile | 1 +
drivers/leds/flash/leds-s2m-flash.c | 429 ++++++++++++++++++++++++++++++++++++
3 files changed, 442 insertions(+)
diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
index 5e08102a67841..be62e05277429 100644
--- a/drivers/leds/flash/Kconfig
+++ b/drivers/leds/flash/Kconfig
@@ -114,6 +114,18 @@ config LEDS_RT8515
To compile this driver as a module, choose M here: the module
will be called leds-rt8515.
+config LEDS_S2M_FLASH
+ tristate "Samsung S2M series PMICs flash/torch LED support"
+ depends on LEDS_CLASS
+ depends on MFD_SEC_CORE
+ depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
+ select REGMAP_IRQ
+ help
+ This option enables support for the flash/torch LEDs found in
+ certain Samsung S2M series PMICs, such as the S2MU005. It has
+ a LED channel dedicated for every physical LED. The LEDs can
+ be controlled in flash and torch modes.
+
config LEDS_SGM3140
tristate "LED support for the SGM3140"
depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
index 712fb737a428e..44e6c1b4beb37 100644
--- a/drivers/leds/flash/Makefile
+++ b/drivers/leds/flash/Makefile
@@ -10,6 +10,7 @@ obj-$(CONFIG_LEDS_MAX77693) += leds-max77693.o
obj-$(CONFIG_LEDS_QCOM_FLASH) += leds-qcom-flash.o
obj-$(CONFIG_LEDS_RT4505) += leds-rt4505.o
obj-$(CONFIG_LEDS_RT8515) += leds-rt8515.o
+obj-$(CONFIG_LEDS_S2M_FLASH) += leds-s2m-flash.o
obj-$(CONFIG_LEDS_SGM3140) += leds-sgm3140.o
obj-$(CONFIG_LEDS_SY7802) += leds-sy7802.o
obj-$(CONFIG_LEDS_TPS6131X) += leds-tps6131x.o
diff --git a/drivers/leds/flash/leds-s2m-flash.c b/drivers/leds/flash/leds-s2m-flash.c
new file mode 100644
index 0000000000000..536a529889a9c
--- /dev/null
+++ b/drivers/leds/flash/leds-s2m-flash.c
@@ -0,0 +1,429 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Flash and Torch LED Driver for Samsung S2M series PMICs.
+ *
+ * Copyright (c) 2015 Samsung Electronics Co., Ltd
+ * Copyright (c) 2025 Kaustabh Chakraborty <kauschluss@disroot.org>
+ */
+
+#include <linux/container_of.h>
+#include <linux/led-class-flash.h>
+#include <linux/mfd/samsung/core.h>
+#include <linux/mfd/samsung/s2mu005.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <media/v4l2-flash-led-class.h>
+
+#define MAX_CHANNELS 2
+
+struct s2m_fled {
+ struct device *dev;
+ struct regmap *regmap;
+ struct led_classdev_flash cdev;
+ struct v4l2_flash *v4l2_flash;
+ /*
+ * The mutex object prevents the concurrent access of flash control
+ * registers by the LED and V4L2 subsystems.
+ */
+ struct mutex lock;
+ const struct s2m_fled_spec *spec;
+ unsigned int reg_enable;
+ u8 channel;
+ u8 flash_brightness;
+ u8 flash_timeout;
+};
+
+struct s2m_fled_spec {
+ u8 nr_channels;
+ u32 torch_max_brightness;
+ u32 flash_min_current_ua;
+ u32 flash_max_current_ua;
+ u32 flash_min_timeout_us;
+ u32 flash_max_timeout_us;
+ int (*torch_brightness_set_blocking)(struct led_classdev *led_cdev,
+ enum led_brightness brightness);
+ 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 void s2m_fled_v4l2_flash_release(void *v4l2_flash)
+{
+ v4l2_flash_release(v4l2_flash);
+}
+
+static int s2mu005_fled_torch_brightness_set(struct led_classdev *cdev,
+ enum led_brightness value)
+{
+ struct s2m_fled *priv = to_led_priv(to_cdev_flash(cdev));
+ struct regmap *regmap = priv->regmap;
+ int ret;
+
+ mutex_lock(&priv->lock);
+
+ if (value == LED_OFF) {
+ ret = regmap_clear_bits(regmap, priv->reg_enable,
+ S2MU005_FLED_TORCH_EN(priv->channel));
+ if (ret < 0)
+ dev_err(priv->dev, "failed to disable torch LED\n");
+ goto unlock;
+ }
+
+ ret = regmap_update_bits(regmap, S2MU005_REG_FLED_CH_CTRL1(priv->channel),
+ S2MU005_FLED_TORCH_IOUT,
+ FIELD_PREP(S2MU005_FLED_TORCH_IOUT, value - 1));
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to set torch current\n");
+ goto unlock;
+ }
+
+ ret = regmap_set_bits(regmap, priv->reg_enable,
+ S2MU005_FLED_TORCH_EN(priv->channel));
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to enable torch LED\n");
+ goto unlock;
+ }
+
+unlock:
+ mutex_unlock(&priv->lock);
+
+ return ret;
+}
+
+static int s2mu005_fled_flash_strobe_set(struct led_classdev_flash *cdev,
+ bool state)
+{
+ struct s2m_fled *priv = to_led_priv(cdev);
+ struct regmap *regmap = priv->regmap;
+ int ret;
+
+ mutex_lock(&priv->lock);
+
+ ret = regmap_clear_bits(regmap, priv->reg_enable,
+ S2MU005_FLED_FLASH_EN(priv->channel));
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to disable flash LED\n");
+ goto unlock;
+ }
+
+ if (!state)
+ goto unlock;
+
+ ret = regmap_update_bits(regmap, S2MU005_REG_FLED_CH_CTRL0(priv->channel),
+ S2MU005_FLED_FLASH_IOUT,
+ FIELD_PREP(S2MU005_FLED_FLASH_IOUT,
+ priv->flash_brightness));
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to set flash brightness\n");
+ goto unlock;
+ }
+
+ ret = regmap_update_bits(regmap, S2MU005_REG_FLED_CH_CTRL3(priv->channel),
+ S2MU005_FLED_FLASH_TIMEOUT,
+ FIELD_PREP(S2MU005_FLED_FLASH_TIMEOUT,
+ priv->flash_timeout));
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to set flash timeout\n");
+ goto unlock;
+ }
+
+ ret = regmap_set_bits(regmap, priv->reg_enable,
+ S2MU005_FLED_FLASH_EN(priv->channel));
+ if (ret < 0) {
+ dev_err(priv->dev, "failed to enable flash LED\n");
+ goto unlock;
+ }
+
+unlock:
+ mutex_unlock(&priv->lock);
+
+ return 0;
+}
+
+static int s2mu005_fled_flash_strobe_get(struct led_classdev_flash *cdev,
+ bool *state)
+{
+ struct s2m_fled *priv = to_led_priv(cdev);
+ struct regmap *regmap = priv->regmap;
+ 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 int s2mu005_fled_init(struct s2m_fled *priv)
+{
+ unsigned int val;
+ int ret;
+
+ /* Enable the LED channels. */
+ ret = regmap_set_bits(priv->regmap, S2MU005_REG_FLED_CTRL1,
+ S2MU005_FLED_CH_EN);
+ if (ret < 0)
+ return dev_err_probe(priv->dev, ret, "failed to enable LED channels\n");
+
+ /*
+ * Get the LED enable register address. Revision EVT0 has the
+ * register at CTRL4, while EVT1 and higher have it at CTRL6.
+ */
+ ret = regmap_read(priv->regmap, S2MU005_REG_ID, &val);
+ if (ret < 0)
+ return dev_err_probe(priv->dev, ret, "failed to read revision\n");
+
+ if (FIELD_GET(S2MU005_ID_MASK, val) == 0)
+ priv->reg_enable = S2MU005_REG_FLED_CTRL4;
+ else
+ priv->reg_enable = S2MU005_REG_FLED_CTRL6;
+
+ return 0;
+}
+
+static const struct s2m_fled_spec s2mu005_fled_spec = {
+ .nr_channels = 2,
+ .torch_max_brightness = 16,
+ .flash_min_current_ua = 25000,
+ .flash_max_current_ua = 375000, /* 400000 causes flickering */
+ .flash_min_timeout_us = 62000,
+ .flash_max_timeout_us = 992000,
+ .torch_brightness_set_blocking = s2mu005_fled_torch_brightness_set,
+ .flash_ops = &s2mu005_fled_flash_ops,
+};
+
+static int s2m_fled_init_channel(struct s2m_fled *priv,
+ struct fwnode_handle *fwnp)
+{
+ 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(priv->dev, &priv->cdev,
+ &init_data);
+ if (ret < 0)
+ return dev_err_probe(priv->dev, ret, "failed to create LED flash device\n");
+
+ v4l2_cfg.intensity.min = priv->spec->flash_min_current_ua;
+ v4l2_cfg.intensity.step = priv->spec->flash_min_current_ua;
+ v4l2_cfg.intensity.max = priv->spec->flash_max_current_ua;
+ v4l2_cfg.intensity.val = priv->spec->flash_max_current_ua;
+
+ v4l2_cfg.has_external_strobe = true;
+
+ priv->v4l2_flash = v4l2_flash_init(priv->dev, fwnp, &priv->cdev,
+ &s2m_fled_v4l2_flash_ops, &v4l2_cfg);
+ if (IS_ERR(priv->v4l2_flash)) {
+ v4l2_flash_release(priv->v4l2_flash);
+ return dev_err_probe(priv->dev, PTR_ERR(priv->v4l2_flash),
+ "failed to create V4L2 flash device\n");
+ }
+
+ ret = devm_add_action_or_reset(priv->dev, (void *)s2m_fled_v4l2_flash_release,
+ priv->v4l2_flash);
+ if (ret < 0)
+ return dev_err_probe(priv->dev, ret, "failed to add cleanup action\n");
+
+ return 0;
+}
+
+static int s2m_fled_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct sec_pmic_dev *pmic_drvdata = dev_get_drvdata(dev->parent);
+ struct s2m_fled *priv;
+ bool channel_initialized[MAX_CHANNELS] = { false };
+ int ret;
+
+ priv = devm_kzalloc(dev, sizeof(*priv) * MAX_CHANNELS, GFP_KERNEL);
+ if (!priv)
+ return -ENOMEM;
+
+ platform_set_drvdata(pdev, priv);
+ priv->dev = dev;
+ priv->regmap = pmic_drvdata->regmap_pmic;
+
+ switch (platform_get_device_id(pdev)->driver_data) {
+ case S2MU005:
+ priv->spec = &s2mu005_fled_spec;
+ ret = s2mu005_fled_init(priv);
+ if (ret)
+ return ret;
+ break;
+ default:
+ return dev_err_probe(dev, -ENODEV,
+ "device type %d is not supported by driver\n",
+ pmic_drvdata->device_type);
+ }
+
+ if (priv->spec->nr_channels > MAX_CHANNELS)
+ return dev_err_probe(dev, -EINVAL,
+ "number of channels specified (%u) exceeds the limit (%u)\n",
+ priv->spec->nr_channels, MAX_CHANNELS);
+
+ device_for_each_child_node_scoped(dev, child) {
+ u32 reg;
+
+ if (fwnode_property_read_u32(child, "reg", ®))
+ continue;
+
+ if (reg >= priv->spec->nr_channels) {
+ dev_warn(dev, "channel %d is non-existent\n", reg);
+ continue;
+ }
+
+ if (channel_initialized[reg]) {
+ dev_warn(dev, "duplicate node for channel %d\n", reg);
+ continue;
+ }
+
+ priv[reg].dev = priv->dev;
+ priv[reg].regmap = priv->regmap;
+ priv[reg].spec = priv->spec;
+ priv[reg].reg_enable = priv->reg_enable;
+ priv[reg].channel = (u8)reg;
+
+ 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(priv + reg, child);
+ if (ret < 0)
+ return ret;
+
+ channel_initialized[reg] = true;
+ }
+
+ return 0;
+}
+
+static const struct platform_device_id s2m_fled_id_table[] = {
+ { "s2mu005-flash", S2MU005 },
+ { /* sentinel */ },
+};
+MODULE_DEVICE_TABLE(platform, s2m_fled_id_table);
+
+/*
+ * Device is instantiated through parent MFD device and device matching
+ * is done through platform_device_id.
+ *
+ * However if device's DT node contains proper compatible and driver is
+ * built as a module, then the *module* matching will be done through DT
+ * aliases. This requires of_device_id table. In the same time this will
+ * not change the actual *device* matching so do not add .of_match_table.
+ */
+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);
+
+static struct platform_driver s2m_fled_driver = {
+ .driver = {
+ .name = "s2m-flash",
+ },
+ .probe = s2m_fled_probe,
+ .id_table = s2m_fled_id_table,
+};
+module_platform_driver(s2m_fled_driver);
+
+MODULE_DESCRIPTION("Flash/Torch LED Driver For Samsung S2M Series PMICs");
+MODULE_AUTHOR("Kaustabh Chakraborty <kauschluss@disroot.org>");
+MODULE_LICENSE("GPL");
--
2.52.0
^ permalink raw reply related
* [PATCH v3 08/13] mfd: sec: resolve PMIC revision in S2MU005
From: Kaustabh Chakraborty @ 2026-02-24 19:15 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Kaustabh Chakraborty
In-Reply-To: <20260225-s2mu005-pmic-v3-0-b4afee947603@disroot.org>
In devices other than S2MPG1X, the revision can be retrieved from the
first register of the PMIC regmap. In S2MU005 however, the location is
in offset 0x73. Introduce a switch-case block to allow selecting the
REG_ID register.
S2MU005 also has a field mask for the revision. Apply it using
FIELD_GET() and get the extracted value.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/mfd/sec-common.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/mfd/sec-common.c b/drivers/mfd/sec-common.c
index b3268516bf75e..230bee16d0690 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>
@@ -119,20 +120,27 @@ static const struct mfd_cell s2mu005_devs[] = {
static void sec_pmic_dump_rev(struct sec_pmic_dev *sec_pmic)
{
- unsigned int val;
+ unsigned int reg, mask, val;
- /* For s2mpg1x, the revision is in a different regmap */
switch (sec_pmic->device_type) {
case S2MPG10:
case S2MPG11:
+ /* For s2mpg1x, the revision is in a different regmap */
return;
- default:
+ case S2MU005:
+ reg = S2MU005_REG_ID;
+ mask = S2MU005_ID_MASK;
break;
+ default:
+ /* For other device types, REG_ID is always the first register. */
+ reg = S2MPS11_REG_ID;
+ mask = ~0;
}
- /* For each device type, the REG_ID is always the first register */
- if (!regmap_read(sec_pmic->regmap_pmic, S2MPS11_REG_ID, &val))
+ if (!regmap_read(sec_pmic->regmap_pmic, reg, &val)) {
+ val = FIELD_GET(S2MU005_ID_MASK, val);
dev_dbg(sec_pmic->dev, "Revision: 0x%x\n", val);
+ }
}
static void sec_pmic_configure(struct sec_pmic_dev *sec_pmic)
--
2.52.0
^ permalink raw reply related
* [PATCH v3 07/13] mfd: sec: set DMA coherent mask
From: Kaustabh Chakraborty @ 2026-02-24 19:15 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Kaustabh Chakraborty
In-Reply-To: <20260225-s2mu005-pmic-v3-0-b4afee947603@disroot.org>
Kernel logs are filled with "DMA mask not set" messages for every
sub-device. The device does not use DMA for communication, so these
messages are useless. Disable the coherent DMA mask for the PMIC device,
which is also propagated to sub-devices.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/mfd/sec-i2c.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/mfd/sec-i2c.c b/drivers/mfd/sec-i2c.c
index d8609886fcc80..9fa1449a4f6eb 100644
--- a/drivers/mfd/sec-i2c.c
+++ b/drivers/mfd/sec-i2c.c
@@ -177,6 +177,9 @@ static int sec_pmic_i2c_probe(struct i2c_client *client)
return dev_err_probe(&client->dev, PTR_ERR(regmap_pmic),
"regmap init failed\n");
+ client->dev.coherent_dma_mask = 0;
+ client->dev.dma_mask = &client->dev.coherent_dma_mask;
+
return sec_pmic_probe(&client->dev, pdata->device_type, client->irq,
regmap_pmic, client);
}
--
2.52.0
^ permalink raw reply related
* [PATCH v3 06/13] mfd: sec: add support for S2MU005 PMIC
From: Kaustabh Chakraborty @ 2026-02-24 19:15 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Kaustabh Chakraborty
In-Reply-To: <20260225-s2mu005-pmic-v3-0-b4afee947603@disroot.org>
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 | 29 ++++
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 | 327 ++++++++++++++++++++++++++++++++++++
6 files changed, 513 insertions(+)
diff --git a/drivers/mfd/sec-common.c b/drivers/mfd/sec-common.c
index bd8b5f9686892..b3268516bf75e 100644
--- a/drivers/mfd/sec-common.c
+++ b/drivers/mfd/sec-common.c
@@ -105,6 +105,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;
@@ -250,6 +262,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..d8609886fcc80 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>
@@ -66,6 +67,19 @@ static bool s2mpu02_volatile(struct device *dev, unsigned int reg)
}
}
+static bool s2mu005_volatile(struct device *dev, unsigned int reg)
+{
+ switch (reg) {
+ case S2MU005_REG_CHGR_INT1M:
+ case S2MU005_REG_FLED_INT1M:
+ case S2MU005_REG_MUIC_INT1M:
+ case S2MU005_REG_MUIC_INT2M:
+ return false;
+ default:
+ return true;
+ }
+}
+
static const struct regmap_config s2dos05_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -130,6 +144,15 @@ 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,
+
+ .max_register = S2MU005_REG_MUIC_LDOADC_H,
+ .volatile_reg = s2mu005_volatile,
+ .cache_type = REGCACHE_FLAT_S,
+};
+
static const struct regmap_config s5m8767_regmap_config = {
.reg_bits = 8,
.val_bits = 8,
@@ -203,6 +226,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 +245,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 133188391f7c2..91a2922463fb6 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -16,6 +16,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"
@@ -223,6 +224,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 S2MU005_REG_CHGR_INT1:
+ return irqf_regs[index];
+ case S2MU005_REG_CHGR_INT1M:
+ 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),
@@ -337,6 +397,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,
@@ -442,6 +513,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 4480c631110a6..6191f409de945 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -47,6 +47,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 6eab95de6fa83..19d0f0e12944f 100644
--- a/include/linux/mfd/samsung/irq.h
+++ b/include/linux/mfd/samsung/irq.h
@@ -408,6 +408,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..07f4ae664950d
--- /dev/null
+++ b/include/linux/mfd/samsung/s2mu005.h
@@ -0,0 +1,327 @@
+/* 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 8
+#define S2MU005_CHGR_STAT_TOPOFF 7
+#define S2MU005_CHGR_STAT_DONE_FLAG 6
+#define S2MU005_CHGR_STAT_CV 5
+#define S2MU005_CHGR_STAT_CC 4
+#define S2MU005_CHGR_STAT_COOL_CHG 3
+#define S2MU005_CHGR_STAT_PRE_CHG 2
+
+/* S2MU005_REG_CHGR_STATUS1 */
+#define S2MU005_CHGR_DETBAT BIT(7)
+#define S2MU005_CHGR_VBUS_OVP GENMASK(6, 4)
+
+#define S2MU005_CHGR_VBUS_OVP_OVERVOLT 2
+
+/* S2MU005_REG_CHGR_STATUS2 */
+#define S2MU005_CHGR_BAT GENMASK(6, 4)
+
+#define S2MU005_CHGR_BAT_VOLT_DET 7
+#define S2MU005_CHGR_BAT_FAST_CHG_DET 6
+#define S2MU005_CHGR_BAT_COOL_CHG_DET 5
+#define S2MU005_CHGR_BAT_LOW_CHG 2
+#define S2MU005_CHGR_BAT_SELF_DISCHG 1
+#define S2MU005_CHGR_BAT_OVP_DET 0
+
+/* S2MU005_REG_CHGR_STATUS3 */
+#define S2MU005_CHGR_EVT GENMASK(3, 0)
+
+#define S2MU005_CHGR_EVT_WDT_RST 6
+#define S2MU005_CHGR_EVT_WDT_SUSP 5
+#define S2MU005_CHGR_EVT_VSYS_VUVLO 4
+#define S2MU005_CHGR_EVT_VSYS_VOVP 3
+#define S2MU005_CHGR_EVT_THERM_FOLDBACK 2
+#define S2MU005_CHGR_EVT_THERM_SHUTDOWN 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 BIT(2)
+#define S2MU005_CHGR_OP_MODE_CHG 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 BIT(2)
+#define S2MU005_CHGR_WDT_OFF 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)
+
+/* S2MU005_REG_MUIC_SWCTRL */
+#define S2MU005_MUIC_DM_DP GENMASK(7, 2)
+#define S2MU005_MUIC_JIG BIT(0)
+
+#define S2MU005_MUIC_DM_DP_UART 0x12
+#define S2MU005_MUIC_DM_DP_USB 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 0x1f
+#define S2MU005_MUIC_VSET_2P6V 0x0e
+#define S2MU005_MUIC_VSET_2P4V 0x0c
+#define S2MU005_MUIC_VSET_2P2V 0x0a
+#define S2MU005_MUIC_VSET_2P0V 0x08
+#define S2MU005_MUIC_VSET_1P5V 0x03
+#define S2MU005_MUIC_VSET_1P4V 0x02
+#define S2MU005_MUIC_VSET_1P2V 0x00
+
+#endif /* __LINUX_MFD_S2MU005_H */
--
2.52.0
^ permalink raw reply related
* [PATCH v3 05/13] dt-bindings: mfd: s2mps11: add documentation for S2MU005 PMIC
From: Kaustabh Chakraborty @ 2026-02-24 19:15 UTC (permalink / raw)
To: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran
Cc: linux-leds, devicetree, linux-kernel, linux-pm, linux-samsung-soc,
linux-rtc, linux-doc, Kaustabh Chakraborty
In-Reply-To: <20260225-s2mu005-pmic-v3-0-b4afee947603@disroot.org>
Samsung's S2MU005 PMIC includes subdevices for a charger, an MUIC (Micro
USB Interface Controller), and flash and RGB LED controllers.
Since regulators are not supported by this device, unmark this property
as required and instead set this in a per-device basis for ones which
need it.
Add the compatible and documentation for the S2MU005 PMIC. Also, add an
example for nodes for supported sub-devices, i.e. charger, extcon,
flash, and rgb.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
.../devicetree/bindings/mfd/samsung,s2mps11.yaml | 109 ++++++++++++++++++++-
1 file changed, 108 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml
index ac5d0c149796b..684409e26273a 100644
--- a/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml
+++ b/Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml
@@ -26,12 +26,28 @@ properties:
- samsung,s2mps15-pmic
- samsung,s2mpu02-pmic
- samsung,s2mpu05-pmic
+ - samsung,s2mu005-pmic
clocks:
$ref: /schemas/clock/samsung,s2mps11.yaml
description:
Child node describing clock provider.
+ charger:
+ $ref: /schemas/power/supply/samsung,s2mu005-charger.yaml
+ description:
+ Child node describing battery charger device.
+
+ extcon:
+ $ref: /schemas/extcon/samsung,s2mu005-muic.yaml
+ description:
+ Child node describing extcon device.
+
+ flash:
+ $ref: /schemas/leds/samsung,s2mu005-flash.yaml
+ description:
+ Child node describing flash LEDs.
+
interrupts:
maxItems: 1
@@ -43,6 +59,11 @@ properties:
description:
List of child nodes that specify the regulators.
+ rgb:
+ $ref: /schemas/leds/samsung,s2mu005-rgb.yaml
+ description:
+ Child node describing RGB LEDs.
+
samsung,s2mps11-acokb-ground:
description: |
Indicates that ACOKB pin of S2MPS11 PMIC is connected to the ground so
@@ -63,7 +84,6 @@ properties:
required:
- compatible
- reg
- - regulators
additionalProperties: false
@@ -78,6 +98,8 @@ allOf:
regulators:
$ref: /schemas/regulator/samsung,s2mps11.yaml
samsung,s2mps11-wrstbi-ground: false
+ required:
+ - regulators
- if:
properties:
@@ -89,6 +111,8 @@ allOf:
regulators:
$ref: /schemas/regulator/samsung,s2mps13.yaml
samsung,s2mps11-acokb-ground: false
+ required:
+ - regulators
- if:
properties:
@@ -101,6 +125,8 @@ allOf:
$ref: /schemas/regulator/samsung,s2mps14.yaml
samsung,s2mps11-acokb-ground: false
samsung,s2mps11-wrstbi-ground: false
+ required:
+ - regulators
- if:
properties:
@@ -113,6 +139,8 @@ allOf:
$ref: /schemas/regulator/samsung,s2mps15.yaml
samsung,s2mps11-acokb-ground: false
samsung,s2mps11-wrstbi-ground: false
+ required:
+ - regulators
- if:
properties:
@@ -125,6 +153,8 @@ allOf:
$ref: /schemas/regulator/samsung,s2mpu02.yaml
samsung,s2mps11-acokb-ground: false
samsung,s2mps11-wrstbi-ground: false
+ required:
+ - regulators
- if:
properties:
@@ -137,6 +167,18 @@ allOf:
$ref: /schemas/regulator/samsung,s2mpu05.yaml
samsung,s2mps11-acokb-ground: false
samsung,s2mps11-wrstbi-ground: false
+ required:
+ - regulators
+
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: samsung,s2mu005-pmic
+ then:
+ properties:
+ samsung,s2mps11-acokb-ground: false
+ samsung,s2mps11-wrstbi-ground: false
examples:
- |
@@ -278,3 +320,68 @@ examples:
};
};
};
+
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/leds/common.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pmic@3d {
+ compatible = "samsung,s2mu005-pmic";
+ reg = <0x3d>;
+ interrupt-parent = <&gpa2>;
+ interrupts = <7 IRQ_TYPE_LEVEL_LOW>;
+
+ charger {
+ compatible = "samsung,s2mu005-charger";
+ monitored-battery = <&battery>;
+ };
+
+ extcon {
+ compatible = "samsung,s2mu005-muic";
+
+ connector {
+ compatible = "usb-b-connector";
+ label = "micro-USB";
+ type = "micro";
+ };
+
+ port {
+ muic_to_usb: endpoint {
+ remote-endpoint = <&usb_to_muic>;
+ };
+ };
+ };
+
+ flash {
+ compatible = "samsung,s2mu005-flash";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ label = "back-cam:white:flash";
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_FLASH;
+ };
+
+ led@1 {
+ reg = <1>;
+ label = "front-cam:white:flash";
+ color = <LED_COLOR_ID_WHITE>;
+ function = LED_FUNCTION_FLASH;
+ };
+ };
+
+ rgb {
+ compatible = "samsung,s2mu005-rgb";
+ label = "notification:rgb:indicator";
+ color = <LED_COLOR_ID_RGB>;
+ function = LED_FUNCTION_INDICATOR;
+ linux,default-trigger = "pattern";
+ };
+ };
+ };
--
2.52.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox