From: Lee Jones <lee@kernel.org>
To: Fred Treven <ftreven@opensource.cirrus.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Simon Trimmer <simont@opensource.cirrus.com>,
Charles Keepax <ckeepax@opensource.cirrus.com>,
Richard Fitzgerald <rf@opensource.cirrus.com>,
Dmitry Torokhov <dmitry.torokhov@gmail.com>,
James Ogletree <jogletre@opensource.cirrus.com>,
Ben Bright <ben.bright@cirrus.com>,
Liam Girdwood <lgirdwood@gmail.com>,
Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>,
Takashi Iwai <tiwai@suse.com>,
David Rhodes <david.rhodes@cirrus.com>,
Jeff LaBundy <jeff@labundy.com>, Heiko Stuebner <heiko@sntech.de>,
Karel Balej <balejk@matfyz.cz>,
Igor Prusov <ivprusov@salutedevices.com>,
Jack Yu <jack.yu@realtek.com>,
Weidong Wang <wangweidong.a@awinic.com>,
Binbin Zhou <zhoubinbin@loongson.cn>,
Prasad Kumpatla <quic_pkumpatl@quicinc.com>,
Paul Handrigan <paulha@opensource.cirrus.com>,
Masahiro Yamada <masahiroy@kernel.org>,
Nuno Sa <nuno.sa@analog.com>,
alsa-devel@alsa-project.org, patches@opensource.cirrus.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-input@vger.kernel.org, linux-sound@vger.kernel.org
Subject: Re: [PATCH RESEND 5/7] mfd: cs40l26: Add support for CS40L26 core driver
Date: Wed, 12 Feb 2025 15:50:50 +0000 [thread overview]
Message-ID: <20250212155050.GC2274105@google.com> (raw)
In-Reply-To: <3bff0ff8-7397-414d-a701-011d5b5a41f4@opensource.cirrus.com>
On Tue, 11 Feb 2025, Fred Treven wrote:
> On 2/5/25 04:34, Krzysztof Kozlowski wrote:
> > On 05/02/2025 00:18, Fred Treven wrote:
> > > Introduce support for Cirrus Logic Device CS40L26:
> > > A boosted haptic driver with integrated DSP and
> > > waveform memory with advanced closed loop algorithms
> > > and LRA protection.
> > >
> > Please wrap commit message according to Linux coding style / submission
> > process (neither too early nor over the limit):
> > https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
> >
> >
> > > +
> > > +#include <linux/cleanup.h>
> > > +#include <linux/mfd/core.h>
> > > +#include <linux/mfd/cs40l26.h>
> > > +#include <linux/property.h>
> > > +#include <linux/regulator/consumer.h>
> > > +
> > > +static const struct mfd_cell cs40l26_devs[] = {
> > > + { .name = "cs40l26-codec", },
> > > + { .name = "cs40l26-vibra", },
> > > +};
> > > +
> > > +const struct regmap_config cs40l26_regmap = {
> > > + .reg_bits = 32,
> > > + .val_bits = 32,
> > > + .reg_stride = 4,
> > > + .reg_format_endian = REGMAP_ENDIAN_BIG,
> > > + .val_format_endian = REGMAP_ENDIAN_BIG,
> > > + .max_register = CS40L26_LASTREG,
> > > + .cache_type = REGCACHE_NONE,
> > > +};
> > > +EXPORT_SYMBOL_GPL(cs40l26_regmap);
> > > +
> > > +static const char *const cs40l26_supplies[] = {
> > > + "va", "vp",
> > > +};
> > > +
> > > +inline void cs40l26_pm_exit(struct device *dev)
> >
> > Exported function and inlined? This feels odd. Anyway, don't use any
> > inline keywords in C units.
> >
> > > +{
> > > + pm_runtime_mark_last_busy(dev);
> > > + pm_runtime_put_autosuspend(dev);
> > > +}
> > > +EXPORT_SYMBOL_GPL(cs40l26_pm_exit);
> > > +
> > > +static int cs40l26_fw_write_raw(struct cs_dsp *dsp, const char *const name,
> > > + const unsigned int algo_id, const u32 offset_words,
> > > + const size_t len_words, u32 *buf)
> > > +{
> > > + struct cs_dsp_coeff_ctl *ctl;
> > > + __be32 *val;
> > > + int i, ret;
> > > +
> > > + ctl = cs_dsp_get_ctl(dsp, name, WMFW_ADSP2_XM, algo_id);
> > > + if (!ctl) {
> > > + dev_err(dsp->dev, "Failed to find FW control %s\n", name);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + val = kzalloc(len_words * sizeof(u32), GFP_KERNEL);
> >
> > Looks like an array, so kcalloc
> >
> > > + if (!val)
> > > + return -ENOMEM;
> > > +
> > > + for (i = 0; i < len_words; i++)
> > > + val[i] = cpu_to_be32(buf[i]);
> > > +
> > > + ret = cs_dsp_coeff_write_ctrl(ctl, offset_words, val, len_words * sizeof(u32));
> > > + if (ret < 0)
> > > + dev_err(dsp->dev, "Failed to write FW control %s\n", name);
> > > +
> > > + kfree(val);
> > > +
> > > + return (ret < 0) ? ret : 0;
> > > +}
> > > +
> > > +inline int cs40l26_fw_write(struct cs_dsp *dsp, const char *const name, const unsigned int algo_id,
> > > + u32 val)
> > > +{
> > > + return cs40l26_fw_write_raw(dsp, name, algo_id, 0, 1, &val);
> > > +}
> > > +EXPORT_SYMBOL_GPL(cs40l26_fw_write);
> > > +
> > > +static int cs40l26_fw_read_raw(struct cs_dsp *dsp, const char *const name,
> > > + const unsigned int algo_id, const unsigned int offset_words,
> > > + const size_t len_words, u32 *buf)
> > > +{
> > > + struct cs_dsp_coeff_ctl *ctl;
> > > + int i, ret;
> > > +
> > > + ctl = cs_dsp_get_ctl(dsp, name, WMFW_ADSP2_XM, algo_id);
> > > + if (!ctl) {
> > > + dev_err(dsp->dev, "Failed to find FW control %s\n", name);
> > > + return -EINVAL;
> > > + }
> > > +
> > > + ret = cs_dsp_coeff_read_ctrl(ctl, offset_words, buf, len_words * sizeof(u32));
> > > + if (ret) {
> > > + dev_err(dsp->dev, "Failed to read FW control %s\n", name);
> > > + return ret;
> > > + }
> > > +
> > > + for (i = 0; i < len_words; i++)
> > > + buf[i] = be32_to_cpu(buf[i]);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +inline int cs40l26_fw_read(struct cs_dsp *dsp, const char *const name, const unsigned int algo_id,
> >
> > All your exported functions should have kerneldoc.
>
> I'm happy to add this, but I don't know where this directive comes from.
> Could you share where in the kernel style guide (or elsewhere) this is stated?
> There are also hundreds of examples in MFD in which exported functions
> do not have kerneldoc which is why I'm curious.
>
> >
> > > + u32 *buf)
> > > +{
> > > + return cs40l26_fw_read_raw(dsp, name, algo_id, 0, 1, buf);
> > > +}
> > > +EXPORT_SYMBOL_GPL(cs40l26_fw_read);
> > > +
> > > +static struct cs40l26_irq *cs40l26_get_irq(struct cs40l26 *cs40l26, const int num, const int bit);
> > > +
> > > +static int cs40l26_gpio1_rise_irq(void *data)
> > > +{
> > > + struct cs40l26 *cs40l26 = data;
> > > +
> > > + if (cs40l26->wksrc_sts & CS40L26_WKSRC_STS_EN)
> > > + dev_dbg(cs40l26->dev, "GPIO1 Rising Edge Detected\n");
> > > +
> > > + cs40l26->wksrc_sts |= CS40L26_WKSRC_STS_EN;
> > > +
> > > + return 0;
> > > +}
> >
> >
> > ...
> >
> > > +err:
> > > + dev_err(cs40l26->dev, "Invalid revision 0x%02X for device 0x%06X\n", cs40l26->revid,
> > > + cs40l26->devid);
> > > + return -EINVAL;
> > > +}
> > > +
> > > +int cs40l26_set_pll_loop(struct cs40l26 *cs40l26, const u32 pll_loop)
> > > +{
> > > + int i;
> > > +
> > > + /* Retry in case DSP is hibernating */
> > > + for (i = 0; i < CS40L26_PLL_NUM_SET_ATTEMPTS; i++) {
> > > + if (!regmap_update_bits(cs40l26->regmap, CS40L26_REFCLK_INPUT,
> > > + CS40L26_PLL_REFCLK_LOOP_MASK,
> > > + pll_loop << CS40L26_PLL_REFCLK_LOOP_SHIFT))
> > > + break;
> > > + }
> > > +
> > > + if (i == CS40L26_PLL_NUM_SET_ATTEMPTS) {
> > > + dev_err(cs40l26->dev, "Failed to configure PLL\n");
> > > + return -ETIMEDOUT;
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +EXPORT_SYMBOL_GPL(cs40l26_set_pll_loop);
> > > +
> >
> > This looks way past simple MFD driver. Not only this - entire file. You
> > configure there quite a lot and for example setting PLLs is not job for
> > MFD. This should be placed in appropriate subsystem.
> >
> I disagree here because the configuration being done in this file
> is essential to the core operation of the part. For instance,
> setting the PLL to open-loop here is required to prevent any
> external interference (e.g. GPIO events) from interrupting
> the part while loading firmware.
>
> The other hardware configuration being done here is required for
> both the Input and ASoC operations of the part.
>
> Lastly, these need to be done in order and independently of which
> child driver (ASoC or input) the user adds. If this is moved
> to cs40l26-vibra.c (the input driver), for instance,
> and that module is then not added, it will disturb the
> required setup for use by the ASoC driver.
>
> I would really like to get Lee's opinion here because it does not
> make sense to me why this is inappropriate when the configuration
> done in the core MFD driver is required for use by all of its
> children.
FWIW, I agree with Krzysztof.
There's a bunch of functionality in here that should be exported out to
leaf drivers which should reside in their associated subsystems. From
just a quick glance that looks to include, but not necessary limited
to; IRQs, GPIOs and PLLs (Clocks).
MFD has been used for a dumping ground under the premise of "core
functionality" before. Tolerance for those arguments are now fairly
low.
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2025-02-12 15:50 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-04 23:18 [PATCH RESEND 0/7] Initial Support for CS40L26 Fred Treven
2025-02-04 23:18 ` [PATCH RESEND 1/7] firmware: cs_dsp: Fix error checking in wseq_write() Fred Treven
2025-02-04 23:18 ` [PATCH RESEND 2/7] firmware: cs_dsp: Check for valid num_regs in cs_dsp_wseq_multi_write() Fred Treven
2025-02-04 23:18 ` [PATCH RESEND 3/7] firmware: cs_dsp: Add ability to load multiple coefficient files Fred Treven
2025-02-04 23:18 ` [PATCH RESEND 4/7] dt-bindings: mfd: cirrus,cs40l26: Support for CS40L26 Fred Treven
2025-02-05 10:09 ` Krzysztof Kozlowski
2025-02-04 23:18 ` [PATCH RESEND 5/7] mfd: cs40l26: Add support for CS40L26 core driver Fred Treven
2025-02-05 10:34 ` Krzysztof Kozlowski
2025-02-11 21:16 ` Fred Treven
2025-02-12 6:19 ` Krzysztof Kozlowski
2025-02-12 15:10 ` Richard Fitzgerald
2025-02-12 15:50 ` Lee Jones [this message]
2025-02-16 22:10 ` Jeff LaBundy
2025-02-04 23:18 ` [PATCH RESEND 6/7] ASoC: cs40l26: Support I2S streaming to CS40L26 Fred Treven
2025-02-04 23:18 ` [PATCH RESEND 7/7] Input: cs40l26 - Add support for CS40L26 haptic driver Fred Treven
2025-02-16 21:13 ` [PATCH RESEND 0/7] Initial Support for CS40L26 Jeff LaBundy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250212155050.GC2274105@google.com \
--to=lee@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=balejk@matfyz.cz \
--cc=ben.bright@cirrus.com \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=conor+dt@kernel.org \
--cc=david.rhodes@cirrus.com \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=ftreven@opensource.cirrus.com \
--cc=heiko@sntech.de \
--cc=ivprusov@salutedevices.com \
--cc=jack.yu@realtek.com \
--cc=jeff@labundy.com \
--cc=jogletre@opensource.cirrus.com \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=nuno.sa@analog.com \
--cc=patches@opensource.cirrus.com \
--cc=paulha@opensource.cirrus.com \
--cc=perex@perex.cz \
--cc=quic_pkumpatl@quicinc.com \
--cc=rf@opensource.cirrus.com \
--cc=robh@kernel.org \
--cc=simont@opensource.cirrus.com \
--cc=tiwai@suse.com \
--cc=wangweidong.a@awinic.com \
--cc=zhoubinbin@loongson.cn \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).