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: <1443095558.74600.84.camel@infradead.org>
Date:	Thu, 24 Sep 2015 12:52:38 +0100
From:	David Woodhouse <dwmw2@...radead.org>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Hanjun Guo <hanjun.guo@...aro.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Jeremy Linton <jeremy.linton@....com>,
	linux-arm-kernel@...ts.infradead.org,
	steve.glendinning@...well.net, netdev@...r.kernel.org,
	grant.likely@...aro.org, Suravee.Suthikulpanit@....com
Subject: Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

Hi Catalin,

I understand your concerns, but I'm still not convinced of your
conclusion.

On Thu, 2015-09-24 at 11:31 +0100, Catalin Marinas wrote:
> PRP0001 opens the door to any DT-like properties in ACPI and, knowing
> how the ARM ecosystem works, I'm pretty sure we'll soon lose control (if
> we haven't already; not all the developments are done in the open).

No. That door is wide open already — people can already do whatever
they like in _DSD properties. If they're going to screw up DT
properties, they'll screw up ACPI-only _DSD properties just the same.

You speak of maintaining "tight control of the _DSD properties that
are going to be used in ACPI tables"... but if you're going to
confiscate their crackpipe and stand over them while they work, you can
do that just as well whether they're using "PRP0001" or "FOO1234" as
their HID value.

In that sense, the HID is entirely orthogonal.

And think about it... we *really* don't want a given peripheral device
to have *different* bindings depending on whether it's discovered with
a specific ACPI HID, vs. when it's discovered via DT or the PRP0001
HID. That way lies complete insanity.

In some ways, your proposal would be actively *counterproductive*. You
say you want to train people *not* to keep patching the kernel. But
where they *could* have just used PRP0001 and used a pre-existing
kernel, you then tell them "oh, but now you need to patch the kernel
because we want you to make up a new HID and not be compatible with
what already exists."

If you go down this road, I predict we'll start seeing *separate*
drivers for identical components, because the bindings for DT vs. ACPI
properties are different. We really don't want that.

> The pro ARM ACPI camp has been very vocal against DT in the server
> space. I'd like to seem them as vocal about PRP0001, unless they find it
> acceptable (and should apologise for bashing DT ;)).

Fundamentally, that DT vs. ACPI distinction has gone away with the
introduction of _DSD. We *need* the flexibility that we gain from being
able to provide device properties rather than inventing a new HID for
every permutation, and with that flexibility comes a certain amount of
responsibility to do things sensibly.

People have not always designed their bindings sensibly. But that isn't
going to be magically solved in the ACPI world, unless you *do*
actually stand over them with their crackpipe in your hand, as I joked
above. And eschewing PRP0001 really doesn't help you with that. It just
makes things harder.

-- 
dwmw2

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