Hi Shawn,
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.
I stand corrected. I assumed the STM platforms did hit mainline meanwhile, but they did not. There really doesn't seem to be one user of sdhci-pltfm without using workarounds. (will make sdhc v3 make it better or worse? I get fears...) So, everything OK with your series.
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.
sdhci-dove needs to overload readw/readl. If there is a user not needings such, i.e. only plain quirks (or even nothing, what a dream!), then a generic driver might be worthwhile. Can wait until we see such a user, though.
Regards,
Wolfram