Re: [PATCH v1 3/7] power: reset: qcom-pon: Migrate to devm_spmi_subdevice_alloc_and_add()

[AngeloGioacchino Del Regno]

Il 21/07/25 13:36, Andy Shevchenko ha scritto:
> On Mon, Jul 21, 2025 at 09:55:21AM +0200, AngeloGioacchino Del Regno wrote:
> > Some Qualcomm PMICs integrates a Power On device supporting pwrkey
> > and resin along with the Android reboot reason action identifier.
> >
> > Instead of using the parent SPMI device (the main PMIC) as a kind
> > of syscon in this driver, register a new SPMI sub-device for PON
> > and initialize its own regmap with this sub-device's specific base
> > address, retrieved from the devicetree.
> >
> > This allows to stop manually adding the register base address to
> > every R/W call in this driver, as this can be, and is now, handled
> > by the regmap API instead.
>
> ...
>
> > +	struct regmap_config qcom_pon_regmap_config = {
> > +		.reg_bits = 16,
> > +		.val_bits = 16,
> > +		.max_register = 0x100,
> > +		.fast_io = true
>
> Please, leave trailing comma in this and other similar cases.

Oki, will do!

> > +	};
>
>
> >   	struct qcom_pon *pon;
> >   	long reason_shift;
> >   	int error;
>
> > +	if (!pdev->dev.parent)
> > +		return -ENODEV;
>
> You can start using
>
> 	struct device *dev = &pdev->dev;
>
> here and perhaps one may convert the rest to it...
>
> ...
>
> >   	error = of_property_read_u32(pdev->dev.of_node, "reg",
>
> ...including, but not limited to, use of device_property_read_u32(dev, ...) here.

I didn't do that for one single reason: I did not want to add noise to the commits
and wanted those to exclusively migrate the drivers to the new API, literally
without doing *anything* else unnecessary, even if I have located some almost
effortless improvements that I could've done to those drivers.

Please - I prefer to keep it this way: these are the first commits that add the
usage of the new functions and of the concept of SPMI subdevices, and I really
want those to contain just that and nothing else - because I suspect that these
will be taken as example and will be read by the next person that is implementing
a new SPMI (sub)driver or converting any remaining ones to subdevice.

Cheers,
Angelo