[PATCH v2 05/12] usb: chipidea: add imx driver binding

[Alexander Shishkin]

Felipe Balbi <balbi at ti.com> 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. :)

> 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