Re: [PATCH v4 3/4] mfd: cs40l50: Add support for CS40L50 core driver

[James Ogletree]

> On Oct 23, 2023, at 8:08 PM, Jeff LaBundy <jeff@xxxxxxxxxxx> wrote:
> 
>>>> Should the last two drivers live in drivers/mailbox?
>>> 
>>> Adopting the mailbox framework seems like an excessive amount
>>> of overhead for our requirements.
>> 
>> MFD isn't a dumping a ground for miscellaneous functionality.
>> 
>> MFD requests resources and registers devices.
>> 
>> Mailbox functionality should live in drivers/mailbox.
> 
> I think this is just a misnomer; the code uses the terms "mailbox" and
> "mbox" throughout because the relevant registers are named as such in
> the datasheet.
> 
> Please correct me James, but I believe the datasheet uses this language
> because both the host and the part itself have write access, meaning the
> part may write a status code to the register after the host writes that
> same register. There is no relation to IPC or the mbox subsystem.
> 
> That being said, some of the functions currently placed in this MFD,
> namely those related to haptic motor properties (e.g. f0 and ReDC), do
> seem more appropriate for the input/FF child device. My understanding
> is that those functions serve only momentary haptic click effects and
> not the I2S streaming case; please let me know if I have misunderstood.
> 
> I understand that no customer would ever build the to-be-added codec
> driver _without_ the input driver, but the MFD must be generic enough
> to support this case. Would a codec-only implementation use f0 and ReDC
> estimation? If so, then these functions _do_ belong in the MFD, albeit
> with some comments to explain their nature.

Thank you for the clarifications, Jeff, and you are correct on all counts.
I see that I spoke before having a good enough grasp on the mailbox
framework. As regards the codec-only use case, they would not be used.
So those functions do belong in the input driver.