* Re: [PATCH v2] dt-bindings: pinctrl: qcom,pmic-gpio: Add Qualcomm PMK7750
From: Krzysztof Kozlowski @ 2026-06-11 12:24 UTC (permalink / raw)
To: sashiko-reviews; +Cc: robh, devicetree, conor+dt
In-Reply-To: <20260611111232.EF6541F00893@smtp.kernel.org>
On 11/06/2026 13:12, sashiko-bot@kernel.org wrote:
>>
>> properties:
>> compatible:
>> - items:
>> - - enum:
> [ ... ]
>> + oneOf:
>> + - items:
>> + - enum:
> [ ... ]
>> + - qcom,pmiv0104-gpio
>> + - qcom,pmk8350-gpio
>> + - qcom,pmk7750-gpio
>
> [Severity: Medium]
> Since qcom,pmk7750-gpio is added here to the standalone enum list, won't
> standalone usage bypass the generation-specific constraints (such as the
> gpio-line-names limit) defined in the allOf conditional block for the
> PMK8550 generation?
I should have removed pmk7750 here :(
Oh, I hate these YAML block re-indentations.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v4 0/2] pinctrl: ultrarisc: add DP1000 pinctrl support
From: Linus Walleij @ 2026-06-11 12:24 UTC (permalink / raw)
To: wangjia
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, linux-gpio, devicetree, linux-kernel,
Conor Dooley
In-Reply-To: <20260610-ultrarisc-pinctrl-v4-0-b7e9b2a8ed84@ultrarisc.com>
On Wed, Jun 10, 2026 at 7:29 AM Jia Wang via B4 Relay
<devnull+wangjia.ultrarisc.com@kernel.org> wrote:
> This series adds the devicetree schema and the pinctrl driver for the
> DP1000 controller using generic pinctrl bindings.
>
> Compared with v1, this series is narrowed down to the pinctrl binding
> and driver only. v1 patches 1, 2, 3, 5, 7, 8, and 9 (vendor prefix,
> CPU/SoC bindings, DTS files, and defconfig update) are not included in
> v2 and will be sent separately.
This is a very good looking driver so I applied the patches!
If there are any more snags they can certainly be fixed in-tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: mux-gpio: name correct maintainer
From: Wolfram Sang @ 2026-06-11 12:25 UTC (permalink / raw)
To: linux-i2c
Cc: Peter Korsgaard, Peter Rosin, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260611122053.7306-2-wsa+renesas@sang-engineering.com>
[-- Attachment #1: Type: text/plain, Size: 420 bytes --]
On Thu, Jun 11, 2026 at 02:20:53PM +0200, Wolfram Sang wrote:
> The YAML conversion added me as maintainer but I can't recall being
> asked nor do I want to maintain it. Add Peter as maintainer for the
> binding as he is maintainer of the driver.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> ---
Peter, are you fine with this change? Sorry, forgot to put this in the
original mail.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 0/2] EDITME: cover title for pmg1110-gpio
From: Linus Walleij @ 2026-06-11 12:26 UTC (permalink / raw)
To: Fenglin Wu
Cc: linux-arm-msm, Bjorn Andersson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-gpio, devicetree, linux-kernel,
Konrad Dybcio
In-Reply-To: <20260610-pmg1110-gpio-v1-0-a9c50cd8b5d9@oss.qualcomm.com>
On Wed, Jun 10, 2026 at 9:05 AM Fenglin Wu <fenglin.wu@oss.qualcomm.com> wrote:
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Fenglin Wu (2):
> dt-bindings: pinctrl: qcom,pmic-gpio: Document PMG1110 GPIO support
> pinctrl: qcom: spmi-gpio: Add PMG1110 GPIO support
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] dt-bindings: i2c: i2c-mux-pinctrl: change maintainer
From: Wolfram Sang @ 2026-06-11 12:26 UTC (permalink / raw)
To: linux-i2c
Cc: Thierry Reding, Wolfram Sang, Peter Rosin, Andi Shyti,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree
The YAML conversion added me as maintainer but I can't recall being
asked nor do I want to maintain it. Thierry has created the YAML file
and works for the company which contributed the driver.
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
---
@Thierry: are you okay with this change?
Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml
index 2e3d555eb96c..f7502da71909 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Pinctrl-based I2C Bus Mux
maintainers:
- - Wolfram Sang <wsa@kernel.org>
+ - Thierry Reding <treding@nvidia.com>
description: |
This binding describes an I2C bus multiplexer that uses pin multiplexing to route the I2C
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v8 5/7] leds: Add driver for ASUS Transformer LEDs
From: Svyatoslav Ryhel @ 2026-06-11 12:27 UTC (permalink / raw)
To: Lee Jones
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Dmitry Torokhov,
Pavel Machek, Sebastian Reichel, Ion Agorria,
Michał Mirosław, devicetree, linux-kernel, linux-input,
linux-leds, linux-pm
In-Reply-To: <20260611113037.GO4151951@google.com>
чт, 11 черв. 2026 р. о 14:30 Lee Jones <lee@kernel.org> пише:
>
> On Thu, 28 May 2026, Svyatoslav Ryhel wrote:
>
> > From: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> >
> > ASUS Transformer tablets have a green and an amber LED on both the Pad
> > and the Dock. If both LEDs are enabled simultaneously, the emitted light
> > will be yellow.
> >
> > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
> > ---
> > drivers/leds/Kconfig | 11 +++
> > drivers/leds/Makefile | 1 +
> > drivers/leds/leds-asus-transformer-ec.c | 125 ++++++++++++++++++++++++
> > 3 files changed, 137 insertions(+)
> > create mode 100644 drivers/leds/leds-asus-transformer-ec.c
> >
> > diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> > index f4a0a3c8c870..f637d23400a8 100644
> > --- a/drivers/leds/Kconfig
> > +++ b/drivers/leds/Kconfig
> > @@ -120,6 +120,17 @@ config LEDS_OSRAM_AMS_AS3668
> > To compile this driver as a module, choose M here: the module
> > will be called leds-as3668.
> >
> > +config LEDS_ASUS_TRANSFORMER_EC
> > + tristate "LED Support for Asus Transformer charging LED"
> > + depends on LEDS_CLASS
> > + depends on MFD_ASUS_TRANSFORMER_EC
> > + help
> > + This option enables support for charging indicator on
> > + Asus Transformer's Pad and it's Dock.
> > +
> > + To compile this driver as a module, choose M here: the module
> > + will be called leds-asus-transformer-ec.
> > +
> > config LEDS_AW200XX
> > tristate "LED support for Awinic AW20036/AW20054/AW20072/AW20108"
> > depends on LEDS_CLASS
> > diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> > index 8fdb45d5b439..d5395c3f1124 100644
> > --- a/drivers/leds/Makefile
> > +++ b/drivers/leds/Makefile
> > @@ -16,6 +16,7 @@ obj-$(CONFIG_LEDS_AN30259A) += leds-an30259a.o
> > obj-$(CONFIG_LEDS_APU) += leds-apu.o
> > obj-$(CONFIG_LEDS_ARIEL) += leds-ariel.o
> > obj-$(CONFIG_LEDS_AS3668) += leds-as3668.o
> > +obj-$(CONFIG_LEDS_ASUS_TRANSFORMER_EC) += leds-asus-transformer-ec.o
> > obj-$(CONFIG_LEDS_AW200XX) += leds-aw200xx.o
> > obj-$(CONFIG_LEDS_AW2013) += leds-aw2013.o
> > obj-$(CONFIG_LEDS_BCM6328) += leds-bcm6328.o
> > diff --git a/drivers/leds/leds-asus-transformer-ec.c b/drivers/leds/leds-asus-transformer-ec.c
> > new file mode 100644
> > index 000000000000..09503e76331c
> > --- /dev/null
> > +++ b/drivers/leds/leds-asus-transformer-ec.c
> > @@ -0,0 +1,125 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +
> > +#include <linux/err.h>
> > +#include <linux/leds.h>
> > +#include <linux/mfd/asus-transformer-ec.h>
> > +#include <linux/module.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/slab.h>
> > +
> > +enum {
> > + ASUSEC_LED_AMBER,
> > + ASUSEC_LED_GREEN,
> > + ASUSEC_LED_MAX
> > +};
> > +
> > +struct asus_ec_led_config {
> > + const char *name;
> > + unsigned int color;
> > + unsigned long long ctrl_bit;
>
> Should we use 'u64' here instead of 'unsigned long long' to align with standard
> kernel integer types?
>
sure
> > +};
> > +
> > +struct asus_ec_led {
> > + struct asus_ec_leds_data *ddata;
> > + struct led_classdev cdev;
> > + unsigned long long ctrl_bit;
>
> Should we use 'u64' here as well to keep it consistent?
>
sure
> > +};
> > +
> > +struct asus_ec_leds_data {
> > + const struct asusec_core *ec;
> > + struct asus_ec_led leds[ASUSEC_LED_MAX];
> > +};
> > +
> > +static const struct asus_ec_led_config asus_ec_leds[] = {
> > + [ASUSEC_LED_AMBER] = {
> > + .name = "amber",
> > + .color = LED_COLOR_ID_AMBER,
> > + .ctrl_bit = ASUSEC_CTL_LED_AMBER,
> > + },
> > + [ASUSEC_LED_GREEN] = {
> > + .name = "green",
> > + .color = LED_COLOR_ID_GREEN,
> > + .ctrl_bit = ASUSEC_CTL_LED_GREEN,
> > + },
> > +};
> > +
> > +static enum led_brightness asus_ec_led_get_brightness(struct led_classdev *cdev)
> > +{
> > + struct asus_ec_led *led = container_of(cdev, struct asus_ec_led, cdev);
> > + const struct asusec_core *ec = led->ddata->ec;
>
> I'm getting confused here.
>
> ddata is what I'd be calling the device data struct passed by the parent?
>
> In fact, ddata is a little known concept in Leds. Any reason to go for
> this over the standard nomenclature?
>
How then it should be named? It holds each LED's control bit.
> > + u64 ctl;
> > + int ret;
> > +
> > + ret = asus_dockram_access_ctl(ec->dockram, &ctl, 0, 0);
>
> Did we discuss preferring regmap already?
>
Yes, you were fine with all and even said that you will merge
everything with Dmitry Ack for input
HERE https://lore.kernel.org/lkml/20260527144619.GA671544@google.com/
Yet now I get a new pile of complaints and nits.
> > + if (ret)
> > + return LED_OFF;
> > +
> > + return ctl & led->ctrl_bit ? LED_ON : LED_OFF;
> > +}
> > +
> > +static int asus_ec_led_set_brightness(struct led_classdev *cdev,
> > + enum led_brightness brightness)
> > +{
> > + struct asus_ec_led *led = container_of(cdev, struct asus_ec_led, cdev);
> > + const struct asusec_core *ec = led->ddata->ec;
> > +
> > + if (brightness)
> > + return asus_dockram_access_ctl(ec->dockram, NULL,
> > + led->ctrl_bit, led->ctrl_bit);
> > +
> > + return asus_dockram_access_ctl(ec->dockram, NULL, led->ctrl_bit, 0);
> > +}
> > +
> > +static int asus_ec_led_probe(struct platform_device *pdev)
> > +{
> > + const struct asusec_core *ec = dev_get_drvdata(pdev->dev.parent);
> > + struct asus_ec_leds_data *ddata;
> > + struct device *dev = &pdev->dev;
> > + int i, ret;
>
> Could we declare the loop counter 'i' directly within the 'for' statement's
> scope to keep its scope limited? For example, 'for (int i = 0; ...)'.
>
> > +
> > + ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> > + if (!ddata)
> > + return -ENOMEM;
> > +
> > + platform_set_drvdata(pdev, ddata);
> > + ddata->ec = ec;
> > +
> > + for (i = 0; i < ASUSEC_LED_MAX; i++) {
>
> Nit: for (int i = ...
>
> > + const struct asus_ec_led_config *cfg = &asus_ec_leds[i];
> > + struct asus_ec_led *led = &ddata->leds[i];
> > +
> > + led->cdev.name = devm_kasprintf(dev, GFP_KERNEL, "%s::%s",
> > + ddata->ec->name, cfg->name);
> > + if (!led->cdev.name)
> > + return -ENOMEM;
> > +
> > + led->cdev.max_brightness = 1;
> > + led->cdev.color = cfg->color;
> > + led->cdev.flags = LED_CORE_SUSPENDRESUME | LED_RETAIN_AT_SHUTDOWN;
> > + led->cdev.brightness_get = asus_ec_led_get_brightness;
> > + led->cdev.brightness_set_blocking = asus_ec_led_set_brightness;
> > +
> > + led->ddata = ddata;
> > + led->ctrl_bit = cfg->ctrl_bit;
> > +
> > + ret = devm_led_classdev_register(dev, &led->cdev);
> > + if (ret)
> > + return dev_err_probe(dev, ret,
> > + "failed to register %s LED\n",
> > + cfg->name);
>
> Should we capitalise the error message here to match our style guidelines
> (e.g. 'Failed to register...')?
>
dev messages end with ":" so it should continue with lower case. You
want cap, I don't mind
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static struct platform_driver asus_ec_led_driver = {
> > + .driver.name = "asus-transformer-ec-led",
> > + .probe = asus_ec_led_probe,
> > +};
> > +module_platform_driver(asus_ec_led_driver);
> > +
> > +MODULE_ALIAS("platform:asus-transformer-ec-led");
> > +MODULE_AUTHOR("Michał Mirosław <mirq-linux@rere.qmqm.pl>");
> > +MODULE_AUTHOR("Svyatoslav Ryhel <clamor95@gmail.com>");
> > +MODULE_DESCRIPTION("ASUS Transformer's charging LED driver");
> > +MODULE_LICENSE("GPL");
> > --
> > 2.51.0
> >
> >
>
> --
> Lee Jones
^ permalink raw reply
* Re: [PATCH 3/3] iio: dac: ad3530r: Add support for AD3532R/AD3532
From: Nuno Sá @ 2026-06-11 12:29 UTC (permalink / raw)
To: Paller, Kim Seer
Cc: Jonathan Cameron, David Lechner, Sa, Nuno, Andy Shevchenko,
Hennerich, Michael, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-iio@vger.kernel.org,
linux-kernel@vger.kernel.org, linux, devicetree@vger.kernel.org
In-Reply-To: <SJ2PR03MB71394BC5D4E680A96F950732F91B2@SJ2PR03MB7139.namprd03.prod.outlook.com>
On Thu, Jun 11, 2026 at 07:04:37AM +0000, Paller, Kim Seer wrote:
> > > @@ -445,7 +704,7 @@ static int ad3530r_setup(struct ad3530r_state *st,
> > > int external_vref_uV) static const struct regmap_config
> > ad3530r_regmap_config = {
> > > .reg_bits = 16,
> > > .val_bits = 8,
> > > - .max_register = AD3530R_MAX_REG_ADDR,
> > > + .max_register = AD3532R_MAX_REG_ADDR,
> >
> > What happens if we read off the end (via debugfs) for the smaller parts?
>
> I tested reading registers at 0x1000 and above on AD3531R it just
> returns 0xFF and no crash. Should I add a per-chip regmap_config to limit
> the exposed register space?
Personally, that would make sense to me.
- Nuno Sá
>
> > > };
> > >
> > > static const struct iio_info ad3530r_info = { @@ -514,6 +773,8 @@
> > > static const struct spi_device_id ad3530r_id[] = {
> > > { "ad3530r", (kernel_ulong_t)&ad3530r_chip },
> > > { "ad3531", (kernel_ulong_t)&ad3531_chip },
> > > { "ad3531r", (kernel_ulong_t)&ad3531r_chip },
> > > + { "ad3532", (kernel_ulong_t)&ad3532_chip },
> > > + { "ad3532r", (kernel_ulong_t)&ad3532r_chip },
> >
> > Add a precursor patch to switch this to named initializers. Otherwise this will
> > clash with the work Uwe is doing to ensure these are all done that way.
> >
> > > { }
> > > };
> > > MODULE_DEVICE_TABLE(spi, ad3530r_id); @@ -523,6 +784,8 @@ static
> > > const struct of_device_id ad3530r_of_match[] = {
> > > { .compatible = "adi,ad3530r", .data = &ad3530r_chip },
> > > { .compatible = "adi,ad3531", .data = &ad3531_chip },
> > > { .compatible = "adi,ad3531r", .data = &ad3531r_chip },
> > > + { .compatible = "adi,ad3532", .data = &ad3532_chip },
> > > + { .compatible = "adi,ad3532r", .data = &ad3532r_chip },
> > > { }
> > > };
> > > MODULE_DEVICE_TABLE(of, ad3530r_of_match);
> > >
>
^ permalink raw reply
* Re: [PATCH v4 07/14] mfd: lm3533: Switch sysfs_create_group() to device_add_group()
From: Svyatoslav Ryhel @ 2026-06-11 12:31 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aimxK3asZjebYrNt@ashevche-desk.local>
ср, 10 черв. 2026 р. о 21:47 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Wed, Jun 10, 2026 at 05:38:38PM +0300, Svyatoslav Ryhel wrote:
> > вт, 9 черв. 2026 р. о 22:14 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > > On Sat, Jun 06, 2026 at 07:57:31AM +0300, Svyatoslav Ryhel wrote:
> > > > Switch from sysfs_create_group() to device_add_group() including device
> > > > managed where appropriate.
> > >
> > > This should use .dev_groups member of struct device_driver.
> >
> > Specify pls, device_add_group literally uses dev_groups, I don't
> > understand what is wrong.
>
> dev_groups of the struct device_driver. It means that the data should be
> static and be available before driver probe is called.
>
> ...
>
> > > > + ret = devm_device_add_group(&bd->dev, &lm3533_bl_attribute_group);
> > >
> > > This will make Greg KH very grumpy. (For the record, original code as well
> > > but it already is in upstream. So, thanks for trying to address this, just
> > > needs a bit more of work.)
> >
> > In the prev iteration YOU asked to me to adjust this. I have adjusted
> > and now you say that this is not appropriate. I will just drop this
> > commit altogether.
>
> Yes, and I still tell that this is the way to fix that issue.
>
> You can even do it yourself in a few clicks (hint: `git log --grep` is the tool
> of the day): 93afe8ba9b01 ("ACPI: TAD: Use dev_groups in struct device_driver").
> This is an example of what I meant.
>
Oh, very nice, thanks!
> > > > + if (ret < 0)
> > > > + return dev_err_probe(&pdev->dev, ret,
> > > > + "failed to create sysfs attributes\n");
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v4 14/14] video: leds: backlight: lm3533: Support getting LED sources from DT
From: Svyatoslav Ryhel @ 2026-06-11 12:33 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lee Jones, Daniel Thompson, Jingoo Han, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Helge Deller,
Johan Hovold, dri-devel, linux-leds, devicetree, linux-kernel,
linux-iio, linux-fbdev
In-Reply-To: <aimy3BxBaXQ3Uigd@ashevche-desk.local>
ср, 10 черв. 2026 р. о 21:54 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
>
> On Wed, Jun 10, 2026 at 05:45:28PM +0300, Svyatoslav Ryhel wrote:
> > вт, 9 черв. 2026 р. о 22:23 Andy Shevchenko <andriy.shevchenko@intel.com> пише:
> > > On Sat, Jun 06, 2026 at 07:57:38AM +0300, Svyatoslav Ryhel wrote:
> > > > Add Control Bank to HVLED/LVLED muxing support based on the led-sources
> > > > defined in the device tree.
>
> ...
>
> > > > + int ret, i;
> > >
> > > No need to add 'i'.
> >
> > This is personal preference as well. There is no strict rule that
> > iteration variable must be defined strictly in the for loop.
>
> This is a preference by Linus who is the leader of the project.
> Also in IIO we have some set of maintainer preferences.
>
Well, this is not meant for IIO, though it seems that Lee is also in
favor if this approach.
> > > > + for (i = 0; i < led->num_leds; i++) {
> > >
> > > for (unsigned int i = 0; i < led->num_leds; i++) {
> > >
> > > > + if (led->leds[i] >= LM3533_LVCTRLBANK_MAX)
> > > > + continue;
> > > > +
> > > > + output_cfg_shift = led->leds[i] * 2;
> > > > + output_cfg_val |= led->id << output_cfg_shift;
> > > > + output_cfg_mask |= OUTPUT_LVLED_MASK << output_cfg_shift;
> > > > + }
>
> --
> With Best Regards,
> Andy Shevchenko
>
>
^ permalink raw reply
* Re: [PATCH v11 0/6] gpio: siul2-s32g2: add initial GPIO driver
From: Linus Walleij @ 2026-06-11 12:35 UTC (permalink / raw)
To: Khristine Andreea Barbulescu
Cc: Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
Dong Aisheng, Jacky Bai, Greg Kroah-Hartman, Rafael J. Wysocki,
Srinivas Kandagatla, Alberto Ruiz, Christophe Lizzi, devicetree,
Enric Balletbo, Eric Chanudet, imx, linux-arm-kernel, linux-gpio,
linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
Vincent Guittot
In-Reply-To: <20260610132116.1998140-1-khristineandreea.barbulescu@oss.nxp.com>
On Wed, Jun 10, 2026 at 3:21 PM Khristine Andreea Barbulescu
<khristineandreea.barbulescu@oss.nxp.com> wrote:
> This patch series adds support for basic GPIO
> operations using gpio-regmap.
The series:
Reviewed-by: Linus Walleij <linusw@kernel.org>
This is definitely merge material, I would disregard Sashiko nitpicking at this
point and just merge it. Any additional fixes can be handled in-tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 02/13] dt-bindings: display: renesas,rzg2l-du: Add support for RZ/G3E SoC
From: Tommaso Merciai @ 2026-06-11 12:42 UTC (permalink / raw)
To: Rob Herring
Cc: tomm.merciai, geert, laurent.pinchart, linux-renesas-soc,
biju.das.jz, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Geert Uytterhoeven, Magnus Damm,
Laurent Pinchart, dri-devel, devicetree, linux-kernel
In-Reply-To: <20260513222725.GA2069022-robh@kernel.org>
Hi Rob,
Thanks for your review.
On Wed, May 13, 2026 at 05:27:25PM -0500, Rob Herring wrote:
> On Thu, May 07, 2026 at 11:21:30AM +0200, Tommaso Merciai wrote:
> > The RZ/G3E SoC integrates two LCD controllers (LCDC0 and LCDC1), each
> > containing a FCPVD, VSPD, and Display Unit (DU).
> >
> > - LCDC0 supports DSI and LVDS (single or dual-channel) outputs.
> > - LCDC1 supports DSI, LVDS (single-channel), and RGB outputs.
> >
> > Add compatible string 'renesas,r9a09g047-du' and extend the binding to
> > support two DU instances: add reg-names ('du0'/'du1'), extend reg,
> > interrupts, and resets to maxItems: 2, and extend clocks/clock-names to
> > six entries (aclk/pclk/vclk per instance, minItems: 3).
>
> Don't write what the diff has. I can read the diff for that.
Ouch, thanks.
>
> >
> > Drop the "Each port shall have a single endpoint." constraint since
> > RZ/G3E ports expose multiple endpoints.
> >
> > Add a RZ/G3E-specific allOf rule mapping two DU instances to two ports:
> >
> > - port@0 (DU0): endpoint@0 DSI, endpoint@2 LVDS ch0, endpoint@3 LVDS ch1
> > - port@1 (DU1): endpoint@0 DSI, endpoint@1 RGB (DPAD), endpoint@3 LVDS ch1
> >
> > Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
> > ---
> > v6->v7:
> > - Rebased on top of [1]
> > [1] https://lore.kernel.org/all/20260429170012.366537-1-prabhakar.mahadev-lad.rj@bp.renesas.com/
> > - Use single DRM device aggregating both DU instances (1 DU dt node),
> > modelling single port for each DU0, DU1 and multiple endpoints for
> > outputs.
>
> That seems like the completely wrong thing to do and you've given no
> reason why you think it is the right choice.
We had a discussion with Laurent at [1] about this topic.
In particular:
DSI ip can select at runtime input data path or DU0 or DU1
via DSI_LINK_GPO0R VICH register. This can be done by managing the
2 DUs as single DRM device aggregating both DU instances that will spawn
2 crtcs. In this way at runtime we can select the output for DSI ip
via the following commands:
modetest -M rzg2l-du -s 58@55:800x600-56.25@XR24 (DU0 -> DSI)
modetest -M rzg2l-du -s 58@56:800x600-56.25@XR24 (DU1 -> DSI)
This can be done using option [B] (single drm device that spawn 2 crtc).
Using option [A] we will have 2 drm devices 1 for DU0 and 1 for DU1
that each will spawn a single CRTC and the above feature will be not
achievable.
In the end we need a way to have single DRM device that spawn 2 CRTCs.
A) Two device tree nodes rapresenting DU0 and DU1 design [v6]:
du0: display@16460000 {
compatible = "renesas,r9a09g047-du";
reg = <0 0x16460000 0 0x10000>;
interrupts = <GIC_SPI 882 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 0xed>,
<&cpg CPG_MOD 0xee>,
<&cpg CPG_MOD 0xef>;
clock-names = "aclk", "pclk", "vclk";
power-domains = <&cpg>;
resets = <&cpg 0xdc>;
renesas,vsps = <&vspd0 0>;
status = "disabled";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
du0_out_dsi: endpoint {
};
};
port@2 {
reg = <2>;
du0_out_lvds0: endpoint {
};
};
port@3 {
reg = <3>;
du0_out_lvds1: endpoint {
};
};
};
};
du1: display@16490000 {
compatible = "renesas,r9a09g047-du";
reg = <0 0x16490000 0 0x10000>;
interrupts = <GIC_SPI 922 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 0x1a8>,
<&cpg CPG_MOD 0x1a9>,
<&cpg CPG_MOD 0x1aa>;
clock-names = "aclk", "pclk", "vclk";
power-domains = <&cpg>;
resets = <&cpg 0x11e>;
renesas,vsps = <&vspd1 0>;
status = "disabled";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
du1_out_dsi: endpoint {
};
};
port@1 {
reg = <1>;
du1_out_rgb: endpoint {
};
};
port@3 {
reg = <3>;
du1_out_lvds1: endpoint {
};
};
};
};
---
B) Single device tree node design aggregating both DU instances [v7]:
du: display@16460000 {
compatible = "renesas,r9a09g047-du";
reg = <0 0x16460000 0 0x10000>,
<0 0x16490000 0 0x10000>;
reg-names = "du0", "du1";
interrupts = <GIC_SPI 882 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 922 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 0xed>,
<&cpg CPG_MOD 0xee>,
<&cpg CPG_MOD 0xef>,
<&cpg CPG_MOD 0x1a8>,
<&cpg CPG_MOD 0x1a9>,
<&cpg CPG_MOD 0x1aa>;
clock-names = "aclk", "pclk", "vclk",
"aclk1", "pclk1", "vclk1";
power-domains = <&cpg>;
resets = <&cpg 0xdc>, <&cpg 0x11e>;
reset-names = "resetn", "resetn1";
renesas,vsps = <&vspd0 0>, <&vspd1 0>;
status = "disabled";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
du0_out_dsi: endpoint@0 {
reg = <0>;
};
du0_out_lvds0: endpoint@2 {
reg = <2>;
};
du0_out_lvds1: endpoint@3 {
reg = <3>;
};
};
port@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
du1_out_dsi: endpoint@0 {
reg = <0>;
};
du1_out_rgb: endpoint@1 {
reg = <1>;
};
du1_out_lvds1: endpoint@3 {
reg = <3>;
};
};
};
};
---
Please Biju, Laurent correct me if I'm missing something.
[1] https://patchwork.kernel.org/project/linux-renesas-soc/patch/8f814f22ff62dcde6153260e2c8c29a5415c9a89.1775636898.git.tommaso.merciai.xr@bp.renesas.com/
[v6] https://patchwork.kernel.org/project/linux-renesas-soc/patch/8f814f22ff62dcde6153260e2c8c29a5415c9a89.1775636898.git.tommaso.merciai.xr@bp.renesas.com/
[v7] https://patchwork.kernel.org/project/linux-renesas-soc/patch/ff8e401a0667970a42a55420dcb071e34730a923.1778141145.git.tommaso.merciai.xr@bp.renesas.com/
Kind Regards,
Tommaso
>
> Rob
^ permalink raw reply
* Re: [PATCH v5 08/10] ACPI: APEI: share GHES CPER helpers
From: Ahmed Tiba @ 2026-06-11 12:42 UTC (permalink / raw)
To: Jonathan Cameron
Cc: will, xueshuai, saket.dumbre, mchehab, dave, djbw, bp, tony.luck,
guohanjun, lenb, skhan, vishal.l.verma, rafael, corbet, ira.weiny,
dave.jiang, krzk+dt, robh, catalin.marinas, alison.schofield,
conor+dt, linux-arm-kernel, Michael.Zhao2, linux-doc,
linux-kernel, linux-cxl, Dmitry.Lamerov, devicetree, linux-acpi,
linux-edac, acpica-devel
In-Reply-To: <20260529173229.18843384@jic23-huawei>
On 29/05/2026 17:32, Jonathan Cameron wrote:
> On Fri, 29 May 2026 10:50:48 +0100
> Ahmed Tiba <ahmed.tiba@arm.com> wrote:
>
>> Wire GHES up to the helper routines in ghes_cper.c and remove the local
>> copies from ghes.c. This keeps the control flow identical while letting
>> the helpers be shared with other firmware-first providers.
>>
>> Signed-off-by: Ahmed Tiba <ahmed.tiba@arm.com>
> Mostly looks fine. The one bit that rather makes this exercise of breaking
> out generic code look dodgy is the ifdefs in the generic file.
>
As below.
>
>> ---
>> drivers/acpi/apei/ghes.c | 416 +--------------------------------------
>> drivers/acpi/apei/ghes_cper.c | 438 +++++++++++++++++++++++++++++++++++++++++-
>> include/acpi/ghes_cper.h | 20 ++
>> 3 files changed, 459 insertions(+), 415 deletions(-)
>>
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 85be2ebf4d3e..f85b97c4db4c 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>
>>
>> static void __ghes_panic(struct ghes *ghes,
>> diff --git a/drivers/acpi/apei/ghes_cper.c b/drivers/acpi/apei/ghes_cper.c
>> index d7a666a163c3..0ff9d06eb78f 100644
>> --- a/drivers/acpi/apei/ghes_cper.c
>> +++ b/drivers/acpi/apei/ghes_cper.c
>> @@ -13,22 +13,32 @@
>
>>
>> #include "apei-internal.h"
>>
>> +ATOMIC_NOTIFIER_HEAD(ghes_report_chain);
>> +
>> +#ifndef CONFIG_ACPI_APEI
>> +void __weak arch_apei_report_mem_error(int sev, struct cper_sec_mem_err *mem_err) { }
>> +#endif
> This is non obvious enough that the reasoning for a new weak function should be mentioned in
> the patch description. Why not stub it in include/acpi/apei.h?
>
Agreed. I should have explained that in the changelog.
The weak arch_apei_report_mem_error() fallback was only meant to keep
the shared helper buildable when GHES_CPER_HELPERS is enabled without
ACPI_APEI, while preserving the current GHES behaviour when ACPI_APEI
is enabled.
I kept it local because this fallback is only needed by this helper
split and I did not want to widen the APEI header API for that.
>> +
>> static struct ghes_estatus_cache __rcu *ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE];
>> static atomic_t ghes_estatus_cache_alloced;
>
>> +void __ghes_print_estatus(const char *pfx,
>> + const struct acpi_hest_generic *generic,
>> + const struct acpi_hest_generic_status *estatus)
>> +{
>> + static atomic_t seqno;
>> + unsigned int curr_seqno;
>> + char pfx_seq[64];
>> +
>> + if (!pfx) {
>> + if (ghes_severity(estatus->error_severity) <=
>> + GHES_SEV_CORRECTED)
>> + pfx = KERN_WARNING;
>> + else
>> + pfx = KERN_ERR;
>> + }
>> + curr_seqno = atomic_inc_return(&seqno);
>> + snprintf(pfx_seq, sizeof(pfx_seq), "%s{%u}" HW_ERR, pfx, curr_seqno);
>> + printk("%sHardware error from APEI Generic Hardware Error Source: %d\n",
>> + pfx_seq, generic->header.source_id);
>> + cper_estatus_print(pfx_seq, estatus);
>> +}
>> +
>> +int ghes_print_estatus(const char *pfx,
>> + const struct acpi_hest_generic *generic,
>> + const struct acpi_hest_generic_status *estatus)
>> +{
>> + /* Not more than 2 messages every 5 seconds */
>> + static DEFINE_RATELIMIT_STATE(ratelimit_corrected, 5 * HZ, 2);
>> + static DEFINE_RATELIMIT_STATE(ratelimit_uncorrected, 5 * HZ, 2);
>> + struct ratelimit_state *ratelimit;
>> +
>> + if (ghes_severity(estatus->error_severity) <= GHES_SEV_CORRECTED)
>> + ratelimit = &ratelimit_corrected;
>> + else
>> + ratelimit = &ratelimit_uncorrected;
>> + if (__ratelimit(ratelimit)) {
>> + __ghes_print_estatus(pfx, generic, estatus);
>> + return 1;
>> + }
>> + return 0;
>> +}
>> +
>> +#ifdef CONFIG_ACPI_APEI
>
> So after the effort to break the the generic stuff we end up with non generic
> bits in the broken out file? Is there no way to avoid this?
>
The intent here was not to create a new generic estatus core
but to keep the existing GHES control flow and lift the CPER helper flow
for reuse by the DT provider.
Splitting the remaining ACPI GHES specific read/clear path back out into
ghes.c would break that flow across files again. The CONFIG_ACPI_APEI
guard keeps that ACPI specific piece local while the DT side reuses the
same CPER parsing and status-dispatch path.
Best regards,
Ahmed
^ permalink raw reply
* Re: [PATCH RFC 0/2] pinctrl: Add support gpiod_to_irq
From: Linus Walleij @ 2026-06-11 12:51 UTC (permalink / raw)
To: xianwei.zhao
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, linux-amlogic,
linux-gpio, devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <20260611-gpio-to-irq-v1-0-12201716f23f@amlogic.com>
Hi Xianwei,
thanks for your patches!
On Thu, Jun 11, 2026 at 9:54 AM Xianwei Zhao via B4 Relay
<devnull+xianwei.zhao.amlogic.com@kernel.org> wrote:
> Some users need to obtain an IRQ directly from a GPIO descriptor through gpiod_to_irq().
> Add the required DT binding and implementation to support this use case.
> Since this introduces a new DT property, the property is kept optional to
> maintain compatibility with existing SoCs and DTS files.
To me it looks like you have just re-implemented hierarchical
irqs.
Look into the section "Infrastructure helpers for GPIO irqchips"
in Documentation/driver-api/gpio/driver.rst, especially towards
the end.
Solve this by using GPIOLIB_IRQCHIP and a custom
child_to_parent_hwirq() callback to translate the GPIO into
an IRQ.
To just implement gpiod_to_irq() without any irqchip abstraction
is also broken: you can't force all users to just use this way
to get an IRQ it's excessively restricting.
Add
interrupt-controller: true
"#interrupt-cells":
const: 2
to the pinctrl node as well so that DT users can simply request
the IRQ from the irqchip inside of the pin controller. It will
be hierarchical and lightweight but an irqchip nevertheless.
The GPIOLIB_IRQCHIP approach will help you to get this
right.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v3 4/4] net: phy: at803x: add RX and TX clock management for IPQ5018 PHY
From: Andrew Lunn @ 2026-06-11 12:52 UTC (permalink / raw)
To: Konrad Dybcio
Cc: George Moussalem, Kathiravan Thirumoorthy, Heiner Kallweit,
Russell King, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Florian Fainelli, Bjorn Andersson, Konrad Dybcio, netdev,
devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <f492327c-7ee1-443f-bb11-b78af0eda207@oss.qualcomm.com>
> Is there any prior art wrt enabling/disabling the PHYs (not necessarily
> clocks specifically, but say power supplies) at runtime?
> A quick grep only points to this very driver, which gets the regulator
> during probe, enables it and never turns it off
Not really. PHYs which care about power do their own power
management. They can sense the line and know if there is anything
plugged in the other end, and only then enable parts of the PHY. The
difference between an active and sleeping 1G PHY should be around 1
Watt. I don't think you will save too much more by turning off the
clocks.
Andrew
^ permalink raw reply
* Re: [PATCH v3 4/4] net: phy: at803x: add RX and TX clock management for IPQ5018 PHY
From: George Moussalem @ 2026-06-11 12:58 UTC (permalink / raw)
To: Andrew Lunn, Konrad Dybcio
Cc: Kathiravan Thirumoorthy, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Bjorn Andersson, Konrad Dybcio, netdev, devicetree, linux-kernel,
linux-arm-msm
In-Reply-To: <10f2c054-3d5e-4a80-adc8-2e63c655b3ae@lunn.ch>
On 6/11/26 16:52, Andrew Lunn wrote:
>> Is there any prior art wrt enabling/disabling the PHYs (not necessarily
>> clocks specifically, but say power supplies) at runtime?
>> A quick grep only points to this very driver, which gets the regulator
>> during probe, enables it and never turns it off
>
> Not really. PHYs which care about power do their own power
> management. They can sense the line and know if there is anything
> plugged in the other end, and only then enable parts of the PHY. The
> difference between an active and sleeping 1G PHY should be around 1
> Watt. I don't think you will save too much more by turning off the
> clocks.
in v4, clocks are enabled in probe using devm_clk_get_enabled.
There are currently no users so there will be no backwards compatibility
issues.
Kindly have a look here:
https://lore.kernel.org/all/20260608-ipq5018-gephy-clocks-v4-0-fb2ccd56894b@outlook.com/
>
> Andrew
Thanks,
George
^ permalink raw reply
* Re: [PATCH 2/2] iio: adc: Add TI ADS1220 driver
From: Jonathan Cameron @ 2026-06-11 13:00 UTC (permalink / raw)
To: Nguyen Minh Tien
Cc: linux-iio, devicetree, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, David Lechner, Nuno Sá, Andy Shevchenko,
linux-kernel
In-Reply-To: <20260610151342.44274-3-zizuzacker@gmail.com>
On Wed, 10 Jun 2026 22:13:42 +0700
Nguyen Minh Tien <zizuzacker@gmail.com> wrote:
> Add an IIO driver for the Texas Instruments ADS1220 24-bit delta-sigma
> SPI ADC. The driver supports single-ended and differential voltage
> channels described as device-tree child nodes, per-channel programmable
> gain (exposed through scale) and data rate (exposed through sampling
> frequency), the internal 2.048V reference, an external reference via a
> regulator, or the analog supply (AVDD) as a ratiometric reference,
> single-shot conversions and a DRDY-interrupt-driven triggered buffer.
> Conversions are gated either on the DRDY interrupt or, when no interrupt
> is wired, on a data-rate-derived delay. Runtime PM powers the device down
> between conversions.
>
> Signed-off-by: Nguyen Minh Tien <zizuzacker@gmail.com>
https://sashiko.dev/#/patchset/20260610151342.44274-1-zizuzacker%40gmail.com
Has some feedback. Take a look, but do be aware it is sometimes wrong.
For example, it is common for SPI controllers to use buffers that are
next to each other for DMA. Maybe it's not the intent of the DMA framework
but in practice it works.
Various comments inline
Thanks,
Jonathan
> ---
> MAINTAINERS | 7 +
> drivers/iio/adc/Kconfig | 12 +
> drivers/iio/adc/Makefile | 1 +
> drivers/iio/adc/ti-ads1220.c | 835 +++++++++++++++++++++++++++++++++++
> 4 files changed, 855 insertions(+)
> create mode 100644 drivers/iio/adc/ti-ads1220.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 396d4e76d..1797af05c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -26661,6 +26661,13 @@ S: Maintained
> F: Documentation/devicetree/bindings/iio/adc/ti,ads1119.yaml
> F: drivers/iio/adc/ti-ads1119.c
>
> +TI ADS1220 ADC DRIVER
> +M: Nguyen Minh Tien <zizuzacker@gmail.com>
> +L: linux-iio@vger.kernel.org
> +S: Maintained
> +F: Documentation/devicetree/bindings/iio/adc/ti,ads1220.yaml
Bring this in with the first file, so in the binding doc.
> +F: drivers/iio/adc/ti-ads1220.c
And add this line in this patch.
> diff --git a/drivers/iio/adc/ti-ads1220.c b/drivers/iio/adc/ti-ads1220.c
> new file mode 100644
> index 000000000..06bcc8841
> --- /dev/null
> +++ b/drivers/iio/adc/ti-ads1220.c
;
> +
> +/*
> + * Available scales expressed as gain reciprocals (val / val2), matching the
> + * convention used by the sibling ti-ads1119 driver: writing 0.25 selects a
> + * gain of 4. The full list is used for differential channels; single-ended
> + * channels (which force the PGA into bypass) are limited to the first three
> + * entries (gains 1, 2, 4).
This doesn't feel right. I'd expect to see scaling including the reference voltage
so you'll have to compute the array at runtime. Maybe we have an historical bug
in the ads1119 if it is not having it's read_raw and write_raw match values.
> + */
> +static const int ads1220_scale_avail[] = {
> + 1, 1,
> + 1, 2,
> + 1, 4,
> + 1, 8,
> + 1, 16,
> + 1, 32,
> + 1, 64,
> + 1, 128,
> +};
> +
> +#define ADS1220_SE_SCALE_AVAIL_LEN (3 * 2)
> +#define ADS1220_SCALE_AVAIL_LEN ARRAY_SIZE(ads1220_scale_avail)
> +
> +struct ads1220_channel_config {
> + unsigned int mux;
> + unsigned int gain;
> + unsigned int datarate;
> + bool single_ended;
> +};
> +
> +struct ads1220_state {
> + struct spi_device *spi;
> + struct completion completion;
> + struct iio_trigger *trig;
> + struct ads1220_channel_config *channels_cfg;
> + unsigned int num_channels_cfg;
> + int vref_uV;
> + unsigned int vref_source;
> +
> + /*
> + * DMA-safe buffers. tx is used for command/register writes, rx for
> + * register and conversion-result reads. scan holds one sample plus a
> + * timestamp for the triggered buffer.
> + */
> + u8 tx[2] __aligned(IIO_DMA_MINALIGN);
> + u8 rx[ADS1220_DATA_BYTES];
> + struct {
> + s32 sample;
> + aligned_s64 timestamp;
> + } scan;
This is accessed other than for DMA. So if you want it in the structure
move it before the section that has forced alignment. However, see below
- I think in this case simply using spi_write_then_read() everywhere
will be a useful simplification.
> +};
> +
> +static int ads1220_command(struct ads1220_state *st, u8 cmd)
> +{
> + st->tx[0] = cmd;
> +
> + return spi_write(st->spi, st->tx, 1);
> +}
> +
> +static int ads1220_write_reg(struct ads1220_state *st, u8 reg, u8 val)
> +{
> + st->tx[0] = ADS1220_CMD_WREG_REG(reg);
> + st->tx[1] = val;
> +
> + return spi_write(st->spi, st->tx, 2);
Given the buffers are small, you could use spi_write_the_read() with 0 sized
read to avoid need for DMA safe buffers. I think that would end up
a little simpler and the cost will be tiny.
> +}
> +
> +static int ads1220_read_reg(struct ads1220_state *st, u8 reg, u8 *val)
> +{
> + int ret;
> +
> + st->tx[0] = ADS1220_CMD_RREG_REG(reg);
> +
> + ret = spi_write_then_read(st->spi, st->tx, 1, st->rx, 1);
Can use local variables for the buffers (it bounces the data anyway)
which might be a little simpler to read.
> + if (ret)
> + return ret;
> +
> + *val = st->rx[0];
> +
> + return 0;
> +}
> +
> +static int ads1220_reset(struct ads1220_state *st)
> +{
> + int ret;
> +
> + ret = ads1220_command(st, ADS1220_CMD_RESET);
> + if (ret)
> + return ret;
> +
> + /* Wait at least 50us + 32 x tCLK after RESET before any command. */
Not obvious how this matches value of 100 to fsleep. Please provide
a little more info - such as what rate of tCLK is.
> + fsleep(100);
> +
> + return 0;
> +}
> +static int ads1220_single_conversion(struct ads1220_state *st,
> + const struct iio_chan_spec *chan,
> + int *val, bool calib_offset)
> +{
> + struct device *dev = &st->spi->dev;
> + struct ads1220_channel_config *cfg = &st->channels_cfg[chan->address];
> + unsigned int mux = cfg->mux;
> + bool single_ended = cfg->single_ended;
> + int ret;
> +
> + if (calib_offset) {
> + mux = ADS1220_MUX_SHORTED;
> + single_ended = false;
> + }
> +
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
> +
> + ret = ads1220_configure(st, mux, cfg->gain, cfg->datarate,
> + single_ended, false);
> + if (ret)
> + goto out;
> +
> + if (st->spi->irq)
> + reinit_completion(&st->completion);
> +
> + ret = ads1220_command(st, ADS1220_CMD_START);
> + if (ret)
> + goto out;
> +
> + ret = ads1220_read_sample(st, cfg->datarate, val);
> + if (ret)
> + goto out;
> +
> + ret = IIO_VAL_INT;
> +out:
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> +
> + return ret;
> +}
> +
> +static int ads1220_read_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int *val, int *val2, long mask)
> +{
> + struct ads1220_state *st = iio_priv(indio_dev);
> + struct ads1220_channel_config *cfg = &st->channels_cfg[chan->address];
> + int ret;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> + ret = ads1220_single_conversion(st, chan, val, false);
> + iio_device_release_direct(indio_dev);
> + return ret;
> + case IIO_CHAN_INFO_OFFSET:
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> + ret = ads1220_single_conversion(st, chan, val, true);
I think a comment on why this shorted channel is appropriate for offset
would be good (and sashiko thinks you have the sign wrong)
> + iio_device_release_direct(indio_dev);
> + return ret;
> + case IIO_CHAN_INFO_SCALE:
> + /* scale [mV] = vref / (gain * 2^23); gain is a power of two. */
> + *val = st->vref_uV / MILLI;
> + *val2 = (chan->scan_type.realbits - 1) + ilog2(cfg->gain);
> + return IIO_VAL_FRACTIONAL_LOG2;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + *val = cfg->datarate;
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ads1220_read_avail(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + const int **vals, int *type, int *length,
> + long mask)
> +{
> + struct ads1220_state *st = iio_priv(indio_dev);
> + struct ads1220_channel_config *cfg = &st->channels_cfg[chan->address];
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + *type = IIO_VAL_FRACTIONAL;
> + *vals = ads1220_scale_avail;
> + *length = cfg->single_ended ? ADS1220_SE_SCALE_AVAIL_LEN :
> + ADS1220_SCALE_AVAIL_LEN;
> + return IIO_AVAIL_LIST;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + *type = IIO_VAL_INT;
> + *vals = ads1220_datarates;
> + *length = ARRAY_SIZE(ads1220_datarates);
> + return IIO_AVAIL_LIST;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ads1220_write_raw(struct iio_dev *indio_dev,
> + const struct iio_chan_spec *chan,
> + int val, int val2, long mask)
> +{
> + struct ads1220_state *st = iio_priv(indio_dev);
> + struct ads1220_channel_config *cfg = &st->channels_cfg[chan->address];
> + unsigned int gain;
> + int i;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + /* The available scales are the gain reciprocals (e.g. 1/4). */
> + if (val == 0 && val2 == 0)
> + return -EINVAL;
> +
> + gain = MICRO / (val * MICRO + val2);
> + if (!is_power_of_2(gain) || gain > BIT(ADS1220_NUM_GAINS - 1))
> + return -EINVAL;
> + if (cfg->single_ended && gain > ADS1220_MAX_SE_GAIN)
> + return -EINVAL;
> +
> + cfg->gain = gain;
Sashiko called this out. The value written here should be the same as the
one we read back from read_raw(). If seems this one isn't taking the reference
voltage into account and should be doing so.
Sadly there is no way to reverse IIO_VAL_FRACTIONAL so to make things easier
you may have to stop using that for the avail and read_raw callbacks and instead
compute the values for IIO_VAL_INT_PLUS_MICRO
> + return 0;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + for (i = 0; i < ARRAY_SIZE(ads1220_datarates); i++) {
> + if (ads1220_datarates[i] == val) {
> + cfg->datarate = val;
> + return 0;
> + }
> + }
> + return -EINVAL;
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int ads1220_buffer_preenable(struct iio_dev *indio_dev)
> +{
> + struct ads1220_state *st = iio_priv(indio_dev);
> + struct device *dev = &st->spi->dev;
> + struct ads1220_channel_config *cfg;
> + unsigned int index;
> + int ret;
> +
> + index = find_first_bit(indio_dev->active_scan_mask,
> + iio_get_masklength(indio_dev));
> + cfg = &st->channels_cfg[index];
> +
> + ret = pm_runtime_resume_and_get(dev);
> + if (ret)
> + return ret;
> +
> + ret = ads1220_configure(st, cfg->mux, cfg->gain, cfg->datarate,
> + cfg->single_ended, true);
> + if (ret)
> + goto err;
> +
> + ret = ads1220_command(st, ADS1220_CMD_START);
> + if (ret)
> + goto err;
> +
> + return 0;
> +err:
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
> + return ret;
> +}
> +
> +static int ads1220_buffer_postdisable(struct iio_dev *indio_dev)
> +{
> + struct ads1220_state *st = iio_priv(indio_dev);
> + struct device *dev = &st->spi->dev;
> +
> + pm_runtime_mark_last_busy(dev);
> + pm_runtime_put_autosuspend(dev);
Read current kernel implementation of pm_runtime_put_autosuspend()
and consider if this pair of calls makes sense any more (it used to!)
> +
> + return 0;
> +}
> +
> +static const struct iio_buffer_setup_ops ads1220_buffer_setup_ops = {
> + .preenable = ads1220_buffer_preenable,
> + .postdisable = ads1220_buffer_postdisable,
> + .validate_scan_mask = &iio_validate_scan_mask_onehot,
I haven't really thought this through but is onehot suitable for this
device? Obvious in simple continuous conversion modes you haven't
a lot of choice, but I think a more complex SPI handling can do
the appropriate channel updates in parallel with capture of the
previous channel. Fine to leave that until we have a user though!
> +};
> +
> +static const struct iio_trigger_ops ads1220_trigger_ops = {
> + .validate_device = &iio_trigger_validate_own_device,
> +};
Just to check, can this device be used with other triggers?
> +
> +static int ads1220_map_mux(struct device *dev, u32 ain_pos, u32 ain_neg,
> + bool differential, unsigned int *mux,
> + bool *single_ended)
> +{
> + static const u8 diff_mux[ADS1220_MAX_AIN][ADS1220_MAX_AIN] = {
> + [0][1] = 0x0, [0][2] = 0x1, [0][3] = 0x2,
> + [1][2] = 0x3, [1][3] = 0x4, [1][0] = 0x6,
> + [2][3] = 0x5,
> + [3][2] = 0x7,
> + };
> +
> + if (!differential) {
> + if (ain_pos >= ADS1220_MAX_AIN)
> + return -EINVAL;
> + *mux = ADS1220_MUX_SINGLE(ain_pos);
> + *single_ended = true;
> + return 0;
> + }
> +
> + if (ain_pos >= ADS1220_MAX_AIN || ain_neg >= ADS1220_MAX_AIN)
> + return -EINVAL;
> +
> + /* Only the input pairs the multiplexer can route are valid. */
> + if (ain_pos == ain_neg || (diff_mux[ain_pos][ain_neg] == 0 &&
> + !(ain_pos == 0 && ain_neg == 1)))
The check is a little ugly. Maybe it would be simpler to use MAX_U8 as a
marker and fill the rest of the table above.
> + return -EINVAL;
> +
> + *mux = diff_mux[ain_pos][ain_neg];
> + *single_ended = false;
> +
> + return 0;
> +}
> +
> +static int ads1220_alloc_channels(struct iio_dev *indio_dev)
> +{
> + const struct iio_chan_spec ads1220_channel = {
> + .type = IIO_VOLTAGE,
> + .indexed = 1,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_OFFSET) |
> + BIT(IIO_CHAN_INFO_SAMP_FREQ),
> + .info_mask_separate_available = BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_SAMP_FREQ),
> + .scan_type = {
> + .sign = 's',
> + .realbits = ADS1220_DATA_BITS,
> + .storagebits = 32,
> + .endianness = IIO_CPU,
> + },
> + };
> + const struct iio_chan_spec ads1220_ts = IIO_CHAN_SOFT_TIMESTAMP(0);
That is now a designated initializer after a recent patch from David, so you
can now avoid the local variable and assign from the macro directly.
> + struct ads1220_state *st = iio_priv(indio_dev);
> + struct device *dev = &st->spi->dev;
> + struct iio_chan_spec *channels, *chan;
> + unsigned int num_channels, i = 0;
Don't mix assigning and non assigning declarations - they are sometimes hard
to read (though obviously this simple one isn't too bad!)
> + int ret;
> +
> + st->num_channels_cfg = device_get_child_node_count(dev);
> + if (st->num_channels_cfg == 0 ||
> + st->num_channels_cfg > ADS1220_MAX_CHANNELS)
> + return dev_err_probe(dev, -EINVAL,
> + "Invalid channel count %u (max %u)\n",
> + st->num_channels_cfg, ADS1220_MAX_CHANNELS);
> +
> + st->channels_cfg = devm_kcalloc(dev, st->num_channels_cfg,
> + sizeof(*st->channels_cfg), GFP_KERNEL);
> + if (!st->channels_cfg)
> + return -ENOMEM;
> +
> + /* One extra channel for the timestamp. */
> + num_channels = st->num_channels_cfg + 1;
> + channels = devm_kcalloc(dev, num_channels, sizeof(*channels),
> + GFP_KERNEL);
> + if (!channels)
> + return -ENOMEM;
> +
> + device_for_each_child_node_scoped(dev, child) {
> + struct ads1220_channel_config *cfg = &st->channels_cfg[i];
> + bool differential;
> + u32 ain[2];
> +
> + differential = fwnode_property_present(child, "diff-channels");
> + if (differential)
> + ret = fwnode_property_read_u32_array(child,
> + "diff-channels",
> + ain, 2);
> + else
> + ret = fwnode_property_read_u32(child, "single-channel",
> + &ain[0]);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to read channel property\n");
> +
> + ret = ads1220_map_mux(dev, ain[0], ain[1], differential,
> + &cfg->mux, &cfg->single_ended);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Invalid input combination\n");
> +
> + cfg->gain = 1;
> + cfg->datarate = ads1220_datarates[0];
> +
> + chan = &channels[i];
> + *chan = ads1220_channel;
I'd use a designated intializer here instead of a const that you copy.
That lets us combine a bunch of stuff into one place.
channels[i++] = (struct iio_chan_spec) = {
.type = IIO_VOLTAGE,
.indexed = 1,
.differental = differential ? 1 : 0,
.channel = ain[0],
.channel2 = ain[1], // just make sure this is set to 0 above.
.address = i,
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_OFFSET) |
BIT(IIO_CHAN_INFO_SAMP_FREQ),
.info_mask_separate_available = BIT(IIO_CHAN_INFO_SCALE) |
BIT(IIO_CHAN_INFO_SAMP_FREQ),
.scan_index = i,
.scan_type = {
.sign = 's',
.realbits = ADS1220_DATA_BITS,
.storagebits = 32,
.endianness = IIO_CPU,
},
};
> + chan->channel = ain[0];
> + chan->address = i;
> + chan->scan_index = i;
> + if (differential) {
> + chan->channel2 = ain[1];
> + chan->differential = 1;
> + }
> +
> + i++;
> + }
> +
> + channels[i] = ads1220_ts;
> + channels[i].scan_index = i;
> +
> + indio_dev->channels = channels;
> + indio_dev->num_channels = num_channels;
> +
> + return 0;
> +}
> +
> +static int ads1220_init(struct ads1220_state *st)
> +{
> + u8 reg2;
> + int ret;
> +
> + ret = ads1220_reset(st);
> + if (ret)
> + return ret;
> +
> + reg2 = FIELD_PREP(ADS1220_CFG2_VREF, st->vref_source);
> +
> + ret = ads1220_write_reg(st, ADS1220_REG_CONFIG2, reg2);
> + if (ret)
> + return ret;
> +
> + /* DRDY only on the dedicated pin (DRDYM = 0). */
> + return ads1220_write_reg(st, ADS1220_REG_CONFIG3, 0);
We might want something in the dt binding about the other case
not making sense. We can't safely do interrupts on an SPI data line
(though some SoCs happen to do the right things to make that work)
so we will in general use another pin tied to that line. If that
were the case might as well wire it to the separate pin instead.
> +}
> +
> +static int ads1220_probe(struct spi_device *spi)
> +{
> + struct device *dev = &spi->dev;
> + struct iio_dev *indio_dev;
> + struct ads1220_state *st;
> + int avdd_uV;
> + int ret;
> +
> + indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + st = iio_priv(indio_dev);
> + st->spi = spi;
> + spi_set_drvdata(spi, indio_dev);
> +
> + /* The ADS1220 uses SPI mode 1 (CPOL = 0, CPHA = 1). */
> + spi->mode |= SPI_CPHA;
> + spi->bits_per_word = 8;
Fairly sure that 8 is the default, so no point in setting it here.
> + ret = spi_setup(spi);
> + if (ret)
> + return dev_err_probe(dev, ret, "SPI setup failed\n");
> +
> + indio_dev->name = "ads1220";
> + indio_dev->info = &ads1220_info;
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + ret = devm_regulator_get_enable(dev, "dvdd");
> + if (ret)
> + return dev_err_probe(dev, ret, "Failed to enable dvdd\n");
> +
> + avdd_uV = devm_regulator_get_enable_read_voltage(dev, "avdd");
> + if (avdd_uV < 0)
> + return dev_err_probe(dev, avdd_uV, "Failed to get avdd\n");
Prefer
ret = devm_regulator_get_enable_read_voltage(dev, "avdd");
if (ret < 0)
return dev_err..
avdd_uV = ret;
Mostly because we don't need to check avdd_uV is signed and general principle
of avoiding reading it.
However, given it's fairly common to not be able to read a voltage from a regulator
you may want to only do this (rather than simply enabling it) if you need
it for a channel reference.
> +
> + /*
> + * Reference source, in priority order:
> + * - external reference on REFP0/REFN0 if a "vref" regulator is given;
> + * - the analog supply (AVDD) for ratiometric single-supply setups if
> + * "ti,vref-avdd" is set - no extra pins, full 0..AVDD input range;
> + * - otherwise the internal 2.048V reference.
> + */
> + st->vref_uV = devm_regulator_get_enable_read_voltage(dev, "vref");
> + if (st->vref_uV >= 0) {
> + st->vref_source = ADS1220_VREF_REFP0_REFN0;
> + } else if (st->vref_uV != -ENODEV) {
> + return dev_err_probe(dev, st->vref_uV, "Failed to get vref\n");
> + } else if (device_property_read_bool(dev, "ti,vref-avdd")) {
As above, I'd only get the voltage on avdd here.
> + st->vref_source = ADS1220_VREF_AVDD;
> + st->vref_uV = avdd_uV;
> + } else {
> + st->vref_source = ADS1220_VREF_INTERNAL;
> + st->vref_uV = ADS1220_INTERNAL_VREF_uV;
> + }
> +
> +static int ads1220_runtime_resume(struct device *dev)
> +{
> + /*
> + * A START/SYNC command wakes the analog parts from power-down; it is
> + * issued by the conversion path, so there is nothing to do here beyond
> + * letting the device settle after the supplies are active again.
This isn't manipulating the supplies so why do we need to wait for them?
> + */
> + fsleep(100);
> +
> + return 0;
> +}
> +
> +static DEFINE_RUNTIME_DEV_PM_OPS(ads1220_pm_ops, ads1220_runtime_suspend,
> + ads1220_runtime_resume, NULL);
> +
> +static const struct spi_device_id ads1220_id[] = {
> + { "ads1220" },
Please use a name initializer here. We are cleaning up this across
IIO at the moment as it makes things easier to read and possible enables
more interesting spi_device_id structures in future.
> + { }
> +};
> +MODULE_DEVICE_TABLE(spi, ads1220_id);
^ permalink raw reply
* Re: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low, level triggered
From: Parthiban.Veerasooran @ 2026-06-11 13:01 UTC (permalink / raw)
To: Selvamani.Rajagopal, andrew, conor
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, robh, krzk+dt,
conor+dt, Pier.Beruto, netdev, linux-kernel, Conor.Dooley,
devicetree
In-Reply-To: <CY8PR02MB9249B913E28E285EB46EC59C831D2@CY8PR02MB9249.namprd02.prod.outlook.com>
Hi Selvamani,
On 10/06/26 1:32 am, Selvamani Rajagopal wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
>> Subject: RE: [PATCH net v3 2/2] dt-bindings: net: updated interrupt type to be active low,
>> level triggered
>>
>>
>> Thanks Parthiban.
>> Though code was ready, I got into other things for the past two days. Please share your
>> changes. I will compare with mine before submitting.
>
>
> Parthiban,
>
> Just submitted the patches. When you have time, please review and test.
> As you could see, one change led to more investigation. I saw a traffic stall
> when I oversubscribed the traffic. That investigation led to extra patches.
>
> https://patchwork.kernel.org/project/netdevbpf/list/?series=1108804
Thank you for the update. I will test your v4 submission and share the
feedback as soon as possible.
Best regards,
Parthiban V
>
>
>>
>>>
>>> Best regards,
>>> Parthiban V
>>>>
>
^ permalink raw reply
* Re: [PATCH v3 2/2] clk: amlogic: Add A9 AO clock controller driver
From: Jian Hu @ 2026-06-11 13:01 UTC (permalink / raw)
To: Jerome Brunet, Jian Hu via B4 Relay
Cc: Neil Armstrong, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, linux-amlogic, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <1jjys6fuhz.fsf@starbuckisacylon.baylibre.com>
On 6/10/2026 8:30 PM, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
>
> On mer. 10 juin 2026 at 16:23, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
>
>> From: Jian Hu <jian.hu@amlogic.com>
>>
>> Add the Always-on clock controller driver for the Amlogic A9 SoC family.
>>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
>> ---
>> drivers/clk/meson/Kconfig | 13 ++
>> drivers/clk/meson/Makefile | 1 +
>> drivers/clk/meson/a9-aoclk.c | 431 +++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 445 insertions(+)
>>
>> diff --git a/drivers/clk/meson/Kconfig b/drivers/clk/meson/Kconfig
>> index cf8cf3f9e4ee..b71299898197 100644
>> --- a/drivers/clk/meson/Kconfig
>> +++ b/drivers/clk/meson/Kconfig
>> @@ -132,6 +132,19 @@ config COMMON_CLK_A1_PERIPHERALS
>> device, A1 SoC Family. Say Y if you want A1 Peripherals clock
>> controller to work.
>>
>> +config COMMON_CLK_A9_AO
>> + tristate "Amlogic A9 SoC AO clock controller support"
>> + depends on ARM64 || COMPILE_TEST
>> + default ARCH_MESON
>> + select COMMON_CLK_MESON_REGMAP
>> + select COMMON_CLK_MESON_CLKC_UTILS
>> + select COMMON_CLK_MESON_DUALDIV
>> + imply COMMON_CLK_SCMI
>> + help
>> + Support for the AO clock controller on Amlogic A311Y3 based
>> + device, AKA A9.
>> + Say Y if you want A9 AO clock controller to work.
>> +
>> config COMMON_CLK_C3_PLL
>> tristate "Amlogic C3 PLL clock controller"
>> depends on ARM64
>> diff --git a/drivers/clk/meson/Makefile b/drivers/clk/meson/Makefile
>> index c6719694a242..f89d027c282c 100644
>> --- a/drivers/clk/meson/Makefile
>> +++ b/drivers/clk/meson/Makefile
>> @@ -19,6 +19,7 @@ obj-$(CONFIG_COMMON_CLK_AXG) += axg.o axg-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_AXG_AUDIO) += axg-audio.o
>> obj-$(CONFIG_COMMON_CLK_A1_PLL) += a1-pll.o
>> obj-$(CONFIG_COMMON_CLK_A1_PERIPHERALS) += a1-peripherals.o
>> +obj-$(CONFIG_COMMON_CLK_A9_AO) += a9-aoclk.o
>> obj-$(CONFIG_COMMON_CLK_C3_PLL) += c3-pll.o
>> obj-$(CONFIG_COMMON_CLK_C3_PERIPHERALS) += c3-peripherals.o
>> obj-$(CONFIG_COMMON_CLK_GXBB) += gxbb.o gxbb-aoclk.o
>> diff --git a/drivers/clk/meson/a9-aoclk.c b/drivers/clk/meson/a9-aoclk.c
>> new file mode 100644
>> index 000000000000..dd9fd8d24702
>> --- /dev/null
>> +++ b/drivers/clk/meson/a9-aoclk.c
>> @@ -0,0 +1,431 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
>> +/*
>> + * Copyright (C) 2026 Amlogic, Inc. All rights reserved
>> + */
>> +
>> +#include <dt-bindings/clock/amlogic,a9-aoclkc.h>
>> +#include <linux/clk-provider.h>
>> +#include <linux/platform_device.h>
>> +#include "clk-regmap.h"
>> +#include "clk-dualdiv.h"
>> +#include "meson-clkc-utils.h"
>> +
>> +#define AO_OSCIN_CTRL 0x00
>> +#define AO_SYS_CLK0 0x04
>> +#define AO_PWM_CLK_A_CTRL 0x1c
>> +#define AO_PWM_CLK_B_CTRL 0x20
>> +#define AO_PWM_CLK_C_CTRL 0x24
>> +#define AO_PWM_CLK_D_CTRL 0x28
>> +#define AO_PWM_CLK_E_CTRL 0x2c
>> +#define AO_PWM_CLK_F_CTRL 0x30
>> +#define AO_PWM_CLK_G_CTRL 0x34
>> +#define AO_CEC_CTRL0 0x38
>> +#define AO_CEC_CTRL1 0x3c
>> +#define AO_RTC_BY_OSCIN_CTRL0 0x50
>> +#define AO_RTC_BY_OSCIN_CTRL1 0x54
>> +
>> +#define A9_COMP_SEL(_name, _reg, _shift, _mask, _pdata) \
>> + MESON_COMP_SEL(a9_ao_, _name, _reg, _shift, _mask, _pdata, NULL, 0, 0)
>> +
>> +#define A9_COMP_DIV(_name, _reg, _shift, _width) \
>> + MESON_COMP_DIV(a9_ao_, _name, _reg, _shift, _width, 0, CLK_SET_RATE_PARENT)
>> +
>> +#define A9_COMP_GATE(_name, _reg, _bit) \
>> + MESON_COMP_GATE(a9_ao_, _name, _reg, _bit, CLK_SET_RATE_PARENT)
>> +
>> +static struct clk_regmap a9_ao_xtal_in = {
>> + .data = &(struct clk_regmap_gate_data){
>> + .offset = AO_OSCIN_CTRL,
>> + .bit_idx = 3,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "ao_xtal_in",
>> + .ops = &clk_regmap_gate_ops,
>> + .parent_data = &(const struct clk_parent_data) {
>> + .fw_name = "xtal",
>> + },
>> + .num_parents = 1,
>> + /*
>> + * ao_sys can select different clock sources. One possible clock path is:
>> + * ao_xtal_in->ao_xtal->ao_sys-> ao sys gate clocks
>> + *
>> + * ao_xtal_in is in the parent chain of AO sys gate clocks.
>> + * Since some downstream clocks are marked CLK_IS_CRITICAL,
>> + * ao_xtal_in must remain enabled and is therefore marked
>> + * CLK_IS_CRITICAL as well.
>> + */
>> + .flags = CLK_IS_CRITICAL,
> Please allow some time for me to reply before reposting.
> See my answer on v2.
>
Sorry for reposting too quickly.
I'll allow more time for review feedback before sending the next revision.
I've seen your reply on v2 and will drop this flag in the next revision.
>> + },
>> +};
>> +
>> +static struct clk_regmap a9_ao_xtal = {
>> + .data = &(struct clk_regmap_mux_data) {
>> + .offset = AO_OSCIN_CTRL,
>> + .mask = 0x1,
>> + .shift = 0,
>> + },
>> + /* ext_32k is from external PAD, do not automatically reparent */
>> + .hw.init = CLK_HW_INIT_PARENTS_DATA("ao_xtal",
>> + ((const struct clk_parent_data []) {
>> + { .hw = &a9_ao_xtal_in.hw },
>> + { .fw_name = "ext_32k" }
>> + }), &clk_regmap_mux_ops, CLK_SET_RATE_NO_REPARENT),
> I hope my view on this is clear as well.
> Let me know if it isn't
>
Understood. I will drop all CLK_HW_INIT* macros and revert to explicit
struct clk_init_data initializers for the A9 clock controllers.
[ ... ]
> --
> Jerome
--
Jian
^ permalink raw reply
* Re: [PATCH v3 3/8] pinctrl: qcom: Register functions before enabling pinctrl
From: Linus Walleij @ 2026-06-11 13:01 UTC (permalink / raw)
To: contact
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Guru Das Srinagesh,
Rob Clark, Joerg Roedel, Will Deacon, Robin Murphy, Kees Cook,
Tony Luck, Guilherme G. Piccoli, linux-arm-msm, devicetree,
linux-kernel, linux-gpio, iommu, phone-devel
In-Reply-To: <20260519-mainline-send-v1-sending-v3-3-3dd7aa125353@alex-min.fr>
On Tue, May 19, 2026 at 9:16 AM Alexandre MINETTE via B4 Relay
<devnull+contact.alex-min.fr@kernel.org> wrote:
> From: Alexandre MINETTE <contact@alex-min.fr>
>
> pinctrl consumers can request states while the pinctrl core enables the
> controller. On Qualcomm pinctrl drivers this can happen before the SoC
> function list has been registered, which leaves the function table
> incomplete during state lookup.
>
> On APQ8064 this can fail while claiming pinctrl hogs:
>
> apq8064-pinctrl 800000.pinctrl: invalid function ps_hold in map table
> apq8064-pinctrl 800000.pinctrl: error claiming hogs: -22
> apq8064-pinctrl 800000.pinctrl: could not claim hogs: -22
>
> Register Qualcomm pinctrl with devm_pinctrl_register_and_init(), add the
> SoC pin functions, and only then enable the pinctrl device.
>
> Signed-off-by: Alexandre MINETTE <contact@alex-min.fr>
This v3 patch applied, I saw there is a v4 and Sashiko is whining
about it so check if there is anything to it, but the AI is a bit noisy
so I just don't care now that I have a review tag from Konrad.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: mux-gpio: name correct maintainer
From: Korsgaard, Peter @ 2026-06-11 13:02 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c@vger.kernel.org
Cc: Peter Rosin, Andi Shyti, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <20260611122053.7306-2-wsa+renesas@sang-engineering.com>
Hi,
> The YAML conversion added me as maintainer but I can't recall being
> asked nor do I want to maintain it. Add Peter as maintainer for the
> binding as he is maintainer of the driver.
>
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Peter Korsgaard <peter.korsgaard@barco.com>
--
Bye, Peter Korsgaard
This message is subject to the following terms and conditions: MAIL DISCLAIMER<https://www.barco.com/en/maildisclaimer>
^ permalink raw reply
* [PATCH/RFC 0/9] R-Car X5H Ironhide pure SCMI proof-of-concept
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
Hi all,
As promised[1], I tried handling all issues with current R-Car X5H
Ironhide SCP FW SDK v4.28, v4.31, and v4.32 as SCMI quirks. This helped
identifying missing features in the SCMI drivers and/or protocol:
- The SCMI PM domain driver does not support always-on domains.
This limits the ability of the Linux Power Management core to
optimize its decisions by taking into account which PM domains
cannot be disabled,
- The SCMI protocol does not support clock domains.
- Power management of on-SoC modules is typically handled through two
methods: module power control and module clock gating. The former
can be exposed as an SCMI power domain, the latter as an SCMI clock.
Currently, the SCMI clock protocol does not support advertizing
whether a clock is intended for power-management of a hardware
module, so such clocks can not be managed automatically through
Runtime PM. To solve this in general, the SCMI CLOCK_ATTRIBUTES
could be extended with a new flag in the returned attributes (which
is not done by this series).
Series overvies:
- Patch 1 is a preparatory refactoring,
- Patches 2-3 add support for always-on power areas,
- Patches 4-7 add support for clock domains,
- Patch 8 adds an SCMI quirk to advertize power-management clocks on
R-Car X5H,
- Patch 9 switches the (still minimal) Ironhide DTS to SCMI (this
needs manual configuration for the actual SCP firmware version, as
the SCMI domain IDs differ).
Note that other SCMI quirks than patch 8 are not included in this
series[2], as IMHO the original issues must be fixed in the SCP firmware
instead.
While the result works, and we might get stable SCMI domain IDs
(eventually), I still prefer the approach taking by the CPG/MDLC
remapping driver series[3], as:
- It describes in DT the actual hardware (which is needed for U-Boot
IPL),
- It does not depend on SCMI domain IDs defined by firmware that is
still under active development,
- It lets us keep the DTB stable, while SCMI domain IDs may change,
depending on system partitioning (i.e. software policy),
- It allows us to support (in the Renesas LTS tree, not upstream)
firmware versions that already exist, but need quirks for proper
operation.
Thanks for your comments!
[1] "Re: [PATCH/RFC 05/14] firmware: arm_scmi: Add scmi_get_base_info()"
https://lore.kernel.org/CAMuHMdWJvMH+a1RqozbaCxxH_8M569JcruTFa8PW+87FysnjHw@mail.gmail.com
[2] List of SCMI quirks which are not included in this series, but are
needed to boot on R-Car X5H Ironhide:
firmware: arm_scmi: quirk: Handle critical clocks on R-Car X5H
firmware: arm_scmi: quirk: Handle bad power domains on R-Car X5H
firmware: arm_scmi: quirk: Handle bad clocks on R-Car X5H
firmware: arm_scmi: quirk: Handle wrong clock rates on R-Car X5H
firmware: arm_scmi: Add support for retrieving rates from another clock
firmware: arm_scmi: quirk: Handle zero clock rates on R-Car X5H
firmware: arm_scmi: quirk: Add always-on power domains on R-Car X5H
firmware: arm_scmi: quirk: Handle broken HSCIF0 reset on R-Car X5H
With diffstat:
drivers/firmware/arm_scmi/clock.c | 2555 +++++++++++++++++++++++++++-
drivers/firmware/arm_scmi/power.c | 83 +
drivers/firmware/arm_scmi/quirks.c | 12 +
drivers/firmware/arm_scmi/quirks.h | 4 +
drivers/firmware/arm_scmi/reset.c | 9 +
5 files changed, 2655 insertions(+), 8 deletions(-)
[3] "[PATCH/RFC 00/14] R-Car X5H Ironhide SCMI CPG/MDLC remapping"
https://lore.kernel.org/cover.1776793163.git.geert+renesas@glider.be
Geert Uytterhoeven (9):
firmware: arm_scmi: Replace scmi_power_proto_ops.name_get() by
.info_get()
firmware: arm_scmi: Advertize always-on power domains
pmdomain: arm: scmi: Add always-on support
firmware: arm_scmi: Add a flag for power-management clocks
clk: scmi: Add scmi_clk_is_pm_clk()
dt-bindings: firmware: arm,scmi: Document arm,clock-domain
pmdomain: arm: scmi: Add clock domain support
firmware: arm_scmi: quirk: Handle power management clocks on R-Car X5H
arm64: dts: renesas: ironhide: Switch to pure SCMI
.../bindings/firmware/arm,scmi.yaml | 7 ++
.../boot/dts/renesas/r8a78000-ironhide.dts | 44 +++++++++
drivers/clk/clk-scmi.c | 9 ++
drivers/firmware/arm_scmi/clock.c | 15 +++
drivers/firmware/arm_scmi/power.c | 21 +++--
drivers/pmdomain/arm/Kconfig | 1 +
drivers/pmdomain/arm/scmi_pm_domain.c | 93 ++++++++++++++++++-
include/linux/clk/scmi.h | 17 ++++
include/linux/scmi_protocol.h | 12 ++-
9 files changed, 204 insertions(+), 15 deletions(-)
create mode 100644 include/linux/clk/scmi.h
--
2.43.0
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH/RFC 1/9] firmware: arm_scmi: Replace scmi_power_proto_ops.name_get() by .info_get()
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
The SCMI power domain protocol operations structure does not provide a
.info_get() method, unlike most other protocols. Instead, it provides
a .name_get() method.
Replace the .name_get() method by the .info_get() method, to increase
uniformity, and to prepare for returning more information.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/firmware/arm_scmi/power.c | 17 ++++++++---------
drivers/pmdomain/arm/scmi_pm_domain.c | 9 ++++++++-
include/linux/scmi_protocol.h | 10 +++++++---
3 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
index 28ef63a4ecc2e1df..a00f7c298efb74f9 100644
--- a/drivers/firmware/arm_scmi/power.c
+++ b/drivers/firmware/arm_scmi/power.c
@@ -63,7 +63,7 @@ struct power_dom_info {
bool state_set_sync;
bool state_set_async;
bool state_set_notify;
- char name[SCMI_MAX_STR_SIZE];
+ struct scmi_power_domain_info info;
};
struct scmi_power_info {
@@ -132,7 +132,7 @@ scmi_power_domain_attributes_get(const struct scmi_protocol_handle *ph,
SUPPORTS_STATE_SET_NOTIFY(flags);
dom_info->state_set_async = SUPPORTS_STATE_SET_ASYNC(flags);
dom_info->state_set_sync = SUPPORTS_STATE_SET_SYNC(flags);
- strscpy(dom_info->name, attr->name, SCMI_SHORT_NAME_MAX_SIZE);
+ strscpy(dom_info->info.name, attr->name, SCMI_SHORT_NAME_MAX_SIZE);
}
ph->xops->xfer_put(ph, t);
@@ -143,7 +143,7 @@ scmi_power_domain_attributes_get(const struct scmi_protocol_handle *ph,
if (!ret && PROTOCOL_REV_MAJOR(ph->version) >= 0x3 &&
SUPPORTS_EXTENDED_NAMES(flags)) {
ph->hops->extended_name_get(ph, POWER_DOMAIN_NAME_GET,
- domain, NULL, dom_info->name,
+ domain, NULL, dom_info->info.name,
SCMI_MAX_STR_SIZE);
}
@@ -199,23 +199,22 @@ static int scmi_power_num_domains_get(const struct scmi_protocol_handle *ph)
return pi->num_domains;
}
-static const char *
-scmi_power_name_get(const struct scmi_protocol_handle *ph,
- u32 domain)
+static const struct scmi_power_domain_info *
+scmi_power_info_get(const struct scmi_protocol_handle *ph, u32 domain)
{
struct scmi_power_info *pi = ph->get_priv(ph);
struct power_dom_info *dom;
if (domain >= pi->num_domains)
- return "unknown";
+ return NULL;
dom = pi->dom_info + domain;
- return dom->name;
+ return &dom->info;
}
static const struct scmi_power_proto_ops power_proto_ops = {
.num_domains_get = scmi_power_num_domains_get,
- .name_get = scmi_power_name_get,
+ .info_get = scmi_power_info_get,
.state_set = scmi_power_state_set,
.state_get = scmi_power_state_get,
};
diff --git a/drivers/pmdomain/arm/scmi_pm_domain.c b/drivers/pmdomain/arm/scmi_pm_domain.c
index 3d73aef21d2f9942..965592e828741b11 100644
--- a/drivers/pmdomain/arm/scmi_pm_domain.c
+++ b/drivers/pmdomain/arm/scmi_pm_domain.c
@@ -76,8 +76,15 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
return -ENOMEM;
for (i = 0; i < num_domains; i++, scmi_pd++) {
+ const struct scmi_power_domain_info *info;
u32 state;
+ info = power_ops->info_get(ph, i);
+ if (!info) {
+ dev_warn(dev, "failed to get info for domain %d\n", i);
+ continue;
+ }
+
if (power_ops->state_get(ph, i, &state)) {
dev_warn(dev, "failed to get state for domain %d\n", i);
continue;
@@ -93,7 +100,7 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
scmi_pd->domain = i;
scmi_pd->ph = ph;
- scmi_pd->name = power_ops->name_get(ph, i);
+ scmi_pd->name = info->name;
scmi_pd->genpd.name = scmi_pd->name;
scmi_pd->genpd.power_off = scmi_pd_power_off;
scmi_pd->genpd.power_on = scmi_pd_power_on;
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 5ab73b1ab9aa4fa8..1c17515ba45d1fd4 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -191,19 +191,23 @@ struct scmi_perf_proto_ops {
enum scmi_power_scale (*power_scale_get)(const struct scmi_protocol_handle *ph);
};
+struct scmi_power_domain_info {
+ char name[SCMI_MAX_STR_SIZE];
+};
+
/**
* struct scmi_power_proto_ops - represents the various operations provided
* by SCMI Power Protocol
*
* @num_domains_get: get the count of power domains provided by SCMI
- * @name_get: gets the name of a power domain
+ * @info_get: gets the information of the specified power domain
* @state_set: sets the power state of a power domain
* @state_get: gets the power state of a power domain
*/
struct scmi_power_proto_ops {
int (*num_domains_get)(const struct scmi_protocol_handle *ph);
- const char *(*name_get)(const struct scmi_protocol_handle *ph,
- u32 domain);
+ const struct scmi_power_domain_info __must_check *(*info_get)
+ (const struct scmi_protocol_handle *ph, u32 domain);
#define SCMI_POWER_STATE_TYPE_SHIFT 30
#define SCMI_POWER_STATE_ID_MASK (BIT(28) - 1)
#define SCMI_POWER_STATE_PARAM(type, id) \
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 2/9] firmware: arm_scmi: Advertize always-on power domains
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
A power domains indicates in its attribute flags if it supports setting
its power state synchronously and/or asynchronously. If none of them is
supported, it must be an always-on power domain.
Make this information available to SCMI protocol drivers, so they can
make use of it.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
drivers/firmware/arm_scmi/power.c | 4 ++++
include/linux/scmi_protocol.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/firmware/arm_scmi/power.c b/drivers/firmware/arm_scmi/power.c
index a00f7c298efb74f9..11ca8c9965110b5a 100644
--- a/drivers/firmware/arm_scmi/power.c
+++ b/drivers/firmware/arm_scmi/power.c
@@ -8,6 +8,7 @@
#define pr_fmt(fmt) "SCMI Notifications POWER - " fmt
#include <linux/module.h>
+#include <linux/pm_domain.h>
#include <linux/scmi_protocol.h>
#include "protocols.h"
@@ -147,6 +148,9 @@ scmi_power_domain_attributes_get(const struct scmi_protocol_handle *ph,
SCMI_MAX_STR_SIZE);
}
+ if (!ret && !dom_info->state_set_async && !dom_info->state_set_sync)
+ dom_info->info.genpd_flags |= GENPD_FLAG_ALWAYS_ON;
+
return ret;
}
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 1c17515ba45d1fd4..1d55374bc8cdcc72 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -193,6 +193,7 @@ struct scmi_perf_proto_ops {
struct scmi_power_domain_info {
char name[SCMI_MAX_STR_SIZE];
+ unsigned int genpd_flags;
};
/**
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 3/9] pmdomain: arm: scmi: Add always-on support
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
Extend the PM domain flags with the flags advertized by the SCMI core.
For now this is limited to GENPD_FLAG_ALWAYS_ON.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
Questions:
- Should the power_ops->state_get() call be skipped in case of an
always-on domain, and state just be force to
SCMI_POWER_STATE_GENERIC_ON instead?
- Should the power_ops->state_set() call be skipped in case of an
always-on domain? Or might this cause issues with some firmware
implementations?
Skipping these calls may avoid adding quirk code later...
---
drivers/pmdomain/arm/scmi_pm_domain.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/pmdomain/arm/scmi_pm_domain.c b/drivers/pmdomain/arm/scmi_pm_domain.c
index 965592e828741b11..8e67f971c707e121 100644
--- a/drivers/pmdomain/arm/scmi_pm_domain.c
+++ b/drivers/pmdomain/arm/scmi_pm_domain.c
@@ -104,7 +104,8 @@ static int scmi_pm_domain_probe(struct scmi_device *sdev)
scmi_pd->genpd.name = scmi_pd->name;
scmi_pd->genpd.power_off = scmi_pd_power_off;
scmi_pd->genpd.power_on = scmi_pd_power_on;
- scmi_pd->genpd.flags = GENPD_FLAG_ACTIVE_WAKEUP;
+ scmi_pd->genpd.flags = GENPD_FLAG_ACTIVE_WAKEUP |
+ info->genpd_flags;
pm_genpd_init(&scmi_pd->genpd, NULL,
state == SCMI_POWER_STATE_GENERIC_OFF);
--
2.43.0
^ permalink raw reply related
* [PATCH/RFC 4/9] firmware: arm_scmi: Add a flag for power-management clocks
From: Geert Uytterhoeven @ 2026-06-11 13:02 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Michael Turquette, Stephen Boyd, Brian Masney,
Ulf Hansson
Cc: arm-scmi, linux-arm-kernel, devicetree, linux-clk, linux-pm,
linux-renesas-soc, linux-kernel, Geert Uytterhoeven
In-Reply-To: <cover.1781171705.git.geert+renesas@glider.be>
Power management of on-SoC modules is typically handled through two
methods: module power control and module clock gating. The former is
exposed as an SCMI power domain, the latter as an SCMI clock.
Add a flag to indicate if a clock is intended for power-management of a
hardware module.
As the SCMI clock protocol does not support advertizing power-management
clocks yet, this flag can only be set by a quirk.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
include/linux/scmi_protocol.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 1d55374bc8cdcc72..c98e0add25f0c6c6 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -55,6 +55,7 @@ struct scmi_clock_info {
bool rate_ctrl_forbidden;
bool parent_ctrl_forbidden;
bool extended_config;
+ bool pm_clk;
u64 min_rate;
u64 max_rate;
int num_parents;
--
2.43.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