On Thu, Mar 18, 2010 at 14:05, Mark Brown wrote: > On Thu, Mar 18, 2010 at 01:17:11PM -0400, Mike Frysinger wrote: >> > The subsystem dependency here come from the fact that ASoC has machine >> > drivers and relies on them selecting the CODEC drivers to get them built >> > in the first place so if you're trying to change something like this >> > you'll most likely not only have to rebuild your kernel but also have to >> > write code. This isn't something that the input layer has (input layer >> > drivers are pretty much standalone, usually only need platform data >> > for any per machine hookup and for I2C and SPI can even be registered >> > from user space IIRC) and it changes the considerations noticably. > >> the machine driver selects the codec, it doesnt select the bus. the >> codec worries about that. so i dont quite follow the logic here. > > That's not the case, CODEC drivers do absolutely nothing to ensure that > they have the buses they need. Multi bus CODECs should all be perfectly > happy to build with no bus at all, though sparse and/or GCC will warn. > > Kconfig will cheerfully ignore any dependencies of things that are > selected - unless it's been updated recently all a select does is force > the selected symbol on, it doesn't recurse through dependencies and > selects of that symbol. Besides, multi bus CODEC drivers can't know > which of their possible buses are actually needed on a given system - > they just build support for any bus types that are configured and let > something else worry about the resulting configuration actually being > useful. sure, on the Kconfig side, i can see that. i was thinking the pure C drivers though. thanks for the clarification. -mike _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
