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

Jean-Christophe PLAGNIOL-VILLARD
2009-04-01T16:31:43Z

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.