All of lore.kernel.org
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Lee Jones <lee@kernel.org>
Cc: <broonie@kernel.org>, <krzysztof.kozlowski+dt@linaro.org>,
	<linus.walleij@linaro.org>, <vkoul@kernel.org>,
	<robh+dt@kernel.org>, <conor+dt@kernel.org>,
	<lgirdwood@gmail.com>, <yung-chuan.liao@linux.intel.com>,
	<sanyog.r.kale@intel.com>, <pierre-louis.bossart@linux.intel.com>,
	<alsa-devel@alsa-project.org>, <patches@opensource.cirrus.com>,
	<devicetree@vger.kernel.org>, <linux-gpio@vger.kernel.org>,
	<linux-spi@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 3/6] mfd: cs42l43: Add support for cs42l43 core driver
Date: Fri, 16 Jun 2023 08:34:04 +0000	[thread overview]
Message-ID: <20230616083404.GR68926@ediswmail.ad.cirrus.com> (raw)
In-Reply-To: <20230615171124.GL3635807@google.com>

On Thu, Jun 15, 2023 at 06:11:24PM +0100, Lee Jones wrote:
> On Mon, 05 Jun 2023, Charles Keepax wrote:
> > +// SPDX-License-Identifier: GPL-2.0
> > +//
> > +// CS42L43 I2C driver
> > +//
> > +// Copyright (C) 2022-2023 Cirrus Logic, Inc. and
> > +//                         Cirrus Logic International Semiconductor Ltd.
> > +
> 
> I realise there is some precedent for this already in MFD.
> 
> However, I'd rather headers used C style multi-line comments.
> 

Apologies but just to be super clear you want this to look like:

// SPDX-License-Identifier: GPL-2.0
/*
 * CS42L43 I2C driver
 *
 * Copyright (C) 2022-2023 Cirrus Logic, Inc. and
 *                         Cirrus Logic International Semiconductor Ltd.
 */

Just clarifying since you want to get rid of all the // comments,
but the SPDX stuff specifically requires one according to
Documentation/process/license-rules.rst.

> > +	// I2C is always attached by definition
> 
> C please.  And everywhere else.
> 

Can do.

> > +static struct i2c_device_id cs42l43_i2c_id[] = {
> > +	{ "cs42l43", 0 },
> > +	{}
> > +};
> > +MODULE_DEVICE_TABLE(i2c, cs42l43_i2c_id);
> 
> Is this required anymore?
> 

I was not aware of it not being required, I think it will still
be used for the purposes of module naming. Perhaps someone more
knowledgable than me can comment?

> > +#if IS_ENABLED(CONFIG_MFD_CS42L43_I2C)
> > +const struct regmap_config cs42l43_i2c_regmap = {
> > +	.reg_bits		= 32,
> > +	.reg_stride		= 4,
> > +	.val_bits		= 32,
> > +	.reg_format_endian	= REGMAP_ENDIAN_BIG,
> > +	.val_format_endian	= REGMAP_ENDIAN_BIG,
> > +
> > +	.max_register		= CS42L43_MCU_RAM_MAX,
> > +	.readable_reg		= cs42l43_readable_register,
> > +	.volatile_reg		= cs42l43_volatile_register,
> > +	.precious_reg		= cs42l43_precious_register,
> > +
> > +	.cache_type		= REGCACHE_RBTREE,
> > +	.reg_defaults		= cs42l43_reg_default,
> > +	.num_reg_defaults	= ARRAY_SIZE(cs42l43_reg_default),
> > +};
> > +EXPORT_SYMBOL_NS_GPL(cs42l43_i2c_regmap, MFD_CS42L43);
> > +#endif
> 
> We don't tend to like #ifery in C files.
> 
> Why is it required?
> 
> And why not just put them were they're consumed?

The trouble is the cs42l43_reg_default array and the array size.
There is no good way to statically initialise those two fields
from a single array in both the I2C and SDW modules.

