linux-kernel - Re: [PATCH RFC 5/5] mfd: cs40l26: Add CODEC driver component

lists.openwall.net		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:   Fri, 26 May 2023 21:23:53 +0000
From:   Fred Treven <Fred.Treven@...rus.com>
To:     Jeff LaBundy <jeff@...undy.com>
CC:     Ben Bright <Ben.Bright@...rus.com>,
        James Ogletree <James.Ogletree@...rus.com>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Simon Trimmer <simont@...nsource.cirrus.com>,
        Charles Keepax <ckeepax@...nsource.cirrus.com>,
        Richard Fitzgerald <rf@...nsource.cirrus.com>,
        "patches@...nsource.cirrus.com" <patches@...nsource.cirrus.com>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "lee@...nel.org" <lee@...nel.org>
Subject: Re: [PATCH RFC 5/5] mfd: cs40l26: Add CODEC driver component

Hi Jeff,

> On May 26, 2023, at 2:43 PM, Jeff LaBundy <jeff@...undy.com> wrote:
> 
> Hi Fred,
> 
> On Thu, May 25, 2023 at 07:04:31PM -0500, Fred Treven wrote:
>> Use MFD interface to load the CODEC driver along
>> with the Input FF driver.
>> 
>> Signed-off-by: Fred Treven <fred.treven@...rus.com>
>> ---
> 
> Did you mean to include a thin codec driver as part of this series to
> support the audio-to-haptics use-case? I don't see one.

That is the end-goal, but I wanted to submit a request for comment with just this patch to see if it was at all acceptable to add another device this way. I see now that it is not.

> 
> As Lee correctly points out, this isn't an MFD despite the title of the
> commit message, and is sort of an abuse of the API.

Understood. Do you think it’s best to migrate the appropriate code to the MFD subsystem before submitting this initial patchset (which will include the codec driver) or would it be acceptable to make that change after this has gone in? My hope was to avoid having code being reviewed more than once if a significant portion is moved to MFD.

> What you seem to actually want is a true MFD driver responsible for
> initializing common resources such as regmap, an IRQ chip, etc. That
> driver then adds input and codec drivers as children.
> 
> At the moment, you're more or less treating the input driver as the
> MFD with one child, but that is not the correct pattern.

Yeah that makes sense. Please advise on what the best way to continue would be: a. Drop this patch and migrate to MFD after the Input driver has been accepted or b. Move necessary code to MFD and add both Input and codec drivers from there along with the codec driver.

Thank you,
Fred