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
| ||
|
Date: Mon, 26 Oct 2015 13:55:29 +0100 From: Tomeu Vizoso <tomeu.vizoso@...labora.com> To: Michael Turquette <mturquette@...libre.com> Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Mark Brown <broonie@...nel.org>, "Rafael J. Wysocki" <rjw@...ysocki.net>, Rob Herring <robh+dt@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Tim Bird <tim.bird@...ymobile.com>, "frowand.list@...il.com" <frowand.list@...il.com>, Russell King <linux@....linux.org.uk>, 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>, 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>, 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" <linux-clk@...r.kernel.org>, "dmaengine@...r.kernel.org" <dmaengine@...r.kernel.org>, "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>, "dri-devel@...ts.freedesktop.org" <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@...r.kernel.org" <linux-usb@...r.kernel.org>, "linux-fbdev@...r.kernel.org" <linux-fbdev@...r.kernel.org> Subject: Re: [GIT PULL] On-demand device probing On 26 October 2015 at 11:51, Michael Turquette <mturquette@...libre.com> wrote: > Quoting Rafael J. Wysocki (2015-10-25 06:54:39) >> On Sun, Oct 25, 2015 at 12:06 AM, Mark Brown <broonie@...nel.org> wrote: >> > On Sat, Oct 24, 2015 at 04:17:12PM +0200, Rafael J. Wysocki wrote: >> > >> >> Well, I'm not quite sure why exactly everyone is so focused on probing here. >> > >> > Probe deferral is really noisy even if it's working fine on a given >> > system so it's constantly being highlighted to people in a way that >> > other issues aren't if you're not directly having problems. >> > >> > There's also the understanding people had that the order things get >> > bound changes the ordering for some of the other cases (perhaps it's a >> > good idea to do that, it seems likely to be sensible?). >> >> But it really doesn't do that. Also making it do so doesn't help much >> in the cases where things can happen asynchronously (system >> suspend/resume, runtime PM). >> >> If, instead, there was a way to specify a functional dependency at the >> device registration time, it might be used to change the order of >> everything relevant, including probe. That should help to reduce the >> noise you're referring to. > > Taking it a step further, if functional dependencies were understood at > link-time then we could optimize link order as well. There are probably > lots of optimizations if we only made the effort to understand these > dependencies earlier. > > Constructing the device/resource dependency graph before the device ever > boots sounds interesting to me. Alexander Holler has been looking at that for some time already. Regards, Tomeu > Regards, > Mike > >> >> If the dependency could only be discovered at the probe time, the >> order of things might be changed in response to letting the driver >> core know about it rather than "just in case", which should be more >> efficient. >> >> Thanks, >> Rafael > -- > 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/ -- 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