From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
To: David Woodhouse <dwmw2@infradead.org>,
Charles Garcia-Tobin <charles.garcia-tobin@arm.com>
Cc: "ahs3@redhat.com" <ahs3@redhat.com>,
Catalin Marinas <Catalin.Marinas@arm.com>,
"steve.glendinning@shawell.net" <steve.glendinning@shawell.net>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Jeremy Linton <Jeremy.Linton@arm.com>,
"hanjun.guo@linaro.org" <hanjun.guo@linaro.org>,
"suravee.suthikulpanit@amd.com" <suravee.suthikulpanit@amd.com>,
"grant.likely@linaro.org" <grant.likely@linaro.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT
Date: Thu, 8 Oct 2015 02:11:38 +0200 [thread overview]
Message-ID: <5615B4BA.2060002@intel.com> (raw)
In-Reply-To: <1444129723.4674.236.camel@infradead.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: rafael.j.wysocki@intel.com (Rafael J. Wysocki)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT
Date: Thu, 8 Oct 2015 02:11:38 +0200 [thread overview]
Message-ID: <5615B4BA.2060002@intel.com> (raw)
In-Reply-To: <1444129723.4674.236.camel@infradead.org>
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
next prev parent reply other threads:[~2015-10-08 0:11 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-12 22:06 [PATCH 0/2] Enable smsc911x for use with ACPI Jeremy Linton
2015-08-12 22:06 ` Jeremy Linton
2015-08-12 22:06 ` [PATCH 1/2] Add a matching set of device_ functions for determining mac/phy Jeremy Linton
2015-08-12 22:06 ` Jeremy Linton
2015-08-12 22:13 ` Florian Fainelli
2015-08-12 22:13 ` Florian Fainelli
2015-08-14 15:55 ` Jeremy Linton
2015-08-14 15:55 ` Jeremy Linton
2015-08-13 11:57 ` Robin Murphy
2015-08-13 11:57 ` Robin Murphy
2015-08-13 14:24 ` Jeremy Linton
2015-08-13 14:24 ` Jeremy Linton
2015-08-12 22:06 ` [PATCH 2/2] Convert smsc911x to use ACPI as well as DT Jeremy Linton
2015-08-12 22:06 ` Jeremy Linton
2015-08-13 8:27 ` Graeme Gregory
2015-08-13 8:27 ` Graeme Gregory
2015-08-13 9:01 ` Lorenzo Pieralisi
2015-08-13 9:01 ` Lorenzo Pieralisi
2015-08-13 9:38 ` Graeme Gregory
2015-08-13 9:38 ` Graeme Gregory
2015-08-13 10:30 ` Lorenzo Pieralisi
2015-08-13 10:30 ` Lorenzo Pieralisi
2015-09-09 16:10 ` Marc Zyngier
2015-09-09 16:10 ` Marc Zyngier
2015-09-23 17:22 ` Jeremy Linton
2015-09-23 17:22 ` Jeremy Linton
2015-09-23 17:46 ` Marc Zyngier
2015-09-23 17:46 ` Marc Zyngier
2015-09-23 17:57 ` Sudeep Holla
2015-09-23 17:57 ` Sudeep Holla
2015-09-24 9:20 ` Catalin Marinas
2015-09-24 9:20 ` Catalin Marinas
2015-11-02 15:48 ` Jeremy Linton
2015-11-02 15:48 ` Jeremy Linton
2015-09-23 18:41 ` David Woodhouse
2015-09-23 18:41 ` David Woodhouse
2015-09-23 20:51 ` Rafael J. Wysocki
2015-09-23 20:51 ` Rafael J. Wysocki
2015-09-23 21:03 ` David Woodhouse
2015-09-23 21:03 ` David Woodhouse
2015-09-23 23:56 ` Hanjun Guo
2015-09-23 23:56 ` Hanjun Guo
2015-09-24 8:16 ` David Woodhouse
2015-09-24 8:16 ` David Woodhouse
2015-09-24 10:31 ` Catalin Marinas
2015-09-24 10:31 ` Catalin Marinas
2015-09-24 11:52 ` David Woodhouse
2015-09-24 11:52 ` David Woodhouse
2015-09-24 14:01 ` Lorenzo Pieralisi
2015-09-24 14:01 ` Lorenzo Pieralisi
2015-09-24 14:31 ` David Woodhouse
2015-09-24 14:31 ` David Woodhouse
2015-09-24 15:15 ` Catalin Marinas
2015-09-24 15:15 ` Catalin Marinas
2015-09-24 18:10 ` David Woodhouse
2015-09-24 18:10 ` David Woodhouse
2015-09-25 15:28 ` Catalin Marinas
2015-09-25 15:28 ` Catalin Marinas
2015-09-26 2:16 ` Rafael J. Wysocki
2015-09-26 2:16 ` Rafael J. Wysocki
2015-09-26 15:20 ` David Woodhouse
2015-09-26 15:20 ` David Woodhouse
2015-10-01 2:23 ` Al Stone
2015-10-01 2:23 ` Al Stone
2015-10-06 0:20 ` Charles Garcia-Tobin
2015-10-06 0:20 ` Charles Garcia-Tobin
2015-10-06 11:08 ` David Woodhouse
2015-10-06 11:08 ` David Woodhouse
2015-10-08 0:11 ` Rafael J. Wysocki [this message]
2015-10-08 0:11 ` Rafael J. Wysocki
2015-08-14 0:00 ` [PATCH 0/2] Enable smsc911x for use with ACPI David Miller
2015-08-14 0:00 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5615B4BA.2060002@intel.com \
--to=rafael.j.wysocki@intel.com \
--cc=Catalin.Marinas@arm.com \
--cc=Jeremy.Linton@arm.com \
--cc=ahs3@redhat.com \
--cc=charles.garcia-tobin@arm.com \
--cc=dwmw2@infradead.org \
--cc=grant.likely@linaro.org \
--cc=hanjun.guo@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=netdev@vger.kernel.org \
--cc=steve.glendinning@shawell.net \
--cc=suravee.suthikulpanit@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.