All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: David Rientjes <rientjes@google.com>
Cc: Mauro Carvalho Chehab <mchehab@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-media@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [GIT PULL for 3.6-rc1] media updates part 2
Date: Fri, 10 Aug 2012 09:13:41 +0200	[thread overview]
Message-ID: <5024B4A5.9090309@redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.00.1208091302220.12942@chino.kir.corp.google.com>

Hi,

On 08/09/2012 10:03 PM, David Rientjes wrote:
> On Thu, 9 Aug 2012, Mauro Carvalho Chehab wrote:
>
>> Yeah, that would work as well, although the code would look uglier.
>> IMHO, using select/depend is better.
>>
>
> Agreed, I think it should be "depends on LEDS_CLASS" rather than select
> it if there is a hard dependency that cannot be fixed with extracting the
> led support in the driver to #ifdef CONFIG_LEDS_CLASS code.

The led support could be #ifdef CONFIG_LEDS_CLASS, the problem with that
approach is the whole module versus build-in thing:

led-class	shark		enable-led-support
build-in	build-in	yes
build-in	module		yes
module		build-in	no
module		module		yes

Now this can be coded into #ifdef magic, but it won't be pretty,
of course we only need the non pretty version once at the top
to set a SHARK_USE_LEDS define, but still.

I'm fine with either solution (depends or ifdef magic), although
I think that people will get unpleasantly surprised if they want
to use the shark driver and they don't get to see it in the
menu because they don't have leds enabled.

Regards,

Hans

      reply	other threads:[~2012-08-10  7:12 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-31 15:15 [GIT PULL for 3.6-rc1] media updates part 2 Mauro Carvalho Chehab
2012-07-31 23:00 ` Mauro Carvalho Chehab
2012-08-08 22:28 ` David Rientjes
2012-08-09 11:38   ` Mauro Carvalho Chehab
2012-08-09 12:00     ` Hans de Goede
2012-08-09 12:38       ` Mauro Carvalho Chehab
2012-08-09 20:03         ` David Rientjes
2012-08-10  7:13           ` Hans de Goede [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=5024B4A5.9090309@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=rientjes@google.com \
    --cc=torvalds@linux-foundation.org \
    /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.