devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Lee Jones <lee@kernel.org>
To: Lukas Timmermann <linux@timmermann.space>
Cc: pavel@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
	conor+dt@kernel.org, linux-leds@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 2/2] leds: as3668: Driver for the ams Osram 4-channel i2c LED driver
Date: Thu, 31 Jul 2025 12:51:56 +0100	[thread overview]
Message-ID: <20250731115156.GF1049189@google.com> (raw)
In-Reply-To: <a028730a-a51c-4595-992e-e1e082329850@timmermann.space>

On Sun, 27 Jul 2025, Lukas Timmermann wrote:

> Formatting was malformed in the last message, sorry. Next try:
> 
> > > +#define AS3668_CHIP_REV1 0x01
> > 
> > How many REVs can one chip have?
> > 
> Would be 4-bit/16. I thought I do a little check about the revision and
> print a warning message to inform about the probably untested revision. Or
> is that not necessary?
> Removing the REV constant results in an if-statement similar to
> if(rev == 1). Is this considered a magic number?

I would omit this until there is another revision.

> > > +static int as3668_read_value(struct i2c_client *client, u8 reg)
> > > +{
> > > +	return i2c_smbus_read_byte_data(client, reg);
> > > +}
> > > +
> > > +static int as3668_write_value(struct i2c_client *client, u8 reg, u8 value)
> > > +{
> > > +	int err = i2c_smbus_write_byte_data(client, reg, value);
> > > +
> > > +	if (err)
> > > +		dev_err(&client->dev, "error writing to reg 0x%02x, returned %d\n", reg, err);
> > > +
> > > +	return err;
> > > +}
> > 
> > These look like abstractions for the sake of abstractions.
> > 
> > Just use the i2c_smbus_*() calls directly.
> > 
> Should I omit the write function as well? I do some error handling there. Is
> it okay to err |= write() the returned error codes in init or should I
> handle every possible write error by itself?

The handling in write() is standard error handling.

It doesn't justify another function.

> > > +	/* Read identifier from chip */
> > > +	chip_id1 = as3668_read_value(client, AS3668_CHIP_ID1);
> > > +
> > > +	if (chip_id1 != AS3668_CHIP_IDENT)
> > > +		return dev_err_probe(&client->dev, -ENODEV,
> > > +				"chip reported wrong id: 0x%02x\n", chip_id1);
> > 
> > Unlikely.  This too is unexpected, as above.
> > 
> Error message not descriptive, understood. Changing that to "unexpected ..."
> as above. Or am I misunderstanding and the check should be omitted entirely?

No, that's fine.

> > > +	/* Check the revision */
> > > +	chip_id2 = as3668_read_value(client, AS3668_CHIP_ID2);
> > 
> > Is child_id2 not for another chip?
> > 
> > This is ambiguous, please improve the variable nomenclature.
> > 
> chip_id2 is directly related to the defined register CHIP_ID2 which name is
> taken from the datasheet of the AS3668. (Not sure if I'm allowed to link it)
> Should we diverge from the datasheet in case of naming?
> Or is only chip_id2 to be renamed, even tho it holds the values of CHIP_ID2?
> I would consider chip_ident for chip_id1 and chip_subident for chip_id2.
> chip_subident would break down into chip_rev and chip_serial.
> Of course reading chip_id2 would be unnecessary if I omit checking the
> revision in the first place (see above).

I would encourage people to match up defines with the datasheet.

Variables should instead be easy to read / maintain.

> > > +	err = as3668_dt_init(as3668);
> > > +	if (err)
> > > +		return dev_err_probe(&client->dev, err, "failed to initialize device\n");
> > 
> > No need for 2 error messages.
> > 
> Doing if(error) return error; then...?

Right.

-- 
Lee Jones [李琼斯]

      reply	other threads:[~2025-07-31 11:52 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-08 14:11 [PATCH v7 0/2] Support for Osram as3668 LED driver Lukas Timmermann
2025-07-08 14:11 ` [PATCH v7 1/2] dt-bindings: leds: Add new as3668 support Lukas Timmermann
2025-07-08 14:11 ` [PATCH v7 2/2] leds: as3668: Driver for the ams Osram 4-channel i2c LED driver Lukas Timmermann
2025-07-23  9:31   ` Lee Jones
2025-07-27 21:14     ` Lukas Timmermann
2025-07-27 21:23     ` Lukas Timmermann
2025-07-31 11:51       ` Lee Jones [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=20250731115156.GF1049189@google.com \
    --to=lee@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=linux@timmermann.space \
    --cc=pavel@kernel.org \
    --cc=robh@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;
as well as URLs for NNTP newsgroup(s).