On 25 April 2014 13:20, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: > On Fri, Apr 25, 2014 at 01:18:28PM +0200, Ulf Hansson wrote: >> On 25 April 2014 11:03, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: >> > On Thu, Apr 24, 2014 at 01:13:05PM +0200, Ulf Hansson wrote: >> >> On 24 April 2014 12:57, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote: >> >> > This is nothing new or unexpected - it was last posted back in February, >> >> > and I elected that it should be held off until after the last merge >> >> > window. >> >> > >> >> > Unfortunately, I didn't have time to post it immediately after the merge >> >> > window closed, partly because it needed to be rebased on top of tglx's >> >> > IRQ changes on which it depends. I was carrying those as separate commits >> >> > to the ones Thomas was carrying in his tree - and in the event, Thomas had >> >> > modified his patches slightly between sending me copies of them and the >> >> > versions he sent during the merge window. >> >> >> >> Okay, so let's keep up the frequency here then. I only had some minor >> >> comments, please fix them and send a v2. >> > >> > Right, so I've updated the patches, and added one ack to one patch. >> > That seems insufficient to me - the only platform these have been >> > tested on is iMX6, which is sdhci-esdhc-imx.c. >> > >> > They _really_ need testing elsewhere too. Or is the plan to merge >> > them and then see about getting people to test them and fix them up >> > afterwards? >> >> I was hoping people could start doing tests, before Chris actually >> decided to pull them in. Now, if that doesn't happen, we could just >> merge them, as you say, and thus we have to fix potential problems >> afterwards. I would expect you to help out if problem occurs. >> >> If we decide to not merge in a while, I am not sure how long we could >> prevent other sdhci patches from being merged. I guess Chris will have >> to take the final call. > > Or we just drop them for yet another cycle and show how mainline kernel > development sucks, why getting stuff into mainline is utterly painful, > and why using vendor kernels is /soo/ much better than this crap. Dropping them is too me a bad option and I really don't think that should be needed. I would like to encourage people to help out with testing and I suppose we have to give this at least some time. Anyway, post your new version. I will create the pull request based on that. > > -- > FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly > improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
