* Re: [PATCH 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress
From: Muhammad Usama Anjum @ 2025-11-25 10:22 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: usama.anjum, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <CAJZ5v0gtGjE-rSwM4Kom4cDEhp3eSOkLCmbLwrt_9u9a7VP6zQ@mail.gmail.com>
On 11/24/25 11:50 PM, Rafael J. Wysocki wrote:
> On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
> <usama.anjum@collabora.com> wrote:
>>
>> Input (Serio) drivers call input_handle_event(). Although the serio
>> drivers have duplicate events, they have separate code path and call
>> input_handle_event(). Ignore the KEY_POWER such that this event isn't
>> sent to the userspace if hibernation is in progress.
>
> Your change affects suspend too.
>
> Also, what's the goal you want to achieve?
Two goals:
* Don't send event to userspace
* Set pm_wakeup for hibernation cancellation for non-acpi devices (This api
call should be tested on non-acpi devices such as arm board to see if it
helps. I don't have an arm board in hand)
>
>> Abort the hibernation by calling pm_wakeup_dev_event(). In case of serio,
>> doesn't have wakeup source registered, this call doesn't do anything.
>> But there may be other input drivers which will require this.
>>
>> Without this, the event is sent to the userspace and it suspends the
>> device after hibernation cancellation.
>
> I think that's because user space handles it this way, isn't it?
Yes, it depends on how userspace handles such events. There are different settings
configured for systemd-logind when power event is received. The purpose is to consume
this event to cancel the hibernation without letting userspace know about it.
Thinking more about it, I wasn't sure if all of such events are compulsory to be
delivered to userspace. But then I found an example: In acpi_button_notify(), all
such events are not sent to userspace if button is suspended. So it seems okay to
not send this as well and just consume in the kernel.
>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
>> ---
>> Changes since RFC:
>> - Use pm_sleep_transition_in_progress()
>> - Update description
>> ---
>> drivers/input/input.c | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>> index a500e1e276c21..7939bd9e47668 100644
>> --- a/drivers/input/input.c
>> +++ b/drivers/input/input.c
>> @@ -26,6 +26,7 @@
>> #include <linux/kstrtox.h>
>> #include <linux/mutex.h>
>> #include <linux/rcupdate.h>
>> +#include <linux/suspend.h>
>> #include "input-compat.h"
>> #include "input-core-private.h"
>> #include "input-poller.h"
>> @@ -362,6 +363,11 @@ void input_handle_event(struct input_dev *dev,
>>
>> lockdep_assert_held(&dev->event_lock);
>>
>> + if (code == KEY_POWER && pm_sleep_transition_in_progress()) {
>> + pm_wakeup_dev_event(&dev->dev, 0, true);
>> + return;
>> + }
>> +
>> disposition = input_get_disposition(dev, type, code, &value);
>> if (disposition != INPUT_IGNORE_EVENT) {
>> if (type != EV_SYN)
>> --
--
---
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH 4/4] PM: sleep: clear pm_abort_suspend at suspend
From: Muhammad Usama Anjum @ 2025-11-25 9:53 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: usama.anjum, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <CAJZ5v0iucMXFkKuRxtAUyAqW11NHHGVuYnjJNbroeMgJoGY1kw@mail.gmail.com>
Hi Rafael,
Thank you for reviewing.
On 11/24/25 11:54 PM, Rafael J. Wysocki wrote:
> On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
> <usama.anjum@collabora.com> wrote:
>>
>> Clear pm_abort_suspend counter in case a wakeup is detected during
>> hibernation process. If this counter isn't reset, it'll affect the
>> next hibernation cycle and next time hibernation will not happen as
>> pm_abort_suspend is still positive.
>>
>> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
>> ---
>> drivers/base/power/main.c | 2 ++
>> kernel/cpu.c | 1 +
>> kernel/power/hibernate.c | 5 ++++-
>> kernel/power/process.c | 1 +
>> 4 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
>> index 5760abb25b591..84e76f8df1e02 100644
>> --- a/drivers/base/power/main.c
>> +++ b/drivers/base/power/main.c
>> @@ -1642,6 +1642,7 @@ static void device_suspend_late(struct device *dev, pm_message_t state, bool asy
>> goto Complete;
>>
>> if (pm_wakeup_pending()) {
>> + pm_wakeup_clear(0);
>> WRITE_ONCE(async_error, -EBUSY);
>> goto Complete;
>> }
>> @@ -1887,6 +1888,7 @@ static void device_suspend(struct device *dev, pm_message_t state, bool async)
>>
>> if (pm_wakeup_pending()) {
>> dev->power.direct_complete = false;
>> + pm_wakeup_clear(0);
>> WRITE_ONCE(async_error, -EBUSY);
>> goto Complete;
>> }
>> diff --git a/kernel/cpu.c b/kernel/cpu.c
>> index db9f6c539b28c..74c9f6b4947dd 100644
>> --- a/kernel/cpu.c
>> +++ b/kernel/cpu.c
>> @@ -1921,6 +1921,7 @@ int freeze_secondary_cpus(int primary)
>>
>> if (pm_wakeup_pending()) {
>> pr_info("Wakeup pending. Abort CPU freeze\n");
>> + pm_wakeup_clear(0);
>> error = -EBUSY;
>> break;
>> }
>> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
>> index e15907f28c4cd..1f6b60df45d34 100644
>> --- a/kernel/power/hibernate.c
>> +++ b/kernel/power/hibernate.c
>> @@ -349,8 +349,10 @@ static int create_image(int platform_mode)
>> goto Enable_irqs;
>> }
>>
>> - if (hibernation_test(TEST_CORE) || pm_wakeup_pending())
>> + if (hibernation_test(TEST_CORE) || pm_wakeup_pending()) {
>> + pm_wakeup_clear(0);
>> goto Power_up;
>> + }
>>
>> in_suspend = 1;
>> save_processor_state();
>> @@ -660,6 +662,7 @@ int hibernation_platform_enter(void)
>> goto Enable_irqs;
>>
>> if (pm_wakeup_pending()) {
>> + pm_wakeup_clear(0);
>> error = -EAGAIN;
>> goto Power_up;
>> }
>> diff --git a/kernel/power/process.c b/kernel/power/process.c
>> index dc0dfc349f22b..e935b27a04ae0 100644
>> --- a/kernel/power/process.c
>> +++ b/kernel/power/process.c
>> @@ -67,6 +67,7 @@ static int try_to_freeze_tasks(bool user_only)
>> break;
>>
>> if (pm_wakeup_pending()) {
>> + pm_wakeup_clear(0);
>> wakeup = true;
>> break;
>> }
>> --
>
> I don't think pm_wakeup_clear() needs to be called in so many places.
>
> Any why isn't it sufficient to call it in freeze_processes()? For
> suspend, it is sufficient, so what's different about hibernation in
> that respect?
It seems this patch was written by me when [1] was added which removed the
unconditional call pm_wakeup_clear(0) from freeze_processes(). It was later
reverted [2].
I've removed this patch and tested again to find out:
- try_to_freeze_tasks() gets called from freeze_process() after
unconditional clearing of pm_wakeup. So pm_wakeup doesn't get cleared
until next hibernation or any other similar operation. So for hibernation
cancellation this patch isn't required. I'll drop it.
But shouldn't this wakeup event be consumed without waiting for next hibernation
(or similar operation to happen)?
[1] 56a232d93cea ("PM: sleep: Make pm_wakeup_clear() call more clear") - Aug 20
[2] 79816d4b9e9b ("Revert "PM: sleep: Make pm_wakeup_clear() call more clear"") - Oct 22
---
Thanks,
Usama
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Romain Gantois @ 2025-11-25 8:49 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Guenter Roeck, Thomas Petazzoni, linux-kernel,
devicetree, linux-iio, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Peter Rosin, Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich,
Kevin Tsai, Linus Walleij, Dmitry Torokhov, Eugen Hristev,
Vinod Koul, Kishon Vijay Abraham I, Sebastian Reichel,
Chen-Yu Tsai, Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <732D3F12-0361-4800-8981-EF629B4C491F@goldelico.com>
[-- Attachment #1: Type: text/plain, Size: 4139 bytes --]
Re-sending this because my mailer messed up the formatting on the first try...
Sorry if you're receiving this twice.
On Monday, 24 November 2025 17:19:45 CET H. Nikolaus Schaller wrote:
...
> > The LTM8054's feedback pin can be driven by a different DAC, which allows
> > for dynamic output voltage control. This is a more complex upstreaming
> > topic however, so I've left it out of this initial series. There are
> > other component functions which fit in squarely into the regulator
> > framework, such as input current limit control and soft-start. But I
> > understand that the current driver might look a bit "bare".
>
> So you just want to have some user-space mechanism to control voltage
> and current limits? Can't this be done by directly controlling them through
> the iio API?
>
> Is this for a device that is already in kernel or planned to be supported?
> Or is it "application support" for some SBC?
>
This is planned support for a voltage regulator chip.
> Are you looking for a virtual "glue" driver to logically combine several low
> level functions?
>
I'm looking for a clean userspace abstraction for this component, the low-
level functions in this case are those of a voltage regulator.
> > > What could be necessary is if you really want to be able to "regulate"
> > > the current going to Vout, some bridge between regulator API and some
> > > IIO DAC.
> > >
> > > And enabling/disabling the regulator by some GPIO can be described in
> > > the DT already through a "regulator-fixed".
> >
> > This is a possibility, but when you bring in all of these other hardware
> > functions that I mentionned e.g. output voltage control and stepping,
> > you'll end up with several different devices which look unrelated from
> > userspace, but actually control the same chip.
>
> That is quite usual... I have often heard: user space must fix this as
> kernel just provides basic functions in a harmonized way and integration
> has to be tailored to the device anyways :)
>
IMHO this is not integration, it's BSP work. As far as regulator functions are
concerned, the current status quo is that the kernel handles getting/setting
voltage levels, applying current and voltage constraints and other basic
regulator features.
> > Userspace will also have to know about some hardware details to properly
> > control the DACs, such as the values of the sense and feedback resistors.
> > In my opinion, this bypasses the kernel's abstraction of hardware.
>
> I came up with this argument several times in the part and got a lot of
> contrary :)
>
> What I still wonder: does your hardware warrant an upstream driver for a
> non-programable chip if a different solution (with help of user-space)
> already exist?
>
A different solution does not currently exist (although a userspace-based
solution could be designed). I just think that a kernel-based solution is more
desirable here.
> Another question: is your scheme generic enough so that it can be expected
> that other devices are using it in the same way?
>
Yes, the LTM8054 has a fairly common design as far as buck-boost chips go.
Things like feedback dividers on the output voltage pin are standard practice.
And since the driver doesn't rely on a particular way of integrating the
LTM8054 with other components, it can be reused wherever the same regulator
chip is used.
> Or could the power controller framework (/sys/class/power_supply) fit
> better?
>
I don't think the power supply abstraction is relevant here. The LTM8054 is a
voltage regulator, it doesn't have charge, capacity, temperature monitoring,
power limitation, or other power supply class features.
> There is an API to ask chargers etc. for battery voltage and current limits
> or even write them.
>
> There is also "generic-adc-battery" which allows to hook up with arbitrary
> iio-adcs for measurements - although you need a DAC in your setup. Maybe an
> extension here is a better strategy than a dedicated ltm8054 driver?
What if the LTM8054 is not used to supply a battery?
Thanks,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Romain Gantois @ 2025-11-25 8:41 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Guenter Roeck, Thomas Petazzoni, linux-kernel,
devicetree, linux-iio, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Peter Rosin, Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich,
Kevin Tsai, Linus Walleij, Dmitry Torokhov, Eugen Hristev,
Vinod Koul, Kishon Vijay Abraham I, Sebastian Reichel,
Chen-Yu Tsai, Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <732D3F12-0361-4800-8981-EF629B4C491F@goldelico.com>
[-- Attachment #1.1: Type: text/plain, Size: 3337 bytes --]
On Monday, 24 November 2025 17:19:45 CET H. Nikolaus Schaller wrote:
...
> > The LTM8054's feedback pin can be driven by a different DAC, which allows
> > for dynamic output voltage control. This is a more complex upstreaming
> > topic however, so I've left it out of this initial series. There are
> > other component functions which fit in squarely into the regulator
> > framework, such as input current limit control and soft-start. But I
> > understand that the current driver might look a bit "bare".
>
> So you just want to have some user-space mechanism to control voltage
> and current limits? Can't this be done by directly controlling them through
> the iio API?
>
> Is this for a device that is already in kernel or planned to be supported?
> Or is it "application support" for some SBC?
>
This is planned support for a voltage regulator chip.
> Are you looking for a virtual "glue" driver to logically combine several low
> level functions?
>
I'm looking for a clean userspace abstraction for this component, the low-
level functions in this case are those of a voltage regulator.
> > > What could be necessary is if you really want to be able to "regulate"
> > > the current going to Vout, some bridge between regulator API and some
> > > IIO DAC.
> > >
> > > And enabling/disabling the regulator by some GPIO can be described in
> > > the DT already through a "regulator-fixed".
> >
> > This is a possibility, but when you bring in all of these other hardware
> > functions that I mentionned e.g. output voltage control and stepping,
> > you'll end up with several different devices which look unrelated from
> > userspace, but actually control the same chip.
>
> That is quite usual... I have often heard: user space must fix this as
> kernel just provides basic functions in a harmonized way and integration
> has to be tailored to the device anyways :)
>
IMHO this is not integration, it's BSP work. As far as regulator functions are
concerned, the current status quo is that the kernel handles getting/setting
voltage levels, applying current and voltage constraints and other basic
regulator features.
> > Userspace will also have to know about some hardware details to properly
> > control the DACs, such as the values of the sense and feedback resistors.
> > In my opinion, this bypasses the kernel's abstraction of hardware.
>
> I came up with this argument several times in the part and got a lot of
> contrary :)
>
> What I still wonder: does your hardware warrant an upstream driver for a
> non-programable chip if a different solution (with help of user-space)
> already exist?
>
A different solution does not currently exist (although a userspace-based
solution could be designed). I just think that a kernel-based solution is more
desirable here.
> Another question: is your scheme generic enough so that it can be expected
> that other devices are using it in the same way?
>
Yes, the LTM8054 has a fairly common design as far as buck-boost chips go.
Things like feedback dividers on the output voltage pin are standard practice.
And since the driver doesn't rely on a particular way of integrating the
LTM8054 with other components, it can be reused wherever the same regulator
chip is used.
> Or could the power controller framework (/sys/class/power_supply) fit
> better?
>
[-- Attachment #1.2: Type: text/html, Size: 10604 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] Input: i8042 - add TUXEDO InfinityBook Max Gen10 AMD to i8042 quirk table
From: Werner Sembach @ 2025-11-24 20:31 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Christoffer Sandberg, Werner Sembach, linux-input, linux-kernel
From: Christoffer Sandberg <cs@tuxedo.de>
The device occasionally wakes up from suspend with missing input on the
internal keyboard and the following suspend attempt results in an instant
wake-up. The quirks fix both issues for this device.
Signed-off-by: Christoffer Sandberg <cs@tuxedo.de>
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Cc: stable@vger.kernel.org
---
drivers/input/serio/i8042-acpipnpio.h | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/input/serio/i8042-acpipnpio.h b/drivers/input/serio/i8042-acpipnpio.h
index 1caa6c4ca435c..654771275ce87 100644
--- a/drivers/input/serio/i8042-acpipnpio.h
+++ b/drivers/input/serio/i8042-acpipnpio.h
@@ -1169,6 +1169,13 @@ static const struct dmi_system_id i8042_dmi_quirk_table[] __initconst = {
.driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
},
+ {
+ .matches = {
+ DMI_MATCH(DMI_BOARD_NAME, "X5KK45xS_X5SP45xS"),
+ },
+ .driver_data = (void *)(SERIO_QUIRK_NOMUX | SERIO_QUIRK_RESET_ALWAYS |
+ SERIO_QUIRK_NOLOOP | SERIO_QUIRK_NOPNP)
+ },
/*
* A lot of modern Clevo barebones have touchpad and/or keyboard issues
* after suspend fixable with the forcenorestore quirk.
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 4/4] PM: sleep: clear pm_abort_suspend at suspend
From: Rafael J. Wysocki @ 2025-11-24 18:54 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <20251107184438.1328717-5-usama.anjum@collabora.com>
On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
<usama.anjum@collabora.com> wrote:
>
> Clear pm_abort_suspend counter in case a wakeup is detected during
> hibernation process. If this counter isn't reset, it'll affect the
> next hibernation cycle and next time hibernation will not happen as
> pm_abort_suspend is still positive.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> ---
> drivers/base/power/main.c | 2 ++
> kernel/cpu.c | 1 +
> kernel/power/hibernate.c | 5 ++++-
> kernel/power/process.c | 1 +
> 4 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c
> index 5760abb25b591..84e76f8df1e02 100644
> --- a/drivers/base/power/main.c
> +++ b/drivers/base/power/main.c
> @@ -1642,6 +1642,7 @@ static void device_suspend_late(struct device *dev, pm_message_t state, bool asy
> goto Complete;
>
> if (pm_wakeup_pending()) {
> + pm_wakeup_clear(0);
> WRITE_ONCE(async_error, -EBUSY);
> goto Complete;
> }
> @@ -1887,6 +1888,7 @@ static void device_suspend(struct device *dev, pm_message_t state, bool async)
>
> if (pm_wakeup_pending()) {
> dev->power.direct_complete = false;
> + pm_wakeup_clear(0);
> WRITE_ONCE(async_error, -EBUSY);
> goto Complete;
> }
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index db9f6c539b28c..74c9f6b4947dd 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -1921,6 +1921,7 @@ int freeze_secondary_cpus(int primary)
>
> if (pm_wakeup_pending()) {
> pr_info("Wakeup pending. Abort CPU freeze\n");
> + pm_wakeup_clear(0);
> error = -EBUSY;
> break;
> }
> diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c
> index e15907f28c4cd..1f6b60df45d34 100644
> --- a/kernel/power/hibernate.c
> +++ b/kernel/power/hibernate.c
> @@ -349,8 +349,10 @@ static int create_image(int platform_mode)
> goto Enable_irqs;
> }
>
> - if (hibernation_test(TEST_CORE) || pm_wakeup_pending())
> + if (hibernation_test(TEST_CORE) || pm_wakeup_pending()) {
> + pm_wakeup_clear(0);
> goto Power_up;
> + }
>
> in_suspend = 1;
> save_processor_state();
> @@ -660,6 +662,7 @@ int hibernation_platform_enter(void)
> goto Enable_irqs;
>
> if (pm_wakeup_pending()) {
> + pm_wakeup_clear(0);
> error = -EAGAIN;
> goto Power_up;
> }
> diff --git a/kernel/power/process.c b/kernel/power/process.c
> index dc0dfc349f22b..e935b27a04ae0 100644
> --- a/kernel/power/process.c
> +++ b/kernel/power/process.c
> @@ -67,6 +67,7 @@ static int try_to_freeze_tasks(bool user_only)
> break;
>
> if (pm_wakeup_pending()) {
> + pm_wakeup_clear(0);
> wakeup = true;
> break;
> }
> --
I don't think pm_wakeup_clear() needs to be called in so many places.
Any why isn't it sufficient to call it in freeze_processes()? For
suspend, it is sufficient, so what's different about hibernation in
that respect?
^ permalink raw reply
* Re: [PATCH v2 03/12] dt-bindings: net: Convert Marvell 8897/8997 bindings to DT schema
From: Rob Herring @ 2025-11-24 18:54 UTC (permalink / raw)
To: Ariel D'Alessandro
Cc: airlied, amergnat, andrew+netdev, andrew-ct.chen,
angelogioacchino.delregno, broonie, chunkuang.hu, conor+dt, davem,
dmitry.torokhov, edumazet, flora.fu, heiko, houlong.wei, jeesw,
kernel, krzk+dt, kuba, lgirdwood, linus.walleij,
louisalexis.eyraud, luiz.dentz, maarten.lankhorst, marcel,
matthias.bgg, mchehab, minghsiu.tsai, mripard, p.zabel, pabeni,
sean.wang, simona, support.opensource, tiffany.lin, tzimmermann,
yunfei.dong, devicetree, dri-devel, linux-arm-kernel,
linux-bluetooth, linux-gpio, linux-input, linux-kernel,
linux-media, linux-mediatek, linux-rockchip, linux-sound, netdev
In-Reply-To: <fb20e4fe-df0a-4089-a7cf-e82bfe1f8e00@collabora.com>
On Wed, Oct 1, 2025 at 12:28 PM Ariel D'Alessandro
<ariel.dalessandro@collabora.com> wrote:
>
> Rob,
>
> On 9/12/25 11:06 AM, Rob Herring wrote:
> > On Thu, Sep 11, 2025 at 12:09:52PM -0300, Ariel D'Alessandro wrote:
> >> Convert the existing text-based DT bindings for Marvell 8897/8997
> >> (sd8897/sd8997) bluetooth devices controller to a DT schema.
> >>
> >> While here:
> >>
> >> * bindings for "usb1286,204e" (USB interface) are dropped from the DT
> >> schema definition as these are currently documented in file [0].
> >> * DT binding users are updated to use bluetooth generic name
> >> recommendation.
> >>
> >> [0] Documentation/devicetree/bindings/net/btusb.txt
> >>
> >> Signed-off-by: Ariel D'Alessandro <ariel.dalessandro@collabora.com>
> >> ---
> >> .../net/bluetooth/marvell,sd8897-bt.yaml | 79 ++++++++++++++++++
> >> .../devicetree/bindings/net/btusb.txt | 2 +-
> >> .../bindings/net/marvell-bt-8xxx.txt | 83 -------------------
> >
> >> .../dts/rockchip/rk3288-veyron-fievel.dts | 2 +-
> >> .../boot/dts/rockchip/rk3288-veyron-jaq.dts | 2 +-
> >> arch/arm64/boot/dts/mediatek/mt8173-elm.dtsi | 2 +-
> >
> > .dts files should be separate patches. Please send the bindings patches
> > separately per subsystem so subsystem maintainers can apply them. All
> > the Mediatek dts changes can be 1 series.
>
> Ack, will fix in v3.
Are you going to send v3 still?
Rob
^ permalink raw reply
* Re: [PATCH 3/4] Input: Ignore the KEY_POWER events if hibernation is in progress
From: Rafael J. Wysocki @ 2025-11-24 18:50 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <20251107184438.1328717-4-usama.anjum@collabora.com>
On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
<usama.anjum@collabora.com> wrote:
>
> Input (Serio) drivers call input_handle_event(). Although the serio
> drivers have duplicate events, they have separate code path and call
> input_handle_event(). Ignore the KEY_POWER such that this event isn't
> sent to the userspace if hibernation is in progress.
Your change affects suspend too.
Also, what's the goal you want to achieve?
> Abort the hibernation by calling pm_wakeup_dev_event(). In case of serio,
> doesn't have wakeup source registered, this call doesn't do anything.
> But there may be other input drivers which will require this.
>
> Without this, the event is sent to the userspace and it suspends the
> device after hibernation cancellation.
I think that's because user space handles it this way, isn't it?
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> ---
> Changes since RFC:
> - Use pm_sleep_transition_in_progress()
> - Update description
> ---
> drivers/input/input.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index a500e1e276c21..7939bd9e47668 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -26,6 +26,7 @@
> #include <linux/kstrtox.h>
> #include <linux/mutex.h>
> #include <linux/rcupdate.h>
> +#include <linux/suspend.h>
> #include "input-compat.h"
> #include "input-core-private.h"
> #include "input-poller.h"
> @@ -362,6 +363,11 @@ void input_handle_event(struct input_dev *dev,
>
> lockdep_assert_held(&dev->event_lock);
>
> + if (code == KEY_POWER && pm_sleep_transition_in_progress()) {
> + pm_wakeup_dev_event(&dev->dev, 0, true);
> + return;
> + }
> +
> disposition = input_get_disposition(dev, type, code, &value);
> if (disposition != INPUT_IGNORE_EVENT) {
> if (type != EV_SYN)
> --
^ permalink raw reply
* Re: [PATCH 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Rafael J. Wysocki @ 2025-11-24 18:42 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Greg Kroah-Hartman,
Danilo Krummrich, Dmitry Torokhov, Thomas Gleixner,
Peter Zijlstra, linux-acpi, linux-kernel, linux-pm, linux-input,
kernel, superm1
In-Reply-To: <20251107184438.1328717-3-usama.anjum@collabora.com>
On Fri, Nov 7, 2025 at 7:45 PM Muhammad Usama Anjum
<usama.anjum@collabora.com> wrote:
>
> acpi_pm_wakeup_event() is called from acpi_button_notify() which is
> called when power button is pressed. The system is worken up from s2idle
> in this case by setting hard parameter to pm_wakeup_dev_event().
Right, so presumably you want to set it for hibernation too.
> Call acpi_pm_wakeup_event() if power button is pressed and hibernation
> is in progress.
Well, this is not what the code does after the change.
> Set the hard parameter such that pm_system_wakeup()
> gets called which increments pm_abort_suspend counter. The explicit call
> to acpi_pm_wakeup_event() is necessary as ACPI button device has the
> wakeup source. Hence call to input_report_key() with input device
> doesn't call pm_system_wakeup() as it doesn't have wakeup source
> registered.
>
> Hence hibernation would be cancelled as in hibernation path, this counter
> is checked if it should be aborted.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> ---
> Changes since RFC:
> - Use pm_sleep_transition_in_progress()
> - Update descriptin why explicit call to acpi_pm_wakeup_event() is
> necessary
> ---
> drivers/acpi/button.c | 12 +++++++++---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
> index 3c6dd9b4ba0ad..e4be5c763edaf 100644
> --- a/drivers/acpi/button.c
> +++ b/drivers/acpi/button.c
> @@ -20,6 +20,7 @@
> #include <linux/acpi.h>
> #include <linux/dmi.h>
> #include <acpi/button.h>
> +#include <linux/suspend.h>
>
> #define ACPI_BUTTON_CLASS "button"
> #define ACPI_BUTTON_FILE_STATE "state"
> @@ -458,11 +459,16 @@ static void acpi_button_notify(acpi_handle handle, u32 event, void *data)
> acpi_pm_wakeup_event(&device->dev);
The above is what you want to change, as this already reports the
event. Reporting it twice is unnecessary and potentially confusing.
> button = acpi_driver_data(device);
> - if (button->suspended || event == ACPI_BUTTON_NOTIFY_WAKE)
> - return;
> -
> input = button->input;
> keycode = test_bit(KEY_SLEEP, input->keybit) ? KEY_SLEEP : KEY_POWER;
> + if (event == ACPI_BUTTON_NOTIFY_STATUS && keycode == KEY_POWER &&
> + pm_sleep_transition_in_progress()) {
> + pm_wakeup_dev_event(&device->dev, 0, true);
> + return;
> + }
First, this will affect suspend too.
Second, this reports an already reported wakeup event.
Next, why KEY_POWER only? Is KEY_SLEEP not expected to wake up?
And why event == ACPI_BUTTON_NOTIFY_STATUS? Isn't this what
ACPI_BUTTON_NOTIFY_WAKE is for?
> +
> + if (button->suspended || event == ACPI_BUTTON_NOTIFY_WAKE)
> + return;
>
> input_report_key(input, keycode, 1);
> input_sync(input);
> --
^ permalink raw reply
* Re: [PATCH v3 1/4] firmware_loader: expand firmware error codes with up-to-date error
From: Russ Weight @ 2025-11-24 17:45 UTC (permalink / raw)
To: Marco Felsch
Cc: Konstantin Ryabitsev, Rob Herring, Conor Dooley, Henrik Rydberg,
Kamel Bouhara, Rafael J. Wysocki, devicetree, Greg Kroah-Hartman,
Dmitry Torokhov, linux-kernel, Luis Chamberlain, Marco Felsch,
linux-input, Andrew Morton, Krzysztof Kozlowski, Danilo Krummrich
In-Reply-To: <20251121140052.f5ry3jljvyg24smn@pengutronix.de>
On Fri, Nov 21, 2025 at 03:00:52PM +0100, Marco Felsch wrote:
> Hi Russ,
>
> On 25-11-19, Konstantin Ryabitsev wrote:
> > On Wed, Nov 19, 2025 at 11:10:07AM +0100, Marco Felsch wrote:
> > > > Marco - I would recommend adding the Reviewed-by tags that you
> > > > have received and then resubmitting the patch.
> > >
> > > I can do this albeit I thought this will be collected autom. by b4.
> >
> > You have to run `b4 trailers -u` for it to be collected.
>
> Is this okay to run it on your site or do I have to add and resend it?
My role is primarily code reviews - I'm not the person who would
pull the patch in to a testing branch. I would recommend adding
the tags and resubmitting.
>
> Regards,
> Marco
>
> >
> > -K
> >
>
> --
> #gernperDu
> #CallMeByMyFirstName
>
> Pengutronix e.K. | |
> Steuerwalder Str. 21 | https://www.pengutronix.de/ |
> 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-9 |
^ permalink raw reply
* Re: [PATCH 2/4] ACPI: button: Cancel hibernation if button is pressed during hibernation
From: Greg Kroah-Hartman @ 2025-11-24 17:03 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Danilo Krummrich,
Dmitry Torokhov, Thomas Gleixner, Peter Zijlstra, linux-acpi,
linux-kernel, linux-pm, linux-input, kernel, superm1
In-Reply-To: <20251107184438.1328717-3-usama.anjum@collabora.com>
On Fri, Nov 07, 2025 at 11:44:29PM +0500, Muhammad Usama Anjum wrote:
> acpi_pm_wakeup_event() is called from acpi_button_notify() which is
> called when power button is pressed. The system is worken up from s2idle
> in this case by setting hard parameter to pm_wakeup_dev_event().
>
> Call acpi_pm_wakeup_event() if power button is pressed and hibernation
> is in progress. Set the hard parameter such that pm_system_wakeup()
> gets called which increments pm_abort_suspend counter. The explicit call
> to acpi_pm_wakeup_event() is necessary as ACPI button device has the
> wakeup source. Hence call to input_report_key() with input device
> doesn't call pm_system_wakeup() as it doesn't have wakeup source
> registered.
>
> Hence hibernation would be cancelled as in hibernation path, this counter
> is checked if it should be aborted.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
This could be dangerous, as this is not what happens today, are you sure
that people aren't just used to pressing the button multiple times until
the system is hibernated? If so, that would now break with this change
as it's hard to determine what is going on.
And why does hibernate take so long? Why not fix that up instead?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/4] PM: hibernate: export pm_sleep_transition_in_progress()
From: Greg Kroah-Hartman @ 2025-11-24 17:01 UTC (permalink / raw)
To: Muhammad Usama Anjum
Cc: Rafael J. Wysocki, Len Brown, Pavel Machek, Danilo Krummrich,
Dmitry Torokhov, Thomas Gleixner, Peter Zijlstra, linux-acpi,
linux-kernel, linux-pm, linux-input, kernel, superm1
In-Reply-To: <20251107184438.1328717-2-usama.anjum@collabora.com>
On Fri, Nov 07, 2025 at 11:44:28PM +0500, Muhammad Usama Anjum wrote:
> Export pm_sleep_transition_in_progress() to be used by other
> modules.
>
> Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com>
> ---
> kernel/power/main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index 33a47ed15994f..ff3354b5be150 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -570,6 +570,7 @@ bool pm_sleep_transition_in_progress(void)
> {
> return pm_suspend_in_progress() || hibernation_in_progress();
> }
> +EXPORT_SYMBOL_GPL(pm_sleep_transition_in_progress);
The problem is, you can not rely on the result of this call as it could
change right after you call it, right?
So who needs to call this and why? What new workflow requires this?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: H. Nikolaus Schaller @ 2025-11-24 16:19 UTC (permalink / raw)
To: Romain Gantois
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Guenter Roeck, Thomas Petazzoni, linux-kernel,
devicetree, linux-iio, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Peter Rosin, Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich,
Kevin Tsai, Linus Walleij, Dmitry Torokhov, Eugen Hristev,
Vinod Koul, Kishon Vijay Abraham I, Sebastian Reichel,
Chen-Yu Tsai, Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <4053840.MHq7AAxBmi@fw-rgant>
Hi,
> Am 24.11.2025 um 16:57 schrieb Romain Gantois <romain.gantois@bootlin.com>:
>
> Hi Nikolaus,
>
> On Monday, 24 November 2025 16:35:28 CET H. Nikolaus Schaller wrote:
> ...
> > > Sorry, I don't quite understand your remark. To integrate this voltage
> > > regulator component into the Linux regulator abstraction, I'm providing a
> > > current limit control function. To provide such a function, the voltage
> > > level on a pin has to be controlled. AFAIK, the kernel abstraction used
> > > to set precise voltages on lines is an IO channel.
> >
> > I was curious to learn about this topic and looked into the data sheet:
> >
> > https://www.analog.com/media/en/technical-documentation/data-sheets/8054fa.p
> > df
> >
> > As far as I see the LTM8054 does not even have a programming interface.
> > So is it reasonable to provide a dedicated driver at all?
> >
> > The figure on page 20 seems to suggest that there is an external DAC
> > which drives the regulator. And the regulator drives for example a fan.
> >
> > So I would think of a driver for the specific DAC and ignore the specific
> > LTM chip at all.
> >
>
> In my use case, the LTM8054 feeds a DC output port on which various devices
> may be plugged. Dynamic output current limitation and output voltage level
> control for these devices is a requirement, as well as stepped voltage
> transitions, thus the need for a proper regulator device.
>
> The LTM8054's feedback pin can be driven by a different DAC, which allows for
> dynamic output voltage control. This is a more complex upstreaming topic
> however, so I've left it out of this initial series. There are other component
> functions which fit in squarely into the regulator framework, such as
> input current limit control and soft-start. But I understand that the current
> driver might look a bit "bare".
So you just want to have some user-space mechanism to control voltage
and current limits? Can't this be done by directly controlling them through
the iio API?
Is this for a device that is already in kernel or planned to be supported?
Or is it "application support" for some SBC?
Are you looking for a virtual "glue" driver to logically combine several low
level functions?
>
> > What could be necessary is if you really want to be able to "regulate"
> > the current going to Vout, some bridge between regulator API and some
> > IIO DAC.
> >
> > And enabling/disabling the regulator by some GPIO can be described in
> > the DT already through a "regulator-fixed".
> >
>
> This is a possibility, but when you bring in all of these other hardware
> functions that I mentionned e.g. output voltage control and stepping, you'll
> end up with several different devices which look unrelated from userspace, but
> actually control the same chip.
That is quite usual... I have often heard: user space must fix this as kernel
just provides basic functions in a harmonized way and integration has to
be tailored to the device anyways :)
> Userspace will also have to know about some hardware details to properly
> control the DACs, such as the values of the sense and feedback resistors. In
> my opinion, this bypasses the kernel's abstraction of hardware.
I came up with this argument several times in the part and got a lot of contrary :)
What I still wonder: does your hardware warrant an upstream driver for a
non-programable chip if a different solution (with help of user-space) already
exist?
Another question: is your scheme generic enough so that it can be expected
that other devices are using it in the same way?
Or could the power controller framework (/sys/class/power_supply) fit better?
There is an API to ask chargers etc. for battery voltage and current limits or
even write them.
There is also "generic-adc-battery" which allows to hook up with arbitrary
iio-adcs for measurements - although you need a DAC in your setup. Maybe an
extension here is a better strategy than a dedicated ltm8054 driver?
BR,
Nikolaus
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Romain Gantois @ 2025-11-24 16:02 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Guenter Roeck
Cc: Thomas Petazzoni, linux-kernel, devicetree, linux-iio,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Peter Rosin,
Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich, Kevin Tsai,
Linus Walleij, Dmitry Torokhov, Eugen Hristev, Vinod Koul,
Kishon Vijay Abraham I, Sebastian Reichel, Chen-Yu Tsai,
Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <da5457ea-c1ed-4c90-8743-fc982a02ed88@roeck-us.net>
[-- Attachment #1.1: Type: text/plain, Size: 1238 bytes --]
On Monday, 24 November 2025 16:40:37 CET Guenter Roeck wrote:
...
> >
> > Do you think that using the IIO consumer API is not correct here? What
> > other
> >
> > method do you think I should use?
>
> Ok, I had a look into the datasheet. Unless I am missing something, the chip
> doesn't have a digital control or monitoring interface such as I2C or SPI.
>
> At the same time, you copied the hardware monitoring mailing list on this
> summary and on (at least) one of the patches, but apparently not on all of
> them. This lead to my apparently wrong assumption that iio is used to
> monitor (not [just] control) something on the chip. I wrongly assumed that
> IIO is used to report chip status (voltage, current, temperature) using an
> internal DAC. Obviously that was a wrong assumption. Sorry for that.
>
> Apparently you copied the hwmon mailing list for the introduction of an IIO
> namespace and its use in a couple of hwmon drivers in one of the patches.
> My personal opinion is that this should not be part of this series but a
> series of its own. That is just my personal opinion, though.
I understand. I can split it out.
Thanks,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: Type: text/html, Size: 3516 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Romain Gantois @ 2025-11-24 15:57 UTC (permalink / raw)
To: H. Nikolaus Schaller
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Guenter Roeck, Thomas Petazzoni, linux-kernel,
devicetree, linux-iio, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Peter Rosin, Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich,
Kevin Tsai, Linus Walleij, Dmitry Torokhov, Eugen Hristev,
Vinod Koul, Kishon Vijay Abraham I, Sebastian Reichel,
Chen-Yu Tsai, Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <563331EB-2460-4CF5-87B3-5FE60B18BB70@goldelico.com>
[-- Attachment #1.1: Type: text/plain, Size: 2557 bytes --]
Hi Nikolaus,
On Monday, 24 November 2025 16:35:28 CET H. Nikolaus Schaller wrote:
...
> > Sorry, I don't quite understand your remark. To integrate this voltage
> > regulator component into the Linux regulator abstraction, I'm providing a
> > current limit control function. To provide such a function, the voltage
> > level on a pin has to be controlled. AFAIK, the kernel abstraction used
> > to set precise voltages on lines is an IO channel.
>
> I was curious to learn about this topic and looked into the data sheet:
>
> https://www.analog.com/media/en/technical-documentation/data-sheets/8054fa.p
> df
>
> As far as I see the LTM8054 does not even have a programming interface.
> So is it reasonable to provide a dedicated driver at all?
>
> The figure on page 20 seems to suggest that there is an external DAC
> which drives the regulator. And the regulator drives for example a fan.
>
> So I would think of a driver for the specific DAC and ignore the specific
> LTM chip at all.
>
In my use case, the LTM8054 feeds a DC output port on which various devices
may be plugged. Dynamic output current limitation and output voltage level
control for these devices is a requirement, as well as stepped voltage
transitions, thus the need for a proper regulator device.
The LTM8054's feedback pin can be driven by a different DAC, which allows for
dynamic output voltage control. This is a more complex upstreaming topic
however, so I've left it out of this initial series. There are other component
functions which fit in squarely into the regulator framework, such as
input current limit control and soft-start. But I understand that the current
driver might look a bit "bare".
> What could be necessary is if you really want to be able to "regulate"
> the current going to Vout, some bridge between regulator API and some
> IIO DAC.
>
> And enabling/disabling the regulator by some GPIO can be described in
> the DT already through a "regulator-fixed".
>
This is a possibility, but when you bring in all of these other hardware
functions that I mentionned e.g. output voltage control and stepping, you'll
end up with several different devices which look unrelated from userspace, but
actually control the same chip.
Userspace will also have to know about some hardware details to properly
control the DACs, such as the values of the sense and feedback resistors. In
my opinion, this bypasses the kernel's abstraction of hardware.
Thanks,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: Type: text/html, Size: 6687 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: H. Nikolaus Schaller @ 2025-11-24 15:35 UTC (permalink / raw)
To: Romain Gantois
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Guenter Roeck, Thomas Petazzoni, linux-kernel,
devicetree, linux-iio, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Peter Rosin, Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich,
Kevin Tsai, Linus Walleij, Dmitry Torokhov, Eugen Hristev,
Vinod Koul, Kishon Vijay Abraham I, Sebastian Reichel,
Chen-Yu Tsai, Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <23111366.EfDdHjke4D@fw-rgant>
Hi
> Am 24.11.2025 um 16:13 schrieb Romain Gantois <romain.gantois@bootlin.com>:
>
> Hello Guenter,
>
> On Monday, 24 November 2025 15:57:41 CET Guenter Roeck wrote:
> > On 11/24/25 06:48, Romain Gantois wrote:
> > > Hello everyone,
> > >
> > > This is version four of my series which adds initial support of the Linear
> > > Technology LTM8054 voltage regulator. The driver supports a fixed voltage
> > > and a tunable output current limit using a DAC-controlled pin.
> > >
> > > I'd say that the most unusual part of this series is the usage of the IIO
> > > consumer API in a regulator driver. I think this makes sense here, since
> > > the regulator driver has to access a DAC to read/set the output current
> > > limit.
> >
> > I don't think that is a valid reason. Literally every driver measuring
> > voltages or current uses a DAC to do it. How else would one convert an
> > analog value into a digital value ?
>
> Sorry, I don't quite understand your remark. To integrate this voltage
> regulator component into the Linux regulator abstraction, I'm providing a
> current limit control function. To provide such a function, the voltage level
> on a pin has to be controlled. AFAIK, the kernel abstraction used to set
> precise voltages on lines is an IO channel.
I was curious to learn about this topic and looked into the data sheet:
https://www.analog.com/media/en/technical-documentation/data-sheets/8054fa.pdf
As far as I see the LTM8054 does not even have a programming interface.
So is it reasonable to provide a dedicated driver at all?
The figure on page 20 seems to suggest that there is an external DAC
which drives the regulator. And the regulator drives for example a fan.
So I would think of a driver for the specific DAC and ignore the specific
LTM chip at all.
What could be necessary is if you really want to be able to "regulate"
the current going to Vout, some bridge between regulator API and some
IIO DAC.
And enabling/disabling the regulator by some GPIO can be described in
the DT already through a "regulator-fixed".
But this are just my first thoughts as I have not been following this
topic before. Hope it helps.
BR,
Nikolaus
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Guenter Roeck @ 2025-11-24 15:40 UTC (permalink / raw)
To: Romain Gantois, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Thomas Petazzoni, linux-kernel, devicetree, linux-iio,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Peter Rosin,
Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich, Kevin Tsai,
Linus Walleij, Dmitry Torokhov, Eugen Hristev, Vinod Koul,
Kishon Vijay Abraham I, Sebastian Reichel, Chen-Yu Tsai,
Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <23111366.EfDdHjke4D@fw-rgant>
On 11/24/25 07:13, Romain Gantois wrote:
> Hello Guenter,
>
>
> On Monday, 24 November 2025 15:57:41 CET Guenter Roeck wrote:
>
> > On 11/24/25 06:48, Romain Gantois wrote:
>
> > > Hello everyone,
>
> > >
>
> > > This is version four of my series which adds initial support of the Linear
>
> > > Technology LTM8054 voltage regulator. The driver supports a fixed voltage
>
> > > and a tunable output current limit using a DAC-controlled pin.
>
> > >
>
> > > I'd say that the most unusual part of this series is the usage of the IIO
>
> > > consumer API in a regulator driver. I think this makes sense here, since
>
> > > the regulator driver has to access a DAC to read/set the output current
>
> > > limit.
>
> >
>
> > I don't think that is a valid reason. Literally every driver measuring
>
> > voltages or current uses a DAC to do it. How else would one convert an
>
> > analog value into a digital value ?
>
>
> Sorry, I don't quite understand your remark. To integrate this voltage
>
> regulator component into the Linux regulator abstraction, I'm providing a
>
> current limit control function. To provide such a function, the voltage level
>
> on a pin has to be controlled. AFAIK, the kernel abstraction used to set
>
> precise voltages on lines is an IO channel.
>
>
> Do you think that using the IIO consumer API is not correct here? What other
>
> method do you think I should use?
>
Ok, I had a look into the datasheet. Unless I am missing something, the chip doesn't
have a digital control or monitoring interface such as I2C or SPI.
At the same time, you copied the hardware monitoring mailing list on this summary and
on (at least) one of the patches, but apparently not on all of them. This lead to my
apparently wrong assumption that iio is used to monitor (not [just] control) something
on the chip. I wrongly assumed that IIO is used to report chip status (voltage, current,
temperature) using an internal DAC. Obviously that was a wrong assumption.
Sorry for that.
Apparently you copied the hwmon mailing list for the introduction of an IIO namespace
and its use in a couple of hwmon drivers in one of the patches. My personal opinion
is that this should not be part of this series but a series of its own. That is just
my personal opinion, though.
Guenter
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Romain Gantois @ 2025-11-24 15:13 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Guenter Roeck
Cc: Thomas Petazzoni, linux-kernel, devicetree, linux-iio,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Peter Rosin,
Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich, Kevin Tsai,
Linus Walleij, Dmitry Torokhov, Eugen Hristev, Vinod Koul,
Kishon Vijay Abraham I, Sebastian Reichel, Chen-Yu Tsai,
Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <24527d76-4f6a-4008-a369-23510d492a94@roeck-us.net>
[-- Attachment #1.1: Type: text/plain, Size: 1359 bytes --]
Hello Guenter,
On Monday, 24 November 2025 15:57:41 CET Guenter Roeck wrote:
> On 11/24/25 06:48, Romain Gantois wrote:
> > Hello everyone,
> >
> > This is version four of my series which adds initial support of the Linear
> > Technology LTM8054 voltage regulator. The driver supports a fixed voltage
> > and a tunable output current limit using a DAC-controlled pin.
> >
> > I'd say that the most unusual part of this series is the usage of the IIO
> > consumer API in a regulator driver. I think this makes sense here, since
> > the regulator driver has to access a DAC to read/set the output current
> > limit.
>
> I don't think that is a valid reason. Literally every driver measuring
> voltages or current uses a DAC to do it. How else would one convert an
> analog value into a digital value ?
Sorry, I don't quite understand your remark. To integrate this voltage
regulator component into the Linux regulator abstraction, I'm providing a
current limit control function. To provide such a function, the voltage level
on a pin has to be controlled. AFAIK, the kernel abstraction used to set
precise voltages on lines is an IO channel.
Do you think that using the IIO consumer API is not correct here? What other
method do you think I should use?
Thanks,
--
Romain Gantois, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
[-- Attachment #1.2: Type: text/html, Size: 3721 bytes --]
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Andy Shevchenko @ 2025-11-24 15:07 UTC (permalink / raw)
To: Guenter Roeck
Cc: Romain Gantois, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Thomas Petazzoni,
linux-kernel, devicetree, linux-iio, Conor Dooley, MyungJoo Ham,
Chanwoo Choi, Peter Rosin, Mariel Tinaco, Lars-Peter Clausen,
Michael Hennerich, Kevin Tsai, Linus Walleij, Dmitry Torokhov,
Eugen Hristev, Vinod Koul, Kishon Vijay Abraham I,
Sebastian Reichel, Chen-Yu Tsai, Support Opensource,
Paul Cercueil, Iskren Chernev, Marek Szyprowski, Matheus Castello,
Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
Casey Connolly, Pali Rohár, Orson Zhai, Baolin Wang,
Chunyan Zhang, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Claudiu Beznea,
Jaroslav Kysela, Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32
In-Reply-To: <24527d76-4f6a-4008-a369-23510d492a94@roeck-us.net>
On Mon, Nov 24, 2025 at 06:57:41AM -0800, Guenter Roeck wrote:
> On 11/24/25 06:48, Romain Gantois wrote:
> >
> > This is version four of my series which adds initial support of the Linear
> > Technology LTM8054 voltage regulator. The driver supports a fixed voltage
> > and a tunable output current limit using a DAC-controlled pin.
> >
> > I'd say that the most unusual part of this series is the usage of the IIO
> > consumer API in a regulator driver. I think this makes sense here, since
> > the regulator driver has to access a DAC to read/set the output current
> > limit.
>
> I don't think that is a valid reason. Literally every driver measuring voltages
> or current uses a DAC to do it. How else would one convert an analog value
> into a digital value ?
While I'm not objecting your vision on this, the ADC is also possible to use to
"measure" the analog signal. DAC approach IIRC considered cheaper solution, but
require an analogue comparator.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Guenter Roeck @ 2025-11-24 14:57 UTC (permalink / raw)
To: Romain Gantois, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko
Cc: Thomas Petazzoni, linux-kernel, devicetree, linux-iio,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Peter Rosin,
Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich, Kevin Tsai,
Linus Walleij, Dmitry Torokhov, Eugen Hristev, Vinod Koul,
Kishon Vijay Abraham I, Sebastian Reichel, Chen-Yu Tsai,
Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
In-Reply-To: <20251124-ltm8054-driver-v4-0-107a8a814abe@bootlin.com>
On 11/24/25 06:48, Romain Gantois wrote:
> Hello everyone,
>
> This is version four of my series which adds initial support of the Linear
> Technology LTM8054 voltage regulator. The driver supports a fixed voltage
> and a tunable output current limit using a DAC-controlled pin.
>
> I'd say that the most unusual part of this series is the usage of the IIO
> consumer API in a regulator driver. I think this makes sense here, since
> the regulator driver has to access a DAC to read/set the output current
> limit.
>
I don't think that is a valid reason. Literally every driver measuring voltages
or current uses a DAC to do it. How else would one convert an analog value
into a digital value ?
Guenter
^ permalink raw reply
* [PATCH v4 2/6] iio: inkern: Use namespaced exports
From: Romain Gantois @ 2025-11-24 14:48 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko
Cc: Thomas Petazzoni, linux-kernel, devicetree, linux-iio,
Romain Gantois, MyungJoo Ham, Chanwoo Choi, Guenter Roeck,
Peter Rosin, Mariel Tinaco, Lars-Peter Clausen, Michael Hennerich,
Kevin Tsai, Linus Walleij, Dmitry Torokhov, Eugen Hristev,
Vinod Koul, Kishon Vijay Abraham I, Sebastian Reichel,
Chen-Yu Tsai, Support Opensource, Paul Cercueil, Iskren Chernev,
Marek Szyprowski, Matheus Castello, Saravanan Sekar,
Matthias Brugger, AngeloGioacchino Del Regno, Casey Connolly,
Pali Rohár, Orson Zhai, Baolin Wang, Chunyan Zhang,
Amit Kucheria, Thara Gopinath, Rafael J. Wysocki, Daniel Lezcano,
Zhang Rui, Lukasz Luba, Claudiu Beznea, Jaroslav Kysela,
Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32
In-Reply-To: <20251124-ltm8054-driver-v4-0-107a8a814abe@bootlin.com>
Use namespaced exports for IIO consumer API functions.
To: MyungJoo Ham <myungjoo.ham@samsung.com>
To: Chanwoo Choi <cw00.choi@samsung.com>
To: Guenter Roeck <linux@roeck-us.net>
To: Peter Rosin <peda@axentia.se>
To: David Lechner <dlechner@baylibre.com>
To: Mariel Tinaco <Mariel.Tinaco@analog.com>
To: Lars-Peter Clausen <lars@metafoo.de>
To: Michael Hennerich <Michael.Hennerich@analog.com>
To: Kevin Tsai <ktsai@capellamicro.com>
To: Linus Walleij <linus.walleij@linaro.org>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Eugen Hristev <eugen.hristev@linaro.org>
To: Vinod Koul <vkoul@kernel.org>
To: Kishon Vijay Abraham I <kishon@kernel.org>
To: Sebastian Reichel <sre@kernel.org>
To: Chen-Yu Tsai <wens@csie.org>
To: Support Opensource <support.opensource@diasemi.com>
To: Paul Cercueil <paul@crapouillou.net>
To: Iskren Chernev <me@iskren.info>
To: Marek Szyprowski <m.szyprowski@samsung.com>
To: Matheus Castello <matheus@castello.eng.br>
To: Saravanan Sekar <sravanhome@gmail.com>
To: Matthias Brugger <matthias.bgg@gmail.com>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
To: Casey Connolly <casey.connolly@linaro.org>
To: "Pali Rohár" <pali@kernel.org>
To: Orson Zhai <orsonzhai@gmail.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Chunyan Zhang <zhang.lyra@gmail.com>
To: Amit Kucheria <amitk@kernel.org>
To: Thara Gopinath <thara.gopinath@gmail.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Zhang Rui <rui.zhang@intel.com>
To: Lukasz Luba <lukasz.luba@arm.com>
To: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>
To: Jaroslav Kysela <perex@perex.cz>
To: Takashi Iwai <tiwai@suse.com>
To: Sylwester Nawrocki <s.nawrocki@samsung.com>
To: Olivier Moysan <olivier.moysan@foss.st.com>
To: Arnaud Pouliquen <arnaud.pouliquen@foss.st.com>
To: Maxime Coquelin <mcoquelin.stm32@gmail.com>
To: Alexandre Torgue <alexandre.torgue@foss.st.com>
To: Dixit Parmar <dixitparmar19@gmail.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-hwmon@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-phy@lists.infradead.org
Cc: linux-pm@vger.kernel.org
Cc: linux-mips@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: linux-sound@vger.kernel.org
Cc: linux-stm32@st-md-mailman.stormreply.com
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
drivers/extcon/extcon-adc-jack.c | 1 +
drivers/hwmon/iio_hwmon.c | 1 +
drivers/hwmon/ntc_thermistor.c | 1 +
drivers/iio/adc/envelope-detector.c | 1 +
drivers/iio/afe/iio-rescale.c | 1 +
drivers/iio/buffer/industrialio-buffer-cb.c | 1 +
drivers/iio/buffer/industrialio-hw-consumer.c | 1 +
drivers/iio/dac/ad8460.c | 1 +
drivers/iio/dac/dpot-dac.c | 1 +
drivers/iio/dac/ds4424.c | 1 +
drivers/iio/inkern.c | 60 ++++++++++++-------------
drivers/iio/light/cm3605.c | 1 +
drivers/iio/light/gp2ap002.c | 1 +
drivers/iio/multiplexer/iio-mux.c | 1 +
drivers/iio/potentiostat/lmp91000.c | 1 +
drivers/iio/test/iio-test-multiply.c | 1 +
drivers/input/joystick/adc-joystick.c | 1 +
drivers/input/keyboard/adc-keys.c | 1 +
drivers/input/touchscreen/colibri-vf50-ts.c | 1 +
drivers/input/touchscreen/resistive-adc-touch.c | 1 +
drivers/phy/motorola/phy-cpcap-usb.c | 1 +
drivers/power/supply/ab8500_btemp.c | 1 +
drivers/power/supply/ab8500_charger.c | 1 +
drivers/power/supply/ab8500_fg.c | 1 +
drivers/power/supply/axp20x_ac_power.c | 1 +
drivers/power/supply/axp20x_battery.c | 1 +
drivers/power/supply/axp20x_usb_power.c | 1 +
drivers/power/supply/axp288_fuel_gauge.c | 1 +
drivers/power/supply/cpcap-battery.c | 1 +
drivers/power/supply/cpcap-charger.c | 1 +
drivers/power/supply/da9150-charger.c | 1 +
drivers/power/supply/generic-adc-battery.c | 1 +
drivers/power/supply/ingenic-battery.c | 1 +
drivers/power/supply/intel_dc_ti_battery.c | 1 +
drivers/power/supply/lego_ev3_battery.c | 1 +
drivers/power/supply/lp8788-charger.c | 1 +
drivers/power/supply/max17040_battery.c | 1 +
drivers/power/supply/mp2629_charger.c | 1 +
drivers/power/supply/mt6370-charger.c | 1 +
drivers/power/supply/qcom_smbx.c | 1 +
drivers/power/supply/rn5t618_power.c | 1 +
drivers/power/supply/rx51_battery.c | 1 +
drivers/power/supply/sc27xx_fuel_gauge.c | 1 +
drivers/power/supply/twl4030_charger.c | 1 +
drivers/power/supply/twl4030_madc_battery.c | 1 +
drivers/power/supply/twl6030_charger.c | 1 +
drivers/thermal/qcom/qcom-spmi-adc-tm5.c | 1 +
drivers/thermal/qcom/qcom-spmi-temp-alarm.c | 1 +
drivers/thermal/renesas/rzg3s_thermal.c | 1 +
drivers/thermal/thermal-generic-adc.c | 1 +
sound/soc/codecs/audio-iio-aux.c | 1 +
sound/soc/samsung/aries_wm8994.c | 1 +
sound/soc/samsung/midas_wm1811.c | 1 +
sound/soc/stm/stm32_adfsdm.c | 1 +
54 files changed, 83 insertions(+), 30 deletions(-)
diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 7e3c9f38297b..e735f43dcdeb 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -210,3 +210,4 @@ module_platform_driver(adc_jack_driver);
MODULE_AUTHOR("MyungJoo Ham <myungjoo.ham@samsung.com>");
MODULE_DESCRIPTION("ADC Jack extcon driver");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/hwmon/iio_hwmon.c b/drivers/hwmon/iio_hwmon.c
index e376d4cde5ad..4c7843fbcc50 100644
--- a/drivers/hwmon/iio_hwmon.c
+++ b/drivers/hwmon/iio_hwmon.c
@@ -222,3 +222,4 @@ module_platform_driver(iio_hwmon_driver);
MODULE_AUTHOR("Jonathan Cameron <jic23@kernel.org>");
MODULE_DESCRIPTION("IIO to hwmon driver");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/hwmon/ntc_thermistor.c b/drivers/hwmon/ntc_thermistor.c
index d21f7266c411..417807fad80b 100644
--- a/drivers/hwmon/ntc_thermistor.c
+++ b/drivers/hwmon/ntc_thermistor.c
@@ -706,3 +706,4 @@ MODULE_DESCRIPTION("NTC Thermistor Driver");
MODULE_AUTHOR("MyungJoo Ham <myungjoo.ham@samsung.com>");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:ntc-thermistor");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/adc/envelope-detector.c b/drivers/iio/adc/envelope-detector.c
index 5b16fe737659..fea20e7e6cd9 100644
--- a/drivers/iio/adc/envelope-detector.c
+++ b/drivers/iio/adc/envelope-detector.c
@@ -406,3 +406,4 @@ module_platform_driver(envelope_detector_driver);
MODULE_DESCRIPTION("Envelope detector using a DAC and a comparator");
MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/afe/iio-rescale.c b/drivers/iio/afe/iio-rescale.c
index ecaf59278c6f..d7f55109af3e 100644
--- a/drivers/iio/afe/iio-rescale.c
+++ b/drivers/iio/afe/iio-rescale.c
@@ -609,3 +609,4 @@ module_platform_driver(rescale_driver);
MODULE_DESCRIPTION("IIO rescale driver");
MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/buffer/industrialio-buffer-cb.c b/drivers/iio/buffer/industrialio-buffer-cb.c
index 3e27385069ed..608ea9afc15a 100644
--- a/drivers/iio/buffer/industrialio-buffer-cb.c
+++ b/drivers/iio/buffer/industrialio-buffer-cb.c
@@ -153,3 +153,4 @@ EXPORT_SYMBOL_GPL(iio_channel_cb_get_iio_dev);
MODULE_AUTHOR("Jonathan Cameron <jic23@kernel.org>");
MODULE_DESCRIPTION("Industrial I/O callback buffer");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/buffer/industrialio-hw-consumer.c b/drivers/iio/buffer/industrialio-hw-consumer.c
index 526b2a8d725d..d7ff086ed783 100644
--- a/drivers/iio/buffer/industrialio-hw-consumer.c
+++ b/drivers/iio/buffer/industrialio-hw-consumer.c
@@ -211,3 +211,4 @@ EXPORT_SYMBOL_GPL(iio_hw_consumer_disable);
MODULE_AUTHOR("Lars-Peter Clausen <lars@metafoo.de>");
MODULE_DESCRIPTION("Hardware consumer buffer the IIO framework");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/dac/ad8460.c b/drivers/iio/dac/ad8460.c
index 6e45686902dd..ad654819ca22 100644
--- a/drivers/iio/dac/ad8460.c
+++ b/drivers/iio/dac/ad8460.c
@@ -955,3 +955,4 @@ MODULE_AUTHOR("Mariel Tinaco <mariel.tinaco@analog.com");
MODULE_DESCRIPTION("AD8460 DAC driver");
MODULE_LICENSE("GPL");
MODULE_IMPORT_NS("IIO_DMAENGINE_BUFFER");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/dac/dpot-dac.c b/drivers/iio/dac/dpot-dac.c
index d1b8441051ae..49dbdb7df955 100644
--- a/drivers/iio/dac/dpot-dac.c
+++ b/drivers/iio/dac/dpot-dac.c
@@ -254,3 +254,4 @@ module_platform_driver(dpot_dac_driver);
MODULE_DESCRIPTION("DAC emulation driver using a digital potentiometer");
MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/dac/ds4424.c b/drivers/iio/dac/ds4424.c
index a8198ba4f98a..cfafee3159b1 100644
--- a/drivers/iio/dac/ds4424.c
+++ b/drivers/iio/dac/ds4424.c
@@ -321,3 +321,4 @@ MODULE_AUTHOR("Ismail H. Kose <ismail.kose@maximintegrated.com>");
MODULE_AUTHOR("Vishal Sood <vishal.sood@maximintegrated.com>");
MODULE_AUTHOR("David Jung <david.jung@maximintegrated.com>");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/inkern.c b/drivers/iio/inkern.c
index 1e5eb5a41271..70b6f589f37a 100644
--- a/drivers/iio/inkern.c
+++ b/drivers/iio/inkern.c
@@ -71,7 +71,7 @@ int iio_map_array_register(struct iio_dev *indio_dev, const struct iio_map *maps
iio_map_array_unregister_locked(indio_dev);
return ret;
}
-EXPORT_SYMBOL_GPL(iio_map_array_register);
+EXPORT_SYMBOL_NS_GPL(iio_map_array_register, "IIO_CONSUMER");
/*
* Remove all map entries associated with the given iio device
@@ -81,7 +81,7 @@ int iio_map_array_unregister(struct iio_dev *indio_dev)
guard(mutex)(&iio_map_list_lock);
return iio_map_array_unregister_locked(indio_dev);
}
-EXPORT_SYMBOL_GPL(iio_map_array_unregister);
+EXPORT_SYMBOL_NS_GPL(iio_map_array_unregister, "IIO_CONSUMER");
static void iio_map_array_unregister_cb(void *indio_dev)
{
@@ -99,7 +99,7 @@ int devm_iio_map_array_register(struct device *dev, struct iio_dev *indio_dev,
return devm_add_action_or_reset(dev, iio_map_array_unregister_cb, indio_dev);
}
-EXPORT_SYMBOL_GPL(devm_iio_map_array_register);
+EXPORT_SYMBOL_NS_GPL(devm_iio_map_array_register, "IIO_CONSUMER");
static const struct iio_chan_spec
*iio_chan_spec_from_name(const struct iio_dev *indio_dev, const char *name)
@@ -281,7 +281,7 @@ struct iio_channel *fwnode_iio_channel_get_by_name(struct fwnode_handle *fwnode,
return ERR_PTR(-ENODEV);
}
-EXPORT_SYMBOL_GPL(fwnode_iio_channel_get_by_name);
+EXPORT_SYMBOL_NS_GPL(fwnode_iio_channel_get_by_name, "IIO_CONSUMER");
static struct iio_channel *fwnode_iio_channel_get_all(struct device *dev)
{
@@ -386,7 +386,7 @@ struct iio_channel *iio_channel_get(struct device *dev,
return iio_channel_get_sys(name, channel_name);
}
-EXPORT_SYMBOL_GPL(iio_channel_get);
+EXPORT_SYMBOL_NS_GPL(iio_channel_get, "IIO_CONSUMER");
void iio_channel_release(struct iio_channel *channel)
{
@@ -395,7 +395,7 @@ void iio_channel_release(struct iio_channel *channel)
iio_device_put(channel->indio_dev);
kfree(channel);
}
-EXPORT_SYMBOL_GPL(iio_channel_release);
+EXPORT_SYMBOL_NS_GPL(iio_channel_release, "IIO_CONSUMER");
static void devm_iio_channel_free(void *iio_channel)
{
@@ -418,7 +418,7 @@ struct iio_channel *devm_iio_channel_get(struct device *dev,
return channel;
}
-EXPORT_SYMBOL_GPL(devm_iio_channel_get);
+EXPORT_SYMBOL_NS_GPL(devm_iio_channel_get, "IIO_CONSUMER");
struct iio_channel *devm_fwnode_iio_channel_get_by_name(struct device *dev,
struct fwnode_handle *fwnode,
@@ -437,7 +437,7 @@ struct iio_channel *devm_fwnode_iio_channel_get_by_name(struct device *dev,
return channel;
}
-EXPORT_SYMBOL_GPL(devm_fwnode_iio_channel_get_by_name);
+EXPORT_SYMBOL_NS_GPL(devm_fwnode_iio_channel_get_by_name, "IIO_CONSUMER");
struct iio_channel *iio_channel_get_all(struct device *dev)
{
@@ -506,7 +506,7 @@ struct iio_channel *iio_channel_get_all(struct device *dev)
iio_device_put(chans[i].indio_dev);
return ERR_PTR(ret);
}
-EXPORT_SYMBOL_GPL(iio_channel_get_all);
+EXPORT_SYMBOL_NS_GPL(iio_channel_get_all, "IIO_CONSUMER");
void iio_channel_release_all(struct iio_channel *channels)
{
@@ -518,7 +518,7 @@ void iio_channel_release_all(struct iio_channel *channels)
}
kfree(channels);
}
-EXPORT_SYMBOL_GPL(iio_channel_release_all);
+EXPORT_SYMBOL_NS_GPL(iio_channel_release_all, "IIO_CONSUMER");
static void devm_iio_channel_free_all(void *iio_channels)
{
@@ -541,7 +541,7 @@ struct iio_channel *devm_iio_channel_get_all(struct device *dev)
return channels;
}
-EXPORT_SYMBOL_GPL(devm_iio_channel_get_all);
+EXPORT_SYMBOL_NS_GPL(devm_iio_channel_get_all, "IIO_CONSUMER");
static int iio_channel_read(struct iio_channel *chan, int *val, int *val2,
enum iio_chan_info_enum info)
@@ -585,7 +585,7 @@ int iio_read_channel_raw(struct iio_channel *chan, int *val)
return iio_channel_read(chan, val, NULL, IIO_CHAN_INFO_RAW);
}
-EXPORT_SYMBOL_GPL(iio_read_channel_raw);
+EXPORT_SYMBOL_NS_GPL(iio_read_channel_raw, "IIO_CONSUMER");
int iio_read_channel_average_raw(struct iio_channel *chan, int *val)
{
@@ -597,7 +597,7 @@ int iio_read_channel_average_raw(struct iio_channel *chan, int *val)
return iio_channel_read(chan, val, NULL, IIO_CHAN_INFO_AVERAGE_RAW);
}
-EXPORT_SYMBOL_GPL(iio_read_channel_average_raw);
+EXPORT_SYMBOL_NS_GPL(iio_read_channel_average_raw, "IIO_CONSUMER");
int iio_multiply_value(int *result, s64 multiplier,
unsigned int type, int val, int val2)
@@ -701,7 +701,7 @@ int iio_convert_raw_to_processed(struct iio_channel *chan, int raw,
return iio_convert_raw_to_processed_unlocked(chan, raw, processed,
scale);
}
-EXPORT_SYMBOL_GPL(iio_convert_raw_to_processed);
+EXPORT_SYMBOL_NS_GPL(iio_convert_raw_to_processed, "IIO_CONSUMER");
int iio_read_channel_attribute(struct iio_channel *chan, int *val, int *val2,
enum iio_chan_info_enum attribute)
@@ -714,13 +714,13 @@ int iio_read_channel_attribute(struct iio_channel *chan, int *val, int *val2,
return iio_channel_read(chan, val, val2, attribute);
}
-EXPORT_SYMBOL_GPL(iio_read_channel_attribute);
+EXPORT_SYMBOL_NS_GPL(iio_read_channel_attribute, "IIO_CONSUMER");
int iio_read_channel_offset(struct iio_channel *chan, int *val, int *val2)
{
return iio_read_channel_attribute(chan, val, val2, IIO_CHAN_INFO_OFFSET);
}
-EXPORT_SYMBOL_GPL(iio_read_channel_offset);
+EXPORT_SYMBOL_NS_GPL(iio_read_channel_offset, "IIO_CONSUMER");
int iio_read_channel_processed_scale(struct iio_channel *chan, int *val,
unsigned int scale)
@@ -748,20 +748,20 @@ int iio_read_channel_processed_scale(struct iio_channel *chan, int *val,
scale);
}
}
-EXPORT_SYMBOL_GPL(iio_read_channel_processed_scale);
+EXPORT_SYMBOL_NS_GPL(iio_read_channel_processed_scale, "IIO_CONSUMER");
int iio_read_channel_processed(struct iio_channel *chan, int *val)
{
/* This is just a special case with scale factor 1 */
return iio_read_channel_processed_scale(chan, val, 1);
}
-EXPORT_SYMBOL_GPL(iio_read_channel_processed);
+EXPORT_SYMBOL_NS_GPL(iio_read_channel_processed, "IIO_CONSUMER");
int iio_read_channel_scale(struct iio_channel *chan, int *val, int *val2)
{
return iio_read_channel_attribute(chan, val, val2, IIO_CHAN_INFO_SCALE);
}
-EXPORT_SYMBOL_GPL(iio_read_channel_scale);
+EXPORT_SYMBOL_NS_GPL(iio_read_channel_scale, "IIO_CONSUMER");
static int iio_channel_read_avail(struct iio_channel *chan,
const int **vals, int *type, int *length,
@@ -790,7 +790,7 @@ int iio_read_avail_channel_attribute(struct iio_channel *chan,
return iio_channel_read_avail(chan, vals, type, length, attribute);
}
-EXPORT_SYMBOL_GPL(iio_read_avail_channel_attribute);
+EXPORT_SYMBOL_NS_GPL(iio_read_avail_channel_attribute, "IIO_CONSUMER");
int iio_read_avail_channel_raw(struct iio_channel *chan,
const int **vals, int *length)
@@ -807,7 +807,7 @@ int iio_read_avail_channel_raw(struct iio_channel *chan,
return ret;
}
-EXPORT_SYMBOL_GPL(iio_read_avail_channel_raw);
+EXPORT_SYMBOL_NS_GPL(iio_read_avail_channel_raw, "IIO_CONSUMER");
static int iio_channel_read_max(struct iio_channel *chan,
int *val, int *val2, int *type,
@@ -863,7 +863,7 @@ int iio_read_max_channel_raw(struct iio_channel *chan, int *val)
return iio_channel_read_max(chan, val, NULL, &type, IIO_CHAN_INFO_RAW);
}
-EXPORT_SYMBOL_GPL(iio_read_max_channel_raw);
+EXPORT_SYMBOL_NS_GPL(iio_read_max_channel_raw, "IIO_CONSUMER");
static int iio_channel_read_min(struct iio_channel *chan,
int *val, int *val2, int *type,
@@ -919,7 +919,7 @@ int iio_read_min_channel_raw(struct iio_channel *chan, int *val)
return iio_channel_read_min(chan, val, NULL, &type, IIO_CHAN_INFO_RAW);
}
-EXPORT_SYMBOL_GPL(iio_read_min_channel_raw);
+EXPORT_SYMBOL_NS_GPL(iio_read_min_channel_raw, "IIO_CONSUMER");
int iio_get_channel_type(struct iio_channel *chan, enum iio_chan_type *type)
{
@@ -933,7 +933,7 @@ int iio_get_channel_type(struct iio_channel *chan, enum iio_chan_type *type)
return 0;
}
-EXPORT_SYMBOL_GPL(iio_get_channel_type);
+EXPORT_SYMBOL_NS_GPL(iio_get_channel_type, "IIO_CONSUMER");
static int iio_channel_write(struct iio_channel *chan, int val, int val2,
enum iio_chan_info_enum info)
@@ -957,13 +957,13 @@ int iio_write_channel_attribute(struct iio_channel *chan, int val, int val2,
return iio_channel_write(chan, val, val2, attribute);
}
-EXPORT_SYMBOL_GPL(iio_write_channel_attribute);
+EXPORT_SYMBOL_NS_GPL(iio_write_channel_attribute, "IIO_CONSUMER");
int iio_write_channel_raw(struct iio_channel *chan, int val)
{
return iio_write_channel_attribute(chan, val, 0, IIO_CHAN_INFO_RAW);
}
-EXPORT_SYMBOL_GPL(iio_write_channel_raw);
+EXPORT_SYMBOL_NS_GPL(iio_write_channel_raw, "IIO_CONSUMER");
unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
{
@@ -978,7 +978,7 @@ unsigned int iio_get_channel_ext_info_count(struct iio_channel *chan)
return i;
}
-EXPORT_SYMBOL_GPL(iio_get_channel_ext_info_count);
+EXPORT_SYMBOL_NS_GPL(iio_get_channel_ext_info_count, "IIO_CONSUMER");
static const struct iio_chan_spec_ext_info *
iio_lookup_ext_info(const struct iio_channel *chan, const char *attr)
@@ -1013,7 +1013,7 @@ ssize_t iio_read_channel_ext_info(struct iio_channel *chan,
return ext_info->read(chan->indio_dev, ext_info->private,
chan->channel, buf);
}
-EXPORT_SYMBOL_GPL(iio_read_channel_ext_info);
+EXPORT_SYMBOL_NS_GPL(iio_read_channel_ext_info, "IIO_CONSUMER");
ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
const char *buf, size_t len)
@@ -1027,7 +1027,7 @@ ssize_t iio_write_channel_ext_info(struct iio_channel *chan, const char *attr,
return ext_info->write(chan->indio_dev, ext_info->private,
chan->channel, buf, len);
}
-EXPORT_SYMBOL_GPL(iio_write_channel_ext_info);
+EXPORT_SYMBOL_NS_GPL(iio_write_channel_ext_info, "IIO_CONSUMER");
ssize_t iio_read_channel_label(struct iio_channel *chan, char *buf)
{
@@ -1038,4 +1038,4 @@ ssize_t iio_read_channel_label(struct iio_channel *chan, char *buf)
return do_iio_read_channel_label(chan->indio_dev, chan->channel, buf);
}
-EXPORT_SYMBOL_GPL(iio_read_channel_label);
+EXPORT_SYMBOL_NS_GPL(iio_read_channel_label, "IIO_CONSUMER");
diff --git a/drivers/iio/light/cm3605.c b/drivers/iio/light/cm3605.c
index 0c17378e27d1..1bd11292d005 100644
--- a/drivers/iio/light/cm3605.c
+++ b/drivers/iio/light/cm3605.c
@@ -325,3 +325,4 @@ module_platform_driver(cm3605_driver);
MODULE_AUTHOR("Linus Walleij <linus.walleij@linaro.org>");
MODULE_DESCRIPTION("CM3605 ambient light and proximity sensor driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/light/gp2ap002.c b/drivers/iio/light/gp2ap002.c
index a0d8a58f2704..04b1f6eade0e 100644
--- a/drivers/iio/light/gp2ap002.c
+++ b/drivers/iio/light/gp2ap002.c
@@ -717,3 +717,4 @@ module_i2c_driver(gp2ap002_driver);
MODULE_AUTHOR("Linus Walleij <linus.walleij@linaro.org>");
MODULE_DESCRIPTION("GP2AP002 ambient light and proximity sensor driver");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/multiplexer/iio-mux.c b/drivers/iio/multiplexer/iio-mux.c
index b742ca9a99d1..e193913f5af7 100644
--- a/drivers/iio/multiplexer/iio-mux.c
+++ b/drivers/iio/multiplexer/iio-mux.c
@@ -464,3 +464,4 @@ module_platform_driver(mux_driver);
MODULE_DESCRIPTION("IIO multiplexer driver");
MODULE_AUTHOR("Peter Rosin <peda@axentia.se>");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/potentiostat/lmp91000.c b/drivers/iio/potentiostat/lmp91000.c
index eccc2a34358f..7d993f2acda4 100644
--- a/drivers/iio/potentiostat/lmp91000.c
+++ b/drivers/iio/potentiostat/lmp91000.c
@@ -423,3 +423,4 @@ module_i2c_driver(lmp91000_driver);
MODULE_AUTHOR("Matt Ranostay <matt.ranostay@konsulko.com>");
MODULE_DESCRIPTION("LMP91000 digital potentiostat");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/iio/test/iio-test-multiply.c b/drivers/iio/test/iio-test-multiply.c
index 432e279ffe5b..e4c497db4c79 100644
--- a/drivers/iio/test/iio-test-multiply.c
+++ b/drivers/iio/test/iio-test-multiply.c
@@ -210,3 +210,4 @@ MODULE_AUTHOR("Hans de Goede <hans@hansg.org>");
MODULE_DESCRIPTION("Test IIO multiply functions");
MODULE_LICENSE("GPL");
MODULE_IMPORT_NS("IIO_UNIT_TEST");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/input/joystick/adc-joystick.c b/drivers/input/joystick/adc-joystick.c
index ff44f9978b71..4fa42f88bcfa 100644
--- a/drivers/input/joystick/adc-joystick.c
+++ b/drivers/input/joystick/adc-joystick.c
@@ -329,3 +329,4 @@ module_platform_driver(adc_joystick_driver);
MODULE_DESCRIPTION("Input driver for joysticks connected over ADC");
MODULE_AUTHOR("Artur Rojek <contact@artur-rojek.eu>");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/input/keyboard/adc-keys.c b/drivers/input/keyboard/adc-keys.c
index f1753207429d..d687459a0c80 100644
--- a/drivers/input/keyboard/adc-keys.c
+++ b/drivers/input/keyboard/adc-keys.c
@@ -202,3 +202,4 @@ module_platform_driver(adc_keys_driver);
MODULE_AUTHOR("Alexandre Belloni <alexandre.belloni@free-electrons.com>");
MODULE_DESCRIPTION("Input driver for resistor ladder connected on ADC");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/input/touchscreen/colibri-vf50-ts.c b/drivers/input/touchscreen/colibri-vf50-ts.c
index 98d5b2ba63fb..89c4d7b2b89e 100644
--- a/drivers/input/touchscreen/colibri-vf50-ts.c
+++ b/drivers/input/touchscreen/colibri-vf50-ts.c
@@ -372,3 +372,4 @@ module_platform_driver(vf50_touch_driver);
MODULE_AUTHOR("Sanchayan Maity");
MODULE_DESCRIPTION("Colibri VF50 Touchscreen driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/input/touchscreen/resistive-adc-touch.c b/drivers/input/touchscreen/resistive-adc-touch.c
index 7e761ec73273..2fefd652864c 100644
--- a/drivers/input/touchscreen/resistive-adc-touch.c
+++ b/drivers/input/touchscreen/resistive-adc-touch.c
@@ -301,3 +301,4 @@ module_platform_driver(grts_driver);
MODULE_AUTHOR("Eugen Hristev <eugen.hristev@microchip.com>");
MODULE_DESCRIPTION("Generic ADC Resistive Touch Driver");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/phy/motorola/phy-cpcap-usb.c b/drivers/phy/motorola/phy-cpcap-usb.c
index 7cb020dd3423..9591672b0511 100644
--- a/drivers/phy/motorola/phy-cpcap-usb.c
+++ b/drivers/phy/motorola/phy-cpcap-usb.c
@@ -717,3 +717,4 @@ MODULE_ALIAS("platform:cpcap_usb");
MODULE_AUTHOR("Tony Lindgren <tony@atomide.com>");
MODULE_DESCRIPTION("CPCAP usb phy driver");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/ab8500_btemp.c b/drivers/power/supply/ab8500_btemp.c
index e5202a7b6209..36b0c52a4b8b 100644
--- a/drivers/power/supply/ab8500_btemp.c
+++ b/drivers/power/supply/ab8500_btemp.c
@@ -829,3 +829,4 @@ MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Johan Palsson, Karl Komierowski, Arun R Murthy");
MODULE_ALIAS("platform:ab8500-btemp");
MODULE_DESCRIPTION("AB8500 battery temperature driver");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/ab8500_charger.c b/drivers/power/supply/ab8500_charger.c
index 5f4537766e5b..6e49d1b28254 100644
--- a/drivers/power/supply/ab8500_charger.c
+++ b/drivers/power/supply/ab8500_charger.c
@@ -3751,3 +3751,4 @@ MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Johan Palsson, Karl Komierowski, Arun R Murthy");
MODULE_ALIAS("platform:ab8500-charger");
MODULE_DESCRIPTION("AB8500 charger management driver");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/ab8500_fg.c b/drivers/power/supply/ab8500_fg.c
index 9dd99722667a..5fa559f796aa 100644
--- a/drivers/power/supply/ab8500_fg.c
+++ b/drivers/power/supply/ab8500_fg.c
@@ -3252,3 +3252,4 @@ MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Johan Palsson, Karl Komierowski");
MODULE_ALIAS("platform:ab8500-fg");
MODULE_DESCRIPTION("AB8500 Fuel Gauge driver");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/axp20x_ac_power.c b/drivers/power/supply/axp20x_ac_power.c
index 5f6ea416fa30..e9049d6229df 100644
--- a/drivers/power/supply/axp20x_ac_power.c
+++ b/drivers/power/supply/axp20x_ac_power.c
@@ -421,3 +421,4 @@ module_platform_driver(axp20x_ac_power_driver);
MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
MODULE_DESCRIPTION("AXP20X and AXP22X PMICs' AC power supply driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/axp20x_battery.c b/drivers/power/supply/axp20x_battery.c
index 50ca8e110085..ee8701a6e907 100644
--- a/drivers/power/supply/axp20x_battery.c
+++ b/drivers/power/supply/axp20x_battery.c
@@ -1155,3 +1155,4 @@ module_platform_driver(axp20x_batt_driver);
MODULE_DESCRIPTION("Battery power supply driver for AXP20X and AXP22X PMICs");
MODULE_AUTHOR("Quentin Schulz <quentin.schulz@free-electrons.com>");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/axp20x_usb_power.c b/drivers/power/supply/axp20x_usb_power.c
index e75d1e377ac1..599adcf84968 100644
--- a/drivers/power/supply/axp20x_usb_power.c
+++ b/drivers/power/supply/axp20x_usb_power.c
@@ -1080,3 +1080,4 @@ module_platform_driver(axp20x_usb_power_driver);
MODULE_AUTHOR("Hans de Goede <hdegoede@redhat.com>");
MODULE_DESCRIPTION("AXP20x PMIC USB power supply status driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/axp288_fuel_gauge.c b/drivers/power/supply/axp288_fuel_gauge.c
index a3d71fc72064..c6897dd808fc 100644
--- a/drivers/power/supply/axp288_fuel_gauge.c
+++ b/drivers/power/supply/axp288_fuel_gauge.c
@@ -817,3 +817,4 @@ MODULE_AUTHOR("Ramakrishna Pallala <ramakrishna.pallala@intel.com>");
MODULE_AUTHOR("Todd Brandt <todd.e.brandt@linux.intel.com>");
MODULE_DESCRIPTION("Xpower AXP288 Fuel Gauge Driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/cpcap-battery.c b/drivers/power/supply/cpcap-battery.c
index 8106d1edcbc2..542c3c70e3cb 100644
--- a/drivers/power/supply/cpcap-battery.c
+++ b/drivers/power/supply/cpcap-battery.c
@@ -1176,3 +1176,4 @@ module_platform_driver(cpcap_battery_driver);
MODULE_LICENSE("GPL v2");
MODULE_AUTHOR("Tony Lindgren <tony@atomide.com>");
MODULE_DESCRIPTION("CPCAP PMIC Battery Driver");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/cpcap-charger.c b/drivers/power/supply/cpcap-charger.c
index d0c3008db534..89bc0fc3c9f8 100644
--- a/drivers/power/supply/cpcap-charger.c
+++ b/drivers/power/supply/cpcap-charger.c
@@ -977,3 +977,4 @@ MODULE_AUTHOR("Tony Lindgren <tony@atomide.com>");
MODULE_DESCRIPTION("CPCAP Battery Charger Interface driver");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:cpcap-charger");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/da9150-charger.c b/drivers/power/supply/da9150-charger.c
index 27f36ef5b88d..58449df6068c 100644
--- a/drivers/power/supply/da9150-charger.c
+++ b/drivers/power/supply/da9150-charger.c
@@ -644,3 +644,4 @@ module_platform_driver(da9150_charger_driver);
MODULE_DESCRIPTION("Charger Driver for DA9150");
MODULE_AUTHOR("Adam Thomson <Adam.Thomson.Opensource@diasemi.com>");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/generic-adc-battery.c b/drivers/power/supply/generic-adc-battery.c
index f5f2566b3a32..d18c8ee40405 100644
--- a/drivers/power/supply/generic-adc-battery.c
+++ b/drivers/power/supply/generic-adc-battery.c
@@ -298,3 +298,4 @@ module_platform_driver(gab_driver);
MODULE_AUTHOR("anish kumar <yesanishhere@gmail.com>");
MODULE_DESCRIPTION("generic battery driver using IIO");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/ingenic-battery.c b/drivers/power/supply/ingenic-battery.c
index b111c7ce2be3..5be269f17bff 100644
--- a/drivers/power/supply/ingenic-battery.c
+++ b/drivers/power/supply/ingenic-battery.c
@@ -190,3 +190,4 @@ module_platform_driver(ingenic_battery_driver);
MODULE_DESCRIPTION("Battery driver for Ingenic JZ47xx SoCs");
MODULE_AUTHOR("Artur Rojek <contact@artur-rojek.eu>");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/intel_dc_ti_battery.c b/drivers/power/supply/intel_dc_ti_battery.c
index 56b0c92e9d28..1a16ded563bc 100644
--- a/drivers/power/supply/intel_dc_ti_battery.c
+++ b/drivers/power/supply/intel_dc_ti_battery.c
@@ -387,3 +387,4 @@ MODULE_ALIAS("platform:" DEV_NAME);
MODULE_AUTHOR("Hans de Goede <hansg@kernel.org>");
MODULE_DESCRIPTION("Intel Dollar Cove (TI) battery driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/lego_ev3_battery.c b/drivers/power/supply/lego_ev3_battery.c
index 28454de05761..414816662b06 100644
--- a/drivers/power/supply/lego_ev3_battery.c
+++ b/drivers/power/supply/lego_ev3_battery.c
@@ -231,3 +231,4 @@ module_platform_driver(lego_ev3_battery_driver);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("David Lechner <david@lechnology.com>");
MODULE_DESCRIPTION("LEGO MINDSTORMS EV3 Battery Driver");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/lp8788-charger.c b/drivers/power/supply/lp8788-charger.c
index f0a680c155c4..8c6ec98362d0 100644
--- a/drivers/power/supply/lp8788-charger.c
+++ b/drivers/power/supply/lp8788-charger.c
@@ -727,3 +727,4 @@ MODULE_DESCRIPTION("TI LP8788 Charger Driver");
MODULE_AUTHOR("Milo Kim");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:lp8788-charger");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/max17040_battery.c b/drivers/power/supply/max17040_battery.c
index c1640bc6accd..1fe658bfecc1 100644
--- a/drivers/power/supply/max17040_battery.c
+++ b/drivers/power/supply/max17040_battery.c
@@ -635,3 +635,4 @@ module_i2c_driver(max17040_i2c_driver);
MODULE_AUTHOR("Minkyu Kang <mk7.kang@samsung.com>");
MODULE_DESCRIPTION("MAX17040 Fuel Gauge");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/mp2629_charger.c b/drivers/power/supply/mp2629_charger.c
index d281c1059629..ed49f9a04c8c 100644
--- a/drivers/power/supply/mp2629_charger.c
+++ b/drivers/power/supply/mp2629_charger.c
@@ -660,3 +660,4 @@ module_platform_driver(mp2629_charger_driver);
MODULE_AUTHOR("Saravanan Sekar <sravanhome@gmail.com>");
MODULE_DESCRIPTION("MP2629 Charger driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/mt6370-charger.c b/drivers/power/supply/mt6370-charger.c
index e6db961d5818..2d02fdf37d70 100644
--- a/drivers/power/supply/mt6370-charger.c
+++ b/drivers/power/supply/mt6370-charger.c
@@ -941,3 +941,4 @@ module_platform_driver(mt6370_chg_driver);
MODULE_AUTHOR("ChiaEn Wu <chiaen_wu@richtek.com>");
MODULE_DESCRIPTION("MediaTek MT6370 Charger Driver");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/qcom_smbx.c b/drivers/power/supply/qcom_smbx.c
index b1cb925581ec..63b88754155c 100644
--- a/drivers/power/supply/qcom_smbx.c
+++ b/drivers/power/supply/qcom_smbx.c
@@ -1050,3 +1050,4 @@ module_platform_driver(qcom_spmi_smb);
MODULE_AUTHOR("Casey Connolly <casey.connolly@linaro.org>");
MODULE_DESCRIPTION("Qualcomm SMB2 Charger Driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/rn5t618_power.c b/drivers/power/supply/rn5t618_power.c
index 40dec55a9f73..a3f30e390c11 100644
--- a/drivers/power/supply/rn5t618_power.c
+++ b/drivers/power/supply/rn5t618_power.c
@@ -821,3 +821,4 @@ module_platform_driver(rn5t618_power_driver);
MODULE_ALIAS("platform:rn5t618-power");
MODULE_DESCRIPTION("Power supply driver for RICOH RN5T618");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/rx51_battery.c b/drivers/power/supply/rx51_battery.c
index b0220ec2d926..57266921dc8e 100644
--- a/drivers/power/supply/rx51_battery.c
+++ b/drivers/power/supply/rx51_battery.c
@@ -246,3 +246,4 @@ MODULE_ALIAS("platform:rx51-battery");
MODULE_AUTHOR("Pali Rohár <pali@kernel.org>");
MODULE_DESCRIPTION("Nokia RX-51 battery driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/sc27xx_fuel_gauge.c b/drivers/power/supply/sc27xx_fuel_gauge.c
index a7ed9de8a289..1719ec4173e6 100644
--- a/drivers/power/supply/sc27xx_fuel_gauge.c
+++ b/drivers/power/supply/sc27xx_fuel_gauge.c
@@ -1350,3 +1350,4 @@ module_platform_driver(sc27xx_fgu_driver);
MODULE_DESCRIPTION("Spreadtrum SC27XX PMICs Fual Gauge Unit Driver");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/twl4030_charger.c b/drivers/power/supply/twl4030_charger.c
index 04216b2bfb6c..151f7b24e9b9 100644
--- a/drivers/power/supply/twl4030_charger.c
+++ b/drivers/power/supply/twl4030_charger.c
@@ -1144,3 +1144,4 @@ MODULE_AUTHOR("Gražvydas Ignotas");
MODULE_DESCRIPTION("TWL4030 Battery Charger Interface driver");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:twl4030_bci");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/twl4030_madc_battery.c b/drivers/power/supply/twl4030_madc_battery.c
index 3935162e350b..9b3785d1643c 100644
--- a/drivers/power/supply/twl4030_madc_battery.c
+++ b/drivers/power/supply/twl4030_madc_battery.c
@@ -237,3 +237,4 @@ MODULE_LICENSE("GPL");
MODULE_AUTHOR("Lukas Märdian <lukas@goldelico.com>");
MODULE_DESCRIPTION("twl4030_madc battery driver");
MODULE_ALIAS("platform:twl4030_madc_battery");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/power/supply/twl6030_charger.c b/drivers/power/supply/twl6030_charger.c
index b4ec26ff257c..82911a811f4e 100644
--- a/drivers/power/supply/twl6030_charger.c
+++ b/drivers/power/supply/twl6030_charger.c
@@ -579,3 +579,4 @@ module_platform_driver(twl6030_charger_driver);
MODULE_DESCRIPTION("TWL6030 Battery Charger Interface driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
index d7f2e6ca92c2..bb6222c8cc5f 100644
--- a/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
+++ b/drivers/thermal/qcom/qcom-spmi-adc-tm5.c
@@ -1069,3 +1069,4 @@ module_platform_driver(adc_tm5_driver);
MODULE_DESCRIPTION("SPMI PMIC Thermal Monitor ADC driver");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
index f39ca0ddd17b..fb003ca96454 100644
--- a/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
+++ b/drivers/thermal/qcom/qcom-spmi-temp-alarm.c
@@ -904,3 +904,4 @@ module_platform_driver(qpnp_tm_driver);
MODULE_ALIAS("platform:spmi-temp-alarm");
MODULE_DESCRIPTION("QPNP PMIC Temperature Alarm driver");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/thermal/renesas/rzg3s_thermal.c b/drivers/thermal/renesas/rzg3s_thermal.c
index e25e36c99a88..7ced8f76a0ec 100644
--- a/drivers/thermal/renesas/rzg3s_thermal.c
+++ b/drivers/thermal/renesas/rzg3s_thermal.c
@@ -270,3 +270,4 @@ module_platform_driver(rzg3s_thermal_driver);
MODULE_DESCRIPTION("Renesas RZ/G3S Thermal Sensor Unit Driver");
MODULE_AUTHOR("Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com>");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/drivers/thermal/thermal-generic-adc.c b/drivers/thermal/thermal-generic-adc.c
index 7c844589b153..cfdb8e674dd2 100644
--- a/drivers/thermal/thermal-generic-adc.c
+++ b/drivers/thermal/thermal-generic-adc.c
@@ -228,3 +228,4 @@ module_platform_driver(gadc_thermal_driver);
MODULE_AUTHOR("Laxman Dewangan <ldewangan@nvidia.com>");
MODULE_DESCRIPTION("Generic ADC thermal driver using IIO framework with DT");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/sound/soc/codecs/audio-iio-aux.c b/sound/soc/codecs/audio-iio-aux.c
index 588e48044c13..864a5a676495 100644
--- a/sound/soc/codecs/audio-iio-aux.c
+++ b/sound/soc/codecs/audio-iio-aux.c
@@ -312,3 +312,4 @@ module_platform_driver(audio_iio_aux_driver);
MODULE_AUTHOR("Herve Codina <herve.codina@bootlin.com>");
MODULE_DESCRIPTION("IIO ALSA SoC aux driver");
MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/sound/soc/samsung/aries_wm8994.c b/sound/soc/samsung/aries_wm8994.c
index 3723329b266d..b6f0f3c0d393 100644
--- a/sound/soc/samsung/aries_wm8994.c
+++ b/sound/soc/samsung/aries_wm8994.c
@@ -700,3 +700,4 @@ module_platform_driver(aries_audio_driver);
MODULE_DESCRIPTION("ALSA SoC ARIES WM8994");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:aries-audio-wm8994");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/sound/soc/samsung/midas_wm1811.c b/sound/soc/samsung/midas_wm1811.c
index 239e958b88d3..12c4962f901d 100644
--- a/sound/soc/samsung/midas_wm1811.c
+++ b/sound/soc/samsung/midas_wm1811.c
@@ -773,3 +773,4 @@ module_platform_driver(midas_driver);
MODULE_AUTHOR("Simon Shields <simon@lineageos.org>");
MODULE_DESCRIPTION("ASoC support for Midas");
MODULE_LICENSE("GPL v2");
+MODULE_IMPORT_NS("IIO_CONSUMER");
diff --git a/sound/soc/stm/stm32_adfsdm.c b/sound/soc/stm/stm32_adfsdm.c
index c914d1c46850..dabcd2759187 100644
--- a/sound/soc/stm/stm32_adfsdm.c
+++ b/sound/soc/stm/stm32_adfsdm.c
@@ -407,3 +407,4 @@ MODULE_DESCRIPTION("stm32 DFSDM DAI driver");
MODULE_AUTHOR("Arnaud Pouliquen <arnaud.pouliquen@st.com>");
MODULE_LICENSE("GPL v2");
MODULE_ALIAS("platform:" STM32_ADFSDM_DRV_NAME);
+MODULE_IMPORT_NS("IIO_CONSUMER");
--
2.51.2
^ permalink raw reply related
* [PATCH v4 0/6] Add support for the LTM8054 voltage regulator
From: Romain Gantois @ 2025-11-24 14:48 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko
Cc: Thomas Petazzoni, linux-kernel, devicetree, linux-iio,
Romain Gantois, Conor Dooley, MyungJoo Ham, Chanwoo Choi,
Guenter Roeck, Peter Rosin, Mariel Tinaco, Lars-Peter Clausen,
Michael Hennerich, Kevin Tsai, Linus Walleij, Dmitry Torokhov,
Eugen Hristev, Vinod Koul, Kishon Vijay Abraham I,
Sebastian Reichel, Chen-Yu Tsai, Support Opensource,
Paul Cercueil, Iskren Chernev, Marek Szyprowski, Matheus Castello,
Saravanan Sekar, Matthias Brugger, AngeloGioacchino Del Regno,
Casey Connolly, Pali Rohár, Orson Zhai, Baolin Wang,
Chunyan Zhang, Amit Kucheria, Thara Gopinath, Rafael J. Wysocki,
Daniel Lezcano, Zhang Rui, Lukasz Luba, Claudiu Beznea,
Jaroslav Kysela, Takashi Iwai, Sylwester Nawrocki, Olivier Moysan,
Arnaud Pouliquen, Maxime Coquelin, Alexandre Torgue, Dixit Parmar,
linux-hwmon, linux-input, linux-phy, linux-pm, linux-mips,
linux-arm-kernel, linux-mediatek, linux-arm-msm, linux-sound,
linux-stm32, Andy Shevchenko
Hello everyone,
This is version four of my series which adds initial support of the Linear
Technology LTM8054 voltage regulator. The driver supports a fixed voltage
and a tunable output current limit using a DAC-controlled pin.
I'd say that the most unusual part of this series is the usage of the IIO
consumer API in a regulator driver. I think this makes sense here, since
the regulator driver has to access a DAC to read/set the output current
limit.
Since the regulator driver writes microvolts and the IIO consumer API takes
millivolts, the reads and writes to the CTL DAC have to be scaled by a
factor of 1000. Scaled reads are already supported in IIO, but scaled
writes are not, which is why I've implemented them in patch 2/4.
Moreover, the IIO read/write operations are done in quite a roundabout way
in the driver's regulator callbacks. This is due to a unsafe locking
interaction: the regulator callbacks are called under regulator lock, which
means they have an active ww_mutex reservation ID. Or, some IIO drivers
will perform regulator operations when read/written to, thus taking a new
ww_mutex reservation ID. Taking two consecutive reservation IDs for the
same ww_mutex context without freeing the first ID is forbidden (and
lockdep will complain about this). The most straightforward solution I've
found is to move the actual IIO read/write operations to a different
thread, and to wait for them to complete with a timeout from the main
callback thread.
Please let me know what you think.
Thanks,
Romain
Signed-off-by: Romain Gantois <romain.gantois@bootlin.com>
---
Changes in v4:
- Various style improvements.
- Used namespaced exports for the IIO consumer API.
- Mitigated bug caused by abs() corner case.
- Link to v3: https://lore.kernel.org/r/20251106-ltm8054-driver-v3-0-fd1feae0f65a@bootlin.com
Changes in v3:
- Made IIO operations to an asynchronous context to avoid locking issue.
- Made CTL DAC control optional.
- Make various style adjustments to the LTM8054 driver.
- Link to v2: https://lore.kernel.org/r/20250925-ltm8054-driver-v2-0-bb61a401a0dc@bootlin.com
Changes in v2:
- Refactored iio_convert_processed_to_raw() to match what was done in Hans'
series.
- Added unit tests for IIO division.
- Fixed coding style issues and removed unnecessary casts.
- Link to v1: https://lore.kernel.org/r/20250916-ltm8054-driver-v1-0-fd4e781d33b9@bootlin.com
---
Romain Gantois (6):
regulator: dt-bindings: Add Linear Technology LTM8054 regulator
iio: inkern: Use namespaced exports
iio: add processed write API
iio: test: Add kunit tests for iio_divide_by_value()
regulator: Support the LTM8054 voltage regulator
regulator: ltm8054: Support output current limit control
.../devicetree/bindings/regulator/adi,ltm8054.yaml | 71 ++++
MAINTAINERS | 6 +
drivers/extcon/extcon-adc-jack.c | 1 +
drivers/hwmon/iio_hwmon.c | 1 +
drivers/hwmon/ntc_thermistor.c | 1 +
drivers/iio/adc/envelope-detector.c | 1 +
drivers/iio/afe/iio-rescale.c | 1 +
drivers/iio/buffer/industrialio-buffer-cb.c | 1 +
drivers/iio/buffer/industrialio-hw-consumer.c | 1 +
drivers/iio/dac/ad8460.c | 1 +
drivers/iio/dac/dpot-dac.c | 1 +
drivers/iio/dac/ds4424.c | 1 +
drivers/iio/inkern.c | 187 ++++++++--
drivers/iio/light/cm3605.c | 1 +
drivers/iio/light/gp2ap002.c | 1 +
drivers/iio/multiplexer/iio-mux.c | 1 +
drivers/iio/potentiostat/lmp91000.c | 1 +
drivers/iio/test/Kconfig | 12 +
drivers/iio/test/Makefile | 1 +
drivers/iio/test/iio-test-divide.c | 247 ++++++++++++++
drivers/iio/test/iio-test-multiply.c | 1 +
drivers/input/joystick/adc-joystick.c | 1 +
drivers/input/keyboard/adc-keys.c | 1 +
drivers/input/touchscreen/colibri-vf50-ts.c | 1 +
drivers/input/touchscreen/resistive-adc-touch.c | 1 +
drivers/phy/motorola/phy-cpcap-usb.c | 1 +
drivers/power/supply/ab8500_btemp.c | 1 +
drivers/power/supply/ab8500_charger.c | 1 +
drivers/power/supply/ab8500_fg.c | 1 +
drivers/power/supply/axp20x_ac_power.c | 1 +
drivers/power/supply/axp20x_battery.c | 1 +
drivers/power/supply/axp20x_usb_power.c | 1 +
drivers/power/supply/axp288_fuel_gauge.c | 1 +
drivers/power/supply/cpcap-battery.c | 1 +
drivers/power/supply/cpcap-charger.c | 1 +
drivers/power/supply/da9150-charger.c | 1 +
drivers/power/supply/generic-adc-battery.c | 1 +
drivers/power/supply/ingenic-battery.c | 1 +
drivers/power/supply/intel_dc_ti_battery.c | 1 +
drivers/power/supply/lego_ev3_battery.c | 1 +
drivers/power/supply/lp8788-charger.c | 1 +
drivers/power/supply/max17040_battery.c | 1 +
drivers/power/supply/mp2629_charger.c | 1 +
drivers/power/supply/mt6370-charger.c | 1 +
drivers/power/supply/qcom_smbx.c | 1 +
drivers/power/supply/rn5t618_power.c | 1 +
drivers/power/supply/rx51_battery.c | 1 +
drivers/power/supply/sc27xx_fuel_gauge.c | 1 +
drivers/power/supply/twl4030_charger.c | 1 +
drivers/power/supply/twl4030_madc_battery.c | 1 +
drivers/power/supply/twl6030_charger.c | 1 +
drivers/regulator/Kconfig | 9 +
drivers/regulator/Makefile | 1 +
drivers/regulator/ltm8054-regulator.c | 379 +++++++++++++++++++++
drivers/thermal/qcom/qcom-spmi-adc-tm5.c | 1 +
drivers/thermal/qcom/qcom-spmi-temp-alarm.c | 1 +
drivers/thermal/renesas/rzg3s_thermal.c | 1 +
drivers/thermal/thermal-generic-adc.c | 1 +
include/linux/iio/consumer.h | 36 ++
sound/soc/codecs/audio-iio-aux.c | 1 +
sound/soc/samsung/aries_wm8994.c | 1 +
sound/soc/samsung/midas_wm1811.c | 1 +
sound/soc/stm/stm32_adfsdm.c | 1 +
63 files changed, 972 insertions(+), 30 deletions(-)
---
base-commit: cda7b38e04b41bf0e19deed2999d725f440a5abd
change-id: 20250728-ltm8054-driver-11cfa4741065
Best regards,
--
Romain Gantois <romain.gantois@bootlin.com>
^ permalink raw reply
* Re: [PATCH v3] HID: memory leak in dualshock4_get_calibration_data
From: Max Staudt @ 2025-11-24 14:06 UTC (permalink / raw)
To: Jiri Slaby, Eslam Khafagy, roderick.colenbrander, jikos, bentiss
Cc: linux-input, linux-kernel, syzbot+4f5f81e1456a1f645bf8, stable
In-Reply-To: <6251f6df-d4ac-4681-8e8b-6df2514e655b@kernel.org>
On 11/24/25 3:32 PM, Jiri Slaby wrote:
> Isn't this fixed already by:
> commit 8513c154f8ad7097653dd9bf43d6155e5aad4ab3
> Author: Abdun Nihaal <nihaal@cse.iitm.ac.in>
> Date: Mon Nov 10 22:45:50 2025 +0530
>
> HID: playstation: Fix memory leak in dualshock4_get_calibration_data()
> ?
As far as I can see, that patch does indeed fix the same issue, and it
is already upstream.
Thanks for the hint - Abdun's patch has been upstreamed quite recently,
hence I guess Eslam missed it by accident. But maybe I'm wrong and Eslam
can chime in himself?
> Anyway, this is a typical use-case for __free(). Why not to use that?
Wow, there's been a lot of interesting stuff happening around cleanup.h.
I've been out of the kernel for too long, this looks like fun. Thanks
for pointing it out :)
Max
^ permalink raw reply
* Re: [PATCH 0/4] PM: Hibernate: Add hibernation cancellation support
From: Muhammad Usama Anjum @ 2025-11-24 13:03 UTC (permalink / raw)
To: Rafael J. Wysocki, superm1
Cc: usama.anjum, kernel, Len Brown, linux-pm, Danilo Krummrich,
Pavel Machek, Thomas Gleixner, Peter Zijlstra, Greg Kroah-Hartman,
linux-input, Dmitry Torokhov, linux-acpi, linux-kernel
In-Reply-To: <20251107184438.1328717-1-usama.anjum@collabora.com>
Hi,
Please review the patches when you have time.
On 11/7/25 11:44 PM, Muhammad Usama Anjum wrote:
> On a normal laptop/PC, the hibernation takes 15-20 seconds which is
> considerable time. Once hibernation is triggered from command line or by
> some GUI option, the hibernation cannot be cancelled until completed.
> Its not a blocker, but poor user experience.
>
> When power button is pressed during hibernation, it generates interrupt
> and then the event is routed to userspace. If systemd is being used, the
> logind handles these events and performs the specific action.
>
> During hibernation, the first stage is to freeze the userspace. Hence
> even if the power button is pressed, it doesn't aborts the hibernation
> as user space daemon is frozen.
>
> My device takes ~19 seconds to hibernate. When I was testing hibernation
> using rtcwake with timeout of 10 seconds, I found out that hibernation
> gets canceled around 10 seconds mark when the interrupt fires.
>
> In this series, the idea is to find a way to cancel the hibernation.
> With this series applied, the hibernation gets cancelled gracefully.
>
> The hibernation cancellation support isn't present in very last stage
> just before power_down(). I've not been able to handle the error paths
> correctly there yet as logs aren't available from that stage. I'll send
> that patch separately when it works.
>
> Cc: rafael@kernel.org
> Cc: superm1@kernel.org
> ---
> Changes since RFC:
> - Update description of patches
> - Use pm_sleep_transition_in_progress() instead of
> hibernation_in_progress()
>
> Muhammad Usama Anjum (4):
> PM: hibernate: export pm_sleep_transition_in_progress()
> ACPI: button: Cancel hibernation if button is pressed during
> hibernation
> Input: Ignore the KEY_POWER events if hibernation is in progress
> PM: sleep: clear pm_abort_suspend at suspend
>
> drivers/acpi/button.c | 12 +++++++++---
> drivers/base/power/main.c | 2 ++
> drivers/input/input.c | 6 ++++++
> kernel/cpu.c | 1 +
> kernel/power/hibernate.c | 5 ++++-
> kernel/power/main.c | 1 +
> kernel/power/process.c | 1 +
> 7 files changed, 24 insertions(+), 4 deletions(-)
>
--
---
Thanks,
Usama
^ permalink raw reply
* [PATCH AUTOSEL 6.17-6.1] HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk list
From: Sasha Levin @ 2025-11-24 8:06 UTC (permalink / raw)
To: patches, stable
Cc: April Grimoire, Jiri Kosina, Sasha Levin, jikos, bentiss,
linux-input
In-Reply-To: <20251124080644.3871678-1-sashal@kernel.org>
From: April Grimoire <april@aprilg.moe>
[ Upstream commit 743c81cdc98fd4fef62a89eb70efff994112c2d9 ]
SONiX AK870 PRO keyboard pretends to be an apple keyboard by VID:PID,
rendering function keys not treated properly. Despite being a
SONiX USB DEVICE, it uses a different name, so adding it to the list.
Signed-off-by: April Grimoire <april@aprilg.moe>
Signed-off-by: Jiri Kosina <jkosina@suse.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
## Comprehensive Analysis
### 1. Commit Message Analysis
The commit "HID: apple: Add SONiX AK870 PRO to non_apple_keyboards quirk
list" addresses a specific hardware compatibility issue. The SONiX AK870
PRO keyboard incorrectly identifies itself using Apple's Vendor ID (VID)
and Product ID (PID). This causes the `hid-apple` driver to mistakenly
apply Apple-specific function key behavior (where F1-F12 act as
media/special keys by default, requiring the Fn key to access standard
F-key functions).
The commit has no "Cc: stable" tag or "Fixes:" tag, but clearly
describes a hardware quirk fix.
### 2. Deep Code Research & Mechanism
The change modifies `drivers/hid/hid-apple.c` by adding a single entry
to the `non_apple_keyboards` array.
**The Mechanism:**
The `hid-apple` driver contains a function
`apple_is_non_apple_keyboard()` which iterates through the
`non_apple_keyboards` list:
```c
static const struct apple_non_apple_keyboard non_apple_keyboards[] = {
{ "SONiX USB DEVICE" },
{ "SONiX AK870 PRO" }, /* Added by this commit */
/* ... other existing entries like Keychron, GANSS ... */
};
static bool apple_is_non_apple_keyboard(struct hid_device *hdev)
{
/* ... iterates array and checks strncmp(hdev->name, ...) ... */
}
```
When a device matches an entry in this list, the driver sets the
`APPLE_IS_NON_APPLE` quirk. This flag fundamentally alters how the
driver processes input, specifically preventing the swapping of function
keys and Option/Command keys that is typical for genuine Apple hardware.
**Code Context:**
This infrastructure was introduced specifically to handle the growing
number of mechanical keyboards that use Apple's protocols/IDs for
compatibility but have PC physical layouts. The commit adds one string
literal to this existing, stable lookup table.
### 3. Feature vs. Bug Fix Classification
While technically "adding" a device ID string, this falls squarely under
the **Quirks and Workarounds** exception in the stable kernel rules.
- **The Bug:** Users of this specific keyboard currently experience
broken function key behavior (F1-F12 do not work as expected for a PC
layout).
- **The Fix:** A hardware-specific quirk that restores correct
functionality.
### 4. Risk and Impact Assessment
- **Impact:** High for owners of this device (restores usability). Zero
for everyone else.
- **Regression Risk:** **Negligible.** The change is a string addition
to a static array. The logic uses `strncmp` against the device name.
It is physically impossible for this change to affect any device that
does not report its name starting with "SONiX AK870 PRO".
- **Mainline Status:** The commit was merged recently (late October
2025). The pattern is well-established and has been used for other
keyboards (e.g., Keychron, Hailuck) without incident.
### 5. Stable Kernel Rules Compliance
- **Fixes a real bug?** Yes, function key behavior is incorrect without
it.
- **No new features?** Yes, it simply enables correct existing driver
behavior for this hardware.
- **Small and contained?** Yes, one line of code.
- **Valid Exception?** Yes, explicitly allowed under "Hardware-specific
quirks for broken/buggy devices."
### Conclusion
This is a textbook candidate for a stable backport. It fixes a user-
visible hardware regression (incorrect key mapping) using a low-risk,
established quirk mechanism. The lack of a "Cc: stable" tag is likely an
oversight common with trivial hardware ID additions, but it fully
qualifies under stable maintenance rules.
**YES**
drivers/hid/hid-apple.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/hid/hid-apple.c b/drivers/hid/hid-apple.c
index 61404d7a43ee1..57da4f86a9fa7 100644
--- a/drivers/hid/hid-apple.c
+++ b/drivers/hid/hid-apple.c
@@ -355,6 +355,7 @@ static const struct apple_key_translation swapped_fn_leftctrl_keys[] = {
static const struct apple_non_apple_keyboard non_apple_keyboards[] = {
{ "SONiX USB DEVICE" },
+ { "SONiX AK870 PRO" },
{ "Keychron" },
{ "AONE" },
{ "GANSS" },
--
2.51.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox