linux-kernel - Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to postcore

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111214182149.GF32251@atomide.com>
Date:	Wed, 14 Dec 2011 10:21:49 -0800
From:	Tony Lindgren <tony@...mide.com>
To:	Janusz Krzysztofik <jkrzyszt@....icnet.pl>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, Greg Kroah-Hartman <gregkh@...e.de>,
	linux-serial@...r.kernel.org
Subject: Re: [PATCH 01/10] GPIO: gpio-generic: Move initialization up to
 postcore

* Janusz Krzysztofik <jkrzyszt@....icnet.pl> [111214 04:40]:
> On Tuesday 13 of December 2011 at 00:55:44, Tony Lindgren wrote:
> > * Janusz Krzysztofik <jkrzyszt@....icnet.pl> [111212 15:13]:
> > > On Tuesday 13 of December 2011 at 00:15:20, Tony Lindgren wrote:
> > > > 
> > > > Might be worth checking if some board specific __initcall helps here
> > > > too?
> > > 
> > > If I only knew how I could insert a board specific __initcall between 
> > > two points from where the generic-gpio first, then the 8250 driver, are 
> > > called.
> > > 
> > > Any hints?
> > 
> > Hmm, can't you do all that in the order you want in
> > ams_delta_modem_init()?  Or make that into a late_initcall so
> > you have generic-gpio available?
> > 
> > It seems that the pieces of code you're talking about don't need
> > to be initialized early, just needs to be done in the right
> > order to get things working.
> 
> Hi,
> I'm almost done with moving registration of all latch dependent devices 
> down to a late_initcall hook, however while working on this, I've found 
> still another arrangement, yet better in my opinion:
> 1) generic-gpio driver registration moved from device_initcall up to 
>    subsys_initcall,
> 2) latch dependent device registration left at arch_initcall, as it is 
>    now,
> 3) a temporary hack, removed with the last patch in the series, that 
>    requests GPIO pins on behalf of device drivers before those are 
>    updated, placed between subsys_initcall and device_initcall, i.e., at 
>    fs_initcall or rootfs_initcall; both look ugly, but this is only for 
>    a while, in order to keep things working while in the transition,
> 4) the modem init hook, once updated with extra GPIO setup that must be 
>    done on behalf of the 8250 driver, which is not prepared for 
>    accepting any extra init hooks passed with the device platform data, 
>    moved down to late_initcall, as suggested,
> 5) once all drivers are updated, the hack is removed, and an 
>    initialization of unused pins added to that late_initcall modem hook, 
>    perhaps renamed in order to not suggest it is still modem only 
>    related.
> 
> What do you think?

Sounds better for sure than what we currently have :)

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/