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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
