From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Fri, 7 Sep 2012 02:11:36 +0200 Subject: [U-Boot] [PATCH v2 4/5] usb: ulpi: add indicator configuration function In-Reply-To: <1346890017.1487.37.camel@tellur> References: <1345580337-9377-1-git-send-email-dev@lynxeye.de> <5FBF8E85CA34454794F0F7ECBA79798F379E0065C9@HQMAIL04.nvidia.com> <1346890017.1487.37.camel@tellur> Message-ID: <201209070211.36464.marex@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Dear Lucas Stach, > Hi Tom, > > Am Mittwoch, den 05.09.2012, 09:25 -0700 schrieb Tom Warren: > > Igor/Marek, > > > > > -----Original Message----- > > > From: Marek Vasut [mailto:marex at denx.de] > > > Sent: Wednesday, September 05, 2012 1:52 AM > > > To: Igor Grinberg > > > Cc: Lucas Stach; u-boot at lists.denx.de; Stephen Warren; Tom Warren > > > Subject: Re: [PATCH v2 4/5] usb: ulpi: add indicator configuration > > > function > > > > > > Dear Igor Grinberg, > > > > > > > Hi Lucas, Tom, > > > > > > > > I'm sorry for the late reply. > > > > I understand, that Tom has already applied this to tegra/next, but as > > > > the changes/follow up patches are required, may be we can do this in > > > > another fashion... > > > > > > > > 1) Thanks for the patch and working on extending the generic > > > > framework! 2) This patch has no dependencies on tegra specific > > > > patches, so > > > > > > > > I think, it should go through Marex usb tree, but doing this will > > > > require the right merge order, so bisectability will not suffer. > > > > So, Marek, Tom, you should decide which way is fine with you both. > > > > I'm not sure how the USB and Tegra repos can coordinate on patches like > > this, since I don't pull from/rebase against USB, and AFAIK Marek > > doesn't reference Tegra when he updates his repo. I'm a sub-repo of ARM, > > which is a sub-repo of TOT (u-boot/master). What I usually do (and have > > always done) is to take the entire patchset that includes a Tegra > > component (USB, mmc, SPI, etc.) and hope (pray?) that anyone merging my > > changes upstream of me will be able to resolve the > > conflicts/pre-existing patches. So far, I haven't heard from anyone > > (Albert or Wolfgang) that's had a problem with that, perhaps because > > it's pretty rare. AFAICT, there's no other procedure outlined in the > > U-Boot wiki custodian's page. If there's a better procedure I should be > > following, let's get it documented and I'll be glad to hew to the line. > > I'm still on the learning curve for git merging, rebasing, etc. > > I thought about how we could merge all this without loosing our sanity. > I've already wrote this a bit hidden in a reply to the multi controller > thread: I think it's best to handle all USB related changes through the > u-boot-usb tree, as all this stuff should really be under drivers/usb. Let's extend this a bit. Since I'm really under heavy load now, why don't you prepare a patchset (that includes all the tegra goo, stuff that Tom will drop etc) that I can pick, submit it (and Cc me) and I'll just pick it all ? That way we'll have a proper ordering and nothing will be lost and all will be tested. > This means: I'll split out the clock output related changes, so they can > go in the Tegra tree. Everything touching USB goes into the u-boot-usb > tree and I'll rebase my changes accordingly. This also means commit "dm: > Tegra: Staticize local functions" should be removed from the Tegra tree > and move over to the USB tree. Drop the dm: from it along the way. > This way we won't get any build breakages and there should be no merge > conflicts. It also opens the possibility to move the Tegra USB > implementation to the right location in the source tree a bit later in > this cycle, without messing up the merge. > > Thanks, > Lucas Best regards, Marek Vasut