Messages in this thread | | | Date | Wed, 15 Oct 2014 16:17:02 +0100 | From | Mark Rutland <> | Subject | Re: [PATCH v4 00/13] Add ACPI _DSD and unified device properties support |
| |
On Wed, Oct 15, 2014 at 03:46:39PM +0100, Darren Hart wrote: > > > On 10/15/14 16:08, David Woodhouse wrote: > > > >> We have been checking for all DT platforms, and that's a bug for DT. > >> Copying that bug to ACPI is inexcusable given we know it's a bug to do > >> so. > > > > We'll, perhaps it should be named 'used-by-firmware' and actually it's > > just as valid under ACPI as it is on RTAS systems. All it does is stop the > > OS from using the port. > > > >> I understand that. However, where a binding doesn't make sense (as in > >> this case), it shouldn't be enabled for ACPI as it provides a larger > >> surface area for misuse, for no benefit. > > > > These are *optional* properties. They were optional precisely *because* > > they only make sense in some cases. I don't know that it makes sense to > > take them away. The benefit we get is *consistency*. For example if > > someone *does* use the property in question as 'used-by-firmware' and > > expects the OS not to touch it, we don't want that to change behaviour > > between ACPI and fdt boots. > > My comment was going to be along the same lines. It is an optional > parameter, which is what I would expect for a firmware-specific type of > property. > > I also don't agree that this is "copying that bug to ACPI". This line of > code has no impact to ACPI. No ACPI implementation should add this, > certainly not if it was actually tested as it would not run if it was > present in the _DSD. So... what's the problem exactly? Or perhaps more > specifically: > > Mark, what would you propose we do differently to enable this driver to > be firmware-type agnostic?
For this particular driver, all I'm asking for is that the "used-by-rtas" property is not moved over from of_find_property to device_get_property. It is irrelevant for all ACPI systems. Evidently my comment was unclear; I apologise for that.
We have status = "disabled" as a less specific mechanism for telling the OS to ignore a node in DT. I was under the impression that ACPI already had a mechanism for marking devices to be ignored, but perhaps I am mistaken.
The concerns I mentioned at the end of my original reply were of a more general nature than this particular device description.
Thanks, Mark.
| |