On Fri, Feb 11, 2011 at 8:45 AM, Rob Herring <robherring2@xxxxxxxxx> wrote: > Thomas, > > On 02/10/2011 09:29 PM, Thomas Abraham wrote: >> >> Hi, >> >> I am currently adding device tree support for Samsung's S5PV310 >> processor. I have a question about handling platform_data when adding >> device tree support in drivers, specifically about the sdhci-s3c >> driver. >> >> The platform data that is passed to the sdhci-s3c driver is defined in >> file arch/arm/plat-samsung/plat/sdhci.h, struct s3c_sdhci_platdata. In >> this structure, there are some function pointers that are passed to >> the driver. These function pointers are setup by the platform code in >> arch/arm/plat-samsung. But when platform devices are created from the >> device tree, how would such function pointers be passed to the driver? >> >> Any suggestions on the approach to handle the platform_data >> information when moving to device tree would be very helpful. >> > As suggested by Grant, you can use bus notifiers. Here is an example: > > arch/powerpc/platforms/512x/pdm360ng.c > > Pure data (flags, quirks, chip select assignments, etc.) should ultimately > go into the device tree. > > For board specific functions, use the bus notifiers. For SoC functions, put > them in the driver and use the OF match table data pointer. Yes, Rob is right. However, things are simpler if the driver can be designed so that it *doesn't* need platform callbacks. Sometimes it is unavoidable, but in a lot of cases platform callback turn into a way to let platform code twiddle or read GPIOs. In those cases it would be better to turn those callbacks into real gpiolib drivers and design the driver to use the gpio api. > See sdhci-of-core.c for an example. On a side note (and not related to sdhci-s3c); I'd like to be rid of both sdhci-of-core.c and sdhci-pltfm.c. I'm all for providing common infrastructure, but I think those two files go about it in the wrong way. Rather than having a single platform_device (well, 2 in this case, but of and non-of can be merged now) that matches against all 'platform' sdhci controllers, each specific controller should have its own platform_driver structure. The way it is done now creates too much indirection (IMHO) and it would be cleaner if the common code was available to the drivers a library function calls. I've put splitting them up onto my todo list if somebody else doesn't beat me to it. g. -- 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
