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
prev parent reply other threads:[~2005-04-07 23:17 UTC|newest]
Thread overview: 79+ 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-03-31 23:23 ` [PATCH] i2c/i2c-elektor: " Greg KH
2005-03-31 23:23 ` [PATCH] I2C: New lm92 chip driver Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Cleanup adm1021 unused defines Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix adm1021 alarms mask Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Kill unused struct members in w83627hf driver Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Make master_xfer debug messages more useful Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Skip broken detection step in it87 Greg KH
2005-03-31 23:23 ` [PATCH] I2C: group Intel on I2C Hardware Bus support Greg KH
2005-03-31 23:23 ` [PATCH] i2c: new driver for ds1337 RTC Greg KH
2005-03-31 23:23 ` [PATCH] i2c: add adt7461 chip support to lm90 driver Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Clean up of i2c-elektor.c build Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix breakage in m41t00 i2c rtc driver Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix some i2c algorithm initialization Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Kill outdated defines in i2c.h Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Avoid repeated resets of i2c-viapro Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Recognize new revision of the ADT7463 chip Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix Vaio EEPROM detection Greg KH
2005-03-31 23:23 ` [PATCH] I2C: busses documentation update 1 of 2 Greg KH
2005-03-31 23:23 ` [PATCH] I2C: busses documentation update 2 " Greg KH
2005-03-31 23:23 ` [PATCH] I2C: lost arbitration detection for PCF8584 Greg KH
2005-03-31 23:23 ` [PATCH] I2C: lsb in emc6d102 and adm1027 Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Delete useless instruction in it87 Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix race condition in it87 driver Greg KH
2005-03-31 23:23 ` [PATCH] I2C: i2c-s3c2410 functionality and fixes Greg KH
2005-03-31 23:23 ` [PATCH] i2c: add adt7461 chip support to lm90 driver's Kconfig entry Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix broken force parameter handling Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Fix indentation of lm87 driver Greg KH
2005-03-31 23:23 ` [PATCH] I2C: Drop useless w83781d RT feature Greg KH
2005-03-31 23:23 ` [PATCH] i2c: i2c-mv64xxx - set adapter owner and class fields Greg KH
2005-04-07 9:45 ` [PATCH] i2c: new driver for ds1337 RTC Ladislav Michl
2005-04-07 9:59 ` Jean Delvare
2005-04-07 11:16 ` Ladislav Michl
2005-04-07 13:07 ` Jean Delvare
2005-04-07 14:28 ` Ladislav Michl
2005-04-07 21:18 ` Greg KH
2005-04-07 23:17 ` [PATCH] ds1337 1/4 Ladislav Michl
2005-04-07 23:36 ` Greg KH
2005-04-08 13:00 ` Ladislav Michl
2005-04-08 16:31 ` James Chapman
2005-05-02 20:41 ` Greg KH
2005-04-08 8:49 ` Jean Delvare
2005-04-07 23:18 ` [PATCH] ds1337 2/4 Ladislav Michl
2005-04-08 8:51 ` Jean Delvare
2005-04-08 13:02 ` Ladislav Michl
2005-05-02 20:41 ` Greg KH
2005-04-07 23:18 ` [PATCH] ds1337 3/4 Ladislav Michl
2005-04-08 10:08 ` Jean Delvare
2005-04-08 13:06 ` Ladislav Michl
2005-05-02 20:41 ` Greg KH
2005-05-04 6:13 ` [PATCH] ds1337 1/3 Ladislav Michl
2005-05-04 8:41 ` Jean Delvare
2005-05-04 6:13 ` [PATCH] ds1337 2/3 Ladislav Michl
2005-05-04 9:44 ` Jean Delvare
2005-05-04 6:14 ` [PATCH] ds1337 3/3 Ladislav Michl
2005-05-04 10:07 ` Jean Delvare
2005-05-10 12:08 ` [PATCH] ds1337 driver works also with ds1339 chip Ladislav Michl
2005-05-10 12:40 ` Jean Delvare
2005-05-10 12:48 ` 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-10 12:51 ` Jean Delvare
2005-05-10 17:55 ` Greg KH
2005-05-10 18:36 ` Ladislav Michl
2005-05-10 20:30 ` Greg KH
2005-05-11 8:32 ` Ladislav Michl
2005-04-07 23:19 ` [PATCH] ds1337 4/4 Ladislav Michl
2005-04-08 11:08 ` Jean Delvare
2005-04-08 12:35 ` Ladislav Michl
2005-04-08 16:21 ` Jean Delvare
2005-04-08 17:44 ` James Chapman
2005-04-10 19:51 ` Ladislav Michl
2005-04-10 21:10 ` Jean Delvare
2005-04-12 18:10 ` James Chapman
2005-04-13 11:04 ` Ladislav Michl
2005-04-13 19:02 ` James Chapman
2005-04-13 19:48 ` Ladislav Michl
2005-04-07 21:29 ` [PATCH] i2c: new driver for ds1337 RTC Jean Delvare
2005-04-07 23:16 ` Ladislav Michl [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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox