From: Grant Likely <grant.likely@secretlab.ca>
To: Ed W <lists@wildgooses.com>
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 12:12:03 -0600 [thread overview]
Message-ID: <20110317181203.GL9597@angua.secretlab.ca> (raw)
In-Reply-To: <4D8243E7.7030309@wildgooses.com>
On Thu, Mar 17, 2011 at 05:24:55PM +0000, Ed W wrote:
> 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?
No, that's bad practise. You should have one Alix setup file,
probably in arch/x86/platform, that takes care of all Alix specific
setup registrations. Right now that only consists of gpio leds, but
it could potentially grow. Note that this is only for on-time setup
and registrations. Actual device drivers still belong under drivers/
> 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?
Nope. It does not matter if the driver gets registered first or the
device.
> 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?).
Unless you've got the hardware to test, probably not.
> Thanks for final confirmation on this and I will quickly resubmit the patch?
Thanks
g.
next prev parent reply other threads:[~2011-03-17 18:12 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 ` Andres Salomon
2011-03-17 16:08 ` Grant Likely
2011-03-17 17:24 ` Ed W
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 [this message]
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=20110317181203.GL9597@angua.secretlab.ca \
--to=grant.likely@secretlab.ca \
--cc=const@mimas.ru \
--cc=dilinger@queued.net \
--cc=linux-geode@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lists@wildgooses.com \
--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
all inboxes | Powered by JetHome®