[U-Boot] [PATCH v2 4/5] usb: ulpi: add indicator configuration function

[Marek Vasut]

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