lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 24 Oct 2023 01:30:44 +0000
From:   James Ogletree <>
To:     Jeff LaBundy <>
CC:     Lee Jones <>,
        James Ogletree <>,
        Dmitry Torokhov <>,
        Rob Herring <>,
        Krzysztof Kozlowski <>,
        Fred Treven <>,
        Ben Bright <>,
        "" <>,
        "" <>,
        "" <>
Subject: Re: [PATCH v4 3/4] mfd: cs40l50: Add support for CS40L50 core driver

> On Oct 23, 2023, at 8:08 PM, Jeff LaBundy <> 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.

Powered by blists - more mailing lists