mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Maarten ter Huurne <maarten@treewalker.org>
Cc: Wenyou Yang <wenyou.yang@atmel.com>,
	Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>,
	Liam Girdwood <lgirdwood@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] regulator: act8865: Expose act8600 registers via debugfs
Date: Mon, 29 Feb 2016 20:28:57 +0900	[thread overview]
Message-ID: <20160229112857.GY18327@sirena.org.uk> (raw)
In-Reply-To: <1456674809-16422-1-git-send-email-maarten@treewalker.org>

[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]

On Sun, Feb 28, 2016 at 04:53:23PM +0100, Maarten ter Huurne wrote:

> The read/write/volatile configuration is valid also when debugfs is
> not enabled, but it doesn't add any value then.

Please write changelogs that accurately describe what your changes do.
Any debugfs changes are at best a second order side effect of changes
here, what this appears to do is some combination of defining one or
more new registers (which don't seem to ever be referred to...) and
providing some access maps.

> +#ifdef CONFIG_DEBUG_FS
> +

No, this is broken.  The access information for a device is not affected
by debugfs and does have an effect on how we work with the device.
Having access maps that depend on random build settings like this is a
recipie for hard to diagnose bugs.

> +static const struct regmap_range act8600_reg_ranges[] = {
> +	{ 0x00, 0x01 },
> +	{ 0x10, 0x10 }, { 0x12, 0x12 },
> +	{ 0x20, 0x20 }, { 0x22, 0x22 },
> +	{ 0x30, 0x30 }, { 0x32, 0x32 },

Your formatting here is just weird and confusing, randomly grouping
things on lines with no obvious .

> +};
> +static const struct regmap_range act8600_reg_ro_ranges[] = {

Missing blank lines between variables.

> +static const struct regmap_range act8600_reg_volatile_ranges[] = {
> +	{ 0x00, 0x01 },

For ranges you should explicitly use .start and .end otherwise these
look like they're intended to be register default tables.

> @@ -421,6 +470,11 @@ static int act8865_pmic_probe(struct i2c_client *client,
>  	struct device_node **of_node;
>  	int i, ret, num_regulators;
>  	struct act8865 *act8865;
> +	struct regmap_config regmap_config = {
> +		.reg_bits = 8,
> +		.val_bits = 8,
> +		.max_register = 0xFF,
> +	};

Why have you moved this from a global static variable where it normally
is to a local variable?  This is unusual and confusing...

> +#ifdef CONFIG_DEBUG_FS
> +		regmap_config.wr_table = &act8600_write_ranges_table;
> +		regmap_config.rd_table = &act8600_read_ranges_table;
> +		regmap_config.volatile_table = &act8600_volatile_ranges_table;
> +#endif

...and the fact that you're doing things like this ought to be a warning
that there's a problem with the way you're handling the access maps.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

      parent reply	other threads:[~2016-02-29 11:29 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-28 15:53 Maarten ter Huurne
2016-02-28 15:53 ` [PATCH 2/7] regulator: act8865: Remove redundant dev lookups Maarten ter Huurne
2016-02-28 15:53 ` [PATCH 3/7] regulator: act8865: Remove "static" from local variable Maarten ter Huurne
2016-02-28 15:53 ` [PATCH 4/7] regulator: act8865: Rename platform_data field to init_data Maarten ter Huurne
2016-02-28 15:53 ` [PATCH 5/7] regulator: act8865: Pass of_node via act8865_regulator_data Maarten ter Huurne
2016-02-29 11:37   ` Mark Brown
2016-02-28 15:53 ` [PATCH 6/7] regulator: act8865: Specify fixed voltage of 3.3V for ACT8600's REG9 Maarten ter Huurne
2016-02-28 15:53 ` [PATCH 7/7] regulator: act8865: Init at subsys level Maarten ter Huurne
2016-02-29 11:35   ` Mark Brown
2016-03-17 14:17     ` Maarten ter Huurne
2016-02-29 11:28 ` Mark Brown [this message]

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=20160229112857.GY18327@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=Zubair.Kakakhel@imgtec.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten@treewalker.org \
    --cc=wenyou.yang@atmel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®