Message ID | CACRpkdZofKjOrPFWNR-2D0LWx3NGMiLwyhf7gAVdvBGvQHqJLQ@mail.gmail.com |
---|---|
State | New |
Headers | show |
On Tue, 20 Sep 2011, Linus Walleij wrote: > Hi Arnd, > > could you please pull: > > git://git.linaro.org/people/triad/linux-stericsson.git for-arnd [...] > Barry Song (1): > ARM: mach-ux500: add explicit cpu_relax() for busy wait loop > > Fredrik Svensson (1): > mach-ux500: remove pull-pinconfig and add SPI2 > > Lee Jones (1): > mach-ux500: remove most of the ugly machine_is_*() calls > > Linus Walleij (2): > mach-ux500: factor out l2x0 handling code > mach-ux500: unlock I&D l2x0 caches before init > > srinidhi kasagar (1): > mach-ux500: enable fix for ARM errata 754322 Please try to include the "ARM: " prefix (or ask the people you merge from) in all the patch titles. Once in mainline with all the other stuff this helps others making sense of the log summaries. no need to redo this lot though. Nicolas
On Tuesday 20 September 2011, Linus Walleij wrote: > could you please pull: > > git://git.linaro.org/people/triad/linux-stericsson.git for-arnd > > to the ARM SoC tree (ux500 branch or however you prefer to handle it)? > They have all been reviewed on the ARM list recently and are mostly > minor fixes and Lee Jones nice cleanup patch. I would really like to see this split into logical branches, even if there are just a few patches for each of them. It looks like the series currently contains bug fixes and cleanups mixed together, which makes it hard to backport fixes and for me to aggregate patches across soc families by category. It's also not clear if the two bug fix patches should be applied to 3.1 and -stable as well as 3.2. My feeling is that they should. If you want bug fixes to be backported, please add a 'Cc: stable@kernel.org' line after your Signed-off-by. If not, add an explanation to the pull request why they are not relevant for backporting. I've applied the first four patches to the stericsson/cleanup and next/cleanup branches now, since these look like they are purely cleanup branches without noticeable code changes. Please submit the two bug fixes again, rebased to an -rc release. there is a dependency on one of the cleanup patches. Don't worry about that, I'll take care of resolving this conflict after you have rebased the bug fix to the mainline kernel. Thanks, Arnd
On Tue, Sep 20, 2011 at 10:48 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 20 September 2011, Linus Walleij wrote: >> to the ARM SoC tree (ux500 branch or however you prefer to handle it)? >> They have all been reviewed on the ARM list recently and are mostly >> minor fixes and Lee Jones nice cleanup patch. > > I would really like to see this split into logical branches, even > if there are just a few patches for each of them. No problem. So the preferred scheme is to have three topics for a SoC: fixes, cleanup and "new stuff" or something like that? > It's also not clear if the two bug fix patches should be applied > to 3.1 and -stable as well as 3.2. My feeling is that they should. Depends. For Srinidhi's "mach-ux500: enable fix for ARM errata 754322" yes, definately. For: "mach-ux500: unlock I&D l2x0 caches before init" it's a performance regression, nothing like a crash or so. (I guess you're referring to these two?) > If you want bug fixes to be backported, please add a 'Cc: stable@kernel.org' > line after your Signed-off-by. If not, add an explanation to the > pull request why they are not relevant for backporting. (...) > Please submit the two bug fixes again, rebased to an -rc release. I'll fix. Since it's just two patches I guess you can just pick these two in plaintext? But I can make a pull request if you prefer... Thanks, Linus Walleij
On Thursday 22 September 2011, Linus Walleij wrote: > On Tue, Sep 20, 2011 at 10:48 PM, Arnd Bergmann <arnd@arndb.de> wrote: > > On Tuesday 20 September 2011, Linus Walleij wrote: > >> to the ARM SoC tree (ux500 branch or however you prefer to handle it)? > >> They have all been reviewed on the ARM list recently and are mostly > >> minor fixes and Lee Jones nice cleanup patch. > > > > I would really like to see this split into logical branches, even > > if there are just a few patches for each of them. > > No problem. So the preferred scheme is to have three topics > for a SoC: fixes, cleanup and "new stuff" or something like that? Roughly, yes. For new stuff, you can have multiple sub-categories, depending on how many patches you have. Some platforms have separated board-specific updates from overall platform changes, which I find very useful. Also, if you add (or remove) a major feature, that can be a branch by itself for this feature. > > It's also not clear if the two bug fix patches should be applied > > to 3.1 and -stable as well as 3.2. My feeling is that they should. > > Depends. For Srinidhi's > "mach-ux500: enable fix for ARM errata 754322" > yes, definately. > > For: > "mach-ux500: unlock I&D l2x0 caches before init" > it's a performance regression, nothing like a crash or so. > > (I guess you're referring to these two?) Right, thanks for the explanation. If the latter is a regression, I'd still treat it as a bug fix. For a general (non-regression) performance improvement, I'd put it into a development branch. > > If you want bug fixes to be backported, please add a 'Cc: stable@kernel.org' > > line after your Signed-off-by. If not, add an explanation to the > > pull request why they are not relevant for backporting. > (...) > > Please submit the two bug fixes again, rebased to an -rc release. > > I'll fix. > > Since it's just two patches I guess you can just pick these > two in plaintext? But I can make a pull request if you prefer... In general, I prefer pull requests, but if you have no other patches for 3.2, I can just cherry-pick them from the branch I already pulled. I would put the first patch into fixes for 3.1 and mark it as 'Cc:stable' and the other one into fixes for 3.2 then. Arnd