[alsa-devel] [Uclinux-dist-devel] [PATCH 1/4] extend ad1938 codec driver to ad193x supporting ad1936/7/8/9

[Mark Brown]

On Thu, Mar 18, 2010 at 01:17:11PM -0400, Mike Frysinger wrote:

> observed, they can be unified across everyone.  subsystems rarely are
> special ... most of the time, people just think they're special and so
> can ignore the common behavior.

I really don't see much of that, to be honest.  Bitrot, lack of time and
poor advertising of new core features seem to be more the issue.

> > 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.