Re: cleaning up sdhci? (was Re: [RFC] thoughts about recent Samsung related patches)

[Alan Cox <alan@linux.intel.com>]

> That is, if some implementations of a controller do not adhere to
> that standard and change some bits in the register layout, well, then
> they have to live with the quirks and their performance issues IMHO.

The ATA layer uses I/O accessors although it abstracts them a bit (so
its got 'read status' type abstractions. For performance reasons one or
two places the abstraction is higher level (eg block data transfers)
but with those in place it doesn't seem to be measurable.

> Seeing Alan's patchset, it seems to be a good time to do some
> sdhci-cleanup. My impression is that we could get generalize a few
> quirks by using io-accessors and overriding capabilties-flags. I am

I avoided doing any of it by making I/O access functions fake results
because that seemed to be a recipe for hard to debug future problems.
When dealing with different register layouts or specific bugs it seems
sensible

(and 8250 serial does this succesfully with some devices faking certain
register bits their hardware gets wrong)

> open for other opinions, though. All in all, it would be great if we
> all could combine our efforts and get some kind of master-plan :)
> Will take a look at Alan's patches now...

If there is going to be a grand clean up my preference long term would
be that there is no

	if (host->ops->foo)
		host->ops->foo(...)
	else {
		do foo
	
	}

but that host->ops gets all the NULL entries filled in and the core
code simply calls host->ops->xxx in each case.

Alan