[removed that bouncing email address we had all along :] On Thu, Oct 21, 2010 at 1:58 AM, Kevin Hilman <khilman@xxxxxxxxxxxxxxxxxxx> 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-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
