Re: [PATCH 3/3] usb host/MIPS: Remove hard-coded OCTEON platform information.

[David Daney <ddaney@caviumnetworks.com>]

On 05/29/2014 10:37 AM, Greg KH wrote:
> On Thu, May 29, 2014 at 09:55:08AM -0700, Florian Fainelli wrote:
>> 2014-05-29 8:03 GMT-07:00 Alan Stern <stern@rowland.harvard.edu>:
>>> On Thu, 29 May 2014, Alex Smith wrote:
>>>
>>>> From: David Daney <david.daney@cavium.com>
>>>>
>>>> The device tree will *always* have correct ehci/ohci clock
>>>> configuration, so use it.  This allows us to remove a big chunk of
>>>> platform configuration code from octeon-platform.c.
>>>
>>> Instead of doing this, how about moving the octeon2_usb_clocks_start()
>>> and _stop() routines into octeon-platform.c, and then using the
>>> ehci-platform and ohci-platform drivers instead of special-purpose
>>> ehci-octeon and ohci-octeon drivers?
>>
>> How about they get their changes in now, and eventually they cleanup
>> the octeon driver in the future?
>
> Nope, sorry, we don't do that for kernel development, you know that.
>
>> My personal experience with that sort of request, is that I had to
>> come up with 50+ patches to clean up the Kconfig mess that USB drivers
>> had back then and I still have not re-submitted the bcm63xx USB
>> patchset.
>
> Well, that's not our fault you haven't resent them :)
>
>> It is fair to pinpoint what *should* be improved and what the next
>> steps could look like, it is not fair to ask people submitting changes
>> to come up with a much bigger task before their patches can be merged.
>
> Of course it is, that's how we do Linux development, again, you know
> this.
>

Several points of clarification:

1) I wrote the patch in question, not Florian.

2) I agree that OCTEON ehci/ohci support could probably be refactored 
along the lines of Alan's suggestion.

3) This patch is a relatively minor change to an *existing* driver 
rather than a completely new thing that hasn't yet been merged.

4) There is a lot of precedent for merging minor enhancements and bug 
fixes instead of requiring a complete refactoring of *existing* code.

All that said, I haven't dug into the ehci-platform and ohci-platform 
enough to be able to opine on the best course of action in this 
particular case.  I hope to be able to make a more educated follow-up 
next week.

David Daney