public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ed W <lists@wildgooses.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Andres Salomon <dilinger@queued.net>,
	rpurdie@rpsys.net, linux-geode@lists.infradead.org,
	const@mimas.ru, linux-kernel@vger.kernel.org
Subject: Re: Feedback please: [PATCH] leds: New PCEngines Alix LED driver using gpio interface
Date: Thu, 17 Mar 2011 17:24:55 +0000	[thread overview]
Message-ID: <4D8243E7.7030309@wildgooses.com> (raw)
In-Reply-To: <AANLkTikga=zrNgfsuN4=8tCfZz0n7vkk6i0xW-zj6zSD@mail.gmail.com>

On 17/03/2011 16:08, Grant Likely wrote:
> Actually, it looks like with your changes this isn't even a driver
> anymore.  It is merely code to register a device on a specific
> platform.  Is there any other alix-specific initialization code in the
> kernel?  If so, you should consider relocating the device registration
> with the rest of the alix setup code.

Agreed.  I confess that I don't understand the linux driver structure
enough to shift the code further though

What I observe is that there is a lot of arch specific setup for ARM,
etc, however, this is not currently done at all for x86 (which is Alix),
so at the moment this would seem to sit slightly awkwardly with current
x86 arch code?

Instead I found leds-net5501.c, which is for a very similar platform to
the Alix (not quite similar enough that I could combine the files) and I
used that as my prototype for this driver.

I think given that we already have a similar driver in the leds area
which does platform alike setup, this gives some justification for doing
the same with the Alix leds?  Additionally if we ever find we need Alix
specific setup code then the code is ready to be used as is by the
platform code?


>>> -module_init(alix_led_init);
>>> -module_exit(alix_led_exit);
>>> +arch_initcall(alix_init);
>>
>> Why is this arch_initcall rather than module_init?   If possible, it
>> would be good to have an unload hook as well.
> 
> Yes, unless you've got specific ordering constraints this should
> definitely be module_init().

I'm out of my depth here.  I would be very happy to resubmit either way?

However, is there not a potential ordering issue if leds-alix2 is loaded
*before* leds-gpio? Is this not the reason for making it an arch_initcall?

Also the same code is used in leds-5501.c - would you like me to submit
a patch to change that also (if you confirm it should become a
module_init call?).

Thanks for final confirmation on this and I will quickly resubmit the patch?

Ed W

  reply	other threads:[~2011-03-17 17:24 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4D81D7FD.1040602@wildgooses.com>
2011-03-17 15:43 ` Feedback please: [PATCH] leds: New PCEngines Alix LED driver using gpio interface Andres Salomon
2011-03-17 16:08   ` Grant Likely
2011-03-17 17:24     ` Ed W [this message]
2011-03-17 17:52       ` Andres Salomon
2011-03-17 17:59         ` Ed W
2011-03-17 18:17           ` Grant Likely
2011-03-18 18:12             ` kernel
2011-03-18 18:32               ` Ed W
2011-03-18 22:48                 ` Grant Likely
2011-03-19 16:51                   ` [PATCH] leds: New PCEngines Alix system driver (enables LEDs via gpio interface) kernel
2011-03-19 17:21                     ` Ed W
2011-03-24  3:52                     ` Grant Likely
2011-03-19 17:46                   ` [PATCH] gpio: Show explicit dependency between GPIO_CS5535 and MFD_CS5535 kernel
2011-03-19 19:59                     ` Andres Salomon
2011-03-17 18:22           ` Feedback please: [PATCH] leds: New PCEngines Alix LED driver using gpio interface Andres Salomon
2011-03-17 18:12       ` Grant Likely
2011-03-17 17:04   ` Ed W
2011-03-17 18:07     ` Grant Likely

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=4D8243E7.7030309@wildgooses.com \
    --to=lists@wildgooses.com \
    --cc=const@mimas.ru \
    --cc=dilinger@queued.net \
    --cc=grant.likely@secretlab.ca \
    --cc=linux-geode@lists.infradead.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