iio: HID sensor time (as RTC)
Subsystems (4)
cover iio: HID sensor time (as RTC)
Hello,
the following 3 patches are neccessary to add a driver for (USB) HID sensors of type time (using hid-sensor-hub).
The driver implements a RTC, so the time will be available like from any other RTC.
Regards,
Alexander
PATCH 1/3 iio: hid-sensors: respect CONFIG_IIO_TRIGGER
Not much to say, without that change, hid-sensor-trigger will be always compiled if HID_SENSOR_IIO_COMMON is selected which fails if CONFIG_IIO_TRIGGER is not set because CONFIG_IIO_CONSUMERS_PER_TRIGGER will not be defined.
--- drivers/iio/accel/Kconfig | 1 + drivers/iio/common/hid-sensors/Makefile | 3 ++- drivers/iio/gyro/Kconfig | 1 + drivers/iio/light/Kconfig | 1 + drivers/iio/magnetometer/Kconfig | 1 + 5 files changed, 6 insertions(+), 1 deletions(-)
drivers/iio/accel/Kconfig +1 -0
@@ -8,6 +8,7 @@ config HID_SENSOR_ACCEL_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Acelerometers 3D" help Say yes here to build support for the HID SENSOR
drivers/iio/common/hid-sensors/Makefile +2 -1
@@ -3,4 +3,5 @@ # obj-$(CONFIG_HID_SENSOR_IIO_COMMON) += hid-sensor-iio-common.o -hid-sensor-iio-common-y := hid-sensor-attributes.o hid-sensor-trigger.o +obj-$(CONFIG_HID_SENSOR_IIO_TRIGGER) += hid-sensor-trigger.o +hid-sensor-iio-common-y := hid-sensor-attributes.o
drivers/iio/gyro/Kconfig +1 -0
@@ -8,6 +8,7 @@ config HID_SENSOR_GYRO_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Gyroscope 3D" help Say yes here to build support for the HID SENSOR
drivers/iio/light/Kconfig +1 -0
@@ -47,6 +47,7 @@ config HID_SENSOR_ALS select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID ALS" help Say yes here to build support for the HID SENSOR
drivers/iio/magnetometer/Kconfig +1 -0
@@ -8,6 +8,7 @@ config HID_SENSOR_MAGNETOMETER_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Magenetometer 3D" help Say yes here to build support for the HID SENSOR
Signature · 1 line
1.7.8.6
PATCH 2/3 iio: Add Usage IDs for HID time sensors.
In reply to Alexander HollerThese are Usage IDs for the attributes year, month, day, hour, minute and second, needed to read HID time sensors.
--- include/linux/hid-sensor-ids.h | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
include/linux/hid-sensor-ids.h +9 -0
@@ -66,6 +66,15 @@#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS 0x200486#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS 0x200487 +/* Time (2000a0) */ +#define HID_USAGE_SENSOR_TIME 0x2000a0 +#define HID_USAGE_SENSOR_TIME_YEAR 0x200521 +#define HID_USAGE_SENSOR_TIME_MONTH 0x200522 +#define HID_USAGE_SENSOR_TIME_DAY 0x200523 +#define HID_USAGE_SENSOR_TIME_HOUR 0x200525 +#define HID_USAGE_SENSOR_TIME_MINUTE 0x200526 +#define HID_USAGE_SENSOR_TIME_SECOND 0x200527 +/* Units */ #define HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED 0x00#define HID_USAGE_SENSOR_UNITS_LUX 0x01
Signature · 1 line
1.7.8.6
PATCH 3/3 iio: add rtc-driver for HID sensors of type time
In reply to Alexander HollerThis driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub.
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
--- drivers/iio/Kconfig | 1 + drivers/iio/Makefile | 1 + drivers/iio/time/Kconfig | 14 ++ drivers/iio/time/Makefile | 5 + drivers/iio/time/hid-sensor-time.c | 397 ++++++++++++++++++++++++++++++++++++ 5 files changed, 418 insertions(+), 0 deletions(-) create mode 100644 drivers/iio/time/Kconfig create mode 100644 drivers/iio/time/Makefile create mode 100644 drivers/iio/time/hid-sensor-time.c
drivers/iio/Kconfig +1 -0
@@ -63,5 +63,6 @@ source "drivers/iio/dac/Kconfig" source "drivers/iio/common/Kconfig" source "drivers/iio/gyro/Kconfig" source "drivers/iio/magnetometer/Kconfig" +source "drivers/iio/time/Kconfig" endif # IIO
drivers/iio/Makefile +1 -0
@@ -19,3 +19,4 @@ obj-y += dac/ obj-y += common/ obj-y += gyro/ obj-y += magnetometer/ +obj-y += time/
drivers/iio/time/Kconfig new file +14 -0
@@ -0,0 +1,14 @@ +# +# Time sensors +# +menu "Time sensors" + +config HID_SENSOR_TIME + depends on HID_SENSOR_HUB + select HID_SENSOR_IIO_COMMON + tristate "HID Time" + help + Say yes here to build support for the HID SENSOR Time. + This drivers makes such sensors available as RTCs. + +endmenu
drivers/iio/time/Makefile new file +5 -0
@@ -0,0 +1,5 @@ +# +# Makefile for industrial I/O Time sensor driver +# + +obj-$(CONFIG_HID_SENSOR_TIME) += hid-sensor-time.o
drivers/iio/time/hid-sensor-time.c new file +397 -0
397 lines not on this page · raw message
Signature · 1 line
1.7.8.6
Re: [PATCH 3/3] iio: add rtc-driver for HID sensors of type time
Quoted 7 lines · Alexander Holler
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub.
Quoted 5 lines
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
I don't think we should register a IIO device for this. Just an RTC device should be fully sufficient.
Quoted 467 lines
Signed-off-by Alexander Holler <[email protected]>--- drivers/iio/Kconfig | 1 + drivers/iio/Makefile | 1 + drivers/iio/time/Kconfig | 14 ++ drivers/iio/time/Makefile | 5 + drivers/iio/time/hid-sensor-time.c | 397 ++++++++++++++++++++++++++++++++++++ 5 files changed, 418 insertions(+), 0 deletions(-) create mode 100644 drivers/iio/time/Kconfig create mode 100644 drivers/iio/time/Makefile create mode 100644 drivers/iio/time/hid-sensor-time.cdrivers/iio/Kconfig +1
-0@@ -63,5 +63,6 @@ source "drivers/iio/dac/Kconfig" source "drivers/iio/common/Kconfig" source "drivers/iio/gyro/Kconfig" source "drivers/iio/magnetometer/Kconfig" +source "drivers/iio/time/Kconfig" endif # IIOdrivers/iio/Makefile +1
-0@@ -19,3 +19,4 @@ obj-y += dac/ obj-y += common/ obj-y += gyro/ obj-y += magnetometer/ +obj-y += time/drivers/iio/time/Kconfig new file +14
-0@@ -0,0 +1,14 @@ +# +# Time sensors +# +menu "Time sensors" + +config HID_SENSOR_TIME + depends on HID_SENSOR_HUB + select HID_SENSOR_IIO_COMMON + tristate "HID Time" + help + Say yes here to build support for the HID SENSOR Time. + This drivers makes such sensors available as RTCs. + +endmenudrivers/iio/time/Makefile new file +5
-0@@ -0,0 +1,5 @@ +# +# Makefile for industrial I/O Time sensor driver +# + +obj-$(CONFIG_HID_SENSOR_TIME) += hid-sensor-time.odrivers/iio/time/hid-sensor-time.c new file +397
-0@@ -0,0 +1,397 @@ +/* +* HID Sensor Time Driver +* Copyright (c) 2012, Alexander Holler. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms and conditions of the GNU General Public License, +* version 2, as published by the Free Software Foundation. +* +* This program is distributed in the hope it will be useful, but WITHOUT +* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for +* more details. +* +* You should have received a copy of the GNU General Public License along with +* this program; if not, write to the Free Software Foundation, Inc., +* 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. +* +*/ +#include <linux/device.h> +#include <linux/platform_device.h> +#include <linux/module.h> +#include <linux/hid-sensor-hub.h> +#include <linux/iio/iio.h> +#include <linux/rtc.h> +#include "../common/hid-sensors/hid-sensor-attributes.h" + +/* Format: HID-SENSOR-usage_id_in_hex */ +/* Usage ID from spec for Time: 0x2000A0 */ +#define DRIVER_NAME "HID-SENSOR-2000a0"/* must be lowercase */ + +enum hid_time_channel { +CHANNEL_SCAN_INDEX_YEAR , +CHANNEL_SCAN_INDEX_MONTH , +CHANNEL_SCAN_INDEX_DAY , +CHANNEL_SCAN_INDEX_HOUR , +CHANNEL_SCAN_INDEX_MINUTE , +CHANNEL_SCAN_INDEX_SECOND , +TIME_RTC_CHANNEL_MAX , +}; + +struct hid_time_state { +struct hid_sensor_hub_callbacks callbacks; +struct hid_sensor_iio_common common_attributes; +struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX ]; +struct rtc_time last_time; +spinlock_t lock_last_time; +struct completion comp_last_time; +struct rtc_time time_buf; +struct rtc_device *rtc; +}; + +static const u32 hid_time_addresses[TIME_RTC_CHANNEL_MAX ] = { +HID_USAGE_SENSOR_TIME_YEAR , +HID_USAGE_SENSOR_TIME_MONTH , +HID_USAGE_SENSOR_TIME_DAY , +HID_USAGE_SENSOR_TIME_HOUR , +HID_USAGE_SENSOR_TIME_MINUTE , +HID_USAGE_SENSOR_TIME_SECOND , +}; + +/* Channel definitions */ +static const struct iio_chan_spec hid_time_channels[TIME_RTC_CHANNEL_MAX ] = { + { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_YEAR , + .extend_name ="year" , + }, { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_MONTH , + .extend_name ="month" , + }, { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_DAY , + .extend_name ="day" , + }, { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_HOUR , + .extend_name ="hour" , + }, { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_MINUTE , + .extend_name ="minute" , + }, { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_SECOND , + .extend_name ="second" , + } +}; + +/* Adjust channel real bits based on report descriptor */ +static void hid_time_adjust_channel_bit_mask (struct iio_chan_spec *channels, +int channel,int size) +{ + channels[channel].scan_type.sign ='u' ; +/* Real storage bits will change based on the report desc. */ + channels[channel].scan_type.realbits = size *8 ; +/* Maximum size of a sample to capture is u8 */ + channels[channel].scan_type.storagebits =sizeof (u8) *8 ; +} + +static int hid_time_read_raw (struct iio_dev *indio_dev, +struct iio_chan_spec const *chan, +int *val,int *val2, +long mask) +{ +struct hid_time_state *time_state =iio_priv (indio_dev); +int report_id; +u32 address; + + *val =0 ; + *val2 =0 ; +if (mask) +return -EINVAL ; + report_id = time_state->info[chan->scan_index].report_id; + address = hid_time_addresses[chan->scan_index]; +if (report_id >=0 ) { + *val =sensor_hub_input_attr_get_raw_value ( + time_state->common_attributes.hsdev, +HID_USAGE_SENSOR_TIME , address, report_id); +return IIO_VAL_INT ; + } + *val =0 ; +return -EINVAL ; +} + +/* Callback handler to send event after all samples are received and captured */ +static int hid_time_proc_event (struct hid_sensor_hub_device *hsdev, +unsigned usage_id,void *priv) +{ +unsigned long flags; +struct iio_dev *indio_dev =platform_get_drvdata (priv); +struct hid_time_state *time_state =iio_priv (indio_dev); + +spin_lock_irqsave (&time_state->lock_last_time, flags); + time_state->last_time = time_state->time_buf; +spin_unlock_irqrestore (&time_state->lock_last_time, flags); +complete (&time_state->comp_last_time); +return 0 ; +} + +static int hid_time_capture_sample (struct hid_sensor_hub_device *hsdev, +unsigned usage_id,size_t raw_len, +char *raw_data,void *priv) +{ +struct iio_dev *indio_dev =platform_get_drvdata (priv); +struct hid_time_state *time_state =iio_priv (indio_dev); +struct rtc_time *time_buf = &time_state->time_buf; + +switch (usage_id) { +case HID_USAGE_SENSOR_TIME_YEAR : + time_buf->tm_year = *(u8 *)raw_data; +if (time_buf->tm_year <70 ) +/* assume we are in 1970...2069 */ + time_buf->tm_year +=100 ; +break ; +case HID_USAGE_SENSOR_TIME_MONTH : + time_buf->tm_mon = --*(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_DAY : + time_buf->tm_mday = *(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_HOUR : + time_buf->tm_hour = *(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_MINUTE : + time_buf->tm_min = *(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_SECOND : + time_buf->tm_sec = *(u8 *)raw_data; +break ; +default : +return -EINVAL ; + } +return 0 ; +} + +static int hid_time_parse_report (struct platform_device *pdev, +struct hid_sensor_hub_device *hsdev, +struct iio_chan_spec *channels, +unsigned usage_id,struct hid_time_state *st) +{ +int ret, i=0 ; + +for (; i <TIME_RTC_CHANNEL_MAX ; ++i) { + ret =sensor_hub_input_get_attribute_info (hsdev, +HID_INPUT_REPORT , usage_id, + hid_time_addresses[i], &st->info[i]); +if (ret <0 ) +return ret; +hid_time_adjust_channel_bit_mask (channels, i, + st->info[i].size); + } + +return ret; +} + +static int hid_rtc_read_time (struct device *dev, +struct rtc_time *tm) +{ +int val; +unsigned long flags; +struct iio_dev *indio_dev = +platform_get_drvdata (to_platform_device (dev)); +struct hid_time_state *time_state =iio_priv (indio_dev); + +init_completion (&time_state->comp_last_time); +/* start a read */ +if (hid_time_read_raw (indio_dev, + &hid_time_channels[0 ], &val, &val,0 ) == -EINVAL ) { +dev_err (dev,"unable to read time!\n" ); +return -EIO ; + } +/* wait for all values (event) */ +wait_for_completion_interruptible_timeout (&time_state->comp_last_time, +HZ *6 ); +spin_lock_irqsave (&time_state->lock_last_time, flags); + *tm = time_state->last_time; +spin_unlock_irqrestore (&time_state->lock_last_time, flags); + +return 0 ; +} + +/* small helper, haven't found any other way */ +static const char *attrib_name (u32 attrib_id) +{ +unsigned i=0 ; +static const char unknown[] ="unknown" ; + +for (; i<TIME_RTC_CHANNEL_MAX ; ++i) { +if (hid_time_addresses[i] == attrib_id) +return hid_time_channels[i].extend_name; + } +return unknown;/* should never happen */ +} + +static const struct iio_info hid_time_info = { + .driver_module =THIS_MODULE , + .read_raw = &hid_time_read_raw, +}; + +static const struct rtc_class_ops rtc_ops = { + .read_time = hid_rtc_read_time, +}; + +static int __devinit hid_time_probe (struct platform_device *pdev) +{ +int temp, ret =0 ; +static char *name ="hid_time" ; +struct hid_time_state *time_state; +struct iio_chan_spec *channels; +struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data; +struct iio_dev *indio_dev =iio_device_alloc (sizeof (struct hid_time_state )); + +if (indio_dev ==NULL ) { + ret = -ENOMEM ; + goto error_ret; + } +platform_set_drvdata (pdev, indio_dev); + + time_state =iio_priv (indio_dev); + time_state->common_attributes.hsdev = hsdev; + time_state->common_attributes.pdev = pdev; + + ret =hid_sensor_parse_common_attributes (hsdev, +HID_USAGE_SENSOR_TIME , + &time_state->common_attributes); +if (ret) { +dev_err (&pdev->dev,"failed to setup common attributes!\n" ); + goto error_free_dev; + } + + channels =kmemdup (hid_time_channels, +sizeof (hid_time_channels), +GFP_KERNEL ); +if (!channels) { +dev_err (&pdev->dev,"failed to duplicate channels!\n" ); + goto error_free_dev; + } + + ret =hid_time_parse_report (pdev, hsdev, channels, +HID_USAGE_SENSOR_TIME , time_state); +if (ret) { +dev_err (&pdev->dev,"failed to setup attributes!\n" ); + goto error_free_dev_mem; + } + +/* Check the attributes we need for sanity */ + temp = time_state->info[ret].report_id; +if (temp<0 ) { +dev_err (&pdev->dev,"bad report ID!\n" ); + goto error_free_dev_mem; + } +for (ret =0 ; ret<TIME_RTC_CHANNEL_MAX ; ++ret) { +if (time_state->info[ret].report_id != temp) { +dev_err (&pdev->dev, +"not all needed attributes inside the same report!\n" ); + goto error_free_dev_mem; + } +if (time_state->info[ret].size !=1 ) { +dev_err (&pdev->dev, +"attribute '%s' not 8 bits wide!\n" , +attrib_name (time_state->info[ret].attrib_id)); + goto error_free_dev_mem; + } +if (time_state->info[ret].units != +HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED && +/* allow attribute seconds with unit seconds */ + !(time_state->info[ret].attrib_id == +HID_USAGE_SENSOR_TIME_SECOND && + time_state->info[ret].units == +HID_USAGE_SENSOR_UNITS_SECOND )) { +dev_err (&pdev->dev, +"attribute '%s' hasn't a unit of type 'none'!\n" , +attrib_name (time_state->info[ret].attrib_id)); + goto error_free_dev_mem; + } +if (time_state->info[ret].unit_expo) { +dev_err (&pdev->dev, +"attribute '%s' hasn't a unit exponent of 1!\n" , +attrib_name (time_state->info[ret].attrib_id)); + goto error_free_dev_mem; + } + } + + indio_dev->channels = channels; + indio_dev->num_channels =ARRAY_SIZE (hid_time_channels); + indio_dev->dev.parent = &pdev->dev; + indio_dev->info = &hid_time_info; + indio_dev->name = name; + indio_dev->modes =INDIO_DIRECT_MODE ; + + ret =iio_device_register (indio_dev); +if (ret) { +dev_err (&pdev->dev,"device register failed!\n" ); + goto error_free_dev_mem; + } + + time_state->callbacks.send_event = hid_time_proc_event; + time_state->callbacks.capture_sample = hid_time_capture_sample; + time_state->callbacks.pdev = pdev; + ret =sensor_hub_register_callback (hsdev,HID_USAGE_SENSOR_TIME , + &time_state->callbacks); +if (ret <0 ) { +dev_err (&pdev->dev,"register callback failed!\n" ); + goto error_iio_unreg; + } + + time_state->rtc =rtc_device_register ("hid-sensor-time" , + &pdev->dev, &rtc_ops,THIS_MODULE ); + +if (IS_ERR (time_state->rtc)) { + ret =PTR_ERR (time_state->rtc); +dev_err (&pdev->dev,"rtc device register failed!\n" ); + goto error_iio_unreg; + } + +return ret; + +error_iio_unreg: +iio_device_unregister (indio_dev); +error_free_dev_mem: +kfree (indio_dev->channels); +error_free_dev: +iio_device_free (indio_dev); +error_ret: +return ret; +} + +static int __devinit hid_time_remove (struct platform_device *pdev) +{ +struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data; +struct iio_dev *indio_dev =platform_get_drvdata (pdev); +struct hid_time_state *time_state =iio_priv (indio_dev); + +if (!IS_ERR (time_state->rtc)) +rtc_device_unregister (time_state->rtc); +sensor_hub_remove_callback (hsdev,HID_USAGE_SENSOR_TIME ); +iio_device_unregister (indio_dev); +kfree (indio_dev->channels); +iio_device_free (indio_dev); + +return 0 ; +} + +static struct platform_driver hid_time_platform_driver = { + .driver = { + .name =DRIVER_NAME , + .owner =THIS_MODULE , + }, + .probe = hid_time_probe, + .remove = hid_time_remove, +}; +module_platform_driver (hid_time_platform_driver); + +MODULE_DESCRIPTION ("HID Sensor Time" ); +MODULE_AUTHOR ("Alexander Holler <[email protected]>" ); +MODULE_LICENSE ("GPL" );
Re: [PATCH 3/3] iio: add rtc-driver for HID sensors of type time
Am 09.12.2012 13:55, schrieb Lars-Peter Clausen:
Quoted 8 lines · Alexander Holler
Quoted 7 lines
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub.
Quoted 9 lines
Quoted 5 lines
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
I don't think we should register a IIO device for this. Just an RTC device should be fully sufficient.
You would have to implement all the used services hid-sensor-hub offers in the rtc-driver again.
Regards,
Alexander
Re: [PATCH 3/3] iio: add rtc-driver for HID sensors of type time
Am 09.12.2012 17:40, schrieb Alexander Holler:
Quoted 15 lines
Am 09.12.2012 13:55, schrieb Lars-Peter Clausen:
Quoted 14 lines · Alexander Holler
Quoted 12 lines
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub.
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Quoted 7 lines
Quoted 4 lines
I don't think we should register a IIO device for this. Just an RTC device
should be fully sufficient.You would have to implement all the used services hid-sensor-hub offers in the rtc-driver again.
Besides that, time is part of the spec for HID sensors, which makes sense. Making that available as a RTC to read/set the time is imho the best to way support that. If you want a driver which doesn't use the HID sensor hub framework (or iio), you would either have to define your own standard or make sure it is interoperable with the HID sensor hub framework, which might not be trivial.
Regards,
Alexander
Re: [PATCH 3/3] iio: add rtc-driver for HID sensors of type time
Quoted 24 lines · Alexander Holler
Am 09.12.2012 17:40, schrieb Alexander Holler:
Quoted 15 lines
Am 09.12.2012 13:55, schrieb Lars-Peter Clausen:
Quoted 14 lines · Alexander Holler
Quoted 12 lines
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub.
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Quoted 7 lines
Quoted 4 lines
I don't think we should register a IIO device for this. Just an RTC device
should be fully sufficient.You would have to implement all the used services hid-sensor-hub offers in the rtc-driver again.
Quoted 6 lines
Besides that, time is part of the spec for HID sensors, which makes sense. Making that available as a RTC to read/set the time is imho the best to way support that. If you want a driver which doesn't use the HID sensor hub framework (or iio), you would either have to define your own standard or make sure it is interoperable with the HID sensor hub framework, which might not be trivial.
I agree with what you wrote above. It just doesn't make sense to register a IIO device for a RTC type device. Just rip out all the IIO related bits from the driver and it will be fine.
- Lars
Re: [PATCH 3/3] iio: add rtc-driver for HID sensors of type time
Am 09.12.2012 20:20, schrieb Lars-Peter Clausen:
Quoted 3 lines
I agree with what you wrote above. It just doesn't make sense to register a IIO device for a RTC type device. Just rip out all the IIO related bits from the driver and it will be fine.
Ah, I misunderstood you. Yes, you are right. As I already have removed the buffer, trigger and the exposure of attributes in sysfs (the driver started as a copy from one of the other hid sensor drivers), the IIO device itself doesn't make sense anymore.
I will remove it.
Regards,
Alexander
PATCH v2 3/3 iio: add rtc-driver for HID sensors of type time
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub.
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
--- drivers/iio/Kconfig | 1 + drivers/iio/Makefile | 1 + drivers/iio/time/Kconfig | 14 ++ drivers/iio/time/Makefile | 5 + drivers/iio/time/hid-sensor-time.c | 346 ++++++++++++++++++++++++++++++++++++ 5 files changed, 367 insertions(+), 0 deletions(-) create mode 100644 drivers/iio/time/Kconfig create mode 100644 drivers/iio/time/Makefile create mode 100644 drivers/iio/time/hid-sensor-time.c
drivers/iio/Kconfig +1 -0
@@ -63,5 +63,6 @@ source "drivers/iio/dac/Kconfig" source "drivers/iio/common/Kconfig" source "drivers/iio/gyro/Kconfig" source "drivers/iio/magnetometer/Kconfig" +source "drivers/iio/time/Kconfig" endif # IIO
drivers/iio/Makefile +1 -0
@@ -19,3 +19,4 @@ obj-y += dac/ obj-y += common/ obj-y += gyro/ obj-y += magnetometer/ +obj-y += time/
drivers/iio/time/Kconfig new file +14 -0
@@ -0,0 +1,14 @@ +# +# Time sensors +# +menu "Time sensors" + +config HID_SENSOR_TIME + depends on HID_SENSOR_HUB + select HID_SENSOR_IIO_COMMON + tristate "HID Time" + help + Say yes here to build support for the HID SENSOR Time. + This drivers makes such sensors available as RTCs. + +endmenu
drivers/iio/time/Makefile new file +5 -0
@@ -0,0 +1,5 @@ +# +# Makefile for industrial I/O Time sensor driver +# + +obj-$(CONFIG_HID_SENSOR_TIME) += hid-sensor-time.o
drivers/iio/time/hid-sensor-time.c new file +346 -0
346 lines not on this page · raw message
Signature · 1 line
1.7.8.6
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Quoted 7 lines · Alexander Holler
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub.
Quoted 7 lines
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Signed-off-by Alexander Holler <[email protected]>
Looks pretty good now. But there are still some IIO remnants which should be removed as well. Also the driver should move to drivers/rtc/ since, well, it's a rtc driver not a IIO driver.
Quoted 6 lines
drivers/iio/time/hid-sensor-time.c new file +0
-0@@ -0,0 +1,346 @@
[...]
Quoted 19 lines
drivers/iio/time/hid-sensor-time.c new file +19
-0+ +/* Channel definitions */ +static const struct iio_chan_spec hid_time_channels[TIME_RTC_CHANNEL_MAX ] = { + { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_YEAR , + .extend_name ="year" , + }, { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_MONTH , + .extend_name ="month" , + }, { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_DAY , + .extend_name ="day" , + }, { + .info_mask =IIO_CHAN_INFO_RAW , + .scan_index =CHANNEL_SCAN_INDEX_HOUR , + .extend_name ="hour" ,
drivers/iio/time/hid-sensor-time.c line 88
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+ }, { + .info_mask = IIO_CHAN_INFO_RAW, + .scan_index = CHANNEL_SCAN_INDEX_MINUTE, + .extend_name = "minute", + }, { + .info_mask = IIO_CHAN_INFO_RAW, + .scan_index = CHANNEL_SCAN_INDEX_SECOND, + .extend_name = "second", + } +};
The channel spec is semi unused. You use it to lookup the scan index and the name, but that could easily be implemented without the channel spec. Especially considering that the scan index lookup is only ever done for channel 0, which will always return CHANNEL_SCAN_INDEX_YEAR.
Quoted 9 lines
drivers/iio/time/hid-sensor-time.c new file +9
-0+ +static int hid_time_read_raw (struct hid_time_state *time_state, +struct iio_chan_spec const *chan, +int *val,int *val2, +long mask) +{ +int report_id; +u32 address; +
drivers/iio/time/hid-sensor-time.c line 107
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+ *val =0 ; + *val2 =0 ; +if (mask) +return -EINVAL ; + report_id = time_state->info[chan->scan_index].report_id; + address = hid_time_addresses[chan->scan_index]; +if (report_id >=0 ) { + *val =sensor_hub_input_attr_get_raw_value ( + time_state->common_attributes.hsdev, +HID_USAGE_SENSOR_TIME , address, report_id);
Just directly call sensor_hub_input_attr_get_raw_value in hid_rtc_read_time instead of wrapping it here.
drivers/iio/time/hid-sensor-time.c line 113
Quoted 6 lines
drivers/iio/time/hid-sensor-time.c new file +6
-0+return IIO_VAL_INT ; + } + *val =0 ; +return -EINVAL ; +} +
[...]
Are the entries in info ordered in the same way as the addresses in hid_time_addresses? If yes you could just use a lookup-table like
static const char * const hid_time_attrib_names[] = {
"second",
...
};and just use 'i' to look them up.
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+static const char *attrib_name (u32 attrib_id) +{ +unsigned i =0 ; +static const char unknown[] ="unknown" ; + +for (; i <TIME_RTC_CHANNEL_MAX ; ++i) { +if (hid_time_addresses[i] == attrib_id) +return hid_time_channels[i].extend_name; + } +return unknown;/* should never happen */
drivers/iio/time/hid-sensor-time.c line 183
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+} + +static int hid_time_parse_report (struct platform_device *pdev, +struct hid_sensor_hub_device *hsdev, +unsigned usage_id, +struct hid_time_state *time_state) +{ +int ret, i =0 ; + +for (; i <TIME_RTC_CHANNEL_MAX ; ++i) {
I'd put the i = 0 in the for header.
drivers/iio/time/hid-sensor-time.c line 191
Quoted 8 lines
drivers/iio/time/hid-sensor-time.c new file +8
-0+ ret =sensor_hub_input_get_attribute_info (hsdev, +HID_INPUT_REPORT , usage_id, + hid_time_addresses[i], &time_state->info[i]); +if (ret <0 ) +return ret; + } +/* Check the (needed) attributes for sanity */ + ret = time_state->info[0 ].report_id;/* use ret as temp. */
maybe name it report_id instead of ret
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+if (ret <0 ) { +dev_err (&pdev->dev,"bad report ID!\n" ); +return -EINVAL ; + } +for (i =0 ; i <TIME_RTC_CHANNEL_MAX ; ++i) { +if (time_state->info[i].report_id != ret) { +dev_err (&pdev->dev, +"not all needed attributes inside the same report!\n" ); +return -EINVAL ; + }
[...]
Quoted 4 lines
drivers/iio/time/hid-sensor-time.c new file +4
-0+ } + +return 0 ; +}
drivers/iio/time/hid-sensor-time.c line 239
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+ +static int hid_rtc_read_time (struct device *dev, +struct rtc_time *tm) +{ +int val; +unsigned long flags; +struct hid_time_state *time_state = +platform_get_drvdata (to_platform_device (dev)); + +init_completion (&time_state->comp_last_time);
This needs to be INIT_COMPLETION. init_completion must be called exactly once on a completion, which should be from inside probe() in this case.
drivers/iio/time/hid-sensor-time.c line 248
Quoted 9 lines
drivers/iio/time/hid-sensor-time.c new file +9
-0+/* start a read */ +if (hid_time_read_raw (time_state, + &hid_time_channels[0 ], &val, &val,0 ) == -EINVAL ) { +dev_err (dev,"unable to read time!\n" ); +return -EIO ; + } +/* wait for all values (event) */ +wait_for_completion_interruptible_timeout (&time_state->comp_last_time, +HZ *6 );
You should check the return value in case either a timeout happens or the sleep is interrupted.
drivers/iio/time/hid-sensor-time.c line 260
Quoted 12 lines
drivers/iio/time/hid-sensor-time.c new file +12
-0+spin_lock_irqsave (&time_state->lock_last_time, flags); + *tm = time_state->last_time; +spin_unlock_irqrestore (&time_state->lock_last_time, flags); + +return 0 ; +} + +static const struct rtc_class_ops rtc_ops = { + .read_time = hid_rtc_read_time, +}; + +static int __devinit hid_time_probe (struct platform_device *pdev)
__devinit is going away, it shouldn't be used anymore in new drivers.
drivers/iio/time/hid-sensor-time.c line 265
Quoted 5 lines
drivers/iio/time/hid-sensor-time.c new file +5
-0+{ +int ret =0 ; +struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data; +struct hid_time_state *time_state = +kzalloc (sizeof (struct hid_time_state ),GFP_KERNEL );
You could use devm_kzalloc here. By doing so you don't have to take care of freeing it again since it will be auto-freed once the device is removed.
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+ +if (time_state ==NULL ) { + ret = -ENOMEM ; + goto error_ret; + } + +platform_set_drvdata (pdev, time_state); + + time_state->common_attributes.hsdev = hsdev; + time_state->common_attributes.pdev = pdev;
drivers/iio/time/hid-sensor-time.c line 285
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+ + ret =hid_sensor_parse_common_attributes (hsdev, +HID_USAGE_SENSOR_TIME , + &time_state->common_attributes); +if (ret) { +dev_err (&pdev->dev,"failed to setup common attributes!\n" ); + goto error_free_drvdata; + } + + ret = hid_time_parse_report(pdev, hsdev, /*channels,*/
remove the commented out code
Quoted 8 lines
drivers/iio/time/hid-sensor-time.c new file +8
-0+ HID_USAGE_SENSOR_TIME, time_state); +if (ret) { +dev_err (&pdev->dev,"failed to setup attributes!\n" ); + goto error_free_drvdata; + } + + time_state->callbacks.send_event = hid_time_proc_event; + time_state->callbacks.capture_sample = hid_time_capture_sample;
drivers/iio/time/hid-sensor-time.c line 303
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+ time_state->callbacks.pdev = pdev; + ret =sensor_hub_register_callback (hsdev,HID_USAGE_SENSOR_TIME , + &time_state->callbacks); +if (ret <0 ) { +dev_err (&pdev->dev,"register callback failed!\n" ); + goto error_free_drvdata; + } + + time_state->rtc =rtc_device_register ("hid-sensor-time" , + &pdev->dev, &rtc_ops,THIS_MODULE );
Since the driver does not do much if the rtc device could not be registered I think it should be ok to fail probe in case registering the rtc device fails.
drivers/iio/time/hid-sensor-time.c line 314
Quoted 11 lines
drivers/iio/time/hid-sensor-time.c new file +11
-0+ +if (IS_ERR (time_state->rtc)) { + ret =PTR_ERR (time_state->rtc); +dev_err (&pdev->dev,"rtc device register failed!\n" ); + goto error_free_drvdata; + } + +return ret; + +error_free_drvdata: +platform_set_drvdata (pdev,NULL );
Setting the platform data to NULL should not be necessary. Some drivers do this but it's kind of the result of cargo-cult-coding.
Quoted 4 lines
drivers/iio/time/hid-sensor-time.c new file +4
-0+kfree (time_state); +error_ret: +return ret; +}
drivers/iio/time/hid-sensor-time.c line 328
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+ +static int __devinit hid_time_remove (struct platform_device *pdev) +{ +struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data; +struct hid_time_state *time_state =platform_get_drvdata (pdev); + +if (!IS_ERR (time_state->rtc)) +rtc_device_unregister (time_state->rtc); +sensor_hub_remove_callback (hsdev,HID_USAGE_SENSOR_TIME ); +platform_set_drvdata (pdev,NULL );
Same here.
Quoted 5 lines
drivers/iio/time/hid-sensor-time.c new file +5
-0+kfree (time_state); + +return 0 ; +} +
[...]
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Am 10.12.2012 18:05, schrieb Lars-Peter Clausen:
Quoted 3 lines
Looks pretty good now. But there are still some IIO remnants which should be removed as well. Also the driver should move to
drivers/rtc/since, well, it's a rtc driver not a IIO driver.
I think it still should be stick to iio, because that is where all HID sensors currently are found and where the user would expect to find such a driver.
Quoted 2 lines
drivers/iio/time/hid-sensor-time.c line 62
Quoted 2 lines
drivers/iio/time/hid-sensor-time.c new file +2
-0+/* Channel definitions */ +static const struct iio_chan_spec hid_time_channels[TIME_RTC_CHANNEL_MAX ] = {
And that is imho the last remaining iio-stuff. If necessary I can remove it too.
Regards,
Alexander
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Quoted 9 lines · Alexander Holler
Am 10.12.2012 18:05, schrieb Lars-Peter Clausen:
Quoted 3 lines
Looks pretty good now. But there are still some IIO remnants which should be removed as well. Also the driver should move to
drivers/rtc/since, well, it's a rtc driver not a IIO driver.I think it still should be stick to iio, because that is where all HID sensors currently are found and where the user would expect to find such a driver.
That's because all the current IIO sensor drivers fall in the IIO domain. This one clearly is a RTC driver, so it belongs in drivers/rtc/
Quoted 6 lines
Quoted 3 lines
drivers/iio/time/hid-sensor-time.c line 62
Quoted 3 lines
drivers/iio/time/hid-sensor-time.c new file +2
-0+/* Channel definitions */ +static const struct iio_chan_spec hid_time_channels[TIME_RTC_CHANNEL_MAX ] = {And that is imho the last remaining iio-stuff. If necessary I can remove it too.
That and the remaining bits of the read_raw callback.
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Am 10.12.2012 21:22, schrieb Lars-Peter Clausen:
Quoted 7 lines · Alexander Holler
Quoted 6 lines
Am 10.12.2012 18:05, schrieb Lars-Peter Clausen:
Quoted 3 lines
Looks pretty good now. But there are still some IIO remnants which should be removed as well. Also the driver should move to
drivers/rtc/since, well, it's a rtc driver not a IIO driver.
Quoted 6 lines
Quoted 3 lines
I think it still should be stick to iio, because that is where all HID sensors currently are found and where the user would expect to find such a driver.
That's because all the current IIO sensor drivers fall in the IIO domain. This one clearly is a RTC driver, so it belongs in
drivers/rtc/
Where nobody will find it if he searches for drivers for his HID sensor. I still see it as HID sensor driver and not a rtc-driver. But ...
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
drivers/iio/time/hid-sensor-time.c line 62
Quoted 4 lines
drivers/iio/time/hid-sensor-time.c new file +2
-0+/* Channel definitions */ +static const struct iio_chan_spec hid_time_channels[TIME_RTC_CHANNEL_MAX ] = {And that is imho the last remaining iio-stuff. If necessary I can remove it too.
That and the remaining bits of the
read_rawcallback.
Ok. I will make a v3.
Alexander
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Quoted 12 lines · Alexander Holler
Am 10.12.2012 21:22, schrieb Lars-Peter Clausen:
Quoted 11 lines · Alexander Holler
Quoted 9 lines
Am 10.12.2012 18:05, schrieb Lars-Peter Clausen:
Quoted 3 lines
Looks pretty good now. But there are still some IIO remnants which should be removed as well. Also the driver should move to
drivers/rtc/since, well, it's a rtc driver not a IIO driver.I think it still should be stick to iio, because that is where all HID sensors currently are found and where the user would expect to find such a driver.
Quoted 6 lines
Quoted 2 lines
That's because all the current IIO sensor drivers fall in the IIO domain. This one clearly is a RTC driver, so it belongs in
drivers/rtc/Where nobody will find it if he searches for drivers for his HID sensor. I still see it as HID sensor driver and not a rtc-driver. But ...
I can understand your position, but drivers are usually grouped by function not by topology. If there is a proper Kconfig help text people should hopefully be find it.
Quoted 9 lines
Quoted 9 lines
Quoted 8 lines
Quoted 5 lines
drivers/iio/time/hid-sensor-time.c line 62
Quoted 5 lines
drivers/iio/time/hid-sensor-time.c new file +2
-0+/* Channel definitions */ +static const struct iio_chan_spec hid_time_channels[TIME_RTC_CHANNEL_MAX ] = {And that is imho the last remaining iio-stuff. If necessary I can remove it too.
Quoted 4 lines
Quoted 1 line
That and the remaining bits of the
read_rawcallback.Ok. I will make a v3.
Btw. have you seen the other comments I had inline in my response to your v2?
Jonathan Cameron
maintainerRe: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Quoted 16 lines · Lars-Peter Clausen
Quoted 15 lines · Alexander Holler
Am 10.12.2012 21:22, schrieb Lars-Peter Clausen:
Quoted 13 lines · Alexander Holler
Quoted 9 lines
Am 10.12.2012 18:05, schrieb Lars-Peter Clausen:
Quoted 3 lines
Looks pretty good now. But there are still some IIO remnants which should be removed as well. Also the driver should move to
drivers/rtc/since, well, it's a rtc driver not a IIO driver.I think it still should be stick to iio, because that is where all HID sensors currently are found and where the user would expect to find such a driver.
That's because all the current IIO sensor drivers fall in the IIO domain. This one clearly is a RTC driver, so it belongs in
drivers/rtc/
Quoted 7 lines
Quoted 3 lines
Where nobody will find it if he searches for drivers for his HID sensor. I still see it as HID sensor driver and not a rtc-driver. But ...
I can understand your position, but drivers are usually grouped by function not by topology. If there is a proper
Kconfighelp text people should hopefully be find it.
Seconded on this. If it is a pure rtc driver then it definitely belongs in drivers/rtc. Now there might have been ways of doing this as a consumer / provider with the provider being in IIO and the consumer in rtc, but that sounds like it is over compicating things, at least for now.
Quoted 21 lines
Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines
drivers/iio/time/hid-sensor-time.c line 62
Quoted 6 lines
drivers/iio/time/hid-sensor-time.c new file +2
-0+/* Channel definitions */ +static const struct iio_chan_spec hid_time_channels[TIME_RTC_CHANNEL_MAX ] = {And that is imho the last remaining iio-stuff. If necessary I can remove it too.
Quoted 4 lines
Quoted 1 line
That and the remaining bits of the
read_rawcallback.Ok. I will make a v3.
Btw. have you seen the other comments I had inline in my response to your v2? --
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Am 10.12.2012 22:42, schrieb Jonathan Cameron:
Quoted 21 lines · Lars-Peter Clausen
Quoted 20 lines · Alexander Holler
Quoted 18 lines
Am 10.12.2012 21:22, schrieb Lars-Peter Clausen:
Quoted 7 lines · Alexander Holler
Quoted 6 lines
Am 10.12.2012 18:05, schrieb Lars-Peter Clausen:
Quoted 3 lines
Looks pretty good now. But there are still some IIO remnants which should be removed as well. Also the driver should move to
drivers/rtc/since, well, it's a rtc driver not a IIO driver.Quoted 6 lines
Quoted 3 lines
I think it still should be stick to iio, because that is where all HID sensors currently are found and where the user would expect to find such a driver.
That's because all the current IIO sensor drivers fall in the IIO domain. This one clearly is a RTC driver, so it belongs in
drivers/rtc/Where nobody will find it if he searches for drivers for his HID sensor. I still see it as HID sensor driver and not a rtc-driver. But ...
Quoted 7 lines
Quoted 3 lines
I can understand your position, but drivers are usually grouped by function not by topology. If there is a proper
Kconfighelp text people should hopefully be find it.Seconded on this. If it is a pure rtc driver then it definitely belongs in
drivers/rtc. Now there might have been ways of doing this as a consumer / provider with the provider being in IIO and the consumer in rtc, but that sounds like it is over compicating things, at least for now.
Personally I just want to use it to have HID-USB_RTCs. ;)
But in case of HID sensor hubs, the main usage of that driver will be to set the time of such hubs (something I still have to make patches for), and not to read it. So if you think as an HID sensor user, it should belong to iio or wherever those sensor will finally end up (I think they should end up in HID and should be usable by bluetooth devices too), but if you creatively misuse the standard to get a driver for USB-RTCs, as I want, then rtc is the correct place. ;)
Because I don't want to do a v4:
the driver has an
#include "../common/hid-sensors/hid-sensor-attributes.h"
so moving it to drivers/rtc/ will make that even more ugly.
Suggestions? I don't really care and as I'm currently at the order receiving end ;) I would change it to whatever the maintainers are wanting. Maybe moving that header to include/linux or even integrating it into include/linux/hid-sensor-hubs.h makes sense.
Regards,
Alexander
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Quoted 43 lines · Alexander Holler
Am 10.12.2012 22:42, schrieb Jonathan Cameron:
Quoted 32 lines · Lars-Peter Clausen
Quoted 26 lines · Alexander Holler
Quoted 16 lines
Am 10.12.2012 21:22, schrieb Lars-Peter Clausen:
Quoted 15 lines · Alexander Holler
Quoted 13 lines
Am 10.12.2012 18:05, schrieb Lars-Peter Clausen:
Quoted 5 lines
Looks pretty good now. But there are still some IIO remnants which should be
removed as well. Also the driver should move todrivers/rtc/since, well,
it's a rtc driver not a IIO driver.I think it still should be stick to iio, because that is where all HID
sensors currently are found and where the user would expect to find such
a driver.Quoted 8 lines
Quoted 3 lines
That's because all the current IIO sensor drivers fall in the IIO domain. This
one clearly is a RTC driver, so it belongs indrivers/rtc/Where nobody will find it if he searches for drivers for his HID sensor.
I still see it as HID sensor driver and not a rtc-driver. But ...Quoted 5 lines
I can understand your position, but drivers are usually grouped by function not
by topology. If there is a properKconfighelp text people should hopefully be
find it.Quoted 7 lines
Seconded on this. If it is a pure rtc driver then it definitely belongs in
drivers/rtc. Now there might have been ways of doing this as a consumer / provider
with the provider being in IIO and the consumer in rtc, but that sounds like
it is over compicating things, at least for now.Personally I just want to use it to have HID-USB_RTCs. ;)
Quoted 7 lines
But in case of HID sensor hubs, the main usage of that driver will be to set the time of such hubs (something I still have to make patches for), and not to read it. So if you think as an HID sensor user, it should belong to iio or wherever those sensor will finally end up (I think they should end up in HID and should be usable by bluetooth devices too), but if you creatively misuse the standard to get a driver for USB-RTCs, as I want, then rtc is the correct place. ;)
I did wonder what you were up to ;)
Quoted 7 lines
Because I don't want to do a v4:
the driver has an
#include "
../common/hid-sensors/hid-sensor-attributes.h"
Quoted 7 lines
so moving it to
drivers/rtc/will make that even more ugly.Suggestions? I don't really care and as I'm currently at the order receiving end ;) I would change it to whatever the maintainers are wanting. Maybe moving that header to
include/linuxor even integrating it intoinclude/linux/hid-sensor-hubs.hmakes sense.
Yes, move the header or merge into existing one as makes sense. I'm not pulling this driver into the IIO tree (unless for some reason Alessandro wants me to and I can't think why he would...).
Quoted 4 lines
Regards,
Alexander
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Quoted 62 lines · Jonathan Cameron
Quoted 43 lines · Alexander Holler
Am 10.12.2012 22:42, schrieb Jonathan Cameron:
Quoted 32 lines · Lars-Peter Clausen
Quoted 26 lines · Alexander Holler
Quoted 16 lines
Am 10.12.2012 21:22, schrieb Lars-Peter Clausen:
Quoted 15 lines · Alexander Holler
Quoted 13 lines
Am 10.12.2012 18:05, schrieb Lars-Peter Clausen:
Quoted 5 lines
Looks pretty good now. But there are still some IIO remnants which should be
removed as well. Also the driver should move todrivers/rtc/since, well,
it's a rtc driver not a IIO driver.I think it still should be stick to iio, because that is where all HID
sensors currently are found and where the user would expect to find such
a driver.Quoted 8 lines
Quoted 3 lines
That's because all the current IIO sensor drivers fall in the IIO domain. This
one clearly is a RTC driver, so it belongs indrivers/rtc/Where nobody will find it if he searches for drivers for his HID sensor.
I still see it as HID sensor driver and not a rtc-driver. But ...Quoted 5 lines
I can understand your position, but drivers are usually grouped by function not
by topology. If there is a properKconfighelp text people should hopefully be
find it.Quoted 7 lines
Seconded on this. If it is a pure rtc driver then it definitely belongs in
drivers/rtc. Now there might have been ways of doing this as a consumer / provider
with the provider being in IIO and the consumer in rtc, but that sounds like
it is over compicating things, at least for now.Personally I just want to use it to have HID-USB_RTCs. ;)
Quoted 7 lines
But in case of HID sensor hubs, the main usage of that driver will be to set the time of such hubs (something I still have to make patches for), and not to read it. So if you think as an HID sensor user, it should belong to iio or wherever those sensor will finally end up (I think they should end up in HID and should be usable by bluetooth devices too), but if you creatively misuse the standard to get a driver for USB-RTCs, as I want, then rtc is the correct place. ;)
I did wonder what you were up to ;)
Quoted 9 lines
Because I don't want to do a v4:
the driver has an
#include "
../common/hid-sensors/hid-sensor-attributes.h"so moving it to
drivers/rtc/will make that even more ugly.
Quoted 8 lines
Quoted 4 lines
Suggestions? I don't really care and as I'm currently at the order receiving end ;) I would change it to whatever the maintainers are wanting. Maybe moving that header to
include/linuxor even integrating it intoinclude/linux/hid-sensor-hubs.hmakes sense.Yes, move the header or merge into existing one as makes sense. I'm not pulling this driver into the IIO tree (unless for some reason Alessandro wants me to and I can't think why he would...).
Alessandro has been pretty quiet for quite some time now. Luckily Andrew Morton usually picks up the stuff for orphaned subsystems. So put him on Cc for v4.
- Lars
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Am 11.12.2012 10:40, schrieb Lars-Peter Clausen:
Quoted 8 lines
Quoted 4 lines
Yes, move the header or merge into existing one as makes sense. I'm not pulling this driver into the IIO tree (unless for some reason Alessandro wants me to and I can't think why he would...).
Alessandro has been pretty quiet for quite some time now. Luckily Andrew Morton usually picks up the stuff for orphaned subsystems. So put him on Cc for v4.
Will do it. Thanks a lot for your review.
I willl post the whole series (4 patches including the merge of hid-sensor-attributes.h) again, when I've finished v3 of the driver (hopefully this evening), marking some patches as RESEND. So 3 out of those 4 patches will be for iio (as hid-sensor-hub is part of it), and the last one, the rtc driver itself, will be for the rtc subsystem. I don't know if they have to be pulled by different maintainers. ;)
Regards,
Alexander
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Quoted 21 lines · Alexander Holler
Am 11.12.2012 10:40, schrieb Lars-Peter Clausen:
Quoted 9 lines
Quoted 4 lines
Yes, move the header or merge into existing one as makes sense. I'm not pulling this driver into the IIO tree (unless for some reason Alessandro wants me to and I can't think why he would...).
Alessandro has been pretty quiet for quite some time now. Luckily Andrew Morton usually picks up the stuff for orphaned subsystems. So put him on Cc
for v4.Will do it. Thanks a lot for your review.
I willl post the whole series (4 patches including the merge of
hid-sensor-attributes.h) again, when I've finished v3 of the driver (hopefully this evening), marking some patches as RESEND. So 3 out of those 4 patches will be for iio (as hid-sensor-hub is part of it), and the last one, the rtc driver itself, will be for the rtc subsystem. I don't know if they have to be pulled by different maintainers. ;)
Quoted 3 lines
Regards,
Alexander
We'll see what Andrew says. We can take the lot through IIO (doubt Greg will mind) as long as we have the correct acks to do so (or at least statements of not caring ;)
PATCH v2 1/4 iio: hid-sensors: respect CONFIG_IIO_TRIGGER
Not much to say, without that change, hid-sensor-trigger will be always compiled if HID_SENSOR_IIO_COMMON is selected which fails if CONFIG_IIO_TRIGGER is not set because CONFIG_IIO_CONSUMERS_PER_TRIGGER will not be defined.
--- drivers/iio/accel/Kconfig | 1 + drivers/iio/common/hid-sensors/Kconfig | 13 ++++++++++++- drivers/iio/common/hid-sensors/Makefile | 3 ++- drivers/iio/gyro/Kconfig | 1 + drivers/iio/light/Kconfig | 1 + drivers/iio/magnetometer/Kconfig | 1 + 6 files changed, 18 insertions(+), 2 deletions(-)
drivers/iio/accel/Kconfig +1 -0
@@ -8,6 +8,7 @@ config HID_SENSOR_ACCEL_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Acelerometers 3D" help Say yes here to build support for the HID SENSOR
drivers/iio/common/hid-sensors/Kconfig +12 -1
@@ -6,7 +6,7 @@ menu "Hid Sensor IIO Common" config HID_SENSOR_IIO_COMMON tristate "Common modules for all HID Sensor IIO drivers" depends on HID_SENSOR_HUB - select IIO_TRIGGER if IIO_BUFFER + select HID_SENSOR_IIO_TRIGGER if IIO_BUFFER help Say yes here to build support for HID sensor to use HID sensor common processing for attributes and IIO triggers.
@@ -14,6 +14,17 @@ config HID_SENSOR_IIO_COMMON HID sensor drivers, this module contains processing for those attributes. +config HID_SENSOR_IIO_TRIGGER + tristate "Common module (trigger) for all HID Sensor IIO drivers" + depends on HID_SENSOR_HUB && HID_SENSOR_IIO_COMMON + select IIO_TRIGGER + help + Say yes here to build trigger support for HID sensors. + Triggers will be send if all requested attributes were read. + + If this driver is compiled as a module, it will be named + hid-sensor-trigger. + config HID_SENSOR_ENUM_BASE_QUIRKS tristate "ENUM base quirks for HID Sensor IIO drivers" depends on HID_SENSOR_IIO_COMMON
drivers/iio/common/hid-sensors/Makefile +2 -1
@@ -3,4 +3,5 @@ # obj-$(CONFIG_HID_SENSOR_IIO_COMMON) += hid-sensor-iio-common.o -hid-sensor-iio-common-y := hid-sensor-attributes.o hid-sensor-trigger.o +obj-$(CONFIG_HID_SENSOR_IIO_TRIGGER) += hid-sensor-trigger.o +hid-sensor-iio-common-y := hid-sensor-attributes.o
drivers/iio/gyro/Kconfig +1 -0
@@ -8,6 +8,7 @@ config HID_SENSOR_GYRO_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Gyroscope 3D" help Say yes here to build support for the HID SENSOR
drivers/iio/light/Kconfig +1 -0
@@ -47,6 +47,7 @@ config HID_SENSOR_ALS select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID ALS" help Say yes here to build support for the HID SENSOR
drivers/iio/magnetometer/Kconfig +1 -0
@@ -8,6 +8,7 @@ config HID_SENSOR_MAGNETOMETER_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Magenetometer 3D" help Say yes here to build support for the HID SENSOR
Signature · 1 line
1.7.8.6
PATCH RESEND 2/4 iio: Add Usage IDs for HID time sensors.
These are Usage IDs for the attributes year, month, day, hour, minute and second, needed to read HID time sensors.
--- include/linux/hid-sensor-ids.h | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
include/linux/hid-sensor-ids.h +9 -0
@@ -67,6 +67,15 @@#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS 0x200486#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS 0x200487 +/* Time (2000a0) */ +#define HID_USAGE_SENSOR_TIME 0x2000a0 +#define HID_USAGE_SENSOR_TIME_YEAR 0x200521 +#define HID_USAGE_SENSOR_TIME_MONTH 0x200522 +#define HID_USAGE_SENSOR_TIME_DAY 0x200523 +#define HID_USAGE_SENSOR_TIME_HOUR 0x200525 +#define HID_USAGE_SENSOR_TIME_MINUTE 0x200526 +#define HID_USAGE_SENSOR_TIME_SECOND 0x200527 +/* Units */ #define HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED 0x00#define HID_USAGE_SENSOR_UNITS_LUX 0x01
Signature · 1 line
1.7.8.6
Jonathan Cameron
maintainerRe: [PATCH 2/4 RESEND] iio: Add Usage IDs for HID time sensors.
Quoted 4 lines · Alexander Holler
These are Usage IDs for the attributes year, month, day, hour, minute and second, needed to read HID time sensors.
Signed-off-by Alexander Holler <[email protected]>
This has gotten very messy to follow. Could you resend the patches (without the first) with Jiri cc'd as well (as some of this is in his domain as HID maintainer).
Given this makes quite a few changes in IIO drivers I'm happy to take the lot through the IIO tree but to do that I would like a go ahead from Jiri + either Andrew or Alessandro (for rtc side of things).
Alexander, you need to be careful with multi subsystem patches like these to ensure everyone relevant is in the cc list.
Quoted 25 lines
--- include/linux/hid-sensor-ids.h | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)include/linux/hid-sensor-ids.h +9
-0@@ -67,6 +67,15 @@#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS 0x200486#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS 0x200487 +/* Time (2000a0) */ +#define HID_USAGE_SENSOR_TIME 0x2000a0 +#define HID_USAGE_SENSOR_TIME_YEAR 0x200521 +#define HID_USAGE_SENSOR_TIME_MONTH 0x200522 +#define HID_USAGE_SENSOR_TIME_DAY 0x200523 +#define HID_USAGE_SENSOR_TIME_HOUR 0x200525 +#define HID_USAGE_SENSOR_TIME_MINUTE 0x200526 +#define HID_USAGE_SENSOR_TIME_SECOND 0x200527 +/* Units */ #define HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED 0x00#define HID_USAGE_SENSOR_UNITS_LUX 0x01
Re: [PATCH 2/4 RESEND] iio: Add Usage IDs for HID time sensors.
Am 15.12.2012 12:06, schrieb Jonathan Cameron:
Quoted 6 lines · Alexander Holler
Quoted 4 lines
These are Usage IDs for the attributes year, month, day, hour, minute and second, needed to read HID time sensors.
Signed-off-by Alexander Holler <[email protected]>This has gotten very messy to follow. Could you resend the
I aggree. The workflow (ping-pong until a patch is almost perfect, without typos and style glitches and makes the maintainers eyes happy) is horrible and requires quite a lot goodwill and patience on every side. Not the stuff people like to do on a voluntarily basis.
So thanks to everyone who still follows.
The whole series (now 5 patches) follows. I mark all of them as RESEND to indicate that no changes were done since I've send them the last time.
Quoted 2 lines
patches (without the first) with Jiri cc'd as well (as some of this is in his domain as HID maintainer).
Sorry, almost the whole series (5-1 = 4) follows. ;)
Quoted 5 lines
Given this makes quite a few changes in IIO drivers I'm happy to take the lot through the IIO tree but to do that I would like a go ahead from Jiri + either Andrew or Alessandro (for rtc side of things).
Thanks again.
Alexander
PATCH RESEND 1/4 iio: Add Usage IDs for HID time sensors.
These are Usage IDs for the attributes year, month, day, hour, minute and second, needed to read HID time sensors.
--- include/linux/hid-sensor-ids.h | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
include/linux/hid-sensor-ids.h +9 -0
@@ -67,6 +67,15 @@#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS 0x200486#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS 0x200487 +/* Time (2000a0) */ +#define HID_USAGE_SENSOR_TIME 0x2000a0 +#define HID_USAGE_SENSOR_TIME_YEAR 0x200521 +#define HID_USAGE_SENSOR_TIME_MONTH 0x200522 +#define HID_USAGE_SENSOR_TIME_DAY 0x200523 +#define HID_USAGE_SENSOR_TIME_HOUR 0x200525 +#define HID_USAGE_SENSOR_TIME_MINUTE 0x200526 +#define HID_USAGE_SENSOR_TIME_SECOND 0x200527 +/* Units */ #define HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED 0x00#define HID_USAGE_SENSOR_UNITS_LUX 0x01
Signature · 1 line
1.7.8.6
PATCH RESEND 2/4 iio: merge hid-sensor-attributes.h into hid-sensor-hub.h
The stuff in hid-sensor-attributes.h is needed by every piece which uses hid-sensor-hub and merging it into hid-sensor-hub.h makes it accessible from outside the iio subdirectory.
--- drivers/iio/accel/hid-sensor-accel-3d.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.h | 57 -------------------- .../iio/common/hid-sensors/hid-sensor-trigger.c | 1 - drivers/iio/gyro/hid-sensor-gyro-3d.c | 1 - drivers/iio/light/hid-sensor-als.c | 1 - drivers/iio/magnetometer/hid-sensor-magn-3d.c | 1 - include/linux/hid-sensor-hub.h | 38 +++++++++++++ 8 files changed, 38 insertions(+), 63 deletions(-) delete mode 100644 drivers/iio/common/hid-sensors/hid-sensor-attributes.h
drivers/iio/accel/hid-sensor-accel-3d.c +0 -1
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
drivers/iio/common/hid-sensors/hid-sensor-attributes.c +0 -1
@@ -25,7 +25,6 @@#include <linux/hid-sensor-hub.h> #include <linux/iio/iio.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" static int pow_10 (unsigned power) {
drivers/iio/common/hid-sensors/hid-sensor-attributes.h deleted +0 -57
57 lines not on this page · raw message
drivers/iio/common/hid-sensors/hid-sensor-trigger.c +0 -1
@@ -26,7 +26,6 @@#include <linux/iio/iio.h> #include <linux/iio/trigger.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" #include "hid-sensor-trigger.h" static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,
drivers/iio/gyro/hid-sensor-gyro-3d.c +0 -1
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
drivers/iio/light/hid-sensor-als.c +0 -1
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
drivers/iio/magnetometer/hid-sensor-magn-3d.c +0 -1
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
include/linux/hid-sensor-hub.h +38 -0
@@ -157,4 +157,42 @@ int sensor_hub_set_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,*/ int sensor_hub_get_feature (struct hid_sensor_hub_device *hsdev,u32 report_id,u32 field_index,s32 *value); + +/* hid-sensor-attributes */ + +/* Common hid sensor iio structure */ +struct hid_sensor_iio_common { +struct hid_sensor_hub_device *hsdev; +struct platform_device *pdev; +unsigned usage_id; +bool data_ready; +struct hid_sensor_hub_attribute_info poll; +struct hid_sensor_hub_attribute_info report_state; +struct hid_sensor_hub_attribute_info power_state; +struct hid_sensor_hub_attribute_info sensitivity; +}; + +/*Convert from hid unit expo to regular exponent*/ +static inline int hid_sensor_convert_exponent (int unit_expo) +{ +if (unit_expo <0x08 ) +return unit_expo; +else if (unit_expo <=0x0f ) +return -(0x0f -unit_expo+1 ); +else +return 0 ; +} + +int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev, +u32 usage_id, +struct hid_sensor_iio_common *st); +int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +int val1,int val2); +int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int *val1,int *val2); +int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int val1,int val2); +int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int *val1,int *val2); +#endif
Signature · 1 line
1.7.8.6
Re: [PATCH 2/4 RESEND] iio: merge hid-sensor-attributes.h into hid-sensor-hub.h
Quoted 5 lines · Alexander Holler
The stuff in
hid-sensor-attributes.his needed by every piece which uses hid-sensor-hub and merging it intohid-sensor-hub.hmakes it accessible from outside the iio subdirectory.Signed-off-by Alexander Holler <[email protected]>
Quoted 197 lines
--- drivers/iio/accel/hid-sensor-accel-3d.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.h | 57 -------------------- .../iio/common/hid-sensors/hid-sensor-trigger.c | 1 - drivers/iio/gyro/hid-sensor-gyro-3d.c | 1 - drivers/iio/light/hid-sensor-als.c | 1 - drivers/iio/magnetometer/hid-sensor-magn-3d.c | 1 - include/linux/hid-sensor-hub.h | 38 +++++++++++++ 8 files changed, 38 insertions(+), 63 deletions(-) delete mode 100644 drivers/iio/common/hid-sensors/hid-sensor-attributes.hdrivers/iio/accel/hid-sensor-accel-3d.c +0
-1@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/ drivers/iio/common/hid-sensors/hid-sensor-attributes.c +0
-1@@ -25,7 +25,6 @@#include <linux/hid-sensor-hub.h> #include <linux/iio/iio.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" static int pow_10 (unsigned power) {drivers/iio/common/hid-sensors/hid-sensor-attributes.h deleted +0
-57@@ -1,57 +0,0 @@ -/* -* HID Sensors Driver -* Copyright (c) 2012, Intel Corporation. -* -* This program is free software; you can redistribute it and/or modify it -* under the terms and conditions of the GNU General Public License, -* version 2, as published by the Free Software Foundation. -* -* This program is distributed in the hope it will be useful, but WITHOUT -* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or -* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for -* more details. -* -* You should have received a copy of the GNU General Public License along with -* this program; if not, write to the Free Software Foundation, Inc., -* 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. -* -*/ -#ifndef _HID_SENSORS_ATTRIBUTES_H -#define _HID_SENSORS_ATTRIBUTES_H - -/* Common hid sensor iio structure */ -struct hid_sensor_iio_common { -struct hid_sensor_hub_device *hsdev; -struct platform_device *pdev; -unsigned usage_id; -bool data_ready; -struct hid_sensor_hub_attribute_info poll; -struct hid_sensor_hub_attribute_info report_state; -struct hid_sensor_hub_attribute_info power_state; -struct hid_sensor_hub_attribute_info sensitivity; -}; - -/*Convert from hid unit expo to regular exponent*/ -static inline int hid_sensor_convert_exponent (int unit_expo) -{ -if (unit_expo <0x08 ) -return unit_expo; -else if (unit_expo <=0x0f ) -return -(0x0f -unit_expo+1 ); -else -return 0 ; -} - -int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev, -u32 usage_id, -struct hid_sensor_iio_common *st); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, -int val1,int val2); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, -int *val1,int *val2); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, -int val1,int val2); -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, -int *val1,int *val2); - -#endif drivers/iio/common/hid-sensors/hid-sensor-trigger.c +0
-1@@ -26,7 +26,6 @@#include <linux/iio/iio.h> #include <linux/iio/trigger.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" #include "hid-sensor-trigger.h" static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,drivers/iio/gyro/hid-sensor-gyro-3d.c +0
-1@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/ drivers/iio/light/hid-sensor-als.c +0
-1@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/ drivers/iio/magnetometer/hid-sensor-magn-3d.c +0
-1@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/ include/linux/hid-sensor-hub.h +38
-0@@ -157,4 +157,42 @@ int sensor_hub_set_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,*/ int sensor_hub_get_feature (struct hid_sensor_hub_device *hsdev,u32 report_id,u32 field_index,s32 *value); + +/* hid-sensor-attributes */ + +/* Common hid sensor iio structure */ +struct hid_sensor_iio_common { +struct hid_sensor_hub_device *hsdev; +struct platform_device *pdev; +unsigned usage_id; +bool data_ready; +struct hid_sensor_hub_attribute_info poll; +struct hid_sensor_hub_attribute_info report_state; +struct hid_sensor_hub_attribute_info power_state; +struct hid_sensor_hub_attribute_info sensitivity; +}; + +/*Convert from hid unit expo to regular exponent*/ +static inline int hid_sensor_convert_exponent (int unit_expo) +{ +if (unit_expo <0x08 ) +return unit_expo; +else if (unit_expo <=0x0f ) +return -(0x0f -unit_expo+1 ); +else +return 0 ; +} + +int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev, +u32 usage_id, +struct hid_sensor_iio_common *st); +int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +int val1,int val2); +int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int *val1,int *val2); +int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int val1,int val2); +int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int *val1,int *val2); +#endif Signature · 1 line
1.7.8.6
Signature · 2 lines
Jiri Kosina SUSE Labs
Jonathan Cameron
maintainerRe: [PATCH 2/4 RESEND] iio: merge hid-sensor-attributes.h into hid-sensor-hub.h
Quoted 9 lines · Jiri Kosina
Quoted 5 lines · Alexander Holler
The stuff in
hid-sensor-attributes.his needed by every piece which uses hid-sensor-hub and merging it intohid-sensor-hub.hmakes it accessible from outside the iio subdirectory.Signed-off-by Alexander Holler <[email protected]>Acked-by Jiri Kosina <[email protected]>
Added to togreg branch of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
Thanks,
Quoted 199 lines
Quoted 198 lines
--- drivers/iio/accel/hid-sensor-accel-3d.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.h | 57 -------------------- .../iio/common/hid-sensors/hid-sensor-trigger.c | 1 - drivers/iio/gyro/hid-sensor-gyro-3d.c | 1 - drivers/iio/light/hid-sensor-als.c | 1 - drivers/iio/magnetometer/hid-sensor-magn-3d.c | 1 - include/linux/hid-sensor-hub.h | 38 +++++++++++++ 8 files changed, 38 insertions(+), 63 deletions(-) delete mode 100644 drivers/iio/common/hid-sensors/hid-sensor-attributes.hdrivers/iio/accel/hid-sensor-accel-3d.c +0
-1@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/ drivers/iio/common/hid-sensors/hid-sensor-attributes.c +0
-1@@ -25,7 +25,6 @@#include <linux/hid-sensor-hub.h> #include <linux/iio/iio.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" static int pow_10 (unsigned power) {drivers/iio/common/hid-sensors/hid-sensor-attributes.h deleted +0
-57@@ -1,57 +0,0 @@ -/* -* HID Sensors Driver -* Copyright (c) 2012, Intel Corporation. -* -* This program is free software; you can redistribute it and/or modify it -* under the terms and conditions of the GNU General Public License, -* version 2, as published by the Free Software Foundation. -* -* This program is distributed in the hope it will be useful, but WITHOUT -* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or -* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for -* more details. -* -* You should have received a copy of the GNU General Public License along with -* this program; if not, write to the Free Software Foundation, Inc., -* 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. -* -*/ -#ifndef _HID_SENSORS_ATTRIBUTES_H -#define _HID_SENSORS_ATTRIBUTES_H - -/* Common hid sensor iio structure */ -struct hid_sensor_iio_common { -struct hid_sensor_hub_device *hsdev; -struct platform_device *pdev; -unsigned usage_id; -bool data_ready; -struct hid_sensor_hub_attribute_info poll; -struct hid_sensor_hub_attribute_info report_state; -struct hid_sensor_hub_attribute_info power_state; -struct hid_sensor_hub_attribute_info sensitivity; -}; - -/*Convert from hid unit expo to regular exponent*/ -static inline int hid_sensor_convert_exponent (int unit_expo) -{ -if (unit_expo <0x08 ) -return unit_expo; -else if (unit_expo <=0x0f ) -return -(0x0f -unit_expo+1 ); -else -return 0 ; -} - -int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev, -u32 usage_id, -struct hid_sensor_iio_common *st); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, -int val1,int val2); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, -int *val1,int *val2); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, -int val1,int val2); -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, -int *val1,int *val2); - -#endif drivers/iio/common/hid-sensors/hid-sensor-trigger.c +0
-1@@ -26,7 +26,6 @@#include <linux/iio/iio.h> #include <linux/iio/trigger.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" #include "hid-sensor-trigger.h" static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,drivers/iio/gyro/hid-sensor-gyro-3d.c +0
-1@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/ drivers/iio/light/hid-sensor-als.c +0
-1@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/ drivers/iio/magnetometer/hid-sensor-magn-3d.c +0
-1@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/ include/linux/hid-sensor-hub.h +38
-0@@ -157,4 +157,42 @@ int sensor_hub_set_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,*/ int sensor_hub_get_feature (struct hid_sensor_hub_device *hsdev,u32 report_id,u32 field_index,s32 *value); + +/* hid-sensor-attributes */ + +/* Common hid sensor iio structure */ +struct hid_sensor_iio_common { +struct hid_sensor_hub_device *hsdev; +struct platform_device *pdev; +unsigned usage_id; +bool data_ready; +struct hid_sensor_hub_attribute_info poll; +struct hid_sensor_hub_attribute_info report_state; +struct hid_sensor_hub_attribute_info power_state; +struct hid_sensor_hub_attribute_info sensitivity; +}; + +/*Convert from hid unit expo to regular exponent*/ +static inline int hid_sensor_convert_exponent (int unit_expo) +{ +if (unit_expo <0x08 ) +return unit_expo; +else if (unit_expo <=0x0f ) +return -(0x0f -unit_expo+1 ); +else +return 0 ; +} + +int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev, +u32 usage_id, +struct hid_sensor_iio_common *st); +int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +int val1,int val2); +int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int *val1,int *val2); +int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int val1,int val2); +int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int *val1,int *val2); +#endif Signature · 1 line
1.7.8.6
PATCH RESEND v5 3/4 rtc: add rtc-driver for HID sensors of type time
In reply to Alexander HollerThis driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Currently the time can only be read. Setting the time must be done through sending a report (or a feature). The spec currently doesn't define how and I'm not sure if I just should define something by myself.
--- drivers/rtc/Kconfig | 16 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-hid-sensor-time.c | 291 +++++++++++++++++++++++++++++++++++++ 3 files changed, 308 insertions(+), 0 deletions(-) create mode 100644 drivers/rtc/rtc-hid-sensor-time.c
drivers/rtc/Kconfig +16 -0
@@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS This driver can also be built as a module, if so, the module will be called "rtc-snvs". +comment "HID Sensor RTC drivers" + +config RTC_DRV_HID_SENSOR_TIME + tristate "HID Sensor Time" + depends on USB_HID + select IIO + select HID_SENSOR_HUB + select HID_SENSOR_IIO_COMMON + help + Say yes here to build support for the HID Sensors of type Time. + This drivers makes such sensors available as RTCs. + + If this driver is compiled as a module, it will be named + rtc-hid-sensor-time. + + endif # RTC_CLASS
drivers/rtc/Makefile +1 -0
@@ -51,6 +51,7 @@ obj-$(CONFIG_RTC_DRV_EM3027) += rtc-em3027.o obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93xx.o obj-$(CONFIG_RTC_DRV_FM3130) += rtc-fm3130.o obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o +obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o obj-$(CONFIG_RTC_DRV_IMXDI) += rtc-imxdi.o obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
drivers/rtc/rtc-hid-sensor-time.c new file +291 -0
291 lines not on this page · raw message
Signature · 1 line
1.7.8.6
Re: [PATCH 3/4 v5 RESEND] rtc: add rtc-driver for HID sensors of type time
Quoted 9 lines · On Sat, 15 Dec 2012 13:45:36 +0100 Alexander Holler <[email protected]>…
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Quoted 4 lines
Currently the time can only be read. Setting the time must be done through sending a report (or a feature). The spec currently doesn't define how and I'm not sure if I just should define something by myself.
Looks OK to me. It sounds like Jonathan will be merging these patches when he's happy with them - please do proceed that way.
Re: [PATCH 3/4 v5 RESEND] rtc: add rtc-driver for HID sensors of type time
Quoted 9 lines · Andrew Morton
Quoted 9 lines
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Quoted 7 lines
Quoted 4 lines
Currently the time can only be read. Setting the time must be done through sending a report (or a feature). The spec currently doesn't define how and I'm not sure if I just should define something by myself.
Looks OK to me. It sounds like Jonathan will be merging these patches when he's happy with them - please do proceed that way.
Yes, fine by me as well -- that's why I have provided by explicit Acks to those.
Jonathan, are you taking those, please?
Signature · 2 lines
Jiri Kosina SUSE Labs
Re: [PATCH 3/4 v5 RESEND] rtc: add rtc-driver for HID sensors of type time
Am 04.01.2013 10:18, schrieb Jiri Kosina:
Quoted 5 lines · Andrew Morton
Quoted 3 lines
Quoted 3 lines
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Quoted 7 lines
Quoted 2 lines
Looks OK to me. It sounds like Jonathan will be merging these patches when he's happy with them - please do proceed that way.
Yes, fine by me as well -- that's why I have provided by explicit Acks to those.
Jonathan, are you taking those, please?
Thanks to all.
Btw. if someone wants to build such a pluggable HID-USB-RTC using an AVR (Arduino Leonardo, or an ATtiny with v-usb), feel free to contact me. I have some working sources around and will write a website with "exact steps" ;) if I find the time. Currently the stuff is still in ugly state, but if someone needs a starting point (e.g. for the HID descriptors), it is already usable.
Regards,
Alexander
Jonathan Cameron
maintainerRe: [PATCH 3/4 v5 RESEND] rtc: add rtc-driver for HID sensors of type time
Quoted 14 lines · Alexander Holler
Am 04.01.2013 10:18, schrieb Jiri Kosina:
Quoted 12 lines · Andrew Morton
Quoted 6 lines
Quoted 3 lines
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Looks OK to me. It sounds like Jonathan will be merging these patches when he's happy with them - please do proceed that way.
Yes, fine by me as well -- that's why I have provided by explicit Acks to those.
Jonathan, are you taking those, please?
Added to togreg branch of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
Thanks all,
Quoted 14 lines
Thanks to all.
Btw. if someone wants to build such a pluggable HID-USB-RTC using an AVR (Arduino Leonardo, or an ATtiny with v-usb), feel free to contact me. I have some working sources around and will write a website with "exact steps" ;) if I find the time. Currently the stuff is still in ugly state, but if someone needs a starting point (e.g. for the HID descriptors), it is already usable.
Regards,
Alexander
Signature · 3 lines
To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
PATCH RESEND 4/4 hid: iio: rename struct hid_sensor_iio_common to hid_sensor_common
In reply to Alexander HollerThe structure with common attributes for hid-sensors isn't specific to the iio-subsystem, so rename it to hid_sensor_common.
--- drivers/iio/accel/hid-sensor-accel-3d.c | 2 +- .../iio/common/hid-sensors/hid-sensor-attributes.c | 10 +++++----- .../iio/common/hid-sensors/hid-sensor-trigger.c | 4 ++-- .../iio/common/hid-sensors/hid-sensor-trigger.h | 2 +- drivers/iio/gyro/hid-sensor-gyro-3d.c | 2 +- drivers/iio/light/hid-sensor-als.c | 2 +- drivers/iio/magnetometer/hid-sensor-magn-3d.c | 2 +- drivers/rtc/rtc-hid-sensor-time.c | 2 +- include/linux/hid-sensor-hub.h | 12 ++++++------ 9 files changed, 19 insertions(+), 19 deletions(-)
drivers/iio/accel/hid-sensor-accel-3d.c +1 -1
@@ -43,7 +43,7 @@ enum accel_3d_channel {struct accel_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info accel[ACCEL_3D_CHANNEL_MAX ];u32 accel_val[ACCEL_3D_CHANNEL_MAX ]; };
drivers/iio/common/hid-sensors/hid-sensor-attributes.c +5 -5
@@ -113,7 +113,7 @@ static u32 convert_to_vtf_format(int size, int exp, int val1, int val2)return value; } -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;
@@ -140,7 +140,7 @@ int hid_sensor_read_samp_freq_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_read_samp_freq_value); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;
@@ -168,7 +168,7 @@ int hid_sensor_write_samp_freq_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_write_samp_freq_value); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;
@@ -190,7 +190,7 @@ int hid_sensor_read_raw_hyst_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_read_raw_hyst_value); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;
@@ -211,7 +211,7 @@ EXPORT_SYMBOL(hid_sensor_write_raw_hyst_value);int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st) +struct hid_sensor_common *st) { sensor_hub_input_get_attribute_info(hsdev,
drivers/iio/common/hid-sensors/hid-sensor-trigger.c +2 -2
@@ -31,7 +31,7 @@static int hid_sensor_data_rdy_trigger_set_state (struct iio_trigger *trig,bool state) { -struct hid_sensor_iio_common *st = trig->private_data; +struct hid_sensor_common *st = trig->private_data;int state_val; state_val = state ?1 :0 ;
@@ -65,7 +65,7 @@ static const struct iio_trigger_ops hid_sensor_trigger_ops = { };int hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb) +struct hid_sensor_common *attrb) {int ret;struct iio_trigger *trig;
drivers/iio/common/hid-sensors/hid-sensor-trigger.h +1 -1
@@ -20,7 +20,7 @@#define _HID_SENSOR_TRIGGER_Hint hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb); +struct hid_sensor_common *attrb);void hid_sensor_remove_trigger (struct iio_dev *indio_dev);#endif
drivers/iio/gyro/hid-sensor-gyro-3d.c +1 -1
@@ -43,7 +43,7 @@ enum gyro_3d_channel {struct gyro_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info gyro[GYRO_3D_CHANNEL_MAX ];u32 gyro_val[GYRO_3D_CHANNEL_MAX ]; };
drivers/iio/light/hid-sensor-als.c +1 -1
@@ -38,7 +38,7 @@struct als_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info als_illum;u32 illum; };
drivers/iio/magnetometer/hid-sensor-magn-3d.c +1 -1
@@ -43,7 +43,7 @@ enum magn_3d_channel {struct magn_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX ];u32 magn_val[MAGN_3D_CHANNEL_MAX ]; };
drivers/rtc/rtc-hid-sensor-time.c +1 -1
@@ -39,7 +39,7 @@ enum hid_time_channel {struct hid_time_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX ];struct rtc_time last_time;spinlock_t lock_last_time;
include/linux/hid-sensor-hub.h +6 -6
@@ -161,7 +161,7 @@ int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,/* hid-sensor-attributes */ /* Common hid sensor iio structure */ -struct hid_sensor_iio_common { +struct hid_sensor_common {struct hid_sensor_hub_device *hsdev;struct platform_device *pdev;unsigned usage_id;
@@ -185,14 +185,14 @@ static inline int hid_sensor_convert_exponent(int unit_expo)int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +struct hid_sensor_common *st); +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2);#endif
Signature · 1 line
1.7.8.6
Re: [PATCH 4/4 RESEND] hid: iio: rename struct hid_sensor_iio_common to hid_sensor_common
Quoted 4 lines · Alexander Holler
The structure with common attributes for hid-sensors isn't specific to the iio-subsystem, so rename it to
hid_sensor_common.Signed-off-by Alexander Holler <[email protected]>
Quoted 197 lines
--- drivers/iio/accel/hid-sensor-accel-3d.c | 2 +- .../iio/common/hid-sensors/hid-sensor-attributes.c | 10 +++++----- .../iio/common/hid-sensors/hid-sensor-trigger.c | 4 ++-- .../iio/common/hid-sensors/hid-sensor-trigger.h | 2 +- drivers/iio/gyro/hid-sensor-gyro-3d.c | 2 +- drivers/iio/light/hid-sensor-als.c | 2 +- drivers/iio/magnetometer/hid-sensor-magn-3d.c | 2 +- drivers/rtc/rtc-hid-sensor-time.c | 2 +- include/linux/hid-sensor-hub.h | 12 ++++++------ 9 files changed, 19 insertions(+), 19 deletions(-)drivers/iio/accel/hid-sensor-accel-3d.c +1
-1@@ -43,7 +43,7 @@ enum accel_3d_channel {struct accel_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info accel[ACCEL_3D_CHANNEL_MAX ];u32 accel_val[ACCEL_3D_CHANNEL_MAX ]; };drivers/iio/common/hid-sensors/hid-sensor-attributes.c +5
-5@@ -113,7 +113,7 @@ static u32 convert_to_vtf_format(int size, int exp, int val1, int val2)return value; } -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;@@ -140,7 +140,7 @@ int hid_sensor_read_samp_freq_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_read_samp_freq_value); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;@@ -168,7 +168,7 @@ int hid_sensor_write_samp_freq_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_write_samp_freq_value); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;@@ -190,7 +190,7 @@ int hid_sensor_read_raw_hyst_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_read_raw_hyst_value); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;@@ -211,7 +211,7 @@ EXPORT_SYMBOL(hid_sensor_write_raw_hyst_value);int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st) +struct hid_sensor_common *st) { sensor_hub_input_get_attribute_info(hsdev,drivers/iio/common/hid-sensors/hid-sensor-trigger.c +2
-2@@ -31,7 +31,7 @@static int hid_sensor_data_rdy_trigger_set_state (struct iio_trigger *trig,bool state) { -struct hid_sensor_iio_common *st = trig->private_data; +struct hid_sensor_common *st = trig->private_data;int state_val; state_val = state ?1 :0 ;@@ -65,7 +65,7 @@ static const struct iio_trigger_ops hid_sensor_trigger_ops = { };int hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb) +struct hid_sensor_common *attrb) {int ret;struct iio_trigger *trig;drivers/iio/common/hid-sensors/hid-sensor-trigger.h +1
-1@@ -20,7 +20,7 @@#define _HID_SENSOR_TRIGGER_Hint hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb); +struct hid_sensor_common *attrb);void hid_sensor_remove_trigger (struct iio_dev *indio_dev);#endif drivers/iio/gyro/hid-sensor-gyro-3d.c +1
-1@@ -43,7 +43,7 @@ enum gyro_3d_channel {struct gyro_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info gyro[GYRO_3D_CHANNEL_MAX ];u32 gyro_val[GYRO_3D_CHANNEL_MAX ]; };drivers/iio/light/hid-sensor-als.c +1
-1@@ -38,7 +38,7 @@struct als_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info als_illum;u32 illum; };drivers/iio/magnetometer/hid-sensor-magn-3d.c +1
-1@@ -43,7 +43,7 @@ enum magn_3d_channel {struct magn_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX ];u32 magn_val[MAGN_3D_CHANNEL_MAX ]; };drivers/rtc/rtc-hid-sensor-time.c +1
-1@@ -39,7 +39,7 @@ enum hid_time_channel {struct hid_time_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX ];struct rtc_time last_time;spinlock_t lock_last_time;include/linux/hid-sensor-hub.h +6
-6@@ -161,7 +161,7 @@ int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,/* hid-sensor-attributes */ /* Common hid sensor iio structure */ -struct hid_sensor_iio_common { +struct hid_sensor_common {struct hid_sensor_hub_device *hsdev;struct platform_device *pdev;unsigned usage_id;@@ -185,14 +185,14 @@ static inline int hid_sensor_convert_exponent(int unit_expo)int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +struct hid_sensor_common *st); +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2);#endif Signature · 1 line
1.7.8.6
Signature · 2 lines
Jiri Kosina SUSE Labs
Jonathan Cameron
maintainerRe: [PATCH 4/4 RESEND] hid: iio: rename struct hid_sensor_iio_common to hid_sensor_common
Quoted 8 lines · Jiri Kosina
Quoted 4 lines · Alexander Holler
The structure with common attributes for hid-sensors isn't specific to the iio-subsystem, so rename it to
hid_sensor_common.Signed-off-by Alexander Holler <[email protected]>Acked-by Jiri Kosina <[email protected]>
Added to togreg branch of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
Thanks,
Quoted 199 lines
Quoted 198 lines
--- drivers/iio/accel/hid-sensor-accel-3d.c | 2 +- .../iio/common/hid-sensors/hid-sensor-attributes.c | 10 +++++----- .../iio/common/hid-sensors/hid-sensor-trigger.c | 4 ++-- .../iio/common/hid-sensors/hid-sensor-trigger.h | 2 +- drivers/iio/gyro/hid-sensor-gyro-3d.c | 2 +- drivers/iio/light/hid-sensor-als.c | 2 +- drivers/iio/magnetometer/hid-sensor-magn-3d.c | 2 +- drivers/rtc/rtc-hid-sensor-time.c | 2 +- include/linux/hid-sensor-hub.h | 12 ++++++------ 9 files changed, 19 insertions(+), 19 deletions(-)drivers/iio/accel/hid-sensor-accel-3d.c +1
-1@@ -43,7 +43,7 @@ enum accel_3d_channel {struct accel_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info accel[ACCEL_3D_CHANNEL_MAX ];u32 accel_val[ACCEL_3D_CHANNEL_MAX ]; };drivers/iio/common/hid-sensors/hid-sensor-attributes.c +5
-5@@ -113,7 +113,7 @@ static u32 convert_to_vtf_format(int size, int exp, int val1, int val2)return value; } -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;@@ -140,7 +140,7 @@ int hid_sensor_read_samp_freq_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_read_samp_freq_value); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;@@ -168,7 +168,7 @@ int hid_sensor_write_samp_freq_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_write_samp_freq_value); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;@@ -190,7 +190,7 @@ int hid_sensor_read_raw_hyst_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_read_raw_hyst_value); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;@@ -211,7 +211,7 @@ EXPORT_SYMBOL(hid_sensor_write_raw_hyst_value);int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st) +struct hid_sensor_common *st) { sensor_hub_input_get_attribute_info(hsdev,drivers/iio/common/hid-sensors/hid-sensor-trigger.c +2
-2@@ -31,7 +31,7 @@static int hid_sensor_data_rdy_trigger_set_state (struct iio_trigger *trig,bool state) { -struct hid_sensor_iio_common *st = trig->private_data; +struct hid_sensor_common *st = trig->private_data;int state_val; state_val = state ?1 :0 ;@@ -65,7 +65,7 @@ static const struct iio_trigger_ops hid_sensor_trigger_ops = { };int hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb) +struct hid_sensor_common *attrb) {int ret;struct iio_trigger *trig;drivers/iio/common/hid-sensors/hid-sensor-trigger.h +1
-1@@ -20,7 +20,7 @@#define _HID_SENSOR_TRIGGER_Hint hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb); +struct hid_sensor_common *attrb);void hid_sensor_remove_trigger (struct iio_dev *indio_dev);#endif drivers/iio/gyro/hid-sensor-gyro-3d.c +1
-1@@ -43,7 +43,7 @@ enum gyro_3d_channel {struct gyro_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info gyro[GYRO_3D_CHANNEL_MAX ];u32 gyro_val[GYRO_3D_CHANNEL_MAX ]; };drivers/iio/light/hid-sensor-als.c +1
-1@@ -38,7 +38,7 @@struct als_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info als_illum;u32 illum; };drivers/iio/magnetometer/hid-sensor-magn-3d.c +1
-1@@ -43,7 +43,7 @@ enum magn_3d_channel {struct magn_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX ];u32 magn_val[MAGN_3D_CHANNEL_MAX ]; };drivers/rtc/rtc-hid-sensor-time.c +1
-1@@ -39,7 +39,7 @@ enum hid_time_channel {struct hid_time_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX ];struct rtc_time last_time;spinlock_t lock_last_time;include/linux/hid-sensor-hub.h +6
-6@@ -161,7 +161,7 @@ int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,/* hid-sensor-attributes */ /* Common hid sensor iio structure */ -struct hid_sensor_iio_common { +struct hid_sensor_common {struct hid_sensor_hub_device *hsdev;struct platform_device *pdev;unsigned usage_id;@@ -185,14 +185,14 @@ static inline int hid_sensor_convert_exponent(int unit_expo)int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +struct hid_sensor_common *st); +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2);#endif Signature · 1 line
1.7.8.6
Re: [PATCH 1/4 RESEND] iio: Add Usage IDs for HID time sensors.
In reply to Alexander HollerQuoted 4 lines · Alexander Holler
These are Usage IDs for the attributes year, month, day, hour, minute and second, needed to read HID time sensors.
Signed-off-by Alexander Holler <[email protected]>
Quoted 27 lines
--- include/linux/hid-sensor-ids.h | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)include/linux/hid-sensor-ids.h +9
-0@@ -67,6 +67,15 @@#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS 0x200486#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS 0x200487 +/* Time (2000a0) */ +#define HID_USAGE_SENSOR_TIME 0x2000a0 +#define HID_USAGE_SENSOR_TIME_YEAR 0x200521 +#define HID_USAGE_SENSOR_TIME_MONTH 0x200522 +#define HID_USAGE_SENSOR_TIME_DAY 0x200523 +#define HID_USAGE_SENSOR_TIME_HOUR 0x200525 +#define HID_USAGE_SENSOR_TIME_MINUTE 0x200526 +#define HID_USAGE_SENSOR_TIME_SECOND 0x200527 +/* Units */ #define HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED 0x00#define HID_USAGE_SENSOR_UNITS_LUX 0x01Signature · 1 line
1.7.8.6
Signature · 2 lines
Jiri Kosina SUSE Labs
Jonathan Cameron
maintainerRe: [PATCH 1/4 RESEND] iio: Add Usage IDs for HID time sensors.
Quoted 8 lines · Jiri Kosina
Quoted 4 lines · Alexander Holler
These are Usage IDs for the attributes year, month, day, hour, minute and second, needed to read HID time sensors.
Signed-off-by Alexander Holler <[email protected]>Signed-off-by Jiri Kosina <[email protected]>
Added to togreg branch of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
Thanks,
Quoted 29 lines
Quoted 28 lines
--- include/linux/hid-sensor-ids.h | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)include/linux/hid-sensor-ids.h +9
-0@@ -67,6 +67,15 @@#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Y_AXIS 0x200486#define HID_USAGE_SENSOR_ORIENT_MAGN_FLUX_Z_AXIS 0x200487 +/* Time (2000a0) */ +#define HID_USAGE_SENSOR_TIME 0x2000a0 +#define HID_USAGE_SENSOR_TIME_YEAR 0x200521 +#define HID_USAGE_SENSOR_TIME_MONTH 0x200522 +#define HID_USAGE_SENSOR_TIME_DAY 0x200523 +#define HID_USAGE_SENSOR_TIME_HOUR 0x200525 +#define HID_USAGE_SENSOR_TIME_MINUTE 0x200526 +#define HID_USAGE_SENSOR_TIME_SECOND 0x200527 +/* Units */ #define HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED 0x00#define HID_USAGE_SENSOR_UNITS_LUX 0x01Signature · 1 line
1.7.8.6
PATCH 3/4 iio: merge hid-sensor-attributes.h into hid-sensor-hub.h
In reply to Alexander HollerThe stuff in hid-sensor-attributes.h is needed by every piece which uses hid-sensor-hub and merging it into hid-sensor-hub.h makes it accessible from outside the iio subdirectory.
--- drivers/iio/accel/hid-sensor-accel-3d.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.h | 57 -------------------- .../iio/common/hid-sensors/hid-sensor-trigger.c | 1 - drivers/iio/gyro/hid-sensor-gyro-3d.c | 1 - drivers/iio/light/hid-sensor-als.c | 1 - drivers/iio/magnetometer/hid-sensor-magn-3d.c | 1 - include/linux/hid-sensor-hub.h | 38 +++++++++++++ 8 files changed, 38 insertions(+), 63 deletions(-) delete mode 100644 drivers/iio/common/hid-sensors/hid-sensor-attributes.h
drivers/iio/accel/hid-sensor-accel-3d.c +0 -1
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
drivers/iio/common/hid-sensors/hid-sensor-attributes.c +0 -1
@@ -25,7 +25,6 @@#include <linux/hid-sensor-hub.h> #include <linux/iio/iio.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" static int pow_10 (unsigned power) {
drivers/iio/common/hid-sensors/hid-sensor-attributes.h deleted +0 -57
57 lines not on this page · raw message
drivers/iio/common/hid-sensors/hid-sensor-trigger.c +0 -1
@@ -26,7 +26,6 @@#include <linux/iio/iio.h> #include <linux/iio/trigger.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" #include "hid-sensor-trigger.h" static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig,
drivers/iio/gyro/hid-sensor-gyro-3d.c +0 -1
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
drivers/iio/light/hid-sensor-als.c +0 -1
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
drivers/iio/magnetometer/hid-sensor-magn-3d.c +0 -1
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h" #include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
include/linux/hid-sensor-hub.h +38 -0
@@ -157,4 +157,42 @@ int sensor_hub_set_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,*/ int sensor_hub_get_feature (struct hid_sensor_hub_device *hsdev,u32 report_id,u32 field_index,s32 *value); + +/* hid-sensor-attributes */ + +/* Common hid sensor iio structure */ +struct hid_sensor_iio_common { +struct hid_sensor_hub_device *hsdev; +struct platform_device *pdev; +unsigned usage_id; +bool data_ready; +struct hid_sensor_hub_attribute_info poll; +struct hid_sensor_hub_attribute_info report_state; +struct hid_sensor_hub_attribute_info power_state; +struct hid_sensor_hub_attribute_info sensitivity; +}; + +/*Convert from hid unit expo to regular exponent*/ +static inline int hid_sensor_convert_exponent (int unit_expo) +{ +if (unit_expo <0x08 ) +return unit_expo; +else if (unit_expo <=0x0f ) +return -(0x0f -unit_expo+1 ); +else +return 0 ; +} + +int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev, +u32 usage_id, +struct hid_sensor_iio_common *st); +int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +int val1,int val2); +int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int *val1,int *val2); +int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int val1,int val2); +int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int *val1,int *val2); +#endif
Signature · 1 line
1.7.8.6
RE: [PATCH 3/4] iio: merge hid-sensor-attributes.h into hid-sensor-hub.h
One minor comment.
-----Original Message-----
From: Alexander Holler [mailto:[email protected]]
Sent: Tuesday, December 11, 2012 10:22 AM
To: [email protected]
Cc: [email protected]; Jonathan Cameron; Lars-Peter Clausen; [email protected]; Alessandro Zummo; Pandruvada, Srinivas; Andrew Morton; Alexander Holler
Subject: [PATCH 3/4] iio: merge hid-sensor-attributes.h into hid-sensor-hub.h
The stuff in hid-sensor-attributes.h is needed by every piece which uses hid-sensor-hub and merging it into hid-sensor-hub.h makes it accessible from outside the iio subdirectory.
--- drivers/iio/accel/hid-sensor-accel-3d.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.c | 1 - .../iio/common/hid-sensors/hid-sensor-attributes.h | 57 -------------------- .../iio/common/hid-sensors/hid-sensor-trigger.c | 1 - drivers/iio/gyro/hid-sensor-gyro-3d.c | 1 - drivers/iio/light/hid-sensor-als.c | 1 - drivers/iio/magnetometer/hid-sensor-magn-3d.c | 1 - include/linux/hid-sensor-hub.h | 38 +++++++++++++ 8 files changed, 38 insertions(+), 63 deletions(-) delete mode 100644 drivers/iio/common/hid-sensors/hid-sensor-attributes.h
drivers/iio/accel/hid-sensor-accel-3d.c +0 -0
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h"#include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
drivers/iio/common/hid-sensors/hid-sensor-attributes.c +0 -1
@@ -25,7 +25,6 @@#include <linux/hid-sensor-hub.h> #include <linux/iio/iio.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" static int pow_10 (unsigned power) {
drivers/iio/common/hid-sensors/hid-sensor-attributes.h deleted +0 -54
54 lines not on this page · raw message
drivers/iio/common/hid-sensors/hid-sensor-trigger.c +0 -1
@@ -26,7 +26,6 @@#include <linux/iio/iio.h> #include <linux/iio/trigger.h> #include <linux/iio/sysfs.h> -#include "hid-sensor-attributes.h" #include "hid-sensor-trigger.h" static int hid_sensor_data_rdy_trigger_set_state(struct iio_trigger *trig, diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index 4c56ada..b98cd70 100644
drivers/iio/gyro/hid-sensor-gyro-3d.c +0 -0
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h"#include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
drivers/iio/light/hid-sensor-als.c +0 -0
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h"#include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
drivers/iio/magnetometer/hid-sensor-magn-3d.c +0 -0
@@ -28,7 +28,6 @@#include <linux/iio/buffer.h> #include <linux/iio/trigger_consumer.h> #include <linux/iio/triggered_buffer.h> -#include "../common/hid-sensors/hid-sensor-attributes.h"#include "../common/hid-sensors/hid-sensor-trigger.h" /*Format: HID-SENSOR-usage_id_in_hex*/
include/linux/hid-sensor-hub.h +13 -0
@@ -157,4 +157,42 @@ int sensor_hub_set_feature(struct hid_sensor_hub_device *hsdev, u32 report_id, */ int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id, u32 field_index, s32 *value); + +/* hid-sensor-attributes */ + +/* Common hid sensor iio structure */ +struct hid_sensor_iio_common { +struct hid_sensor_hub_device *hsdev; +struct platform_device *pdev; +unsigned usage_id; +bool data_ready; +struct hid_sensor_hub_attribute_info poll; +struct hid_sensor_hub_attribute_info report_state; +struct hid_sensor_hub_attribute_info power_state; +struct hid_sensor_hub_attribute_info sensitivity; };
<Since it is not common to iio only, we should also remove iio in the structure name. >
+/*Convert from hid unit expo to regular exponent*/ static inline int +hid_sensor_convert_exponent(int unit_expo) {
+ if (unit_expo < 0x08)
+ return unit_expo;
+ else if (unit_expo <= 0x0f)
+ return -(0x0f-unit_expo+1);
+ else
+ return 0;
+}
+
+int hid_sensor_parse_common_attributes(struct hid_sensor_hub_device *hsdev,
+ u32 usage_id,
+ struct hid_sensor_iio_common *st); int
+hid_sensor_write_raw_hyst_value(struct hid_sensor_iio_common *st,
+ int val1, int val2);
+int hid_sensor_read_raw_hyst_value(struct hid_sensor_iio_common *st,
+ int *val1, int *val2);
+int hid_sensor_write_samp_freq_value(struct hid_sensor_iio_common *st,
+ int val1, int val2);
+int hid_sensor_read_samp_freq_value(struct hid_sensor_iio_common *st,
+ int *val1, int *val2);
+
#endif
--
1.7.8.6
Re: [PATCH 3/4] iio: merge hid-sensor-attributes.h into hid-sensor-hub.h
Am 12.12.2012 16:45, schrieb Pandruvada, Srinivas:
Quoted 16 lines
One minor comment.
include/linux/hid-sensor-hub.h +12
-0+/* hid-sensor-attributes */ + +/* Common hid sensor iio structure */ +struct hid_sensor_iio_common { +struct hid_sensor_hub_device *hsdev; +struct platform_device *pdev; +unsigned usage_id; +bool data_ready; +struct hid_sensor_hub_attribute_info poll; +struct hid_sensor_hub_attribute_info report_state; +struct hid_sensor_hub_attribute_info power_state; +struct hid_sensor_hub_attribute_info sensitivity; };
Quoted 2 lines
<Since it is not common to iio only, we should also remove iio in the structure name. >
Ok, I play the patch-monkey and will send a patch 5/4.
Alexander
[PATCHi 5/4] hid: iio: rename struct hid_sensor_iio_common to hid_sensor_common
The structure with common attributes for hid-sensors isn't specific to the iio-subsystem, so rename it to hid_sensor_common.
--- drivers/iio/accel/hid-sensor-accel-3d.c | 2 +- .../iio/common/hid-sensors/hid-sensor-attributes.c | 10 +++++----- .../iio/common/hid-sensors/hid-sensor-trigger.c | 4 ++-- .../iio/common/hid-sensors/hid-sensor-trigger.h | 2 +- drivers/iio/gyro/hid-sensor-gyro-3d.c | 2 +- drivers/iio/light/hid-sensor-als.c | 2 +- drivers/iio/magnetometer/hid-sensor-magn-3d.c | 2 +- drivers/rtc/rtc-hid-sensor-time.c | 2 +- include/linux/hid-sensor-hub.h | 12 ++++++------ 9 files changed, 19 insertions(+), 19 deletions(-)
drivers/iio/accel/hid-sensor-accel-3d.c +1 -1
@@ -43,7 +43,7 @@ enum accel_3d_channel {struct accel_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info accel[ACCEL_3D_CHANNEL_MAX ];u32 accel_val[ACCEL_3D_CHANNEL_MAX ]; };
drivers/iio/common/hid-sensors/hid-sensor-attributes.c +5 -5
@@ -113,7 +113,7 @@ static u32 convert_to_vtf_format(int size, int exp, int val1, int val2)return value; } -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;
@@ -140,7 +140,7 @@ int hid_sensor_read_samp_freq_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_read_samp_freq_value); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;
@@ -168,7 +168,7 @@ int hid_sensor_write_samp_freq_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_write_samp_freq_value); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;
@@ -190,7 +190,7 @@ int hid_sensor_read_raw_hyst_value(struct hid_sensor_iio_common *st, }EXPORT_SYMBOL (hid_sensor_read_raw_hyst_value); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;
@@ -211,7 +211,7 @@ EXPORT_SYMBOL(hid_sensor_write_raw_hyst_value);int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st) +struct hid_sensor_common *st) { sensor_hub_input_get_attribute_info(hsdev,
drivers/iio/common/hid-sensors/hid-sensor-trigger.c +2 -2
@@ -31,7 +31,7 @@static int hid_sensor_data_rdy_trigger_set_state (struct iio_trigger *trig,bool state) { -struct hid_sensor_iio_common *st = trig->private_data; +struct hid_sensor_common *st = trig->private_data;int state_val; state_val = state ?1 :0 ;
@@ -65,7 +65,7 @@ static const struct iio_trigger_ops hid_sensor_trigger_ops = { };int hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb) +struct hid_sensor_common *attrb) {int ret;struct iio_trigger *trig;
drivers/iio/common/hid-sensors/hid-sensor-trigger.h +1 -1
@@ -20,7 +20,7 @@#define _HID_SENSOR_TRIGGER_Hint hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb); +struct hid_sensor_common *attrb);void hid_sensor_remove_trigger (struct iio_dev *indio_dev);#endif
drivers/iio/gyro/hid-sensor-gyro-3d.c +1 -1
@@ -43,7 +43,7 @@ enum gyro_3d_channel {struct gyro_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info gyro[GYRO_3D_CHANNEL_MAX ];u32 gyro_val[GYRO_3D_CHANNEL_MAX ]; };
drivers/iio/light/hid-sensor-als.c +1 -1
@@ -38,7 +38,7 @@struct als_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info als_illum;u32 illum; };
drivers/iio/magnetometer/hid-sensor-magn-3d.c +1 -1
@@ -43,7 +43,7 @@ enum magn_3d_channel {struct magn_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX ];u32 magn_val[MAGN_3D_CHANNEL_MAX ]; };
drivers/rtc/rtc-hid-sensor-time.c +1 -1
@@ -39,7 +39,7 @@ enum hid_time_channel {struct hid_time_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX ];struct rtc_time last_time;spinlock_t lock_last_time;
include/linux/hid-sensor-hub.h +6 -6
@@ -161,7 +161,7 @@ int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,/* hid-sensor-attributes */ /* Common hid sensor iio structure */ -struct hid_sensor_iio_common { +struct hid_sensor_common {struct hid_sensor_hub_device *hsdev;struct platform_device *pdev;unsigned usage_id;
@@ -185,14 +185,14 @@ static inline int hid_sensor_convert_exponent(int unit_expo)int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +struct hid_sensor_common *st); +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2);#endif
Signature · 1 line
1.7.8.6
RE: [PATCHi 5/4] hid: iio: rename struct hid_sensor_iio_common to hid_sensor_common
Looks good.
-----Original Message-----
From: Alexander Holler [mailto:[email protected]]
Sent: Wednesday, December 12, 2012 12:28 PM
To: [email protected]
Cc: [email protected]; Jonathan Cameron; Lars-Peter Clausen; [email protected]; Alessandro Zummo; Pandruvada, Srinivas; Andrew Morton; Alexander Holler
Subject: [PATCHi 5/4] hid: iio: rename struct hid_sensor_iio_common to hid_sensor_common
The structure with common attributes for hid-sensors isn't specific to the iio-subsystem, so rename it to hid_sensor_common.
--- drivers/iio/accel/hid-sensor-accel-3d.c | 2 +- .../iio/common/hid-sensors/hid-sensor-attributes.c | 10 +++++----- .../iio/common/hid-sensors/hid-sensor-trigger.c | 4 ++-- .../iio/common/hid-sensors/hid-sensor-trigger.h | 2 +- drivers/iio/gyro/hid-sensor-gyro-3d.c | 2 +- drivers/iio/light/hid-sensor-als.c | 2 +- drivers/iio/magnetometer/hid-sensor-magn-3d.c | 2 +- drivers/rtc/rtc-hid-sensor-time.c | 2 +- include/linux/hid-sensor-hub.h | 12 ++++++------ 9 files changed, 19 insertions(+), 19 deletions(-)
drivers/iio/accel/hid-sensor-accel-3d.c +1 -1
@@ -43,7 +43,7 @@ enum accel_3d_channel {struct accel_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info accel[ACCEL_3D_CHANNEL_MAX ];u32 accel_val[ACCEL_3D_CHANNEL_MAX ]; };
drivers/iio/common/hid-sensors/hid-sensor-attributes.c +5 -5
@@ -113,7 +113,7 @@ static u32 convert_to_vtf_format(int size, int exp, int val1, int val2)return value; } -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;
@@ -140,7 +140,7 @@ int hid_sensor_read_samp_freq_value(struct hid_sensor_iio_common *st, } EXPORT_SYMBOL(hid_sensor_read_samp_freq_value); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;
@@ -168,7 +168,7 @@ int hid_sensor_write_samp_freq_value(struct hid_sensor_iio_common *st, } EXPORT_SYMBOL(hid_sensor_write_samp_freq_value); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2) {s32 value;
@@ -190,7 +190,7 @@ int hid_sensor_read_raw_hyst_value(struct hid_sensor_iio_common *st, } EXPORT_SYMBOL(hid_sensor_read_raw_hyst_value); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2) {s32 value;
@@ -211,7 +211,7 @@ EXPORT_SYMBOL(hid_sensor_write_raw_hyst_value);int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st) +struct hid_sensor_common *st) { sensor_hub_input_get_attribute_info(hsdev,
drivers/iio/common/hid-sensors/hid-sensor-trigger.c +2 -2
@@ -31,7 +31,7 @@static int hid_sensor_data_rdy_trigger_set_state (struct iio_trigger *trig,bool state) { -struct hid_sensor_iio_common *st = trig->private_data; +struct hid_sensor_common *st = trig->private_data;int state_val; state_val = state ?1 :0 ;
@@ -65,7 +65,7 @@ static const struct iio_trigger_ops hid_sensor_trigger_ops = { };int hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb) +struct hid_sensor_common *attrb) {int ret;struct iio_trigger *trig;
drivers/iio/common/hid-sensors/hid-sensor-trigger.h +1 -1
@@ -20,7 +20,7 @@#define _HID_SENSOR_TRIGGER_Hint hid_sensor_setup_trigger (struct iio_dev *indio_dev,const char *name, -struct hid_sensor_iio_common *attrb); +struct hid_sensor_common *attrb);void hid_sensor_remove_trigger (struct iio_dev *indio_dev);#endif
drivers/iio/gyro/hid-sensor-gyro-3d.c +1 -1
@@ -43,7 +43,7 @@ enum gyro_3d_channel {struct gyro_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info gyro[GYRO_3D_CHANNEL_MAX ];u32 gyro_val[GYRO_3D_CHANNEL_MAX ]; };
drivers/iio/light/hid-sensor-als.c +1 -1
@@ -38,7 +38,7 @@struct als_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info als_illum;u32 illum; };
drivers/iio/magnetometer/hid-sensor-magn-3d.c +1 -1
@@ -43,7 +43,7 @@ enum magn_3d_channel {struct magn_3d_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info magn[MAGN_3D_CHANNEL_MAX ];u32 magn_val[MAGN_3D_CHANNEL_MAX ]; };
drivers/rtc/rtc-hid-sensor-time.c +1 -1
@@ -39,7 +39,7 @@ enum hid_time_channel {struct hid_time_state {struct hid_sensor_hub_callbacks callbacks; -struct hid_sensor_iio_common common_attributes; +struct hid_sensor_common common_attributes;struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX ];struct rtc_time last_time;spinlock_t lock_last_time;
include/linux/hid-sensor-hub.h +6 -6
@@ -161,7 +161,7 @@ int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,/* hid-sensor-attributes */ /* Common hid sensor iio structure */ -struct hid_sensor_iio_common { +struct hid_sensor_common {struct hid_sensor_hub_device *hsdev;struct platform_device *pdev;unsigned usage_id;
@@ -185,14 +185,14 @@ static inline int hid_sensor_convert_exponent(int unit_expo)int hid_sensor_parse_common_attributes (struct hid_sensor_hub_device *hsdev,u32 usage_id, -struct hid_sensor_iio_common *st); -int hid_sensor_write_raw_hyst_value (struct hid_sensor_iio_common *st, +struct hid_sensor_common *st); +int hid_sensor_write_raw_hyst_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_raw_hyst_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_raw_hyst_value (struct hid_sensor_common *st,int *val1,int *val2); -int hid_sensor_write_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_write_samp_freq_value (struct hid_sensor_common *st,int val1,int val2); -int hid_sensor_read_samp_freq_value (struct hid_sensor_iio_common *st, +int hid_sensor_read_samp_freq_value (struct hid_sensor_common *st,int *val1,int *val2);#endif
--
1.7.8.6
PATCH v3 4/4 rtc: add rtc-driver for HID sensors of type time
In reply to Alexander HollerThis driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub. (I've planned to submit patches.)
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
--- drivers/rtc/Kconfig | 16 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-hid-sensor-time.c | 284 +++++++++++++++++++++++++++++++++++++ 3 files changed, 301 insertions(+), 0 deletions(-) create mode 100644 drivers/rtc/rtc-hid-sensor-time.c
drivers/rtc/Kconfig +16 -0
@@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS This driver can also be built as a module, if so, the module will be called "rtc-snvs". +comment "HID Sensor RTC drivers" + +config RTC_DRV_HID_SENSOR_TIME + tristate "HID Sensor Time" + depends on USB_HID + select IIO + select HID_SENSOR_HUB + select HID_SENSOR_IIO_COMMON + help + Say yes here to build support for the HID Sensors of type Time. + This drivers makes such sensors available as RTCs. + + If this driver is compiled as a module, it will be named + rtc-hid-sensor-time. + + endif # RTC_CLASS
drivers/rtc/Makefile +1 -0
@@ -51,6 +51,7 @@ obj-$(CONFIG_RTC_DRV_EM3027) += rtc-em3027.o obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93xx.o obj-$(CONFIG_RTC_DRV_FM3130) += rtc-fm3130.o obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o +obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o obj-$(CONFIG_RTC_DRV_IMXDI) += rtc-imxdi.o obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
drivers/rtc/rtc-hid-sensor-time.c new file +284 -0
284 lines not on this page · raw message
Signature · 1 line
1.7.8.6
Re: [PATCH 4/4 v3] rtc: add rtc-driver for HID sensors of type time
Quoted 7 lines · Alexander Holler
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub. (I've planned to submit patches.)
Quoted 7 lines
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Signed-off-by Alexander Holler <[email protected]>
Looks good, but as I wrote during the last review the __devinits need to go. A few other suggerstions online
Quoted 19 lines
--- drivers/rtc/Kconfig | 16 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-hid-sensor-time.c | 284 +++++++++++++++++++++++++++++++++++++ 3 files changed, 301 insertions(+), 0 deletions(-) create mode 100644 drivers/rtc/rtc-hid-sensor-time.cdrivers/rtc/Kconfig +4
-0@@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS This driver can also be built as a module, if so, the module will be called "rtc-snvs". +comment "HID Sensor RTC drivers" + +config RTC_DRV_HID_SENSOR_TIME + tristate "HID Sensor Time"
drivers/rtc/Kconfig config RTC_DRV_SNVS · line 1160
Quoted 10 lines
drivers/rtc/Kconfig +10
-0+ depends on USB_HID + select IIO + select HID_SENSOR_HUB + select HID_SENSOR_IIO_COMMON + help + Say yes here to build support for the HID Sensors of type Time. + This drivers makes such sensors available as RTCs. + + If this driver is compiled as a module, it will be named + rtc-hid-sensor-time.
The help text should be indented using one tab followed by two spaces
Quoted 3 lines
drivers/rtc/Kconfig +2
-0+ + endif # RTC_CLASS
[...]
Quoted 6 lines
drivers/rtc/rtc-hid-sensor-time.c new file +0
-0@@ -0,0 +1,284 @@
[...]
drivers/rtc/rtc-hid-sensor-time.c line 61
Quoted 3 lines
drivers/rtc/rtc-hid-sensor-time.c new file +3
-0+ +/* Channel names for verbose error messages */ +static const char *hid_time_channel_names[TIME_RTC_CHANNEL_MAX ] = {
const char * const
Quoted 23 lines
drivers/rtc/rtc-hid-sensor-time.c new file +23
-0+ "year", "month", "day", "hour", "minute", "second", +}; + +/* Callback handler to send event after all samples are received and captured */ +static int hid_time_proc_event (struct hid_sensor_hub_device *hsdev, +unsigned usage_id,void *priv) +{ +unsigned long flags; +struct hid_time_state *time_state =platform_get_drvdata (priv); + +spin_lock_irqsave (&time_state->lock_last_time, flags); + time_state->last_time = time_state->time_buf; +spin_unlock_irqrestore (&time_state->lock_last_time, flags); +complete (&time_state->comp_last_time); +return 0 ; +} + +static int hid_time_capture_sample (struct hid_sensor_hub_device *hsdev, +unsigned usage_id,size_t raw_len, +char *raw_data,void *priv) +{ +struct hid_time_state *time_state =platform_get_drvdata (priv); +struct rtc_time *time_buf = &time_state->time_buf;
drivers/rtc/rtc-hid-sensor-time.c line 94
Quoted 10 lines
drivers/rtc/rtc-hid-sensor-time.c new file +10
-0+ +switch (usage_id) { +case HID_USAGE_SENSOR_TIME_YEAR : + time_buf->tm_year = *(u8 *)raw_data; +if (time_buf->tm_year <70 ) +/* assume we are in 1970...2069 */ + time_buf->tm_year +=100 ; +break ; +case HID_USAGE_SENSOR_TIME_MONTH : + time_buf->tm_mon = --*(u8 *)raw_data;
What's up with the double minus?
Quoted 16 lines
drivers/rtc/rtc-hid-sensor-time.c new file +16
-0+break ; +case HID_USAGE_SENSOR_TIME_DAY : + time_buf->tm_mday = *(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_HOUR : + time_buf->tm_hour = *(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_MINUTE : + time_buf->tm_min = *(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_SECOND : + time_buf->tm_sec = *(u8 *)raw_data; +break ; +default : +return -EINVAL ; + }
drivers/rtc/rtc-hid-sensor-time.c line 120
Quoted 10 lines
drivers/rtc/rtc-hid-sensor-time.c new file +10
-0+return 0 ; +} + +/* small helper, haven't found any other way */ +static const char *attrib_name (u32 attrib_id) +{ +unsigned i =0 ; +static const char unknown[] ="unknown" ; + +for (; i <TIME_RTC_CHANNEL_MAX ; ++i) {
I would put the i = 0 in the for header.
Quoted 4 lines
drivers/rtc/rtc-hid-sensor-time.c new file +4
-0+if (hid_time_addresses[i] == attrib_id) +return hid_time_channel_names[i]; + } +return unknown;/* should never happen */
drivers/rtc/rtc-hid-sensor-time.c line 134
Quoted 10 lines
drivers/rtc/rtc-hid-sensor-time.c new file +10
-0+} + +static int hid_time_parse_report (struct platform_device *pdev, +struct hid_sensor_hub_device *hsdev, +unsigned usage_id, +struct hid_time_state *time_state) +{ +int ret, i =0 ; + +for (; i <TIME_RTC_CHANNEL_MAX ; ++i) {
Same here
drivers/rtc/rtc-hid-sensor-time.c line 142
Quoted 8 lines
drivers/rtc/rtc-hid-sensor-time.c new file +8
-0+ ret =sensor_hub_input_get_attribute_info (hsdev, +HID_INPUT_REPORT , usage_id, + hid_time_addresses[i], &time_state->info[i]); +if (ret <0 ) +return ret; + } +/* Check the (needed) attributes for sanity */ + ret = time_state->info[0 ].report_id;/* use ret as temp. */
As I said last time, report_id instead of ret may be a better name for the variable
Quoted 10 lines
drivers/rtc/rtc-hid-sensor-time.c new file +10
-0+if (ret <0 ) { +dev_err (&pdev->dev,"bad report ID!\n" ); +return -EINVAL ; + } +for (i =0 ; i <TIME_RTC_CHANNEL_MAX ; ++i) { +if (time_state->info[i].report_id != ret) { +dev_err (&pdev->dev, +"not all needed attributes inside the same report!\n" ); +return -EINVAL ; + }
[...]
Quoted 5 lines
drivers/rtc/rtc-hid-sensor-time.c new file +5
-0+ } + +return 0 ; +} +
[...]
drivers/rtc/rtc-hid-sensor-time.c line 265
Quoted 7 lines
drivers/rtc/rtc-hid-sensor-time.c new file +7
-0+ +static int __devinit hid_time_remove (struct platform_device *pdev) +{ +struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data; +struct hid_time_state *time_state =platform_get_drvdata (pdev); + +if (!IS_ERR (time_state->rtc))
This will never be false, so you can just run unregister unconditionally
Quoted 5 lines
drivers/rtc/rtc-hid-sensor-time.c new file +5
-0+rtc_device_unregister (time_state->rtc); +sensor_hub_remove_callback (hsdev,HID_USAGE_SENSOR_TIME ); + +return 0 ; +}
Re: [PATCH 4/4 v3] rtc: add rtc-driver for HID sensors of type time
Am 12.12.2012 10:51, schrieb Lars-Peter Clausen:
Quoted 2 lines
Looks good, but as I wrote during the last review the
__devinitsneed to go. A few other suggerstions online
Oh, have forgotten it. Ok, will make a v4, changing the other few things too.
Quoted 2 lines
drivers/rtc/rtc-hid-sensor-time.c line 94
Quoted 2 lines
drivers/rtc/rtc-hid-sensor-time.c new file +2
-0+case HID_USAGE_SENSOR_TIME_MONTH : + time_buf->tm_mon = --*(u8 *)raw_data;
Time sensors are sending the month in the range 1-12, not 0-11.
Regards,
Alexander
Re: [PATCH 4/4 v3] rtc: add rtc-driver for HID sensors of type time
Quoted 5 lines · Alexander Holler
Am 12.12.2012 10:51, schrieb Lars-Peter Clausen:
Quoted 2 lines
Looks good, but as I wrote during the last review the
__devinitsneed to go. A few other suggerstions online
Quoted 7 lines
Oh, have forgotten it. Ok, will make a v4, changing the other few things too.
Quoted 2 lines
drivers/rtc/rtc-hid-sensor-time.c line 94
Quoted 2 lines
drivers/rtc/rtc-hid-sensor-time.c new file +2
-0+case HID_USAGE_SENSOR_TIME_MONTH : + time_buf->tm_mon = --*(u8 *)raw_data;Time sensors are sending the month in the range 1-12, not 0-11.
Ah, sorry, I guess hadn't had enough coffee yet, I read this as -(-(*(u8 *)raw_data))) and was a bit confused...
PATCH v4 4/4 rtc: add rtc-driver for HID sensors of type time
In reply to Alexander HollerThis driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub. (I've planned to submit patches.)
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
--- drivers/rtc/Kconfig | 16 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-hid-sensor-time.c | 283 +++++++++++++++++++++++++++++++++++++ 3 files changed, 300 insertions(+), 0 deletions(-) create mode 100644 drivers/rtc/rtc-hid-sensor-time.c
drivers/rtc/Kconfig +16 -0
@@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS This driver can also be built as a module, if so, the module will be called "rtc-snvs". +comment "HID Sensor RTC drivers" + +config RTC_DRV_HID_SENSOR_TIME + tristate "HID Sensor Time" + depends on USB_HID + select IIO + select HID_SENSOR_HUB + select HID_SENSOR_IIO_COMMON + help + Say yes here to build support for the HID Sensors of type Time. + This drivers makes such sensors available as RTCs. + + If this driver is compiled as a module, it will be named + rtc-hid-sensor-time. + + endif # RTC_CLASS
drivers/rtc/Makefile +1 -0
@@ -51,6 +51,7 @@ obj-$(CONFIG_RTC_DRV_EM3027) += rtc-em3027.o obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93xx.o obj-$(CONFIG_RTC_DRV_FM3130) += rtc-fm3130.o obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o +obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o obj-$(CONFIG_RTC_DRV_IMXDI) += rtc-imxdi.o obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
drivers/rtc/rtc-hid-sensor-time.c new file +283 -0
283 lines not on this page · raw message
Signature · 1 line
1.7.8.6
Re: [PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
Quoted 7 lines · Alexander Holler
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub. (I've planned to submit patches.)
Quoted 7 lines
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Signed-off-by Alexander Holler <[email protected]>
Hi,
sorry for the delay. There is still the __devinit in front of hid_time_remove left.
And another thing I've overlooked before:wait_for_completion_interruptible_timeout can either return a positive number when the completion was completed, 0 in case of an timeout, or a negative error code in case it was interrupted. You need to handle all three. E.g. something like this.
ret = wait_for_completion_interruptible_timeout(...) if (ret == 0)
return -EIO;
if (ret < 0)
return ret
Otherwise it looks fine now. Maybe add a prefix to attrib_name() to avoid potential clashes with the global namespace. E.g. hid_time_attrib_name() Same goes for rtc_ops, hid_time_rtc_ops would be a better name.
- Lars
Quoted 333 lines
--- drivers/rtc/Kconfig | 16 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-hid-sensor-time.c | 283 +++++++++++++++++++++++++++++++++++++ 3 files changed, 300 insertions(+), 0 deletions(-) create mode 100644 drivers/rtc/rtc-hid-sensor-time.cdrivers/rtc/Kconfig +16
-0@@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS This driver can also be built as a module, if so, the module will be called "rtc-snvs". +comment "HID Sensor RTC drivers" + +config RTC_DRV_HID_SENSOR_TIME + tristate "HID Sensor Time" + depends on USB_HID + select IIO + select HID_SENSOR_HUB + select HID_SENSOR_IIO_COMMON + help + Say yes here to build support for the HID Sensors of type Time. + This drivers makes such sensors available as RTCs. + + If this driver is compiled as a module, it will be named + rtc-hid-sensor-time. + + endif # RTC_CLASSdrivers/rtc/Makefile +1
-0@@ -51,6 +51,7 @@ obj-$(CONFIG_RTC_DRV_EM3027) += rtc-em3027.o obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93xx.o obj-$(CONFIG_RTC_DRV_FM3130) += rtc-fm3130.o obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o +obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o obj-$(CONFIG_RTC_DRV_IMXDI) += rtc-imxdi.o obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.odrivers/rtc/rtc-hid-sensor-time.c new file +283
-0@@ -0,0 +1,283 @@ +/* +* HID Sensor Time Driver +* Copyright (c) 2012, Alexander Holler. +* +* This program is free software; you can redistribute it and/or modify it +* under the terms and conditions of the GNU General Public License, +* version 2, as published by the Free Software Foundation. +* +* This program is distributed in the hope it will be useful, but WITHOUT +* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or +* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for +* more details. +* +* You should have received a copy of the GNU General Public License along with +* this program; if not, write to the Free Software Foundation, Inc., +* 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA. +* +*/ +#include <linux/device.h> +#include <linux/platform_device.h> +#include <linux/module.h> +#include <linux/hid-sensor-hub.h> +#include <linux/iio/iio.h> +#include <linux/rtc.h> + +/* Format: HID-SENSOR-usage_id_in_hex */ +/* Usage ID from spec for Time: 0x2000A0 */ +#define DRIVER_NAME "HID-SENSOR-2000a0"/* must be lowercase */ + +enum hid_time_channel { +CHANNEL_SCAN_INDEX_YEAR , +CHANNEL_SCAN_INDEX_MONTH , +CHANNEL_SCAN_INDEX_DAY , +CHANNEL_SCAN_INDEX_HOUR , +CHANNEL_SCAN_INDEX_MINUTE , +CHANNEL_SCAN_INDEX_SECOND , +TIME_RTC_CHANNEL_MAX , +}; + +struct hid_time_state { +struct hid_sensor_hub_callbacks callbacks; +struct hid_sensor_iio_common common_attributes; +struct hid_sensor_hub_attribute_info info[TIME_RTC_CHANNEL_MAX ]; +struct rtc_time last_time; +spinlock_t lock_last_time; +struct completion comp_last_time; +struct rtc_time time_buf; +struct rtc_device *rtc; +}; + +static const u32 hid_time_addresses[TIME_RTC_CHANNEL_MAX ] = { +HID_USAGE_SENSOR_TIME_YEAR , +HID_USAGE_SENSOR_TIME_MONTH , +HID_USAGE_SENSOR_TIME_DAY , +HID_USAGE_SENSOR_TIME_HOUR , +HID_USAGE_SENSOR_TIME_MINUTE , +HID_USAGE_SENSOR_TIME_SECOND , +}; + +/* Channel names for verbose error messages */ +static const char *const hid_time_channel_names[TIME_RTC_CHANNEL_MAX ] = { +"year" ,"month" ,"day" ,"hour" ,"minute" ,"second" , +}; + +/* Callback handler to send event after all samples are received and captured */ +static int hid_time_proc_event (struct hid_sensor_hub_device *hsdev, +unsigned usage_id,void *priv) +{ +unsigned long flags; +struct hid_time_state *time_state =platform_get_drvdata (priv); + +spin_lock_irqsave (&time_state->lock_last_time, flags); + time_state->last_time = time_state->time_buf; +spin_unlock_irqrestore (&time_state->lock_last_time, flags); +complete (&time_state->comp_last_time); +return 0 ; +} + +static int hid_time_capture_sample (struct hid_sensor_hub_device *hsdev, +unsigned usage_id,size_t raw_len, +char *raw_data,void *priv) +{ +struct hid_time_state *time_state =platform_get_drvdata (priv); +struct rtc_time *time_buf = &time_state->time_buf; + +switch (usage_id) { +case HID_USAGE_SENSOR_TIME_YEAR : + time_buf->tm_year = *(u8 *)raw_data; +if (time_buf->tm_year <70 ) +/* assume we are in 1970...2069 */ + time_buf->tm_year +=100 ; +break ; +case HID_USAGE_SENSOR_TIME_MONTH : +/* sensor sending the month as 1-12, we need 0-11 */ + time_buf->tm_mon = *(u8 *)raw_data-1 ; +break ; +case HID_USAGE_SENSOR_TIME_DAY : + time_buf->tm_mday = *(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_HOUR : + time_buf->tm_hour = *(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_MINUTE : + time_buf->tm_min = *(u8 *)raw_data; +break ; +case HID_USAGE_SENSOR_TIME_SECOND : + time_buf->tm_sec = *(u8 *)raw_data; +break ; +default : +return -EINVAL ; + } +return 0 ; +} + +/* small helper, haven't found any other way */ +static const char *attrib_name (u32 attrib_id) +{ +static const char unknown[] ="unknown" ; +unsigned i; + +for (i =0 ; i <TIME_RTC_CHANNEL_MAX ; ++i) { +if (hid_time_addresses[i] == attrib_id) +return hid_time_channel_names[i]; + } +return unknown;/* should never happen */ +} + +static int hid_time_parse_report (struct platform_device *pdev, +struct hid_sensor_hub_device *hsdev, +unsigned usage_id, +struct hid_time_state *time_state) +{ +int report_id, i; + +for (i =0 ; i <TIME_RTC_CHANNEL_MAX ; ++i) +if (sensor_hub_input_get_attribute_info (hsdev, +HID_INPUT_REPORT , usage_id, + hid_time_addresses[i], + &time_state->info[i]) <0 ) +return -EINVAL ; +/* Check the (needed) attributes for sanity */ + report_id = time_state->info[0 ].report_id; +if (report_id <0 ) { +dev_err (&pdev->dev,"bad report ID!\n" ); +return -EINVAL ; + } +for (i =0 ; i <TIME_RTC_CHANNEL_MAX ; ++i) { +if (time_state->info[i].report_id != report_id) { +dev_err (&pdev->dev, +"not all needed attributes inside the same report!\n" ); +return -EINVAL ; + } +if (time_state->info[i].size !=1 ) { +dev_err (&pdev->dev, +"attribute '%s' not 8 bits wide!\n" , +attrib_name (time_state->info[i].attrib_id)); +return -EINVAL ; + } +if (time_state->info[i].units != +HID_USAGE_SENSOR_UNITS_NOT_SPECIFIED && +/* allow attribute seconds with unit seconds */ + !(time_state->info[i].attrib_id == +HID_USAGE_SENSOR_TIME_SECOND && + time_state->info[i].units == +HID_USAGE_SENSOR_UNITS_SECOND )) { +dev_err (&pdev->dev, +"attribute '%s' hasn't a unit of type 'none'!\n" , +attrib_name (time_state->info[i].attrib_id)); +return -EINVAL ; + } +if (time_state->info[i].unit_expo) { +dev_err (&pdev->dev, +"attribute '%s' hasn't a unit exponent of 1!\n" , +attrib_name (time_state->info[i].attrib_id)); +return -EINVAL ; + } + } + +return 0 ; +} + +static int hid_rtc_read_time (struct device *dev,struct rtc_time *tm) +{ +unsigned long flags; +struct hid_time_state *time_state = +platform_get_drvdata (to_platform_device (dev)); + +INIT_COMPLETION (time_state->comp_last_time); +/* get a report with all values through requesting one value */ +sensor_hub_input_attr_get_raw_value (time_state->common_attributes.hsdev, +HID_USAGE_SENSOR_TIME , hid_time_addresses[0 ], + time_state->info[0 ].report_id); +/* wait for all values (event) */ +if (!wait_for_completion_interruptible_timeout ( + &time_state->comp_last_time,HZ *6 )) +return -EIO ; +spin_lock_irqsave (&time_state->lock_last_time, flags); + *tm = time_state->last_time; +spin_unlock_irqrestore (&time_state->lock_last_time, flags); + +return 0 ; +} + +static const struct rtc_class_ops rtc_ops = { + .read_time = hid_rtc_read_time, +}; + +static int hid_time_probe (struct platform_device *pdev) +{ +int ret =0 ; +struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data; +struct hid_time_state *time_state =devm_kzalloc (&pdev->dev, +sizeof (struct hid_time_state ),GFP_KERNEL ); + +if (time_state ==NULL ) +return -ENOMEM ; + +platform_set_drvdata (pdev, time_state); + +init_completion (&time_state->comp_last_time); + time_state->common_attributes.hsdev = hsdev; + time_state->common_attributes.pdev = pdev; + + ret =hid_sensor_parse_common_attributes (hsdev, +HID_USAGE_SENSOR_TIME , + &time_state->common_attributes); +if (ret) { +dev_err (&pdev->dev,"failed to setup common attributes!\n" ); +return ret; + } + + ret =hid_time_parse_report (pdev, hsdev,HID_USAGE_SENSOR_TIME , + time_state); +if (ret) { +dev_err (&pdev->dev,"failed to setup attributes!\n" ); +return ret; + } + + time_state->callbacks.send_event = hid_time_proc_event; + time_state->callbacks.capture_sample = hid_time_capture_sample; + time_state->callbacks.pdev = pdev; + ret =sensor_hub_register_callback (hsdev,HID_USAGE_SENSOR_TIME , + &time_state->callbacks); +if (ret <0 ) { +dev_err (&pdev->dev,"register callback failed!\n" ); +return ret; + } + + time_state->rtc =rtc_device_register ("hid-sensor-time" , + &pdev->dev, &rtc_ops,THIS_MODULE ); + +if (IS_ERR (time_state->rtc)) { +dev_err (&pdev->dev,"rtc device register failed!\n" ); +return PTR_ERR (time_state->rtc); + } + +return ret; +} + +static int __devinit hid_time_remove (struct platform_device *pdev) +{ +struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data; +struct hid_time_state *time_state =platform_get_drvdata (pdev); + +rtc_device_unregister (time_state->rtc); +sensor_hub_remove_callback (hsdev,HID_USAGE_SENSOR_TIME ); + +return 0 ; +} + +static struct platform_driver hid_time_platform_driver = { + .driver = { + .name =DRIVER_NAME , + .owner =THIS_MODULE , + }, + .probe = hid_time_probe, + .remove = hid_time_remove, +}; +module_platform_driver (hid_time_platform_driver); + +MODULE_DESCRIPTION ("HID Sensor Time" ); +MODULE_AUTHOR ("Alexander Holler <[email protected]>" ); +MODULE_LICENSE ("GPL" );
Re: [PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
Am 14.12.2012 10:42, schrieb Lars-Peter Clausen:
Quoted 27 lines · Alexander Holler
Quoted 7 lines
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
Currently the time can only be read. Setting the time must be done through sending a report, which currently isn't supported by hid-sensor-hub. (I've planned to submit patches.)
Quoted 7 lines
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Signed-off-by Alexander Holler <[email protected]>Hi,
sorry for the delay. There is still the
__devinitin front ofhid_time_removeleft.And another thing I've overlooked before:
wait_for_completion_interruptible_timeoutcan either return a positive number when the completion was completed, 0 in case of an timeout, or a negative error code in case it was interrupted. You need to handle all three. E.g. something like this.
Quoted 6 lines
ret =
wait_for_completion_interruptible_timeout(...)if (ret == 0)return -EIO;if (ret < 0)
return ret
Hmpf, the only working approach to use some in kernel functions really is to the read source yourself and don't trust anything else. :/
And that ping-ping is stressing my patience, I think I will write a rfc to introduce (at least allow) maintainer-patches.
Will make a v5.
Regards,
Alexander
Re: [PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
Am 14.12.2012 14:08, schrieb Alexander Holler:
Quoted 15 lines
Am 14.12.2012 10:42, schrieb Lars-Peter Clausen:
Quoted 6 lines
And another thing I've overlooked before:
wait_for_completion_interruptible_timeoutcan either return a positive number when the completion was completed, 0 in case of an timeout, or a negative error code in case it was interrupted. You need to handle all three. E.g. something like this.Quoted 6 lines
ret =
wait_for_completion_interruptible_timeout(...)if (ret == 0)return -EIO;if (ret < 0)
return ret
Quoted 2 lines
Hmpf, the only working approach to use some in kernel functions really is to the read source yourself and don't trust anything else. :/
Anyway, my approach doesn't work as it introduces a race condition:
/* get a report with all values through requesting one value */ sensor_hub_input_attr_get_raw_value(...)
/* race if this task goes to slepp and the values were received before it could call the below wait...
/* wait for all values (event) */
if (!wait_for_completion_interruptible_timeout(...))
I'll have to look for a mechanism how to avoid that. So v5 might need some time.
Regards,
Alexander
Re: [PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
Am 14.12.2012 15:15, schrieb Alexander Holler:
Quoted 28 lines
Am 14.12.2012 14:08, schrieb Alexander Holler:
Quoted 15 lines
Am 14.12.2012 10:42, schrieb Lars-Peter Clausen:
Quoted 6 lines
And another thing I've overlooked before:
wait_for_completion_interruptible_timeoutcan either return a positive number when the completion was completed, 0 in case of an timeout, or a negative error code in case it was interrupted. You need to handle all three. E.g. something like this.Quoted 6 lines
ret =
wait_for_completion_interruptible_timeout(...)if (ret == 0)return -EIO;if (ret < 0)
return retQuoted 2 lines
Hmpf, the only working approach to use some in kernel functions really is to the read source yourself and don't trust anything else. :/
Anyway, my approach doesn't work as it introduces a race condition:
/* get a report with all values through requesting one value */
sensor_hub_input_attr_get_raw_value(...)/* race if this task goes to slepp and the values were received before it could call the below wait...
Quoted 6 lines
/* wait for all values (event) */
if (!wait_for_completion_interruptible_timeout(...))I'll have to look for a mechanism how to avoid that. So v5 might need some time.
Sorry for the noise. That INIT_COMPLETION() before the sensor...() does exactly that. So it's enough if I handle the different return situations of wait_for...().
I will just use if(wait...()<=0) return -EIO.
Regards,
Alexander
Re: [PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
Quoted 33 lines · Alexander Holler
Am 14.12.2012 15:15, schrieb Alexander Holler:
Quoted 32 lines
Am 14.12.2012 14:08, schrieb Alexander Holler:
Quoted 15 lines
Am 14.12.2012 10:42, schrieb Lars-Peter Clausen:
Quoted 6 lines
And another thing I've overlooked before:
wait_for_completion_interruptible_timeoutcan either return a positive number when the completion was completed, 0 in case of an timeout, or a negative error code in case it was interrupted. You need to handle all three. E.g. something like this.Quoted 6 lines
ret =
wait_for_completion_interruptible_timeout(...)if (ret == 0)return -EIO;if (ret < 0)
return retQuoted 2 lines
Hmpf, the only working approach to use some in kernel functions really is to the read source yourself and don't trust anything else. :/
Anyway, my approach doesn't work as it introduces a race condition:
/* get a report with all values through requesting one value */
sensor_hub_input_attr_get_raw_value(...)/* race if this task goes to slepp and the values were received before it could call the below wait...
/* wait for all values (event) */
if (!wait_for_completion_interruptible_timeout(...))
Quoted 9 lines
Quoted 2 lines
I'll have to look for a mechanism how to avoid that. So v5 might need some time.
Sorry for the noise. That
INIT_COMPLETION()before the sensor...() does exactly that. So it's enough if I handle the different return situations of wait_for...().I will just use if(wait...()<=0) return
-EIO.
No, that's wrong. You should really return the error code returned by wait_for_completion_interruptible_timeout(). This will make sure that userspace restarts the syscall if necessary.
- Lars
Re: [PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
Am 14.12.2012 15:34, schrieb Lars-Peter Clausen:
Quoted 41 lines · Alexander Holler
Quoted 40 lines
Am 14.12.2012 15:15, schrieb Alexander Holler:
Quoted 28 lines
Am 14.12.2012 14:08, schrieb Alexander Holler:
Quoted 15 lines
Am 14.12.2012 10:42, schrieb Lars-Peter Clausen:
Quoted 6 lines
And another thing I've overlooked before:
wait_for_completion_interruptible_timeoutcan either return a positive number when the completion was completed, 0 in case of an timeout, or a negative error code in case it was interrupted. You need to handle all three. E.g. something like this.Quoted 6 lines
ret =
wait_for_completion_interruptible_timeout(...)if (ret == 0)return -EIO;if (ret < 0)
return retQuoted 2 lines
Hmpf, the only working approach to use some in kernel functions really is to the read source yourself and don't trust anything else. :/
Anyway, my approach doesn't work as it introduces a race condition:
/* get a report with all values through requesting one value */
sensor_hub_input_attr_get_raw_value(...)/* race if this task goes to slepp and the values were received before it could call the below wait...
Quoted 6 lines
/* wait for all values (event) */
if (!wait_for_completion_interruptible_timeout(...))I'll have to look for a mechanism how to avoid that. So v5 might need some time.
Sorry for the noise. That
INIT_COMPLETION()before the sensor...() does exactly that. So it's enough if I handle the different return situations of wait_for...().
Quoted 6 lines
Quoted 2 lines
I will just use if(wait...()<=0) return
-EIO.No, that's wrong. You should really return the error code returned by
wait_for_completion_interruptible_timeout(). This will make sure that userspace restarts the syscall if necessary.
Sorry for my ignorance, but which reasons for interruption do exist which doesn't kill the userspace too? The error number -ESYSRESTART doesn't offer a hint.
Alexander
Re: [PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
Quoted 45 lines · Alexander Holler
Am 14.12.2012 15:34, schrieb Lars-Peter Clausen:
Quoted 44 lines · Alexander Holler
Quoted 42 lines
Am 14.12.2012 15:15, schrieb Alexander Holler:
Quoted 28 lines
Am 14.12.2012 14:08, schrieb Alexander Holler:
Quoted 15 lines
Am 14.12.2012 10:42, schrieb Lars-Peter Clausen:
Quoted 6 lines
And another thing I've overlooked before:
wait_for_completion_interruptible_timeoutcan either return a positive number when the completion was completed, 0 in case of an timeout, or a negative error code in case it was interrupted. You need to handle all three. E.g. something like this.Quoted 6 lines
ret =
wait_for_completion_interruptible_timeout(...)if (ret == 0)return -EIO;if (ret < 0)
return retQuoted 2 lines
Hmpf, the only working approach to use some in kernel functions really is to the read source yourself and don't trust anything else. :/
Anyway, my approach doesn't work as it introduces a race condition:
/* get a report with all values through requesting one value */
sensor_hub_input_attr_get_raw_value(...)/* race if this task goes to slepp and the values were received before it could call the below wait...
Quoted 6 lines
/* wait for all values (event) */
if (!wait_for_completion_interruptible_timeout(...))I'll have to look for a mechanism how to avoid that. So v5 might need some time.
Sorry for the noise. That
INIT_COMPLETION()before the sensor...() does exactly that. So it's enough if I handle the different return situations of wait_for...().I will just use if(wait...()<=0) return
-EIO.
Quoted 7 lines
Quoted 3 lines
No, that's wrong. You should really return the error code returned by
wait_for_completion_interruptible_timeout(). This will make sure that userspace restarts the syscall if necessary.Sorry for my ignorance, but which reasons for interruption do exist which doesn't kill the userspace too? The error number
-ESYSRESTARTdoesn't offer a hint.
Well I'm not an expert on this either, but as far as I know any signal the process is listening on can cause an interruption. Most signals won't kill the process though. More on the whole restart stuff:
http://lwn.net/Articles/528935/
- Lars
Re: [PATCH 4/4 v4] rtc: add rtc-driver for HID sensors of type time
Am 14.12.2012 17:33, schrieb Lars-Peter Clausen:
Quoted 55 lines · Alexander Holler
Quoted 45 lines
Am 14.12.2012 15:34, schrieb Lars-Peter Clausen:
Quoted 44 lines · Alexander Holler
Quoted 42 lines
Am 14.12.2012 15:15, schrieb Alexander Holler:
Quoted 28 lines
Am 14.12.2012 14:08, schrieb Alexander Holler:
Quoted 15 lines
Am 14.12.2012 10:42, schrieb Lars-Peter Clausen:
Quoted 6 lines
And another thing I've overlooked before:
wait_for_completion_interruptible_timeoutcan either return a positive number when the completion was completed, 0 in case of an timeout, or a negative error code in case it was interrupted. You need to handle all three. E.g. something like this.Quoted 6 lines
ret =
wait_for_completion_interruptible_timeout(...)if (ret == 0)return -EIO;if (ret < 0)
return retQuoted 2 lines
Hmpf, the only working approach to use some in kernel functions really is to the read source yourself and don't trust anything else. :/
Anyway, my approach doesn't work as it introduces a race condition:
/* get a report with all values through requesting one value */
sensor_hub_input_attr_get_raw_value(...)/* race if this task goes to slepp and the values were received before it could call the below wait...
Quoted 6 lines
/* wait for all values (event) */
if (!wait_for_completion_interruptible_timeout(...))I'll have to look for a mechanism how to avoid that. So v5 might need some time.
Sorry for the noise. That
INIT_COMPLETION()before the sensor...() does exactly that. So it's enough if I handle the different return situations of wait_for...().I will just use if(wait...()<=0) return
-EIO.Quoted 7 lines
Quoted 3 lines
No, that's wrong. You should really return the error code returned by
wait_for_completion_interruptible_timeout(). This will make sure that userspace restarts the syscall if necessary.Sorry for my ignorance, but which reasons for interruption do exist which doesn't kill the userspace too? The error number
-ESYSRESTARTdoesn't offer a hint.
Quoted 4 lines
Well I'm not an expert on this either, but as far as I know any signal the process is listening on can cause an interruption. Most signals won't kill the process though. More on the whole restart stuff:
http://lwn.net/Articles/528935/
I've come to the conclusion that using wait_for_completion_interruptible_timeout() isn't what should be used here and will switch to wait_for_completion_killable_timeout(). Here are my reasons:
1. I don't think any caller of rtc_ops.read_time will be prepared to handle -ESYSRESTART.
2. Someone wants the time. Beeing interruptible seems to mean the process might be interrupted by signal processing with an unknown long duration which could decrease the accuracy even below the desired one second (which doesn't look unlikely, signal processing in userspace is unpredictable and (mis)used for all kind of stuff).
3. I've primarily used it to be friendly in means of killable, but didn't know that ..._killable() does exist. ;)
Btw., here is a imho good and especially short introduction about the task states along with some pointers to more comprehensive resources:
http://www.ibm.com/developerworks/linux/library/l-task-killable/
v5 of that patch will follow. Hopefully the last one necessary.
Regards,
Alexander
PATCH v5 4/4 rtc: add rtc-driver for HID sensors of type time
This driver makes the time from HID sensors (hubs) which are offering such available like any other RTC does.
It is necessary that all values like year, month etc, are send as 8bit values (1 byte each) and all of them in 1 report. Also the spec HUTRR39b doesn't define the range of the year field, we tread it as 0 - 99 because that's what most RTCs I know about are offering.
Currently the time can only be read. Setting the time must be done through sending a report (or a feature). The spec currently doesn't define how and I'm not sure if I just should define something by myself.
--- drivers/rtc/Kconfig | 16 ++ drivers/rtc/Makefile | 1 + drivers/rtc/rtc-hid-sensor-time.c | 291 +++++++++++++++++++++++++++++++++++++ 3 files changed, 308 insertions(+), 0 deletions(-) create mode 100644 drivers/rtc/rtc-hid-sensor-time.c
drivers/rtc/Kconfig +16 -0
@@ -1144,4 +1144,20 @@ config RTC_DRV_SNVS This driver can also be built as a module, if so, the module will be called "rtc-snvs". +comment "HID Sensor RTC drivers" + +config RTC_DRV_HID_SENSOR_TIME + tristate "HID Sensor Time" + depends on USB_HID + select IIO + select HID_SENSOR_HUB + select HID_SENSOR_IIO_COMMON + help + Say yes here to build support for the HID Sensors of type Time. + This drivers makes such sensors available as RTCs. + + If this driver is compiled as a module, it will be named + rtc-hid-sensor-time. + + endif # RTC_CLASS
drivers/rtc/Makefile +1 -0
@@ -51,6 +51,7 @@ obj-$(CONFIG_RTC_DRV_EM3027) += rtc-em3027.o obj-$(CONFIG_RTC_DRV_EP93XX) += rtc-ep93xx.o obj-$(CONFIG_RTC_DRV_FM3130) += rtc-fm3130.o obj-$(CONFIG_RTC_DRV_GENERIC) += rtc-generic.o +obj-$(CONFIG_RTC_DRV_HID_SENSOR_TIME) += rtc-hid-sensor-time.o obj-$(CONFIG_RTC_DRV_IMXDI) += rtc-imxdi.o obj-$(CONFIG_RTC_DRV_ISL1208) += rtc-isl1208.o obj-$(CONFIG_RTC_DRV_ISL12022) += rtc-isl12022.o
drivers/rtc/rtc-hid-sensor-time.c new file +291 -0
291 lines not on this page · raw message
Signature · 1 line
1.7.8.6
Jonathan Cameron
maintainerRe: [PATCH 1/4 v2] iio: hid-sensors: respect CONFIG_IIO_TRIGGER
In reply to Alexander HollerQuoted 6 lines · Alexander Holler
Not much to say, without that change, hid-sensor-trigger will be always compiled if
HID_SENSOR_IIO_COMMONis selected which fails ifCONFIG_IIO_TRIGGERis not set becauseCONFIG_IIO_CONSUMERS_PER_TRIGGERwill not be defined.Signed-off-by Alexander Holler <[email protected]>
Not sure what tree this was against as it is needs some fixing up for staging-next and currently mainline. Ah well fixed up and added to togreg branch of
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.git
Please check I haven't messed it up.
Quoted 100 lines
--- drivers/iio/accel/Kconfig | 1 + drivers/iio/common/hid-sensors/Kconfig | 13 ++++++++++++- drivers/iio/common/hid-sensors/Makefile | 3 ++- drivers/iio/gyro/Kconfig | 1 + drivers/iio/light/Kconfig | 1 + drivers/iio/magnetometer/Kconfig | 1 + 6 files changed, 18 insertions(+), 2 deletions(-)drivers/iio/accel/Kconfig +1
-0@@ -8,6 +8,7 @@ config HID_SENSOR_ACCEL_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Acelerometers 3D" help Say yes here to build support for the HID SENSORdrivers/iio/common/hid-sensors/Kconfig +12
-1@@ -6,7 +6,7 @@ menu "Hid Sensor IIO Common" config HID_SENSOR_IIO_COMMON tristate "Common modules for all HID Sensor IIO drivers" depends on HID_SENSOR_HUB - select IIO_TRIGGER if IIO_BUFFER + select HID_SENSOR_IIO_TRIGGER if IIO_BUFFER help Say yes here to build support for HID sensor to use HID sensor common processing for attributes and IIO triggers.@@ -14,6 +14,17 @@ config HID_SENSOR_IIO_COMMON HID sensor drivers, this module contains processing for those attributes. +config HID_SENSOR_IIO_TRIGGER + tristate "Common module (trigger) for all HID Sensor IIO drivers" + depends on HID_SENSOR_HUB && HID_SENSOR_IIO_COMMON + select IIO_TRIGGER + help + Say yes here to build trigger support for HID sensors. + Triggers will be send if all requested attributes were read. + + If this driver is compiled as a module, it will be named + hid-sensor-trigger. + config HID_SENSOR_ENUM_BASE_QUIRKS tristate "ENUM base quirks for HID Sensor IIO drivers" depends on HID_SENSOR_IIO_COMMONdrivers/iio/common/hid-sensors/Makefile +2
-1@@ -3,4 +3,5 @@ # obj-$(CONFIG_HID_SENSOR_IIO_COMMON) += hid-sensor-iio-common.o -hid-sensor-iio-common-y := hid-sensor-attributes.o hid-sensor-trigger.o +obj-$(CONFIG_HID_SENSOR_IIO_TRIGGER) += hid-sensor-trigger.o +hid-sensor-iio-common-y := hid-sensor-attributes.odrivers/iio/gyro/Kconfig +1
-0@@ -8,6 +8,7 @@ config HID_SENSOR_GYRO_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Gyroscope 3D" help Say yes here to build support for the HID SENSORdrivers/iio/light/Kconfig +1
-0@@ -47,6 +47,7 @@ config HID_SENSOR_ALS select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID ALS" help Say yes here to build support for the HID SENSORdrivers/iio/magnetometer/Kconfig +1
-0@@ -8,6 +8,7 @@ config HID_SENSOR_MAGNETOMETER_3D select IIO_BUFFER select IIO_TRIGGERED_BUFFER select HID_SENSOR_IIO_COMMON + select HID_SENSOR_IIO_TRIGGER tristate "HID Magenetometer 3D" help Say yes here to build support for the HID SENSOR
Re: [PATCH 1/4 v2] iio: hid-sensors: respect CONFIG_IIO_TRIGGER
Am 15.12.2012 11:54, schrieb Jonathan Cameron:
Quoted 11 lines · Alexander Holler
Quoted 6 lines
Not much to say, without that change, hid-sensor-trigger will be always compiled if
HID_SENSOR_IIO_COMMONis selected which fails ifCONFIG_IIO_TRIGGERis not set becauseCONFIG_IIO_CONSUMERS_PER_TRIGGERwill not be defined.Signed-off-by Alexander Holler <[email protected]>Not sure what tree this was against as it is needs some fixing up for staging-next and currently mainline. Ah well fixed up and added to togreg branch of
Should have been 3.7(-rcN).
Quoted 4 lines
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio.gitPlease check I haven't messed it up.
Still looks like what I have here.
Thanks,
Alexander
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
In reply to Lars-Peter ClausenQuoted 8 lines · On Tue, 11 Dec 2012 10:40:01 +0100 Lars-Peter Clausen <[email protected]> wrote:
Quoted 4 lines
Yes, move the header or merge into existing one as makes sense. I'm not pulling this driver into the IIO tree (unless for some reason Alessandro wants me to and I can't think why he would...).
Alessandro has been pretty quiet for quite some time now. Luckily Andrew Morton usually picks up the stuff for orphaned subsystems. So put him on Cc for v4.
Still reading e-mails ;) Andrew monitors the rtc mailing list and picks up the patches that do not need to go in any arch's main tree, which is the suggested way as, with modern chipsets, the RTCs shares hw with many other drivers.
Signature · 6 lines
Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Am 16.12.2012 23:15, schrieb Alessandro Zummo:
Quoted 8 lines
Quoted 5 lines · On Tue, 11 Dec 2012 10:40:01 +0100 Lars-Peter Clausen <[email protected]> wrote:
Quoted 4 lines
Yes, move the header or merge into existing one as makes sense. I'm not pulling this driver into the IIO tree (unless for some reason Alessandro wants me to and I can't think why he would...).
Quoted 7 lines
Quoted 3 lines
Alessandro has been pretty quiet for quite some time now. Luckily Andrew Morton usually picks up the stuff for orphaned subsystems. So put him on Cc for v4.
Still reading e-mails ;) Andrew monitors the rtc mailing list and picks up the patches that do not need to go in any arch's main tree, which is the suggested way as, with modern chipsets, the RTCs shares hw with many other drivers.
Reading just the latest patch (v5) might be faster. ;)
It basically doesn't do much. On call of read_time() a so called report with the time values (year, month, ...) is requested from the device, rtc_time is filled with them, done.
Regards,
Alexander
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
In reply to Lars-Peter ClausenAm 10.12.2012 18:05, schrieb Lars-Peter Clausen:
Quoted 6 lines · Alexander Holler
The channel spec is semi unused. You use it to lookup the scan index and the name, but that could easily be implemented without the channel spec. Especially considering that the scan index lookup is only ever done for channel 0, which will always return
CHANNEL_SCAN_INDEX_YEAR.
Thats what I had in mind for v3.
Quoted 9 lines
Are the entries in info ordered in the same way as the addresses in
hid_time_addresses? If yes you could just use a lookup-table likestatic const char * const hid_time_attrib_names[] = { "second", ... };and just use 'i' to look them up.
Again, what I had in mind for v3. It would have been better I wouldn't have used one of the existing drivers as template and afterwards removing tons of stuff. ;)
Quoted 4 lines
drivers/iio/time/hid-sensor-time.c line 239
Quoted 1 line
drivers/iio/time/hid-sensor-time.c new file +1
-0+init_completion (&time_state->comp_last_time);This needs to be
INIT_COMPLETION.init_completionmust be called exactly once on a completion, which should be from insideprobe()in this case.
Ah, so I've misread http://lwn.net/Articles/23993/ . I've read it as init_completion() is usable multiple times (I had the impression INIT_COMPLETION got replaced by init_completion().
Quoted 6 lines
drivers/iio/time/hid-sensor-time.c line 248
Quoted 3 lines
drivers/iio/time/hid-sensor-time.c new file +3
-0+/* wait for all values (event) */ +wait_for_completion_interruptible_timeout (&time_state->comp_last_time, +HZ *6 );You should check the return value in case either a timeout happens or the sleep is interrupted.
Yes, I already wanted to do it, but it seems I've forgotten it.
Quoted 5 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ struct hid_time_state *time_state = + kzalloc(sizeof(struct hid_time_state), GFP_KERNEL);You could use
devm_kzallochere. By doing so you don't have to take care of freeing it again since it will be auto-freed once the device is removed.
Thanks. I already searched such and wondered why such didn't exist. Just to clarify, if I use devm_kzalloc, I don't have to free time_state here
Quoted 6 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+error_free_drvdata: + platform_set_drvdata(pdev, NULL);Setting the platform data to NULL should not be necessary. Some drivers do this but it's kind of the result of cargo-cult-coding.
Quoted 15 lines
Quoted 4 lines
drivers/iio/time/hid-sensor-time.c new file +4
-0+kfree (time_state); +error_ret: +return ret; +}drivers/iio/time/hid-sensor-time.c line 328
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+ +static int __devinit hid_time_remove (struct platform_device *pdev) +{ +struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data; +struct hid_time_state *time_state =platform_get_drvdata (pdev); + +if (!IS_ERR (time_state->rtc)) +rtc_device_unregister (time_state->rtc); +sensor_hub_remove_callback (hsdev,HID_USAGE_SENSOR_TIME ); +platform_set_drvdata (pdev,NULL );
and here?
Quoted 8 lines
Same here.
Quoted 5 lines
drivers/iio/time/hid-sensor-time.c new file +5
-0+kfree (time_state); + +return 0 ; +} +[...]
Regards,
Alexander
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Quoted 10 lines · Alexander Holler
[...]
Quoted 4 lines
Quoted 1 line
+
init_completion(&time_state->comp_last_time);This needs to be
INIT_COMPLETION.init_completionmust be called exactly once on a completion, which should be from insideprobe()in this case.Ah, so I've misread http://lwn.net/Articles/23993/ . I've read it as
init_completion()is usable multiple times (I had the impressionINIT_COMPLETIONgot replaced byinit_completion().
Well, I've been exaggerating a bit, you can call it multiple times, but you need to make sure that the completion is not in use at the same time, since init_completion will completely reinitialize the struct and if it is in use at the same time you'll get undefined behavior. So it is a good rule of thumb to just use it once in probe(). INIT_COMPLETION on the other hand will just clear the done flag, so you know that between your call to INIT_COMPLETION and when wait_for_completion returns successfully your event has occurred at least once.
Quoted 43 lines
Quoted 7 lines
Quoted 4 lines
(quoted diff) +2
-0+ /* wait for all values (event) */ +wait_for_completion_interruptible_timeout(&time_state->comp_last_time,
+ HZ*6);You should check the return value in case either a timeout happens or the sleep is interrupted.
Yes, I already wanted to do it, but it seems I've forgotten it.
Quoted 6 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+ struct hid_time_state *time_state = + kzalloc(sizeof(struct hid_time_state), GFP_KERNEL);You could use
devm_kzallochere. By doing so you don't have to take care of
freeing it again since it will be auto-freed once the device is removed.Thanks. I already searched such and wondered why such didn't exist. Just to clarify, if I use
devm_kzalloc, I don't have to freetime_statehereQuoted 7 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+error_free_drvdata: + platform_set_drvdata(pdev, NULL);Setting the platform data to NULL should not be necessary. Some drivers do
this but it's kind of the result of cargo-cult-coding.Quoted 15 lines
Quoted 4 lines
drivers/iio/time/hid-sensor-time.c new file +4
-0+kfree (time_state); +error_ret: +return ret; +}drivers/iio/time/hid-sensor-time.c line 328
Quoted 10 lines
drivers/iio/time/hid-sensor-time.c new file +10
-0+ +static int __devinit hid_time_remove (struct platform_device *pdev) +{ +struct hid_sensor_hub_device *hsdev = pdev->dev.platform_data; +struct hid_time_state *time_state =platform_get_drvdata (pdev); + +if (!IS_ERR (time_state->rtc)) +rtc_device_unregister (time_state->rtc); +sensor_hub_remove_callback (hsdev,HID_USAGE_SENSOR_TIME ); +platform_set_drvdata (pdev,NULL );
Quoted 2 lines
and here?
yes.
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Am 10.12.2012 23:36, schrieb Lars-Peter Clausen:
Quoted 1 line
Well, I've been exaggerating a bit, you can call it multiple times, but you
Thanks a lot for the explanation(s).
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+error_free_drvdata: + platform_set_drvdata(pdev, NULL);Setting the platform data to NULL should not be necessary. Some drivers do
this but it's kind of the result of cargo-cult-coding.Quoted 1 line
+
kfree(time_state);
Btw. I wouldn't call that cargo-cult-coding. It's more defensive programming as people might not be sure, if there is something around which still might access the platform data at that point. Ok, there would be a need for a mutex or similiar if that really could happen, but I wouldn't call such practices cargo-cult. ;)
Regards,
Alexander
Re: [PATCH 3/3 v2] iio: add rtc-driver for HID sensors of type time
Quoted 12 lines · On Tue, 11 Dec 2012 01:01:29 +0100 Alexander Holler <[email protected]>…
Am 10.12.2012 23:36, schrieb Lars-Peter Clausen:
Quoted 1 line
Well, I've been exaggerating a bit, you can call it multiple times, but you
Thanks a lot for the explanation(s).
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Review
Quoted 2 lines
(quoted diff) +2
-0+error_free_drvdata: + platform_set_drvdata(pdev, NULL);Setting the platform data to NULL should not be necessary. Some drivers do
this but it's kind of the result of cargo-cult-coding.
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
+
kfree(time_state);Btw. I wouldn't call that cargo-cult-coding. It's more defensive programming as people might not be sure, if there is something around which still might access the platform data at that point. Ok, there would be a need for a mutex or similiar if that really could happen, but I wouldn't call such practices cargo-cult. ;)
Agreed - pointer NULLing catches a lot of mistakes during teardown where timers or interrupts running in parallel get missed.
Alan