Re: [PATCH 01/12] misc: add driver for sequencer serial port

[Cyril Chemparathy <cyril-l0cyMroinI0@public.gmane.org>]

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.

For reference, could you please point me to some other place where
something similar is being done?

Regards
Cyril.