[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