All of lore.kernel.org
 help / color / mirror / Atom feed
From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] atmel_lcdfb Kconfig: remove long dependency line
Date: Tue, 03 Nov 2009 15:42:16 +0100	[thread overview]
Message-ID: <4AF04148.8070103@atmel.com> (raw)
In-Reply-To: <20090625084631.GA7985@n2100.arm.linux.org.uk>

I come back on this patch as I have a Kconfig cleanup patch series coming.

Russell King - ARM Linux :
> On Tue, Jun 23, 2009 at 04:12:54PM +0200, Nicolas Ferre wrote:
>> Haavard Skinnemoen :
>>> Nicolas Ferre wrote:
>>>> +config ARCH_ATMEL_HAS_FB
>>>> +	bool
>>>> +	depends on FB
>>>> +	default n
>>> What happens when we unconditionally select something which depends on
>>> something else?
>> :-P
>>
>> Experience shows that this configuration is selected.
>>
>> The dependency allows to have a good hierarchy in the configuration tree...
>> Better proposition welcome.
> 
> 1st - no need for 'default n' - you're specifying something that's already
> the default.

Ok.

> 2nd - don't make this symbol depend on anything, and don't use the symbol
> for anything except providing a dependency for FB_ATMEL.  Instead, let
> FB_ATMEL deal with the dependency on FB and ARCH_ATMEL_HAS_FB.

The problem is that if I do not setup the dependency here the menu entry
will not be available at the proper level. In fact I will see the Atmel
LCD entry here:
"Graphics support"
 <*> Support for frame buffer devices  --->
 <*> AT91/AT32 LCD Controller support

instead of here:
"Graphics support"
 ---> "Support for frame buffer devices"
      [..]
      <*> "AT91/AT32 LCD Controller support"
      [..]

So I keep the depend.

> 3rd - ISTR we have a convention for these - 'HAVE_foo' for a configuration
> option named 'foo'.  So it should probably be HAVE_FB_ATMEL.

Ok, changed to HAVE_FB_ATMEL indeed.

Thanks. Best regards,
-- 
Nicolas Ferre

WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Haavard Skinnemoen <haavard.skinnemoen@atmel.com>,
	plagnioj@jcrosoft.com, linux-arm-kernel@lists.arm.linux.org.uk,
	linux-kernel@vger.kernel.org, avictor.za@gmail.com
Subject: Re: [RFC PATCH] atmel_lcdfb Kconfig: remove long dependency line
Date: Tue, 03 Nov 2009 15:42:16 +0100	[thread overview]
Message-ID: <4AF04148.8070103@atmel.com> (raw)
In-Reply-To: <20090625084631.GA7985@n2100.arm.linux.org.uk>

I come back on this patch as I have a Kconfig cleanup patch series coming.

Russell King - ARM Linux :
> On Tue, Jun 23, 2009 at 04:12:54PM +0200, Nicolas Ferre wrote:
>> Haavard Skinnemoen :
>>> Nicolas Ferre wrote:
>>>> +config ARCH_ATMEL_HAS_FB
>>>> +	bool
>>>> +	depends on FB
>>>> +	default n
>>> What happens when we unconditionally select something which depends on
>>> something else?
>> :-P
>>
>> Experience shows that this configuration is selected.
>>
>> The dependency allows to have a good hierarchy in the configuration tree...
>> Better proposition welcome.
> 
> 1st - no need for 'default n' - you're specifying something that's already
> the default.

Ok.

> 2nd - don't make this symbol depend on anything, and don't use the symbol
> for anything except providing a dependency for FB_ATMEL.  Instead, let
> FB_ATMEL deal with the dependency on FB and ARCH_ATMEL_HAS_FB.

The problem is that if I do not setup the dependency here the menu entry
will not be available at the proper level. In fact I will see the Atmel
LCD entry here:
"Graphics support"
 <*> Support for frame buffer devices  --->
 <*> AT91/AT32 LCD Controller support

instead of here:
"Graphics support"
 ---> "Support for frame buffer devices"
      [..]
      <*> "AT91/AT32 LCD Controller support"
      [..]

So I keep the depend.

> 3rd - ISTR we have a convention for these - 'HAVE_foo' for a configuration
> option named 'foo'.  So it should probably be HAVE_FB_ATMEL.

Ok, changed to HAVE_FB_ATMEL indeed.

Thanks. Best regards,
-- 
Nicolas Ferre


  reply	other threads:[~2009-11-03 14:42 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-18 16:16 [PATCH 0/5] at91: Introduction of at91sam9g10 SOC Nicolas Ferre
2009-06-18 16:16 ` [PATCH 1/5] at91: Basic support for at91sam9g10: header files Nicolas Ferre
2009-06-18 16:16 ` [PATCH 2/5] at91: Support for at91sam9g10: clocks management Nicolas Ferre
2009-06-18 16:16 ` [PATCH 3/5] at91: Support for at91sam9g10: core chip & board support Nicolas Ferre
2009-06-18 22:28   ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-18 16:16 ` [PATCH 4/5] at91/USB: USB drivers modifications for at91sam9g10 Nicolas Ferre
2009-09-16 11:59   ` Nicolas Ferre
2009-09-16 11:59     ` Nicolas Ferre
2009-09-25 10:24     ` Nicolas Ferre
2009-09-25 10:24       ` Nicolas Ferre
2009-09-25 17:51       ` David Brownell
2009-09-25 17:51         ` David Brownell
2009-09-29  7:59         ` Nicolas Ferre
2009-09-29  7:59           ` Nicolas Ferre
2009-09-29 17:40           ` Greg KH
2009-09-29 17:40             ` Greg KH
2009-10-20 13:01             ` Nicolas Ferre
2009-10-20 13:01               ` Nicolas Ferre
2009-06-18 16:16 ` [PATCH 5/5] at91/atmel_lcdfb: add at91sam9g10 support to atmel LCD driver Nicolas Ferre
2009-06-18 22:24   ` Jean-Christophe PLAGNIOL-VILLARD
2009-06-23 13:20     ` Nicolas Ferre
2009-06-23 14:30       ` [RFC PATCH] atmel_lcdfb Kconfig: remove long dependency line Nicolas Ferre
2009-06-23 13:35         ` Haavard Skinnemoen
2009-06-23 14:12           ` Nicolas Ferre
2009-06-25  8:46             ` Russell King - ARM Linux
2009-11-03 14:42               ` Nicolas Ferre [this message]
2009-11-03 14:42                 ` Nicolas Ferre
2009-11-03 21:05                 ` Russell King - ARM Linux
2009-11-13 15:27                   ` Nicolas Ferre
2009-06-23 14:13         ` Jean-Christophe PLAGNIOL-VILLARD
2009-07-06 10:32   ` [PATCH 5/5] at91/atmel_lcdfb: add at91sam9g10 support to atmel LCD driver Nicolas Ferre
2009-07-20 22:24     ` Andrew Morton
2009-07-20 22:24       ` Andrew Morton
2009-07-21  9:31       ` Nicolas Ferre
2009-06-25 22:00 ` [PATCH 0/5] at91: Introduction of at91sam9g10 SOC Andrew Victor

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=4AF04148.8070103@atmel.com \
    --to=nicolas.ferre@atmel.com \
    --cc=linux-arm-kernel@lists.infradead.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.