From: Rodolfo Giometti <giometti@enneenne.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, Jean Delvare <khali@linux-fr.org>
Subject: Re: [PATCH] TSL2550 support (I2C device driver)
Date: Tue, 30 Jan 2007 11:26:42 +0100 [thread overview]
Message-ID: <20070130102642.GC8882@enneenne.com> (raw)
In-Reply-To: <20070129183950.00ef3a04.akpm@osdl.org>
On Mon, Jan 29, 2007 at 06:39:50PM -0800, Andrew Morton wrote:
> > +/* Insmod parameters */
> > +I2C_CLIENT_INSMOD_1(tsl2550);
> > +
> > +static int operating_mode = 0;
>
> The `= 0' is unneeded and undesirable.
Fixed.
> > ...
> >
> > +static int tsl2550_get_adc_value(struct i2c_client *client, int channel)
> > +{
> > + u8 cmd = channel == 0 ? TSL2550_READ_ADC0 : TSL2550_READ_ADC1;
> > + int timeout, ret;
> > +
> > + /* Read ADC channel waiting at most 400ms (see data sheet for further
> > + * info) */
> > + for (timeout = 400; timeout > 0; timeout--) {
> > + i2c_smbus_write_byte(client, cmd);
> > + mdelay(1);
> > + ret = i2c_smbus_read_byte(client);
> > + if (ret < 0)
> > + return ret;
> > + else if (ret & 0x0080)
> > + break;
> > + }
> > + if (timeout == 0)
> > + return -EIO;
> > + return ((u8) ret) & 0x7f; /* remove the "valid" bit */
> > +}
>
> eek. Is there no way to avoid the busy-wait? We cannot sleep here?
That's why I have to retry reading data for at most 400ms otherwise
the chip will start a new ADC conversion.
I can replace mdelay(1) with schedule_timeout(HZ/1000) but doing this
I'm not sure that just 1ms has elapesed. Also the chip has no irq
lines to use for that.
> > +/* --- LUX calculation ----------------------------------------------------- */
> > +
> > +#define TSL2550_MAX_LUX 1846
> > +
> > +static u8 ratio_lut[] = {
> > + 100, 100, 100, 100, 100, 100, 100, 100,
> > [snip]
> > +
> > +static u16 count_lut[] = {
> > + 0, 1, 2, 3, 4, 5, 6, 7,
> > [snip]
>
> These tables could perhaps be const?
Fixed.
> > +static ssize_t tsl2550_show_power_state(struct device *dev, struct device_attribute *attr, char *buf)
>
> It's preferred to try to fit the code into an 80-col window. (But some
> people disagree with this specifically for function definitions such as
> this).
I agree with them. :)
> Preferred coding style is
>
> err = i2c_detach_client(client);
> if (err)
> return err;
>
> (multiple places)
Fixed.
I'm going to repost the patch after some tests.
Thanks,
Rodolfo
--
GNU/Linux Solutions e-mail: giometti@enneenne.com
Linux Device Driver giometti@gnudd.com
Embedded Systems giometti@linux.it
UNIX programming phone: +39 349 2432127
next prev parent reply other threads:[~2007-01-30 10:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-29 23:56 [PATCH] TSL2550 support (I2C device driver) Rodolfo Giometti
2007-01-30 2:39 ` Andrew Morton
2007-01-30 2:41 ` Andrew Morton
2007-01-30 10:26 ` Rodolfo Giometti [this message]
2007-01-30 10:35 ` Andrew Morton
2007-01-30 11:32 ` [PATCH 001/001] I2C: TSL2550 support Rodolfo Giometti
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=20070130102642.GC8882@enneenne.com \
--to=giometti@enneenne.com \
--cc=akpm@osdl.org \
--cc=khali@linux-fr.org \
--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 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.