linux-kernel - Re: [PATCH] usb: host: tegra: code clean up

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5051662E.1040908@wwwdotorg.org>
Date:	Wed, 12 Sep 2012 22:50:54 -0600
From:	Stephen Warren <swarren@...dotorg.org>
To:	Venu Byravarasu <vbyravarasu@...dia.com>
CC:	"balbi@...com" <balbi@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>
Subject: Re: [PATCH] usb: host: tegra: code clean up

On 09/12/2012 09:42 PM, Venu Byravarasu wrote:
> Stephen Warren wrote at Wednesday, September 12, 2012 11:41 PM:
>> On 09/12/2012 01:02 AM, Venu Byravarasu wrote:
>>> As part of code clean up, used devm counterparts for the APIs
>>> possible.
>>
>> Almost all of this patch has already been applied as:
> 
> Agree. 
> Currently Balbi's tree has bit old ehci-tegra.c.

Quite possibly. That would happen if patches to ehci-tegra.c were
checked into other branches, which have not yet been merged to Linus's
tree, and hence have not made it into the baseline for Felipe's tree.
This is especially likely as ehci-tegra.c isn't something that Felipe's
xceiv branch would usually take patches for IIRC.

> Because of this the patches prepared with linux-next need to be rebased onto this tree and prepare a new patch.
> My main intention behind pushing this patch was to get all changes of ehci-tegra.c from linux-next into balbi's code base so that I can push the same patch against either balbi's tree or linux-next.

That's not the way the Linux branching model works. The primary way for
Felipe's branch to pick up changes from another branch is for the other
branch to be merged by Linus, and then Felipe to either merge Linus's
branch into his, or start a new branch based on a more recent tag from
Linus's tree. If you send patches to Felipe that duplicate work that's
already happened in another branch, you'll most likely end up causing
merge conflicts when Felipe's branch is merged with the other branch
containing the same work in linux-next, Greg's USB tree, and Linus's
tree. Of course, you might get lucky and avoid conflicts if the patches
are identical, but duplicate patches are still not a good idea.

It's best if you send patches that apply and operate correctly on one
particular branch, e.g. just Felipe's or some other USB
(sub-)maintainer's branch.

If your patches actually rely on changes from multiple different
branches, then that is problematic. The simplest answer is to simply
wait for the (end of the) next kernel merge window when everything has
been merged together, and then start sending patches based on the merged
result.

In some cases, branches can be merged together other than by Linus,
although you do have to be quite careful to avoid pain when doing this.
It's best to plan out what patches you'll send, where you expect they
will be applied, and point out any such dependencies to the maintainers
ahead of time. Developing all your big patches first and then sending
them, rather than developing them piecemeal, may help you plan this out
better, at least at first.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/