Messages in this thread | | | Date | Wed, 29 Apr 2015 11:46:43 +0200 | From | Alexander Holler <> | Subject | Re: [RFC 00/12] On-demand device registration |
| |
Am 29.04.2015 um 08:58 schrieb Tomeu Vizoso: > On 28 April 2015 at 20:17, Alexander Holler <holler@ahsoftware.de> wrote: >> Am 28.04.2015 um 14:49 schrieb Tomeu Vizoso: >>> >>> On 25 April 2015 at 01:15, Alexander Holler <holler@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
| |