All of lore.kernel.org
 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-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: removing set_clientdata(NULL)
Date: Tue, 30 Mar 2010 09:05:27 +0200	[thread overview]
Message-ID: <20100330090527.303e2386@hyperion.delvare> (raw)
In-Reply-To: <20100330024831.GB23862-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>

Hi Wolfram,

On Tue, 30 Mar 2010 04:48:31 +0200, Wolfram Sang wrote:
> On Mon, Mar 29, 2010 at 05:27:34PM +0200, Jean Delvare wrote:
> > Not sure what you mean there... What's the alternative?
> 
> I was confused by your "so that drivers can start removing the call on their
> end quickly". It sounded a bit like they should care themselves.

Ah. I mean that if they care, they can do it themselves. But most
probably they don't care and will leave it up to us (that is, you).

> > No, 2.6.35. This touches too many drivers for 2.6.34 at this point in
> > time.
> 
> I agree. So I base the removal-patch on rc3, so it can go to linux-next. If
> there are other users of i2c_set_clientdata popping up until the merge-window,
> it will be handled by an incremental patch.
> 
> > > - also patches per subsystem?
> > 
> > Not sure if it's worth the effort.
> 
> Not much effort, I made scripts for that :) Still, I think it should go in just
> using one commit. Let's hope it won't get too intrusive (= creating conflicts).

If it turns out to be an issue, I guess we could hold on and generate
the path again at the end of the 2.6.35 merge window.

> > > - shall this better go via the i2c-tree?
> > 
> > This seems simpler, yes. I don't think subsystem or driver maintainers
> > need to be bothered with what is really only a cleanup.
> 
> Yes.

Thanks,
-- 
Jean Delvare

      parent reply	other threads:[~2010-03-30  7:05 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-27 12:15 removing set_clientdata(NULL) Wolfram Sang
     [not found] ` <20100327121558.GA5880-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2010-03-29 14:28   ` Jean Delvare
     [not found]     ` <20100329162812.548d131b-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2010-03-29 15:09       ` Wolfram Sang
     [not found]         ` <20100329150956.GB6717-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2010-03-29 15:27           ` Jean Delvare
     [not found]             ` <20100329172734.7cd7341d-ig7AzVSIIG7kN2dkZ6Wm7A@public.gmane.org>
2010-03-29 15:49               ` Mark Brown
     [not found]                 ` <20100329154910.GE13239-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2010-03-29 16:43                   ` Jean Delvare
2010-03-30  2:48               ` Wolfram Sang
     [not found]                 ` <20100330024831.GB23862-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2010-03-30  7:05                   ` 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=20100330090527.303e2386@hyperion.delvare \
    --to=khali-puyad+kwke1g9huczpvpmw@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 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.