octeon-usb and dwc2 in staging are for the same hw

Greg KH gregkh at linuxfoundation.org
Sat Aug 17 03:02:27 UTC 2013


On Sat, Aug 17, 2013 at 02:18:27AM +0300, Aaro Koskinen wrote:
> 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.

dcw2 already supports different boards/systems, so perhaps there's a way
to tie your board into that?

As a matter of course, I can't merge this driver into the main part of
the tree if it's really the same core as dwc2, as we don't allow that to
happen anymore (we did in the past and it got really messy.)

> (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.)

That would be good to see happen.

> > > 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.

I understand, it wasn't ment personally, just complaining about the code :)

thanks,

greg k-h


More information about the devel mailing list