Thread (86 messages) 86 messages, 9 authors, 2016-10-12

Re: [RFC 00/15] ACPI graph support

From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: 2016-10-06 15:56:30

On Thu, Oct 6, 2016 at 5:23 PM, Mark Brown [off-list ref] wrote:
On Thu, Oct 06, 2016 at 03:15:36PM +0200, Rafael J. Wysocki wrote:
quoted
On Thu, Oct 6, 2016 at 12:40 PM, Mark Brown [off-list ref] wrote:
quoted
quoted
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.
quoted
My view on that is a bit different.
quoted
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.
quoted
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.
Yes, it can.

I'm not against being careful, but I'd rather not reject things as a
matter of principle.
quoted
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.
quoted
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.
But here we are talking about using bindings that (a) have already
been defined in DT and (b) are actively used by the existing code.

I guess you mean using existing DT bindings instead of working on
standards, but let's face it, DT bindings de facto are the standard in
some parts of the kernel.
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.
Agreed, and that doesn't apply to ACPI only, of course.

Thanks,
Rafael
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help