On Mon, Oct 18, 2010 at 7:56 AM, Cyril Chemparathy <cy...@ti.com> wrote: > Hi Grant, > > Thanks for the feedback, I will send out an updated v2 with the proposed > changes. > > [...] >>> +EXPORT_SYMBOL(ti_ssp_open); >> >> I'm not thrilled with the ti_ssp_open()/ti_ssp_close() usage model. >> It appears that the usage model is the board code registers an pile >> of platform_devices, one for the ssp, and one for each of the >> behaviours on top of it. Then the various driver instances have to >> figure out how to find each other and whether or not they are related. >> Am I correct? >> >> Rather than doing an end-run around the Linux driver model, I strongly >> recommend using the model to solve your problem. Register only the >> ssp platform_device in the board support code and pass it data about >> the intended behaviour (via platform data). When it gets probed, it >> can then register additional platform devices which will get probed by >> the requested driver. That way the specific ssp device instance data >> can be passed reliably to the spi/i2c/whatever driver without any >> ambiguity, without any uncertainty about whether a port is 'busy', and >> without the need of these open/close routines. >> >> (Hint: The trick is to set the platform_device's pdev->dev.parent >> pointer to make use of the Linux device model's hierarchy). > > I am not very thrilled with this approach either :-) I had looked at a > few other instances where something similar was being done (spi, i2c, > mdio, etc.), but felt that defining a new bus type would be an overkill > for this.
Nope! you don't need to define a new bus type. Just continue to use platform bus. If you set the dev->parent pointer before registering the device then the device model with have the appropriate hierarchy. > For reference, could you please point me to some other place where > something similar is being done? Most of the multifunction devices operating in this way (though those implementations are probably more convoluted than they need to be. Take a look. If you still have trouble with it let me know and I'll draft an example for you. g. _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
