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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxx>:
On Thu, 29 May 2014, Alex Smith wrote:

From: David Daney <david.daney@xxxxxxxxxx>

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





[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux