From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Christophe PLAGNIOL-VILLARD Date: Wed, 1 Apr 2009 18:31:43 +0200 Subject: [U-Boot] [PATCH 10/13] at91: move usb driver to drivers/usb In-Reply-To: <49D3904C.1090301@gandalf.sssup.it> References: <1238193026-12564-2-git-send-email-plagnioj@jcrosoft.com> <20090331192117.GF24923@game.jcrosoft.org> <20090331203822.60DED83797DC@gemini.denx.de> <200904010855.55698.sr@denx.de> <49D3904C.1090301@gandalf.sssup.it> Message-ID: <20090401163143.GG14366@game.jcrosoft.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.