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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Tue, 26 Aug 2014 09:51:28 +0100 From: Grant Likely <grant.likely@...aro.org> To: Jon Loeliger <jdl@....com>, Thierry Reding <thierry.reding@...il.com> Cc: Mark Rutland <mark.rutland@....com>, Alexander Holler <holler@...oftware.de>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Russell King <linux@....linux.org.uk>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Rob Herring <robh+dt@...nel.org>, Arnd Bergmann <arnd@...db.de>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT) On Mon, 25 Aug 2014 08:08:59 -0500, Jon Loeliger <jdl@....com> wrote: > > > > > Anyway, instead of going back and forth between "deferred probe is good" > > and "deferred probe is bad", how about we do something useful now and > > concentrate on how to make use of the information we have in DT with the > > goal to reduce the number of cases where deferred probing is required? > > Good idea. > > The proposal on the table is to allow the probe code > to make a topological sort of the devices based on > dependency information either implied, explicitly stated > or both. That is likely a fundamentally correct approach. > > I believe some of the issues that need to be resolved are: > > 1) What constitutes a dependency? > 2) How is that dependency expressed? > 3) How do we add missing dependencies? > 4) Backward compatability problems. > > There are other questions, of course. Is it a topsort > per bus? Are there required "early devices"? Should > the inter-node dependencies be expressed at each node, > or in a separate hierarchy within the DTS? Others. Getting the dependency tree I think is only half the problem. The other have is how to get the driver model to actually order probing using that list. That problem is hard because the order drivers are probed is currently determined by the interaction of driver link order, driver initcall level, and device registration order. The first devices are registered at an early initcall, before their drivers, and therefore bind order is primarily determined by initcall level and driver link order. However, later devices (ie. i2c clients) are registered by the bus driver (ie. again, i2c) and probe order may be primarily link order (if the driver is not yet registered) or registration order (if the driver was registered before the parent bus). g. -- 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