linux-input.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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 [李琼斯]

  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).