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: Thu, 8 Oct 2015 02:11:38 +0200 From: "Rafael J. Wysocki" <rafael.j.wysocki@...el.com> To: David Woodhouse <dwmw2@...radead.org>, Charles Garcia-Tobin <charles.garcia-tobin@....com> Cc: "ahs3@...hat.com" <ahs3@...hat.com>, Catalin Marinas <Catalin.Marinas@....com>, "steve.glendinning@...well.net" <steve.glendinning@...well.net>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>, 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 10/6/2015 1:08 PM, David Woodhouse wrote: > 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. > Also, let me mention one case PRP0001 is intended for that seems to be real. Say there is a piece of hardware that becomes so popular that the majority of vendors include it in their SoCs. Now all of them have to allocate ACPI/PNP device IDs for that and (without PRP0001) all of those device IDs need to go into the driver for that thing to make it work on all of the SoCs in question. As a result, the mainline kernel doesn't work on new SoCs with ACPI without modifications, although it works on all of them with DT in principle. Moreover, unmodified binary distro kernels don't work on new SoCs with ACPI, although they may work just fine on them with DT (that sort of seems to be a case that Red Hat may be interested in for one example, but I may be wrong here). In theory, that may be addressed by allocating a "master" ACPI/PNP device ID for that device and listing it in the device's _CID on all of the SoCs in question, but then it isn't particularly clear who's going to be responsible for allocating that device ID and "propagating" the knowledge of it to everybody interested to make things consistent. [Side note: Using a different vendor's device ID in a _CID is quite questionable, so the "master" one would need to be something "vendor agnostic" if that makes sense at all ...] Let alone the fact that PRP0001 is actually quite useful at the prototyping stage when it is premature to allocate a new device ID just yet. Taking that to the extreme, if someone whittles a board in his or her garage and wants to use it to drive their homemade grass watering system, having to invent a new device ID and put it into the existing driver that otherwise doesn't require any modifications is ... you know what I mean. All in all, I'd recommend some caution to ensure that the baby is not going away along with the bath water here. Thanks, Rafael -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists