Hi Curt, others,
On Fri, Jun 22, 2018 at 10:27:55AM -0700, Curt Brune wrote:
> Hello -
>
> I am looking into exporting acpi _DSD properties to sysfs by updating
> acpi_device_setup_files() in drivers/acpi/scan.c. I need some advice.
>
> One problem area are device references that have not been created yet.
> For a tiny example, consider a device "X126" that refers to another
> device "QS24" that is not yet created:
>
> Device (X126) {
> Name (_HID, "PRP0001")
> Name (_DSD,
> Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () { "compatible", "some device X" },
> Package () { "peer", Package() { \QS24, 2 } },
> }
> }
> }
>
> Device (QS24) {
> Name (_HID, "PRP0001")
> Name (_DSD,
> Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () { "compatible", "some other device QS" },
> }
> }
> }
>
> The asl compiles fine, the compiler works out the references,
> presumably using two passes.
>
> Note: the fix is *not* to rewrite the asl to define QS24 before trying
> to reference it from X126. This is an instance of a more general
> problem where QS24 could be a hotplug device that arrives much later
> in time.
>
> With an older kernel, when calling
> __acpi_node_get_property_reference() to find properties for X126 it
> would return -ENODEV when processing the "peer" property, which would
> signal me that the "QS24" was not yet ready. I would add that ref to
> a deffered list and process it later during acpi_bus_scan(). That
> approach worked fine.
>
> However, these commits changed the return codes
> __acpi_node_get_property_reference(), nullifying the deferral check:
>
> 51858a277 ACPI: properties: Fix __acpi_node_get_property_reference() return codes
> c343bc2ce ACPI: properties: Align return codes of __acpi_node_get_property_reference()
>
> Having most errors come back as -EINVAL is not granular enough for my
> use case.
>
> My question is there a better way to do this? I could roll my own,
> but it would need to duplicate about 80% of
> __acpi_node_get_property_reference(), which would be dumb.
>
> Any advice is greatly appreciated.
Thanks for bringing this up.
I suppose it's the change of the return value from -ENODEV in 51858a277
that's the real issue?
One option could be to revert to the approach I had with v2 of the patch,
i.e. handle the conversion from ACPI specific return codes in
fwnode_property_get_reference_args() instead. This could be done for all
return codes or just for -ENODEV (I think I'd prefer that, as this is a
very specific use case that likely doesn't exist ).
Mika, Rafael, any opinion?
--
Kind regards,
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxx
--
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
