Date:	Thu, 19 Mar 2015 09:01:46 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@...e.com>,
	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Olof Johansson <olof@...om.net>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Subject: Re: [PATCH 6/8] amd64_edac: enforce synchronous probe

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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists