Messages in this thread | | | From | Tomeu Vizoso <> | Date | Tue, 26 May 2015 19:53:33 +0200 | Subject | Re: [PATCH 10/21] regulator: core: Probe regulators on demand |
| |
On 26 May 2015 at 18:54, Mark Brown <broonie@kernel.org> wrote: > On Tue, May 26, 2015 at 05:08:38PM +0200, Tomeu Vizoso wrote: >> On 26 May 2015 at 11:36, Mark Brown <broonie@kernel.org> wrote: > >> > Yes, x86 based embedded systems use ACPI (and we really ought to be >> > trying to help systems using board files too for that matter). > >> Yes, I see how registering devices on-demand could be implemented for >> all those, but what I don't see is how they would benefit from it. > > You'd need to be clearer about what problem you're trying to solve > there, which is something you left us guessing at! > >> I can see an hypothetical maintenance benefit in sharing as much code >> as possible between these different scenarios, but in this case, >> because this feature is so closely tied to machine description I think >> complexity would be actually bigger. > > We've now got abstractions for common firmware operations (look at the > fwnode stuff) and this isn't exactly deep introspection here. > > If you're trying to solve the probe order problem you can probably get a > long way by just doing something that boils down to "try to instantiate > everything referenced from this node" which could probably even be > kicked from the driver core prior to probe and cover most cases. Or put > this into the node lookup interface so we try to instantiate everything > we reference. > >> On machines that have ACPI, most of those devices aren't exposed to >> the kernel and few or no deferred probes happen (though I have only >> tested on qemu and Minnowboard MAX, both with no deferred probes). > > On the machines that you happen to have looked at; I would rather expect > that x86 based phones will be in a similar situation once they move to > ACPI which they should be doing this year if they didn't already, and > the embedded systems will doubtless run into this once they have any > meaningful hardware on them (the base Minnoboard isn't really > interesting here, it's once you build a system on top of that). > >> On machines with board files, devices are registered in a >> predetermined order, presumably without any deferred probes. > > No, not in the least. Quite aside from anything else as soon as you > allow things to be built as modules userspace is free to load things in > whatever order amuses it. Think about what's going on here - it's not > just registration of devices, it's also about the order in which > subsystems and drivers register themselves. > >> My understanding is that the problem I'm addressing is specific of >> machines in which the kernel is in charge of pretty much everything >> and that the information about what devices are present is given in an >> arbitrary order. > > I don't think you've fully understood the problem space here.
Fair enough, what's your understanding of it?
Thanks,
Tomeu
| |