On Wednesday, June 27, 2018 1:42:08 PM CEST Sakari Ailus wrote:
> 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?
Not really, please do what you think is the most appropriate.
Thanks!
--
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
