On Wed, Dec 15, 2010 at 11:37:30AM +0100, Wolfram Sang wrote: > > > Still, I don't see the point -- the amount of code would be about the > > same between wrapping it with a coat of workarounds and op structures, > > gpio setup, etc, and just doing a separate simple driver. The code shared > > is really just the resource allocation pieces. > > ? Saving 150 out of 260 lines does not count? Having a central point for > bug-fixes in that part of the code? Between duplicating some platform resource allocation code in the separate driver, a driver (or shim layer) that will be needed in either case, I don't consider that a high price to pay. > If there is something yet missing in sdhci-pltfm which you need, it > probably is worth adding it there. Chances are good that other > pltfm-users might want that, too. Taking that to an extreme, any sdhci driver should plug into sdhci-pltfm and just add the hooks needed. It will result in just one more abstraction layer that makes following code flow harder. I know there's times when it makes sense to do so. I just consider this one to be over the line where it makes sense to do a separate driver. Especially if you want some of the quirk code to be moved from sdhci.c to the driver. Thanks, -Olof -- 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
