Kernel-space: can .probe be called simultaneously/concurrently?

Question

I have a simple kernel module for embedded ARM-based system associated with it's .compatible . As we know, multiple ".compatibles" can occur in one device tree and .probe will be called for each matched OF node.
I can't find accurate information whether the .probe function can be called simultaneously by kernel (!) or not in case more than one appropriate .compatible appear in device tree. Neither reading kernel drivers sources gives me confidence that it can't (be called simultaneously) despite I haven't seen locks in .probes .

From https://www.kernel.org/doc/Documentation/driver-model/design-patterns.txt , I've read:

While the kernel contains a few device drivers that assume that they will only be probed() once on a certain system (singletons), it is custom to assume that the device the driver binds to will appear in several instances. This means that the probe() function and all callbacks need to be reentrant.

But this looks like related to hot plug or something like this (correct me if I'm wrong) while my question is about processing OF nodes only.
I've found there is .probe_type which can be set to PROBE_PREFER_ASYNCHRONOUS in platform_driver.driver , but not sure if it is about what I need (correct me if I'm wrong).
If .probe can be called synchronously/concurrently I have to implement some locking and finally make this routine re-entrant.
Can someone, please, point me to link/document/chapter where I can read about how .probe mechanism is implemented or give me the exact answer.

Answer 1

The answer for my case was simple:

.probe_type = PROBE_FORCE_SYNCHRONOUS

will make kernel call .probes one by one on each of_node found.

.probe_type = PROBE_PREFER_ASYNCHRONOUS

will make kernel call .probes concurrently.

How did I get to it. I couldn't find that information in documentation or on blogs/forums. So I've made one second delay in my.probe function, added two of_nodes with my.compatible to my DT and tested it in both cases (PROBE_FORCE_SYNCHRONOUS and PROBE_PREFER_ASYNCHRONOUS) by measuring time insmod takes to load module.

Results of these test look clear: PROBE_FORCE_SYNCHRONOUS takes two seconds to load module, while PROBE_PREFER_ASYNCHRONOUS takes one second.

So, the answer is: yes, .probes can be called concurrently, but we have mechanism to control it.

BTW, thank you for your replies