Hi, 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. -- balbi -- 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
