From: ladis@linux-mips.org (Ladislav Michl)
To: Jean Delvare <khali@linux-fr.org>
Cc: Greg KH <greg@kroah.com>, LKML <linux-kernel@vger.kernel.org>,
LM Sensors <sensors@Stimpy.netroedge.com>,
James Chapman <jchapman@katalix.com>
Subject: [PATCH] i2c: new driver for ds1337 RTC
Date: Thu, 19 May 2005 06:25:49 +0000 [thread overview]
Message-ID: <20050407231650.GA27226@orphique> (raw)
In-Reply-To: <20050407232908.418d8878.khali@linux-fr.org>
Jean,
I'll comment your mail first and then send separate patches (somehow
I can't sleep this night :))
On Thu, Apr 07, 2005 at 11:29:08PM +0200, Jean Delvare wrote:
> > * Move NULL argument checking from get/set date functions to
> > ds1337_command function, so it is only at one place. Note that other
> > drivers do not this checking at all and I think it is pointess,
> > because you have to know that you are passing struct rtc_time
> > anyway.
>
> I am not certain these are the right things to do (moving the check or
> removing it). I am not a specialist of ioctl, but it looks to me that
> ds1337_command acts as a dispatcher, branching to various functions
> depending on the value of cmd. I can imagine that some functions take an
> argument, and some don't, so checking for NULL pointer in the dispatcher
> doesn't make much sense. Now it is correct that for now all (two)
> functions need a parameter, but what if later a function is added, which
> takes no parameter? You'd have to undo your change and move the check in
> each function again.
>
> As for the check itself, the pointer somehow comes from user-space as I
> understand it, so you can't tell whether it's NULL or not - so checking
> makes full sense to me. If you take a look at the rtc8564 driver you'll
> see it *does* check for NULL pointers too.
You can't tell if memory it points to is valid. Okay, probably better
than nothing.
> > @@ -95,60 +96,38 @@
> > */
> > static int ds1337_get_datetime(struct i2c_client *client, struct
> > rtc_time *dt) {
> > - struct ds1337_data *data = i2c_get_clientdata(client);
> > - int result;
> > - u8 buf[7];
> > - u8 val;
> > - struct i2c_msg msg[2];
> > - u8 offs = 0;
> > -
> > - if (!dt) {
> > - dev_dbg(&client->adapter->dev, "%s: EINVAL: dt=NULL\n",
> > - __FUNCTION__);
> > -
> > - return -EINVAL;
> > - }
> > -
> > - msg[0].addr = client->addr;
> > - msg[0].flags = 0;
> > - msg[0].len = 1;
> > - msg[0].buf = &offs;
> > -
> > - msg[1].addr = client->addr;
> > - msg[1].flags = I2C_M_RD;
> > - msg[1].len = sizeof(buf);
> > - msg[1].buf = &buf[0];
> > + unsigned char buf[7] = { 0, }, addr[1] = { 0 };
> > + struct i2c_msg msgs[2] = {
> > + { client->addr, 0, 1, addr },
> > + { client->addr, I2C_M_RD, 7, buf }
> > + };
> > + int result = i2c_transfer(client->adapter, msgs, 2);
> >
> > - result = client->adapter->algo->master_xfer(client->adapter,
> > - &msg[0], 2);
>
> You are doing much more than just using i2c_transfer instead of
> master_xfer. You are also rewriting the way the message data is
> initialized. I see no reason to do that, as the previous code was
> correct as far as I can see.
Right, I just made it shorter. One more point for you, my way is not
struct i2c_msg change proof. I'll drop it.
> > - if (result >= 0) {
> (...)
> > + if (result < 0) {
>
> By changing this you are making your patch much bigger and harder to
> review. Why do you do that?
Here you need to look at patched code. Now conditions in both
ds1337_get_datetime and ds1337_set_datetime look similar, so code is
IHMO easily readable. I'm fine with droping this change.
> > - val = buf[2] & 0x3f;
> > - dt->tm_hour = BCD_TO_BIN(val);
> (...)
> > + dt->tm_hour = BCD2BIN(buf[2] & 0x3f);
>
> No, James is correct. BCD2BIN (or BCD_TO_BIN for that matter) is a
> macro which evaluates its argument more than once. Using a temporary
> variable makes sense.
Agree.
> > + unsigned char buf[8];
> > int result;
> > - u8 buf[8];
>
> Wow, what a useful change. Please please please... Focus on making your
> patch compact, have it do just the thing it is supposed (and advertised)
> to do. You know, I'll repeat it until you get it. No matter how many
> tries it takes.
Save your time I got it. buf is supposed to be char, that's what function
expects. I wrongly made it unsigned. u8, u16 etc. are used in case
when you for example need to generate say 8 bit bus access or need same
width on all architectures. Neither is case here and using u8 makes no
sense. Anyway, will drop change.
> > if (dt->tm_year >= 2000) {
> > - val = dt->tm_year - 2000;
> > buf[6] |= (1 << 7);
> > - } else {
> > - val = dt->tm_year - 1900;
> > - }
> > - buf[7] = BIN_TO_BCD(val);
> > + buf[7] = BIN2BCD(dt->tm_year - 2000);
> > + } else
> > + buf[7] = BIN2BCD(dt->tm_year - 1900);
>
> Same as before, the use of a temporary variable makes full sense, don't
> change that. And you're again adding noise by dropping a pair of curly
> braces.
That's only because I read mail by jgarzik suggesting to remove such
braces few hours ago :) Also, i'll drop this change.
Best regards,
ladis
WARNING: multiple messages have this Message-ID (diff)
From: Ladislav Michl <ladis@linux-mips.org>
To: Jean Delvare <khali@linux-fr.org>
Cc: Greg KH <greg@kroah.com>, LKML <linux-kernel@vger.kernel.org>,
LM Sensors <sensors@Stimpy.netroedge.com>,
James Chapman <jchapman@katalix.com>
Subject: Re: [PATCH] i2c: new driver for ds1337 RTC
Date: Fri, 8 Apr 2005 01:16:50 +0200 [thread overview]
Message-ID: <20050407231650.GA27226@orphique> (raw)
In-Reply-To: <20050407232908.418d8878.khali@linux-fr.org>
Jean,
I'll comment your mail first and then send separate patches (somehow
I can't sleep this night :))
On Thu, Apr 07, 2005 at 11:29:08PM +0200, Jean Delvare wrote:
> > * Move NULL argument checking from get/set date functions to
> > ds1337_command function, so it is only at one place. Note that other
> > drivers do not this checking at all and I think it is pointess,
> > because you have to know that you are passing struct rtc_time
> > anyway.
>
> I am not certain these are the right things to do (moving the check or
> removing it). I am not a specialist of ioctl, but it looks to me that
> ds1337_command acts as a dispatcher, branching to various functions
> depending on the value of cmd. I can imagine that some functions take an
> argument, and some don't, so checking for NULL pointer in the dispatcher
> doesn't make much sense. Now it is correct that for now all (two)
> functions need a parameter, but what if later a function is added, which
> takes no parameter? You'd have to undo your change and move the check in
> each function again.
>
> As for the check itself, the pointer somehow comes from user-space as I
> understand it, so you can't tell whether it's NULL or not - so checking
> makes full sense to me. If you take a look at the rtc8564 driver you'll
> see it *does* check for NULL pointers too.
You can't tell if memory it points to is valid. Okay, probably better
than nothing.
> > @@ -95,60 +96,38 @@
> > */
> > static int ds1337_get_datetime(struct i2c_client *client, struct
> > rtc_time *dt) {
> > - struct ds1337_data *data = i2c_get_clientdata(client);
> > - int result;
> > - u8 buf[7];
> > - u8 val;
> > - struct i2c_msg msg[2];
> > - u8 offs = 0;
> > -
> > - if (!dt) {
> > - dev_dbg(&client->adapter->dev, "%s: EINVAL: dt=NULL\n",
> > - __FUNCTION__);
> > -
> > - return -EINVAL;
> > - }
> > -
> > - msg[0].addr = client->addr;
> > - msg[0].flags = 0;
> > - msg[0].len = 1;
> > - msg[0].buf = &offs;
> > -
> > - msg[1].addr = client->addr;
> > - msg[1].flags = I2C_M_RD;
> > - msg[1].len = sizeof(buf);
> > - msg[1].buf = &buf[0];
> > + unsigned char buf[7] = { 0, }, addr[1] = { 0 };
> > + struct i2c_msg msgs[2] = {
> > + { client->addr, 0, 1, addr },
> > + { client->addr, I2C_M_RD, 7, buf }
> > + };
> > + int result = i2c_transfer(client->adapter, msgs, 2);
> >
> > - result = client->adapter->algo->master_xfer(client->adapter,
> > - &msg[0], 2);
>
> You are doing much more than just using i2c_transfer instead of
> master_xfer. You are also rewriting the way the message data is
> initialized. I see no reason to do that, as the previous code was
> correct as far as I can see.
Right, I just made it shorter. One more point for you, my way is not
struct i2c_msg change proof. I'll drop it.
> > - if (result >= 0) {
> (...)
> > + if (result < 0) {
>
> By changing this you are making your patch much bigger and harder to
> review. Why do you do that?
Here you need to look at patched code. Now conditions in both
ds1337_get_datetime and ds1337_set_datetime look similar, so code is
IHMO easily readable. I'm fine with droping this change.
> > - val = buf[2] & 0x3f;
> > - dt->tm_hour = BCD_TO_BIN(val);
> (...)
> > + dt->tm_hour = BCD2BIN(buf[2] & 0x3f);
>
> No, James is correct. BCD2BIN (or BCD_TO_BIN for that matter) is a
> macro which evaluates its argument more than once. Using a temporary
> variable makes sense.
Agree.
> > + unsigned char buf[8];
> > int result;
> > - u8 buf[8];
>
> Wow, what a useful change. Please please please... Focus on making your
> patch compact, have it do just the thing it is supposed (and advertised)
> to do. You know, I'll repeat it until you get it. No matter how many
> tries it takes.
Save your time I got it. buf is supposed to be char, that's what function
expects. I wrongly made it unsigned. u8, u16 etc. are used in case
when you for example need to generate say 8 bit bus access or need same
width on all architectures. Neither is case here and using u8 makes no
sense. Anyway, will drop change.
> > if (dt->tm_year >= 2000) {
> > - val = dt->tm_year - 2000;
> > buf[6] |= (1 << 7);
> > - } else {
> > - val = dt->tm_year - 1900;
> > - }
> > - buf[7] = BIN_TO_BCD(val);
> > + buf[7] = BIN2BCD(dt->tm_year - 2000);
> > + } else
> > + buf[7] = BIN2BCD(dt->tm_year - 1900);
>
> Same as before, the use of a temporary variable makes full sense, don't
> change that. And you're again adding noise by dropping a pair of curly
> braces.
That's only because I read mail by jgarzik suggesting to remove such
braces few hours ago :) Also, i'll drop this change.
Best regards,
ladis
next prev parent reply other threads:[~2005-05-19 6:25 UTC|newest]
Thread overview: 158+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-31 23:22 [BK PATCH] I2C patches for 2.6.12-rc1 Greg KH
2005-03-31 23:23 ` [PATCH] i2c/i2c-ite: remove interruptible_sleep_on_timeout() usage Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] i2c/i2c-elektor: " Greg KH
2005-05-19 6:25 ` [PATCH] i2c/i2c-elektor: remove interruptible_sleep_on_timeout() Greg KH
2005-03-31 23:23 ` [PATCH] I2C: New lm92 chip driver Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Cleanup adm1021 unused defines Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix adm1021 alarms mask Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Kill unused struct members in w83627hf driver Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Make master_xfer debug messages more useful Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Skip broken detection step in it87 Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: group Intel on I2C Hardware Bus support Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] i2c: new driver for ds1337 RTC Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] i2c: add adt7461 chip support to lm90 driver Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Clean up of i2c-elektor.c build Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix breakage in m41t00 i2c rtc driver Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix some i2c algorithm initialization Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Kill outdated defines in i2c.h Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Avoid repeated resets of i2c-viapro Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Recognize new revision of the ADT7463 chip Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix Vaio EEPROM detection Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: busses documentation update 1 of 2 Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: busses documentation update 2 " Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: lost arbitration detection for PCF8584 Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: lsb in emc6d102 and adm1027 Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Delete useless instruction in it87 Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix race condition in it87 driver Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: i2c-s3c2410 functionality and fixes Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] i2c: add adt7461 chip support to lm90 driver's Kconfig entry Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix broken force parameter handling Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix indentation of lm87 driver Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Drop useless w83781d RT feature Greg KH
2005-05-19 6:25 ` Greg KH
2005-03-31 23:23 ` [PATCH] i2c: i2c-mv64xxx - set adapter owner and class fields Greg KH
2005-05-19 6:25 ` Greg KH
2005-04-07 9:45 ` [PATCH] i2c: new driver for ds1337 RTC Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-07 9:59 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-04-07 11:16 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-07 13:07 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-04-07 14:28 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-07 21:18 ` Greg KH
2005-05-19 6:25 ` Greg KH
2005-04-07 23:17 ` [PATCH] ds1337 1/4 Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-07 23:36 ` Greg KH
2005-05-19 6:25 ` Greg KH
2005-04-08 13:00 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-08 16:31 ` James Chapman
2005-05-19 6:25 ` James Chapman
2005-05-02 20:41 ` Greg KH
2005-05-19 6:25 ` Greg KH
2005-04-08 8:49 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-04-07 23:18 ` [PATCH] ds1337 2/4 Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-08 8:51 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-04-08 13:02 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-05-02 20:41 ` Greg KH
2005-05-19 6:25 ` Greg KH
2005-04-07 23:18 ` [PATCH] ds1337 3/4 Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-08 10:08 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-04-08 13:06 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-05-02 20:41 ` Greg KH
2005-05-19 6:25 ` Greg KH
2005-05-04 6:13 ` [PATCH] ds1337 1/3 Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-05-04 8:41 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-05-04 6:13 ` [PATCH] ds1337 2/3 Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-05-04 9:44 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-05-04 6:14 ` [PATCH] ds1337 3/3 Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-05-04 10:07 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-05-10 12:08 ` [PATCH] ds1337 driver works also with ds1339 chip Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-05-10 12:40 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-05-10 12:48 ` Russell King
2005-05-19 6:25 ` Russell King
[not found] ` <1DTwF8-18P-00@press.kroah.org>
[not found] ` <20050508204021.627f9cd1.khali@linux-fr.org>
[not found] ` <427E6E21.60001@katalix.com>
[not found] ` <20050508222351.08bfe2e1.khali@linux-fr.org>
2005-05-10 12:18 ` [PATCH] ds1337: export ds1337_do_command Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-05-10 12:51 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-05-10 17:55 ` Greg KH
2005-05-19 6:25 ` Greg KH
2005-05-10 18:36 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-05-10 20:30 ` Greg KH
2005-05-19 6:25 ` Greg KH
2005-05-11 8:32 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-07 23:19 ` [PATCH] ds1337 4/4 Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-08 11:08 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-04-08 12:35 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-08 16:21 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-04-08 17:44 ` James Chapman
2005-05-19 6:25 ` James Chapman
2005-04-10 19:51 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-10 21:10 ` Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-04-12 18:10 ` James Chapman
2005-05-19 6:25 ` James Chapman
2005-04-13 11:04 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-04-13 19:02 ` James Chapman
2005-05-19 6:25 ` James Chapman
2005-04-13 19:48 ` Ladislav Michl
2005-05-19 6:25 ` Ladislav Michl
2005-05-19 6:25 ` Jean Delvare
2005-04-07 21:29 ` [PATCH] i2c: new driver for ds1337 RTC Jean Delvare
2005-05-19 6:25 ` Jean Delvare
2005-04-07 23:16 ` Ladislav Michl [this message]
2005-05-19 6:25 ` Ladislav Michl
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=20050407231650.GA27226@orphique \
--to=ladis@linux-mips.org \
--cc=greg@kroah.com \
--cc=jchapman@katalix.com \
--cc=khali@linux-fr.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sensors@Stimpy.netroedge.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 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.