On 8/17/14, 5:49, "Grant Likely" <grant.likely@xxxxxxxxxxxx> wrote:
>
>Hi Mika and Rafael,
>
>Comments below...
>
>On Sun, 17 Aug 2014 09:04:13 +0300, Mika Westerberg
><mika.westerberg@xxxxxxxxxxxxxxx> wrote:
>> From: "Rafael J. Wysocki" <rafael.j.wysocki@xxxxxxxxx>
>>
>> Add a uniform interface by which device drivers can request device
>> properties from the platform firmware by providing a property name
>> and the corresponding data type.
>>
>> Three general helper functions, device_property_get(),
>> device_property_read() and device_property_read_array() are provided.
>> The first one allows the raw value of a given device property to be
>> accessed by the driver. The remaining two allow the value of a numeric
>> or string property and multiple numeric or string values of one array
>> property to be acquired, respectively.
>>
>> The interface is supposed to cover both ACPI and Device Trees,
>> although the ACPI part is only implemented at this time.
>
>Nit:
>s/at this time/in this change. The DT component is implemented in a
>subsequent patch./
>
>I almost complained that the DT portion must be implemented before this
>series can even be considered, but then I found it in patch 4/9. :-)
>
>>
>> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
>> Signed-off-by: Aaron Lu <aaron.lu@xxxxxxxxx>
>> Reviewed-by: Darren Hart <dvhart@xxxxxxxxxxxxxxx>
>> Signed-off-by: Mika Westerberg <mika.westerberg@xxxxxxxxxxxxxxx>
>> ---
>> drivers/acpi/glue.c | 4 +-
>> drivers/acpi/property.c | 179
>>++++++++++++++++++++++++++++++++++++++++++++++-
>> drivers/acpi/scan.c | 12 +++-
>> drivers/base/Makefile | 2 +-
>> drivers/base/property.c | 48 +++++++++++++
>> include/acpi/acpi_bus.h | 1 +
>> include/linux/device.h | 3 +
>> include/linux/property.h | 50 +++++++++++++
>> 8 files changed, 293 insertions(+), 6 deletions(-)
>> create mode 100644 drivers/base/property.c
>> create mode 100644 include/linux/property.h
>>
...
>>
>> static void acpi_device_del(struct acpi_device *device)
>> {
>> mutex_lock(&acpi_device_lock);
>> - if (device->parent)
>> + if (device->parent) {
>> list_del(&device->node);
>> + device->parent->child_count--;
>
>I worry about housekeeping like this. It is easy for bugs to slip in.
>Unless returning the child count is in a critical path (which it
>shouldn't be), I would drop the child_count member and simply count the
>number of items in the list when required.
>
>This of course is not my subsystem, so I won't ACK or NACK the patch over
>this.
This would be consistent with of_get_child_count() and is unlikely to be
called much more than once per device. The maintenance however is limited
to the add/del functions, so it doesn't seem difficult to maintain. I have
no objections to just walking the list though if that is preferable.
...
>> @@ -701,6 +702,7 @@ struct acpi_dev_node {
>> * @archdata: For arch-specific additions.
>> * @of_node: Associated device tree node.
>> * @acpi_node: Associated ACPI device node.
>> + * @property_ops: Firmware interface for device properties
>> * @devt: For creating the sysfs "dev".
>> * @id: device instance
>> * @devres_lock: Spinlock to protect the resource of the device.
>> @@ -777,6 +779,7 @@ struct device {
>>
>> struct device_node *of_node; /* associated device tree node */
>> struct acpi_dev_node acpi_node; /* associated ACPI device node */
>> + struct dev_prop_ops *property_ops;
>
>There are only 2 users of this interface. I don't think adding an ops
>pointer to each and every struct device is warrented when the wrapper
>function can check if of_node or acpi_node is set and call the
>appropriate helper. It is unlikely anything else will use this hook. It
>will result in smaller memory footprint. Also smaller code when only one
>of
>CONFIG_OF and CONFIG_ACPI are selected, which is almost always. :-)
>
>It can be refactored later if that ever changes.
Our intent was to eliminate the #ifdefery in every one of the accessors.
It was my understanding the ops structures were preferable in such
situations. For a 64-bit machine with 1000 devices (all of which use
device properties) with one or the other of ACPI/OF enabled, the
additional memory requirement here is what... Something like (8*1000 + 4)
~= 8KB ? That seems worth the arguably more maintainable code to me. Is
there more to it than this, am I missing some more significant impact?
>> dev_t devt; /* dev_t, creates the sysfs "dev" */
>> u32 id; /* device instance */
>> diff --git a/include/linux/property.h b/include/linux/property.h
>> new file mode 100644
>> index 000000000000..52ea7fe7fe09
>> --- /dev/null
>> +++ b/include/linux/property.h
>> @@ -0,0 +1,50 @@
>> +/*
>> + * property.h - Unified device property interface.
>> + *
>> + * Copyright (C) 2014, Intel Corporation
>> + * Author: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx>
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#ifndef _LINUX_PROPERTY_H_
>> +#define _LINUX_PROPERTY_H_
>> +
>> +#include <linux/device.h>
>> +#include <linux/acpi.h>
>> +#include <linux/of.h>
>> +
>> +enum dev_prop_type {
>> + DEV_PROP_U8,
>> + DEV_PROP_U16,
>> + DEV_PROP_U32,
>> + DEV_PROP_U64,
>> + DEV_PROP_STRING,
>> + DEV_PROP_MAX,
>> +};
>> +
>> +struct dev_prop_ops {
>> + int (*get)(struct device *dev, const char *propname, void **valptr);
>> + int (*read)(struct device *dev, const char *propname,
>> + enum dev_prop_type proptype, void *val);
>> + int (*read_array)(struct device *dev, const char *propname,
>> + enum dev_prop_type proptype, void *val, size_t nval);
>
>The associated DT functions that implement property reads
>(of_property_read_*) were created in part to provide some type safety
>when reading properties. This proposed API throws that away by accepting
>a void* for the data field, which I don't want to do. This API either
>needs to have a separate accessor for each data type, or it needs some
>other mechanism (accessor macros?) to ensure the right type is passed
>in.
OK, this would increase the memory impact by 6-fold for 8,16,32,and 64
byte integers, strings, and device references if additional typed function
pointers were added to the dev_prop_ops. The macros could mitigate this I
suppose.
Type checking and validation was something we had discussed as being
important to this mechanism. I believe there was some interest in seeing
this done at the ASL/FDT + Schema level - but that's not justification for
maintaining it in the kernel interface as well.
Could this be addressed by adding an enum dev_prop_type to the get/read
calls similar to that of the read_array call? That would keep the call
count down, maintain the smaller memory footprint, and still allow for
type verification within the device properties API.
--
Darren Hart Open Source Technology Center
darren.hart@xxxxxxxxx Intel Corporation
--
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
