[PATCH v9 07/12] ARM: EXYNOS: introduce soc specific pm ops

[Krzysztof Kozlowski]

On Fri, Apr 7, 2017 at 4:11 PM, pankaj.dubey <pankaj.dubey at samsung.com> wrote:

(...)

>>> +int __init exynos_s2r_init(void)
>>> +{
>>> +       const struct soc_device_attribute *match;
>>> +
>>> +       match = soc_device_match(exynos_soc_revision);
>>> +
>>> +       if (match)
>>> +               s2r_data = (const struct exynos_s2r_data *) match->data;
>>> +
>>> +       if (!s2r_data)
>>> +               return -ENODEV;
>>> +
>>> +       return 0;
>>> +}
>>> +arch_initcall(exynos_s2r_init);
>>> +
>>
>> I guess you already found possible probe-order issue. You should
>> register all of this after having the soc chipid driver. However it is
>> required by cpuidle driver which is being registered in machine_init()
>> call....  You cannot use deferred probe here, so maybe the only way is
>> to manually order the calls in machine_init():
>> 1. exynos_chipid_early_init()
>> 2. this one.
>> 3. cpuidle driver register.
>>
>
> exynos_s2r_init is not required during early stage of boot, so as Arnd
> suggested I can drop arch_initcall here and probably go for
>
> 1: late_init
> 2: Call this directly from machine_init

I think this will be used on first AFTR which might happen few moments
after exynos_dt_machine_init() because it registers the cpuidle
platform devices thus probing them. This is before late_init. You
might call it from machine_init, but again mind the order.

>
> I prefer first option, as I mentioned my long term plan to move these
> files out of arch/arm/mach-exynos/ and if I call it from mach-exynos,
> then while moving I have to make this function as export symbol or make
> it extern so that mach-exynos/exynos.c should be able to access it. Both
> of these approaches have been rejected in past. What do you say?

Because of the cpuidle I think late_initcall is too late.

Best regards,
Krzysztof