linux-kernel - Re: [RFC PATCH 0/9] dt: dependencies (for deterministic driver initialization order based on the DT)

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]

Message-ID: <20140825093931.GB2399@ulmo>
Date:	Mon, 25 Aug 2014 11:39:32 +0200
From:	Thierry Reding <thierry.reding@...il.com>
To:	Mark Rutland <mark.rutland@....com>
Cc:	Alexander Holler <holler@...oftware.de>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Jon Loeliger <jdl@....com>,
	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 Fri, Aug 22, 2014 at 02:19:19PM +0100, Mark Rutland wrote:
> On Thu, Aug 21, 2014 at 08:19:00PM +0100, Alexander Holler wrote:
> > Am 21.08.2014 16:02, schrieb Thierry Reding:
> > 
> > > Anyway, those are all fairly standard reasons for where deferred probe
> > > triggers, and since I do like deferred probe for it's simplicity and
> > > reliability I'd rather not try to work around it if boot time is all
> > > that people are concerned about.
> > 
> > It's neither simple nor reliable. It's non deterministic brutforcing 
> > while making it almost impossible to identify real errors.
> 
> It's horrible, yes.
> 
> > In my humble opinion the worst way to solve something. I'm pretty sure 
> > if I would have suggest such a solution, the maintainer crowd would have 
> > eaten me without cooking.
> 
> We didn't have a better workable solution at the time.

You make it sound like we've come up with a better workable solution in
the meantime.

> Having a hack that got boards booting was considered better than not
> having them boot.
> I don't remember people being particularly enthralled by the idea.

Odd, I remember things quite differently.

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?

Thierry

Content of type "application/pgp-signature" skipped