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. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
