TPS65214 and TPS65215 are Power Management Integrated Circuits (PMICs) that
have significant register map overlap with TPS65219 and each other. The 
series introduces the 2 new PMICs and restructures the existing driver to 
support multiple devices.

- TPS65214, TPS65215, and TPS65219 each have 3 Buck regulators
- TPS65214 has 2 LDOS and 1 GPO, whereas TPS65219 has 4 LDOs and 2 GPOs.
- TPS65214's LDO1 maps to TPS65219's LDO3.
- A key difference between TPS65215 & TPS65214 are the LDO current and
  voltage output ranges and the configurable options available.
- TPS65215 has 2 LDOs, whereas TPS65219 has 4 LDOs.
- TPS65215's LDO2 maps to TPS65219's LDO3.
- TPS65215 has 1 GPO, whereas TPS65219 has 2 GPOs.

Dependencies:
- Patches 2 & 3 depend on https://lore.kernel.org/all/20250206173725.386720-5-s-ramamoorthy@ti.com/
- Patch 4 depends on https://lore.kernel.org/all/20250206173725.386720-6-s-ramamoorthy@ti.com/

TPS65214 TRM: https://www.ti.com/lit/pdf/slvud30
TPS65215 TRM: https://www.ti.com/lit/pdf/slvucw5/

AM62L + TPS65214 Test Logs:
https://gist.github.com/ramamoorthyhs/0793f7813332d94423ca1baee02f62c9
AM62L + TPS65215 Test Logs:
https://gist.github.com/ramamoorthyhs/7560eca6110fafc77b51894fa2c0fd22

---
Change Log:
v3 -> v4:
- Update commit header to be "regulator: tps65219" since the driver name has not 
  been changed from TPS65219.
- Combined TPS65214 & TPS65215 regulator patches into 1 series, 
  since the series' share a dependency & these patches have overlapping changes
- Drop tps65215_regulator_irq_types empty array and instead: set irq_types to NULL and dev_irq_size to 0

v2 -> v3:
dt-bindings: 
- Alphanumeric order for PMIC list
- add allOf:if:then: which will disallow :false two LDOs and their supplies

regulator.c:
- Revert addition of 2 probe helper functions
- Add empty tps65215_regulator_irq_types struct to minimize loops in probe
- Consolidate patches to define and use func/structs in the same patches to
  prevent build error due to no users of the defined functions
- Apply reverse xmas tree style to variable defintions in functions
- Remove unnecessary new lines & add new line after declarations

v1 -> v2:
- have any PMIC lists be in alpha-numeric order: TPS65215, then TPS65219
- Add driver prefix to chip_data struct
- Have probe() helper functions use dev_err_probe instead of dev_err() to 
  log the error code in a human readable format & combined with return, it 
  saves a few LoC since { } can be removed.
- Add error handling of 'irq_data' in probe() as previously done.
---
Shree Ramamoorthy (4):
  regulator: tps65219: Update struct names
  regulator: tps65219: Add support for TPS65215 regulator resources
  regulator: tps65219: Add support for TPS65215 Regulator IRQs
  regulator: tps65219: Add TI TPS65214 Regulator Support

 drivers/regulator/Kconfig              |  12 +-
 drivers/regulator/tps65219-regulator.c | 242 ++++++++++++++++++++-----
 2 files changed, 202 insertions(+), 52 deletions(-)

-- 
2.43.0

On Wed, Feb 12, 2025 at 01:11:25PM -0600, Shree Ramamoorthy wrote:

> Dependencies:
> - Patches 2 & 3 depend on https://lore.kernel.org/all/20250206173725.386720-5-s-ramamoorthy@ti.com/
> - Patch 4 depends on https://lore.kernel.org/all/20250206173725.386720-6-s-ramamoorthy@ti.com/

These all appear to be in the MFD tree without a tag to pull from or
anything so I can't apply any of this stuff until after the merge
window.  I'm not clear why they weren't sent as part of the MFD series?
You should probably resend copying Lee.

Hi Mark,

On 2/26/2025 4:40 PM, Mark Brown wrote:
> On Wed, Feb 12, 2025 at 01:11:25PM -0600, Shree Ramamoorthy wrote:
>
>> Dependencies:
>> - Patches 2 & 3 depend on https://lore.kernel.org/all/20250206173725.386720-5-s-ramamoorthy@ti.com/
>> - Patch 4 depends on https://lore.kernel.org/all/20250206173725.386720-6-s-ramamoorthy@ti.com/
> These all appear to be in the MFD tree without a tag to pull from or
> anything so I can't apply any of this stuff until after the merge
> window.  I'm not clear why they weren't sent as part of the MFD series?
> You should probably resend copying Lee.

I wasn't sure if the MFD + entire regulator patches could be sent in the same series, so this is good to know!
I will resend a v5 Regulator series with Lee cc'd asking if he can take the series if you give the patches an ACK when ready.

On Fri, Feb 28, 2025 at 11:30:43AM -0600, Shree Ramamoorthy wrote:
> On 2/26/2025 4:40 PM, Mark Brown wrote:

> > These all appear to be in the MFD tree without a tag to pull from or
> > anything so I can't apply any of this stuff until after the merge
> > window.  I'm not clear why they weren't sent as part of the MFD series?
> > You should probably resend copying Lee.

> I wasn't sure if the MFD + entire regulator patches could be sent in the same series, so this is good to know!

In general if there's a build dependency it's OK to send things
together, if the patches are just for the same board or something but
don't actually interact at all then that's the time to split them up.

> I will resend a v5 Regulator series with Lee cc'd asking if he can take the series if you give the patches an ACK when ready.

OK.