Re: [PATCH v2 00/14] Support ROHM Scalable PMIC family

[Matti Vaittinen <mazziesaccount@gmail.com>]

On 10/04/2025 11:02, Lee Jones wrote:
> On Tue, 08 Apr 2025, Matti Vaittinen wrote:
> 
>> On 04/04/2025 18:43, Lee Jones wrote:
>>> On Mon, 24 Mar 2025, Matti Vaittinen wrote:
>>>
>>>> Support ROHM BD96802, BD96805 and BD96806 PMICs
>>>>
>>>> The ROHM BD96801 [1] and BD96805 [2] are almost identical PMICs what comes
>>>> to the digital interface. Main difference is voltage tuning range.
>>>> Supporting BD96805 with BD96801 drivers is mostly just a matter of being
>>>> able to differentiate the PMICs (done based on the devicetree
>>>> compatible) and then providing separate voltage tables.
>>>>
>>>> The ROHM BD96802 [3] is a companion PMIC which is intended to be used to
>>>> provide more capacity on systems where the BD96801 alone is not
>>>> sufficient. Startup sequence of these PMICs can be synchronized in
>>>> hardware level, and there seems to be some mechanisms which allow
>>>> delivering the companion PMIC (BD96802) status to the main PMIC
>>>> (BD96801/BD96805). This patch series does treat the companion PMIC(s) as
>>>> individual PMICs and allows using them from software point of view as a
>>>> stand alone ICs. From the digital point of view, the BD96802 is a subset
>>>> of BD96801, providing only buck1 and buck2 regulators. Please see the
>>>> data sheet
>>>>
>>>> The ROHM BD96806 [4] is similar to the BD96802, except that it does also
>>>> provide different voltage tuning ranges.
>>>>
>>>> This series adds basic voltage monitoring and control as well as a
>>>> watchdog support for these PMICs using the BD96801 drivers.
>>>>
>>>> Similarly to the BD96801, these PMICs too have a few configurations
>>>> which can only be done when the PMIC is in STBY state. Similarly to the
>>>> BD96801, doing these configurations isn't supported by the driver. The
>>>> original BD96801 RFC [5] driver should be able to cover those
>>>> configurations, if modified to support these models.
>>>>
>>>> [1]: ROHM BD96801 data sheet:
>>>> https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/switching_regulator_system/product_brief_bd96801qxx-c-e.pdf
>>>> [2]: ROHM BD96805 data sheet:
>>>> https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/switching_regulator_system/product_brief_bd96805qxx-c-e.pdf
>>>> [3]: ROHM BD96802 data sheet:
>>>> https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/switching_regulator_system/product_brief_bd96802qxx-c-e.pdf
>>>> [4]: ROHM BD96806 data sheet:
>>>> https://fscdn.rohm.com/en/products/databook/datasheet/ic/power/switching_regulator_system/product_brief_bd96806qxx-c-e.pdf
>>>> [5]: Original BD96801 RFC:
>>>> https://lore.kernel.org/all/cover.1712058690.git.mazziesaccount@gmail.com/
>>>>
>>>> Revision history:
>>>>
>>>> v1 => v2: MFD driver changes after review by Lee
>>>>    - Use enum for chip type instead of picking the data directly from the
>>>>      of_match_data.
>>>>    - rename "chip data" variable 'cd' to more widely used 'ddata'.
>>>>    link to v1:
>>>>     https://lore.kernel.org/all/cover.1741864404.git.mazziesaccount@gmail.com/
>>
>>>
>>> The MFD stuff looks okay to me now.
>>>
>>> Let me know when everything else is ready to go.
>>>
>>
>> I'll treat this as an ACK for the V3. Please, let me know if that's not
>> Okay.
> 
> Acks are tricky because another maintainer might (have have in the past)
> assume that they can apply the set with my blessing, this is not the
> case.  I used to use `Acked-for-MFD-by: <me>`, but these ended up being
> merged.  *face palm*
> 
> Anyway, no harm done this time around I think.

I remembered you used to use the "Acked-for-MFD-by". Never knew the 
rationale though. Thanks for sharing the reason - and downside :)

I try to remember to not treat your "this looks good to me" as an ACK in 
the future then, but expect explicit acks.

Yours,
	-- Matti