public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: Adam Thomson <Adam.Thomson.Opensource@diasemi.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Support Opensource <Support.Opensource@diasemi.com>
Subject: Re: [RESEND PATCH v2 1/2] mfd: da9063: Fix revision handling to correctly select reg tables
Date: Fri, 17 Apr 2020 10:24:10 +0100	[thread overview]
Message-ID: <20200417092410.GF2167633@dell> (raw)
In-Reply-To: <AM6PR10MB22634D3B677E57EED0514DF680D80@AM6PR10MB2263.EURPRD10.PROD.OUTLOOK.COM>

On Thu, 16 Apr 2020, Adam Thomson wrote:

> On 16 April 2020 09:00, Lee Jones wrote:
> 
> > > +/*
> > > + * Raw I2C access required for just accessing chip and variant info before we
> > > + * know which device is present. The info read from the device using this
> > > + * approach is then used to select the correct regmap tables.
> > > + */
> > > +static int da9063_i2c_blockreg_read(struct i2c_client *client, u16 addr,
> > > +				    u8 *buf, int count)
> > > +{
> > > +	struct i2c_msg xfer[3];
> > > +	u8 page_num, paged_addr;
> > > +	u8 page_buf[2];
> > > +	int ret;
> > > +
> > > +	/* Determine page info based on register address */
> > > +	page_num = (addr / 0x100);
> > 
> > Please define magic numbers.
> > 
> > > +	if (page_num > 1)
> > 
> > Please define magic numbers.
> 
> I was going to but decided against it given the minimal use. Easy enough to
> change though.

It's purely for readability purposes.

> > > +		return -EINVAL;
> > 
> > Do you want to fail silently here?
> 
> Well an error message is printed in the calling code, so didn't feel like it
> was necessary to have additional debug here. Felt like bloat.

As a user, I would prefer a more specific reason.

Thus, I would provide an error message here and omit the generic one.

> > > +	paged_addr = (addr % 0x100) & 0xFF;
> > > +	page_buf[0] = DA9063_REG_PAGE_CON;
> > > +	page_buf[1] = (page_num << DA9063_I2C_PAGE_SEL_SHIFT) &
> > > +		      DA9063_REG_PAGE_MASK;
> > > +
> > > +	/* Write reg address, page selection */
> > > +	xfer[0].addr = client->addr;
> > > +	xfer[0].flags = 0;
> > > +	xfer[0].len = 2;
> > > +	xfer[0].buf = page_buf;
> > > +
> > > +	/* Select register address */
> > > +	xfer[1].addr = client->addr;
> > > +	xfer[1].flags = 0;
> > > +	xfer[1].len = 1;
> > > +	xfer[1].buf = &paged_addr;
> > > +
> > > +	/* Read data */
> > > +	xfer[2].addr = client->addr;
> > > +	xfer[2].flags = I2C_M_RD;
> > > +	xfer[2].len = count;
> > > +	xfer[2].buf = buf;
> > > +
> > > +	ret = i2c_transfer(client->adapter, xfer, 3);
> > 
> > Why is this 3?  'count' and a NULL char?
> 
> Well there are 3 messages defined above so I want to process all of them. One to
> set the page register to the page we want to read from, one to select the
> register we want to read from in that page and then finally the read back of 
> the chip id and revision/variant info.

I see.  Thank you for the explanation.

> > > +	if (ret == 3)
> > > +		return 0;
> > > +	else if (ret < 0)
> > > +		return ret;
> > > +	else
> > > +		return -EIO;
> > 
> > I think the following makes it slightly clearer.
> > 
> > 	if (ret < 0)
> > 		return ret;
> > 
> > 	if (ret == 3)
> > 		return 0;
> > 	else
> > 		return -EIO;
> >
> 
> Ok. Don't think it makes much of a difference but don't mind really. I can add a
> #define for the number of messages to be sent which will clarify this slightly
> anyway.

Yes, I think that would be good.

> > > +}
> > > +
> > > +enum {
> > > +	DA9063_DEV_ID_REG = 0,
> > > +	DA9063_VAR_ID_REG,
> > > +	DA9063_CHIP_ID_REGS,
> > > +};
> > > +
> > > +static int da9063_get_device_type(struct i2c_client *i2c, struct da9063
> > *da9063)
> > > +{
> > > +	int ret;
> > > +	u8 buf[DA9063_CHIP_ID_REGS];
> > 
> > Really small nit: Could you reverse these please.
> 
> Yep, agreed.
> 
> > 
> > > +	ret = da9063_i2c_blockreg_read(i2c, DA9063_REG_DEVICE_ID, buf,
> > > +				       DA9063_CHIP_ID_REGS);
> > > +	if (ret < 0) {
> > 
> > if (ret)
> > 
> > Or better yet, as this is a read function, you could just return
> > i2c_transfer() and do the appropriate error checking here *instead*.
> 
> I think given that the function handles all of the I2C specific stuff I'd prefer
> it be kept there. Logically that to me makes more sense. Can change this to
> 'if (ret)'

Yes, not that I understand the message length (3) has more do to with
the I2C interactions (rather than a derisive of 'count'), it makes
sense to handle that inside the function.

However, it does seem odd to handle the return value of a *_read()
function in this way.  They usually return the number of bytes read,
which in this case would be DA9063_CHIP_ID_REGS (count), right?

[...]

-- 
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2020-04-17  9:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-06  8:54 [RESEND PATCH v2 0/2] Resolve revision handling and add support for DA silicon Adam Thomson
2020-04-06  8:54 ` [RESEND PATCH v2 1/2] mfd: da9063: Fix revision handling to correctly select reg tables Adam Thomson
2020-04-16  7:59   ` Lee Jones
2020-04-16  9:04     ` Adam Thomson
2020-04-17  9:24       ` Lee Jones [this message]
2020-04-17  9:51         ` Adam Thomson
2020-04-20  7:31           ` Lee Jones
2020-04-20  8:14             ` Adam Thomson
2020-04-06  8:54 ` [RESEND v2 PATCH 2/2] mfd: da9063: Add support for latest DA silicon revision Adam Thomson
2020-04-16  8:06   ` Lee Jones
2020-04-16  9:06     ` Adam Thomson

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=20200417092410.GF2167633@dell \
    --to=lee.jones@linaro.org \
    --cc=Adam.Thomson.Opensource@diasemi.com \
    --cc=Support.Opensource@diasemi.com \
    --cc=linux-kernel@vger.kernel.org \
    /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