linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philip Prindeville <philipp@redfish-solutions.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Alessandro Zummo <a.zummo@towertech.it>,
	Richard Purdie <rpurdie@rpsys.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/1] net5501: platform driver for Soekris Engineering net5501 single-board computer
Date: Tue, 31 Jan 2012 18:38:26 -0700	[thread overview]
Message-ID: <4F289792.3000503@redfish-solutions.com> (raw)
In-Reply-To: <20120131141908.2c4c8b13.akpm@linux-foundation.org>

On 1/31/12 3:19 PM, Andrew Morton wrote:
> On Fri, 27 Jan 2012 22:02:19 -0700
> Philip Prindeville <philipp@redfish-solutions.com> wrote:
> 
>> ---
>> Trivial platform driver for Soekris Engineering net5501 single-board
>> computer. Probes well-known locations in ROM for BIOS signature to
>> confirm correct platform. Registers 1 LED and 1 GPIO-based button
>> (typically used for soft reset).
>>
>> ...
>>
>>  arch/x86/Kconfig                  |    6 ++
>>  arch/x86/platform/geode/Makefile  |    1 +
>>  arch/x86/platform/geode/net5501.c |  154 +++++++++++++++++++++++++++++++++++++
>>  drivers/leds/leds-net5501.c       |   97 -----------------------
> 
> Forgot to clean up the leftovers:
> 
> make[2]: *** No rule to make target `drivers/leds/leds-net5501.c', needed by `drivers/leds/leds-net5501.o'.  Stop.
> 
> Also, are you sure that the new Kconfig entry is sufficient?  The old
> driver had more dependencies (GPIO_CS5535 and LEDS_TRIGGERS) and
> selects LEDS_TRIGGER_DEFAULT_ON.  Should the new driver be doing such
> things?

Thanks for getting that.  Overlooked it.

The thing about the way the platform driver is now is it can wait until the subordinate modules get loaded and it will register the relevant devices then...

It's conceivable that one might want LEDs but not the reset button, or vice versa.

It might make sense to have the GPIO_CS5535 driver be selected, but also I'm good with the platform driver being statically linked in, and the LED or GPIO drivers being insmod'd.

I figure best to KISS and allow people to have as small a static kernel as they want, and then build up functionality with modules.

-Philip

> 
> 
> --- a/drivers/leds/Kconfig~net5501-platform-driver-for-soekris-engineering-net5501-single-board-computer-fix
> +++ a/drivers/leds/Kconfig
> @@ -89,16 +89,6 @@ config LEDS_NET48XX
>  	  This option enables support for the Soekris net4801 and net4826 error
>  	  LED.
>  
> -config LEDS_NET5501
> -	tristate "LED Support for Soekris net5501 series Error LED"
> -	depends on LEDS_TRIGGERS
> -	depends on X86 && GPIO_CS5535
> -	select LEDS_TRIGGER_DEFAULT_ON
> -	default n
> -	help
> -	  Add support for the Soekris net5501 board (detection, error led
> -	  and GPIO).
> -
>  config LEDS_FSG
>  	tristate "LED Support for the Freecom FSG-3"
>  	depends on LEDS_CLASS
> --- a/drivers/leds/Makefile~net5501-platform-driver-for-soekris-engineering-net5501-single-board-computer-fix
> +++ a/drivers/leds/Makefile
> @@ -14,7 +14,6 @@ obj-$(CONFIG_LEDS_MIKROTIK_RB532)	+= led
>  obj-$(CONFIG_LEDS_S3C24XX)		+= leds-s3c24xx.o
>  obj-$(CONFIG_LEDS_AMS_DELTA)		+= leds-ams-delta.o
>  obj-$(CONFIG_LEDS_NET48XX)		+= leds-net48xx.o
> -obj-$(CONFIG_LEDS_NET5501)		+= leds-net5501.o
>  obj-$(CONFIG_LEDS_WRAP)			+= leds-wrap.o
>  obj-$(CONFIG_LEDS_COBALT_QUBE)		+= leds-cobalt-qube.o
>  obj-$(CONFIG_LEDS_COBALT_RAQ)		+= leds-cobalt-raq.o
> _
> 
> 
> 


      reply	other threads:[~2012-02-01  1:39 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-31  9:28 [PATCH 1/1] net5501: platform driver for Soekris Engineering net5501 single-board computer Philip Prindeville
2012-01-27 22:59 ` Andrew Morton
2012-01-28  5:02 ` [PATCH v2 " Philip Prindeville
2012-01-31 22:19   ` Andrew Morton
2012-02-01  1:38     ` Philip Prindeville [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=4F289792.3000503@redfish-solutions.com \
    --to=philipp@redfish-solutions.com \
    --cc=a.zummo@towertech.it \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rpurdie@rpsys.net \
    /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).