On Tue, May 22, 2012 at 01:41:30PM +0300, Alexander Shishkin wrote: > Felipe Balbi <balbi@xxxxxx> writes: > > > On Tue, May 22, 2012 at 06:31:40PM +0800, Richard Zhao wrote: > >> On Tue, May 22, 2012 at 01:06:26PM +0300, Felipe Balbi wrote: > >> > Hi, > >> > > >> > On Tue, May 22, 2012 at 12:56:52PM +0300, Alexander Shishkin wrote: > >> > > > Do you think it's a good idea to let user select binding driver directly > >> > > > and the binding driver config depends on chipidea config? > >> > > > >> > > I don't have a strong opinion on this, although I prefer it the way it > >> > > is now, because, imo: > >> > > > >> > > * in case of =m (and that's the only sane way of compiling it anyway), > >> > > these all are compiled as modules, which you simply don't install if > >> > > you don't want them; > >> > > * all of them get compile-tested every time you change something in > >> > > the driver, which is a good thing; > >> > > >> > only true for $(ARCH) builds. I would like to see these drivers being > >> > compile tested on linux-next on all arches. Thus the patches I just > >> > sent. > >> The idea is great. But > >> - how can I make sure it pass for all arch? There' 27 folder in arch/. > >> - it's hard to predict one driver depends on what. > >> - for embedded kernel, people like built-in drivers, and people will > >> have things they don't need at all. > > > > that's true to some extent, but until we know for sure that all of that > > is compiling fine and all dependencies are properly handled, I wouldn't > > like to see Kconfig or Makefile being abused. That has happened before > > and will happen again if we allow it. > > > > My suggestion to Alex is to remove all dependencies for at least a > > couple of merge windows and only add dependencies for stuff which > > actually matters; like only building the PCI glue layer when CONFIG_PCI > > is defined instead of when ARCH_X86 is defined and so on. > > That's what I mean to do as well. I wouldn't dream of making something > like this x86 specific. :) Alex, Have you made the decision that remove all dependencies and leave only ones that has to be there? If yes, I'll try the way, though I don't feel good about that. Thanks Richard > > > When it gets to a product, that can be easily optimized and when we have > > decided what's the best way to place the choices, we will do so. Until > > then, we like to use linux-next for compile testing everything. > > Seconded. > > Regards, > -- > Alex > -- > To unsubscribe from this list: send the line "unsubscribe linux-usb" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
