[U-Boot-Users] [PATCH] Fix USB support issue for MPC8641HPCN board.

[Jerry Van Baren]

Jon Loeliger wrote:
> On Wed, 2007-10-31 at 05:20, Wolfgang Denk wrote:
>> In message <87pryv63m3.fsf at denx.de> you wrote:
>>>> The configuration file has already enabled USB, but it
>>>> missed definition of CFG_OHCI_SWAP_REG_ACCESS, the USB
>>>> on MPC8641HPCN can not work because of the wrong USB
>>>> register endian.
>>>>
>>>> And add the USB command to U-Boot commands list.
>>>>
>>>> Signed-off-by: Zhang Wei <wei.zhang at freescale.com>
>>> Who will take care of this patch? I think patches to board configs
>>> generally should be taken care of board / architecture, not subsystem
>>> maintainers. That path is less prone of causing conflicts.
>> Correct. This should go through the 86xx repo.
> 
> Right.  This patch is mine.
> 
> Wolfgang, procedural question for you, though.
> 
> I have already applied patches for the new MPC8610HPCD
> board port to the -mpc86xx custodian repository's master
> branch.  My original notion was to wait until the next
> merge window after 1.3.0 to have you pull these three
> patches.
> 
> However, there are several more bug-fix patches that
> need to go through the -mpc86xx repository now too.
> 
> How would you like to handle this?  I see a few viable
> options:
> 
> 1) I can just apply bug fixes to -mpc86xx master as well,
>     have you pull it, and pick up the new 8610 port anyway.
> 
> 2) Apply the bug fixes to a different branch in -mpc86xx
>     and ask you to pull that specific branch.
> 
> 3) Just ACK patches on list and have you apply them
>     one-at-a-time "by hand" directly,
> 
> 4) Uh, something else...?
> 
> Thanks,
> jdl

Yeah, that is one reason I have been advocating a "for Wolfgang" (merge) 
branch and keeping the master branch a clean to track u-boot.git.  Not 
necessarily the best way, but the best way I know how...

On option 4, you could clone your master branch into a "for the next 
merge window" (testing?) branch to preserve your patches, reset --hard 
your master back to match the current u-boot.git revision level, and 
then apply the bug fixes to the master (or a "merge" branch if you think 
this might happen again ;-).

You will probably have to --force pushes back to denx.de and if someone 
has cloned your -86xx repo, this will probably mess him up (not 
irreparably, but still annoying). :-(

With this method, you can keep rebasing your "for the next merge window" 
against your master branch (updated from u-boot.git) to keep it surfing 
ahead of the wave.

---

Wolfgang has (strongly) expressed his preference for pulling from the 
"master" branch, any my advocation of a "merge" branch doesn't work this 
way.

An alternative methodology that I have not tried yet, but seems logical, 
is to have a "sync" branch that the custodian uses to pull u-boot.git 
into and then rebase the "master" branch against it to keep it surfing 
ahead of u-boot.git.  This should work and keep Wolfgang happier at the 
same time.  Note that the "sync" branch does not need to be pushed back 
to the denx.de custodian repository.

clone u-boot.git <--- u-boot.git
   |                      |
   v                      |
master                   |
   |\ branch            PatchA
   | ------ sync          |
   |         |          PatchB
Patch1      |            |
   |         |  pull     /|
Patch2      | ---------- :
   |         |/           :
   |       PatchA
   |         |
   |       PatchB
   |         |
   | rebase /|
   | ------- :
   |/        :
PatchA
   |
PatchB
   |
Patch1
   |
Patch2
   :
   :


Looks reasonable in ASCII-art.

Thoughts?
gvb