On 18:03 Wed 01 Apr , Michael Trimarchi wrote: > k...@koi8.net wrote: >> On Wed, 1 Apr 2009, Stefan Roese wrote: >> >> >>> On Tuesday 31 March 2009, Wolfgang Denk wrote: >>> >>>> In message <20090331192117.gf24...@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? >> >> --- >> ****************************************************************** >> * k...@home KOI8 Net < > The impossible we do immediately. * >> * Las Vegas NV, USA < > Miracles require 24-hour notice. * >> ****************************************************************** >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> U-Boot mailing list >> U-Boot@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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
