Hi Wolfram,
Thanks for the review.
On Tue, Apr 19, 2011 at 12:20:31PM +0200, Wolfram Sang wrote: [...]
The approach seems sensible, so have a look at my (mostly minor) comments inside the patches. However, there is one bigger piece missing. You converted all the drivers which had a seperate source-file and hooked into sdhci-pltfm.c. However, those are only those users which need additional code to work around the quirks. There are also users which can take the plain pltfm-driver with a properly set platform_data (check the thread "[PATCH] mmc: add SDHCI driver for STM platforms (V2)" for an example). Those have to be converted, too.
Even those drivers need pltfm-<something>.c to accommodate the platform_data, right? I think sdhci-dove.c (sitting on mainline) is also such an example. So if I'm not mistaken, I did take care of the drivers which can take the current plain pltfm-sdhci driver.
Now the discussion could be if every of those users gets its own pltfm-<something>.c or if we create something similat to sdhci-pltfm-generic, which can also be setup with platform_data like the old driver (/me likes the latter a bit more. If we don't change the name of the driver (not talking about the sourcefile) and keep it "sdhci-pltfm", then you wouldn't need to change all those users if you ensured it behaves the same.
Since there are already pltfm-<something>.c to hold platform_data for those users anyway, it's not an argument here.
Also, I think the next version of this series should have all makers of a sdhci-pltfm user CCed so we give them a chance to report breakage. Or donate acks or tested-by.
Ok, will do.