From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Wed, 31 Oct 2007 13:13:49 -0400 Subject: [U-Boot-Users] [PATCH] Fix USB support issue for MPC8641HPCN board. In-Reply-To: <1193844542.24526.8.camel@ld0161-tx32> References: <20071031102049.5B4AD247F4@gemini.denx.de> <1193844542.24526.8.camel@ld0161-tx32> Message-ID: <4728B7CD.6020300@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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 >>> 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