Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1367603

Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors

Show all headers | View raw

On Wed, Mar 30, 2016 at 10:06:36PM +0200, Enric Balletbo Serra wrote:
> El dia 30/03/2016 19:26, "Russell King - ARM Linux" <linux@arm.linux.org.uk>
> va escriure:
> > I'd really suggest that the dw-mmc folk place a moritorium on quirk
> > flags, and instead deal with situations like this without resorting
> > to this kind of thing.
> >
> > sdhci is a good example why the quirk flag approach is totally wrong,
> > and shows that it leads to an unmaintainable mess.  If dw-mmc people
> > don't want the driver to decend into the same state that sdhci is,
> > then things like this should not be quirks.  sdhci already has a
> > long-term moritorium on quirk flags until the resulting mess has been
> > cleaned up.
> >
> 
> You mean that was a mess in the past and now is cleaned up?

SDHCI is far from being "cleaned up" - the conclusion that I've put
forward, and Ulf appears to agree with is that the core SDHCI driver
needs to become a library.

We then need individual drivers, which make selective use of the
library functions, and the "quirks" implemented as either fixes to
the core code or implemented by replacement functions.

The problem with SDHCI is that it's not far off having every other
line of code being conditional on a quirk flag - I've submitted to
very large series of patches so far doing a series of code transforms
to reduce this, but the job is nowhere near complete.  Given the
number of drivers, it's something that needs to be done with care
and over a period of time.

This is why I'm warning about this as soon as I've heard another
driver going down the quirks route - hopefully you can avoid this
mistake early enough that it doesn't become a several year project
to sort out.

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Doug Anderson <dianders@chromium.org> - 2016-03-21 23:40 +0100
  Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Enric Balletbo Serra <eballetbo@gmail.com> - 2016-03-24 12:30 +0100
    Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Doug Anderson <dianders@chromium.org> - 2016-03-24 16:20 +0100
    Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-03-24 16:40 +0100
      Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Doug Anderson <dianders@chromium.org> - 2016-03-24 17:10 +0100
        Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-03-24 17:30 +0100
          Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Enric Balletbo Serra <eballetbo@gmail.com> - 2016-03-30 19:20 +0200
            Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-03-30 19:30 +0200
              Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Russell King - ARM Linux <linux@arm.linux.org.uk> - 2016-03-30 22:40 +0200
              Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Shawn Lin <shawn.lin@rock-chips.com> - 2016-03-31 04:00 +0200
            Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Jaehoon Chung <jh80.chung@samsung.com> - 2016-03-31 04:10 +0200
              Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Enric Balletbo Serra <eballetbo@gmail.com> - 2016-03-31 08:40 +0200
          Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors Doug Anderson <dianders@chromium.org> - 2016-03-31 20:20 +0200

csiph-web