Re: [PATCH v2 5/8] v4l: Switch from V4L2 OF not V4L2 fwnode API

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux