On 06/10/16 14:04, Rafael J. Wysocki wrote:
On Thu, Oct 6, 2016 at 12:29 PM, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
[...]
No doubt about that, though controlling it is another question.
Especially ARM vendors who have some driver for DT might just use this
method without anyone noticing, ignoring the ACPI method as everything
just works out of box. That's the main worry. Also it also provides no
incentive for them to work with ASWG to enhance ACPI specification.
They will need to hack the kernel to do that, because the mainline
will not support anything like regulator or pinctrl support based on
DT properties, at least as long as I have any influence on that.
OK, that's good.
And if they need to hack the kernel anyway, nothing prevents them from
hacking it to support whatever properties they like even if we don't
put any support for any generic _DSD properties into the mainline.
That's why the whole "oh but this allows ARM vendors to abuse things"
argument doesn't hold any water in my view.
While I agree with you, the argument which will be done and will win
most of the time to upstream something is that "we have shipped the
product with that table, we need to support it upstream...". I don't
think even you disagree with that ;)
Yes, it may make it a bit easier for them to abuse things (as they
don't have to hack the kernel to support properties already supported
by it), but OTOH it sort of avoids the problem that multiple vendors
could hack the kernel in different and possibly incompatible ways to
make it support the same set of properties they all need.
Pity, but still better :)
Sure. On the side note, we should at-least have PRP0001 reserved
officially in the ACPI specification, I still see no mention about that
in the spec and both firmware and Linux are using it for a while now.
The whole PRPxxxx range of device IDs is reserved.
Good, sorry I couldn't spot anything in ACPIv6.1 or uefi.org apart from
dsd mailing list.
There is a metric ton of DT-centric code already in the kernel that is
well understood and tested and it would be plain unreasonable to try
to reinvent the wheel and (a) invent ACPI-specific ways of doing the
same thing for every use case that is distinct enough and (b) write
code using those ACPI-specific ways instead of already defined
properties just in order to handle the same hardware in the same OS.
[If you have to support different OSes, this is a different matter.]
Agreed, but as you mentioned the question of different OS remains.
If you are saying "no DT properties in _DSD", this implies that code
reuse is bad for some unspecified reason. It is very difficult to me
to agree with that position.
No, I am not saying no. I am just worried where do we stop this and how
do we prevent ARM vendors exploiting this, and not rather contributing
to the ACPI specification enhancement.
The ACPI spec may not be the right place to define support for things
this series is about, though. Ideally, they should be defined by
other standards using ASL as a form of expression or representation,
if you will.
Yes, that would be ideal.
And that still needs to happen for different OSes to be able to use
the ACPI tables in the same way (which doesn't even happen for
different versions of Windows, but that's a different matter).
However, adding support for additional _DSD properties to the mainline
kernel need not prevent a standardization process like this from
happening. The point is that this process will take time and both the
HW and the code in the kernel supporting it are available today. The
only problem is that the code is DT-centric and there are ACPI tables
in the boards in question.
If/when the new standard comes along, we will support it by default
and then fall back to _DSD properties if information defined by it is
not available. Pretty much the same way as we fall back to
driver-supplied data if we can get information we need from the
platform firmware.
Yes that's much better.
--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
