Jon Loeliger wrote:
On Wed, 2007-10-31 at 05:20, Wolfgang Denk wrote:
In message 87pryv63m3.fsf@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@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:
I can just apply bug fixes to -mpc86xx master as well, have you pull it, and pick up the new 8610 port anyway.
Apply the bug fixes to a different branch in -mpc86xx and ask you to pull that specific branch.
Just ACK patches on list and have you apply them one-at-a-time "by hand" directly,
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