From: Mark Brown <broonie@kernel.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Mika Westerberg <mika.westerberg@linux.intel.com>,
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
Sakari Ailus <sakari.ailus@linux.intel.com>,
ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Rob Herring <robh@kernel.org>, Al Stone <ahs3@redhat.com>
Subject: Re: [RFC 00/15] ACPI graph support
Date: Thu, 6 Oct 2016 17:23:07 +0200 [thread overview]
Message-ID: <20161006152307.pqmmkazctqwlxsmy@sirena.org.uk> (raw)
In-Reply-To: <CAJZ5v0htdbUpqZNPi00ieNJ5WWiAczK+LbKLYobNGAr3Sr+HWw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2207 bytes --]
On Thu, Oct 06, 2016 at 03:15:36PM +0200, Rafael J. Wysocki wrote:
> On Thu, Oct 6, 2016 at 12:40 PM, Mark Brown <broonie@kernel.org> wrote:
> > One of my biggest concerns with this approach is that I'm really not
> > clear to me that that this has broad buy in from the x86/ACPI community
> > and therefore that we might end up needing to support several different
> > styles of ACPI bindings. Reuse would be great but it can be confusing
> > if there's multiple different styles of bindings in use at the same
> > time.
> My view on that is a bit different.
> Even if there's more than one style in use, they all can be supported
> at the same time. Avoiding confusion is only a matter of prioritizing
> them, then.
> It should be clear which style is the default one, which is going to
> be taken into consideration next and so on. If that is made clear, I
> don't see a big problem here, at least in principle.
My concern isn't just people using multiple styles, it's also people
trying to mix and match. Sometimes that will work well enough and it's
fine but it can go wrong.
> The pinctrl thing is being dealt with (and not in a way of adding
> pinctrl _DSD properties support to the kernel FWIW). Other things
> potentially conflicting with ACPI-defined HW control should be dealt
> with analogously.
Right, I was mentioning it mainly as an example of the general pattern
of ACPI bindings springing up without coordination rather than as a
specific problem that needs resolution.
> The point here is that some things just don't conflict with
> ACPI-defined HW control even potentially and they can be handled with
> the help of _DSD properties just fine. Thus, there are no technical
> obstacles to do that, at least not in principle.
It feels like we should be aiming for a higher bar with defining things
like this than simple technical possibility - my fear is that we end up
with a mess down the line with people being far too gung ho about
defining new bindings without trying to work on standards. Perhaps I'm
just worrying too much here but I'm not sure there's enough
communication going on. The private nature of ACPI standardization
discussion doesn't help here of course.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
next prev parent reply other threads:[~2016-10-06 15:44 UTC|newest]
Thread overview: 86+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-04 22:45 [RFC 00/15] ACPI graph support Sakari Ailus
2016-10-04 22:45 ` [RFC 01/15] ACPI / property: Add possiblity to retrieve parent firmware node Sakari Ailus
2016-10-04 22:45 ` [RFC 02/15] device property: Add fwnode_get_parent() Sakari Ailus
2016-10-04 22:45 ` [RFC 03/15] ACPI / property: Add fwnode_get_next_child_node() Sakari Ailus
2016-10-04 22:45 ` [RFC 04/15] device property: Add fwnode_get_named_child_node() Sakari Ailus
2016-10-04 22:45 ` [RFC 05/15] ACPI / property: Add support for remote endpoints Sakari Ailus
2016-10-04 22:45 ` [RFC 06/15] device " Sakari Ailus
2016-10-04 22:45 ` [RFC 07/15] device property: Add fwnode_handle_get() Sakari Ailus
2016-10-04 22:45 ` [RFC 08/15] of: Add of_fwnode_handle() to convert device nodes to fwnode_handle Sakari Ailus
2016-10-04 22:45 ` [RFC 09/15] driver core: Arrange headers alphabetically Sakari Ailus
2016-10-04 22:45 ` [RFC 10/15] of: No need to include property.h, fwnode.h is sufficient Sakari Ailus
2016-10-04 22:45 ` [RFC 11/15] device property: Obtain device's fwnode independently of FW type Sakari Ailus
2016-10-04 22:45 ` [RFC 12/15] device property: Add support for fwnode endpoints Sakari Ailus
2016-10-04 22:45 ` [RFC 13/15] of: Add nop implementation of of_get_next_parent() Sakari Ailus
2016-10-04 22:45 ` [RFC 14/15] device property: Add fwnode_get_next_parent() Sakari Ailus
2016-10-04 22:45 ` [RFC 15/15] ACPI / DSD: Document references, ports and endpoints Sakari Ailus
2016-10-05 9:22 ` [RFC 00/15] ACPI graph support Lorenzo Pieralisi
2016-10-05 11:41 ` Mika Westerberg
2016-10-05 15:06 ` Lorenzo Pieralisi
2016-10-05 15:32 ` Mika Westerberg
2016-10-05 16:18 ` Lorenzo Pieralisi
2016-10-05 20:33 ` Rafael J. Wysocki
2016-10-06 8:57 ` Lorenzo Pieralisi
2016-10-06 9:11 ` Mika Westerberg
2016-10-06 9:57 ` Lorenzo Pieralisi
2016-10-06 11:19 ` Mika Westerberg
2016-10-06 15:31 ` Mark Brown
2016-10-06 16:00 ` Rafael J. Wysocki
2016-10-06 16:14 ` Mark Brown
2016-10-06 17:02 ` Rafael J. Wysocki
2016-10-11 12:44 ` Mark Rutland
2016-10-12 0:19 ` Rafael J. Wysocki
2016-10-06 12:30 ` Rafael J. Wysocki
2016-10-06 10:40 ` Mark Brown
2016-10-06 12:26 ` Mika Westerberg
2016-10-06 13:15 ` Rafael J. Wysocki
2016-10-06 15:23 ` Mark Brown [this message]
2016-10-06 15:56 ` Rafael J. Wysocki
2016-10-06 15:57 ` Sudeep Holla
2016-10-06 12:26 ` Rafael J. Wysocki
2016-10-06 21:37 ` Mark Brown
2016-10-10 23:44 ` Rafael J. Wysocki
2016-10-11 12:11 ` Rafael J. Wysocki
2016-10-11 13:05 ` Mark Brown
2016-10-11 12:44 ` Mark Brown
2016-10-11 13:32 ` Mark Rutland
2016-10-12 0:32 ` Rafael J. Wysocki
2016-10-12 12:05 ` Mark Brown
2016-10-12 12:26 ` Rafael J. Wysocki
2016-10-11 13:01 ` Mark Rutland
2016-10-11 13:26 ` Mark Brown
2016-10-11 12:56 ` Mark Rutland
2016-10-06 22:02 ` Sakari Ailus
2016-10-11 12:35 ` Mark Rutland
2016-10-12 9:00 ` Mika Westerberg
2016-10-12 10:28 ` Mark Brown
2016-10-12 11:12 ` Mika Westerberg
2016-10-12 11:25 ` Rafael J. Wysocki
2016-10-12 16:00 ` Mark Brown
2016-10-12 11:14 ` Rafael J. Wysocki
2016-10-12 12:32 ` Mark Brown
2016-10-12 12:42 ` Rafael J. Wysocki
2016-10-12 14:59 ` Mark Brown
2016-10-12 17:50 ` Rafael J. Wysocki
2016-10-06 21:58 ` Sakari Ailus
2016-10-05 15:21 ` Mark Brown
2016-10-05 15:30 ` Sudeep Holla
2016-10-05 18:14 ` Mika Westerberg
2016-10-05 20:18 ` Rafael J. Wysocki
2016-10-06 10:29 ` Sudeep Holla
2016-10-06 13:04 ` Rafael J. Wysocki
2016-10-06 14:20 ` Sudeep Holla
2016-10-06 17:05 ` Rafael J. Wysocki
2016-10-06 17:20 ` Sudeep Holla
2016-10-11 0:05 ` Rafael J. Wysocki
2016-10-11 8:57 ` Sudeep Holla
2016-10-11 11:59 ` Rafael J. Wysocki
2016-10-11 13:15 ` Mark Brown
2016-10-12 0:35 ` Rafael J. Wysocki
2016-10-06 17:20 ` Al Stone
2016-10-06 20:14 ` Mark Brown
2016-10-06 20:54 ` Al Stone
2016-10-11 12:28 ` Mark Rutland
2016-10-12 1:18 ` Rafael J. Wysocki
2016-10-06 21:10 ` Sakari Ailus
2016-10-11 13:30 ` Mark Rutland
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=20161006152307.pqmmkazctqwlxsmy@sirena.org.uk \
--to=broonie@kernel.org \
--cc=ahs3@redhat.com \
--cc=linux-acpi@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=mika.westerberg@linux.intel.com \
--cc=rafael@kernel.org \
--cc=robh@kernel.org \
--cc=sakari.ailus@linux.intel.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.