Hi Fred, On Fri, May 26, 2023 at 09:23:53PM +0000, Fred Treven wrote: > > Hi Jeff, > > > On May 26, 2023, at 2:43 PM, Jeff LaBundy <jeff@xxxxxxxxxxx> 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@xxxxxxxxxx> > >> --- > > > > 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. If your goal is to support audio-to-haptics in mainline and to do so using an ASoC driver, then I recommend option B. You should start with a scalable and maintainable solution that reflects your long-term goals. Option A is sunk cost. I also expect that you will identify additional changes required to the input driver, particularly with respect to interrupt handling, beyond moving initialization-related code to the MFD. It's a major re-write in my opinion. It would be interesting to see if an existing Cirrus ASoC driver can be gently reworked to act as the child codec, vs. having to write an entirely new one for L26. I'm sure the devil is in the details though. > > Thank you, > Fred > > Kind regards, Jeff LaBundy
