Hi Olof, Thanks for the quick reply. I'm still new to this, but from your experience, is there still an acceptable chance of the existing driver to get accepted? We're trying to evaluate the best way to get this integrated, without spending time into working on things that is less valuable. Yes, the code might not get "any worse" by doing refactoring on it, but I might just bite the bullet and rewrite if the code has too slim chances of getting integrated. The main thing is that I seek is both yours and Greg's opinion on how much potential you see in the current patch/code, since you're the go to guy to Linux USB. If there's not much potential in the current code, I will talk to my colleagues and potentially rewrite the code, after some planning I do with my colleagues. Thanks again. -----Original Message----- From: Olof Johansson [mailto:olof@xxxxxxxxx] Sent: Friday, January 20, 2012 12:20 PM To: Tien Hock Loh Cc: linux-usb@xxxxxxxxxxxxxxx; Ley Foon Tan; Kenneth Chong Yin Tan Subject: Re: Designware USB OTG driver upstream questions Hi, On Thu, Jan 19, 2012 at 7:26 PM, Tien Hock Loh <thloh@xxxxxxxxxx> wrote: > Hi, > > I'm currently working on a board that uses the Designware USB OTG IP, and our company wishes to have the driver integrated to the Linux kernel, and will be working on it. > > Referring to this thread: http://thread.gmane.org/gmane.linux.usb.general/53348/focus=53913 > > I understand that Olof and Greg suggested that the code needs a major overhaul, preferably a rewrite. > Is there any potential of the current code being updated and fixed accordingly and gets accepted? > If that's not the case, is the main issue blocking the integration to the kernel the code being bloated and untested? > > I'm trying to understand the problem so that we could get the driver for the IP integrated to the Linux kernel, either by a rewrite or a good amount of refactoring to the existing patch/code. The core of my concern was that the driver was "feature complete", meaning it clearly implemented every single option bit that the IP vendor put in the design, while many, many uses of the actual device won't use or even implement some or many of them. It means the driver is overly complicated, hard to read and just in general bloated. It had been posted for a number of repeats of minor polishes of surface items, but none of them really dealt with the unnecessary complexity of the driver. That's why I finally said it needs a rewrite. Compare that posted driver with the other designware usb driver in the kernel and you'll see what I mean. I'm not saying that it has to be quite as simple, but there is lots of room in between. Greg said he was willing to pick it up in staging. I won't object to that, but staging tends to be a place more for coding style cleanup and refactoring of code, and I think the driver needs a good pruning of functionality in addition to that. So, give it a go, I'd say. It probably can't get _worse_ by being worked on in drivers/staging, and feel free to take ownership of the cleanup and make it work great on your particular hardware, pruning out many of the things that aren't needed. Doing so in staging means there is a shared location for others to work on it instead of out of tree, so it's not a bad choice. When it comes to features -- if you prune too hard and someone needs something added back, that can easily be done later. That's my $0.02. -Olof Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. -- 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
