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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20160330203903.GJ19428@n2100.arm.linux.org.uk>
Date:	Wed, 30 Mar 2016 21:39:04 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Enric Balletbo Serra <eballetbo@...il.com>
Cc:	Doug Anderson <dianders@...omium.org>,
	Heiko Stübner <heiko@...ech.de>,
	Sonny Rao <sonnyrao@...omium.org>,
	Caesar Wang <wxt@...k-chips.com>,
	Alim Akhtar <alim.akhtar@...il.com>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Alexandru Stan <amstan@...omium.org>,
	Alim Akhtar <alim.akhtar@...sung.com>,
	Javier Martinez Canillas <javier@....samsung.com>,
	Addy Ke <addy.ke@...k-chips.com>,
	Andrew Bresticker <abrestic@...omium.org>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Chris Zhong <zyw@...k-chips.com>
Subject: Re: [PATCH] mmc: dw_mmc: Wait for data transfer after response errors

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@....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.