It seems "git-format-patch -M" fails to detect this patch as a rename(maybe due to too many changed lines?), so I commit two times to get a readable patch and attach them. 1. rename ad1938 to ad193x 2. extend ad1938 codec driver to ad193x supporting ad1936/7/8/9 -barry
On Fri, Mar 19, 2010 at 11:30 AM, Barry Song 21cnbao@gmail.com wrote:
I think this issue has nothing to do with subsystems, anyway, both are acceptable to me. Since there has been an example in ASoC, I will follow it and send v2. thanks -barry
On Fri, Mar 19, 2010 at 2:08 AM, Mike Frysinger vapier.adi@gmail.com wrote:
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