On 10/21/2015 09:02 PM, Frank Rowand wrote:
> On 10/21/2015 9:55 AM, Grygorii Strashko wrote:
>> On 10/21/2015 06:36 PM, Frank Rowand wrote:
>>> On 10/21/2015 1:18 AM, Russell King - ARM Linux wrote:
>>>> On Tue, Oct 20, 2015 at 08:58:19PM -0700, Frank Rowand wrote:
>>>>> On 10/20/2015 8:46 AM, Russell King - ARM Linux wrote:
>>>
>>> < snip >
>>>
>>>>>> +
>>>>>> static bool driver_deferred_probe_enable = false;
>>>>>> +
>>>>>> /**
>>>>>> * driver_deferred_probe_trigger() - Kick off re-probing deferred devices
>>>>>> *
>>>>>> @@ -188,6 +210,13 @@ static int deferred_probe_initcall(void)
>>>>>> driver_deferred_probe_trigger();
>>>>>
>>>>> Couldn't you put the "driver_deferred_probe_report = true" here? And then
>>>>> not add another round of probes.
>>>>
>>>> The idea is not to report anything for drivers that were deferred
>>>> during the normal bootup. The above is part of the normal bootup,
>>>> and the deferred activity should not be warned about.
>>>
>>> The above is currently the last point for probe to succeed or defer
>>> (until possibly, as you mentioned, module loading resolves the defer).
>>> If a probe defers above, it will defer again below. The set of defers
>>> should be exactly the same above and below.
>>>
>>
>> Unfortunately this is not "the last point for probe to succeed or defer".
>> There are still a bunch of drivers in Kernel which will be probed at late_initcall() level.
>> (like ./drivers/net/ethernet/ti/cpsw.c => late_initcall(cpsw_init);
>
> Yes, cpsw_init() should _not_ be a late_initcall. This is yet another
> example of playing games with ordering probes that we have been trying
> to eliminate.
yes, we're trying to solve such issues and have all TI's drivers initialized
from module_init() level, but as usual this process is not so fast.
You know, some times ago there was no other way to solve boot ordering issues,
but only to play with init levels :) And, as result, right now in drivers/
and sound/ folders there are >77 occurrences of late_initcall().
>
> Thanks for pointing out one of the resulting problems this causes for the
> deferred probe mechanism.
>
>> Yes - they probably need to be updated to use module_init(), but that's what
>> we have now). Those drivers will re-trigger deferred device probing if their
>> probe succeeded.
>
> Yes, if cpsw_init() leads to a successful probe, then deferred device probing
> will be re-triggered. I do not know if cpsw_init() will be called before or
> after deferred_probe_initcall(). The general initcall mechanism does not
> provide any ordering guarantees between the two functions because they are
> at the same initcall level.
It will be called after and it will re-triggered deferred device probing.
Now ordering of init calls will be specified by drivers/Makefile
which itself is funny thing.
>
>>
>> As result, it is impossible to say when will it happen the
>> "final round of deferred device probing" :( and final list of drivers which
>> was "deferred forever" will be know only when kernel exits to User space
>> ("deferred forever" - before loading modules).
>>
>> May be, we also can consider adding debug_fs entry which can be used to display
>> actual state of deferred_probe_pending_list?
>>
>>>>
>>>> If we have any devices still deferring after _this_ round, that must
>>>> indicate that some resource they want is not available, and that
>>>> should be warned about.
>>>>
>>>> Of course, modules can defer too - and I made some suggestions in my
>>>> waffle above the patch about that.
>>>>
>>>
>>> < adding back trimmed, for fuller context >
>>>
>>>>>> /* Sort as many dependencies as possible before exiting initcalls */
>>>>>> flush_workqueue(deferred_wq);
>>>>>> +
>>>>>> + /* Now one final round, reporting any devices that remain deferred */
>>>>>> + driver_deferred_probe_report = true;
>>>>>> + driver_deferred_probe_trigger();
>>>>>> + /* Sort as many dependencies as possible before exiting initcalls */
>>>>>> + flush_workqueue(deferred_wq);
>>>>>> +
>>>>>> return 0;
>>>>>> }
>>
>>
>
--
regards,
-grygorii
--
To unsubscribe from this list: send the line "unsubscribe dmaengine" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
