From: David Brownell <david-b@pacbell.net>
To: "Lopez Cruz, Misael" <x0052729@ti.com>
Cc: "mesak82@gmail.com" <mesak82@gmail.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"Pandita, Vikram" <vikram.pandita@ti.com>
Subject: Re: [PATCH] ALSA: SoC: Add support for TI SDP3430
Date: Thu, 20 Nov 2008 23:23:01 -0800 [thread overview]
Message-ID: <200811202323.01493.david-b@pacbell.net> (raw)
In-Reply-To: <2C7D3DF36ADFFC479B44490D912B616705A445CBB1@dlee07.ent.ti.com>
On Thursday 20 November 2008, Lopez Cruz, Misael wrote:
> > On Thursday 20 November 2008, mesak82@gmail.com wrote:
> > > + tristate "SoC Audio support for Texas Instruments SDP3430"
> > > + depends on SND_OMAP_SOC && MACH_OMAP_3430SDP
> > > + select SND_OMAP_SOC_MCBSP
> > > + select SND_SOC_TWL4030
> >
> > depends also on TWL4030_CORE, yes?
> The machine driver itself doesn't depend on TWL4030_CORE, but
> TWL4030 SoC codec driver does (sound/soc/codecs/Kconfig)
>
> config SND_SOC_TWL4030
> tristate
> depends on TWL4030_CORE
>
> Although that dependency is overridden by _select_ statement.
No it isn't. Reverse dependencies don't work like you might
expect ... even when there's no ambiguity in walking up a
chain of them, *no* additional dependencies are flagged.
So as you've written it, SND_SOC_TWL4030 will be active,
but not TWL4030_CORE on which it depends.
If you fix that in Kconfig, you'd make a lot of folk
fairly happy ... but there'd be fun ambiguities to cope
with. Example:
config X
select D
config D
depends on (A && B) || C
It's not clear whether to enable both A and B; just C;
or all of them...
Probably asking the user to resolve such issues would be
necessary. Coming up with all the solutions would be a bit
more complex than a Prolog interpreter, since Kconfig uses
tristate logic not boolean.
> What should be the best way to handle this dependency? Directly
> in kconfig entry for each TWL4030-related machine driver?
The least error-prone answer involves no "select" statements
at all, ever. That is, least error-prone in terms of the
output of Kconfig being a valid configuration ... in terms
of minimizing user error, I suggest just adding the single
dependency I mentioned.
- Dave
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-11-21 7:23 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-21 4:30 [PATCH] ALSA: SoC: Add support for TI SDP3430 mesak82
2008-11-21 5:29 ` David Brownell
2008-11-21 6:18 ` Lopez Cruz, Misael
2008-11-21 7:23 ` David Brownell [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-11-24 19:18 mesak82
2008-11-24 19:25 ` Misael Lopez
2008-11-24 20:07 ` David Brownell
2008-11-25 3:44 ` Misael Lopez
2008-11-25 3:49 Misael Lopez Cruz
2008-11-25 4:21 Misael Lopez Cruz
2008-11-25 15:15 ` Mark Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200811202323.01493.david-b@pacbell.net \
--to=david-b@pacbell.net \
--cc=linux-omap@vger.kernel.org \
--cc=mesak82@gmail.com \
--cc=vikram.pandita@ti.com \
--cc=x0052729@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.