[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