On Fri, Aug 12, 2011 at 6:33 PM, Greg KH <email@example.com> wrote:
> On Fri, Aug 12, 2011 at 06:20:48PM +0200, Manuel Lauss wrote:
>> On Fri, Aug 12, 2011 at 6:04 PM, Greg KH <firstname.lastname@example.org> wrote:
>> > On Fri, Aug 12, 2011 at 11:39:38AM +0200, Manuel Lauss wrote:
>> >> Alchemy chips have one or more registers which control access
>> >> to the usb blocks as well as PHY configuration. I don't want
>> >> the OHCI/EHCI glues to know about the different registers and bits;
>> >> new arch code hides the gory details of USB configuration from them.
>> >> Cc: email@example.com
>> >> Cc: Greg Kroah-Hartman <firstname.lastname@example.org> (USB glue parts)
>> >> Signed-off-by: Manuel Lauss <email@example.com>
>> >> ---
>> >> CC'ed Greg for an Ack on the USB glue parts. I'd like this to go through
>> >> the
>> >> MIPS tree since other changes in it depend on it.
>> > Fine with me on the USB portions, you are just deleting code, which I
>> > like :)
>> > But should the "common" USB code really live under arch/mips/alchemy/ ?
>> > The goal is to move driver code out of arch/ and into drivers/. Why are
>> > you moving stuff backwards here?
>> This is just chip-dependent code for usb block and phy management, which
>> varies wich chip subtype, the OHCI and EHCI controllers are identical on all
>> of them. At the time moving the chip-depedent code to the other
>> code seemed like a good idea...
> But that's what drivers/* is, chip-dependent code. Please move it there
> Has the MIPS developers learned nothing from the recent ARM mess? :)
Personally I disagree with some of the results of the "ARM mess", but if that's
what it takes to get things moving forware, so be it.
Give me a few minutes to figure out what to do...