Hi Rafael/Rui,

On 8/17/2017 8:14 PM, Zhang Rui wrote:

On Fri, 2017-08-18 at 02:09 +0200, Rafael J. Wysocki wrote:

quoted

On Wed, Aug 9, 2017 at 4:27 PM, Zhang Rui [off-list ref]
wrote:

quoted

Hi, Prakash,

On Tue, 2017-08-08 at 10:01 -0600, Prakash, Prashanth wrote:

quoted

Hi Rui,

On 8/8/2017 2:23 AM, Zhang Rui wrote:

quoted

On Fri, 2017-07-14 at 11:48 -0600, Prashanth Prakash wrote:

quoted

Per ACPI 6.2 spec, platforms can optionally add a
string(_STR)
object within each thermal zone package which provides a user
friendly name/description.

Add support to parse the string object, which will be exposed
to userspace by thermal framework.

is there any real request for this?

Yes, Qualcomm server platforms adds these description strings.

quoted

_STR is a generic control method for all the ACPI devices.
Thus I'm wondering, if really needed, should we expose this in
acpi
bus
instead?

AFAIK, adding a _STR to any package was not explicitly allowed by
the
spec.
Updates in APCI 6.2 made it legal to add an _STR object to
thermal
zone
specifically, so added this support only to thermal zone.

I see that _STR is stated explicitly in 11.4.14, ACPI spec 6.2, but
according to section 6.1.10, "The _STR object evaluates to a
Unicode
string that describes the device or thermal zone. "
_STR is still a generic control method that can exist in any other
device scope.

so to me, this is a optional but generic feature for all the ACPI
devices, and we don't have a solid reason that it should be part of
thermal sysfs I/F, thus a better solution to me is to expose this
as an
attribute of ACPI device, and we can link to the ACPI device from
thermal sysfs I/F in userspace.

what do you think, Rafael?

Since you have a ->get_desc method, I don't have a big problem with
the approach here.

I'm not particularly liking the "<not supported>" thing returned if
_STR is not present, though.

I will change the implementation such that if _STR object was not found then
thermal_get_desc would return -ENXIO (or should it be different errno?).

No, actually I mean adding a new sysfs attribute under ACPI device
node, just like path/hid/status/adr, etc.

Sorry Rui, I didn't read your earlier comment correctly. Thermal zone's _STR is
useful in couple of scenarios(even if ACPI device containing the thermal_zone
had a _STR object):
- When we have more than 1 thermal sensors/zones under a device then this will
allow us to differentiate them
- When we have some thermal sensors that doesn't have ACPI device associated
with it. For example: a shared L3 cache, an abstract region on SoC. In these cases
we can add a thermal zone object in an appropriate place in dsdt and the
associated _STR will allow us to provide a user friendly name/description.

Of course the attribute should be optional, depends on if the _STR
control methods exist or not.

thanks,
rui

quoted

Thanks,
Rafael

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Thanks for your feedback!

--
Regards,
Prashanth