> > +static int cs42l43_soft_reset(struct cs42l43 *cs42l43)
> > +{
> > +	static const struct reg_sequence reset[] = {
> > +		{ CS42L43_SFT_RESET, 0x5A000000 },
> > +	};
> > +	unsigned long time;
> > +
> > +	dev_dbg(cs42l43->dev, "Soft resetting\n");
> 
> How often are you realistically going to enable these?  Can you do
> without them and just add some printks when debugging?  Seems a shame to
> dirty the code-base with seldom used / questionably helpful LoC.

I mean I use them all the time they are very helpful. But yeah I
can just add them each time I need them its just a pain, but I
guess since you are the second person to comment I will accept
that wanting to easily turn on debug is not a feature we are keen
on.

> > +	reinit_completion(&cs42l43->device_detach);
> > +
> > +	/* apply cache only as the device will also fall off the soundwire bus */
> 
> Grammar please.  Some capital letters missing there.
> 

No problem.

> > +	regcache_cache_only(cs42l43->regmap, true);
> > +	regmap_multi_reg_write_bypassed(cs42l43->regmap, reset, ARRAY_SIZE(reset));
> > +
> > +	msleep(20);
> 
> Why 20?
> 

Because that is what the hardware needs, I assume this will be
covered when I turn all number in to defines.

> > +static int cs42l43_mcu_stage_2_3(struct cs42l43 *cs42l43, bool shadow)
> > +{
> > +	unsigned int need_reg = CS42L43_NEED_CONFIGS;
> > +	unsigned int val;
> > +	int ret;
> > +
> > +	if (shadow)
> 
> What's shadow?  Comment please.
> 

Yeah can add a comment for that.

> > +		need_reg = CS42L43_FW_SH_BOOT_CFG_NEED_CONFIGS;
> > +
> > +	regmap_write(cs42l43->regmap, need_reg, 0x0);
> > +
> > +	ret = regmap_read_poll_timeout(cs42l43->regmap, CS42L43_BOOT_STATUS,
> > +				       val, (val == 3), 5000, 20000);
> 
> Defines are easier to read than magic numbers.
> 

Can do.

> > +	if (ret) {
> > +		dev_err(cs42l43->dev, "Failed to move to stage 3: %d, 0x%x\n", ret, val);
> 
> Stage 3 what?
> 

Of the MCU boot.

> Perhaps some simple function headers would help?
> 

You mean add some kernel doc for these functions, right? Assuming
that is what you mean, will do.

Thanks,
Charles

  reply	other threads:[~2023-06-16  8:34 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-05 12:54 [PATCH v3 0/6] Add cs42l43 PC focused SoundWire CODEC Charles Keepax
2023-06-05 12:54 ` [PATCH v3 1/6] soundwire: bus: Allow SoundWire peripherals to register IRQ handlers Charles Keepax
2023-06-15 22:14   ` andy.shevchenko
2023-06-16 16:01     ` Charles Keepax
2023-06-05 12:55 ` [PATCH v3 2/6] dt-bindings: mfd: cirrus,cs42l43: Add initial DT binding Charles Keepax
2023-06-06  8:49   ` Krzysztof Kozlowski
2023-06-05 12:55 ` [PATCH v3 3/6] mfd: cs42l43: Add support for cs42l43 core driver Charles Keepax
2023-06-15 17:11   ` Lee Jones
2023-06-16  8:34     ` Charles Keepax [this message]
2023-06-19  8:30       ` Lee Jones
2023-06-19  8:52         ` Charles Keepax
2023-06-19  9:11           ` Charles Keepax
2023-06-05 12:55 ` [PATCH v3 4/6] pinctrl: cs42l43: Add support for the cs42l43 Charles Keepax
2023-06-05 12:55 ` [PATCH v3 5/6] spi: cs42l43: Add SPI controller support Charles Keepax
2023-06-05 12:55 ` [PATCH v3 6/6] ASoC: cs42l43: Add support for the cs42l43 Charles Keepax

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=20230616083404.GR68926@ediswmail.ad.cirrus.com \
    --to=ckeepax@opensource.cirrus.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzysztof.kozlowski+dt@linaro.org \
    --cc=lee@kernel.org \
    --cc=lgirdwood@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=patches@opensource.cirrus.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=robh+dt@kernel.org \
    --cc=sanyog.r.kale@intel.com \
    --cc=vkoul@kernel.org \
    --cc=yung-chuan.liao@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.