linux-kernel - Re: [GIT PULL] On-demand device probing

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 17 Oct 2015 11:27:55 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Rob Clark <robdclark@...il.com>
Cc:	Rob Herring <robh+dt@...nel.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Russell King <linux@....linux.org.uk>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Vinod Koul <vinod.koul@...el.com>,
	Dan Williams <dan.j.williams@...el.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	Alexandre Courbot <gnurou@...il.com>,
	Thierry Reding <thierry.reding@...il.com>,
	David Airlie <airlied@...ux.ie>,
	Terje Bergström <tbergstrom@...dia.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Wolfram Sang <wsa@...-dreams.de>,
	Frank Rowand <frowand.list@...il.com>,
	Grant Likely <grant.likely@...aro.org>,
	Kishon Vijay Abraham I <kishon@...com>,
	Sebastian Reichel <sre@...nel.org>,
	Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Felipe Balbi <balbi@...com>,
	Jingoo Han <jingoohan1@...il.com>,
	Lee Jones <lee.jones@...aro.org>,
	Jean-Christophe Plagniol-Villard <plagnioj@...osoft.com>,
	Tomi Valkeinen <tomi.valkeinen@...com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-clk@...r.kernel.org, dmaengine@...r.kernel.org,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>,
	"linux-i2c@...r.kernel.org" <linux-i2c@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	Linux PWM List <linux-pwm@...r.kernel.org>,
	Linux USB List <linux-usb@...r.kernel.org>,
	"linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org>
Subject: Re: [GIT PULL] On-demand device probing

On Sat, Oct 17, 2015 at 01:54:43PM -0400, Rob Clark wrote:
> On Sat, Oct 17, 2015 at 12:56 PM, Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> >> I'm guessing the time is a matter of probing and undoing the probes
> >> rather than slow h/w. We could maybe improve things by making sure
> >> drivers move what they defer on to the beginning of probe, but that
> >> seems like a horrible, fragile hack.
> >
> > How can calling probe and failing cause 2 seconds?  How many different
> > probe calls are failing here?  Again, a boot log graph would be great to
> > see as it will show the root cause, not just guessing at this.
> 
> 
> just fwiw, but when you have a driver that depends on several other
> drivers (which in turn depend on other drivers and so on), the amount
> of probe-defer we end up seeing is pretty comical.  Yeah, there
> probably is some room to optimize by juggling around order drivers do
> things in probe.  But that doesn't solve the fundamental problem with
> the current state, about probe order having no clue about
> dependencies..

I can imagine it is a lot of iterations, but how long does it really
take?  How many different devices are involved that it takes multiple
loops in order to finally work out the correct order?  Where is the time
delays here, just calling probe() and having it instantly return
shouldn't take all that long.

thanks,

greg k-h
--
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/