[U-Boot] [PATCH 10/13] at91: move usb driver to drivers/usb

[Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>]

On 18:03 Wed 01 Apr     , Michael Trimarchi wrote:
> ksi at koi8.net wrote:
>> On Wed, 1 Apr 2009, Stefan Roese wrote:
>>
>>   
>>> On Tuesday 31 March 2009, Wolfgang Denk wrote:
>>>     
>>>> In message <20090331192117.GF24923@game.jcrosoft.org> you wrote:
>>>>       
>>>>>>>  drivers/usb/Makefile                        >        |    1 +
>>>>>>>  .../at91/usb.c => drivers/usb/atmel_usb.c          |  >   0
>>>>>>>  rename cpu/arm926ejs/at91/usb.c => drivers/usb/atmel_usb.c
>>>>>>>             
>>> (100%)
>>>     
>>>>>> Same here, this is architecture specific code, why move it to
>>>>>>           
>>> generic
>>>     
>>>>>> cod> e?
>>>>>>           
>>>>> it's the at91 usb drivers and we need to have it in the driver/usb
>>>>>         
>>>> Why do we need to have it in the driver/usb ?
>>>>
>>>> Please explain in detail.
>>>>       
>>> >From what I remember we all agreed to move the device drivers (e.g.
>>> ethernet, NAND, USB, serial etc) from the architecture/board (cpu/... 
>>> board/...)
>>> to the drivers directories at some time.
>>>
>>> Speaking for PPC4xx, the 4xx ethernet driver has recently been moved
>>> from cpu/ppc4xx to drivers/net. And I'm planning to move the 4xx NAND 
>>> driver
>>> (and others) soon too.
>>>
>>> So if this atmel_usb.c driver isn't just platform USB init code, but a
>>> real USB driver, then I'm voting to move it to drivers/usb as well.
>>>     
>>
>> I also vote for moving _ALL_ the drivers (i2c, usb, net, etc.) to
>> appropriate directories under drivers/ no matter architecture specific they
>> are or not.
>>
>> This will make the tree more logical and one wouldn't have to chase say USB
>> driver all over the source tree.
>>
>> Also it is a first step to general overhaul that would allow for multiple
>> drivers support. The fact some SoC has a built-in, say USB controller does
>> _NOT_ mean there is no more USB controllers on the same board. Some can be
>> on PCI bus etc. The same is true for each and every other driver. And we
>> should _NOT_ treat some drivers (e.g. SPI) as marginal. AT91RM9200 for
>> example can _NOT_ boot off of parallel flash because of silicon error so it
>> boots off of SPI DataFlash thus making SPI driver essential for the system.
>>
>> To contain drivers is a reason for drivers/* to exist, isn't it?
>>
>> ---
>> ******************************************************************
>> *  KSI at home    KOI8 Net  < >  The impossible we do immediately.  *
>> *  Las Vegas   NV, USA   < >  Miracles require 24-hour notice.   *
>> ******************************************************************
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>   
> Somenthing like that for usb?
>
> :-----core
> : :-----include
> :-----device
> : :-----include
> :-----host
> : :-----include
include is a few overkill

code
host
gadget

I've in mind

Best Regards,
J.