On 21 December 2015 at 14:59, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: > On 21 December 2015 at 14:41, Russell King - ARM Linux > <linux@xxxxxxxxxxxxxxxx> wrote: >> On Mon, Dec 21, 2015 at 02:23:17PM +0100, Ulf Hansson wrote: >>> On 21 December 2015 at 13:51, Russell King - ARM Linux >>> <linux@xxxxxxxxxxxxxxxx> wrote: >>> > On Mon, Dec 21, 2015 at 01:35:36PM +0100, Ulf Hansson wrote: >>> >> I decided to try to apply it for my next branch, to get some good test >>> >> coverage. Although, it failed when reaching patch 8. Would you mind >>> >> posting yet another new re-based version, please. >>> > >>> > Given that these are _fixes_ and need to be applied to -rc kernels, they >>> > are based on -rc6. I don't see the point of rebasing them onto non-rc >>> > kernels to test, because then you're not testing against where they >>> > should be applied. >>> >>> I see your point, but I would rather not aim for rcs with these >>> changes, unless you insist. >>> >>> Not because they aren't fixes, but because it's old errors. Instead we >>> can "cc stable" or use the fixes tag as we are in quite late stage of >>> the rc. This approach will also allow us to get a bit better test >>> coverage. >> >> Even if we do this, we still need to get _these_ tested because _these_ >> will be the ones which need to be applied to stable trees such as the >> 4.4 stable series. >> >> What I suggest is applying them against -rc6, and then merging them >> into your -next branch, and fixing the resulting conflicts. We then >> have the patches ready for -rc, but which can still be tested in -next >> (for what that's worth.) If people find problems, they can always >> re-test these patches without all the development stuff. >> >> If I were to give you a set of patches suitable just for -next, then >> people can only test with all the development stuff included, and we'll >> have no idea whether any new problems are the result of development or >> these patches. > > Okay! I will publish the branch as soon as I can. Huh. The merge ends up in a quite complicated conflict to resolve for me. And I am running out of time. I have queued a quite limited amount of sdhci patches for this cycle, so indeed I think it's good opportunity to try out your changes right now. In particular, it's the following patch which I have queued for next that conflicts with your changes. "mmc: sdhci: 64-bit DMA actually has 4-byte alignment" Could you perhaps reconsider to rebase your patches on top of my next branch. I have also rebased my next branch on top of rc6. Kind regards Uffe -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
