Hi, On Fri, Aug 16, 2013 at 10:39:39AM -0700, Greg KH wrote: > > > As the dwc2 code seems to be the "more mature" codebase, any objection > > > to me deleting the octeon-usb driver? > > > > If it's possible to get it working on Octeon HW, then having a single > > driver is of course the best solution. Is dwc2 fully functional (there > > is no TODO file)? I'll check if I get it working, otherwise I'll be > > disappointed if octeon-usb is deleted and I need to carry an out-of-tree > > driver to use my board. :-) > > I agree, that wouldn't be good, making it so that this works for your > hardware is the best. Looking more into this (and after a failed testing attempt), I don't think we can simply delete octeon-usb if we want to keep supporting Octeon: there's also Octeon-specific registers of which the driver needs to take care of before/while using DWC2 HW block. So migration to DWC2 is not simply a driver change, we would still need some kind of octeon-hcd glue for for it. I guess we should start converting octeon-usb to reuse code from DWC2, but this won't happen overnight. (BTW, there maybe be also bits DWC2 could "steal" from octeon-usb, e.g. documentation - compare e.g. what's being said about GINTSTS or other regs.) > > The driver is only buildable for OCTEON SoC, and the function > > cvmx_usb_get_num_ports() knows each SoC version if they have the USB > > block or not. > > That seems "odd". Why not just use the normal driver probing logic that > the rest of the kernel uses? Yes, this driver is in staging because of multiple "odd" things, and I am/was trying to fix them. Please accept I'm not the original author or designer of this driver. A. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
