On Mon, Jun 16, 2014 at 02:17:30PM +0200, Ulf Hansson wrote:
> On 16 June 2014 12:46, Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx> wrote:
> > On Wed, Apr 23, 2014 at 08:08:07PM +0100, Russell King wrote:
> >> @@ -1507,25 +1529,7 @@ static void sdhci_do_set_ios(struct sdhci_host *host, struct mmc_ios *ios)
> >> host->ops->set_clock(host, host->clock);
> >> }
> >>
> >> - if (host->ops->set_uhs_signaling)
> >> - host->ops->set_uhs_signaling(host, ios->timing);
> >> - else {
> >> - ctrl_2 = sdhci_readw(host, SDHCI_HOST_CONTROL2);
> >> - /* Select Bus Speed Mode for host */
> >> - ctrl_2 &= ~SDHCI_CTRL_UHS_MASK;
> >> - if ((ios->timing == MMC_TIMING_MMC_HS200) ||
> >> - (ios->timing == MMC_TIMING_UHS_SDR104))
> >> - ctrl_2 |= SDHCI_CTRL_UHS_SDR104;
> >> - else if (ios->timing == MMC_TIMING_UHS_SDR12)
> >> - ctrl_2 |= SDHCI_CTRL_UHS_SDR12;
> >> - else if (ios->timing == MMC_TIMING_UHS_SDR25)
> >> - ctrl_2 |= SDHCI_CTRL_UHS_SDR25;
> >> - else if (ios->timing == MMC_TIMING_UHS_SDR50)
> >> - ctrl_2 |= SDHCI_CTRL_UHS_SDR50;
> >> - else if (ios->timing == MMC_TIMING_UHS_DDR50)
> >> - ctrl_2 |= SDHCI_CTRL_UHS_DDR50;
> >> - sdhci_writew(host, ctrl_2, SDHCI_HOST_CONTROL2);
> >> - }
> >> + host->ops->set_uhs_signaling(host, ios->timing);
> >>
> >> if (!(host->quirks2 & SDHCI_QUIRK2_PRESET_VALUE_BROKEN) &&
> >> ((ios->timing == MMC_TIMING_UHS_SDR12) ||
> >
> > Whoever decided to poorly pick these patches up against my will has
> > slightly messed this patch up - whereas my original patch left the
> > code correctly formatted, when whoever applied this patch did so, they
> > left an additional blank line in the above.
>
> Hi Russell,
>
> We kindly pinged you several times asking for your state and for the
> PR, but I suppose you were just too busy. Your PR were kind of
> blocking patches for sdhci, if you remember.
I wasn't "too busy". I had walked away from all kernel maintanence in
disgust at the way many in the ARM community ignores questions, and
ignores patches which need testing - I'm talking there about the L2C
patch series which was extremely poorly tested, and still, to this day,
has questions outstanding. Yes, the code now produces warnings. It
produces warnings /because/ people were not willing to help.
Those warnings serve as a reminder that there's still problems which
need solving there, and they're not going to go away until those
problems are solved.
While I don't like pushing unfinished code into mainline, in this case,
others deemed the patch set too important _not_ to go into mainline
even with these problems.
Now, it's been /soo/ long since I worked on that patch set that my
knowledge has now diminished... so it's now going to be _much_ harder
to resolve those issues than it would have been three months ago.
And I'm also holding a grudge, and I bear grudges for a long time, so
expect me to be "difficult" towards Linux stuff for a while yet.
> The mmc people were also very helping in sending patches to fixup
> related regressions, immediately after we merged your patchset. Thus
> together I think we managed to pull it off.
The formatting problem I refer to above is line 1532/1533 in sdhci.c -
there's an additional blank line which somehow got left behind, caused
presumably by insufficient attention paid to cleaning up a conflict
between my original patches and the state of the tree they were
applied to.
--
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 linux-mmc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
