All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] new [PATCH] I2C: add new rx8025 driver
Date: Sat, 04 Mar 2006 16:02:26 +0000	[thread overview]
Message-ID: <20060304170226.21caf195.khali@linux-fr.org> (raw)
In-Reply-To: <20060203134225.GA4398@digi.com>

Hi Uwe,

Sorry for the late answer.

> here comes a reworked driver (in a seperate e-mail to ease applying it).
> I didn't implemented all your suggestions, as commented below.
> 
> I didn't (yet) used Alessandro's rtc core as it doesn't compile on
> current HEAD.  (Moreover my driver has to work on 2.6.12.5, because
> that's the version our customer has to stick to.)

True, but if we merge your driver in the main Linux tree, it'll happen
at best in 2.6.17-rc1 so the version we'll merge will not be compatible
with 2.6.12.5 anyway. You must have noticed that the i2c subsystem had
a few minor changes in the last few Linux releases. So, given that you
will have to maintain a separate version for your customer anyway, we
better make the merged driver comply with the latest standards.

These latest standards include Alessandro Zummo's rtc core and kzalloc,
but also the new mutex implementation, and in a near future (I hope...)
the new explicit i2c client attach method.

> Still open: I don't know if the mutex is needed.  I didn't see it in
> other drivers but in my eyes it must be there.  Any comments?

On second read, I think it is needed, but maybe not for the reasons you
thought. It is needed to make sure that the i2c client won't be freed
while you're using it. It is not needed for I2C transfers themselves,
as the i2c-core already handles the locking there. So, it looks to me
like you are not always holding the lock when you need it. For example,
in rx8025_get_rtctime, you release the lock, then right after you use
&rx8025_rtcclient->dev. This doesn't look correct to me.

Anyway, Alessandro told me that the rtc core may handle that kind of
lock, so it's probably not worth investigating until your driver has
been converted to that subsystem.

> I hope I catched all the remaining points to your satisfaction.

Seems so, or at least enough for me to accept your driver, except that
I'd like it to be ported to the rtc core instead, as explained above. I
think Alessandro is willing to help with that, so please see with him
how you want to handle it; it shouldn't be very difficult.

Thanks,
-- 
Jean Delvare


  reply	other threads:[~2006-03-04 16:02 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-03 13:42 [lm-sensors] new [PATCH] I2C: add new rx8025 driver Uwe Zeisberger
2006-03-04 16:02 ` Jean Delvare [this message]
2006-03-06  7:30 ` Uwe Zeisberger

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=20060304170226.21caf195.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=lm-sensors@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.