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

[Michael Trimarchi <trimarchi@gandalf.sssup.it>]

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

Michael



-------------- next part --------------
A non-text attachment was scrubbed...
Name: makefile.patch
Type: text/x-patch
Size: 2040 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090401/afea2e02/attachment.bin