Moi, On 04/10/17 13:11, Mika Westerberg wrote: > On Mon, Apr 10, 2017 at 12:59:36PM +0300, Sakari Ailus wrote: >> Hi Mika and Laurent, >> >> On 04/10/17 12:21, Mika Westerberg wrote: >>> On Sat, Apr 08, 2017 at 01:55:15AM +0300, Sakari Ailus wrote: >>>>> My ACPI knowledge is limited, but don't ACPI nodes have 4 character names that >>>>> can be combined in a string to create a full path ? >>>> >>>> There is something, yes, but the ACPI framework currently has no such >>>> functionality. I believe it could be implemented though. Cc Mika. >>> >>> All ACPI node names are 32-bit integers and those are combined to form a >>> path, like \_SB.PCI0.I2C0 and so on. A single ACPI node name cannot be >>> larger than 4 chars, though. >> >> On OF, each node has a full_node string attached to it. You could >> produce a similar string on ACPI, it is not currently done. Adding such >> a string to each fwnode would require some extra memory as well. I >> wonder if that could be a Kconfig option. >> >> It would help debugging though. >> >> Providing this information to the user space has been proposed as well: >> Devicetree spec defines the syntax for such strings. The user can use >> that information for recognising a particular device in the system. >> >> The ACPI spec does, too, but it is limited to ACPI nodes and does not >> address hierarchical data extensions. We'd define the syntax for those >> ourselves. >> >> Mika: what do you think? > > There is a function acpi_get_name() which you can use to extract the > full name of the node. Why not investigate how to use that instead of > duplicating the name in an ACPI node. > acpi_get_name() would obviously be needed to produce such a string in the first place. acpi_get_name() puts the string to an existing buffer so it cannot be used as such to return a pointer to a string (e.g. to be used for snprintf()). Also, it only contains the device path of the device. The data extension path matters here, too. -- Regards, Sakari Ailus sakari.ailus@xxxxxxxxxxxxxxx
