[PATCH 1/4] dt-bindings: mfd: nxp,bbnsm: Add binding for nxp bbnsm

[Krzysztof Kozlowski]

On 23/11/2022 08:43, Jacky Bai wrote:
>> Subject: Re: [PATCH 1/4] dt-bindings: mfd: nxp,bbnsm: Add binding for nxp
>> bbnsm
>>
>> On 21/11/2022 11:26, Jacky Bai wrote:
>>>> Subject: Re: [PATCH 1/4] dt-bindings: mfd: nxp,bbnsm: Add binding for
>>>> nxp bbnsm
>>>>
>>>> On 21/11/2022 07:51, Jacky Bai wrote:
>>>>> Add binding for NXP BBNSM(Battery-Backed Non-Secure Module).
>>>>>
>>>>> Signed-off-by: Jacky Bai <ping.bai at nxp.com>
>>>>> ---
>>>
>>> ...
>>>
>>>>> +
>>>>> +    properties:
>>>>> +      compatible:
>>>>> +        const: nxp,bbnsm-rtc
>>>>
>>>>
>>>> Missing ref to rtc.yaml.
>>>
>>> Ok will include in v2.
>>>>
>>>>> +
>>>>> +      regmap:
>>>>
>>>> Use vendor prefix, descriptive name and description. Where is the
>>>> type of 'regmap' defined?
>>>
>>> Type is missed. Will add a description and type define if necessary.
>>>
>>>>
>>>>> +        maxItems: 1
>>>>
>>>> I don't think this is correct. Rob explained the simple-mfd means
>>>> children
>>> do
>>>> not depend on anything from the parent, but taking a regmap from its
>>> parent
>>>> contradicts it.
>>>
>>> For this BBNSM module, basically, it provides two sperate & different
>>> function: RTC and ON/OFF button control. But no separate register
>>> offset range for each of these functions. For example, the interrupt
>>> enable control, Interrupt status and basic function control are mixed
>>> in the same registers'
>>> different bit.
>>>
>>> Any good suggestion on how to handle such case? ^_^
>>
>> The solution for more complex common parts, dedicated device driver (MFD
>> driver) with its own binding. However I understand why it would be overshoot
>> here.
>>
> 
> Is it ok to keep current implementation rather than reimplement a new dedicate MFD wrapper driver?

Yes

Best regards,
Krzysztof