From: Jean Delvare <khali@linux-fr.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: linux-next@vger.kernel.org, Greg KH <greg@kroah.com>
Subject: Re: linux-next: manual merge of i2c tree
Date: Tue, 17 Jun 2008 14:10:04 +0200 [thread overview]
Message-ID: <20080617141004.1fe78ebc@hyperion.delvare> (raw)
In-Reply-To: <20080617142821.88d73657.sfr@canb.auug.org.au>
Hi Stephen,
On Tue, 17 Jun 2008 14:28:21 +1000, Stephen Rothwell wrote:
> Today's linux-next merge if the i2c tree got a conflict in
> drivers/i2c/i2c-core.c between commit
> 5f38434efd52cd113a6bd278d9765f11e63005d7
> ("i2c-use-class_for_each_device") from the driver-core tree and commits
> 30b96672f3860f0b45b4347b0b0280523ca2a5d1 ("i2c: Use
> list_for_each_entry_safe"), d6d4d5deddec521bbac62860338237c448adc5d7
> ("i2c: Simplify i2c_del_driver()") and
> a7e4e16fe30eb27f6d0975d9cd97af157bf7576d ("i2c: Add detection capability
> to new-style drivers") from the i2c tree.
>
> I fixed it up as best I could. Please check after I publish the tree,
> thanks. I took the i2c tree version except that class_for_each_device
> now has an extra argument.
Yes, you did the right thing.
Is there a way Greg and/or I could make your life easier?
>From my point of view, patch "i2c-use-class_for_each_device.patch" in
Greg's tree does two things: it makes i2c-core use
class_for_each_device instead of walking the list manually, and it adds
a parameter to class_for_each_device. The former is something I have
also done in my tree (with a slightly different implementation), the
latter is something I can't do in my tree (as it depends of
driver-core-add-ability-for-class_for_each_device-to-start-in-middle-of-list.patch
in Greg's tree.)
If Greg would pick _my_ i2c-use-class_for_each_device.patch, and would
apply it before his
driver-core-add-ability-for-class_for_each_device-to-start-in-middle-of-list.patch,
and would update that patch to add the extra parameter to the calls in
i2c-core, then we would have a patch in common. Wouldn't it be easier
for Stephen to notice that and discard the redundant copy?
Or this could even be brought one step further. If I know that Greg has
my patch in his tree, and his tree gets sequenced before mine in
linux-next, then I could stop exporting the patch in question to
linux-next (using adequate marks in my series file), so there wouldn't
even be the need to spot the duplicate, and no conflict to solve. My
tree would apply smoothly on top of Greg's.
This would probably help not only Stephen for linux-next, but also Greg
and myself for the next merge window. If Greg merges before me (very
likely) then I simply drop the patch we have in common from my own tree
before I merge it, instead of having to rebase it.
If everyone agrees with this plan, then Greg please:
* Delete your own i2c-use-class_for_each_device.patch, download
http://khali.linux-fr.org/devel/linux-2.6/jdelvare-i2c/i2c-use-class_for_each_device.patch
as a replacement, and sequence it before
driver-core-add-ability-for-class_for_each_device-to-start-in-middle-of-list.patch
in your tree.
* Fold the following patch into
driver-core-add-ability-for-class_for_each_device-to-start-in-middle-of-list.patch
. That's the fixup Stephen had to apply manually so far.
--- linux-2.6.26-rc6/drivers/i2c/i2c-core.c 2008-06-17 13:53:52.000000000 +0200
+++ linux-2.6.26-rc6-next/drivers/i2c/i2c-core.c 2008-06-17 12:58:56.000000000 +0200
@@ -709,7 +709,8 @@
INIT_LIST_HEAD(&driver->clients);
/* Walk the adapters that are already present */
- class_for_each_device(&i2c_adapter_class, driver, __attach_adapter);
+ class_for_each_device(&i2c_adapter_class, NULL, driver,
+ __attach_adapter);
mutex_unlock(&core_lock);
return 0;
@@ -769,7 +770,8 @@
{
mutex_lock(&core_lock);
- class_for_each_device(&i2c_adapter_class, driver, __detach_adapter);
+ class_for_each_device(&i2c_adapter_class, NULL, driver,
+ __detach_adapter);
driver_unregister(&driver->driver);
pr_debug("i2c-core: driver [%s] unregistered\n", driver->driver.name);
--
Jean Delvare
prev parent reply other threads:[~2008-06-17 12:10 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-17 4:28 linux-next: manual merge of i2c tree Stephen Rothwell
2008-06-17 12:10 ` 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=20080617141004.1fe78ebc@hyperion.delvare \
--to=khali@linux-fr.org \
--cc=greg@kroah.com \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
/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