On Tue, Aug 18, 2009 at 07:26:42PM +0300, Felipe Balbi wrote: > On Tue, Aug 18, 2009 at 12:34:31PM +0200, ext Daniel Mack wrote: > > On Tue, Aug 18, 2009 at 12:57:40PM +0300, Felipe Balbi wrote: > > > On Tue, Aug 18, 2009 at 11:03:38AM +0200, ext Gadiyar, Anand wrote: > > > > Different link controllers have different methods for accessing the > > > > transceiver's registers. This series is only adding function pointers > > > > that can be populated later depending on the controller used. I think > > > > it is useful to have. > > > > > > yes, and that could be done via platform_data on nop-xceiv for example. > > > > I don't get the idea what nop-xceiv is supposed to do in the game, > > sorry. What's needed for embedded boards is a thin glue layer that links > > platform/soc specific ULPI access functions to the generic ULPI > > transceiver (which was formerly a specific 1504 driver, but that will > > change now). > > > > So what I will add is a function like > > > > struct otg_transceiver *otg_ulpi_xceiv_create(struct otg_io_access_ops *ops); > > > > and call it from the platform code. Which is quite straigt forward, > > right? How would that look like with the nop-xceiv code, can you > > elaborate? > > I was pointing out that the 1504 driver was unnecessary, in a sense. > Having ulpi_read() and ulpi_write() abstractions is pretty ok and should > be done for sure. Any feelings about the new version of this patch set I've sent around some days ago? http://article.gmane.org/gmane.linux.ports.arm.kernel/65048 Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
