Pull regulator fixes from Mark Brown:
 "A couple of unremarkable driver specific fixes that came in during the
  merge window"

* tag 'regulator-fix-v7.2-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: da9121: Use subvariant ids in the I2C table
  regulator: pca9450: Correct default t_off_deb for PCA9451A/PCA9452

da9121_i2c_probe() stores i2c_get_match_data() in chip->subvariant_id
and da9121_assign_chip_model() switches on DA9121_SUBTYPE_* values.  The
OF table provides those subvariant values, but the I2C id table
currently provides DA9121_TYPE_* values.

Make the I2C id table use the same subvariant namespace as the OF table
so non-DT I2C matches feed the expected data type into the model
assignment code.

Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Link: https://patch.msgid.link/20260624060024.61300-1-pengpeng@iscas.ac.cn
Signed-off-by: Mark Brown <broonie@kernel.org>

The PMIC PCA9451A and PCA9452 have a default power-off debounce time of
2ms according to their datasheet, while PCA9450A and PCA9450BC use 120us.

Add default_t_off_deb field to struct pca9450 to support per-variant
default configuration when the device tree property is not specified.

Datasheet reference links:
- PCA9451A Rev.2.1: https://www.nxp.com/docs/en/data-sheet/PCA9451A.pdf
- PCA9452 Rev.1.0: https://www.nxp.com/docs/en/data-sheet/PCA9452.pdf

Signed-off-by: Joy Zou <joy.zou@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Link: https://patch.msgid.link/20260618-b4-regulator-opt-v1-1-c43b1f62aaf6@oss.nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>

Pull regulator updates from Mark Brown:
 "The development of the regulator subsystem continues to be quite
  quiet, we've got several new devices, removal of one old device and
  some kernel wide cleanup of platform devices but nothing in the core.

   - Cleanups of platform_device_id usage

   - Filling out and fixing of the description of the MediaTek MT6359

   - Removal of the PCAP regulator driver, the MFD has been removed

   - New device support for Qualcomm Nord RPMH, PM8109, PM8150 and
     PMAU0102, and SG Micro SGM3804"

* tag 'regulator-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: (23 commits)
  regulator: dt-bindings: mt6311: Convert to DT schema
  regulator: qcom_smd-regulator: Add PM8019
  regulator: dt-bindings: qcom,smd-rpm-regulator: Add PM8019
  regulator: mt6359: Fix vbbck default internal supply name
  regulator: bq257xx: drop confusing configuration of_node
  regulator: Unify usage of space and comma in platform_device_id arrays
  regulator: Use named initializers for platform_device_id arrays
  regulator: Drop unused assignment of platform_device_id driver data
  regulator: scmi: fix of_node refcount leak in scmi_regulator_probe()
  regulator: remove used pcap regulator driver
  regulator: add SGM3804 Dual Output driver
  regulator: dt-bindings: document the SGM3804 Dual Output regulator
  regulator: mt6359: Add proper ldo_vcn33_[12] regulators
  regulator: mt6359: Add regulator supply names
  regulator: mt6359: const-ify regulator descriptions
  regulator: dt-bindings: mt6359: Deprecate bogus vcn33_[12]_* split regulators
  regulator: dt-bindings: mt6359: Drop regulator-name pattern restrictions
  regulator: palmas: Move MODULE_DEVICE_TABLE next to the table itself
  regulator: qcom_smd: Add PM8150 regulators
  regulator: dt-bindings: qcom,smd-rpm-regulator: Document PM8150 IC
  ...

Stephan Gerhold <stephan.gerhold@linaro.org> says:

Add the definitions and dt-bindings for the regulators in PM8019 to allow
controlling them through the RPM firmware. PM8019 is typically used
together with the MDM9607 SoC.

Link: https://patch.msgid.link/20260608-rpm-smd-regulator-pm8019-v1-0-c671388b9ea5@linaro.org

Add the definitions for the regulators in PM8019 to allow controlling them
through the RPM firmware. Reading the TYPE/SUBTYPE registers using SPMI
reveals that PM8019 uses a mixture of regulators from PMA8084 (hfsmps,
pldo) and PM8916 (nldo).

Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260608-rpm-smd-regulator-pm8019-v1-2-c671388b9ea5@linaro.org
Signed-off-by: Mark Brown <broonie@kernel.org>

This issue was pointed out by Sashiko.

vbbck is fed internally from vio18. For the MT6359, the default supply
name was incorrectly set as "VIO18", instead of the supply's default
"VIO18". In practice this still works, but it causes the regulator
description copy and replace to always happen. For the MT6359P the
name is correct.

Fix the supply name for MT6359 so that both instances are the same and
correct. Also copy the comment about the internal supply from the MT6359
list to the MT6359P list.

Fixes: 10be8fc1d534 ("regulator: mt6359: Add regulator supply names")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Link: https://patch.msgid.link/20260609083630.1600070-1-wenst@chromium.org
Signed-off-by: Mark Brown <broonie@kernel.org>

The driver reuses the OF node of the parent multi-function device but
still sets the of_node field of the regulator configuration to any prior
OF node.

Since the MFD child device does not have an OF node set until probe is
called, this field is set to NULL on first probe and to the reused OF
node if the driver is later rebound.

As the device_set_of_node_from_dev() helper drops a reference to any
prior OF node before taking a reference to the new one this can
apparently also confuse LLMs like Sashiko which flags it as a potential
use-after-free (which it is not).

Drop the confusing and redundant configuration of_node assignment.

Link: https://sashiko.dev/#/patchset/20260408073055.5183-1-johan%40kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20260604115912.2734074-1-johan@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>

Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com> says:

this series targets to use named initializers for platform_device_id
arrays. In general these are better readable for humans and more robust
to changes in the respective struct definition.

This robustness is needed as I want to do

Link: https://patch.msgid.link/cover.1779878004.git.u.kleine-koenig@baylibre.com

After converting all these arrays to use named initializers and fixing
coding style en passant, adapt the coding style also for those drivers that
already used named initializers before for consistency.

Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-koenig@baylibre.com>
Link: https://patch.msgid.link/a3a2736ebfcfa5a228dcebfbfefc14960dcce314.1779878004.git.u.kleine-koenig@baylibre.com
Signed-off-by: Mark Brown <broonie@kernel.org>