On Thu, Mar 19, 2015 at 11:41:41AM -0400, Tejun Heo wrote: > Hello, Dmitry. > > On Wed, Mar 18, 2015 at 05:26:19PM -0700, Dmitry Torokhov wrote: > > Why would they get decoupled? For example, if we are talking about input > > devices, they can be connected to platform bus or one of i2c buses or > > HID (via USB). If we want to ensure ordering we'd have to synchronize > > all of them somehow and I do not have even sure what the rule should be. > > I mean I am probing platform devices simultaneously and I come to an > > i2c controller and gpio input device. So I wait till both done probing > > before posting new devices to the driver core? What if one returns > > -EPROBE_DEFER? Do I stop and wait for the deferral to complete? What if > > deferral is satisfied by a 3rd device on platform bus? If I am waiting > > for all devices to probe I won't be able to resolve the deferral. And > > even without deferral in old world we'd probe i2c and i2c will lead to > > discovery of another input device which would be registered before > > registering the platform input device. So with async we'd have to pause > > platform probing until all children of i2c are done probing, which > > pretty much kills all async gains as far as I can see. > ... > > I think the logic is pretty much the same even with async probing, > > especially if you take into account -EPROBE_DEFER handling that we > > already have. You may not run into it that often on x86 but it is pretty > > common on arm devices and it does change the probe order. > > I see, so, if ordering has never been reliable for a given platform or > class of devices, there's nothing to worry about. Or even if ordering > has been reliable but change of ordering wouldn't be noticable from > userland, that'd be fine too. The thing is that for certain classes > of devices, we've been guaranteeing probe ordering during boot and > there are non-insignificant number of use cases which depend on that > and we should be able to accomodate them. > > I don't think this'd be a huge burden. e.g. even something like > synchronizing once for all async pci probes can be enough. That > should be enough for most traditional storage devices and that's the > biggest item.
OK, I guess I (or maybe somebody else) could look into PCI bus core to add the necessary sync points for that before we enable wholesale async probing. > > > I do not think this flag is useful for end users but rather for > > distributions. Either their userspace is ready to handle fully async > > probe or not quite yet. > > I think we should be able to enable all-async probing by default and > that'd be far beneficial and simpler for everybody. I think that would be the goal, yes, but I think we'd need some "trial" period before we can do that: I need to look into at least serial and regulators to make it work (not even considering any userspace). We are definitely not ready just yet and that is why I have a whitelist: there are classes of devices that all userspaces learned to deal with long ago and we can make them not stall boot right now. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
