Hi, On Wed, Aug 11, 2010 at 10:10:38PM +0200, ext Ohad Ben-Cohen wrote:
Think of several wl1271 devices, each of which is represented by two devices; an SDIO function, and a platform device. The SDIO function stands for a specific MMC controller the device is hardwired to, and the platform device stands for the external irq line that the device is hardwired to. We must couple the SDIO function with the correct platform device, otherwise it will start getting the wrong interrupts. So after the SDIO function is probed, it registers a platform driver with the unique name that represents the platform device that it is coupled with. When the platform device is probed, it needs to deliver its platform data info to the specific SDIO function that it is bound with. To avoid using some global data structure in that driver, we allocate a unique platform driver per each device, which makes it possible for the platform driver probe to find the SDIO function context by means of container_of. Alternatively, we can also use some global structure in that file, most probably idr, which would also make it possible to reach the SDIO function contexts without going through the driver structure. The idr indexes would then be the MMC controller index, which should match the platform device id. I'll try this out, it might actually look nicer.
you need no globals and you don't need to fiddle with driver structures either.
Just make an sdio driver that platform_device_alloc() and pass in a platform_data, builds struct resources etc for each device found on the sdio bus. Similarly for the SPI-connected wifi chip.
You should never fiddle with internal structures. If you want to look at an example implementation, take a look at drivers/mfd/twl-core.c, there we use an i2c driver to instantiate several platform_devices. Nobody fiddles with driver structures and all the drivers are logically separated into their own source files.
-- balbi DefectiveByDesign.org -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
