[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87bp6pviwf.fsf@deeprootsystems.com>
Date: Tue, 19 Oct 2010 16:53:52 -0700
From: Kevin Hilman <khilman@...prootsystems.com>
To: Ohad Ben-Cohen <ohad@...ery.com>
Cc: linux-omap@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, akpm@...ux-foundation.org,
Greg KH <greg@...ah.com>, Tony Lindgren <tony@...mide.com>,
Benoit Cousson <b-cousson@...com>,
Grant Likely <grant.likely@...retlab.ca>,
Hari Kanigeri <h-kanigeri2@...com>, Suman Anna <s-anna@...com>,
Simon Que <sque@...com>
Subject: Re: [PATCH 3/3] omap: add hwspinlock device
Ohad Ben-Cohen <ohad@...ery.com> writes:
> On Tue, Oct 19, 2010 at 7:03 PM, Kevin Hilman
> <khilman@...prootsystems.com> wrote:
>>> +postcore_initcall(hwspinlocks_init);
>>
>> Any reason this needs to be a postcore_initcall? Are there users of
>> hwspinlocks this early in boot?
>
> i2c-omap, which is subsys_initcall (the I2C bus is shared between the
> A9 and the M3 on some OMAP4 boards).
Rather than moving towards having more drivers have to be built in (and
depend on their probe order) we need to be moving towards building all
these drivers as modules, including omap-i2c.
> And to allow early board code to reserve specific hwspinlock numbers
> for predefined use-cases, we probably want to be before arch_initcall.
There's no reason for board code to have to do this at initcall time.
This kind of thing needs to be done by platform_data function pointers,
as is done for every other driver that needs platform-specific driver
customization.
Kevin
--
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