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. -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
