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 [李琼斯]
prev parent 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 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.