linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
To: Wolfram Sang <w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Cc: Linux I2C <linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Ben Dooks <ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
Subject: Re: [PATCH] i2c: Minor fixes to upgrading-clients document
Date: Sun, 20 Feb 2011 18:01:31 +0100	[thread overview]
Message-ID: <20110220180131.6683e2d2@endymion.delvare> (raw)
In-Reply-To: <20110220140837.GA14786-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

On Sun, 20 Feb 2011 15:08:38 +0100, Wolfram Sang wrote:
> On Sun, Feb 20, 2011 at 03:04:08PM +0100, Jean Delvare wrote:
> 
> > * Typical legacy drivers implemented method .detach_client, not
> >   .detach_adapter.
> > * Drop all references to __devexit, as i2c drivers shouldn't use it.
> 
> Even not in remove()? 40 out of 84 drivers are doing so.

Well, unless I am seriously mistaken, this isn't always safe.

Consider the case where !CONFIG_HOTPLUG and your i2c device driver is
built into the kernel (not as a module). The __devexit function will be
stripped at link time. If the i2c _bus_ driver is built as a module, it
can be inserted and removed at any time. When the bus driver is
removed, the .remove() method of every I2C device on this bus should be
called, except that your driver won't have any, so the clean-up won't
happen and you end up with a half-registered device.

So __devexit on the remove function on an i2c device driver is only
safe if the i2c bus driver is built into the kernel. Unfortunately,
unless !CONFIG_MODULES, the i2c device drivers have no way to tell if
this will be the case.

-- 
Jean Delvare

      parent reply	other threads:[~2011-02-20 17:01 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-20 14:04 [PATCH] i2c: Minor fixes to upgrading-clients document Jean Delvare
     [not found] ` <20110220150408.03e9a674-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2011-02-20 14:08   ` Wolfram Sang
     [not found]     ` <20110220140837.GA14786-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2011-02-20 17:01       ` Jean Delvare [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=20110220180131.6683e2d2@endymion.delvare \
    --to=khali-puyad+kwke1g9huczpvpmw@public.gmane.org \
    --cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=w.sang-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).