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]
Message-ID: <F6FA6CFA-BFC5-47DA-83D1-6330E66195F5@cirrus.com>
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


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