linux-kernel - Re: [PATCH 3/3] omap: add hwspinlock device

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: <AANLkTi=TbMq4TEDoDby+kqtX6M_7_pOpiHuNNbp8r691@mail.gmail.com>
Date:	Thu, 21 Oct 2010 08:11:15 +0200
From:	Ohad Ben-Cohen <ohad@...ery.com>
To:	Kevin Hilman <khilman@...prootsystems.com>
Cc:	Balaji T K <balajitk@...com>, "Kamat, Nishant" <nskamat@...com>,
	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>
Subject: Re: [PATCH 3/3] omap: add hwspinlock device

[removed that bouncing email address we had all along :]

On Thu, Oct 21, 2010 at 1:58 AM, Kevin Hilman
<khilman@...prootsystems.com> wrote:
>>>> Why would we need platform-specific function pointers here ? I'm not
>>>> sure I'm following this one.
>>>
>>> So that board code (built-in) does not call the hwspinlock driver
>>> (potentially a module.)
>>>
>>> The way to solve this is to have platform_data with function pointers,
>>> so that when the driver's ->probe() is done, it can call cany custom
>>> hooks registered by the board code.
>>
>> Sorry, still not following.
>>
>> Do you refer to the i2c driver calling the hwspinlcok_request function
>> at probe time via platform_data function pointers ?
>
> No, earlier in this discussion, in response to my question about users
> of this API early in boot, you said:
>
>> And to allow early board code to reserve specific hwspinlock numbers
>> for predefined use-cases, we probably want to be before arch_initcall.

yes.

> My suggestion to use platform_data + function pointers was to address
> the requesting of hwspinlocks in board/platform-specific code.
>
...
> ... if
> board code ever needs to call the hwspinlock API, then pdata func
> pointers are needed to handle both the case of late driver probe
> or driver built as a module.

How would pdata func pointers help here ?

As you say, pdata func pointers are used in scenarios where
platform-specific code needs to be executed from a driver.

But this is not the case here; here we have driver code ( the
_request_specific() API) that must be called very early in the boot,
before any other driver get the chance to call the dynamic _request()
API.

And to be able to call _request_specific() API that early in the boot,
we must have the hwspinlock driver in place (loaded and already
probe()'ed). So we had to give both the hwspinlock device creation
code and its driver a very early initcall state.

Of course, as we all agree, if we get rid of the _request_specific()
API, hwspinlock will only race with its users (namely i2c_omap), and
in this case arch_initcall() is enough.

> I agree with others that this is a much broader problem, and should not
> hold up the hwspinlock driver, so for now, making hwspinlock have an
> initcall before subsys_initcall is OK with me.  Probably arch_initcall()
> is fine here.
>
> I suggest you add a comment in the code at the initcall point as to why
> it is using arch_initcall(), namely it has to load before i2c because...

Sure.

Thanks,
Ohad.
--
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/