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. Thank you, Fred
