alfred steele wrote: > Hi Jonathan/Michael, >> I'd say this is just the wrong way round: >> Design goal should be to keep application as is and just load another >> driver on H/W change + changing access path in some config file. > I get that. > I am assuming that in order to get the sht15 driver working on my > platform, all i need to do is populate the correct GPIO's in the > platform device structure. Yes and register it with the kernel > Any idea as to how to do that , i mean > where(which file in the source) does the actual platform device > strucutre's pdata get populated. On an embedded board this would typically be in the board config file. For example, see arch/arm/mach-pxa/imote2.c which has an sht15 attached. The exact method of registration may be a bit architecture specific but will look something like the relevant parts of that file. > What would be the optimal method to > tie it to the userspace. Can i add an ioctl to the sht15 driver and > export it for the userspace driver to use. No. Preferred way to access this sort of slow low bandwidth device is via sysfs. It'll create files for reading the various values under /sys/class/hwmon/hwmon?/device/ from memory they are called temp0 and humidity0 Jonathan
