public inbox for linuxppc-dev@ozlabs.org 
 help / color / mirror / Atom feed

From: Jean Delvare <khali@linux-fr•org>
To: "Mark A. Greer" <mgreer@mvista•com>
Cc: LM@ozlabs•org, linuxppc-embedded@ozlabs•org,
	Sensors <lm-sensors@lm-sensors•org>
Subject: Re: [lm-sensors] Re: [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip
Date: Thu, 9 Jun 2005 21:29:33 +0200	[thread overview]
Message-ID: <20050609212933.2fa44d62.khali@linux-fr.org> (raw)
In-Reply-To: <42A89338.209@mvista.com>

Hi Mark,

> I interpreted the doc the same way Randy did when I did the m41t00
> chip  code.  Also, Mark Studebaker seemed to support that
> interpretation in  this email:
> http://archives.andrew.net.au/lm-sensors/msg29325.html

I am not discussing the fast that using basic SMBus commands increases
the number of system the driver will be usable on. This is quite
obviously true, and I am fine with using this when there is no
performance drawback.

However, in the case of the DS1374, reading the registers as a block
would make the driver *much* faster and more simple. This has to be
considered, especially if the DS1374 chip is found on a limited number
of systems.

If you think the documentation should be updated to reflect that better,
well, patches are welcome ;)

> I suppose the best thing to do is check if the adapter is a true i2c 
> ctlr (something like: i2c_check_functionality(adapter, I2C_FUNC_I2C)) 
> and base the cmds used on that.
> 
> We can do something similar with I2C_FUNC_SMBUS_READ_I2C_BLOCK & 
> I2C_FUNC_SMBUS_WRITE_BLOCK_DATA to check if we can use the smbus
> block cmds too, correct?

There is actually no benefit in checking for true I2C, since the
commands you would then build would be exactly I2C_FUNC_SMBUS_READ_I2C
and I2C_FUNC_SMBUS_WRITE_BLOCK_DATA. Better check for these directly, as
some non-I2C masters will support them (especially the second, the first
one is only rarely found). If both functions are supported, go with
this. If not, either fallback to the current code, or drop this code and
state that this isn't supported (I'd do that). If it happens that this
support is ever needed, it can be added back at that time - but that
time may never actually come.

Thanks,
-- 
Jean Delvare

next prev parent reply	other threads:[~2005-06-09 19:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-03 21:36 [PATCH 1/2] Add support for Maxim/Dallas DS1374 Real-Time Clock Chip Randy Vinson
2005-06-03 21:41 ` Kumar Gala
2005-06-03 22:05   ` Randy Vinson
2005-06-03 21:43 ` [PATCH 2/2] " Randy Vinson
2005-06-03 21:46 ` [PATCH 1/2] " Eugene Surovegin
2005-06-03 22:17   ` Randy Vinson
2005-06-09 17:25     ` [lm-sensors] " Jean Delvare
2005-06-09 19:06       ` Mark A. Greer
2005-06-09 19:29         ` Jean Delvare [this message]
2005-06-09 18:21 ` [lm-sensors] " Jean Delvare

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=20050609212933.2fa44d62.khali@linux-fr.org \
    --to=khali@linux-fr$(echo .)org \
    --cc=LM@ozlabs$(echo .)org \
    --cc=linuxppc-embedded@ozlabs$(echo .)org \
    --cc=lm-sensors@lm-sensors$(echo .)org \
    --cc=mgreer@mvista$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox