netdev - Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as 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: <1444129723.4674.236.camel@infradead.org>
Date:	Tue, 06 Oct 2015 12:08:43 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Charles Garcia-Tobin <charles.garcia-tobin@....com>,
	"ahs3@...hat.com" <ahs3@...hat.com>,
	Catalin Marinas <Catalin.Marinas@....com>
Cc:	"steve.glendinning@...well.net" <steve.glendinning@...well.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Jeremy Linton <Jeremy.Linton@....com>,
	"hanjun.guo@...aro.org" <hanjun.guo@...aro.org>,
	"suravee.suthikulpanit@....com" <suravee.suthikulpanit@....com>,
	"grant.likely@...aro.org" <grant.likely@...aro.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

On Mon, 2015-10-05 at 17:20 -0700, Charles Garcia-Tobin wrote:
> it in ACPI circles
> unless we had wider agreement among OSs to use it. AFAIK PRP00001 has not
> actually been approved yet in the specification forum, and that it in
> itself is more of a concern for me,as the code has been pushed upstream.

Why would that be a concern? In that context it's just one device ID.
Individual devices don't *need* to be approved. OK, the 'PRP' vendor
prefix is not officially assigned but that's really a trivial piece of
bureaucracy.

> I guess it¹s up to Catalin, but disabling for ARM seems like a good idea
> right now, another option is to add tests to FWTS.

I understand the motivation to avoid embracing a whole bunch of crappy
bindings. But I think that eschewing PRP0001 is the wrong technical
approach to achieving that.

It has false negatives — as soon as you have a *single* existing DT
binding, perhaps something as simple as the serial port bindings from
the CHRP days, you'll be in a situation where you can't use that.
I've *got* hardware where I need to advertise a serial port with a
clock-frequency property because it *isn't* compatible with PNP0501.

And it has false positives — there's nothing to prevent people from
doing ACPI-style bindings with crappy device bindings which also aren't
approved.

I think it's utterly naïve to believe that simply avoiding the use of
PRP0001 + compatible for matching is going to have *any* significant
beneficial effect whatsoever. It only makes life harder for all
concerned.

Perhaps a better approach would be to introduce something like
CONFIG_UNAPPROVED_BINDINGS (which can't be set on ARM64), and those
drivers which use bindings that *aren't* approved by Catalin's crack
team of reviewers need to depend on !UNAPPROVED_BINDINGS. To be honest,
I still think even *that* is somewhat naïve, but it's still a better
way of implementing what you're actually trying to achieve, however
optimistic you have to be to think it'll ever work in practice.

-- 
dwmw2

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5691 bytes)