* Re: [PATCH V7 1/6] dt-bindings: power: supply: sgm41542: document sgm41542
From: Chris Morgan @ 2026-06-11 16:47 UTC (permalink / raw)
To: Rob Herring
Cc: Chris Morgan, linux-rockchip, devicetree, xsf, sre, simona,
airlied, tzimmermann, mripard, maarten.lankhorst, jesszhan0024,
neil.armstrong, heiko, conor+dt, krzk+dt
In-Reply-To: <20260611163613.GA2922314-robh@kernel.org>
On Thu, Jun 11, 2026 at 11:36:13AM -0500, Rob Herring wrote:
> On Wed, Jun 10, 2026 at 09:44:02AM -0500, Chris Morgan wrote:
> > From: Chris Morgan <macromorgan@hotmail.com>
> >
> > Document the SG Micro sgm41542 battery charger/boost converter.
> > The parameters of input-current-limit-microamp and
> > input-voltage-limit-microvolt are defined as such since they are in
> > common use among multiple bindings currently.
> >
> > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
>
> Missing Conor's reviewed-by.
> > ---
> > .../power/supply/sgmicro,sgm41542.yaml | 96 +++++++++++++++++++
> > 1 file changed, 96 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/power/supply/sgmicro,sgm41542.yaml
I'm sorry, somehow I accidentally dropped it. If I need a V8 I'll be
sure to include it, unless you want me to submit a V8 to add it?
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Shivendra Pratap @ 2026-06-11 16:44 UTC (permalink / raw)
To: Lee Jones
Cc: Bartosz Golaszewski, Sebastian Reichel, Mark Rutland,
Lorenzo Pieralisi, Rafael J. Wysocki, Daniel Lezcano,
Christian Loehle, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Arnd Bergmann,
Souvik Chakravarty, Andy Yan, Matthias Brugger, John Stultz,
Moritz Fischer, Sudeep Holla, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-kernel, devicetree, Florian Fainelli,
Krzysztof Kozlowski, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Greg Kroah-Hartman, Kathiravan Thirumoorthy, Srinivas Kandagatla,
Bartosz Golaszewski
In-Reply-To: <20260611164211.GD1212816@google.com>
On 11-06-2026 22:12, Lee Jones wrote:
> /* Sashiko Automation: Reviewed (0 Findings) */
>
> On Thu, 04 Jun 2026, Shivendra Pratap wrote:
>
>>
>>
>> On 25-05-2026 15:04, Shivendra Pratap wrote:
>>>
>>>
>>> On 22-05-2026 14:38, Bartosz Golaszewski wrote:
>>>> On Thu, May 21, 2026 at 6:27 PM Lee Jones <lee@kernel.org> wrote:
>>>>>
>>>>> On Thu, 21 May 2026, Bartosz Golaszewski wrote:
>>>>>
>>>>>> On Thu, May 21, 2026 at 3:24 PM Lee Jones <lee@kernel.org> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I suggested it because of its flexibility. The alternative I had in
>>>>>>>> mind is something like a new field in mfd_cell:
>>>>>>>>
>>>>>>>> const char *cell_node_name;
>>>>>>>>
>>>>>>>> Which - if set - would tell MFD to look up an fwnode
>>>>>>>> that's a child of
>>>>>>>> the parent device's node by name - as it may not have a compatible.
>>>>>>>
>>>>>>> Remind me why the chlid device can't look-up its own fwnode?
>>>>>>>
>>>>>>
>>>>>> Oh sure it can, but should it? I'm not sure it's logically sound to
>>>>>> have the child device reach into the parent, look up the fwnode and
>>>>>> then assign it to itself after it's already attached to the driver.
>>>>>> This should be done at the subsystem level before the device is
>>>>>> registered.
>>>>>
>>>>> Leaf drivers reach back into the parent all the time.
>>>>>
>>>>
>>>> But drivers don't generally assign firmware nodes to devices they are
>>>> already bound to. This is racy as in probe() the device is already
>>>> visible to the system. There's no synchronization of device property
>>>> access - properties are assumed to be read-only for a registered
>>>> device.
>>>
>>> thanks Bart/Lee. Any pointers to take this from here?
>>
>> Hi Lee,
>>
>> To take this patchset forward, it would be helpful to get your views on
>> fwnode based addition in mfd-core. Maybe, a member like "*named_fwnode" in
>> mfd-core and then a lookup logic, or any alternatives?
>
> Can you please make your best pick and resubmit the set please?
>
> I'll comment on a fresh set with fresh eyes.
sure. thanks.
thanks,
Shivendra
^ permalink raw reply
* Re: [PATCH v22 08/13] mfd: core: Add firmware-node support to MFD cells
From: Lee Jones @ 2026-06-11 16:42 UTC (permalink / raw)
To: Shivendra Pratap
Cc: Bartosz Golaszewski, Sebastian Reichel, Mark Rutland,
Lorenzo Pieralisi, Rafael J. Wysocki, Daniel Lezcano,
Christian Loehle, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Arnd Bergmann,
Souvik Chakravarty, Andy Yan, Matthias Brugger, John Stultz,
Moritz Fischer, Sudeep Holla, linux-pm, linux-kernel,
linux-arm-msm, linux-arm-kernel, devicetree, Florian Fainelli,
Krzysztof Kozlowski, Dmitry Baryshkov, Mukesh Ojha, Andre Draszik,
Greg Kroah-Hartman, Kathiravan Thirumoorthy, Srinivas Kandagatla,
Bartosz Golaszewski
In-Reply-To: <81680397-3bbd-4f66-9166-546c8fe753fc@oss.qualcomm.com>
/* Sashiko Automation: Reviewed (0 Findings) */
On Thu, 04 Jun 2026, Shivendra Pratap wrote:
>
>
> On 25-05-2026 15:04, Shivendra Pratap wrote:
> >
> >
> > On 22-05-2026 14:38, Bartosz Golaszewski wrote:
> > > On Thu, May 21, 2026 at 6:27 PM Lee Jones <lee@kernel.org> wrote:
> > > >
> > > > On Thu, 21 May 2026, Bartosz Golaszewski wrote:
> > > >
> > > > > On Thu, May 21, 2026 at 3:24 PM Lee Jones <lee@kernel.org> wrote:
> > > > > >
> > > > > > >
> > > > > > > I suggested it because of its flexibility. The alternative I had in
> > > > > > > mind is something like a new field in mfd_cell:
> > > > > > >
> > > > > > > const char *cell_node_name;
> > > > > > >
> > > > > > > Which - if set - would tell MFD to look up an fwnode
> > > > > > > that's a child of
> > > > > > > the parent device's node by name - as it may not have a compatible.
> > > > > >
> > > > > > Remind me why the chlid device can't look-up its own fwnode?
> > > > > >
> > > > >
> > > > > Oh sure it can, but should it? I'm not sure it's logically sound to
> > > > > have the child device reach into the parent, look up the fwnode and
> > > > > then assign it to itself after it's already attached to the driver.
> > > > > This should be done at the subsystem level before the device is
> > > > > registered.
> > > >
> > > > Leaf drivers reach back into the parent all the time.
> > > >
> > >
> > > But drivers don't generally assign firmware nodes to devices they are
> > > already bound to. This is racy as in probe() the device is already
> > > visible to the system. There's no synchronization of device property
> > > access - properties are assumed to be read-only for a registered
> > > device.
> >
> > thanks Bart/Lee. Any pointers to take this from here?
>
> Hi Lee,
>
> To take this patchset forward, it would be helpful to get your views on
> fwnode based addition in mfd-core. Maybe, a member like "*named_fwnode" in
> mfd-core and then a lookup logic, or any alternatives?
Can you please make your best pick and resubmit the set please?
I'll comment on a fresh set with fresh eyes.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v7 4/8] mfd: khadas-mcu: Add support for VIM4 MCU variant
From: Lee Jones @ 2026-06-11 16:40 UTC (permalink / raw)
To: linux-kernel-dev
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Andi Shyti, Kevin Hilman, Jerome Brunet, Martin Blumenstingl,
Beniamino Galvani, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Liam Girdwood, Mark Brown, linux-amlogic, devicetree,
linux-kernel, linux-i2c, linux-arm-kernel, linux-pm
In-Reply-To: <20260603-add-mcu-fan-khadas-vim4-v7-4-594ba8a965d8@aliel.fr>
/* Sashiko Automation: Reviewed (0 Findings) */
On Wed, 03 Jun 2026, Ronald Claveau via B4 Relay wrote:
> From: Ronald Claveau <linux-kernel-dev@aliel.fr>
>
> Refactor probe() to use per-variant values
> instead of hardcoded globals.
>
> Add dedicated regmap configuration for the VIM4 MCU,
> with its own volatile/writeable registers.
>
> Add the fan control register
> (0–100 levels vs 0–3 for previous supported boards).
>
> Add a new compatible string "khadas,vim4-mcu".
>
> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
> ---
> drivers/mfd/khadas-mcu.c | 115 ++++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 99 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mfd/khadas-mcu.c b/drivers/mfd/khadas-mcu.c
> index ba981a7886921..1bf260729d73b 100644
> --- a/drivers/mfd/khadas-mcu.c
> +++ b/drivers/mfd/khadas-mcu.c
> @@ -75,47 +75,129 @@ static const struct regmap_config khadas_mcu_regmap_config = {
> .cache_type = REGCACHE_MAPLE,
> };
>
> -static struct mfd_cell khadas_mcu_fan_cells[] = {
> +static const struct khadas_mcu_fan_pdata khadas_mcu_fan_pdata = {
> + .fan_reg = KHADAS_MCU_CMD_FAN_STATUS_CTRL_REG,
> + .max_level = 3, /* Fan speed: 0 = off, 1 = low, 2 = medium, 3 = high */
Instead of this comment, you could always just define the value(s)?
> +};
> +
> +static const struct mfd_cell khadas_mcu_fan_cells[] = {
> /* VIM1/2 Rev13+ and VIM3 only */
> - { .name = "khadas-mcu-fan-ctrl", },
> + {
> + .name = "khadas-mcu-fan-ctrl",
> + .platform_data = &khadas_mcu_fan_pdata,
> + .pdata_size = sizeof(khadas_mcu_fan_pdata),
No need to attempt to align the '=' like this, please.
> + },
> };
>
> -static struct mfd_cell khadas_mcu_cells[] = {
> +static const struct mfd_cell khadas_mcu_cells[] = {
> { .name = "khadas-mcu-user-mem", },
> };
>
> +static bool khadas_mcu_vim4_reg_volatile(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case KHADAS_MCU_PWR_OFF_CMD_REG:
> + case KHADAS_MCU_VIM4_REST_CONF_REG:
> + case KHADAS_MCU_WOL_INIT_START_REG:
> + case KHADAS_MCU_VIM4_LED_ON_RAM_REG:
> + case KHADAS_MCU_VIM4_FAN_CTRL_REG:
> + case KHADAS_MCU_VIM4_WDT_EN_REG:
> + case KHADAS_MCU_VIM4_SYS_RST_REG:
> + return true;
> + default:
> + return false;
> + }
> +}
> +
> +static bool khadas_mcu_vim4_reg_writeable(struct device *dev, unsigned int reg)
> +{
> + switch (reg) {
> + case KHADAS_MCU_VERSION_0_REG:
> + case KHADAS_MCU_VERSION_1_REG:
> + case KHADAS_MCU_SHUTDOWN_NORMAL_STATUS_REG:
> + return false;
> + default:
> + return true;
> + }
> +}
> +
> +static const struct regmap_config khadas_mcu_vim4_regmap_config = {
> + .reg_bits = 8,
> + .reg_stride = 1,
> + .val_bits = 8,
> + .max_register = KHADAS_MCU_VIM4_SYS_RST_REG,
> + .volatile_reg = khadas_mcu_vim4_reg_volatile,
> + .writeable_reg = khadas_mcu_vim4_reg_writeable,
> + .cache_type = REGCACHE_MAPLE,
> +};
> +
> +static const struct khadas_mcu_fan_pdata khadas_vim4_fan_pdata = {
> + .fan_reg = KHADAS_MCU_VIM4_FAN_CTRL_REG,
> + .max_level = 0x64,
> +};
> +
> +static const struct mfd_cell khadas_mcu_vim4_cells[] = {
> + {
> + .name = "khadas-mcu-fan-ctrl",
> + .platform_data = &khadas_vim4_fan_pdata,
> + .pdata_size = sizeof(khadas_vim4_fan_pdata),
> + },
> +};
> +
> static int khadas_mcu_probe(struct i2c_client *client)
> {
> + const struct mfd_cell *cells, *fan_cells;
> + const struct regmap_config *regmap_cfg;
> struct device *dev = &client->dev;
> + int ncells, nfan_cells, ret;
> struct khadas_mcu *ddata;
> - int ret;
>
> ddata = devm_kzalloc(dev, sizeof(*ddata), GFP_KERNEL);
> if (!ddata)
> return -ENOMEM;
>
> + switch ((uintptr_t)i2c_get_match_data(client)) {
> + case KHADAS_MCU_GENERIC:
> + regmap_cfg = &khadas_mcu_regmap_config;
> + cells = khadas_mcu_cells;
> + ncells = ARRAY_SIZE(khadas_mcu_cells);
> + fan_cells = khadas_mcu_fan_cells;
> + nfan_cells = ARRAY_SIZE(khadas_mcu_fan_cells);
> + break;
> + case KHADAS_MCU_VIM4:
> + regmap_cfg = &khadas_mcu_vim4_regmap_config;
> + cells = NULL;
> + ncells = 0;
> + fan_cells = khadas_mcu_vim4_cells;
> + nfan_cells = ARRAY_SIZE(khadas_mcu_vim4_cells);
I'm not as offended by this as I thought I would be!
> + break;
> + default:
> + return -ENODEV;
> + }
> +
> i2c_set_clientdata(client, ddata);
>
> ddata->dev = dev;
>
> - ddata->regmap = devm_regmap_init_i2c(client, &khadas_mcu_regmap_config);
> + ddata->regmap = devm_regmap_init_i2c(client, regmap_cfg);
> if (IS_ERR(ddata->regmap)) {
> ret = PTR_ERR(ddata->regmap);
> - dev_err(dev, "Failed to allocate register map: %d\n", ret);
> - return ret;
> + return dev_err_probe(dev, ret, "Failed to allocate register map\n");
> }
>
> - ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
> - khadas_mcu_cells,
> - ARRAY_SIZE(khadas_mcu_cells),
> - NULL, 0, NULL);
> - if (ret)
> - return ret;
> + if (cells && ncells) {
> + ret = devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
> + cells,
> + ncells,
> + NULL, 0, NULL);
> + if (ret)
> + return ret;
> + }
>
> if (of_property_present(dev->of_node, "#cooling-cells"))
> return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE,
> - khadas_mcu_fan_cells,
> - ARRAY_SIZE(khadas_mcu_fan_cells),
> + fan_cells,
> + nfan_cells,
> NULL, 0, NULL);
>
> return 0;
> @@ -123,7 +205,8 @@ static int khadas_mcu_probe(struct i2c_client *client)
>
> #ifdef CONFIG_OF
> static const struct of_device_id khadas_mcu_of_match[] = {
> - { .compatible = "khadas,mcu", },
> + { .compatible = "khadas,mcu", .data = (void *)KHADAS_MCU_GENERIC },
> + { .compatible = "khadas,vim4-mcu", .data = (void *)KHADAS_MCU_VIM4 },
> {},
> };
> MODULE_DEVICE_TABLE(of, khadas_mcu_of_match);
>
> --
> 2.49.0
>
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: hwmon: pmbus: Add bindings for Silergy SQ24860
From: Rob Herring @ 2026-06-11 16:38 UTC (permalink / raw)
To: Ziming Zhu
Cc: Guenter Roeck, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, linux-hwmon, devicetree, linux-kernel, linux-doc,
Ziming Zhu
In-Reply-To: <20260611074335.4415-2-zmzhu0630@163.com>
On Thu, Jun 11, 2026 at 03:43:33PM +0800, Ziming Zhu wrote:
> From: Ziming Zhu <ziming.zhu@silergycorp.com>
>
> Add devicetree binding documentation for the Silergy SQ24860 eFuse.
>
> The device is a PMBus hardware monitoring device which reports voltage,
> current, power, and temperature telemetry. The board-specific IMON
> resistor value is described with silergy,rimon-micro-ohms.
>
> Signed-off-by: Ziming Zhu <ziming.zhu@silergycorp.com>
Missing Conor's reviewed-by.
> ---
> .../bindings/hwmon/pmbus/silergy,sq24860.yaml | 74 +++++++++++++++++++
> 1 file changed, 74 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/silergy,sq24860.yaml
^ permalink raw reply
* Re: [PATCH 3/4] mfd: mt6397-core: add mt6323 AUXADC support
From: Lee Jones @ 2026-06-11 16:37 UTC (permalink / raw)
To: rva333
Cc: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, linux-iio, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260602-mt6323-adc-v1-3-68ec737508ee@protonmail.com>
Interesting. Has this been considered?
/* Sashiko Automation: Issues Found (1 Findings) */
On Tue, 02 Jun 2026, Roman Vivchar via B4 Relay wrote:
> From: Roman Vivchar <rva333@protonmail.com>
>
> The mt6323 PMIC includes an AUXADC. Register the AUXADC in the mt6323
> devices array to allow the corresponding driver to probe using compatible
> string.
>
> Tested-by: Ben Grisdale <bengris32@protonmail.ch> # Amazon Echo Dot (2nd Generation)
> Signed-off-by: Roman Vivchar <rva333@protonmail.com>
> ---
> drivers/mfd/mt6397-core.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/mfd/mt6397-core.c b/drivers/mfd/mt6397-core.c
> index 3e58d0764c7e..013b0857fb54 100644
> --- a/drivers/mfd/mt6397-core.c
> +++ b/drivers/mfd/mt6397-core.c
> @@ -125,6 +125,9 @@ static const struct resource mt6323_pwrc_resources[] = {
>
> static const struct mfd_cell mt6323_devs[] = {
> {
> + .name = "mt6323-auxadc",
> + .of_compatible = "mediatek,mt6323-auxadc",
[Severity: High]
Does adding this compatible string expose an unhandled edge case in the
auxadc driver?
If this device is instantiated directly from a Device Tree without an MFD
parent (e.g., at the DT root), dev->parent could be the platform bus
(which has a NULL parent) or NULL itself.
Looking at mt6323_auxadc_probe() in drivers/iio/adc/mt6323-auxadc.c:
regmap = dev_get_regmap(dev->parent->parent, NULL);
Could blindly dereferencing dev->parent->parent here, or passing a NULL
device to dev_get_regmap() (which calls devres_find()), result in a
kernel oops if probed as a root node?
> + }, {
> .name = "mt6323-rtc",
> .num_resources = ARRAY_SIZE(mt6323_rtc_resources),
> .resources = mt6323_rtc_resources,
>
> --
> 2.54.0
>
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH V7 1/6] dt-bindings: power: supply: sgm41542: document sgm41542
From: Rob Herring @ 2026-06-11 16:36 UTC (permalink / raw)
To: Chris Morgan
Cc: linux-rockchip, devicetree, xsf, sre, simona, airlied,
tzimmermann, mripard, maarten.lankhorst, jesszhan0024,
neil.armstrong, heiko, conor+dt, krzk+dt, Chris Morgan
In-Reply-To: <20260610144407.438846-2-macroalpha82@gmail.com>
On Wed, Jun 10, 2026 at 09:44:02AM -0500, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Document the SG Micro sgm41542 battery charger/boost converter.
> The parameters of input-current-limit-microamp and
> input-voltage-limit-microvolt are defined as such since they are in
> common use among multiple bindings currently.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Missing Conor's reviewed-by.
> ---
> .../power/supply/sgmicro,sgm41542.yaml | 96 +++++++++++++++++++
> 1 file changed, 96 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/power/supply/sgmicro,sgm41542.yaml
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: mfd: syscon: Drop custom select for older dtschema
From: Rob Herring @ 2026-06-11 16:31 UTC (permalink / raw)
To: Conor Dooley
Cc: Krzysztof Kozlowski, Lee Jones, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno, Jacky Huang,
Shan-Chun Hung, Geert Uytterhoeven, Magnus Damm, Heiko Stuebner,
Aaro Koskinen, Andreas Kemnade, Kevin Hilman, Roger Quadros,
Tony Lindgren, devicetree, linux-kernel, linux-arm-kernel,
linux-mediatek, linux-renesas-soc, linux-rockchip, linux-omap
In-Reply-To: <20260609-vertical-antarctic-e18a7ec91685@spud>
On Tue, Jun 09, 2026 at 05:28:21PM +0100, Conor Dooley wrote:
> On Mon, Jun 08, 2026 at 10:44:25PM +0200, Krzysztof Kozlowski wrote:
> > Older dtschema <2024.02 required custom select to avoid applying this
> > binding to anything having "syscon" compatible. That's not the case
> > anymore and this additional select has two headaches:
> >
> > 1. Duplicates all the compatibles listed in the schema.
> >
> > 2. Is error-prone, because it requires contributor to add the compatible
> > in two places, otherwise the schema will be silently ignored.
> > The select list already misses mentioning compatibles:
> > mediatek,mt8365-infracfg-nao and renesas,r9a08g046-lvds-cmn (with the
> > latter being reverted for different reasons).
> >
> > This requires bumping minimum dtschema requirement to v2024.04, which
> > feels old enough to be a safe requirement.
>
> I agree, seems reasonable enough given it's a jump from 2023.09 and not
> some large jump.
> The diff is nice too!
> I assume Rob will be taking it, but just in case..
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
I expect Lee to take this. I suspect syscon.yaml has other conflicting
changes.
Rob
^ permalink raw reply
* Re: [PATCH V11 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Chris Morgan @ 2026-06-11 16:31 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <20260611172022.4d138820@jic23-huawei>
On Thu, Jun 11, 2026 at 05:20:22PM +0100, Jonathan Cameron wrote:
> On Thu, 11 Jun 2026 09:32:38 -0500
> Chris Morgan <macromorgan@hotmail.com> wrote:
>
> > On Thu, Jun 11, 2026 at 12:09:43PM +0100, Jonathan Cameron wrote:
> > > On Wed, 10 Jun 2026 12:54:47 -0500
> > > Chris Morgan <macroalpha82@gmail.com> wrote:
> > >
> > > > From: Chris Morgan <macromorgan@hotmail.com>
> > > >
> > > > Add the core component of a new inv_icm42607 driver. This includes
> > > > a few setup functions and the full register definition in the
> > > > header file.
> > > >
> > > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > > Hi Chris,
> > >
> > > A couple more minor things from a fresh read.
> > >
> > > Thanks
> > >
> > > Jonathan
> > >
> > > > ---
> > > > drivers/iio/imu/inv_icm42607/inv_icm42607.h | 334 ++++++++++++++++++
> > > > .../iio/imu/inv_icm42607/inv_icm42607_core.c | 197 +++++++++++
> > > > 2 files changed, 531 insertions(+)
> > > > create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > > create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > >
> > > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > > new file mode 100644
> > > > index 000000000000..716fc0f1c3fd
> > > > --- /dev/null
> > > > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > >
> > > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > > new file mode 100644
> > > > index 000000000000..334264120b42
> > > > --- /dev/null
> > > > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > >
> > > > +
> > > > +static int inv_icm42607_setup(struct inv_icm42607_state *st,
> > > > + inv_icm42607_bus_setup inv_icm42607_bus_setup)
> > > > +{
> > > > + const struct device *dev = regmap_get_device(st->map);
> > > > + unsigned int val;
> > > > + int ret;
> > > > +
> > > > + ret = regmap_read(st->map, INV_ICM42607_REG_WHOAMI, &val);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + /* Warn, but don't fail. */
> > > > + if (val != st->hw->whoami)
> > > > + dev_warn(dev, "Unknown whoami %#02x expected %#02x (%s)\n",
> > > > + val, st->hw->whoami, st->hw->name);
> > > > +
> > > > + ret = regmap_write(st->map, INV_ICM42607_REG_SIGNAL_PATH_RESET,
> > > > + INV_ICM42607_SIGNAL_PATH_RESET_SOFT_RESET);
> > > > + if (ret)
> > > > + return ret;
> > > > +
> > > > + fsleep(INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC);
> > > > +
> > > > + /*
> > > > + * No polling interval specified in datasheet, so use reset time as
> > > > + * polling interval and 10x reset time as timeout period.
> > > > + */
> > > > + ret = regmap_read_poll_timeout(st->map, INV_ICM42607_REG_INT_STATUS,
> > > > + val, val & INV_ICM42607_INT_STATUS_RESET_DONE,
> > > > + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC),
> > > > + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC * 10));
> > > > + if (ret)
> > > > + return dev_err_probe(dev, ret,
> > > > + "reset error, reset done bit not set\n");
> > > > +
> > > > + /* Sync the regcache again after a reset. */
> > > > + regcache_mark_dirty(st->map);
> > > > + ret = regcache_sync(st->map);
> > >
> > > Sashiko raised the point that you don't have a writeable register list for the regmap
> > > and so potentially we at very least write a bunch of stuff that isn't needed.
> > > I doubt it's actually a problem or you would have seen it, but nice little optimization
> > > to reduce what is written.
> >
> > I will add such a list, I'd put it in patch 4 unless you think I should
> > merge patch 3 and 4 to make the driver compileable at the first commit
> > of code (will push the number of lines to the ~850/900 range though).
> >
> I'm fine with them split but don't mind if Andy prefers them combined.
> His comment on adding a COMPILE_TEST option would allow that to be
> built, but it is a bit odd to do it just for that purpose.
>
> Jonathan
>
I'm going to add the i2c stuff to this series, and then do the SPI
on the next patch. That should add only a little bit to this one but
still ensure the very first (code) commit has something to compile.
I'm going to avoid doing COMPILE_TEST unless collectively you all
think I should.
I'm still racing to try and get this one done before the merge
window opens up, but I'm pretty sure it's already too late at
this point. I'll refrain from submitting updates once the window opens
though.
Thank you,
Chris
^ permalink raw reply
* Re: [PATCH v10 5/9] mfd: p3h2x4x: Add driver for NXP P3H2x4x i3c hub and on-die regulator
From: Lee Jones @ 2026-06-11 16:30 UTC (permalink / raw)
To: Lakshay Piplani
Cc: linux-kernel, linux-i3c, alexandre.belloni, krzk+dt, robh,
conor+dt, devicetree, broonie, Frank.Li, lgirdwood, vikash.bansal,
priyanka.jain, aman.kumarpandey
In-Reply-To: <20260525064209.2263045-6-lakshay.piplani@nxp.com>
On Mon, 25 May 2026, Lakshay Piplani wrote:
> From: Aman Kumar Pandey <aman.kumarpandey@nxp.com>
>
> Add core MFD support for the NXP P3H2x4x (P3H2440/P3H2441/P3H2840/P3H2841)
> family of multiport I3C hub devices. These devices connect to a host via
> I3C/I2C/SMBus and expose multiple downstream target ports.
>
> Signed-off-by: Aman Kumar Pandey <aman.kumarpandey@nxp.com>
> Signed-off-by: Vikash Bansal <vikash.bansal@nxp.com>
> Signed-off-by: Lakshay Piplani <lakshay.piplani@nxp.com>
>
> ---
> Changes in v10:
> - Drop redundant is_p3h2x4x_in_i3c flag
>
> Changes in v9:
> - Renamed macros to follow consistent uppercase naming conventions
> - Made REGMAP selects in the P3H2X4X MFD Kconfig conditional,
> to avoid I3C/I2C dependency issues
>
> Changes in v8:
> - No change
>
> Changes in v7:
> - Use new config I3C_OR_I2C
>
> Changes in v6:
> - No change
>
> Changes in v5:
> - Corrected the ordering in the Makefile and Kconfig for MFD_P3H2X4X
> - Updated dev_err_probe() for regmap_init failure.
> - Updated module description
>
> Changes in v4:
> - Split the driver into three separate patches(mfd, regulator and I3C hub)
> - Added support for NXP P3H2x4x MFD functionality
> ---
> ---
> MAINTAINERS | 2 +
> drivers/mfd/Kconfig | 13 ++++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/p3h2840.c | 122 ++++++++++++++++++++++++++++++++++++
> include/linux/i3c/device.h | 1 +
> include/linux/mfd/p3h2840.h | 26 ++++++++
> 6 files changed, 165 insertions(+)
> create mode 100644 drivers/mfd/p3h2840.c
> create mode 100644 include/linux/mfd/p3h2840.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8ae231f67460..25e578dd74dd 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -19311,6 +19311,8 @@ L: linux-kernel@vger.kernel.org
> L: linux-i3c-owner@lists.infradead.org
> S: Maintained
> F: Documentation/devicetree/bindings/i3c/nxp,p3h2840.yaml
> +F: drivers/mfd/p3h2840.c
> +F: include/linux/mfd/p3h2840.h
>
> NXP PF5300/PF5301/PF5302 PMIC REGULATOR DEVICE DRIVER
> M: Woodrow Douglass <wdouglass@carnegierobotics.com>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 7192c9d1d268..405b50c3c77b 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -617,6 +617,19 @@ config MFD_MX25_TSADC
> i.MX25 processors. They consist of a conversion queue for general
> purpose ADC and a queue for Touchscreens.
>
> +config MFD_P3H2X4X
> + tristate "NXP P3H2X4X I3C Hub Device"
> + depends on I3C_OR_I2C
> + select MFD_CORE
> + select REGMAP_I3C if I3C
> + select REGMAP_I2C if I2C
> + help
> + Enable Support for NXP P3H244x/P3H284x I3C HUB device using I3C/I2C
> + communication interface.
> +
> + This driver provides support for I3C hub and regulator, each subdriver
> + can be enabled independently depending on the required functionality.
> +
> config MFD_PF1550
> tristate "NXP PF1550 PMIC Support"
> depends on I2C=y && OF
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index e75e8045c28a..a284b22c7b13 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -122,6 +122,7 @@ obj-$(CONFIG_MFD_MC13XXX) += mc13xxx-core.o
> obj-$(CONFIG_MFD_MC13XXX_SPI) += mc13xxx-spi.o
> obj-$(CONFIG_MFD_MC13XXX_I2C) += mc13xxx-i2c.o
>
> +obj-$(CONFIG_MFD_P3H2X4X) += p3h2840.o
> obj-$(CONFIG_MFD_PF1550) += pf1550.o
>
> obj-$(CONFIG_MFD_NCT6694) += nct6694.o
> diff --git a/drivers/mfd/p3h2840.c b/drivers/mfd/p3h2840.c
> new file mode 100644
> index 000000000000..9bd8cf6980f1
> --- /dev/null
> +++ b/drivers/mfd/p3h2840.c
> @@ -0,0 +1,122 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2025-2026 NXP
> + * P3H2X4X i3c hub and regulator device.
> + */
> +
> +#include <linux/i2c.h>
> +#include <linux/i3c/master.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/p3h2840.h>
> +#include <linux/regmap.h>
> +
> +static const struct mfd_cell p3h2x4x_devs[] = {
> + {
> + .name = "p3h2x4x-regulator",
> + },
> + {
> + .name = "p3h2x4x-i3c-hub",
> + },
> +};
MFD_CELL_NAME()
> +static const struct regmap_config p3h2x4x_regmap_config = {
> + .reg_bits = P3H2X4X_REG_BITS,
> + .val_bits = P3H2X4X_VAL_BITS,
> + .max_register = 0xFF,
> +};
> +
> +static int p3h2x4x_device_probe_i3c(struct i3c_device *i3cdev)
> +{
> + struct p3h2x4x_dev *p3h2x4x;
struct p3h2x4x *ddata;
> + int ret;
> +
> + p3h2x4x = devm_kzalloc(&i3cdev->dev, sizeof(*p3h2x4x), GFP_KERNEL);
> + if (!p3h2x4x)
> + return -ENOMEM;
> +
> + i3cdev_set_drvdata(i3cdev, p3h2x4x);
> +
> + p3h2x4x->regmap = devm_regmap_init_i3c(i3cdev, &p3h2x4x_regmap_config);
> + if (IS_ERR(p3h2x4x->regmap))
> + return dev_err_probe(&i3cdev->dev, PTR_ERR(p3h2x4x->regmap),
> + "Failed to register HUB regmap\n");
> + p3h2x4x->i3cdev = i3cdev;
Where is this used again?
> +
> + ret = devm_mfd_add_devices(&i3cdev->dev, PLATFORM_DEVID_AUTO,
> + p3h2x4x_devs, ARRAY_SIZE(p3h2x4x_devs),
> + NULL, 0, NULL);
> + if (ret)
> + return dev_err_probe(&i3cdev->dev, ret, "Failed to add sub devices\n");
> +
> + return 0;
> +}
> +
> +static int p3h2x4x_device_probe_i2c(struct i2c_client *client)
> +{
> + struct p3h2x4x_dev *p3h2x4x;
> + int ret;
> +
> + p3h2x4x = devm_kzalloc(&client->dev, sizeof(*p3h2x4x), GFP_KERNEL);
> + if (!p3h2x4x)
> + return -ENOMEM;
> +
> + i2c_set_clientdata(client, p3h2x4x);
> +
> + p3h2x4x->regmap = devm_regmap_init_i2c(client, &p3h2x4x_regmap_config);
> + if (IS_ERR(p3h2x4x->regmap))
> + return dev_err_probe(&client->dev, PTR_ERR(p3h2x4x->regmap),
> + "Failed to register HUB regmap\n");
> +
> + p3h2x4x->i3cdev = NULL;
> +
> + ret = devm_mfd_add_devices(&client->dev, PLATFORM_DEVID_AUTO,
> + p3h2x4x_devs, ARRAY_SIZE(p3h2x4x_devs),
> + NULL, 0, NULL);
> + if (ret)
> + return dev_err_probe(&client->dev, ret, "Failed to add sub devices\n");
> +
> + return 0;
> +}
> +
> +static const struct i3c_device_id p3h2x4x_i3c_ids[] = {
> + I3C_CLASS(I3C_DCR_HUB, NULL),
> + { /* sentinel */ },
> +};
> +MODULE_DEVICE_TABLE(i3c, p3h2x4x_i3c_ids);
> +
> +static const struct i2c_device_id p3h2x4x_i2c_id_table[] = {
> + { "nxp-i3c-hub" },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(i2c, p3h2x4x_i2c_id_table);
> +
> +static const struct of_device_id p3h2x4x_i2c_of_match[] = {
> + { .compatible = "nxp,p3h2840", },
> + { /* sentinel */ }
> +};
> +MODULE_DEVICE_TABLE(of, p3h2x4x_i2c_of_match);
> +
> +static struct i3c_driver p3h2x4x_i3c = {
> + .driver = {
> + .name = "p3h2x4x_i3c_drv",
> + },
'-'s only and drop the "_drv" part.
> + .probe = p3h2x4x_device_probe_i3c,
> + .id_table = p3h2x4x_i3c_ids,
> +};
> +
> +static struct i2c_driver p3h2x4x_i2c = {
> + .driver = {
> + .name = "p3h2x4x_i2c_drv",
> + .of_match_table = p3h2x4x_i2c_of_match,
> + },
> + .probe = p3h2x4x_device_probe_i2c,
> + .id_table = p3h2x4x_i2c_id_table,
> +};
> +
Remove this line.
> +module_i3c_i2c_driver(p3h2x4x_i3c, &p3h2x4x_i2c);
> +
> +MODULE_AUTHOR("Aman Kumar Pandey <aman.kumarpandey@nxp.com>");
> +MODULE_AUTHOR("Vikash Bansal <vikash.bansal@nxp.com>");
> +MODULE_AUTHOR("Lakshay Piplani <lakshay.piplani@nxp.com>");
> +MODULE_DESCRIPTION("NXP P3H2X4X I3C HUB multi function driver");
> +MODULE_LICENSE("GPL");
> diff --git a/include/linux/i3c/device.h b/include/linux/i3c/device.h
> index 971d53349b6f..6188082599dd 100644
> --- a/include/linux/i3c/device.h
> +++ b/include/linux/i3c/device.h
> @@ -85,6 +85,7 @@ struct i3c_xfer {
> */
> enum i3c_dcr {
> I3C_DCR_GENERIC_DEVICE = 0,
> + I3C_DCR_HUB = 194,
> };
>
> #define I3C_PID_MANUF_ID(pid) (((pid) & GENMASK_ULL(47, 33)) >> 33)
> diff --git a/include/linux/mfd/p3h2840.h b/include/linux/mfd/p3h2840.h
> new file mode 100644
> index 000000000000..18ff15f9e2d9
> --- /dev/null
> +++ b/include/linux/mfd/p3h2840.h
> @@ -0,0 +1,26 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2025-2026 NXP
> + * This header file contain private Reg address and its bit mapping etc.
> + */
"This header file contains register definitions and bit masks for the P3H2X4X."
> +
> +#ifndef _LINUX_MFD_P3H2840_H
> +#define _LINUX_MFD_P3H2840_H
> +
> +#include <linux/types.h>
> +
> +/* Device Configuration Registers */
> +#define P3H2X4X_DEV_REG_PROTECTION_CODE 0x10
> +#define P3H2X4X_REGISTERS_LOCK_CODE 0x00
> +#define P3H2X4X_REGISTERS_UNLOCK_CODE 0x69
> +#define P3H2X4X_CP1_REGISTERS_UNLOCK_CODE 0x6a
> +
> +/* Reg config for Regmap */
> +#define P3H2X4X_REG_BITS 8
> +#define P3H2X4X_VAL_BITS 8
> +
> +struct p3h2x4x_dev {
> + struct i3c_device *i3cdev;
> + struct regmap *regmap;
> +};
> +#endif /* _LINUX_MFD_P3H2840_H */
> --
> 2.25.1
>
--
Lee Jones
^ permalink raw reply
* Re: [PATCH 0/2] Add support for the QMP PCIe PHYs in Qualcomm IPQ9650
From: Kathiravan Thirumoorthy @ 2026-06-11 16:22 UTC (permalink / raw)
To: Vinod Koul
Cc: Neil Armstrong, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <aiqYtowP2DQt7Jw0@vaman>
On 6/11/2026 4:45 PM, Vinod Koul wrote:
> On 02-06-26, 14:40, Kathiravan Thirumoorthy wrote:
>> Qualcomm's IPQ9650 SoC has 3 Gen3 dual lane and 2 Gen3 single lane
>> controllers with the QMP PHYs. Unlike the PHYs in the other IPQ SoC,
>> refgen supply is needed to bringup the PHYs. Both single and dual lane
>> shares the same HW init sequence. So reuse the tables.
>>
>> Document the compatible along with refgen supply and add the phy driver
>> support for it.
> Please rebase this on phy-next tomorrow. It does not apply for me due to
> changes applied ealier today
There is a discussion open about the supplies[1]. Once that is
clarified, let me re spin. So we can take up this series for v7.3 once
that discussion is closed.
[1]
https://lore.kernel.org/linux-arm-msm/aiqYtowP2DQt7Jw0@vaman/T/#m37a571fac0c77fd00f6379ad9a2414b60431820b
>
^ permalink raw reply
* Re: [PATCH V11 3/9] iio: imu: inv_icm42607: Add inv_icm42607 Core Driver
From: Jonathan Cameron @ 2026-06-11 16:20 UTC (permalink / raw)
To: Chris Morgan
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <PH0PR19MB9973387E29375D4E8F28C6B9D9A51B2@PH0PR19MB997338.namprd19.prod.outlook.com>
On Thu, 11 Jun 2026 09:32:38 -0500
Chris Morgan <macromorgan@hotmail.com> wrote:
> On Thu, Jun 11, 2026 at 12:09:43PM +0100, Jonathan Cameron wrote:
> > On Wed, 10 Jun 2026 12:54:47 -0500
> > Chris Morgan <macroalpha82@gmail.com> wrote:
> >
> > > From: Chris Morgan <macromorgan@hotmail.com>
> > >
> > > Add the core component of a new inv_icm42607 driver. This includes
> > > a few setup functions and the full register definition in the
> > > header file.
> > >
> > > Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> > Hi Chris,
> >
> > A couple more minor things from a fresh read.
> >
> > Thanks
> >
> > Jonathan
> >
> > > ---
> > > drivers/iio/imu/inv_icm42607/inv_icm42607.h | 334 ++++++++++++++++++
> > > .../iio/imu/inv_icm42607/inv_icm42607_core.c | 197 +++++++++++
> > > 2 files changed, 531 insertions(+)
> > > create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > >
> > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> > > new file mode 100644
> > > index 000000000000..716fc0f1c3fd
> > > --- /dev/null
> > > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> >
> > > diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> > > new file mode 100644
> > > index 000000000000..334264120b42
> > > --- /dev/null
> > > +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> >
> > > +
> > > +static int inv_icm42607_setup(struct inv_icm42607_state *st,
> > > + inv_icm42607_bus_setup inv_icm42607_bus_setup)
> > > +{
> > > + const struct device *dev = regmap_get_device(st->map);
> > > + unsigned int val;
> > > + int ret;
> > > +
> > > + ret = regmap_read(st->map, INV_ICM42607_REG_WHOAMI, &val);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + /* Warn, but don't fail. */
> > > + if (val != st->hw->whoami)
> > > + dev_warn(dev, "Unknown whoami %#02x expected %#02x (%s)\n",
> > > + val, st->hw->whoami, st->hw->name);
> > > +
> > > + ret = regmap_write(st->map, INV_ICM42607_REG_SIGNAL_PATH_RESET,
> > > + INV_ICM42607_SIGNAL_PATH_RESET_SOFT_RESET);
> > > + if (ret)
> > > + return ret;
> > > +
> > > + fsleep(INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC);
> > > +
> > > + /*
> > > + * No polling interval specified in datasheet, so use reset time as
> > > + * polling interval and 10x reset time as timeout period.
> > > + */
> > > + ret = regmap_read_poll_timeout(st->map, INV_ICM42607_REG_INT_STATUS,
> > > + val, val & INV_ICM42607_INT_STATUS_RESET_DONE,
> > > + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC),
> > > + (INV_ICM42607_RESET_TIME_MS * USEC_PER_MSEC * 10));
> > > + if (ret)
> > > + return dev_err_probe(dev, ret,
> > > + "reset error, reset done bit not set\n");
> > > +
> > > + /* Sync the regcache again after a reset. */
> > > + regcache_mark_dirty(st->map);
> > > + ret = regcache_sync(st->map);
> >
> > Sashiko raised the point that you don't have a writeable register list for the regmap
> > and so potentially we at very least write a bunch of stuff that isn't needed.
> > I doubt it's actually a problem or you would have seen it, but nice little optimization
> > to reduce what is written.
>
> I will add such a list, I'd put it in patch 4 unless you think I should
> merge patch 3 and 4 to make the driver compileable at the first commit
> of code (will push the number of lines to the ~850/900 range though).
>
I'm fine with them split but don't mind if Andy prefers them combined.
His comment on adding a COMPILE_TEST option would allow that to be
built, but it is a bit odd to do it just for that purpose.
Jonathan
^ permalink raw reply
* Re: [PATCH V11 0/9] Add Invensense ICM42607
From: Jonathan Cameron @ 2026-06-11 16:18 UTC (permalink / raw)
To: Chris Morgan
Cc: Chris Morgan, linux-iio, andy, nuno.sa, dlechner,
jean-baptiste.maneyrol, linux-rockchip, devicetree, heiko,
conor+dt, krzk+dt, robh, andriy.shevchenko
In-Reply-To: <PH0PR19MB99733845CDEFA1D8441200B60FA51B2@PH0PR19MB997338.namprd19.prod.outlook.com>
On Thu, 11 Jun 2026 09:36:08 -0500
Chris Morgan <macromorgan@hotmail.com> wrote:
> On Thu, Jun 11, 2026 at 11:59:38AM +0100, Jonathan Cameron wrote:
> > On Wed, 10 Jun 2026 12:54:44 -0500
> > Chris Morgan <macroalpha82@gmail.com> wrote:
> >
> > > From: Chris Morgan <macromorgan@hotmail.com>
> > >
> > > Add support for the ICM42607 IMU. This sensor shares the same
> > > functionality but a different register layout with the existing
> > > ICM42600.
> > >
> > > This driver should work with the ICM42607 and ICM42607P over both I2C
> > > and SPI, however only the ICM42607P over I2C could be tested.
> > Hi Chris,
> >
> > Just a quick reminder to check if there is useful feedback at:
> > https://sashiko.dev/#/patchset/20260610175455.19006-1-macroalpha82%40gmail.com
> >
> > I didn't look into most of the but the last one about no avail mask bits
> > being set for gyro channels was easy to verify as correct and suggests
> > a testing gap.
> >
> > Jonathan
> >
>
> Thanks, I've been checking sashiko on every patch and trying to address
> what it says to the best of my ability. Honestly I wish there was a way
> to simply push to that bot first and *then* push to the mailing list
> once I've resolved all of its comments.
Agreed - that would be helpful. I believe it is possible to run locally
against a bunch of LLMs - I recall seeing something saying there
is a git repo with scripts. No idea if that is possible with a free level though.
Jonathan
>
> Thank you,
> Chris
^ permalink raw reply
* Re: [PATCH 2/4] nvmem: add mt6323 PMIC EFUSE driver
From: Andy Shevchenko @ 2026-06-11 16:13 UTC (permalink / raw)
To: rva333
Cc: Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Srinivas Kandagatla, Andy Shevchenko,
Jonathan Cameron, linux-pm, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <20260611-mt6323-nvmem-v1-2-b5e1b9ce51f2@protonmail.com>
On Thu, Jun 11, 2026 at 1:21 PM Roman Vivchar via B4 Relay
<devnull+rva333.protonmail.com@kernel.org> wrote:
>
> Add support for the EFUSE controller found in the Mediatek MT6323 PMIC.
> The MT6323 EFUSE stores 24 bytes of hardware-related data, such as
> thermal sensor calibration values.
Reviewed-by: Andy Shevchenko <andy@kernel.org>
...
> +static int mt6323_efuse_read(void *context, unsigned int offset, void *val,
> + size_t bytes)
> +{
> + struct regmap *map = context;
> + u32 tmp;
> + u16 *buf = val;
> + int ret;
Perhaps reversed xmas tree order? And it's actually better to see
assignments first.
> + /*
> + * A manual loop using regmap_read is required because PWRAP is not
> + * a continuous MMIO space, but rather a FSM that doesn't implement the
> + * necessary read callback for the regmap_read_raw and regmap_read_bulk
> + * functions.
> + */
> + for (size_t i = 0; i < bytes; i += sizeof(*buf)) {
> + ret = regmap_read(map, MT6323_EFUSE_DOUT_BASE + offset + i, &tmp);
> + if (ret)
> + return ret;
> +
> + *buf++ = tmp;
> + }
> +
> + return 0;
> +}
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: shikra: Add BAM-DMUX support
From: Vishnu Santhosh @ 2026-06-11 16:01 UTC (permalink / raw)
To: Stephan Gerhold
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
bjorn.andersson, chris.lew
In-Reply-To: <aip3_fyE8tMtJZIW@linaro.org>
On 11-06-2026 02:25 pm, Stephan Gerhold wrote:
> On Thu, Jun 11, 2026 at 02:11:59PM +0530, Vishnu Santhosh wrote:
>> + bam_dmux: bam-dmux {
>> + compatible = "qcom,bam-dmux";
>> +
>> + interrupts-extended = <&modem_smsm 1 IRQ_TYPE_EDGE_BOTH>,
>> + <&modem_smsm 11 IRQ_TYPE_EDGE_BOTH>;
>> + interrupt-names = "pc",
>> + "pc-ack";
>> +
>> + qcom,smem-states = <&apps_smsm 1>,
>> + <&apps_smsm 11>;
>> + qcom,smem-state-names = "pc",
>> + "pc-ack";
>> +
>> + dmas = <&bam_dmux_dma 4>, <&bam_dmux_dma 5>;
>> + dma-names = "tx", "rx";
>> + };
> This should be a child node of the modem remoteproc. See msm8916.dtsi
> for example.
Thanks for the context! We actually referenced msm8916.dtsi during
bring-up and initially placed bam-dmux as a
remoteproc child. We then hit the issue that the driver was not probing
at all. After some digging, we realized
that qcom_q6v5_mss.c (used by msm8916) explicitly calls
of_platform_device_create() for its qcom,bam-dmux child,
but qcom_q6v5_pas.c which Shikra uses has no such logic, so the platform
device was never created.
There was a prior attempt to fix this generically by adding
of_platform_populate() to qcom_q6v5.c
(https://lore.kernel.org/all/20251223123227.1317244-3-gaurav.kohli@oss.qualcomm.com/),
but it was blocked
because GLINK/SMD edge child nodes would also get spurious platform
devices registered for them.
That series remains unresolved at v1.
Since your driver already manages modem lifecycle independently via SMSM
state bits without remoteproc dependency,
we moved it to the root level where of_platform_populate() picks it up
at boot, and everything worked.
Would love to get your suggestion on whether this approach is welcomed,
since it needs zero driver changes.
Thanks,
Vishnu
^ permalink raw reply
* Re: [PATCH 2/2] iio: adc: Add TI ADS1220 driver
From: Andy Shevchenko @ 2026-06-11 16:00 UTC (permalink / raw)
To: Nguyen Minh Tien
Cc: Jonathan Cameron, 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, Jun 10, 2026 at 10:13:42PM +0700, Nguyen Minh Tien 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.
...
+ array_size.h
> +#include <linux/bitfield.h>
> +#include <linux/bits.h>
Instead you should use bitops.h due to sign_extend32() and other calls.
> +#include <linux/completion.h>
> +#include <linux/delay.h>
> +#include <linux/err.h>
> +#include <linux/interrupt.h>
> +#include <linux/log2.h>
+ math.h // DIV_ROUND_UP()
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/property.h>
> +#include <linux/regulator/consumer.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/spi/spi.h>
+ types.h // bool, uXX
> +#include <linux/units.h>
> +#include <linux/unaligned.h>
...
> +/* Worst-case single conversion: 20 SPS => 50 ms, plus margin. */
> +#define ADS1220_CONV_TIMEOUT_MS 100
> +#define ADS1220_CONV_MARGIN_US 2000
2 * USEC_PER_MSEC (will need time.h to be included).
...
> +#define ADS1220_SUSPEND_DELAY_MS 2000
2 * MSEC_PER_SEC respectively.
...
> +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);
sizeof(st->tx) ?
> +}
...
> +static unsigned int ads1220_datarate_to_code(unsigned int datarate)
unsigned? See below why.
> +{
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(ads1220_datarates); i++)
for (unsigned int i = 0; i < ARRAY_SIZE(ads1220_datarates); i++)
> + if (ads1220_datarates[i] == datarate)
> + return i;
> +
> + return 0;
This is wrong. It should return -ENOENT or so to be distinct with the 0 index.
> +}
...
> +static int ads1220_read_sample(struct ads1220_state *st, unsigned int datarate,
> + int *val)
> +{
> + int ret;
> +
> + if (st->spi->irq) {
> + unsigned long timeout = msecs_to_jiffies(ADS1220_CONV_TIMEOUT_MS);
> +
> + if (!wait_for_completion_timeout(&st->completion, timeout))
> + return -ETIMEDOUT;
> + } else {
> + /*
> + * No DRDY interrupt: wait for the conversion to finish. In
> + * single-shot mode the result stays latched until the next
> + * START, so waiting longer than one conversion is harmless;
> + * wait two periods plus a margin to comfortably cover the
> + * oscillator start-up and its tolerance.
> + */
> + fsleep(2 * DIV_ROUND_UP(MICRO, datarate) + ADS1220_CONV_MARGIN_US);
USEC_PER_SEC instead of MICRO?
> + }
> +
> + /*
> + * Once DRDY is low the result can be clocked out directly, MSB first,
> + * without an RDATA command (datasheet section 8.5.4).
> + */
> + ret = spi_read(st->spi, st->rx, ADS1220_DATA_BYTES);
> + if (ret)
> + return ret;
> +
> + *val = sign_extend32(get_unaligned_be24(st->rx), ADS1220_DATA_BITS - 1);
> +
> + 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;
Use PM_ACQUIRE_*() macros instead.
> + 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);
Even without above this is not needed, it's implied by the below call.
> + pm_runtime_put_autosuspend(dev);
> +
> + return ret;
> +}
...
> +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;
Why signed? And why not to make it local to the loop?
> + 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;
> + 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;
> + }
> + }
Can't ads1220_datarate_to_code() be used?
> + return -EINVAL;
> + default:
> + return -EINVAL;
> + }
> +}
...
> +static int ads1220_debugfs_reg_access(struct iio_dev *indio_dev,
> + unsigned int reg, unsigned int writeval,
> + unsigned int *readval)
> +{
> + struct ads1220_state *st = iio_priv(indio_dev);
> + u8 val;
> + int ret;
> + if (reg > ADS1220_MAX_REG)
> + return -EINVAL;
How is this not a dead code? Forgot to set .max_register in regmap configuration?
> + if (readval) {
> + ret = ads1220_read_reg(st, reg, &val);
> + if (ret)
> + return ret;
> + *readval = val;
> + return 0;
> + }
> +
> + return ads1220_write_reg(st, reg, writeval);
> +}
...
> +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);
Dup.
> + 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);
Dup.
> + pm_runtime_put_autosuspend(dev);
> +
> + return 0;
> +}
...
> + 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,
Please, fill all the gaps to make this look nice tabulator.
Also you may drop the first _MAX_AIN, compiler will be able to get this.
> + };
...
> + const struct iio_chan_spec ads1220_channel = {
Why is this not static?
> + .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,
> + },
> + };
...
> + unsigned int num_channels, i = 0;
Split assignment and definition to avoid subtle mistakes in the future.
Move the assignment closer to it's first user
(device_for_each_child_node_scoped() loop AFAICS).
> + 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)
in_range() ?
> + return dev_err_probe(dev, -EINVAL,
> + "Invalid channel count %u (max %u)\n",
> + st->num_channels_cfg, ADS1220_MAX_CHANNELS);
> + /* One extra channel for the timestamp. */
> + num_channels = st->num_channels_cfg + 1;
> + channels = devm_kcalloc(dev, num_channels, sizeof(*channels),
> + GFP_KERNEL);
I would leave it on a single line.
> + 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);
ARRAY_SIZE()
> + 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,
ain[1] may be uninitialised here. Why not supply the pointer to the array since
you anyway supply '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;
> + chan->channel = ain[0];
> + chan->address = i;
> + chan->scan_index = i;
> + if (differential) {
> + chan->channel2 = ain[1];
> + chan->differential = 1;
> + }
> +
> + i++;
> + }
...
> + st->vref_uV = devm_regulator_get_enable_read_voltage(dev, "vref");
> + if (st->vref_uV >= 0) {
Does Vref == 0 make any sense?
> + 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")) {
> + 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;
> + }
...
> + if (spi->irq > 0) {
> + ret = devm_request_irq(dev, spi->irq, ads1220_irq_handler,
> + IRQF_NO_THREAD, "ads1220", indio_dev);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to request irq\n");
No dup messages, just
return ret;
here.
> + st->trig = devm_iio_trigger_alloc(dev, "%s-dev%d",
> + indio_dev->name,
> + iio_device_id(indio_dev));
> + if (!st->trig)
> + return -ENOMEM;
> +
> + st->trig->ops = &ads1220_trigger_ops;
> + iio_trigger_set_drvdata(st->trig, indio_dev);
> +
> + ret = devm_iio_trigger_register(dev, st->trig);
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to register trigger\n");
> + }
...
> +static const struct spi_device_id ads1220_id[] = {
> + { "ads1220" },
Use C99 initialisers.
> + { }
> +};
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v7 2/2] ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
From: Andrew Lunn @ 2026-06-11 15:57 UTC (permalink / raw)
To: Kyle Hsieh
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel
In-Reply-To: <20260611-ventura2_initial_dts-v7-2-a61d8902bc5f@gmail.com>
> + /* Marvell 88E6393X EEPROM */
> + eeprom@50 {
> + compatible = "atmel,24c64";
> + reg = <0x50>;
> + };
How is this on both a host I2C bus, and the switches I2C bus? Are you
using multi-master? Is there a GPIO to hold the switch in reset while
the host access the EEPROM?
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/3] dt-bindings: iio: accel: convert lis302 binding to YAML schema (v2)
From: sashiko-bot @ 2026-06-11 15:52 UTC (permalink / raw)
To: Md Shofiqul Islam; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260611154105.3727-4-shofiqtest@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [Medium] The `st,lis302dl` compatible string causes a dual-schema validation conflict.
- [Medium] The properties `st,click-double-{x,y,z}` were incorrectly omitted during the YAML schema conversion.
- [Medium] The schema fails to document the upstream legacy typo `st,click-click-time-limit`, causing validation failures.
- [Medium] The `compatible` property incorrectly rejects upstream fallback combinations by strictly requiring a single exact match.
--
commit a5b5cff978006324100603bf6453cf1d3ceba157
Author: Md Shofiqul Islam <shofiqtest@gmail.com>
dt-bindings: iio: accel: convert lis302 binding to YAML schema (v2)
Replace the plain text lis302.txt with a YAML schema for the
LIS302DL/LIS3LV02D accelerometer family.
> diff --git a/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> new file mode 100644
> index 0000000000000..8a19aa1085215
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
> @@ -0,0 +1,320 @@
[ ... ]
> +properties:
> + compatible:
> + oneOf:
> + - description: I2C variant (original part)
> + const: st,lis302dl
[Severity: Medium]
Since this compatible string is also present in the existing
Documentation/devicetree/bindings/iio/st,st-sensors.yaml, does adding it here
cause a dual-schema validation conflict?
If device tree nodes use st,lis302dl and include the legacy properties
introduced in this new schema, they might fail dt_binding_check validation
against st,st-sensors.yaml because that schema strictly restricts properties.
> + - description: I2C variant (larger range)
> + const: st,lis3lv02d
> + - description: SPI variant; including the bus type in the compatible
> + string is a legacy naming error, do not copy for new bindings
> + const: st,lis302dl-spi
[Severity: Medium]
Will this strict oneOf and const definition incorrectly reject valid upstream
device trees that use a multiple-string fallback array?
Numerous upstream device trees (e.g., am335x-evm.dts, omap3-gta04a3.dts)
use a fallback array like:
compatible = "st,lis331dlh", "st,lis3lv02d";
A const rule fails against an array, which will cause these boards to fail
schema validation.
Should this be rewritten to support items lists?
[ ... ]
> + st,click-single-x:
> + type: boolean
> + deprecated: true
> + description: Enable single-click detection on X axis.
> +
> + st,click-single-y:
> + type: boolean
> + deprecated: true
> + description: Enable single-click detection on Y axis.
> +
> + st,click-single-z:
> + type: boolean
> + deprecated: true
> + description: Enable single-click detection on Z axis.
[Severity: Medium]
Were the properties st,click-double-{x,y,z} omitted from this conversion?
The original lis302.txt binding defined these properties, and the driver at
drivers/misc/lis3lv02d/lis3lv02d.c actively parses them via
of_property_read_bool().
Since the new schema specifies unevaluatedProperties: false, any device tree
correctly utilizing the double-click properties will now fail schema validation.
[ ... ]
> + st,click-thresh-y:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: See st,click-thresh-x.
> +
> + st,click-thresh-z:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: See st,click-thresh-x.
> +
> + st,click-time-limit:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + deprecated: true
> + description: Click time limit in 0.5ms steps (0-127).
[Severity: Medium]
Does the schema need to document the legacy typo st,click-click-time-limit
to prevent validation failures?
The conversion correctly maps this to st,click-time-limit, but upstream
device trees (e.g., arch/arm/boot/dts/ti/omap/omap3-gta04a3.dts) still use the
misspelled property.
Because unevaluatedProperties is set to false, dt_binding_check will now fail
for those boards.
Should this typo be accommodated similarly to how the st,click-thresh-x typo
was handled?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611154105.3727-1-shofiqtest@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v2 1/3] misc: lis3lv02d: set default click detection thresholds
From: sashiko-bot @ 2026-06-11 15:52 UTC (permalink / raw)
To: Md Shofiqul Islam; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260611154105.3727-2-shofiqtest@gmail.com>
Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
New issues:
- [High] The patch hardcodes a default click threshold instead of parsing the documented legacy DT property `st,click-thresh-*`, incorrectly overriding explicitly configured board values.
Pre-existing issues:
- [High] The dynamically allocated `struct lis3lv02d_platform_data` is leaked on probe error paths and device unbind.
- [High] The return value of `lis3lv02d_add_fs` is ignored, leading to an invalid pointer address generation and a kernel crash if device creation fails.
- [High] Sysfs hardware access occurs with a runtime PM usage count of zero, risking a race condition with device suspend.
--
commit e23e0f8c271ea91f741e5d3559287f33c9596b0d
Author: Md Shofiqul Islam <shofiqtest@gmail.com>
misc: lis3lv02d: set default click detection thresholds
This commit works around an issue where several upstream board DTS files
use an undocumented property name for click thresholds. It hardcodes a
default value of 10 during the driver's device tree initialization to
compensate for the driver reading a misspelled property name.
> diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c b/drivers/misc/lis3lv02d/lis3lv02d.c
> index 6957091ab6dee..245bb6249033b 100644
> --- a/drivers/misc/lis3lv02d/lis3lv02d.c
> +++ b/drivers/misc/lis3lv02d/lis3lv02d.c
> @@ -958,6 +958,14 @@ int lis3lv02d_init_dt(struct lis3lv02d *lis3)
> if (!pdata)
> return -ENOMEM;
[Severity: High]
This is a pre-existing issue, but does this code leak the allocated platform
data?
When pdata is dynamically allocated via kzalloc() earlier in
lis3lv02d_init_dt() and assigned to lis3_dev.pdata, there appears to be no
corresponding kfree() in the error teardown paths. For example, if the bus
probe fails in lis3lv02d_i2c_probe() due to -EPROBE_DEFER, the allocated
memory is never freed:
drivers/misc/lis3lv02d/lis3lv02d_i2c.c:lis3lv02d_i2c_probe() {
...
fail:
if (pdata && pdata->release_resources)
pdata->release_resources();
return ret;
}
Since lis3_dev is a static global variable, repeatedly probing and deferring
or unbinding and rebinding the driver could continuously leak memory.
>
> + /* Set sensible click threshold defaults. Several upstream board DTS
> + * files use the misspelled property "st,click-thresh-*" which the
> + * driver never reads, leaving these at zero. Default to 10 so those
> + * boards get working click detection without a DT change. */
> + pdata->click_thresh_x = 10;
> + pdata->click_thresh_y = 10;
> + pdata->click_thresh_z = 10;
[Severity: High]
Can hardcoding these defaults override explicitly configured board values?
The device tree binding documents st,click-thresh-x/y/z, but the driver
erroneously parses st,click-threshold-x/y/z. Instead of updating the driver
to parse both properties to respect the DT ABI, this applies an arbitrary
default of 10.
If a board correctly configures a different threshold, such as
st,click-thresh-x = <8>, will this explicit configuration be ignored and
silently forced to 10?
[ ... ]
[Severity: High]
This is a pre-existing issue, but will the lack of a return value check cause
a kernel crash if device creation fails?
In lis3lv02d_init_device(), lis3lv02d_add_fs() is called without checking
its return value:
drivers/misc/lis3lv02d/lis3lv02d.c:lis3lv02d_init_device() {
...
lis3lv02d_add_fs(lis3);
err = lis3lv02d_poweron(lis3);
...
}
If faux_device_create_with_groups() fails and returns NULL, lis3->fdev
remains NULL. When the code later calls lis3lv02d_joystick_enable(), it
computes &lis3->fdev->dev and assigns it to input_dev->dev.parent. The
offset calculation from a NULL pointer yields an invalid pointer, leading
to a NULL pointer dereference when the input subsystem accesses the parent
device.
[Severity: High]
This is a pre-existing issue, but is sysfs hardware accessed with a runtime
PM usage count of zero?
In sysfs attribute handlers like lis3lv02d_position_show(),
lis3lv02d_sysfs_poweron() is called before accessing the hardware:
drivers/misc/lis3lv02d/lis3lv02d.c:lis3lv02d_position_show() {
...
lis3lv02d_sysfs_poweron(lis3);
mutex_lock(&lis3->mutex);
lis3lv02d_get_xyz(lis3, &x, &y, &z);
...
}
However, lis3lv02d_sysfs_poweron() calls pm_runtime_get_sync(), but then
immediately drops the usage count via pm_runtime_put_noidle():
drivers/misc/lis3lv02d/lis3lv02d.c:lis3lv02d_sysfs_poweron() {
...
pm_runtime_put_noidle(lis3->pm_dev);
pm_schedule_suspend(lis3->pm_dev, LIS3_SYSFS_POWERDOWN_DELAY);
}
This drops the runtime PM usage count to 0 while the I2C/SPI registers
are actively being read. Could a concurrent system sleep physically power
off the device while communication is occurring, leading to bus lockups
or a kernel oops?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260611154105.3727-1-shofiqtest@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: Heikki Krogerus @ 2026-06-11 15:48 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Andy Shevchenko, Greg Kroah-Hartman, Daniel Scally, Sakari Ailus,
Rafael J. Wysocki, Danilo Krummrich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Alan Stern, linux-acpi, driver-core,
linux-pm, linux-usb, devicetree, linux-mediatek, linux-arm-kernel,
linux-kernel, Manivannan Sadhasivam, Chen-Yu Tsai
In-Reply-To: <CAMRc=MdRN7YitmMX8PknbzLh+MdsWm+dDg0MLtCVYOorqNobTw@mail.gmail.com>
On Thu, Jun 11, 2026 at 11:35:13AM +0200, Bartosz Golaszewski wrote:
> On Thu, Jun 11, 2026 at 10:37 AM Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> >
> > On Thu, Jun 11, 2026 at 04:20:58AM -0400, Bartosz Golaszewski wrote:
> > > On Wed, 10 Jun 2026 16:16:12 +0200, Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> said:
> > > > On Wed, Jun 10, 2026 at 04:40:39PM +0800, Chen-Yu Tsai wrote:
> > > >> When a USB hub port is connected to a connector in a firmware node
> > > >> graph, the port itself has a node in the graph.
> > > >>
> > > >> Associate the port's firmware node with the USB port's device,
> > > >> usb_port::dev. This is used in later changes for the M.2 slot power
> > > >> sequencing provider to match against the requesting port.
> > > >
> > > > Okay, would this affect ACPI-based systems? if so, how?
> > > > Can you elaborate on that, please?
> > >
> > > Is it possible that there's an ACPI device node associated with the port like
> > > on some DT systems? I don't think so and there should be no impact IMO but I
> > > also don't know enough about ACPI.
There are device nodes for the USB ports in ACPI, and I think they get
always assigned in drivers/usb/core/usb-acpi.c.
> > The API is agnostic. There is a possibility to have software nodes associated
> > with the port. I think the best is to be sure that ACPI-aware people who are
> > experts in USB will check this (Heikki?).
I can't say what's the impact from this patch - I'm not an expert with
this side of USB. Is there a danger that we end up overwriting the
ACPI node for the port, or something else?
> Even if there is a software node - it shouldn't really matter. It will
> just be assigned to the port device.
thanks,
--
heikki
^ permalink raw reply
* [PATCH v2 3/3] dt-bindings: iio: accel: convert lis302 binding to YAML schema (v2)
From: Md Shofiqul Islam @ 2026-06-11 15:41 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: jic23, robh, krzk+dt, conor+dt, linusw, linux-kernel,
Md Shofiqul Islam
In-Reply-To: <20260611154105.3727-1-shofiqtest@gmail.com>
Replace the plain text lis302.txt with a YAML schema for the
LIS302DL/LIS3LV02D accelerometer family.
Key changes from v1:
- Add a prominent WARNING in the description that this is a legacy
binding and must not be copied for new devices
- Add st,lis302dl compatible (used by Nokia N900 / omap3-n900.dts)
in addition to st,lis302dl-spi and st,lis3lv02d
- Document both supply naming conventions: Vdd-supply/Vdd_IO-supply
(legacy uppercase, used by most boards) and vdd-supply/vddio-supply
(modern lowercase, used by Nokia N900)
- Add mount-matrix support (used by Nokia N900)
- Add self-test limit properties st,min-limit-x/y/z and
st,max-limit-x/y/z (these legitimately belong in DT as they
encode per-board hardware tolerances)
- Mark all click/irq/wakeup/filter properties as deprecated=true.
They configure run-time driver behaviour, not hardware, and should
not appear in DT for new boards
- Add st,click-thresh-x/y/z as deprecated with an explicit note that
this is a misspelling present in several upstream boards; the driver
reads st,click-threshold-x/y/z and never reads the short form
- Remove driver path reference from description
- Use schema constraints (minimum/maximum) for axis remapping range
- Remove Jonathan Cameron as maintainer; use Linus Walleij who
already maintains the related st,st-sensors binding
- Use example based on actual upstream board (Nokia N900)
Boards using this as primary binding:
st,lis302dl: omap3-n900.dts
st,lis3lv02d: omap3-n950-n9.dtsi, am335x-pepper.dts
st,lis302dl-spi: pxa300-raumfeld-controller.dts
Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
---
.../devicetree/bindings/iio/accel/lis302.txt | 119 -------
.../bindings/iio/accel/st,lis302dl.yaml | 320 ++++++++++++++++++
2 files changed, 320 insertions(+), 119 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/accel/lis302.txt
create mode 100644 Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
diff --git a/Documentation/devicetree/bindings/iio/accel/lis302.txt b/Documentation/devicetree/bindings/iio/accel/lis302.txt
deleted file mode 100644
index 457539647f36..000000000000
--- a/Documentation/devicetree/bindings/iio/accel/lis302.txt
+++ /dev/null
@@ -1,119 +0,0 @@
-LIS302 accelerometer devicetree bindings
-
-This device is matched via its bus drivers, and has a number of properties
-that apply in on the generic device (independent from the bus).
-
-
-Required properties for the SPI bindings:
- - compatible: should be set to "st,lis3lv02d-spi"
- - reg: the chipselect index
- - spi-max-frequency: maximal bus speed, should be set to 1000000 unless
- constrained by external circuitry
- - interrupts: the interrupt generated by the device
-
-Required properties for the I2C bindings:
- - compatible: should be set to "st,lis3lv02d"
- - reg: i2c slave address
- - Vdd-supply: The input supply for Vdd
- - Vdd_IO-supply: The input supply for Vdd_IO
-
-
-Optional properties for all bus drivers:
-
- - st,click-single-{x,y,z}: if present, tells the device to issue an
- interrupt on single click events on the
- x/y/z axis.
- - st,click-double-{x,y,z}: if present, tells the device to issue an
- interrupt on double click events on the
- x/y/z axis.
- - st,click-thresh-{x,y,z}: set the x/y/z axis threshold
- - st,click-click-time-limit: click time limit, from 0 to 127.5msec
- with step of 0.5 msec
- - st,click-latency: click latency, from 0 to 255 msec with
- step of 1 msec.
- - st,click-window: click window, from 0 to 255 msec with
- step of 1 msec.
- - st,irq{1,2}-disable: disable IRQ 1/2
- - st,irq{1,2}-ff-wu-1: raise IRQ 1/2 on FF_WU_1 condition
- - st,irq{1,2}-ff-wu-2: raise IRQ 1/2 on FF_WU_2 condition
- - st,irq{1,2}-data-ready: raise IRQ 1/2 on data ready condition
- - st,irq{1,2}-click: raise IRQ 1/2 on click condition
- - st,irq-open-drain: consider IRQ lines open-drain
- - st,irq-active-low: make IRQ lines active low
- - st,wu-duration-1: duration register for Free-Fall/Wake-Up
- interrupt 1
- - st,wu-duration-2: duration register for Free-Fall/Wake-Up
- interrupt 2
- - st,wakeup-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
- upper/lower limit
- - st,wakeup-threshold: set wakeup threshold
- - st,wakeup2-{x,y,z}-{lo,hi}: set wakeup condition on x/y/z axis for
- upper/lower limit for second wakeup
- engine.
- - st,wakeup2-threshold: set wakeup threshold for second wakeup
- engine.
- - st,highpass-cutoff-hz=: 1, 2, 4 or 8 for 1Hz, 2Hz, 4Hz or 8Hz of
- highpass cut-off frequency
- - st,hipass{1,2}-disable: disable highpass 1/2.
- - st,default-rate=: set the default rate
- - st,axis-{x,y,z}=: set the axis to map to the three coordinates.
- Negative values can be used for inverted axis.
- - st,{min,max}-limit-{x,y,z} set the min/max limits for x/y/z axis
- (used by self-test)
-
-
-Example for a SPI device node:
-
- accelerometer@0 {
- compatible = "st,lis302dl-spi";
- reg = <0>;
- spi-max-frequency = <1000000>;
- interrupt-parent = <&gpio>;
- interrupts = <104 0>;
-
- st,click-single-x;
- st,click-single-y;
- st,click-single-z;
- st,click-thresh-x = <10>;
- st,click-thresh-y = <10>;
- st,click-thresh-z = <10>;
- st,irq1-click;
- st,irq2-click;
- st,wakeup-x-lo;
- st,wakeup-x-hi;
- st,wakeup-y-lo;
- st,wakeup-y-hi;
- st,wakeup-z-lo;
- st,wakeup-z-hi;
- };
-
-Example for a I2C device node:
-
- lis331dlh: accelerometer@18 {
- compatible = "st,lis331dlh", "st,lis3lv02d";
- reg = <0x18>;
- Vdd-supply = <&lis3_reg>;
- Vdd_IO-supply = <&lis3_reg>;
-
- st,click-single-x;
- st,click-single-y;
- st,click-single-z;
- st,click-thresh-x = <10>;
- st,click-thresh-y = <10>;
- st,click-thresh-z = <10>;
- st,irq1-click;
- st,irq2-click;
- st,wakeup-x-lo;
- st,wakeup-x-hi;
- st,wakeup-y-lo;
- st,wakeup-y-hi;
- st,wakeup-z-lo;
- st,wakeup-z-hi;
- st,min-limit-x = <120>;
- st,min-limit-y = <120>;
- st,min-limit-z = <140>;
- st,max-limit-x = <550>;
- st,max-limit-y = <550>;
- st,max-limit-z = <750>;
- };
-
diff --git a/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
new file mode 100644
index 000000000000..8a19aa108521
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
@@ -0,0 +1,320 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/accel/st,lis302dl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: STMicroelectronics LIS302DL/LIS3LV02D 3-Axis Accelerometer (Legacy Binding)
+
+description: |
+ WARNING: This is a legacy binding for hardware that predates modern DT
+ practices. It is documented as-found in upstream board files. Do NOT use
+ this as a template for new drivers or bindings.
+
+ The driver lives in drivers/misc/lis3lv02d, not in IIO. Many properties
+ listed here represent run-time driver configuration that would normally not
+ appear in device tree. They are documented here only because existing
+ upstream board DTS files use them.
+
+ Compatibles st,lis302dl-spi and st,lis3lv02d were previously listed as
+ deprecated in st,st-sensors.yaml. They are moved here with their actual
+ hardware configuration so validation works correctly.
+
+maintainers:
+ - Linus Walleij <linus.walleij@linaro.org>
+
+properties:
+ compatible:
+ oneOf:
+ - description: I2C variant (original part)
+ const: st,lis302dl
+ - description: I2C variant (larger range)
+ const: st,lis3lv02d
+ - description: SPI variant; including the bus type in the compatible
+ string is a legacy naming error, do not copy for new bindings
+ const: st,lis302dl-spi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ minItems: 1
+ maxItems: 2
+
+ Vdd-supply:
+ description: Main power supply (legacy uppercase name used by most boards).
+
+ Vdd_IO-supply:
+ description: I/O power supply (legacy uppercase name used by most boards).
+
+ vdd-supply:
+ description: Main power supply (modern lowercase name, used by omap3-n900).
+
+ vddio-supply:
+ description: I/O power supply (modern lowercase name, used by omap3-n900).
+
+ mount-matrix:
+ description: 3x3 mounting rotation matrix.
+
+ st,min-limit-x:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Minimum acceptable self-test delta for X axis.
+
+ st,min-limit-y:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Minimum acceptable self-test delta for Y axis.
+
+ st,min-limit-z:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Minimum acceptable self-test delta for Z axis.
+
+ st,max-limit-x:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Maximum acceptable self-test delta for X axis.
+
+ st,max-limit-y:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Maximum acceptable self-test delta for Y axis.
+
+ st,max-limit-z:
+ $ref: /schemas/types.yaml#/definitions/int32
+ description: Maximum acceptable self-test delta for Z axis.
+
+ # The following properties configure run-time driver behaviour and do not
+ # describe hardware. They are deprecated. Documented here only so that
+ # existing upstream board DTS files pass dt_binding_check.
+
+ st,click-single-x:
+ type: boolean
+ deprecated: true
+ description: Enable single-click detection on X axis.
+
+ st,click-single-y:
+ type: boolean
+ deprecated: true
+ description: Enable single-click detection on Y axis.
+
+ st,click-single-z:
+ type: boolean
+ deprecated: true
+ description: Enable single-click detection on Z axis.
+
+ st,click-threshold-x:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: Click threshold X axis. Driver default is used if absent.
+
+ st,click-threshold-y:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: Click threshold Y axis. Driver default is used if absent.
+
+ st,click-threshold-z:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: Click threshold Z axis. Driver default is used if absent.
+
+ st,click-thresh-x:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: |
+ Misspelling of st,click-threshold-x present in several upstream board
+ files. The driver does not read this property; it is silently ignored.
+ Documented here only to avoid dt_binding_check failures on those boards.
+
+ st,click-thresh-y:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: See st,click-thresh-x.
+
+ st,click-thresh-z:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: See st,click-thresh-x.
+
+ st,click-time-limit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: Click time limit in 0.5ms steps (0-127).
+
+ st,click-latency:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ description: Click latency in 1ms steps (0-255).
+
+ st,click-window:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+
+ st,irq1-click:
+ type: boolean
+ deprecated: true
+ st,irq2-click:
+ type: boolean
+ deprecated: true
+ st,irq1-ff-wu-1:
+ type: boolean
+ deprecated: true
+ st,irq1-ff-wu-2:
+ type: boolean
+ deprecated: true
+ st,irq2-ff-wu-1:
+ type: boolean
+ deprecated: true
+ st,irq2-ff-wu-2:
+ type: boolean
+ deprecated: true
+ st,irq1-data-ready:
+ type: boolean
+ deprecated: true
+ st,irq2-data-ready:
+ type: boolean
+ deprecated: true
+ st,irq1-disable:
+ type: boolean
+ deprecated: true
+ st,irq2-disable:
+ type: boolean
+ deprecated: true
+ st,irq-open-drain:
+ type: boolean
+ deprecated: true
+ st,irq-active-low:
+ type: boolean
+ deprecated: true
+
+ st,wakeup-x-lo:
+ type: boolean
+ deprecated: true
+ st,wakeup-x-hi:
+ type: boolean
+ deprecated: true
+ st,wakeup-y-lo:
+ type: boolean
+ deprecated: true
+ st,wakeup-y-hi:
+ type: boolean
+ deprecated: true
+ st,wakeup-z-lo:
+ type: boolean
+ deprecated: true
+ st,wakeup-z-hi:
+ type: boolean
+ deprecated: true
+ st,wakeup-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+
+ st,wakeup2-x-lo:
+ type: boolean
+ deprecated: true
+ st,wakeup2-x-hi:
+ type: boolean
+ deprecated: true
+ st,wakeup2-y-lo:
+ type: boolean
+ deprecated: true
+ st,wakeup2-y-hi:
+ type: boolean
+ deprecated: true
+ st,wakeup2-z-lo:
+ type: boolean
+ deprecated: true
+ st,wakeup2-z-hi:
+ type: boolean
+ deprecated: true
+ st,wakeup2-threshold:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+
+ st,wu-duration-1:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+ st,wu-duration-2:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+
+ st,highpass-cutoff-hz:
+ enum: [1, 2, 4, 8]
+ deprecated: true
+ st,hipass1-disable:
+ type: boolean
+ deprecated: true
+ st,hipass2-disable:
+ type: boolean
+ deprecated: true
+
+ st,default-rate:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ deprecated: true
+
+ st,axis-x:
+ $ref: /schemas/types.yaml#/definitions/int32
+ minimum: -3
+ maximum: 3
+ deprecated: true
+ description: Axis remapping. Replaced by mount-matrix.
+
+ st,axis-y:
+ $ref: /schemas/types.yaml#/definitions/int32
+ minimum: -3
+ maximum: 3
+ deprecated: true
+ description: Axis remapping. Replaced by mount-matrix.
+
+ st,axis-z:
+ $ref: /schemas/types.yaml#/definitions/int32
+ minimum: -3
+ maximum: 3
+ deprecated: true
+ description: Axis remapping. Replaced by mount-matrix.
+
+required:
+ - compatible
+ - reg
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@1d {
+ compatible = "st,lis302dl";
+ reg = <0x1d>;
+ vdd-supply = <&vaux1>;
+ vddio-supply = <&vio>;
+ interrupt-parent = <&gpio6>;
+ interrupts = <21 IRQ_TYPE_EDGE_RISING>,
+ <20 IRQ_TYPE_EDGE_RISING>;
+ mount-matrix = "-1", "0", "0",
+ "0", "1", "0",
+ "0", "0", "-1";
+ };
+ };
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ accelerometer@1 {
+ compatible = "st,lis302dl-spi";
+ reg = <1>;
+ spi-max-frequency = <1000000>;
+ interrupt-parent = <&gpio>;
+ interrupts = <104 IRQ_TYPE_EDGE_FALLING>;
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+ st,irq1-click;
+ st,irq2-click;
+ };
+ };
+...
--
2.51.1
^ permalink raw reply related
* [PATCH v2 2/3] dt-bindings: iio: st,st-sensors: remove lis302dl and lis3lv02d from deprecated list
From: Md Shofiqul Islam @ 2026-06-11 15:41 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: jic23, robh, krzk+dt, conor+dt, linusw, linux-kernel,
Md Shofiqul Islam
In-Reply-To: <20260611154105.3727-1-shofiqtest@gmail.com>
st,lis302dl-spi and st,lis3lv02d are being given their own binding in
Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml. Remove
them from the deprecated section of st,st-sensors.yaml to eliminate
the duplicate compatible string warnings reported by the kernel test
robot.
Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
---
Documentation/devicetree/bindings/iio/st,st-sensors.yaml | 6 ------
1 file changed, 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
index a1a958215cdb..ebe9041f6326 100644
--- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
+++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml
@@ -88,12 +88,6 @@ properties:
enum:
- st,lsm303d-imu
- st,lsm9ds0-imu
- - description: Deprecated bindings
- enum:
- - st,lis302dl-spi
- - st,lis3lv02d
- deprecated: true
-
reg:
maxItems: 1
--
2.51.1
^ permalink raw reply related
* [PATCH v2 1/3] misc: lis3lv02d: set default click detection thresholds
From: Md Shofiqul Islam @ 2026-06-11 15:41 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: jic23, robh, krzk+dt, conor+dt, linusw, linux-kernel,
Md Shofiqul Islam
In-Reply-To: <20260611154105.3727-1-shofiqtest@gmail.com>
Several upstream board DTS files use st,click-thresh-x/y/z (the name
documented in the old lis302.txt binding), but the driver reads
st,click-threshold-x/y/z. As a result those boards have had click
detection silently broken since the DT properties were added.
Set a default threshold of 10 for all three axes immediately after
the platform data allocation so those boards get working click
detection without requiring a DT change.
The DT reads for st,click-threshold-x/y/z are unchanged so boards
using the correct name can still override the default.
Fixes: 6a7740c7f5b2 ("lis3lv02d: add device-tree support")
Signed-off-by: Md Shofiqul Islam <shofiqtest@gmail.com>
---
drivers/misc/lis3lv02d/lis3lv02d.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/misc/lis3lv02d/lis3lv02d.c b/drivers/misc/lis3lv02d/lis3lv02d.c
index 21e8ad0a7444..6a028c1bf866 100644
--- a/drivers/misc/lis3lv02d/lis3lv02d.c
+++ b/drivers/misc/lis3lv02d/lis3lv02d.c
@@ -956,6 +956,14 @@ int lis3lv02d_init_dt(struct lis3lv02d *lis3)
if (!pdata)
return -ENOMEM;
+ /* Set sensible click threshold defaults. Several upstream board DTS
+ * files use the misspelled property "st,click-thresh-*" which the
+ * driver never reads, leaving these at zero. Default to 10 so those
+ * boards get working click detection without a DT change. */
+ pdata->click_thresh_x = 10;
+ pdata->click_thresh_y = 10;
+ pdata->click_thresh_z = 10;
+
if (of_property_read_bool(np, "st,click-single-x"))
pdata->click_flags |= LIS3_CLICK_SINGLE_X;
if (of_property_read_bool(np, "st,click-double-x"))
--
2.51.1
^ permalink raw reply related
* [PATCH v2 0/3] lis302dl/lis3lv02d: fix click thresholds and add legacy YAML binding
From: Md Shofiqul Islam @ 2026-06-11 15:41 UTC (permalink / raw)
To: linux-iio, devicetree
Cc: jic23, robh, krzk+dt, conor+dt, linusw, linux-kernel,
Md Shofiqul Islam
This series addresses the review feedback on v1 of the lis302 binding
conversion.
During the audit of upstream board DTS files I found 11 ARM boards
referencing st,lis302dl or st,lis3lv02d. This led to two additional
findings that the v1 patch missed:
1. A longstanding driver bug: the driver reads st,click-threshold-x/y/z
but 5 upstream boards use st,click-thresh-x/y/z (the name from the
old .txt documentation). Those boards have had silent click detection
failures for years because the driver ignores the misspelled property.
Patch 1 fixes this by setting a sensible default of 10 in the driver.
2. Three different compatible strings are used as the primary binding
for different boards: st,lis302dl (Nokia N900), st,lis3lv02d (Nokia
N950/N9, AM335x Pepper), and st,lis302dl-spi (PXA300 Raumfeld).
The v1 patch only included st,lis302dl-spi and st,lis3lv02d.
Changes from v1:
- New patch 1: fix driver click threshold defaults
- New patch 2: remove st,lis302dl-spi and st,lis3lv02d from the
deprecated section of st,st-sensors.yaml (duplicate resolution)
- Patch 3 (binding, formerly the only patch):
- Add prominent WARNING at top of description
- Add st,lis302dl compatible (Nokia N900)
- Document both supply naming conventions (Vdd-supply/Vdd_IO-supply
and vdd-supply/vddio-supply used by N900)
- Add mount-matrix (Nokia N900)
- Mark all click/irq/wakeup/filter properties as deprecated=true
- Add st,click-thresh-x/y/z as deprecated with a note explaining
the misspelling situation
- Remove Jonathan Cameron as maintainer (declined); use Linus Walleij
- Remove driver path reference from description
- Add schema range constraints for axis remapping properties
- Update example to use Nokia N900 (minimal, modern node)
Md Shofiqul Islam (3):
misc: lis3lv02d: set default click detection thresholds
dt-bindings: iio: st,st-sensors: remove lis302dl and lis3lv02d from
deprecated list
dt-bindings: iio: accel: convert lis302 binding to YAML schema (v2)
.../devicetree/bindings/iio/accel/lis302.txt | 119 -------
.../bindings/iio/accel/st,lis302dl.yaml | 320 ++++++++++++++++++
.../bindings/iio/st,st-sensors.yaml | 6 -
drivers/misc/lis3lv02d/lis3lv02d.c | 8 +
4 files changed, 328 insertions(+), 125 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/iio/accel/lis302.txt
create mode 100644 Documentation/devicetree/bindings/iio/accel/st,lis302dl.yaml
--
2.51.1
^ permalink raw reply
* Re: [PATCH v6 0/2] phy: add basic support for NXPs TJA1145 CAN transceiver
From: Vinod Koul @ 2026-06-11 15:35 UTC (permalink / raw)
To: Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Dimitri Fedrau, Dimitri Fedrau
Cc: linux-phy, devicetree, linux-kernel, Conor Dooley, lee.lockhey,
Marc Kleine-Budde
In-Reply-To: <20260602-tja1145-support-v6-0-0e0ffc8ee63d@liebherr.com>
On Tue, 02 Jun 2026 10:25:36 +0200, Dimitri Fedrau wrote:
> Add basic driver support for NXPs TJA1145 CAN transceiver which brings the
> PHY up/down by switching to normal/standby mode using SPI commands.
>
>
Applied, thanks!
[1/2] dt-bindings: phy: add support for NXPs TJA1145 CAN transceiver
commit: baacd0af457c2505137c4774e71efe044c11b26d
[2/2] phy: add basic support for NXPs TJA1145 CAN transceiver
commit: e5a9c1c917b59a4aff066b9f317501834c6d5af2
Best regards,
--
~Vinod
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox