From: "Bruno Prémont" <bonbons@linux-vserver.org>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Jiri Kosina <jkosina@suse.cz>,
linux-kernel@vger.kernel.org, linux-input@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
rvinyard@cs.nmsu.edu
Subject: Re: [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE
Date: Wed, 7 Apr 2010 22:29:37 +0200 [thread overview]
Message-ID: <20100407222937.73ed530b@neptune.home> (raw)
In-Reply-To: <20100407131204.10759584.randy.dunlap@oracle.com>
On Wed, 07 April 2010 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> On Wed, 7 Apr 2010 20:44:04 +0200 Bruno Prémont wrote:
>
> > On Tue, 06 April 2010 Randy Dunlap <randy.dunlap@oracle.com> wrote:
> > > >
> > > > One of my attempts did end up with a circular loop with regard to FB
> > > > (some of the FB drivers did select INPUT)?
> > >
> > > (not that I can find)
> > >
> > > CONFIG_VT does select INPUT
> > > and CONFIG_DRM_I915 does
> > > select INPUT if ACPI
> >
> > A newer attempt still produces the same result:
> >
> > drivers/input/Kconfig:9:error: found recursive dependency: INPUT ->
> > HID_SUPPORT -> HID_PICOLCD_FB -> FB -> FB_STI -> VT -> INPUT
> >
> > (it's only FB which causes the loop, LEDS, LCD and BACKLIGHT are fine)
>
> (yes, so I see)
>
> > This is with following patch on top of the improved deps patch I sent
> > a few minutes ago deeper in this thread.
> >
> > Is there a way around this?
> >
>
> Well, lesson #1 is that select is evil^W^W should only be used to enable
> library-like code, or as Documentation/kbuild/kconfig-language.txt says:
>
> Note:
> select should be used with care. select will force
> a symbol to a value without visiting the dependencies.
> By abusing select you are able to select a symbol FOO even
> if FOO depends on BAR that is not set.
> In general use select only for non-visible symbols
> (no prompts anywhere) and for symbols with no dependencies.
> That will limit the usefulness but on the other hand avoid
> the illegal configurations all over.
> kconfig should one day warn about such things.
I've read that paragraph and I would definitely prefer not to have to
use select for what this patch should achieve!
It should really be a helper for the user going through menuconfig like
"please check all what is needed to satisfy this item's dependencies"
A "try-select-deep" or whatever it could be called.
A well-behaved "GUI" implementation of this would show what would get newly
checked and give the user the opportunity to not proceed or fine-tune
y/m choices.
> (more below)
>
> >
> > diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
> > index 782a34e..711c091 100644
> > --- a/drivers/hid/Kconfig
> > +++ b/drivers/hid/Kconfig
> > @@ -285,7 +285,7 @@ config HID_PICOLCD_FB
> > bool "Framebuffer support"
> > default !EMBEDDED
> > depends on HID_PICOLCD
> > - depends on HID_PICOLCD=FB || FB=y
> > + select FB
>
> If you'll go back to the unpatched (by this patch) version here,
> it seems to work OK.
So best is probably to just forget about all of this non-leaf select
usage for now. (and not have one half doing one way and the other half
doing it the other way)
Thanks,
Bruno
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2010-04-07 20:29 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <201004052336.o35NaeSE015814@imap1.linux-foundation.org>
2010-04-06 5:04 ` [PATCH mmotm] hid-picolcd: depends on LCD_CLASS_DEVICE Randy Dunlap
2010-04-06 8:40 ` Jiri Kosina
2010-04-06 8:56 ` Bruno Prémont
2010-04-06 15:26 ` Randy Dunlap
2010-04-06 16:35 ` Bruno Prémont
2010-04-06 16:56 ` Randy Dunlap
2010-04-06 21:04 ` Bruno Prémont
2010-04-07 16:20 ` Randy Dunlap
2010-04-07 18:31 ` Bruno Prémont
2010-04-08 12:42 ` Jiri Kosina
2010-04-11 10:17 ` Bruno Prémont
2010-04-11 18:28 ` Jiri Kosina
2010-04-07 18:44 ` Bruno Prémont
2010-04-07 20:12 ` Randy Dunlap
2010-04-07 20:29 ` Bruno Prémont [this message]
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=20100407222937.73ed530b@neptune.home \
--to=bonbons@linux-vserver.org \
--cc=akpm@linux-foundation.org \
--cc=jkosina@suse.cz \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=rvinyard@cs.nmsu.edu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).