[PATCH v19 5/8] regulator: p3h2x4x: Add driver for on-die regulators in NXP P3H2x4x i3c hub

sashiko-bot at kernel.org sashiko-bot at kernel.org
Wed Sep 16 00:17:34 PDT 2026


Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] regulator: p3h2x4x: unused fields and dead code in driver data
- [Low] mfd: driver-specific header placed in global include/linux/mfd/ directory
--

commit 24a75a3dc0fb9f5c1adccf0bcd6a9d774397dc1c
Author: Aman Kumar Pandey <aman.kumarpandey at nxp.com>

    regulator: p3h2x4x: Add driver for on-die regulators in NXP P3H2x4x i3c hub

This commit adds a regulator driver for the on-die voltage regulators
integrated in the NXP P3H2x4x i3c hub family. It registers the regulators
via the MFD framework and standard regulator APIs.

> diff --git a/drivers/regulator/p3h2840_i3c_hub_regulator.c b/drivers/regulator/p3h2840_i3c_hub_regulator.c
> new file mode 100644
> index 0000000000000..244f2a4f70f38
> --- /dev/null
> +++ b/drivers/regulator/p3h2840_i3c_hub_regulator.c
> @@ -0,0 +1,289 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2025-2026 NXP
> + * NXP P3H2X4X regulator driver file contain functions for enable/disable regulator
> + * and voltage set/get.
> + */
> +#include <linux/bitfield.h>
> +#include <linux/cleanup.h>
> +#include <linux/mfd/p3h2840.h>
           ^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Low]
Is this driver-specific header used only by the parent and its immediate
children?

The MFD subsystem guidelines state that driver-specific header files should not
be placed in the global include/linux/mfd/ directory if they are only used
by the parent and its immediate children. Could this header be kept local to
drivers/mfd/ instead?

[ ... ]

> +#define P3H2X4X_VCCIO_LDO_CONF					0x16
> +#define P3H2X4X_CP0_VCCIO_LDO_VOLTAGE_MASK			GENMASK(1, 0)
> +#define P3H2X4X_CP0_VCCIO_LDO_VOLTAGE(x)	\
> +		FIELD_PREP(P3H2X4X_CP0_VCCIO_LDO_VOLTAGE_MASK, x)
> +#define P3H2X4X_CP1_VCCIO_LDO_VOLTAGE_MASK			GENMASK(3, 2)
> +#define P3H2X4X_CP1_VCCIO_LDO_VOLTAGE(x)	\
> +		FIELD_PREP(P3H2X4X_CP1_VCCIO_LDO_VOLTAGE_MASK, x)
> +#define P3H2X4X_TP0145_VCCIO_LDO_VOLTAGE_MASK			GENMASK(5, 4)
> +#define P3H2X4X_TP0145_VCCIO_LDO_VOLTAGE(x)	\
> +		FIELD_PREP(P3H2X4X_TP0145_VCCIO_LDO_VOLTAGE_MASK, x)
> +#define P3H2X4X_TP2367_VCCIO_LDO_VOLTAGE_MASK			GENMASK(7, 6)
> +#define P3H2X4X_TP2367_VCCIO_LDO_VOLTAGE(x)	\
> +		FIELD_PREP(P3H2X4X_TP2367_VCCIO_LDO_VOLTAGE_MASK, x)

[Severity: Low]
Are the P3H2X4X_*_VCCIO_LDO_VOLTAGE() macros used anywhere?

They appear to be defined using FIELD_PREP but never utilized in the driver
code, adding unnecessary complexity.

> +#define P3H2X4X_LDO_COUNT					4
> +#define P3H2X4X_LDO_ENABLE_TIME_US				5000
> +
> +struct p3h2x4x_regulator_dev {
> +	struct regulator_dev *rp3h2x4x_dev[P3H2X4X_LDO_COUNT];
> +	struct p3h2x4x *p3h2x4x;
> +	struct regmap *regmap;
> +};

[Severity: Low]
Are the rp3h2x4x_dev and regmap fields needed in this structure?

During p3h2x4x_regulator_probe(), these fields are populated but they don't seem
to be read anywhere on any subsequent execution path. For example, regmap access
uses rdev->regmap directly from the regulator core. Could they be removed to
reduce memory overhead and driver data payload complexity?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260916070728.1088801-1-lakshay.piplani@nxp.com?part=5



More information about the linux-i3c mailing list