[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141012143033.GB378@amd>
Date: Sun, 12 Oct 2014 16:30:33 +0200
From: Pavel Machek <pavel@...x.de>
To: dinguyen@...nsource.altera.com
Cc: p.zabel@...gutronix.de, dinh.linux@...il.com,
s.trumtrar@...gutronix.de, grant.likely@...aro.org,
robh+dt@...nel.org, atull@...nsource.altera.com,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] reset: socfpga: use arch_initcall for early
initialization
Hi!
> From: Dinh Nguyen <dinguyen@...nsource.altera.com>
>
> There are certain drivers that are required to get loaded very early using
> arch_initcall. An example of such a driver is the SOCFPGA's FPGA bridge driver.
> This driver has to get loaded early because it needs to enable FPGA components
> that are connected to the bridge.
>
> This FPGA bridge driver will using the reset controller API to toggle it's
> reset bits, thus, it needs the reset driver to be loaded as early as possible
> in order for it to get used properly.
>
> Signed-off-by: Dinh Nguyen <dinguyen@...nsource.altera.com>
> +static int __init socfpga_reset_init(void)
> +{
> + return platform_driver_probe(&socfpga_reset_driver,
> + socfpga_reset_probe);
> +}
> +
> +static void __exit socfpga_reset_exit(void)
> +{
> + platform_driver_unregister(&socfpga_reset_driver);
> +}
> +
> +arch_initcall(socfpga_reset_init);
> +module_exit(socfpga_reset_exit);
That is quite a strange combination. Driver can be module but needs to
be initialized early? Should we make it always built in?
> MODULE_AUTHOR("Steffen Trumtrar <s.trumtrar@...gutronix.de");
> MODULE_DESCRIPTION("Socfpga Reset Controller Driver");
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/
Powered by blists - more mailing lists