| Message ID | 1685059471-9598-5-git-send-email-fred.treven@cirrus.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v2,1/5] dt-bindings: input: cirrus,cs40l26: Support for CS40L26 | expand |
On Thu, 25 May 2023, Fred Treven wrote: > Use MFD interface to load the CODEC driver along > with the Input FF driver. > > Signed-off-by: Fred Treven <fred.treven@cirrus.com> > --- > drivers/input/misc/cs40l26.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/input/misc/cs40l26.c b/drivers/input/misc/cs40l26.c > index 12c29cbd4ff0..35d15a6c2230 100644 > --- a/drivers/input/misc/cs40l26.c > +++ b/drivers/input/misc/cs40l26.c > @@ -13,6 +13,7 @@ > #include <linux/i2c.h> > #include <linux/interrupt.h> > #include <linux/kernel.h> > +#include <linux/mfd/core.h> NACK. Please do not use the MFD API outside of drivers/mfd. > #include <linux/pm_runtime.h> > #include <linux/string.h> > #include <linux/firmware/cirrus/wmfw.h> > @@ -2136,6 +2137,10 @@ static inline int cs40l26_worker_init(struct cs40l26_private *cs40l26) > return 0; > } > > +static const struct mfd_cell cs40l26_devs[] = { > + { .name = "cs40l26-codec" }, This is one device. Thus, not an MFD anyway. > +}; > + > static struct regulator_bulk_data cs40l26_supplies[] = { > { .supply = "VP" }, > { .supply = "VA" }, > @@ -2275,6 +2280,12 @@ int cs40l26_probe(struct cs40l26_private *cs40l26) > if (error) > goto err; > > + error = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, cs40l26_devs, 1, NULL, 0, NULL); > + if (error) { > + dev_err(dev, "Failed to MFD add device %s: %d\n", cs40l26_devs[0].name, error); > + goto err; > + } > + > return 0; > err: > cs40l26_remove(cs40l26); > -- > 2.7.4 >
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@cirrus.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. 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. 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. > drivers/input/misc/cs40l26.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/input/misc/cs40l26.c b/drivers/input/misc/cs40l26.c > index 12c29cbd4ff0..35d15a6c2230 100644 > --- a/drivers/input/misc/cs40l26.c > +++ b/drivers/input/misc/cs40l26.c > @@ -13,6 +13,7 @@ > #include <linux/i2c.h> > #include <linux/interrupt.h> > #include <linux/kernel.h> > +#include <linux/mfd/core.h> > #include <linux/pm_runtime.h> > #include <linux/string.h> > #include <linux/firmware/cirrus/wmfw.h> > @@ -2136,6 +2137,10 @@ static inline int cs40l26_worker_init(struct cs40l26_private *cs40l26) > return 0; > } > > +static const struct mfd_cell cs40l26_devs[] = { > + { .name = "cs40l26-codec" }, > +}; > + > static struct regulator_bulk_data cs40l26_supplies[] = { > { .supply = "VP" }, > { .supply = "VA" }, > @@ -2275,6 +2280,12 @@ int cs40l26_probe(struct cs40l26_private *cs40l26) > if (error) > goto err; > > + error = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, cs40l26_devs, 1, NULL, 0, NULL); > + if (error) { > + dev_err(dev, "Failed to MFD add device %s: %d\n", cs40l26_devs[0].name, error); > + goto err; > + } > + > return 0; > err: > cs40l26_remove(cs40l26); > -- > 2.7.4 > Kind regards, Jeff LaBundy
Hi Jeff, > On May 26, 2023, at 2:43 PM, Jeff LaBundy <jeff@labundy.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@cirrus.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
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@labundy.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@cirrus.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. 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
diff --git a/drivers/input/misc/cs40l26.c b/drivers/input/misc/cs40l26.c index 12c29cbd4ff0..35d15a6c2230 100644 --- a/drivers/input/misc/cs40l26.c +++ b/drivers/input/misc/cs40l26.c @@ -13,6 +13,7 @@ #include <linux/i2c.h> #include <linux/interrupt.h> #include <linux/kernel.h> +#include <linux/mfd/core.h> #include <linux/pm_runtime.h> #include <linux/string.h> #include <linux/firmware/cirrus/wmfw.h> @@ -2136,6 +2137,10 @@ static inline int cs40l26_worker_init(struct cs40l26_private *cs40l26) return 0; } +static const struct mfd_cell cs40l26_devs[] = { + { .name = "cs40l26-codec" }, +}; + static struct regulator_bulk_data cs40l26_supplies[] = { { .supply = "VP" }, { .supply = "VA" }, @@ -2275,6 +2280,12 @@ int cs40l26_probe(struct cs40l26_private *cs40l26) if (error) goto err; + error = devm_mfd_add_devices(dev, PLATFORM_DEVID_AUTO, cs40l26_devs, 1, NULL, 0, NULL); + if (error) { + dev_err(dev, "Failed to MFD add device %s: %d\n", cs40l26_devs[0].name, error); + goto err; + } + return 0; err: cs40l26_remove(cs40l26);
Use MFD interface to load the CODEC driver along with the Input FF driver. Signed-off-by: Fred Treven <fred.treven@cirrus.com> --- drivers/input/misc/cs40l26.c | 11 +++++++++++ 1 file changed, 11 insertions(+)