Am 29.04.2015 um 08:58 schrieb Tomeu Vizoso:
On 28 April 2015 at 20:17, Alexander Holler <hol...@ahsoftware.de> wrote:
Am 28.04.2015 um 14:49 schrieb Tomeu Vizoso:
On 25 April 2015 at 01:15, Alexander Holler <hol...@ahsoftware.de> wrote:
Am 24.04.2015 um 16:47 schrieb Tomeu Vizoso:
Hi,
while reading the thread [0] that Alexander Holler started with his
series to make probing order deterministic, it occurred to me that it should
be possible to achieve the same by probing devices as they are referenced by
other devices.
This basically reuses the information that is already embedded in the
probe() implementations, saving us from refactoring existing drivers or
adding information to DTBs.
The main issue I see is that the registration code path in some
subsystems may not be reentrant, so some refactoring of the locking will be
needed. In my testing I have found this problem with regulators, as the
supply of a regulator might end up being registered during the registration
of the first one.
Something I'm not completely happy with is that I have had to move the
population of the device tree after all platform drivers have been
registered. Otherwise I don't see how I could register drivers on demand as
we don't have yet each driver's compatible strings.
I have done my testing on a Tegra124-based Chromebook, and these patches
were enough to eliminate all the deferred probes.
First you have to solve a problem which is totally unrelated to DT or
ACPI or x86 or ARM:
I think as long as drivers don't register themself whithout any side
effect, this problem isn't solvable. In order to make an ordered list of
drivers to start, you need to know which drivers are actually available.
Yeah, I kind of side-stepped that issue by waiting until all drivers
have been registered before registering devices. I think someone
suggested doing so in your thread (maybe Grant?).
That doesn't work. As said above, several drivers doing a lot more than just
registering in their initcall. They might even crash if some prerequisits
aren't given. And several of these prerequisits (init orders) are hardcoded
by various means.
But aren't those dependencies being taken care currently by the
initcall level the driver is placed in? That remains the same in this
approach.
In short, no. There are various very ugly things done in several drivers
to enforce some order.
Regards,
Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
