Re: [PATCH] adc: correctly check return value

[Hartmut Knaack]

Insu Yun schrieb am 19.10.2015 um 18:08:
> Since devm_regulator_get returns address or error, not NULL,
> it needs to be checked with IS_ERR, not IS_ERR_OR_NULL.
> 

Actually, it does return NULL, if regulator support is disabled
(see [1]).

[1]http://lxr.free-electrons.com/source/include/linux/regulator/consumer.h#L286

> Signed-off-by: Insu Yun 
> ---
>  drivers/iio/adc/ad7266.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/ad7266.c b/drivers/iio/adc/ad7266.c
> index 70f78c3..26cd54b 100644
> --- a/drivers/iio/adc/ad7266.c
> +++ b/drivers/iio/adc/ad7266.c
> @@ -397,7 +397,7 @@ static int ad7266_probe(struct spi_device *spi)
>   st = iio_priv(indio_dev);
>  
>   st->reg = devm_regulator_get(>dev, "vref");
> - if (!IS_ERR_OR_NULL(st->reg)) {
> + if (!IS_ERR(st->reg)) {
>   ret = regulator_enable(st->reg);
>   if (ret)
>   return ret;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] adc: correctly check return value

[Hartmut Knaack]

Insu Yun schrieb am 19.10.2015 um 18:08:
> Since devm_regulator_get returns address or error, not NULL,
> it needs to be checked with IS_ERR, not IS_ERR_OR_NULL.
> 

Actually, it does return NULL, if regulator support is disabled
(see [1]).

[1]http://lxr.free-electrons.com/source/include/linux/regulator/consumer.h#L286

> Signed-off-by: Insu Yun 
> ---
>  drivers/iio/adc/ad7266.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/adc/ad7266.c b/drivers/iio/adc/ad7266.c
> index 70f78c3..26cd54b 100644
> --- a/drivers/iio/adc/ad7266.c
> +++ b/drivers/iio/adc/ad7266.c
> @@ -397,7 +397,7 @@ static int ad7266_probe(struct spi_device *spi)
>   st = iio_priv(indio_dev);
>  
>   st->reg = devm_regulator_get(>dev, "vref");
> - if (!IS_ERR_OR_NULL(st->reg)) {
> + if (!IS_ERR(st->reg)) {
>   ret = regulator_enable(st->reg);
>   if (ret)
>   return ret;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/20] regmap: Add missing comments about struct regmap_bus

[Hartmut Knaack]

Markus Pargmann schrieb am 12.08.2015 um 12:12:
> There are some fields of this struct undocumented or old. This patch
> updates the missing comments.
> 
> Signed-off-by: Markus Pargmann 
> ---
>  include/linux/regmap.h | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/include/linux/regmap.h b/include/linux/regmap.h
> index 59c55ea0f0b5..6ff83c9ddb45 100644
> --- a/include/linux/regmap.h
> +++ b/include/linux/regmap.h
> @@ -296,8 +296,11 @@ typedef void (*regmap_hw_free_context)(void *context);
>   *if not implemented  on a given device.
>   * @async_write: Write operation which completes asynchronously, optional and
>   *   must serialise with respect to non-async I/O.
> + * @reg_write: Write operation for a register. Writes value to register.
>   * @read: Read operation.  Data is returned in the buffer used to transmit
>   * data.
> + * @reg_read: Read operation for a register. Reads a value from a register.
> + * @free_conetext: Free context.

Typo: free_context

>   * @async_alloc: Allocate a regmap_async() structure.
>   * @read_flag_mask: Mask to be set in the top byte of the register when doing
>   *  a read.
> @@ -307,7 +310,6 @@ typedef void (*regmap_hw_free_context)(void *context);
>   * @val_format_endian_default: Default endianness for formatted register
>   * values. Used when the regmap_config specifies DEFAULT. If this is
>   * DEFAULT, BIG is assumed.
> - * @async_size: Size of struct used for async work.
>   */
>  struct regmap_bus {
>   bool fast_io;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/20] regmap: Add missing comments about struct regmap_bus

[Hartmut Knaack]

Markus Pargmann schrieb am 12.08.2015 um 12:12:
 There are some fields of this struct undocumented or old. This patch
 updates the missing comments.
 
 Signed-off-by: Markus Pargmann m...@pengutronix.de
 ---
  include/linux/regmap.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/include/linux/regmap.h b/include/linux/regmap.h
 index 59c55ea0f0b5..6ff83c9ddb45 100644
 --- a/include/linux/regmap.h
 +++ b/include/linux/regmap.h
 @@ -296,8 +296,11 @@ typedef void (*regmap_hw_free_context)(void *context);
   *if not implemented  on a given device.
   * @async_write: Write operation which completes asynchronously, optional and
   *   must serialise with respect to non-async I/O.
 + * @reg_write: Write operation for a register. Writes value to register.
   * @read: Read operation.  Data is returned in the buffer used to transmit
   * data.
 + * @reg_read: Read operation for a register. Reads a value from a register.
 + * @free_conetext: Free context.

Typo: free_context

   * @async_alloc: Allocate a regmap_async() structure.
   * @read_flag_mask: Mask to be set in the top byte of the register when doing
   *  a read.
 @@ -307,7 +310,6 @@ typedef void (*regmap_hw_free_context)(void *context);
   * @val_format_endian_default: Default endianness for formatted register
   * values. Used when the regmap_config specifies DEFAULT. If this is
   * DEFAULT, BIG is assumed.
 - * @async_size: Size of struct used for async work.
   */
  struct regmap_bus {
   bool fast_io;
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/6] iio: buffer: Fix kernel docs warnings

[Hartmut Knaack]

Hartmut Knaack schrieb am 02.08.2015 um 21:32:
> Jonathan Cameron schrieb am 02.08.2015 um 19:27:
>> On 24/07/15 14:18, Cristina Opriceana wrote:
>>> Fix kernel docs for structures and functions in order to
>>> remove some warnings when the documentation gets generated.
>>>
>>> Signed-off-by: Cristina Opriceana 
>> Applied with another typo fixed up.
> 
> Hi,
> I'm afraid there is some information missing.
> 
>>> ---
>>>  drivers/iio/industrialio-buffer.c | 15 ++-
>>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/iio/industrialio-buffer.c 
>>> b/drivers/iio/industrialio-buffer.c
>>> index b13f941..a671953 100644
>>> --- a/drivers/iio/industrialio-buffer.c
>>> +++ b/drivers/iio/industrialio-buffer.c
>>> @@ -91,9 +91,16 @@ static bool iio_buffer_ready(struct iio_dev *indio_dev, 
>>> struct iio_buffer *buf,
>>>  
>>>  /**
>>>   * iio_buffer_read_first_n_outer() - chrdev read for buffer access
>>> + * @filp:  File structure pointer for the char device
>>> + * @buf:   Destination buffer for iio buffer read
>>> + * @n: First n bytes to read
>>> + * @f_ps:  Long offset provided by the user as a seek position
>>>   *
>>>   * This function relies on all buffer implementations having an
>>>   * iio_buffer as their first element.
>>> + *
>>> + * Return: negative values corresponding to error codes or ret != 0
>>> + *for ending the reading activity
> 
> This may also return 0. Would it be wrong to state that if the return
> value is not negative, then it will indicate the amount of data read?
> 
>>>   **/
>>>  ssize_t iio_buffer_read_first_n_outer(struct file *filp, char __user *buf,
>>>   size_t n, loff_t *f_ps)
>>> @@ -143,6 +150,12 @@ ssize_t iio_buffer_read_first_n_outer(struct file 
>>> *filp, char __user *buf,
>>>  
>>>  /**
>>>   * iio_buffer_poll() - poll the buffer to find out if it has data
>>> + * @filp:  File structure poiner for device access
>> pointer
>>> + * @wait:  Poll table structure pointer for which the driver adds
>>> + * a wait queue
>>> + *
>>> + * Return: (POLLIN | POLLRDNORM) if data is available for reading
>>> + *or 0 for other cases
> 
> This can also return -ENODEV.

On second thought however, it may return anything, given it is unsigned int.
Any volunteers?

> 
>>>   */
>>>  unsigned int iio_buffer_poll(struct file *filp,
>>>  struct poll_table_struct *wait)
>>> @@ -1136,7 +1149,7 @@ int iio_scan_mask_query(struct iio_dev *indio_dev,
>>>  EXPORT_SYMBOL_GPL(iio_scan_mask_query);
>>>  
>>>  /**
>>> - * struct iio_demux_table() - table describing demux memcpy ops
>>> + * struct iio_demux_table - table describing demux memcpy ops
>>>   * @from:  index to copy from
>>>   * @to:index to copy to
>>>   * @length:how many bytes to copy
>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] iio: event: Add missing fields in kernel docs

[Hartmut Knaack]

Jonathan Cameron schrieb am 02.08.2015 um 19:33:
> On 24/07/15 14:21, Cristina Opriceana wrote:
>> Fix kernel docs warnings by adding the missing fields,
>> each with its associated description.
>>
>> Signed-off-by: Cristina Opriceana 
> Applied.  Thanks
> 
> Jonathan
>> ---
>>  drivers/iio/industrialio-event.c | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/drivers/iio/industrialio-event.c 
>> b/drivers/iio/industrialio-event.c
>> index 894d813..b2f63f9 100644
>> --- a/drivers/iio/industrialio-event.c
>> +++ b/drivers/iio/industrialio-event.c
>> @@ -32,6 +32,7 @@
>>   * @dev_attr_list:  list of event interface sysfs attribute
>>   * @flags:  file operations related flags including busy flag.
>>   * @group:  event interface sysfs attribute group
>> + * @read_lock:  lock to protect kfifo read operations
>>   */
>>  struct iio_event_interface {
>>  wait_queue_head_t   wait;
>> @@ -75,6 +76,11 @@ EXPORT_SYMBOL(iio_push_event);
>>  
>>  /**
>>   * iio_event_poll() - poll the event queue to find out if it has data
>> + * @filep:  File structure pointer to identify the device
>> + * @wait:   Poll table pointer to add the wait queue on
>> + *
>> + * Return: (POLLIN | POLLRDNORM) if data is available for reading
>> + * or a negative error code on failure

This can also return 0 if no data is available.

Actually, being unsigned int, the intended negative error code won't
appear - ouch! Any volunteers to address this issue?

>>   */
>>  static unsigned int iio_event_poll(struct file *filep,
>>   struct poll_table_struct *wait)
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/6] iio: buffer: Fix kernel docs warnings

[Hartmut Knaack]

Jonathan Cameron schrieb am 02.08.2015 um 19:27:
> On 24/07/15 14:18, Cristina Opriceana wrote:
>> Fix kernel docs for structures and functions in order to
>> remove some warnings when the documentation gets generated.
>>
>> Signed-off-by: Cristina Opriceana 
> Applied with another typo fixed up.

Hi,
I'm afraid there is some information missing.

>> ---
>>  drivers/iio/industrialio-buffer.c | 15 ++-
>>  1 file changed, 14 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/iio/industrialio-buffer.c 
>> b/drivers/iio/industrialio-buffer.c
>> index b13f941..a671953 100644
>> --- a/drivers/iio/industrialio-buffer.c
>> +++ b/drivers/iio/industrialio-buffer.c
>> @@ -91,9 +91,16 @@ static bool iio_buffer_ready(struct iio_dev *indio_dev, 
>> struct iio_buffer *buf,
>>  
>>  /**
>>   * iio_buffer_read_first_n_outer() - chrdev read for buffer access
>> + * @filp:   File structure pointer for the char device
>> + * @buf:Destination buffer for iio buffer read
>> + * @n:  First n bytes to read
>> + * @f_ps:   Long offset provided by the user as a seek position
>>   *
>>   * This function relies on all buffer implementations having an
>>   * iio_buffer as their first element.
>> + *
>> + * Return: negative values corresponding to error codes or ret != 0
>> + * for ending the reading activity

This may also return 0. Would it be wrong to state that if the return
value is not negative, then it will indicate the amount of data read?

>>   **/
>>  ssize_t iio_buffer_read_first_n_outer(struct file *filp, char __user *buf,
>>size_t n, loff_t *f_ps)
>> @@ -143,6 +150,12 @@ ssize_t iio_buffer_read_first_n_outer(struct file 
>> *filp, char __user *buf,
>>  
>>  /**
>>   * iio_buffer_poll() - poll the buffer to find out if it has data
>> + * @filp:   File structure poiner for device access
> pointer
>> + * @wait:   Poll table structure pointer for which the driver adds
>> + *  a wait queue
>> + *
>> + * Return: (POLLIN | POLLRDNORM) if data is available for reading
>> + * or 0 for other cases

This can also return -ENODEV.

>>   */
>>  unsigned int iio_buffer_poll(struct file *filp,
>>   struct poll_table_struct *wait)
>> @@ -1136,7 +1149,7 @@ int iio_scan_mask_query(struct iio_dev *indio_dev,
>>  EXPORT_SYMBOL_GPL(iio_scan_mask_query);
>>  
>>  /**
>> - * struct iio_demux_table() - table describing demux memcpy ops
>> + * struct iio_demux_table - table describing demux memcpy ops
>>   * @from:   index to copy from
>>   * @to: index to copy to
>>   * @length: how many bytes to copy
>>
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/6] iio: buffer: Fix kernel docs warnings

[Hartmut Knaack]

Jonathan Cameron schrieb am 02.08.2015 um 19:27:
 On 24/07/15 14:18, Cristina Opriceana wrote:
 Fix kernel docs for structures and functions in order to
 remove some warnings when the documentation gets generated.

 Signed-off-by: Cristina Opriceana cristina.oprice...@gmail.com
 Applied with another typo fixed up.

Hi,
I'm afraid there is some information missing.

 ---
  drivers/iio/industrialio-buffer.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

 diff --git a/drivers/iio/industrialio-buffer.c 
 b/drivers/iio/industrialio-buffer.c
 index b13f941..a671953 100644
 --- a/drivers/iio/industrialio-buffer.c
 +++ b/drivers/iio/industrialio-buffer.c
 @@ -91,9 +91,16 @@ static bool iio_buffer_ready(struct iio_dev *indio_dev, 
 struct iio_buffer *buf,
  
  /**
   * iio_buffer_read_first_n_outer() - chrdev read for buffer access
 + * @filp:   File structure pointer for the char device
 + * @buf:Destination buffer for iio buffer read
 + * @n:  First n bytes to read
 + * @f_ps:   Long offset provided by the user as a seek position
   *
   * This function relies on all buffer implementations having an
   * iio_buffer as their first element.
 + *
 + * Return: negative values corresponding to error codes or ret != 0
 + * for ending the reading activity

This may also return 0. Would it be wrong to state that if the return
value is not negative, then it will indicate the amount of data read?

   **/
  ssize_t iio_buffer_read_first_n_outer(struct file *filp, char __user *buf,
size_t n, loff_t *f_ps)
 @@ -143,6 +150,12 @@ ssize_t iio_buffer_read_first_n_outer(struct file 
 *filp, char __user *buf,
  
  /**
   * iio_buffer_poll() - poll the buffer to find out if it has data
 + * @filp:   File structure poiner for device access
 pointer
 + * @wait:   Poll table structure pointer for which the driver adds
 + *  a wait queue
 + *
 + * Return: (POLLIN | POLLRDNORM) if data is available for reading
 + * or 0 for other cases

This can also return -ENODEV.

   */
  unsigned int iio_buffer_poll(struct file *filp,
   struct poll_table_struct *wait)
 @@ -1136,7 +1149,7 @@ int iio_scan_mask_query(struct iio_dev *indio_dev,
  EXPORT_SYMBOL_GPL(iio_scan_mask_query);
  
  /**
 - * struct iio_demux_table() - table describing demux memcpy ops
 + * struct iio_demux_table - table describing demux memcpy ops
   * @from:   index to copy from
   * @to: index to copy to
   * @length: how many bytes to copy

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

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/6] iio: buffer: Fix kernel docs warnings

[Hartmut Knaack]

Hartmut Knaack schrieb am 02.08.2015 um 21:32:
 Jonathan Cameron schrieb am 02.08.2015 um 19:27:
 On 24/07/15 14:18, Cristina Opriceana wrote:
 Fix kernel docs for structures and functions in order to
 remove some warnings when the documentation gets generated.

 Signed-off-by: Cristina Opriceana cristina.oprice...@gmail.com
 Applied with another typo fixed up.
 
 Hi,
 I'm afraid there is some information missing.
 
 ---
  drivers/iio/industrialio-buffer.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

 diff --git a/drivers/iio/industrialio-buffer.c 
 b/drivers/iio/industrialio-buffer.c
 index b13f941..a671953 100644
 --- a/drivers/iio/industrialio-buffer.c
 +++ b/drivers/iio/industrialio-buffer.c
 @@ -91,9 +91,16 @@ static bool iio_buffer_ready(struct iio_dev *indio_dev, 
 struct iio_buffer *buf,
  
  /**
   * iio_buffer_read_first_n_outer() - chrdev read for buffer access
 + * @filp:  File structure pointer for the char device
 + * @buf:   Destination buffer for iio buffer read
 + * @n: First n bytes to read
 + * @f_ps:  Long offset provided by the user as a seek position
   *
   * This function relies on all buffer implementations having an
   * iio_buffer as their first element.
 + *
 + * Return: negative values corresponding to error codes or ret != 0
 + *for ending the reading activity
 
 This may also return 0. Would it be wrong to state that if the return
 value is not negative, then it will indicate the amount of data read?
 
   **/
  ssize_t iio_buffer_read_first_n_outer(struct file *filp, char __user *buf,
   size_t n, loff_t *f_ps)
 @@ -143,6 +150,12 @@ ssize_t iio_buffer_read_first_n_outer(struct file 
 *filp, char __user *buf,
  
  /**
   * iio_buffer_poll() - poll the buffer to find out if it has data
 + * @filp:  File structure poiner for device access
 pointer
 + * @wait:  Poll table structure pointer for which the driver adds
 + * a wait queue
 + *
 + * Return: (POLLIN | POLLRDNORM) if data is available for reading
 + *or 0 for other cases
 
 This can also return -ENODEV.

On second thought however, it may return anything, given it is unsigned int.
Any volunteers?

 
   */
  unsigned int iio_buffer_poll(struct file *filp,
  struct poll_table_struct *wait)
 @@ -1136,7 +1149,7 @@ int iio_scan_mask_query(struct iio_dev *indio_dev,
  EXPORT_SYMBOL_GPL(iio_scan_mask_query);
  
  /**
 - * struct iio_demux_table() - table describing demux memcpy ops
 + * struct iio_demux_table - table describing demux memcpy ops
   * @from:  index to copy from
   * @to:index to copy to
   * @length:how many bytes to copy


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

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

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/6] iio: event: Add missing fields in kernel docs

[Hartmut Knaack]

Jonathan Cameron schrieb am 02.08.2015 um 19:33:
 On 24/07/15 14:21, Cristina Opriceana wrote:
 Fix kernel docs warnings by adding the missing fields,
 each with its associated description.

 Signed-off-by: Cristina Opriceana cristina.oprice...@gmail.com
 Applied.  Thanks
 
 Jonathan
 ---
  drivers/iio/industrialio-event.c | 6 ++
  1 file changed, 6 insertions(+)

 diff --git a/drivers/iio/industrialio-event.c 
 b/drivers/iio/industrialio-event.c
 index 894d813..b2f63f9 100644
 --- a/drivers/iio/industrialio-event.c
 +++ b/drivers/iio/industrialio-event.c
 @@ -32,6 +32,7 @@
   * @dev_attr_list:  list of event interface sysfs attribute
   * @flags:  file operations related flags including busy flag.
   * @group:  event interface sysfs attribute group
 + * @read_lock:  lock to protect kfifo read operations
   */
  struct iio_event_interface {
  wait_queue_head_t   wait;
 @@ -75,6 +76,11 @@ EXPORT_SYMBOL(iio_push_event);
  
  /**
   * iio_event_poll() - poll the event queue to find out if it has data
 + * @filep:  File structure pointer to identify the device
 + * @wait:   Poll table pointer to add the wait queue on
 + *
 + * Return: (POLLIN | POLLRDNORM) if data is available for reading
 + * or a negative error code on failure

This can also return 0 if no data is available.

Actually, being unsigned int, the intended negative error code won't
appear - ouch! Any volunteers to address this issue?

   */
  static unsigned int iio_event_poll(struct file *filep,
   struct poll_table_struct *wait)

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

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] tools: iio: print error message when buffer enable fails

[Hartmut Knaack]

Irina Tirdea schrieb am 24.07.2015 um 15:28:
> Running generic_buffer without enabling any channel of the
> sensor will fail without printing any error message.
> 
> Add an error message that indicates buffer enable failed.
> 
> Signed-off-by: Irina Tirdea 
Acked-by: Hartmut Knaack 
> ---
>  tools/iio/generic_buffer.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
> index 32f389eb..9f7b85b 100644
> --- a/tools/iio/generic_buffer.c
> +++ b/tools/iio/generic_buffer.c
> @@ -364,8 +364,11 @@ int main(int argc, char **argv)
>  
>   /* Enable the buffer */
>   ret = write_sysfs_int("enable", buf_dir_name, 1);
> - if (ret < 0)
> + if (ret < 0) {
> + fprintf(stderr,
> + "Failed to enable buffer: %s\n", strerror(-ret));
>   goto error_free_buf_dir_name;
> + }
>  
>   scan_size = size_from_channelarray(channels, num_channels);
>   data = malloc(scan_size * buf_len);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] tools: iio: print error message when buffer enable fails

[Hartmut Knaack]

Irina Tirdea schrieb am 24.07.2015 um 15:28:
 Running generic_buffer without enabling any channel of the
 sensor will fail without printing any error message.
 
 Add an error message that indicates buffer enable failed.
 
 Signed-off-by: Irina Tirdea irina.tir...@intel.com
Acked-by: Hartmut Knaack knaac...@gmx.de
 ---
  tools/iio/generic_buffer.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
 index 32f389eb..9f7b85b 100644
 --- a/tools/iio/generic_buffer.c
 +++ b/tools/iio/generic_buffer.c
 @@ -364,8 +364,11 @@ int main(int argc, char **argv)
  
   /* Enable the buffer */
   ret = write_sysfs_int(enable, buf_dir_name, 1);
 - if (ret  0)
 + if (ret  0) {
 + fprintf(stderr,
 + Failed to enable buffer: %s\n, strerror(-ret));
   goto error_free_buf_dir_name;
 + }
  
   scan_size = size_from_channelarray(channels, num_channels);
   data = malloc(scan_size * buf_len);
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] tools: iio: print error message when buffer enable fails

[Hartmut Knaack]

Irina Tirdea schrieb am 23.07.2015 um 19:22:
> Running generic_buffer without enabling any channel of the
> sensor will fail without printing any error message.
> 
> Add an error message that indicates buffer enable failed.

Hi,
please make use of the error code stored in ret (with negative sign), as
in most cases the value of errno has already changed since the original
error has occurred.
Thanks,

Hartmut

> 
> Signed-off-by: Irina Tirdea 
> ---
>  tools/iio/generic_buffer.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
> index 32f389eb..936469c 100644
> --- a/tools/iio/generic_buffer.c
> +++ b/tools/iio/generic_buffer.c
> @@ -364,8 +364,11 @@ int main(int argc, char **argv)
>  
>   /* Enable the buffer */
>   ret = write_sysfs_int("enable", buf_dir_name, 1);
> - if (ret < 0)
> + if (ret < 0) {
> + fprintf(stderr,
> + "Failed to enable buffer: %s\n", strerror(errno));
>   goto error_free_buf_dir_name;
> + }
>  
>   scan_size = size_from_channelarray(channels, num_channels);
>   data = malloc(scan_size * buf_len);
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] tools: iio: fix mask for 32 bit sensor data

[Hartmut Knaack]

Irina Tirdea schrieb am 23.07.2015 um 19:22:
> When the the sensor data uses 32 bits out of 32, generic_buffer prints
> the value 0 for all data read.
> 
> In this case, the mask is shifted 32 bits, which is beyond the size of
> an integer. This will lead to the mask always being 0. Before printing,
> the mask is applied to the raw value, thus generating a final value of 0.
> 
> Fix the mask by shifting a 64 bit value instead of an integer.
> 
> Signed-off-by: Irina Tirdea 
Acked-by: Hartmut Knaack 
> ---
>  tools/iio/iio_utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
> index 1dcdf03..a95270f 100644
> --- a/tools/iio/iio_utils.c
> +++ b/tools/iio/iio_utils.c
> @@ -168,7 +168,7 @@ int iioutils_get_type(unsigned *is_signed, unsigned 
> *bytes, unsigned *bits_used,
>   if (*bits_used == 64)
>   *mask = ~0;
>   else
> - *mask = (1 << *bits_used) - 1;
> + *mask = (1ULL << *bits_used) - 1;
>  
>   *is_signed = (signchar == 's');
>   if (fclose(sysfsfp)) {
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] tools: iio: print error message when buffer enable fails

[Hartmut Knaack]

Irina Tirdea schrieb am 23.07.2015 um 19:22:
 Running generic_buffer without enabling any channel of the
 sensor will fail without printing any error message.
 
 Add an error message that indicates buffer enable failed.

Hi,
please make use of the error code stored in ret (with negative sign), as
in most cases the value of errno has already changed since the original
error has occurred.
Thanks,

Hartmut

 
 Signed-off-by: Irina Tirdea irina.tir...@intel.com
 ---
  tools/iio/generic_buffer.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)
 
 diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
 index 32f389eb..936469c 100644
 --- a/tools/iio/generic_buffer.c
 +++ b/tools/iio/generic_buffer.c
 @@ -364,8 +364,11 @@ int main(int argc, char **argv)
  
   /* Enable the buffer */
   ret = write_sysfs_int(enable, buf_dir_name, 1);
 - if (ret  0)
 + if (ret  0) {
 + fprintf(stderr,
 + Failed to enable buffer: %s\n, strerror(errno));
   goto error_free_buf_dir_name;
 + }
  
   scan_size = size_from_channelarray(channels, num_channels);
   data = malloc(scan_size * buf_len);
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] tools: iio: fix mask for 32 bit sensor data

[Hartmut Knaack]

Irina Tirdea schrieb am 23.07.2015 um 19:22:
 When the the sensor data uses 32 bits out of 32, generic_buffer prints
 the value 0 for all data read.
 
 In this case, the mask is shifted 32 bits, which is beyond the size of
 an integer. This will lead to the mask always being 0. Before printing,
 the mask is applied to the raw value, thus generating a final value of 0.
 
 Fix the mask by shifting a 64 bit value instead of an integer.
 
 Signed-off-by: Irina Tirdea irina.tir...@intel.com
Acked-by: Hartmut Knaack knaac...@gmx.de
 ---
  tools/iio/iio_utils.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
 index 1dcdf03..a95270f 100644
 --- a/tools/iio/iio_utils.c
 +++ b/tools/iio/iio_utils.c
 @@ -168,7 +168,7 @@ int iioutils_get_type(unsigned *is_signed, unsigned 
 *bytes, unsigned *bits_used,
   if (*bits_used == 64)
   *mask = ~0;
   else
 - *mask = (1  *bits_used) - 1;
 + *mask = (1ULL  *bits_used) - 1;
  
   *is_signed = (signchar == 's');
   if (fclose(sysfsfp)) {
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] tools: iio: Send error messages to stderr

[Hartmut Knaack]

Cristina Opriceana schrieb am 13.07.2015 um 15:33:
> This patch intends to make some cleanup and send printf
> error messages to stderr. The changes were performed with coccinelle
> for failure messages and manual for other cases, such as wrong usage
> messages.
> 

Looking very good so far. Two off-by-one indentation issues spotted however
(checkpatch didn't spot at least the first one), but after fixing you can
add my

Reviewed-by: Hartmut Knaack 

> Signed-off-by: Cristina Opriceana 
> ---
> Changes since v2:
>  - merge all replacements in one commit
> 
>  tools/iio/generic_buffer.c| 23 +++-
>  tools/iio/iio_event_monitor.c | 14 ++---
>  tools/iio/iio_utils.c | 49 
> +--
>  tools/iio/lsiio.c |  2 +-
>  4 files changed, 50 insertions(+), 38 deletions(-)
> 
> diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
> index 9535c2d..249858a 100644
> --- a/tools/iio/generic_buffer.c
> +++ b/tools/iio/generic_buffer.c
> @@ -193,7 +193,7 @@ void process_scan(char *data,
>  
>  void print_usage(void)
>  {
> - printf("Usage: generic_buffer [options]...\n"
> + fprintf(stderr, "Usage: generic_buffer [options]...\n"
>  "Capture, convert and output data from IIO device buffer\n"
>  "  -c  Do n conversions\n"
>  "  -e Disable wait for event (new data)\n"

These lines should be moved one space to the right, as well.

<...>
> diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
> index e177f40..15bd663 100644
> --- a/tools/iio/iio_utils.c
> +++ b/tools/iio/iio_utils.c
<...>  
> @@ -800,8 +808,9 @@ static int _write_sysfs_string(const char *filename, 
> const char *basedir,
>   }
>  
>   if (strcmp(temp, val) != 0) {
> - printf("Possible failure in string write of %s "
> -"Should be %s written to %s/%s\n", temp, val,
> + fprintf(stderr,
> + "Possible failure in string write of %s "
> + "Should be %s written to %s/%s\n", temp, val,
>  basedir, filename);

And this is the other instance.

>   ret = -1;
>   }

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] tools: iio: Add ARRAY_SIZE macro

[Hartmut Knaack]

Cristina Opriceana schrieb am 13.07.2015 um 15:20:
> Calculation of the length of an array can be done with the ARRAY_SIZE
> macro to make code more abstract and remove the associated
> checkpatch.pl warning.
> 
> Signed-off-by: Cristina Opriceana 
Acked-by: Hartmut Knaack 
> ---
>  tools/iio/iio_utils.c | 2 +-
>  tools/iio/iio_utils.h | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
> index 4a7e480..e177f40 100644
> --- a/tools/iio/iio_utils.c
> +++ b/tools/iio/iio_utils.c
> @@ -39,7 +39,7 @@ int iioutils_break_up_name(const char *full_name, char 
> **generic_name)
>   char *working, *prefix = "";
>   int i, ret;
>  
> - for (i = 0; i < sizeof(iio_direction) / sizeof(iio_direction[0]); i++)
> + for (i = 0; i < ARRAY_SIZE(iio_direction); i++)
>   if (!strncmp(full_name, iio_direction[i],
>strlen(iio_direction[i]))) {
>   prefix = iio_direction[i];
> diff --git a/tools/iio/iio_utils.h b/tools/iio/iio_utils.h
> index 0866101..f30a109 100644
> --- a/tools/iio/iio_utils.h
> +++ b/tools/iio/iio_utils.h
> @@ -18,6 +18,8 @@
>  #define FORMAT_SCAN_ELEMENTS_DIR "%s/scan_elements"
>  #define FORMAT_TYPE_FILE "%s_type"
>  
> +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof(arr[0]))
> +
>  extern const char *iio_dir;
>  
>  /**
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] tools: iio: Remove unnecessary braces

[Hartmut Knaack]

Cristina Opriceana schrieb am 13.07.2015 um 15:17:
> Single statement blocks don’t need braces.
> Found with checkpatch.pl.
> 
> Signed-off-by: Cristina Opriceana 
Acked-by: Hartmut Knaack 
> ---

Oops, that slipped through my hands. Thanks for taking care of this.

>  tools/iio/iio_event_monitor.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index 703f4cb..9ee1959 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c
> @@ -262,9 +262,8 @@ int main(int argc, char **argv)
>   printf("Found IIO device with name %s with device number %d\n",
>  device_name, dev_num);
>   ret =sprintf(_name, "/dev/iio:device%d", dev_num);
> - if (ret < 0) {
> + if (ret < 0)
>   return -ENOMEM;
> - }
>   } else {
>   /*
>* If we can't find an IIO device by name assume device_name is
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] tools: iio: Remove explicit NULL comparison

[Hartmut Knaack]

Cristina Opriceana schrieb am 13.07.2015 um 15:15:
> Remove explicit NULL comparison and write it in its simpler form as
> recommended by checkpatch.pl.
> 
> Signed-off-by: Cristina Opriceana 
Reviewed-by: Hartmut Knaack 
> ---

Every instance covered, consistency improved. Not everyone will mind that,
but good job.

>  tools/iio/generic_buffer.c |  4 ++--
>  tools/iio/iio_utils.c  | 56 
> +++---
>  tools/iio/lsiio.c  | 10 -
>  3 files changed, 35 insertions(+), 35 deletions(-)
> 
> diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
> index 0e73723..9535c2d 100644
> --- a/tools/iio/generic_buffer.c
> +++ b/tools/iio/generic_buffer.c
> @@ -270,7 +270,7 @@ int main(int argc, char **argv)
>   }
>   }
>  
> - if (device_name == NULL) {
> + if (!device_name) {
>   printf("Device name not set\n");
>   print_usage();
>   return -1;
> @@ -290,7 +290,7 @@ int main(int argc, char **argv)
>   return -ENOMEM;
>  
>   if (!notrigger) {
> - if (trigger_name == NULL) {
> + if (!trigger_name) {
>   /*
>* Build the trigger name. If it is device associated
>* its name is _dev[n] where n matches
> diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
> index 8fb3214..4a7e480 100644
> --- a/tools/iio/iio_utils.c
> +++ b/tools/iio/iio_utils.c
> @@ -117,13 +117,13 @@ int iioutils_get_type(unsigned *is_signed, unsigned 
> *bytes, unsigned *bits_used,
>   }
>  
>   dp = opendir(scan_el_dir);
> - if (dp == NULL) {
> + if (!dp) {
>   ret = -errno;
>   goto error_free_builtname_generic;
>   }
>  
>   ret = -ENOENT;
> - while (ent = readdir(dp), ent != NULL)
> + while (ent = readdir(dp), ent)
>   /*
>* Do we allow devices to override a generic name with
>* a specific one?
> @@ -138,7 +138,7 @@ int iioutils_get_type(unsigned *is_signed, unsigned 
> *bytes, unsigned *bits_used,
>   }
>  
>   sysfsfp = fopen(filename, "r");
> - if (sysfsfp == NULL) {
> + if (!sysfsfp) {
>   ret = -errno;
>   printf("failed to open %s\n", filename);
>   goto error_free_filename;
> @@ -235,13 +235,13 @@ int iioutils_get_param_float(float *output, const char 
> *param_name,
>   }
>  
>   dp = opendir(device_dir);
> - if (dp == NULL) {
> + if (!dp) {
>   ret = -errno;
>   goto error_free_builtname_generic;
>   }
>  
>   ret = -ENOENT;
> - while (ent = readdir(dp), ent != NULL)
> + while (ent = readdir(dp), ent)
>   if ((strcmp(builtname, ent->d_name) == 0) ||
>   (strcmp(builtname_generic, ent->d_name) == 0)) {
>   ret = asprintf(,
> @@ -325,12 +325,12 @@ int build_channel_array(const char *device_dir,
>   return -ENOMEM;
>  
>   dp = opendir(scan_el_dir);
> - if (dp == NULL) {
> + if (!dp) {
>   ret = -errno;
>   goto error_free_name;
>   }
>  
> - while (ent = readdir(dp), ent != NULL)
> + while (ent = readdir(dp), ent)
>   if (strcmp(ent->d_name + strlen(ent->d_name) - strlen("_en"),
>  "_en") == 0) {
>   ret = asprintf(,
> @@ -341,7 +341,7 @@ int build_channel_array(const char *device_dir,
>   }
>  
>   sysfsfp = fopen(filename, "r");
> - if (sysfsfp == NULL) {
> + if (!sysfsfp) {
>   ret = -errno;
>   free(filename);
>   goto error_close_dir;
> @@ -369,13 +369,13 @@ int build_channel_array(const char *device_dir,
>   }
>  
>   *ci_array = malloc(sizeof(**ci_array) * (*counter));
> - if (*ci_array == NULL) {
> + if (!*ci_array) {
>   ret = -ENOMEM;
>   goto error_close_dir;
>   }
>  
>   seekdir(dp, 0);
> - while (ent = readdir(dp), ent != NULL) {
> + while (ent = readdir(dp), ent) {
>   if (strcmp(ent->d_name + strlen(ent->d_name) - strlen("_en"),
>  "_en") == 0) {
>   int curren

Re: [PATCH 2/3] tools: iio: Remove unnecessary braces

[Hartmut Knaack]

Cristina Opriceana schrieb am 13.07.2015 um 15:17:
 Single statement blocks don’t need braces.
 Found with checkpatch.pl.
 
 Signed-off-by: Cristina Opriceana cristina.oprice...@gmail.com
Acked-by: Hartmut Knaack knaac...@gmx.de
 ---

Oops, that slipped through my hands. Thanks for taking care of this.

  tools/iio/iio_event_monitor.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
 
 diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
 index 703f4cb..9ee1959 100644
 --- a/tools/iio/iio_event_monitor.c
 +++ b/tools/iio/iio_event_monitor.c
 @@ -262,9 +262,8 @@ int main(int argc, char **argv)
   printf(Found IIO device with name %s with device number %d\n,
  device_name, dev_num);
   ret =sprintf(chrdev_name, /dev/iio:device%d, dev_num);
 - if (ret  0) {
 + if (ret  0)
   return -ENOMEM;
 - }
   } else {
   /*
* If we can't find an IIO device by name assume device_name is
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/3] tools: iio: Remove explicit NULL comparison

[Hartmut Knaack]

Cristina Opriceana schrieb am 13.07.2015 um 15:15:
 Remove explicit NULL comparison and write it in its simpler form as
 recommended by checkpatch.pl.
 
 Signed-off-by: Cristina Opriceana cristina.oprice...@gmail.com
Reviewed-by: Hartmut Knaack knaac...@gmx.de
 ---

Every instance covered, consistency improved. Not everyone will mind that,
but good job.

  tools/iio/generic_buffer.c |  4 ++--
  tools/iio/iio_utils.c  | 56 
 +++---
  tools/iio/lsiio.c  | 10 -
  3 files changed, 35 insertions(+), 35 deletions(-)
 
 diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
 index 0e73723..9535c2d 100644
 --- a/tools/iio/generic_buffer.c
 +++ b/tools/iio/generic_buffer.c
 @@ -270,7 +270,7 @@ int main(int argc, char **argv)
   }
   }
  
 - if (device_name == NULL) {
 + if (!device_name) {
   printf(Device name not set\n);
   print_usage();
   return -1;
 @@ -290,7 +290,7 @@ int main(int argc, char **argv)
   return -ENOMEM;
  
   if (!notrigger) {
 - if (trigger_name == NULL) {
 + if (!trigger_name) {
   /*
* Build the trigger name. If it is device associated
* its name is device_name_dev[n] where n matches
 diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
 index 8fb3214..4a7e480 100644
 --- a/tools/iio/iio_utils.c
 +++ b/tools/iio/iio_utils.c
 @@ -117,13 +117,13 @@ int iioutils_get_type(unsigned *is_signed, unsigned 
 *bytes, unsigned *bits_used,
   }
  
   dp = opendir(scan_el_dir);
 - if (dp == NULL) {
 + if (!dp) {
   ret = -errno;
   goto error_free_builtname_generic;
   }
  
   ret = -ENOENT;
 - while (ent = readdir(dp), ent != NULL)
 + while (ent = readdir(dp), ent)
   /*
* Do we allow devices to override a generic name with
* a specific one?
 @@ -138,7 +138,7 @@ int iioutils_get_type(unsigned *is_signed, unsigned 
 *bytes, unsigned *bits_used,
   }
  
   sysfsfp = fopen(filename, r);
 - if (sysfsfp == NULL) {
 + if (!sysfsfp) {
   ret = -errno;
   printf(failed to open %s\n, filename);
   goto error_free_filename;
 @@ -235,13 +235,13 @@ int iioutils_get_param_float(float *output, const char 
 *param_name,
   }
  
   dp = opendir(device_dir);
 - if (dp == NULL) {
 + if (!dp) {
   ret = -errno;
   goto error_free_builtname_generic;
   }
  
   ret = -ENOENT;
 - while (ent = readdir(dp), ent != NULL)
 + while (ent = readdir(dp), ent)
   if ((strcmp(builtname, ent-d_name) == 0) ||
   (strcmp(builtname_generic, ent-d_name) == 0)) {
   ret = asprintf(filename,
 @@ -325,12 +325,12 @@ int build_channel_array(const char *device_dir,
   return -ENOMEM;
  
   dp = opendir(scan_el_dir);
 - if (dp == NULL) {
 + if (!dp) {
   ret = -errno;
   goto error_free_name;
   }
  
 - while (ent = readdir(dp), ent != NULL)
 + while (ent = readdir(dp), ent)
   if (strcmp(ent-d_name + strlen(ent-d_name) - strlen(_en),
  _en) == 0) {
   ret = asprintf(filename,
 @@ -341,7 +341,7 @@ int build_channel_array(const char *device_dir,
   }
  
   sysfsfp = fopen(filename, r);
 - if (sysfsfp == NULL) {
 + if (!sysfsfp) {
   ret = -errno;
   free(filename);
   goto error_close_dir;
 @@ -369,13 +369,13 @@ int build_channel_array(const char *device_dir,
   }
  
   *ci_array = malloc(sizeof(**ci_array) * (*counter));
 - if (*ci_array == NULL) {
 + if (!*ci_array) {
   ret = -ENOMEM;
   goto error_close_dir;
   }
  
   seekdir(dp, 0);
 - while (ent = readdir(dp), ent != NULL) {
 + while (ent = readdir(dp), ent) {
   if (strcmp(ent-d_name + strlen(ent-d_name) - strlen(_en),
  _en) == 0) {
   int current_enabled = 0;
 @@ -391,7 +391,7 @@ int build_channel_array(const char *device_dir,
   }
  
   sysfsfp = fopen(filename, r);
 - if (sysfsfp == NULL) {
 + if (!sysfsfp) {
   ret = -errno;
   free(filename);
   count--;
 @@ -424,7 +424,7 @@ int build_channel_array(const char *device_dir,
   current-name = strndup(ent-d_name

Re: [PATCH 3/3] tools: iio: Add ARRAY_SIZE macro

[Hartmut Knaack]

Cristina Opriceana schrieb am 13.07.2015 um 15:20:
 Calculation of the length of an array can be done with the ARRAY_SIZE
 macro to make code more abstract and remove the associated
 checkpatch.pl warning.
 
 Signed-off-by: Cristina Opriceana cristina.oprice...@gmail.com
Acked-by: Hartmut Knaack knaac...@gmx.de
 ---
  tools/iio/iio_utils.c | 2 +-
  tools/iio/iio_utils.h | 2 ++
  2 files changed, 3 insertions(+), 1 deletion(-)
 
 diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
 index 4a7e480..e177f40 100644
 --- a/tools/iio/iio_utils.c
 +++ b/tools/iio/iio_utils.c
 @@ -39,7 +39,7 @@ int iioutils_break_up_name(const char *full_name, char 
 **generic_name)
   char *working, *prefix = ;
   int i, ret;
  
 - for (i = 0; i  sizeof(iio_direction) / sizeof(iio_direction[0]); i++)
 + for (i = 0; i  ARRAY_SIZE(iio_direction); i++)
   if (!strncmp(full_name, iio_direction[i],
strlen(iio_direction[i]))) {
   prefix = iio_direction[i];
 diff --git a/tools/iio/iio_utils.h b/tools/iio/iio_utils.h
 index 0866101..f30a109 100644
 --- a/tools/iio/iio_utils.h
 +++ b/tools/iio/iio_utils.h
 @@ -18,6 +18,8 @@
  #define FORMAT_SCAN_ELEMENTS_DIR %s/scan_elements
  #define FORMAT_TYPE_FILE %s_type
  
 +#define ARRAY_SIZE(arr) (sizeof(arr) / sizeof(arr[0]))
 +
  extern const char *iio_dir;
  
  /**
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3] tools: iio: Send error messages to stderr

[Hartmut Knaack]

Cristina Opriceana schrieb am 13.07.2015 um 15:33:
 This patch intends to make some cleanup and send printf
 error messages to stderr. The changes were performed with coccinelle
 for failure messages and manual for other cases, such as wrong usage
 messages.
 

Looking very good so far. Two off-by-one indentation issues spotted however
(checkpatch didn't spot at least the first one), but after fixing you can
add my

Reviewed-by: Hartmut Knaack knaac...@gmx.de

 Signed-off-by: Cristina Opriceana cristina.oprice...@gmail.com
 ---
 Changes since v2:
  - merge all replacements in one commit
 
  tools/iio/generic_buffer.c| 23 +++-
  tools/iio/iio_event_monitor.c | 14 ++---
  tools/iio/iio_utils.c | 49 
 +--
  tools/iio/lsiio.c |  2 +-
  4 files changed, 50 insertions(+), 38 deletions(-)
 
 diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
 index 9535c2d..249858a 100644
 --- a/tools/iio/generic_buffer.c
 +++ b/tools/iio/generic_buffer.c
 @@ -193,7 +193,7 @@ void process_scan(char *data,
  
  void print_usage(void)
  {
 - printf(Usage: generic_buffer [options]...\n
 + fprintf(stderr, Usage: generic_buffer [options]...\n
  Capture, convert and output data from IIO device buffer\n
-c n Do n conversions\n
-e Disable wait for event (new data)\n

These lines should be moved one space to the right, as well.

...
 diff --git a/tools/iio/iio_utils.c b/tools/iio/iio_utils.c
 index e177f40..15bd663 100644
 --- a/tools/iio/iio_utils.c
 +++ b/tools/iio/iio_utils.c
...  
 @@ -800,8 +808,9 @@ static int _write_sysfs_string(const char *filename, 
 const char *basedir,
   }
  
   if (strcmp(temp, val) != 0) {
 - printf(Possible failure in string write of %s 
 -Should be %s written to %s/%s\n, temp, val,
 + fprintf(stderr,
 + Possible failure in string write of %s 
 + Should be %s written to %s/%s\n, temp, val,
  basedir, filename);

And this is the other instance.

   ret = -1;
   }

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/4] tools: iio: Move printf failure messages to stderr

[Hartmut Knaack]

Cristina Georgiana Opriceana schrieb am 12.07.2015 um 13:38:
> On Sat, Jul 11, 2015 at 12:42 AM, Hartmut Knaack  wrote:
>> Cristina Opriceana schrieb am 10.07.2015 um 12:56:
>>> Replace printf error messages with fprintf(stderr, ...) in order
>>> to ensure consistency and to make faults easier to identify.
>>> This patch uses coccinelle to detect and apply the changes.
>>>
>>
>> Hi Cristina,
>> I just had a look at the series. You have all cases I regard necessary
>> covered. There are however a few cases which probably qualify as error
>> messages, too. Please see inline.
>> However, for my personal taste, this could have been merged all in a
>> single patch. Especially the third patch should have been included in
>> this one (as during review, people certainly think that you missed the
>> second line, just to find it fixed two patches later).
> 
> Hi,
> 
> Yes, I could have included all in a single patch, but I tried to
> automatize this task and build a rather generic semantic patch in
> coccinelle for the substitutions. Had I included all in one patch, the
> changes with coccinelle wouldn't have been differentiated from the
> other ones. If that is okay, I think I can merge them in one patch.
> 

Point taken for making it reproducible. I just like to raise awareness:
The maintainers are very busy. They have a full time job, respond to the
mailing list, review patches and do all the git magic. That keeps them
pretty busy, so I would aim to make the maintainers life as easy as possible.
Checking just one patch against some sources can be quicker/easier than
checking multiple ones. Same goes for applying patches.
Other than that, I just feel strong about the third patch standing separate,
which I don't regard a good idea. Either your script should have been
extended to catch such cases, or if it is not worth the effort, it should
have been changed by hand. But it should have gone in one pass.

>>> Signed-off-by: Cristina Opriceana 
>>> ---
>>> Changes in v2:
>>>  - s/failiure/failure
>>>
>>>  tools/iio/generic_buffer.c| 17 ++---
>>>  tools/iio/iio_event_monitor.c |  6 +++---
>>>  tools/iio/iio_utils.c | 34 --
>>>  3 files changed, 33 insertions(+), 24 deletions(-)
>>>
>>> diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
>>> index 0e73723..2f4e12f 100644
>>> --- a/tools/iio/generic_buffer.c
>>> +++ b/tools/iio/generic_buffer.c
>>> @@ -271,7 +271,7 @@ int main(int argc, char **argv)
>>>   }
>>>
>>>   if (device_name == NULL) {
>>> - printf("Device name not set\n");
>>> + fprintf(stderr, "Device name not set\n");
>>>   print_usage();
>>>   return -1;
>>>   }
>>> @@ -279,7 +279,7 @@ int main(int argc, char **argv)
>>>   /* Find the device requested */
>>>   dev_num = find_type_by_name(device_name, "iio:device");
>>>   if (dev_num < 0) {
>>> - printf("Failed to find the %s\n", device_name);
>>> + fprintf(stderr, "Failed to find the %s\n", device_name);
>>>   return dev_num;
>>>   }
>>>
>>> @@ -307,7 +307,8 @@ int main(int argc, char **argv)
>>>   /* Verify the trigger exists */
>>>   trig_num = find_type_by_name(trigger_name, "trigger");
>>>   if (trig_num < 0) {
>>> - printf("Failed to find the trigger %s\n", 
>>> trigger_name);
>>> + fprintf(stderr, "Failed to find the trigger %s\n",
>>> + trigger_name);
>>>   ret = trig_num;
>>>   goto error_free_triggername;
>>>   }
>>> @@ -323,7 +324,7 @@ int main(int argc, char **argv)
>>>*/
>>>   ret = build_channel_array(dev_dir_name, , _channels);
>>>   if (ret) {
>>> - printf("Problem reading scan element information\n");
>>> + fprintf(stderr, "Problem reading scan element information\n");
>>>   printf("diag %s\n", dev_dir_name);
>>
>> My preference would even be to print it all in just one fprintf.
> 
> I thought so, also, but the string would go beyond 80 characters and
> would have to be split which is ugly and brings a warning on it.
> 

I just 

Re: [PATCH v2 1/4] tools: iio: Move printf failure messages to stderr

[Hartmut Knaack]

Cristina Georgiana Opriceana schrieb am 12.07.2015 um 13:38:
 On Sat, Jul 11, 2015 at 12:42 AM, Hartmut Knaack knaac...@gmx.de wrote:
 Cristina Opriceana schrieb am 10.07.2015 um 12:56:
 Replace printf error messages with fprintf(stderr, ...) in order
 to ensure consistency and to make faults easier to identify.
 This patch uses coccinelle to detect and apply the changes.


 Hi Cristina,
 I just had a look at the series. You have all cases I regard necessary
 covered. There are however a few cases which probably qualify as error
 messages, too. Please see inline.
 However, for my personal taste, this could have been merged all in a
 single patch. Especially the third patch should have been included in
 this one (as during review, people certainly think that you missed the
 second line, just to find it fixed two patches later).
 
 Hi,
 
 Yes, I could have included all in a single patch, but I tried to
 automatize this task and build a rather generic semantic patch in
 coccinelle for the substitutions. Had I included all in one patch, the
 changes with coccinelle wouldn't have been differentiated from the
 other ones. If that is okay, I think I can merge them in one patch.
 

Point taken for making it reproducible. I just like to raise awareness:
The maintainers are very busy. They have a full time job, respond to the
mailing list, review patches and do all the git magic. That keeps them
pretty busy, so I would aim to make the maintainers life as easy as possible.
Checking just one patch against some sources can be quicker/easier than
checking multiple ones. Same goes for applying patches.
Other than that, I just feel strong about the third patch standing separate,
which I don't regard a good idea. Either your script should have been
extended to catch such cases, or if it is not worth the effort, it should
have been changed by hand. But it should have gone in one pass.

 Signed-off-by: Cristina Opriceana cristina.oprice...@gmail.com
 ---
 Changes in v2:
  - s/failiure/failure

  tools/iio/generic_buffer.c| 17 ++---
  tools/iio/iio_event_monitor.c |  6 +++---
  tools/iio/iio_utils.c | 34 --
  3 files changed, 33 insertions(+), 24 deletions(-)

 diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
 index 0e73723..2f4e12f 100644
 --- a/tools/iio/generic_buffer.c
 +++ b/tools/iio/generic_buffer.c
 @@ -271,7 +271,7 @@ int main(int argc, char **argv)
   }

   if (device_name == NULL) {
 - printf(Device name not set\n);
 + fprintf(stderr, Device name not set\n);
   print_usage();
   return -1;
   }
 @@ -279,7 +279,7 @@ int main(int argc, char **argv)
   /* Find the device requested */
   dev_num = find_type_by_name(device_name, iio:device);
   if (dev_num  0) {
 - printf(Failed to find the %s\n, device_name);
 + fprintf(stderr, Failed to find the %s\n, device_name);
   return dev_num;
   }

 @@ -307,7 +307,8 @@ int main(int argc, char **argv)
   /* Verify the trigger exists */
   trig_num = find_type_by_name(trigger_name, trigger);
   if (trig_num  0) {
 - printf(Failed to find the trigger %s\n, 
 trigger_name);
 + fprintf(stderr, Failed to find the trigger %s\n,
 + trigger_name);
   ret = trig_num;
   goto error_free_triggername;
   }
 @@ -323,7 +324,7 @@ int main(int argc, char **argv)
*/
   ret = build_channel_array(dev_dir_name, channels, num_channels);
   if (ret) {
 - printf(Problem reading scan element information\n);
 + fprintf(stderr, Problem reading scan element information\n);
   printf(diag %s\n, dev_dir_name);

 My preference would even be to print it all in just one fprintf.
 
 I thought so, also, but the string would go beyond 80 characters and
 would have to be split which is ugly and brings a warning on it.
 

I just gave it a try compile testing:
fprintf(stderr, Problem reading scan element information\n
diag %s\n, dev_dir_name);

Compiled just fine, and the same format is used in your second patch as well.

   goto error_free_triggername;
   }
 @@ -350,7 +351,8 @@ int main(int argc, char **argv)
   dev_dir_name,
   trigger_name);
   if (ret  0) {
 - printf(Failed to write current_trigger file\n);
 + fprintf(stderr,
 + Failed to write current_trigger file\n);
   goto error_free_buf_dir_name;
   }
   }
 @@ -382,7 +384,7 @@ int main(int argc, char **argv)
   fp = open(buffer_access, O_RDONLY | O_NONBLOCK);
   if (fp == -1) { /* TODO

Re: [PATCH v2 1/4] tools: iio: Move printf failure messages to stderr

[Hartmut Knaack]

Cristina Opriceana schrieb am 10.07.2015 um 12:56:
> Replace printf error messages with fprintf(stderr, ...) in order
> to ensure consistency and to make faults easier to identify.
> This patch uses coccinelle to detect and apply the changes.
> 

Hi Cristina,
I just had a look at the series. You have all cases I regard necessary
covered. There are however a few cases which probably qualify as error
messages, too. Please see inline.
However, for my personal taste, this could have been merged all in a
single patch. Especially the third patch should have been included in
this one (as during review, people certainly think that you missed the
second line, just to find it fixed two patches later).

> Signed-off-by: Cristina Opriceana 
> ---
> Changes in v2:
>  - s/failiure/failure
> 
>  tools/iio/generic_buffer.c| 17 ++---
>  tools/iio/iio_event_monitor.c |  6 +++---
>  tools/iio/iio_utils.c | 34 --
>  3 files changed, 33 insertions(+), 24 deletions(-)
> 
> diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
> index 0e73723..2f4e12f 100644
> --- a/tools/iio/generic_buffer.c
> +++ b/tools/iio/generic_buffer.c
> @@ -271,7 +271,7 @@ int main(int argc, char **argv)
>   }
>  
>   if (device_name == NULL) {
> - printf("Device name not set\n");
> + fprintf(stderr, "Device name not set\n");
>   print_usage();
>   return -1;
>   }
> @@ -279,7 +279,7 @@ int main(int argc, char **argv)
>   /* Find the device requested */
>   dev_num = find_type_by_name(device_name, "iio:device");
>   if (dev_num < 0) {
> - printf("Failed to find the %s\n", device_name);
> + fprintf(stderr, "Failed to find the %s\n", device_name);
>   return dev_num;
>   }
>  
> @@ -307,7 +307,8 @@ int main(int argc, char **argv)
>   /* Verify the trigger exists */
>   trig_num = find_type_by_name(trigger_name, "trigger");
>   if (trig_num < 0) {
> - printf("Failed to find the trigger %s\n", trigger_name);
> + fprintf(stderr, "Failed to find the trigger %s\n",
> + trigger_name);
>   ret = trig_num;
>   goto error_free_triggername;
>   }
> @@ -323,7 +324,7 @@ int main(int argc, char **argv)
>*/
>   ret = build_channel_array(dev_dir_name, , _channels);
>   if (ret) {
> - printf("Problem reading scan element information\n");
> + fprintf(stderr, "Problem reading scan element information\n");
>   printf("diag %s\n", dev_dir_name);

My preference would even be to print it all in just one fprintf.

>   goto error_free_triggername;
>   }
> @@ -350,7 +351,8 @@ int main(int argc, char **argv)
>   dev_dir_name,
>   trigger_name);
>   if (ret < 0) {
> - printf("Failed to write current_trigger file\n");
> + fprintf(stderr,
> + "Failed to write current_trigger file\n");
>   goto error_free_buf_dir_name;
>   }
>   }
> @@ -382,7 +384,7 @@ int main(int argc, char **argv)
>   fp = open(buffer_access, O_RDONLY | O_NONBLOCK);
>   if (fp == -1) { /* TODO: If it isn't there make the node */
>   ret = -errno;
> - printf("Failed to open %s\n", buffer_access);
> + fprintf(stderr, "Failed to open %s\n", buffer_access);
>   goto error_free_buffer_access;
>   }
>  

At line 410 we have a block:
read_size = read(fp, data, toread * scan_size);
if (read_size < 0) {
if (errno == EAGAIN) {
printf("nothing available\n");
continue;

I'm tempted to say,that this should go to stderr, as well. Any opinions?

> @@ -431,7 +433,8 @@ int main(int argc, char **argv)
>   ret = write_sysfs_string("trigger/current_trigger",
>dev_dir_name, "NULL");
>   if (ret < 0)
> - printf("Failed to write to %s\n", dev_dir_name);
> + fprintf(stderr, "Failed to write to %s\n",
> + dev_dir_name);
>  
>  error_close_buffer_access:
>   if (close(fp) == -1)
> diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
> index 703f4cb..843bc4c 100644
> --- a/tools/iio/iio_event_monitor.c
> +++ b/tools/iio/iio_event_monitor.c

At line 217:
if (!event_is_known(event)) {
printf("Unknown event: time: %lld, id: %llx\n",
   event->timestamp, event->id);

return;
Better have this on stderr, as well?

> @@ -278,14 +278,14 @@ int 

Re: [PATCH v2 1/4] tools: iio: Move printf failure messages to stderr

[Hartmut Knaack]

Cristina Opriceana schrieb am 10.07.2015 um 12:56:
 Replace printf error messages with fprintf(stderr, ...) in order
 to ensure consistency and to make faults easier to identify.
 This patch uses coccinelle to detect and apply the changes.
 

Hi Cristina,
I just had a look at the series. You have all cases I regard necessary
covered. There are however a few cases which probably qualify as error
messages, too. Please see inline.
However, for my personal taste, this could have been merged all in a
single patch. Especially the third patch should have been included in
this one (as during review, people certainly think that you missed the
second line, just to find it fixed two patches later).

 Signed-off-by: Cristina Opriceana cristina.oprice...@gmail.com
 ---
 Changes in v2:
  - s/failiure/failure
 
  tools/iio/generic_buffer.c| 17 ++---
  tools/iio/iio_event_monitor.c |  6 +++---
  tools/iio/iio_utils.c | 34 --
  3 files changed, 33 insertions(+), 24 deletions(-)
 
 diff --git a/tools/iio/generic_buffer.c b/tools/iio/generic_buffer.c
 index 0e73723..2f4e12f 100644
 --- a/tools/iio/generic_buffer.c
 +++ b/tools/iio/generic_buffer.c
 @@ -271,7 +271,7 @@ int main(int argc, char **argv)
   }
  
   if (device_name == NULL) {
 - printf(Device name not set\n);
 + fprintf(stderr, Device name not set\n);
   print_usage();
   return -1;
   }
 @@ -279,7 +279,7 @@ int main(int argc, char **argv)
   /* Find the device requested */
   dev_num = find_type_by_name(device_name, iio:device);
   if (dev_num  0) {
 - printf(Failed to find the %s\n, device_name);
 + fprintf(stderr, Failed to find the %s\n, device_name);
   return dev_num;
   }
  
 @@ -307,7 +307,8 @@ int main(int argc, char **argv)
   /* Verify the trigger exists */
   trig_num = find_type_by_name(trigger_name, trigger);
   if (trig_num  0) {
 - printf(Failed to find the trigger %s\n, trigger_name);
 + fprintf(stderr, Failed to find the trigger %s\n,
 + trigger_name);
   ret = trig_num;
   goto error_free_triggername;
   }
 @@ -323,7 +324,7 @@ int main(int argc, char **argv)
*/
   ret = build_channel_array(dev_dir_name, channels, num_channels);
   if (ret) {
 - printf(Problem reading scan element information\n);
 + fprintf(stderr, Problem reading scan element information\n);
   printf(diag %s\n, dev_dir_name);

My preference would even be to print it all in just one fprintf.

   goto error_free_triggername;
   }
 @@ -350,7 +351,8 @@ int main(int argc, char **argv)
   dev_dir_name,
   trigger_name);
   if (ret  0) {
 - printf(Failed to write current_trigger file\n);
 + fprintf(stderr,
 + Failed to write current_trigger file\n);
   goto error_free_buf_dir_name;
   }
   }
 @@ -382,7 +384,7 @@ int main(int argc, char **argv)
   fp = open(buffer_access, O_RDONLY | O_NONBLOCK);
   if (fp == -1) { /* TODO: If it isn't there make the node */
   ret = -errno;
 - printf(Failed to open %s\n, buffer_access);
 + fprintf(stderr, Failed to open %s\n, buffer_access);
   goto error_free_buffer_access;
   }
  

At line 410 we have a block:
read_size = read(fp, data, toread * scan_size);
if (read_size  0) {
if (errno == EAGAIN) {
printf(nothing available\n);
continue;

I'm tempted to say,that this should go to stderr, as well. Any opinions?

 @@ -431,7 +433,8 @@ int main(int argc, char **argv)
   ret = write_sysfs_string(trigger/current_trigger,
dev_dir_name, NULL);
   if (ret  0)
 - printf(Failed to write to %s\n, dev_dir_name);
 + fprintf(stderr, Failed to write to %s\n,
 + dev_dir_name);
  
  error_close_buffer_access:
   if (close(fp) == -1)
 diff --git a/tools/iio/iio_event_monitor.c b/tools/iio/iio_event_monitor.c
 index 703f4cb..843bc4c 100644
 --- a/tools/iio/iio_event_monitor.c
 +++ b/tools/iio/iio_event_monitor.c

At line 217:
if (!event_is_known(event)) {
printf(Unknown event: time: %lld, id: %llx\n,
   event-timestamp, event-id);

return;
Better have this on stderr, as well?

 @@ -278,14 +278,14 @@ int main(int argc, char **argv)
   fd = open(chrdev_name, 0);
   if (fd == -1) {
   ret = 

Re: [PATCH v2 1/3] iio: magnetometer: Add support for MEMSIC MMC35240 sensor

[Hartmut Knaack]

Daniel Baluta schrieb am 29.06.2015 um 09:52:
> On Mon, Jun 29, 2015 at 2:07 AM, Hartmut Knaack  wrote:
>> Daniel Baluta schrieb am 24.04.2015 um 17:58:
>>> Minimal implementation for MMC35240 3-axis magnetometer
>>> sensor. It provides processed readings and possiblity to change
>>> the sampling frequency.
>>>
>>
>> Hi Daniel,
>> please find a few issues inline, which you could address in a next
>> rework patch set. I would have sent a patch for the critical stuff,
>> but was obviously too stupid to find a data sheet :-(
> 
> Well, there is no public datasheet. We are discussing with the vendor
> to make it public.
> 
<...>
>>> +static int mmc35240_hw_set(struct mmc35240_data *data, bool set)
>>> +{
>>> + int ret;
>>> + u8 coil_bit;
>>> +
>>> + /*
>>> +  * Recharge the capacitor at VCAP pin, requested to be issued
>>> +  * before a SET/RESET command.
>>> +  */
>>> + ret = regmap_update_bits(data->regmap, MMC35240_REG_CTRL0,
>>> +  MMC35240_CTRL0_REFILL_BIT,
>>> +  MMC35240_CTRL0_REFILL_BIT);
>>> + if (ret < 0)
>>> + return ret;
>>> + usleep_range(MMC35240_WAIT_CHARGE_PUMP, MMC35240_WAIT_CHARGE_PUMP + 
>>> 1);
>>> +
>>> + if (set)
>>> + coil_bit = MMC35240_CTRL0_SET_BIT;
>>> + else
>>> + coil_bit = MMC35240_CTRL0_RESET_BIT;
>>> +
>>> + return regmap_update_bits(data->regmap, MMC35240_REG_CTRL0,
>>> +   MMC35240_CTRL0_REFILL_BIT,
>>> +   coil_bit);
>>
>> coil_bit is in any case outside the mask of MMC35240_CTRL0_REFILL_BIT.
>> Not sure about the whole intention, meaning in which state
>> MMC35240_CTRL0_REFILL_BIT is supposed to be (set) when either
>> MMC35240_CTRL0_SET_BIT or MMC35240_CTRL0_RESET_BIT is written.
> 
> Yes, this is a bug. We have a patch prepared for it. Will send once Jonathan 
> is
> ready to accept bugfixes. Together with this:
> 
> http://marc.info/?l=linux-iio=143489464403101=2
> 

Sending it out earlier gives people more time to review (or may allow more 
people
to review).

> 
>>
>>> +}

<...>
>>> +
>>> +static int mmc35240_take_measurement(struct mmc35240_data *data)
>>> +{
>>> + int ret, tries = 100;
>>> + unsigned int reg_status;
>>> +
>>> + ret = regmap_write(data->regmap, MMC35240_REG_CTRL0,
>>> +MMC35240_CTRL0_TM_BIT);
>>> + if (ret < 0)
>>> + return ret;
>>> +
>>> + while (tries-- > 0) {
>>> + ret = regmap_read(data->regmap, MMC35240_REG_STATUS,
>>> +   _status);
>>> + if (ret < 0)
>>> + return ret;
>>> + if (reg_status & MMC35240_STATUS_MEAS_DONE_BIT)
>>> + break;
>>
>> I would actually return 0 here, as measurement was successful. That
>> would mean that getting outside the loop is the error case and would
>> make the check obsolete.
> 
> You are right, this could also work. Anyhow, I think code is easier to
> understand as it is. The check for (tries < 0) makes it very clear, that the
> data was not ready.
> 
> Getting outside the loop in the error case is harder to understand at a first
> glance.
> 

I can not really agree. The mission is accomplished at the break, so better
take the shortest way out (return 0 usually reflects that). Still going through
a check that won't trigger in this case just adds bloat without any benefit.
It's not a bug, so I don't feel too strong to fix it myself (still too much
reviews to be done). Sorry for annoying with such issues, spending my childhood
with slow and low memory 8 bit machines just left a mark ;-)

>>
>>> + msleep(20);
>>> + }
>>> +
>>> + if (tries < 0) {
>>> + dev_err(>client->dev, "data not ready\n");
>>> + return -EIO;
>>
>> Doesn't this qualify more for a timeout error, rather than I/O?
> 
> Looking at the IIO drivers, most of them return EIO in such case.
> (grep for EIO in drivers/iio/light for example)
> 

I don't feel too strong about this. I just regard I/O errors as indication
that communication with the device went wrong. But when getting here, it
always told to be busy.

> 
> 
>>> + 

Re: [PATCH v2 1/3] iio: magnetometer: Add support for MEMSIC MMC35240 sensor

[Hartmut Knaack]

Daniel Baluta schrieb am 29.06.2015 um 09:52:
 On Mon, Jun 29, 2015 at 2:07 AM, Hartmut Knaack knaac...@gmx.de wrote:
 Daniel Baluta schrieb am 24.04.2015 um 17:58:
 Minimal implementation for MMC35240 3-axis magnetometer
 sensor. It provides processed readings and possiblity to change
 the sampling frequency.


 Hi Daniel,
 please find a few issues inline, which you could address in a next
 rework patch set. I would have sent a patch for the critical stuff,
 but was obviously too stupid to find a data sheet :-(
 
 Well, there is no public datasheet. We are discussing with the vendor
 to make it public.
 
...
 +static int mmc35240_hw_set(struct mmc35240_data *data, bool set)
 +{
 + int ret;
 + u8 coil_bit;
 +
 + /*
 +  * Recharge the capacitor at VCAP pin, requested to be issued
 +  * before a SET/RESET command.
 +  */
 + ret = regmap_update_bits(data-regmap, MMC35240_REG_CTRL0,
 +  MMC35240_CTRL0_REFILL_BIT,
 +  MMC35240_CTRL0_REFILL_BIT);
 + if (ret  0)
 + return ret;
 + usleep_range(MMC35240_WAIT_CHARGE_PUMP, MMC35240_WAIT_CHARGE_PUMP + 
 1);
 +
 + if (set)
 + coil_bit = MMC35240_CTRL0_SET_BIT;
 + else
 + coil_bit = MMC35240_CTRL0_RESET_BIT;
 +
 + return regmap_update_bits(data-regmap, MMC35240_REG_CTRL0,
 +   MMC35240_CTRL0_REFILL_BIT,
 +   coil_bit);

 coil_bit is in any case outside the mask of MMC35240_CTRL0_REFILL_BIT.
 Not sure about the whole intention, meaning in which state
 MMC35240_CTRL0_REFILL_BIT is supposed to be (set) when either
 MMC35240_CTRL0_SET_BIT or MMC35240_CTRL0_RESET_BIT is written.
 
 Yes, this is a bug. We have a patch prepared for it. Will send once Jonathan 
 is
 ready to accept bugfixes. Together with this:
 
 http://marc.info/?l=linux-iiom=143489464403101w=2
 

Sending it out earlier gives people more time to review (or may allow more 
people
to review).

 

 +}

...
 +
 +static int mmc35240_take_measurement(struct mmc35240_data *data)
 +{
 + int ret, tries = 100;
 + unsigned int reg_status;
 +
 + ret = regmap_write(data-regmap, MMC35240_REG_CTRL0,
 +MMC35240_CTRL0_TM_BIT);
 + if (ret  0)
 + return ret;
 +
 + while (tries--  0) {
 + ret = regmap_read(data-regmap, MMC35240_REG_STATUS,
 +   reg_status);
 + if (ret  0)
 + return ret;
 + if (reg_status  MMC35240_STATUS_MEAS_DONE_BIT)
 + break;

 I would actually return 0 here, as measurement was successful. That
 would mean that getting outside the loop is the error case and would
 make the check obsolete.
 
 You are right, this could also work. Anyhow, I think code is easier to
 understand as it is. The check for (tries  0) makes it very clear, that the
 data was not ready.
 
 Getting outside the loop in the error case is harder to understand at a first
 glance.
 

I can not really agree. The mission is accomplished at the break, so better
take the shortest way out (return 0 usually reflects that). Still going through
a check that won't trigger in this case just adds bloat without any benefit.
It's not a bug, so I don't feel too strong to fix it myself (still too much
reviews to be done). Sorry for annoying with such issues, spending my childhood
with slow and low memory 8 bit machines just left a mark ;-)


 + msleep(20);
 + }
 +
 + if (tries  0) {
 + dev_err(data-client-dev, data not ready\n);
 + return -EIO;

 Doesn't this qualify more for a timeout error, rather than I/O?
 
 Looking at the IIO drivers, most of them return EIO in such case.
 (grep for EIO in drivers/iio/light for example)
 

I don't feel too strong about this. I just regard I/O errors as indication
that communication with the device went wrong. But when getting here, it
always told to be busy.

 snip
 
 + case IIO_CHAN_INFO_SAMP_FREQ:
 + mutex_lock(data-mutex);
 + ret = regmap_read(data-regmap, MMC35240_REG_CTRL1, reg);
 + mutex_unlock(data-mutex);
 + if (ret  0)
 + return ret;
 +
 + i = (reg  MMC35240_CTRL1_BW_MASK)  MMC35240_CTRL1_BW_SHIFT;
 + if (i  0 || i  ARRAY_SIZE(mmc35240_samp_freq))

 I would drop i and keep using reg. Has the nice side effect that you don't
 need to check for negative values.
 
 Ok.
 
 
 snip
 
 +
 +static bool mmc35240_is_volatile_reg(struct device *dev, unsigned int reg)
 +{
 + switch (reg) {
 + case MMC35240_REG_CTRL0:
 + case MMC35240_REG_CTRL1:

 I would regard MMC35240_REG_ID as non-volatile, as well. Or is it because it
 is just accessed once?
 
 Correct, we access it only once.
 
 Hartmut, thanks a lot for your reviews!
 
 thanks,
 Daniel.
 --
 To unsubscribe from this list: send the line unsubscribe linux-iio in
 the body

Re: [PATCH v2 1/3] iio: magnetometer: Add support for MEMSIC MMC35240 sensor

[Hartmut Knaack]

Daniel Baluta schrieb am 24.04.2015 um 17:58:
> Minimal implementation for MMC35240 3-axis magnetometer
> sensor. It provides processed readings and possiblity to change
> the sampling frequency.
> 

Hi Daniel,
please find a few issues inline, which you could address in a next
rework patch set. I would have sent a patch for the critical stuff,
but was obviously too stupid to find a data sheet :-(

> Signed-off-by: Daniel Baluta 
> ---
>  drivers/iio/magnetometer/Kconfig|  11 +
>  drivers/iio/magnetometer/Makefile   |   1 +
>  drivers/iio/magnetometer/mmc35240.c | 468 
> 
>  3 files changed, 480 insertions(+)
>  create mode 100644 drivers/iio/magnetometer/mmc35240.c
> 
> diff --git a/drivers/iio/magnetometer/Kconfig 
> b/drivers/iio/magnetometer/Kconfig
> index a5d6de7..7aba685 100644
> --- a/drivers/iio/magnetometer/Kconfig
> +++ b/drivers/iio/magnetometer/Kconfig
> @@ -47,6 +47,17 @@ config HID_SENSOR_MAGNETOMETER_3D
> Say yes here to build support for the HID SENSOR
> Magnetometer 3D.
>  
> +config MMC35240
> + tristate "MEMSIC MMC35240 3-axis magnetic sensor"
> + select REGMAP_I2C
> + depends on I2C
> + help
> +   Say yes here to build support for the MEMSIC MMC35240 3-axis
> +   magnetic sensor.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called mmc35240.
> +
>  config IIO_ST_MAGN_3AXIS
>   tristate "STMicroelectronics magnetometers 3-Axis Driver"
>   depends on (I2C || SPI_MASTER) && SYSFS
> diff --git a/drivers/iio/magnetometer/Makefile 
> b/drivers/iio/magnetometer/Makefile
> index 0f5d3c9..696a429 100644
> --- a/drivers/iio/magnetometer/Makefile
> +++ b/drivers/iio/magnetometer/Makefile
> @@ -6,6 +6,7 @@
>  obj-$(CONFIG_AK8975) += ak8975.o
>  obj-$(CONFIG_MAG3110)+= mag3110.o
>  obj-$(CONFIG_HID_SENSOR_MAGNETOMETER_3D) += hid-sensor-magn-3d.o
> +obj-$(CONFIG_MMC35240)   += mmc35240.o
>  
>  obj-$(CONFIG_IIO_ST_MAGN_3AXIS) += st_magn.o
>  st_magn-y := st_magn_core.o
> diff --git a/drivers/iio/magnetometer/mmc35240.c 
> b/drivers/iio/magnetometer/mmc35240.c
> new file mode 100644
> index 000..beefebc
> --- /dev/null
> +++ b/drivers/iio/magnetometer/mmc35240.c
> @@ -0,0 +1,468 @@
> +/*
> + * MMC35240 - MEMSIC 3-axis Magnetic Sensor
> + *
> + * Copyright (c) 2015, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for MMC35240 (7-bit I2C slave address 0x30).
> + *
> + * TODO: offset, ACPI, continuous measurement mode, PM
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +
> +#define MMC35240_DRV_NAME "mmc35240"
> +#define MMC35240_REGMAP_NAME "mmc35240_regmap"
> +
> +#define MMC35240_REG_XOUT_L  0x00
> +#define MMC35240_REG_XOUT_H  0x01
> +#define MMC35240_REG_YOUT_L  0x02
> +#define MMC35240_REG_YOUT_H  0x03
> +#define MMC35240_REG_ZOUT_L  0x04
> +#define MMC35240_REG_ZOUT_H  0x05
> +
> +#define MMC35240_REG_STATUS  0x06
> +#define MMC35240_REG_CTRL0   0x07
> +#define MMC35240_REG_CTRL1   0x08
> +
> +#define MMC35240_REG_ID  0x20
> +
> +#define MMC35240_STATUS_MEAS_DONE_BITBIT(0)
> +
> +#define MMC35240_CTRL0_REFILL_BITBIT(7)
> +#define MMC35240_CTRL0_RESET_BIT BIT(6)
> +#define MMC35240_CTRL0_SET_BIT   BIT(5)
> +#define MMC35240_CTRL0_CMM_BIT   BIT(1)
> +#define MMC35240_CTRL0_TM_BITBIT(0)

It took me quite some time to figure out TM would stand for take measurement.
Still no clue about CMM (it's still not used from what I could see). Would be
great if you could comment them.

> +
> +/* output resolution bits */
> +#define MMC35240_CTRL1_BW0_BIT   BIT(0)
> +#define MMC35240_CTRL1_BW1_BIT   BIT(1)
> +
> +#define MMC35240_CTRL1_BW_MASK(MMC35240_CTRL1_BW0_BIT | \
> +  MMC35240_CTRL1_BW1_BIT)
> +#define MMC35240_CTRL1_BW_SHIFT  0
> +
> +#define MMC35240_WAIT_CHARGE_PUMP5   /* us */
> +#define MMC53240_WAIT_SET_RESET  1000/* us */
> +
> +enum mmc35240_resolution {
> + MMC35240_16_BITS_SLOW = 0, /* 100 Hz */
> + MMC35240_16_BITS_FAST, /* 200 Hz */
> + MMC35240_14_BITS,  /* 333 Hz */
> + MMC35240_12_BITS,  /* 666 Hz */
> +};
> +
> +enum mmc35240_axis {
> + AXIS_X = 0,
> + AXIS_Y,
> + AXIS_Z,
> +};
> +
> +static const struct {
> + int sens[3]; /* sensitivity per X, Y, Z axis */
> + int nfo; /* null field output */
> +} mmc35240_props_table[] = {
> + /* 16 bits, 100Hz ODR */
> + {
> + {1024, 1024, 770},
> + 32768,
> + },
> + /* 16 bits, 200Hz ODR */
> + {
> + {1024, 1024, 770},
> + 32768,
> + },
> + /* 14 bits, 333Hz ODR */
> + {
> +   

Re: [PATCH v2 1/3] iio: magnetometer: Add support for MEMSIC MMC35240 sensor

[Hartmut Knaack]

Daniel Baluta schrieb am 24.04.2015 um 17:58:
 Minimal implementation for MMC35240 3-axis magnetometer
 sensor. It provides processed readings and possiblity to change
 the sampling frequency.
 

Hi Daniel,
please find a few issues inline, which you could address in a next
rework patch set. I would have sent a patch for the critical stuff,
but was obviously too stupid to find a data sheet :-(

 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
  drivers/iio/magnetometer/Kconfig|  11 +
  drivers/iio/magnetometer/Makefile   |   1 +
  drivers/iio/magnetometer/mmc35240.c | 468 
 
  3 files changed, 480 insertions(+)
  create mode 100644 drivers/iio/magnetometer/mmc35240.c
 
 diff --git a/drivers/iio/magnetometer/Kconfig 
 b/drivers/iio/magnetometer/Kconfig
 index a5d6de7..7aba685 100644
 --- a/drivers/iio/magnetometer/Kconfig
 +++ b/drivers/iio/magnetometer/Kconfig
 @@ -47,6 +47,17 @@ config HID_SENSOR_MAGNETOMETER_3D
 Say yes here to build support for the HID SENSOR
 Magnetometer 3D.
  
 +config MMC35240
 + tristate MEMSIC MMC35240 3-axis magnetic sensor
 + select REGMAP_I2C
 + depends on I2C
 + help
 +   Say yes here to build support for the MEMSIC MMC35240 3-axis
 +   magnetic sensor.
 +
 +   To compile this driver as a module, choose M here: the module
 +   will be called mmc35240.
 +
  config IIO_ST_MAGN_3AXIS
   tristate STMicroelectronics magnetometers 3-Axis Driver
   depends on (I2C || SPI_MASTER)  SYSFS
 diff --git a/drivers/iio/magnetometer/Makefile 
 b/drivers/iio/magnetometer/Makefile
 index 0f5d3c9..696a429 100644
 --- a/drivers/iio/magnetometer/Makefile
 +++ b/drivers/iio/magnetometer/Makefile
 @@ -6,6 +6,7 @@
  obj-$(CONFIG_AK8975) += ak8975.o
  obj-$(CONFIG_MAG3110)+= mag3110.o
  obj-$(CONFIG_HID_SENSOR_MAGNETOMETER_3D) += hid-sensor-magn-3d.o
 +obj-$(CONFIG_MMC35240)   += mmc35240.o
  
  obj-$(CONFIG_IIO_ST_MAGN_3AXIS) += st_magn.o
  st_magn-y := st_magn_core.o
 diff --git a/drivers/iio/magnetometer/mmc35240.c 
 b/drivers/iio/magnetometer/mmc35240.c
 new file mode 100644
 index 000..beefebc
 --- /dev/null
 +++ b/drivers/iio/magnetometer/mmc35240.c
 @@ -0,0 +1,468 @@
 +/*
 + * MMC35240 - MEMSIC 3-axis Magnetic Sensor
 + *
 + * Copyright (c) 2015, Intel Corporation.
 + *
 + * This file is subject to the terms and conditions of version 2 of
 + * the GNU General Public License.  See the file COPYING in the main
 + * directory of this archive for more details.
 + *
 + * IIO driver for MMC35240 (7-bit I2C slave address 0x30).
 + *
 + * TODO: offset, ACPI, continuous measurement mode, PM
 + */
 +
 +#include linux/module.h
 +#include linux/init.h
 +#include linux/i2c.h
 +#include linux/delay.h
 +#include linux/regmap.h
 +
 +#include linux/iio/iio.h
 +#include linux/iio/sysfs.h
 +
 +#define MMC35240_DRV_NAME mmc35240
 +#define MMC35240_REGMAP_NAME mmc35240_regmap
 +
 +#define MMC35240_REG_XOUT_L  0x00
 +#define MMC35240_REG_XOUT_H  0x01
 +#define MMC35240_REG_YOUT_L  0x02
 +#define MMC35240_REG_YOUT_H  0x03
 +#define MMC35240_REG_ZOUT_L  0x04
 +#define MMC35240_REG_ZOUT_H  0x05
 +
 +#define MMC35240_REG_STATUS  0x06
 +#define MMC35240_REG_CTRL0   0x07
 +#define MMC35240_REG_CTRL1   0x08
 +
 +#define MMC35240_REG_ID  0x20
 +
 +#define MMC35240_STATUS_MEAS_DONE_BITBIT(0)
 +
 +#define MMC35240_CTRL0_REFILL_BITBIT(7)
 +#define MMC35240_CTRL0_RESET_BIT BIT(6)
 +#define MMC35240_CTRL0_SET_BIT   BIT(5)
 +#define MMC35240_CTRL0_CMM_BIT   BIT(1)
 +#define MMC35240_CTRL0_TM_BITBIT(0)

It took me quite some time to figure out TM would stand for take measurement.
Still no clue about CMM (it's still not used from what I could see). Would be
great if you could comment them.

 +
 +/* output resolution bits */
 +#define MMC35240_CTRL1_BW0_BIT   BIT(0)
 +#define MMC35240_CTRL1_BW1_BIT   BIT(1)
 +
 +#define MMC35240_CTRL1_BW_MASK(MMC35240_CTRL1_BW0_BIT | \
 +  MMC35240_CTRL1_BW1_BIT)
 +#define MMC35240_CTRL1_BW_SHIFT  0
 +
 +#define MMC35240_WAIT_CHARGE_PUMP5   /* us */
 +#define MMC53240_WAIT_SET_RESET  1000/* us */
 +
 +enum mmc35240_resolution {
 + MMC35240_16_BITS_SLOW = 0, /* 100 Hz */
 + MMC35240_16_BITS_FAST, /* 200 Hz */
 + MMC35240_14_BITS,  /* 333 Hz */
 + MMC35240_12_BITS,  /* 666 Hz */
 +};
 +
 +enum mmc35240_axis {
 + AXIS_X = 0,
 + AXIS_Y,
 + AXIS_Z,
 +};
 +
 +static const struct {
 + int sens[3]; /* sensitivity per X, Y, Z axis */
 + int nfo; /* null field output */
 +} mmc35240_props_table[] = {
 + /* 16 bits, 100Hz ODR */
 + {
 + {1024, 1024, 770},
 + 32768,
 + },
 + /* 16 bits, 200Hz ODR */
 + {
 + {1024, 1024, 770},
 + 32768,
 + },
 + /* 14 bits, 333Hz ODR */
 + {
 + {256, 256, 193},
 +  

Re: [PATCH v2 00/17] Fixes for the mma9553 driver

[Hartmut Knaack]

Irina Tirdea schrieb am 13.04.2015 um 17:40:
> This is a set of follow-up patches for the mma9553 driver that fixes
> issues as suggested by Hartmut and Daniel.
> 

Finally, I got around to this series. Looks good to me.
Thanks,

Hartmut

> Changes in v2:
>  - split some of the the v1 patches into smaller patches
> as suggested by Jonathan
>  - reordered the series to have bug fixes first followed by style fixes
>  - use Reported-by for bug fixes
>  - added more fixes for issues detected by checkpatch.pl --strict
> 
> Irina Tirdea (17):
>   iio: accel: mma9553: fix endianness issue when reading status
>   iio: accel: mma9553: check input value for activity period
>   iio: accel: mma9551_core: prevent buffer overrun
>   iio: accel: mma9553: add enable channel for activity
>   iio: accel: mma9551_core: wrong doc fixes
>   iio: accel: mma9551_core: typo fix in RSC APP ID
>   iio: accel: mma9553: check for error in reading initial activity and
> stepcnt
>   iio: accel: mma9553: return 0 as indication of success
>   iio: accel: mma9553: comment and error message fixes
>   iio: accel: mma9553: use GENMASK
>   iio: accel: mma9553: prefix naming fixes
>   iio: accel: mma9553: fix gpio bitnum init value
>   iio: accel: mma9553: refactor mma9553_read_raw
>   iio: accel: mma9551_core: use size in words for word buffers
>   iio: accel: mma9553: fix alignment issues
>   iio: accel: mma9553: document use of mutex
>   iio: accel: mma9553: use unsigned counters
> 
>  drivers/iio/accel/mma9551_core.c |  70 ++-
>  drivers/iio/accel/mma9551_core.h |   8 +-
>  drivers/iio/accel/mma9553.c  | 253 
> ++-
>  3 files changed, 160 insertions(+), 171 deletions(-)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 00/17] Fixes for the mma9553 driver

[Hartmut Knaack]

Irina Tirdea schrieb am 13.04.2015 um 17:40:
 This is a set of follow-up patches for the mma9553 driver that fixes
 issues as suggested by Hartmut and Daniel.
 

Finally, I got around to this series. Looks good to me.
Thanks,

Hartmut

 Changes in v2:
  - split some of the the v1 patches into smaller patches
 as suggested by Jonathan
  - reordered the series to have bug fixes first followed by style fixes
  - use Reported-by for bug fixes
  - added more fixes for issues detected by checkpatch.pl --strict
 
 Irina Tirdea (17):
   iio: accel: mma9553: fix endianness issue when reading status
   iio: accel: mma9553: check input value for activity period
   iio: accel: mma9551_core: prevent buffer overrun
   iio: accel: mma9553: add enable channel for activity
   iio: accel: mma9551_core: wrong doc fixes
   iio: accel: mma9551_core: typo fix in RSC APP ID
   iio: accel: mma9553: check for error in reading initial activity and
 stepcnt
   iio: accel: mma9553: return 0 as indication of success
   iio: accel: mma9553: comment and error message fixes
   iio: accel: mma9553: use GENMASK
   iio: accel: mma9553: prefix naming fixes
   iio: accel: mma9553: fix gpio bitnum init value
   iio: accel: mma9553: refactor mma9553_read_raw
   iio: accel: mma9551_core: use size in words for word buffers
   iio: accel: mma9553: fix alignment issues
   iio: accel: mma9553: document use of mutex
   iio: accel: mma9553: use unsigned counters
 
  drivers/iio/accel/mma9551_core.c |  70 ++-
  drivers/iio/accel/mma9551_core.h |   8 +-
  drivers/iio/accel/mma9553.c  | 253 
 ++-
  3 files changed, 160 insertions(+), 171 deletions(-)
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] iio: gyro: itg3200: add suspend/resume support.

[Hartmut Knaack]

NeilBrown schrieb am 24.02.2015 um 03:24:
> 
> Unless we put the device to sleep when not it use, it wastes
> 6mA.
> 
> If the device is asleep on probe, the 'id' register
> sometimes mis-reads - so reset first.  If the device responds
> at all a command sent to the address, it is almost certainly
> the correct device already.
> 
> Acked-by: Manuel Stahl 
> Acked-by: Hartmut Knaack 

I don't recall acking on this. Anyway, no objection on the patch content.

Hartmut

> Signed-off-by: NeilBrown 
> 
> ---
> v1 of this was sent in November.  I got some useful feedback, but then got 
> distracted
> by something.  Sorry for the long gap.
> NeilBrown
> 
> 
> diff --git a/drivers/iio/gyro/itg3200_core.c b/drivers/iio/gyro/itg3200_core.c
> index 6a8020d48140..f0fd94055d88 100644
> --- a/drivers/iio/gyro/itg3200_core.c
> +++ b/drivers/iio/gyro/itg3200_core.c
> @@ -223,6 +223,10 @@ static int itg3200_initial_setup(struct iio_dev 
> *indio_dev)
>   int ret;
>   u8 val;
>  
> + ret = itg3200_reset(indio_dev);
> + if (ret)
> + goto err_ret;
> +
>   ret = itg3200_read_reg_8(indio_dev, ITG3200_REG_ADDRESS, );
>   if (ret)
>   goto err_ret;
> @@ -233,10 +237,6 @@ static int itg3200_initial_setup(struct iio_dev 
> *indio_dev)
>   goto err_ret;
>   }
>  
> - ret = itg3200_reset(indio_dev);
> - if (ret)
> - goto err_ret;
> -
>   ret = itg3200_enable_full_scale(indio_dev);
>  err_ret:
>   return ret;
> @@ -351,6 +351,26 @@ static int itg3200_remove(struct i2c_client *client)
>   return 0;
>  }
>  
> +static int __maybe_unused itg3200_suspend(struct device *dev)
> +{
> + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> + struct itg3200 *st = iio_priv(indio_dev);
> +
> + dev_dbg(>i2c->dev, "suspend device");
> +
> + return itg3200_write_reg_8(indio_dev, ITG3200_REG_POWER_MANAGEMENT,
> +ITG3200_SLEEP);
> +}
> +
> +static int __maybe_unused itg3200_resume(struct device *dev)
> +{
> + struct iio_dev *indio_dev = dev_get_drvdata(dev);
> +
> + return itg3200_initial_setup(indio_dev);
> +}
> +
> +static SIMPLE_DEV_PM_OPS(itg3200_pm_ops, itg3200_suspend, itg3200_resume);
> +
>  static const struct i2c_device_id itg3200_id[] = {
>   { "itg3200", 0 },
>   { }
> @@ -361,6 +381,7 @@ static struct i2c_driver itg3200_driver = {
>   .driver = {
>   .owner  = THIS_MODULE,
>   .name   = "itg3200",
> + .pm = _pm_ops,
>   },
>   .id_table   = itg3200_id,
>   .probe  = itg3200_probe,
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] iio: gyro: itg3200: add suspend/resume support.

[Hartmut Knaack]

NeilBrown schrieb am 24.02.2015 um 03:24:
 
 Unless we put the device to sleep when not it use, it wastes
 6mA.
 
 If the device is asleep on probe, the 'id' register
 sometimes mis-reads - so reset first.  If the device responds
 at all a command sent to the address, it is almost certainly
 the correct device already.
 
 Acked-by: Manuel Stahl manuel.st...@iis.fraunhofer.de
 Acked-by: Hartmut Knaack knaac...@gmx.de

I don't recall acking on this. Anyway, no objection on the patch content.

Hartmut

 Signed-off-by: NeilBrown n...@brown.name
 
 ---
 v1 of this was sent in November.  I got some useful feedback, but then got 
 distracted
 by something.  Sorry for the long gap.
 NeilBrown
 
 
 diff --git a/drivers/iio/gyro/itg3200_core.c b/drivers/iio/gyro/itg3200_core.c
 index 6a8020d48140..f0fd94055d88 100644
 --- a/drivers/iio/gyro/itg3200_core.c
 +++ b/drivers/iio/gyro/itg3200_core.c
 @@ -223,6 +223,10 @@ static int itg3200_initial_setup(struct iio_dev 
 *indio_dev)
   int ret;
   u8 val;
  
 + ret = itg3200_reset(indio_dev);
 + if (ret)
 + goto err_ret;
 +
   ret = itg3200_read_reg_8(indio_dev, ITG3200_REG_ADDRESS, val);
   if (ret)
   goto err_ret;
 @@ -233,10 +237,6 @@ static int itg3200_initial_setup(struct iio_dev 
 *indio_dev)
   goto err_ret;
   }
  
 - ret = itg3200_reset(indio_dev);
 - if (ret)
 - goto err_ret;
 -
   ret = itg3200_enable_full_scale(indio_dev);
  err_ret:
   return ret;
 @@ -351,6 +351,26 @@ static int itg3200_remove(struct i2c_client *client)
   return 0;
  }
  
 +static int __maybe_unused itg3200_suspend(struct device *dev)
 +{
 + struct iio_dev *indio_dev = dev_get_drvdata(dev);
 + struct itg3200 *st = iio_priv(indio_dev);
 +
 + dev_dbg(st-i2c-dev, suspend device);
 +
 + return itg3200_write_reg_8(indio_dev, ITG3200_REG_POWER_MANAGEMENT,
 +ITG3200_SLEEP);
 +}
 +
 +static int __maybe_unused itg3200_resume(struct device *dev)
 +{
 + struct iio_dev *indio_dev = dev_get_drvdata(dev);
 +
 + return itg3200_initial_setup(indio_dev);
 +}
 +
 +static SIMPLE_DEV_PM_OPS(itg3200_pm_ops, itg3200_suspend, itg3200_resume);
 +
  static const struct i2c_device_id itg3200_id[] = {
   { itg3200, 0 },
   { }
 @@ -361,6 +381,7 @@ static struct i2c_driver itg3200_driver = {
   .driver = {
   .owner  = THIS_MODULE,
   .name   = itg3200,
 + .pm = itg3200_pm_ops,
   },
   .id_table   = itg3200_id,
   .probe  = itg3200_probe,
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/3] iio: add driver for Freescale MMA9553

[Hartmut Knaack]

Irina Tirdea schrieb am 27.01.2015 um 19:41:
> Add support for Freescale MMA9553L Intelligent Pedometer Platform.
> 
> The following functionalities are supported:
>  - step counter (counts the number of steps using a HW register)
>  - step detector (generates an iio event at every step the user takes)
>  - activity recognition (rest, walking, jogging, running)
>  - speed
>  - calories
>  - distance
> 
> To get accurate pedometer results, the user's height, weight and gender
> need to be configured.
> 
> The specifications can be downloaded from:
> http://www.freescale.com/files/sensors/doc/ref_manual/MMA955xLSWRM.pdf
> http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf
> 

Hi Irina,
I still spotted a few issues and have some recommendations which you
could address in a follow-up patch. Also, there are some minor style
issues (spaces after cast, alignment issues, unnecessary blank lines),
which checkpatch.pl --strict reveals.

One other issue, where I would like to get the opinion of the other
maintainers as well, concerns some of the functions you added to
mma9551_core.c. The way they are used so far doesn't pose a threat, yet.
But I am worried about the __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS],
where the elements are accessed in relation to the len parameter. So,
should there be a check in those functions to prevent buffer overrun
problems, or just be very careful when using those functions?

> Signed-off-by: Irina Tirdea 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio |   49 +-
>  drivers/iio/accel/Kconfig   |   10 +
>  drivers/iio/accel/Makefile  |1 +
>  drivers/iio/accel/mma9551_core.c|  183 +
>  drivers/iio/accel/mma9551_core.h|   17 +-
>  drivers/iio/accel/mma9553.c | 1334 
> +++
>  6 files changed, 1589 insertions(+), 5 deletions(-)
>  create mode 100644 drivers/iio/accel/mma9553.c
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 588620e..9a70c31 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -343,7 +343,30 @@ Description:
>   production inaccuracies).  If shared across all channels,
>   _calibscale is used.
>  
> -What:/sys/bus/iio/devices/iio:deviceX/in_steps_calibheight
> +What:/sys/bus/iio/devices/iio:deviceX/in_activity_calibgender
> +What:/sys/bus/iio/devices/iio:deviceX/in_energy_calibgender
> +What:/sys/bus/iio/devices/iio:deviceX/in_distance_calibgender
> +What:/sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender
> +KernelVersion:   3.20
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Gender of the user (e.g.: male, female) used by some pedometers
> + to compute the stride length, distance, speed and activity
> + type.
> +
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender_available
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender_available
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender_available
> +What:
> /sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender_available
> +KernelVersion:   3.20
> +Contact: linux-...@vger.kernel.org
> +Description:
> + Lists all available gender values (e.g.: male, female).
> +
> +What:/sys/bus/iio/devices/iio:deviceX/in_activity_calibheight
> +What:/sys/bus/iio/devices/iio:deviceX/in_energy_calibheight
> +What:/sys/bus/iio/devices/iio:deviceX/in_distance_calibheight
> +What:/sys/bus/iio/devices/iio:deviceX/in_velocity_calibheight
>  KernelVersion:   3.19
>  Contact: linux-...@vger.kernel.org
>  Description:
> @@ -818,6 +841,14 @@ What:
> /sys/.../events/in_tempY_roc_falling_period
>  What:/sys/.../events/in_accel_x_mag_falling_period
>  What:/sys/.../events/in_intensity0_thresh_period
>  What:/sys/.../events/in_proximity0_thresh_period
> +What:/sys/.../events/in_activity_still_thresh_rising_period
> +What:/sys/.../events/in_activity_still_thresh_falling_period
> +What:/sys/.../events/in_activity_walking_thresh_rising_period
> +What:
> /sys/.../events/in_activity_walking_thresh_falling_period
> +What:/sys/.../events/in_activity_jogging_thresh_rising_period
> +What:
> /sys/.../events/in_activity_jogging_thresh_falling_period
> +What:/sys/.../events/in_activity_running_thresh_rising_period
> +What:
> /sys/.../events/in_activity_running_thresh_falling_period
>  KernelVersion:   2.6.37
>  Contact: linux-...@vger.kernel.org
>  Description:
> @@ -1142,6 +1173,12 @@ 

Re: [PATCH v3 3/3] iio: add driver for Freescale MMA9553

[Hartmut Knaack]

Irina Tirdea schrieb am 27.01.2015 um 19:41:
 Add support for Freescale MMA9553L Intelligent Pedometer Platform.
 
 The following functionalities are supported:
  - step counter (counts the number of steps using a HW register)
  - step detector (generates an iio event at every step the user takes)
  - activity recognition (rest, walking, jogging, running)
  - speed
  - calories
  - distance
 
 To get accurate pedometer results, the user's height, weight and gender
 need to be configured.
 
 The specifications can be downloaded from:
 http://www.freescale.com/files/sensors/doc/ref_manual/MMA955xLSWRM.pdf
 http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf
 

Hi Irina,
I still spotted a few issues and have some recommendations which you
could address in a follow-up patch. Also, there are some minor style
issues (spaces after cast, alignment issues, unnecessary blank lines),
which checkpatch.pl --strict reveals.

One other issue, where I would like to get the opinion of the other
maintainers as well, concerns some of the functions you added to
mma9551_core.c. The way they are used so far doesn't pose a threat, yet.
But I am worried about the __be16 be_buf[MMA9551_MAX_MAILBOX_DATA_REGS],
where the elements are accessed in relation to the len parameter. So,
should there be a check in those functions to prevent buffer overrun
problems, or just be very careful when using those functions?

 Signed-off-by: Irina Tirdea irina.tir...@intel.com
 ---
  Documentation/ABI/testing/sysfs-bus-iio |   49 +-
  drivers/iio/accel/Kconfig   |   10 +
  drivers/iio/accel/Makefile  |1 +
  drivers/iio/accel/mma9551_core.c|  183 +
  drivers/iio/accel/mma9551_core.h|   17 +-
  drivers/iio/accel/mma9553.c | 1334 
 +++
  6 files changed, 1589 insertions(+), 5 deletions(-)
  create mode 100644 drivers/iio/accel/mma9553.c
 
 diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
 b/Documentation/ABI/testing/sysfs-bus-iio
 index 588620e..9a70c31 100644
 --- a/Documentation/ABI/testing/sysfs-bus-iio
 +++ b/Documentation/ABI/testing/sysfs-bus-iio
 @@ -343,7 +343,30 @@ Description:
   production inaccuracies).  If shared across all channels,
   type_calibscale is used.
  
 -What:/sys/bus/iio/devices/iio:deviceX/in_steps_calibheight
 +What:/sys/bus/iio/devices/iio:deviceX/in_activity_calibgender
 +What:/sys/bus/iio/devices/iio:deviceX/in_energy_calibgender
 +What:/sys/bus/iio/devices/iio:deviceX/in_distance_calibgender
 +What:/sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender
 +KernelVersion:   3.20
 +Contact: linux-...@vger.kernel.org
 +Description:
 + Gender of the user (e.g.: male, female) used by some pedometers
 + to compute the stride length, distance, speed and activity
 + type.
 +
 +What:
 /sys/bus/iio/devices/iio:deviceX/in_activity_calibgender_available
 +What:
 /sys/bus/iio/devices/iio:deviceX/in_energy_calibgender_available
 +What:
 /sys/bus/iio/devices/iio:deviceX/in_distance_calibgender_available
 +What:
 /sys/bus/iio/devices/iio:deviceX/in_velocity_calibgender_available
 +KernelVersion:   3.20
 +Contact: linux-...@vger.kernel.org
 +Description:
 + Lists all available gender values (e.g.: male, female).
 +
 +What:/sys/bus/iio/devices/iio:deviceX/in_activity_calibheight
 +What:/sys/bus/iio/devices/iio:deviceX/in_energy_calibheight
 +What:/sys/bus/iio/devices/iio:deviceX/in_distance_calibheight
 +What:/sys/bus/iio/devices/iio:deviceX/in_velocity_calibheight
  KernelVersion:   3.19
  Contact: linux-...@vger.kernel.org
  Description:
 @@ -818,6 +841,14 @@ What:
 /sys/.../events/in_tempY_roc_falling_period
  What:/sys/.../events/in_accel_xyz_mag_falling_period
  What:/sys/.../events/in_intensity0_thresh_period
  What:/sys/.../events/in_proximity0_thresh_period
 +What:/sys/.../events/in_activity_still_thresh_rising_period
 +What:/sys/.../events/in_activity_still_thresh_falling_period
 +What:/sys/.../events/in_activity_walking_thresh_rising_period
 +What:
 /sys/.../events/in_activity_walking_thresh_falling_period
 +What:/sys/.../events/in_activity_jogging_thresh_rising_period
 +What:
 /sys/.../events/in_activity_jogging_thresh_falling_period
 +What:/sys/.../events/in_activity_running_thresh_rising_period
 +What:
 /sys/.../events/in_activity_running_thresh_falling_period
  KernelVersion:   2.6.37
  Contact: linux-...@vger.kernel.org
  Description:
 @@ -1142,6 +1173,12 @@ Description:
   This attribute is used to get/set the 

Re: [PATCH v2 01/10] iio: core: Introduce ENERGY channel type

[Hartmut Knaack]

Irina Tirdea schrieb am 11.01.2015 um 20:10:
> Human activity sensors report the energy burnt by the user.
> One of this devices is Freescale's MMA9553L
> (http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
> that computes the number of calories based on weight and step rate.
> 
> Introduce a new channel type ENERGY to export these values.
> 

Hi Irina,
annoyingly, some people decided to increase the major version number of the
kernel. Could you take care of updating your introduced instances from 3.20
to 4.0?
Thanks,

Hartmut

> Signed-off-by: Irina Tirdea 
> ---
>  Documentation/ABI/testing/sysfs-bus-iio | 10 ++
>  drivers/iio/industrialio-core.c |  1 +
>  include/linux/iio/types.h   |  1 +
>  3 files changed, 12 insertions(+)
> 
> diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
> b/Documentation/ABI/testing/sysfs-bus-iio
> index 831db86..3311886 100644
> --- a/Documentation/ABI/testing/sysfs-bus-iio
> +++ b/Documentation/ABI/testing/sysfs-bus-iio
> @@ -282,6 +282,7 @@ What: 
> /sys/bus/iio/devices/iio:deviceX/in_current_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_accel_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
> +What:/sys/bus/iio/devices/iio:deviceX/in_energy_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_magn_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
>  What:/sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
> @@ -1049,6 +1050,15 @@ Description:
>   For a list of available output power modes read
>   in_accel_power_mode_available.
>  
> +What:/sys/.../iio:deviceX/in_energy_input
> +What:/sys/.../iio:deviceX/in_energy_raw
> +KernelVersion:   3.20
> +Contact: linux-...@vger.kernel.org
> +Description:
> + This attribute is used to read the energy value reported by the
> + device (e.g.: human activity sensors report energy burnt by the
> + user). Units after application of scale are Joules.
> +
>  What:/sys/bus/iio/devices/iio:deviceX/store_eeprom
>  KernelVersion:   3.4.0
>  Contact: linux-...@vger.kernel.org
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index 69feb91..8d2c9ba 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -72,6 +72,7 @@ static const char * const iio_chan_type_name_spec[] = {
>   [IIO_HUMIDITYRELATIVE] = "humidityrelative",
>   [IIO_ACTIVITY] = "activity",
>   [IIO_STEPS] = "steps",
> + [IIO_ENERGY] = "energy",
>  };
>  
>  static const char * const iio_modifier_names[] = {
> diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
> index 904dcbb..26b8a1c 100644
> --- a/include/linux/iio/types.h
> +++ b/include/linux/iio/types.h
> @@ -32,6 +32,7 @@ enum iio_chan_type {
>   IIO_HUMIDITYRELATIVE,
>   IIO_ACTIVITY,
>   IIO_STEPS,
> + IIO_ENERGY,
>  };
>  
>  enum iio_modifier {
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 01/10] iio: core: Introduce ENERGY channel type

[Hartmut Knaack]

Irina Tirdea schrieb am 11.01.2015 um 20:10:
 Human activity sensors report the energy burnt by the user.
 One of this devices is Freescale's MMA9553L
 (http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf)
 that computes the number of calories based on weight and step rate.
 
 Introduce a new channel type ENERGY to export these values.
 

Hi Irina,
annoyingly, some people decided to increase the major version number of the
kernel. Could you take care of updating your introduced instances from 3.20
to 4.0?
Thanks,

Hartmut

 Signed-off-by: Irina Tirdea irina.tir...@intel.com
 ---
  Documentation/ABI/testing/sysfs-bus-iio | 10 ++
  drivers/iio/industrialio-core.c |  1 +
  include/linux/iio/types.h   |  1 +
  3 files changed, 12 insertions(+)
 
 diff --git a/Documentation/ABI/testing/sysfs-bus-iio 
 b/Documentation/ABI/testing/sysfs-bus-iio
 index 831db86..3311886 100644
 --- a/Documentation/ABI/testing/sysfs-bus-iio
 +++ b/Documentation/ABI/testing/sysfs-bus-iio
 @@ -282,6 +282,7 @@ What: 
 /sys/bus/iio/devices/iio:deviceX/in_current_scale
  What:/sys/bus/iio/devices/iio:deviceX/in_accel_scale
  What:/sys/bus/iio/devices/iio:deviceX/in_accel_peak_scale
  What:/sys/bus/iio/devices/iio:deviceX/in_anglvel_scale
 +What:/sys/bus/iio/devices/iio:deviceX/in_energy_scale
  What:/sys/bus/iio/devices/iio:deviceX/in_magn_scale
  What:/sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
  What:/sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
 @@ -1049,6 +1050,15 @@ Description:
   For a list of available output power modes read
   in_accel_power_mode_available.
  
 +What:/sys/.../iio:deviceX/in_energy_input
 +What:/sys/.../iio:deviceX/in_energy_raw
 +KernelVersion:   3.20
 +Contact: linux-...@vger.kernel.org
 +Description:
 + This attribute is used to read the energy value reported by the
 + device (e.g.: human activity sensors report energy burnt by the
 + user). Units after application of scale are Joules.
 +
  What:/sys/bus/iio/devices/iio:deviceX/store_eeprom
  KernelVersion:   3.4.0
  Contact: linux-...@vger.kernel.org
 diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
 index 69feb91..8d2c9ba 100644
 --- a/drivers/iio/industrialio-core.c
 +++ b/drivers/iio/industrialio-core.c
 @@ -72,6 +72,7 @@ static const char * const iio_chan_type_name_spec[] = {
   [IIO_HUMIDITYRELATIVE] = humidityrelative,
   [IIO_ACTIVITY] = activity,
   [IIO_STEPS] = steps,
 + [IIO_ENERGY] = energy,
  };
  
  static const char * const iio_modifier_names[] = {
 diff --git a/include/linux/iio/types.h b/include/linux/iio/types.h
 index 904dcbb..26b8a1c 100644
 --- a/include/linux/iio/types.h
 +++ b/include/linux/iio/types.h
 @@ -32,6 +32,7 @@ enum iio_chan_type {
   IIO_HUMIDITYRELATIVE,
   IIO_ACTIVITY,
   IIO_STEPS,
 + IIO_ENERGY,
  };
  
  enum iio_modifier {
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized

[Hartmut Knaack]

Pandruvada, Srinivas schrieb am 19.01.2015 um 17:56:
> On Mon, 2015-01-19 at 18:49 +0200, Daniel Baluta wrote: 
>> On Mon, Jan 19, 2015 at 6:44 PM, Pandruvada, Srinivas
>>  wrote:
>>> On Mon, 2015-01-19 at 16:40 +0200, Daniel Baluta wrote:
>>>> Hello,
>>>>
>>>> On Sat, Dec 20, 2014 at 11:29 PM, Pandruvada, Srinivas
>>>>  wrote:
>>>>> +Mika
>>>>>
>>>>> On Sat, 2014-12-20 at 13:26 -0800, Srinivas Pandruvada wrote:
>>>>>> On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote:
>>>>>>> On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack  
>>>>>>> wrote:
>>>>>>>> Daniel Baluta schrieb am 18.12.2014 um 18:16:
>>>>>>>>> When using ACPI, if acpi_match_device fails then chipset enum will be
>>>>>>>>> uninitialized and _def_array[chipset] will point to some bad 
>>>>>>>>> address.
>>>>>>>>>
>>>>>> I am missing something. You are enumerated over i2c device, which was
>>>>>> created from ACPI PNP resource. There is a valid handle or and the
>>>>>> device has an ACPI companion at the least. If this failing, I have to
>>>>>> check the code for acpi i2c.
>>>>>> Can you check why this check failed? We may have bug in i2c handling.
>>>>
>>>> You are right about this. Under normal circumstances, if probe is called
>>>> then acpi_match_device will not fail. I even tried to remove the
>>>> device after probe
>>>> but before acpi_match_device, anyhow acpi_match_device was still 
>>>> successful :)
>>>>
>>>> This is more a matter of code correctness.
>>>>
>>>> In ak8975_match_acpi_device we have:
>>>>
>>>> »   const struct acpi_device_id *id;
>>>>
>>>> »   id = acpi_match_device(dev->driver->acpi_match_table, dev);
>>>> »   if (!id)
>>>> »   »   return NULL;
>>>> »   *chipset = (int)id->driver_data;
>>>>
>>>> Compiler complains on the fact that chipset might be uninitialized
>>>> if this returns NULL, and we shouldn't ignore this warning even this case
>>>> will never happen.
>>>>
>>> Will this fix?
>>> data->chipset = AK8975;
>>> before
>>> ak8975_match_acpi_device(>dev, >chipset);
>>>

This would fix the compiler warning, but doesn't seem the right solution for
this issue. Quoting the description of acpi_match_device:
"Return a pointer to the first matching ID on success or %NULL on failure."
So, even if it is very unlikely to for it to fail - if it does fail, the
error should be handled as quick as possible. I would favor Daniels solution
to check for a valid assignment of name.

>>
>> Yes, this is done in the original patch:
>>
>> +   *chipset = AK_MAX_TYPE;
> Since data memory is not zero alloced, other member of data are anyway
> initialized, so adding this also may be better. 

If there did not occur an error condition, it will be assigned a value
before being checked for valid ranges. And if there is an error, probe
should be aborted, anyway. So initializing *chipset doesn't seem to add
any benefit IMHO.

>>
>> .. and fixes the warning.
>>
>> Daniel.
> 
> N�r��y���b�X��ǧv�^�)޺{.n�+{��*"��^n�r���z���h&���G���h�(�階�ݢj"���m�z�ޖ���f���h���~�mml==
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized

[Hartmut Knaack]

Pandruvada, Srinivas schrieb am 19.01.2015 um 17:56:
 On Mon, 2015-01-19 at 18:49 +0200, Daniel Baluta wrote: 
 On Mon, Jan 19, 2015 at 6:44 PM, Pandruvada, Srinivas
 srinivas.pandruv...@intel.com wrote:
 On Mon, 2015-01-19 at 16:40 +0200, Daniel Baluta wrote:
 Hello,

 On Sat, Dec 20, 2014 at 11:29 PM, Pandruvada, Srinivas
 srinivas.pandruv...@intel.com wrote:
 +Mika

 On Sat, 2014-12-20 at 13:26 -0800, Srinivas Pandruvada wrote:
 On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote:
 On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack knaac...@gmx.de 
 wrote:
 Daniel Baluta schrieb am 18.12.2014 um 18:16:
 When using ACPI, if acpi_match_device fails then chipset enum will be
 uninitialized and ak_def_array[chipset] will point to some bad 
 address.

 I am missing something. You are enumerated over i2c device, which was
 created from ACPI PNP resource. There is a valid handle or and the
 device has an ACPI companion at the least. If this failing, I have to
 check the code for acpi i2c.
 Can you check why this check failed? We may have bug in i2c handling.

 You are right about this. Under normal circumstances, if probe is called
 then acpi_match_device will not fail. I even tried to remove the
 device after probe
 but before acpi_match_device, anyhow acpi_match_device was still 
 successful :)

 This is more a matter of code correctness.

 In ak8975_match_acpi_device we have:

 »   const struct acpi_device_id *id;

 »   id = acpi_match_device(dev-driver-acpi_match_table, dev);
 »   if (!id)
 »   »   return NULL;
 »   *chipset = (int)id-driver_data;

 Compiler complains on the fact that chipset might be uninitialized
 if this returns NULL, and we shouldn't ignore this warning even this case
 will never happen.

 Will this fix?
 data-chipset = AK8975;
 before
 ak8975_match_acpi_device(client-dev, data-chipset);


This would fix the compiler warning, but doesn't seem the right solution for
this issue. Quoting the description of acpi_match_device:
Return a pointer to the first matching ID on success or %NULL on failure.
So, even if it is very unlikely to for it to fail - if it does fail, the
error should be handled as quick as possible. I would favor Daniels solution
to check for a valid assignment of name.


 Yes, this is done in the original patch:

 +   *chipset = AK_MAX_TYPE;
 Since data memory is not zero alloced, other member of data are anyway
 initialized, so adding this also may be better. 

If there did not occur an error condition, it will be assigned a value
before being checked for valid ranges. And if there is an error, probe
should be aborted, anyway. So initializing *chipset doesn't seem to add
any benefit IMHO.


 .. and fixes the warning.

 Daniel.
 
 N�r��y���b�X��ǧv�^�)޺{.n�+{��*��^n�r���z���h���G���h�(�階�ݢj���m�z�ޖ���f���h���~�mml==
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table

[Hartmut Knaack]

Daniel Baluta schrieb am 05.01.2015 um 10:21:
> odr_bits values are between 0 and 11, so we can use the index
> in kmx61_samp_freq_table instead of odr_bits structure member.
> 
> Signed-off-by: Daniel Baluta 
Reviewed-by: Hartmut Knaack 
> ---
> Changes since v1:
>   * use ARRAY_SIZE instead of an hardcoded value
>   * review is at: https://lkml.org/lkml/2015/1/1/46
> 
>  drivers/iio/imu/kmx61.c | 64 
> -
>  1 file changed, 26 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index b60b22d..a32ddbb 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -169,19 +169,18 @@ static const u16 kmx61_uscale_table[] = {9582, 19163, 
> 38326};
>  static const struct {
>   int val;
>   int val2;
> - u8 odr_bits;
> -} kmx61_samp_freq_table[] = { {12, 50, 0x00},
> - {25, 0, 0x01},
> - {50, 0, 0x02},
> - {100, 0, 0x03},
> - {200, 0, 0x04},
> - {400, 0, 0x05},
> - {800, 0, 0x06},
> - {1600, 0, 0x07},
> - {0, 781000, 0x08},
> - {1, 563000, 0x09},
> - {3, 125000, 0x0A},
> - {6, 25, 0x0B} };
> +} kmx61_samp_freq_table[] = { {12, 50},
> + {25, 0},
> + {50, 0},
> + {100, 0},
> + {200, 0},
> + {400, 0},
> + {800, 0},
> + {1600, 0},
> + {0, 781000},
> + {1, 563000},
> + {3, 125000},
> + {6, 25} };
>  
>  static const struct {
>   int val;
> @@ -302,24 +301,10 @@ static int kmx61_convert_freq_to_bit(int val, int val2)
>   for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
>   if (val == kmx61_samp_freq_table[i].val &&
>   val2 == kmx61_samp_freq_table[i].val2)
> - return kmx61_samp_freq_table[i].odr_bits;
> - return -EINVAL;
> -}
> -
> -static int kmx61_convert_bit_to_freq(u8 odr_bits, int *val, int *val2)
> -{
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
> - if (odr_bits == kmx61_samp_freq_table[i].odr_bits) {
> - *val = kmx61_samp_freq_table[i].val;
> - *val2 = kmx61_samp_freq_table[i].val2;
> - return 0;
> - }
> + return i;
>   return -EINVAL;
>  }
>  
> -
>  static int kmx61_convert_wake_up_odr_to_bit(int val, int val2)
>  {
>   int i;
> @@ -478,7 +463,7 @@ static int kmx61_set_odr(struct kmx61_data *data, int 
> val, int val2, u8 device)
>  
>  static int kmx61_get_odr(struct kmx61_data *data, int *val, int *val2,
>u8 device)
> -{int i;
> +{
>   u8 lodr_bits;
>  
>   if (device & KMX61_ACC)
> @@ -490,13 +475,13 @@ static int kmx61_get_odr(struct kmx61_data *data, int 
> *val, int *val2,
>   else
>   return -EINVAL;
>  
> - for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
> - if (lodr_bits == kmx61_samp_freq_table[i].odr_bits) {
> - *val = kmx61_samp_freq_table[i].val;
> - *val2 = kmx61_samp_freq_table[i].val2;
> - return 0;
> - }
> - return -EINVAL;
> + if (lodr_bits >= ARRAY_SIZE(kmx61_samp_freq_table))
> + return -EINVAL;
> +
> + *val = kmx61_samp_freq_table[lodr_bits].val;
> + *val2 = kmx61_samp_freq_table[lodr_bits].val2;
> +
> + return 0;
>  }
>  
>  static int kmx61_set_range(struct kmx61_data *data, u8 range)
> @@ -580,8 +565,11 @@ static int kmx61_chip_init(struct kmx61_data *data)
>   }
>   data->odr_bits = ret;
>  
> - /* set output data rate for wake up (motion detection) function */
> - ret = kmx61_convert_bit_to_freq(data->odr_bits, , );
> + /*
> +  * set output data rate for wake up (motion detection) function
> +  * to match data rate for accelerometer sampling
> +  */
> + ret = kmx61_get_odr(data, , , KMX61_ACC);
>   if (ret < 0)
>   return ret;
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table

[Hartmut Knaack]

Daniel Baluta schrieb am 05.01.2015 um 10:21:
 odr_bits values are between 0 and 11, so we can use the index
 in kmx61_samp_freq_table instead of odr_bits structure member.
 
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Reviewed-by: Hartmut Knaack knaac...@gmx.de
 ---
 Changes since v1:
   * use ARRAY_SIZE instead of an hardcoded value
   * review is at: https://lkml.org/lkml/2015/1/1/46
 
  drivers/iio/imu/kmx61.c | 64 
 -
  1 file changed, 26 insertions(+), 38 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index b60b22d..a32ddbb 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -169,19 +169,18 @@ static const u16 kmx61_uscale_table[] = {9582, 19163, 
 38326};
  static const struct {
   int val;
   int val2;
 - u8 odr_bits;
 -} kmx61_samp_freq_table[] = { {12, 50, 0x00},
 - {25, 0, 0x01},
 - {50, 0, 0x02},
 - {100, 0, 0x03},
 - {200, 0, 0x04},
 - {400, 0, 0x05},
 - {800, 0, 0x06},
 - {1600, 0, 0x07},
 - {0, 781000, 0x08},
 - {1, 563000, 0x09},
 - {3, 125000, 0x0A},
 - {6, 25, 0x0B} };
 +} kmx61_samp_freq_table[] = { {12, 50},
 + {25, 0},
 + {50, 0},
 + {100, 0},
 + {200, 0},
 + {400, 0},
 + {800, 0},
 + {1600, 0},
 + {0, 781000},
 + {1, 563000},
 + {3, 125000},
 + {6, 25} };
  
  static const struct {
   int val;
 @@ -302,24 +301,10 @@ static int kmx61_convert_freq_to_bit(int val, int val2)
   for (i = 0; i  ARRAY_SIZE(kmx61_samp_freq_table); i++)
   if (val == kmx61_samp_freq_table[i].val 
   val2 == kmx61_samp_freq_table[i].val2)
 - return kmx61_samp_freq_table[i].odr_bits;
 - return -EINVAL;
 -}
 -
 -static int kmx61_convert_bit_to_freq(u8 odr_bits, int *val, int *val2)
 -{
 - int i;
 -
 - for (i = 0; i  ARRAY_SIZE(kmx61_samp_freq_table); i++)
 - if (odr_bits == kmx61_samp_freq_table[i].odr_bits) {
 - *val = kmx61_samp_freq_table[i].val;
 - *val2 = kmx61_samp_freq_table[i].val2;
 - return 0;
 - }
 + return i;
   return -EINVAL;
  }
  
 -
  static int kmx61_convert_wake_up_odr_to_bit(int val, int val2)
  {
   int i;
 @@ -478,7 +463,7 @@ static int kmx61_set_odr(struct kmx61_data *data, int 
 val, int val2, u8 device)
  
  static int kmx61_get_odr(struct kmx61_data *data, int *val, int *val2,
u8 device)
 -{int i;
 +{
   u8 lodr_bits;
  
   if (device  KMX61_ACC)
 @@ -490,13 +475,13 @@ static int kmx61_get_odr(struct kmx61_data *data, int 
 *val, int *val2,
   else
   return -EINVAL;
  
 - for (i = 0; i  ARRAY_SIZE(kmx61_samp_freq_table); i++)
 - if (lodr_bits == kmx61_samp_freq_table[i].odr_bits) {
 - *val = kmx61_samp_freq_table[i].val;
 - *val2 = kmx61_samp_freq_table[i].val2;
 - return 0;
 - }
 - return -EINVAL;
 + if (lodr_bits = ARRAY_SIZE(kmx61_samp_freq_table))
 + return -EINVAL;
 +
 + *val = kmx61_samp_freq_table[lodr_bits].val;
 + *val2 = kmx61_samp_freq_table[lodr_bits].val2;
 +
 + return 0;
  }
  
  static int kmx61_set_range(struct kmx61_data *data, u8 range)
 @@ -580,8 +565,11 @@ static int kmx61_chip_init(struct kmx61_data *data)
   }
   data-odr_bits = ret;
  
 - /* set output data rate for wake up (motion detection) function */
 - ret = kmx61_convert_bit_to_freq(data-odr_bits, val, val2);
 + /*
 +  * set output data rate for wake up (motion detection) function
 +  * to match data rate for accelerometer sampling
 +  */
 + ret = kmx61_get_odr(data, val, val2, KMX61_ACC);
   if (ret  0)
   return ret;
  
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/10] iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table

[Hartmut Knaack]

Jonathan Cameron schrieb am 04.01.2015 um 11:55:
> On 01/01/15 13:53, Hartmut Knaack wrote:
>> Daniel Baluta schrieb am 23.12.2014 um 14:22:
>>> odr_bits values are between 0 and 11, so we can use the index
>>> in kmx61_samp_freq_table instead of odr_bits structure member.
>> Basically looking good, but I would feel more comfortable to check
>> against the boundaries of the table. Please see inline.
>>
>>>
>>> Signed-off-by: Daniel Baluta 
>>> ---
>>>  drivers/iio/imu/kmx61.c | 64 
>>> -
>>>  1 file changed, 26 insertions(+), 38 deletions(-)
>>>
>>> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
>>> index eb3900e..98369eb 100644
>>> --- a/drivers/iio/imu/kmx61.c
>>> +++ b/drivers/iio/imu/kmx61.c
>>> @@ -169,19 +169,18 @@ u16 kmx61_uscale_table[] = {9582, 19163, 38326};
>>>  static const struct {
>>> int val;
>>> int val2;
>>> -   u8 odr_bits;
>>> -} kmx61_samp_freq_table[] = { {12, 50, 0x00},
>>> -   {25, 0, 0x01},
>>> -   {50, 0, 0x02},
>>> -   {100, 0, 0x03},
>>> -   {200, 0, 0x04},
>>> -   {400, 0, 0x05},
>>> -   {800, 0, 0x06},
>>> -   {1600, 0, 0x07},
>>> -   {0, 781000, 0x08},
>>> -   {1, 563000, 0x09},
>>> -   {3, 125000, 0x0A},
>>> -   {6, 25, 0x0B} };
>>> +} kmx61_samp_freq_table[] = { {12, 50},
>>> +   {25, 0},
>>> +   {50, 0},
>>> +   {100, 0},
>>> +   {200, 0},
>>> +   {400, 0},
>>> +   {800, 0},
>>> +   {1600, 0},
>>> +   {0, 781000},
>>> +   {1, 563000},
>>> +   {3, 125000},
>>> +   {6, 25} };
>>>  
>>>  static const struct {
>>> int val;
>>> @@ -302,24 +301,10 @@ static int kmx61_convert_freq_to_bit(int val, int 
>>> val2)
>>> for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
>>> if (val == kmx61_samp_freq_table[i].val &&
>>> val2 == kmx61_samp_freq_table[i].val2)
>>> -   return kmx61_samp_freq_table[i].odr_bits;
>>> -   return -EINVAL;
>>> -}
>>> -
>>> -static int kmx61_convert_bit_to_freq(u8 odr_bits, int *val, int *val2)
>>> -{
>>> -   int i;
>>> -
>>> -   for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
>>> -   if (odr_bits == kmx61_samp_freq_table[i].odr_bits) {
>>> -   *val = kmx61_samp_freq_table[i].val;
>>> -   *val2 = kmx61_samp_freq_table[i].val2;
>>> -   return 0;
>>> -   }
>>> +   return i;
>>> return -EINVAL;
>>>  }
>>>  
>>> -
>>>  static int kmx61_convert_wake_up_odr_to_bit(int val, int val2)
>>>  {
>>> int i;
>>> @@ -478,7 +463,7 @@ static int kmx61_set_odr(struct kmx61_data *data, int 
>>> val, int val2, u8 device)
>>>  
>>>  static int kmx61_get_odr(struct kmx61_data *data, int *val, int *val2,
>>>  u8 device)
>>> -{  int i;
>>> +{
>>> u8 lodr_bits;
>>>  
>>> if (device & KMX61_ACC)
>>> @@ -490,13 +475,13 @@ static int kmx61_get_odr(struct kmx61_data *data, int 
>>> *val, int *val2,
>>> else
>>> return -EINVAL;
>>>  
>>> -   for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
>>> -   if (lodr_bits == kmx61_samp_freq_table[i].odr_bits) {
>>> -   *val = kmx61_samp_freq_table[i].val;
>>> -   *val2 = kmx61_samp_freq_table[i].val2;
>>> -   return 0;
>>> -   }
>>> -   return -EINVAL;
>>> +   if (lodr_bits > 0xB)
>> Since we use it as an index, I regard it safer to check against
>> ARRAY_SIZE(kmx61_samp_freq_table) rather than a fix value.
> Makes sense to me as well - though obviously 
> ARRAY_SIZE(kmx61_samp_freq_table) is
> 0xC (12) rather than 0xB (11) so you'll need a minus 1
> 
Instead of subtracting, I would favor this one:
if !(lodr_bits < ARRAY_SIZ

Re: [PATCH 09/10] iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table

[Hartmut Knaack]

Jonathan Cameron schrieb am 04.01.2015 um 11:55:
 On 01/01/15 13:53, Hartmut Knaack wrote:
 Daniel Baluta schrieb am 23.12.2014 um 14:22:
 odr_bits values are between 0 and 11, so we can use the index
 in kmx61_samp_freq_table instead of odr_bits structure member.
 Basically looking good, but I would feel more comfortable to check
 against the boundaries of the table. Please see inline.


 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
  drivers/iio/imu/kmx61.c | 64 
 -
  1 file changed, 26 insertions(+), 38 deletions(-)

 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index eb3900e..98369eb 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -169,19 +169,18 @@ u16 kmx61_uscale_table[] = {9582, 19163, 38326};
  static const struct {
 int val;
 int val2;
 -   u8 odr_bits;
 -} kmx61_samp_freq_table[] = { {12, 50, 0x00},
 -   {25, 0, 0x01},
 -   {50, 0, 0x02},
 -   {100, 0, 0x03},
 -   {200, 0, 0x04},
 -   {400, 0, 0x05},
 -   {800, 0, 0x06},
 -   {1600, 0, 0x07},
 -   {0, 781000, 0x08},
 -   {1, 563000, 0x09},
 -   {3, 125000, 0x0A},
 -   {6, 25, 0x0B} };
 +} kmx61_samp_freq_table[] = { {12, 50},
 +   {25, 0},
 +   {50, 0},
 +   {100, 0},
 +   {200, 0},
 +   {400, 0},
 +   {800, 0},
 +   {1600, 0},
 +   {0, 781000},
 +   {1, 563000},
 +   {3, 125000},
 +   {6, 25} };
  
  static const struct {
 int val;
 @@ -302,24 +301,10 @@ static int kmx61_convert_freq_to_bit(int val, int 
 val2)
 for (i = 0; i  ARRAY_SIZE(kmx61_samp_freq_table); i++)
 if (val == kmx61_samp_freq_table[i].val 
 val2 == kmx61_samp_freq_table[i].val2)
 -   return kmx61_samp_freq_table[i].odr_bits;
 -   return -EINVAL;
 -}
 -
 -static int kmx61_convert_bit_to_freq(u8 odr_bits, int *val, int *val2)
 -{
 -   int i;
 -
 -   for (i = 0; i  ARRAY_SIZE(kmx61_samp_freq_table); i++)
 -   if (odr_bits == kmx61_samp_freq_table[i].odr_bits) {
 -   *val = kmx61_samp_freq_table[i].val;
 -   *val2 = kmx61_samp_freq_table[i].val2;
 -   return 0;
 -   }
 +   return i;
 return -EINVAL;
  }
  
 -
  static int kmx61_convert_wake_up_odr_to_bit(int val, int val2)
  {
 int i;
 @@ -478,7 +463,7 @@ static int kmx61_set_odr(struct kmx61_data *data, int 
 val, int val2, u8 device)
  
  static int kmx61_get_odr(struct kmx61_data *data, int *val, int *val2,
  u8 device)
 -{  int i;
 +{
 u8 lodr_bits;
  
 if (device  KMX61_ACC)
 @@ -490,13 +475,13 @@ static int kmx61_get_odr(struct kmx61_data *data, int 
 *val, int *val2,
 else
 return -EINVAL;
  
 -   for (i = 0; i  ARRAY_SIZE(kmx61_samp_freq_table); i++)
 -   if (lodr_bits == kmx61_samp_freq_table[i].odr_bits) {
 -   *val = kmx61_samp_freq_table[i].val;
 -   *val2 = kmx61_samp_freq_table[i].val2;
 -   return 0;
 -   }
 -   return -EINVAL;
 +   if (lodr_bits  0xB)
 Since we use it as an index, I regard it safer to check against
 ARRAY_SIZE(kmx61_samp_freq_table) rather than a fix value.
 Makes sense to me as well - though obviously 
 ARRAY_SIZE(kmx61_samp_freq_table) is
 0xC (12) rather than 0xB (11) so you'll need a minus 1
 
Instead of subtracting, I would favor this one:
if !(lodr_bits  ARRAY_SIZE(...))

Or this one:
if (lodr_bits = ARRAY_SIZE(...))

 I'll leave this one for a new spin.

 +   return -EINVAL;
 +
 +   *val = kmx61_samp_freq_table[lodr_bits].val;
 +   *val2 = kmx61_samp_freq_table[lodr_bits].val2;
 +
 +   return 0;
  }
  
  static int kmx61_set_range(struct kmx61_data *data, u8 range)
 @@ -580,8 +565,11 @@ static int kmx61_chip_init(struct kmx61_data *data)
 }
 data-odr_bits = ret;
  
 -   /* set output data rate for wake up (motion detection) function */
 -   ret = kmx61_convert_bit_to_freq(data-odr_bits, val, val2);
 +   /*
 +* set output data rate for wake up (motion detection) function
 +* to match data rate for accelerometer sampling
 +*/
 +   ret = kmx61_get_odr(data, val, val2, KMX61_ACC);
 if (ret  0)
 return ret;
  


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

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

Re: [PATCH v5 3/7] iio: Add support for DA9150 GPADC

[Hartmut Knaack]

Adam Thomson schrieb am 22.12.2014 um 17:51:
> This patch adds support for DA9150 Charger & Fuel-Gauge IC GPADC.
> 
> Signed-off-by: Adam Thomson 
Reviewed-by: Hartmut Knaack 
> ---
>  drivers/iio/adc/Kconfig|   9 +
>  drivers/iio/adc/Makefile   |   1 +
>  drivers/iio/adc/da9150-gpadc.c | 409 
> +
>  3 files changed, 419 insertions(+)
>  create mode 100644 drivers/iio/adc/da9150-gpadc.c
> 
> diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> index 0f79e47..6e00b81 100644
> --- a/drivers/iio/adc/Kconfig
> +++ b/drivers/iio/adc/Kconfig
> @@ -135,6 +135,15 @@ config AXP288_ADC
> device. Depending on platform configuration, this general purpose ADC 
> can
> be used for sampling sensors such as thermal resistors.
> 
> +config DA9150_GPADC
> + tristate "Dialog DA9150 GPADC driver support"
> + depends on MFD_DA9150
> + help
> +   Say yes here to build support for Dialog DA9150 GPADC.
> +
> +   This driver can also be built as a module. If chosen, the module name
> +   will be da9150-gpadc.
> +
>  config EXYNOS_ADC
>   tristate "Exynos ADC driver support"
>   depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF && 
> COMPILE_TEST)
> diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> index 701fdb7..d56ee9b 100644
> --- a/drivers/iio/adc/Makefile
> +++ b/drivers/iio/adc/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
>  obj-$(CONFIG_AD799X) += ad799x.o
>  obj-$(CONFIG_AT91_ADC) += at91_adc.o
>  obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
> +obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
>  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
>  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
>  obj-$(CONFIG_MAX1027) += max1027.o
> diff --git a/drivers/iio/adc/da9150-gpadc.c b/drivers/iio/adc/da9150-gpadc.c
> new file mode 100644
> index 000..3f7bc81
> --- /dev/null
> +++ b/drivers/iio/adc/da9150-gpadc.c
> @@ -0,0 +1,409 @@
> +/*
> + * DA9150 GPADC Driver
> + *
> + * Copyright (c) 2014 Dialog Semiconductor
> + *
> + * Author: Adam Thomson 
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/* Channels */
> +enum da9150_gpadc_hw_channel {
> + DA9150_GPADC_HW_CHAN_GPIOA_2V = 0,
> + DA9150_GPADC_HW_CHAN_GPIOA_2V_,
> + DA9150_GPADC_HW_CHAN_GPIOB_2V,
> + DA9150_GPADC_HW_CHAN_GPIOB_2V_,
> + DA9150_GPADC_HW_CHAN_GPIOC_2V,
> + DA9150_GPADC_HW_CHAN_GPIOC_2V_,
> + DA9150_GPADC_HW_CHAN_GPIOD_2V,
> + DA9150_GPADC_HW_CHAN_GPIOD_2V_,
> + DA9150_GPADC_HW_CHAN_IBUS_SENSE,
> + DA9150_GPADC_HW_CHAN_IBUS_SENSE_,
> + DA9150_GPADC_HW_CHAN_VBUS_DIV,
> + DA9150_GPADC_HW_CHAN_VBUS_DIV_,
> + DA9150_GPADC_HW_CHAN_ID,
> + DA9150_GPADC_HW_CHAN_ID_,
> + DA9150_GPADC_HW_CHAN_VSYS,
> + DA9150_GPADC_HW_CHAN_VSYS_,
> + DA9150_GPADC_HW_CHAN_GPIOA_6V,
> + DA9150_GPADC_HW_CHAN_GPIOA_6V_,
> + DA9150_GPADC_HW_CHAN_GPIOB_6V,
> + DA9150_GPADC_HW_CHAN_GPIOB_6V_,
> + DA9150_GPADC_HW_CHAN_GPIOC_6V,
> + DA9150_GPADC_HW_CHAN_GPIOC_6V_,
> + DA9150_GPADC_HW_CHAN_GPIOD_6V,
> + DA9150_GPADC_HW_CHAN_GPIOD_6V_,
> + DA9150_GPADC_HW_CHAN_VBAT,
> + DA9150_GPADC_HW_CHAN_VBAT_,
> + DA9150_GPADC_HW_CHAN_TBAT,
> + DA9150_GPADC_HW_CHAN_TBAT_,
> + DA9150_GPADC_HW_CHAN_TJUNC_CORE,
> + DA9150_GPADC_HW_CHAN_TJUNC_CORE_,
> + DA9150_GPADC_HW_CHAN_TJUNC_OVP,
> + DA9150_GPADC_HW_CHAN_TJUNC_OVP_,
> +};
> +
> +enum da9150_gpadc_channel {
> + DA9150_GPADC_CHAN_GPIOA = 0,
> + DA9150_GPADC_CHAN_GPIOB,
> + DA9150_GPADC_CHAN_GPIOC,
> + DA9150_GPADC_CHAN_GPIOD,
> + DA9150_GPADC_CHAN_IBUS,
> + DA9150_GPADC_CHAN_VBUS,
> + DA9150_GPADC_CHAN_ID,
> + DA9150_GPADC_CHAN_VSYS,
> + DA9150_GPADC_CHAN_VBAT,
> + DA9150_GPADC_CHAN_TBAT,
> + DA9150_GPADC_CHAN_TJUNC_CORE,
> + DA9150_GPADC_CHAN_TJUNC_OVP,
> +};
> +
> +/* Private data */
> +struct da9150_gpadc {
> + struct da9150 *da9150;
> + struct device *dev;
> +
> + struct mutex lock;
> + struct completion complete;
> +};
> +
> +
> +static irqreturn_t da9150_gpadc_irq(int irq, void

Re: [PATCH 10/10] iio: imu: kmx61: Use correct base when reading data

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> We have two IIO devices and we need to adjust the base
> when reading data.
> 
> Signed-off-by: Daniel Baluta 
Reviewed-by: Hartmut Knaack 
> ---
>  drivers/iio/imu/kmx61.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 98369eb..6178cea 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -1210,12 +1210,18 @@ static irqreturn_t kmx61_trigger_handler(int irq, 
> void *p)
>   struct iio_dev *indio_dev = pf->indio_dev;
>   struct kmx61_data *data = kmx61_get_data(indio_dev);
>   int bit, ret, i = 0;
> + u8 base;
>   s16 buffer[8];
>  
> + if (indio_dev == data->acc_indio_dev)
> + base = KMX61_ACC_XOUT_L;
> + else
> + base = KMX61_MAG_XOUT_L;
> +
>   mutex_lock(>lock);
>   for_each_set_bit(bit, indio_dev->buffer->scan_mask,
>indio_dev->masklength) {
> - ret = kmx61_read_measurement(data, KMX61_ACC_XOUT_L, bit);
> + ret = kmx61_read_measurement(data, base, bit);
>   if (ret < 0) {
>   mutex_unlock(>lock);
>   goto err;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 09/10] iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> odr_bits values are between 0 and 11, so we can use the index
> in kmx61_samp_freq_table instead of odr_bits structure member.
Basically looking good, but I would feel more comfortable to check
against the boundaries of the table. Please see inline.

> 
> Signed-off-by: Daniel Baluta 
> ---
>  drivers/iio/imu/kmx61.c | 64 
> -
>  1 file changed, 26 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index eb3900e..98369eb 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -169,19 +169,18 @@ u16 kmx61_uscale_table[] = {9582, 19163, 38326};
>  static const struct {
>   int val;
>   int val2;
> - u8 odr_bits;
> -} kmx61_samp_freq_table[] = { {12, 50, 0x00},
> - {25, 0, 0x01},
> - {50, 0, 0x02},
> - {100, 0, 0x03},
> - {200, 0, 0x04},
> - {400, 0, 0x05},
> - {800, 0, 0x06},
> - {1600, 0, 0x07},
> - {0, 781000, 0x08},
> - {1, 563000, 0x09},
> - {3, 125000, 0x0A},
> - {6, 25, 0x0B} };
> +} kmx61_samp_freq_table[] = { {12, 50},
> + {25, 0},
> + {50, 0},
> + {100, 0},
> + {200, 0},
> + {400, 0},
> + {800, 0},
> + {1600, 0},
> + {0, 781000},
> + {1, 563000},
> + {3, 125000},
> + {6, 25} };
>  
>  static const struct {
>   int val;
> @@ -302,24 +301,10 @@ static int kmx61_convert_freq_to_bit(int val, int val2)
>   for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
>   if (val == kmx61_samp_freq_table[i].val &&
>   val2 == kmx61_samp_freq_table[i].val2)
> - return kmx61_samp_freq_table[i].odr_bits;
> - return -EINVAL;
> -}
> -
> -static int kmx61_convert_bit_to_freq(u8 odr_bits, int *val, int *val2)
> -{
> - int i;
> -
> - for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
> - if (odr_bits == kmx61_samp_freq_table[i].odr_bits) {
> - *val = kmx61_samp_freq_table[i].val;
> - *val2 = kmx61_samp_freq_table[i].val2;
> - return 0;
> - }
> + return i;
>   return -EINVAL;
>  }
>  
> -
>  static int kmx61_convert_wake_up_odr_to_bit(int val, int val2)
>  {
>   int i;
> @@ -478,7 +463,7 @@ static int kmx61_set_odr(struct kmx61_data *data, int 
> val, int val2, u8 device)
>  
>  static int kmx61_get_odr(struct kmx61_data *data, int *val, int *val2,
>u8 device)
> -{int i;
> +{
>   u8 lodr_bits;
>  
>   if (device & KMX61_ACC)
> @@ -490,13 +475,13 @@ static int kmx61_get_odr(struct kmx61_data *data, int 
> *val, int *val2,
>   else
>   return -EINVAL;
>  
> - for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
> - if (lodr_bits == kmx61_samp_freq_table[i].odr_bits) {
> - *val = kmx61_samp_freq_table[i].val;
> - *val2 = kmx61_samp_freq_table[i].val2;
> - return 0;
> - }
> - return -EINVAL;
> + if (lodr_bits > 0xB)
Since we use it as an index, I regard it safer to check against
ARRAY_SIZE(kmx61_samp_freq_table) rather than a fix value.

> + return -EINVAL;
> +
> + *val = kmx61_samp_freq_table[lodr_bits].val;
> + *val2 = kmx61_samp_freq_table[lodr_bits].val2;
> +
> + return 0;
>  }
>  
>  static int kmx61_set_range(struct kmx61_data *data, u8 range)
> @@ -580,8 +565,11 @@ static int kmx61_chip_init(struct kmx61_data *data)
>   }
>   data->odr_bits = ret;
>  
> - /* set output data rate for wake up (motion detection) function */
> - ret = kmx61_convert_bit_to_freq(data->odr_bits, , );
> + /*
> +  * set output data rate for wake up (motion detection) function
> +  * to match data rate for accelerometer sampling
> +  */
> + ret = kmx61_get_odr(data, , , KMX61_ACC);
>   if (ret < 0)
>   return ret;
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] iio: imu: kmx61: Remove unnecessary REG_INS1 read

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> Useful in the debugging phase, not needed now.
> 
> Signed-off-by: Daniel Baluta 
Acked-by: Hartmut Knaack 
> ---
>  drivers/iio/imu/kmx61.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 5b5be2b..eb3900e 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -1196,8 +1196,6 @@ ack_intr:
>   if (ret < 0)
>   dev_err(>client->dev, "Error reading reg_inl\n");
>  
> - ret = i2c_smbus_read_byte_data(data->client, KMX61_REG_INS1);
> -
>   return IRQ_HANDLED;
>  }
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/10] iio: imu: kmx61: Fix device initialization when setting trigger state

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> Signed-off-by: Daniel Baluta 
Acked-by: Hartmut Knaack 
> ---
>  drivers/iio/imu/kmx61.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 30825cf..5b5be2b 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -1057,8 +1057,7 @@ static int kmx61_data_rdy_trigger_set_state(struct 
> iio_trigger *trig,
>   goto err_unlock;
>   }
>  
> -
> - if (data->acc_dready_trig == trig || data->motion_trig)
> + if (data->acc_dready_trig == trig || data->motion_trig == trig)
>   device = KMX61_ACC;
>   else
>   device = KMX61_MAG;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/10] iio: imu: kmx61: Use false instead of 0 for ev_enable_state

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> Signed-off-by: Daniel Baluta 
Acked-by: Hartmut Knaack 
> ---
>  drivers/iio/imu/kmx61.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 332ee67..30825cf 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -976,7 +976,7 @@ static int kmx61_write_event_config(struct iio_dev 
> *indio_dev,
>   mutex_lock(>lock);
>  
>   if (!state && data->motion_trig_on) {
> - data->ev_enable_state = 0;
> + data->ev_enable_state = false;
>   goto err_unlock;
>   }
>  
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/10] iio: imu: kmx61: Drop unused device parameter

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> Signed-off-by: Daniel Baluta 
Reviewed-by: Hartmut Knaack 
> ---
>  drivers/iio/imu/kmx61.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 2652179..332ee67 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -681,7 +681,7 @@ static int kmx61_chip_update_thresholds(struct kmx61_data 
> *data)
>  }
>  
>  static int kmx61_setup_any_motion_interrupt(struct kmx61_data *data,
> - bool status, u8 device)
> + bool status)
>  {
>   u8 mode;
>   int ret;
> @@ -984,7 +984,7 @@ static int kmx61_write_event_config(struct iio_dev 
> *indio_dev,
>   if (ret < 0)
>   goto err_unlock;
>  
> - ret = kmx61_setup_any_motion_interrupt(data, state, KMX61_ACC);
> + ret = kmx61_setup_any_motion_interrupt(data, state);
>   if (ret < 0) {
>   kmx61_set_power_state(data, false, KMX61_ACC);
>   goto err_unlock;
> @@ -1070,7 +1070,7 @@ static int kmx61_data_rdy_trigger_set_state(struct 
> iio_trigger *trig,
>   if (data->acc_dready_trig == trig || data->mag_dready_trig == trig)
>   ret = kmx61_setup_new_data_interrupt(data, state, device);
>   else
> - ret = kmx61_setup_any_motion_interrupt(data, state, KMX61_ACC);
> + ret = kmx61_setup_any_motion_interrupt(data, state);
>   if (ret < 0) {
>   kmx61_set_power_state(data, false, device);
>   goto err_unlock;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/10] iio: imu: kmx61: Fixup parameters alignment

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> Signed-off-by: Daniel Baluta 
Acked-by: Hartmut Knaack 
> ---
>  drivers/iio/imu/kmx61.c | 18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 4fc4f63..2652179 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -926,11 +926,11 @@ static int kmx61_read_event(struct iio_dev *indio_dev,
>  }
>  
>  static int kmx61_write_event(struct iio_dev *indio_dev,
> - const struct iio_chan_spec *chan,
> - enum iio_event_type type,
> - enum iio_event_direction dir,
> - enum iio_event_info info,
> - int val, int val2)
> +  const struct iio_chan_spec *chan,
> +  enum iio_event_type type,
> +  enum iio_event_direction dir,
> +  enum iio_event_info info,
> +  int val, int val2)
>  {
>   struct kmx61_data *data = kmx61_get_data(indio_dev);
>  
> @@ -962,10 +962,10 @@ static int kmx61_read_event_config(struct iio_dev 
> *indio_dev,
>  }
>  
>  static int kmx61_write_event_config(struct iio_dev *indio_dev,
> -const struct iio_chan_spec *chan,
> -enum iio_event_type type,
> -enum iio_event_direction dir,
> -int state)
> + const struct iio_chan_spec *chan,
> + enum iio_event_type type,
> + enum iio_event_direction dir,
> + int state)
>  {
>   struct kmx61_data *data = kmx61_get_data(indio_dev);
>   int ret = 0;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/10] iio: imu: kmx61: Enhance error handling

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> This fixes parts of kmx61 error handling to make code easier to read and to be
> more consistent with IIO coding conventions:
>   * prefer as single point for error handling instead of duplicating code
>   for each function
>   * directly return a value from a case branch instead of breaking
>   * fix error message for writing REG_CTRL1
> 
> Also, add separate error paths for 
> kmx61_trigger_setup/iio_triggered_buffer_setup
> calls.
Some issues remain in this one, please see inline. Otherwise looking good.

> 
> Signed-off-by: Daniel Baluta 
> ---
>  drivers/iio/imu/kmx61.c | 100 
> +---
>  1 file changed, 43 insertions(+), 57 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index e9cbd91..4fc4f63 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -656,11 +656,7 @@ static int kmx61_setup_new_data_interrupt(struct 
> kmx61_data *data,
>   return ret;
>   }
>  
> - ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
> - if (ret)
> - return ret;
> -
> - return 0;
> + return kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
>  }
>  
>  static int kmx61_chip_update_thresholds(struct kmx61_data *data)
> @@ -678,12 +674,10 @@ static int kmx61_chip_update_thresholds(struct 
> kmx61_data *data)
>   ret = i2c_smbus_write_byte_data(data->client,
>   KMX61_REG_WUF_THRESH,
>   data->wake_thresh);
> - if (ret < 0) {
> + if (ret < 0)
>   dev_err(>client->dev, "Error writing reg_wuf_thresh\n");
> - return ret;
> - }
>  
> - return 0;
> + return ret;
>  }
>  
>  static int kmx61_setup_any_motion_interrupt(struct kmx61_data *data,
> @@ -737,11 +731,7 @@ static int kmx61_setup_any_motion_interrupt(struct 
> kmx61_data *data,
>   return ret;
>   }
>   mode |= KMX61_ACT_STBY_BIT;
> - ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
> - if (ret)
> - return ret;
> -
> - return 0;
> + return kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
>  }
>  
>  /**
> @@ -924,10 +914,10 @@ static int kmx61_read_event(struct iio_dev *indio_dev,
>   switch (info) {
>   case IIO_EV_INFO_VALUE:
>   *val = data->wake_thresh;
> - break;
> + return IIO_VAL_INT;
>   case IIO_EV_INFO_PERIOD:
>   *val = data->wake_duration;
> - break;
> + return IIO_VAL_INT;
>   default:
>   return -EINVAL;
>   }
Down below this line is still a return IIO_VAL_INT, which is now obsolete.
> @@ -950,10 +940,10 @@ static int kmx61_write_event(struct iio_dev *indio_dev,
>   switch (info) {
>   case IIO_EV_INFO_VALUE:
>   data->wake_thresh = val;
> - break;
> + return IIO_VAL_INT;
>   case IIO_EV_INFO_PERIOD:
>   data->wake_duration = val;
> - break;
> + return IIO_VAL_INT;
>   default:
>   return -EINVAL;
>   }
Same obsolete return exists below this line.
> @@ -978,7 +968,7 @@ static int kmx61_write_event_config(struct iio_dev 
> *indio_dev,
>  int state)
>  {
>   struct kmx61_data *data = kmx61_get_data(indio_dev);
> - int ret;
> + int ret = 0;
>  
>   if (state && data->ev_enable_state)
>   return 0;
> @@ -987,27 +977,25 @@ static int kmx61_write_event_config(struct iio_dev 
> *indio_dev,
>  
>   if (!state && data->motion_trig_on) {
>   data->ev_enable_state = 0;
> - mutex_unlock(>lock);
> - return 0;
> + goto err_unlock;
>   }
>  
>   ret = kmx61_set_power_state(data, state, KMX61_ACC);
> - if (ret < 0) {
> - mutex_unlock(>lock);
> - return ret;
> - }
> + if (ret < 0)
> + goto err_unlock;
>  
>   ret = kmx61_setup_any_motion_interrupt(data, state, KMX61_ACC);
>   if (ret < 0) {
>   kmx61_set_power_state(data, false, KMX61_ACC);
> - mutex_unlock(>lock);
> - return ret;
> + goto err_unlock;
>   }
>  
>   data->ev_enable_state = state;
> +
> +err_unlock:
>   mutex_unlock(>lock);
>  
> - return 0;
> + return ret;
>  }
>  
>  static int kmx61_acc_validate_trigger(struct iio_dev *indio_dev,
> @@ -1066,8 +1054,7 @@ static int kmx61_data_rdy_trigger_set_state(struct 
> iio_trigger *trig,
>  
>   if (!state && data->ev_enable_state && data->motion_trig_on) {
>   data->motion_trig_on = false;
> - mutex_unlock(>lock);
> - return 0;
> + goto err_unlock;
>   }
>  
>  
> @@ -1077,10 +1064,8 @@ static int kmx61_data_rdy_trigger_set_state(struct 
> iio_trigger *trig,
> 

Re: [PATCH 02/10] iio: imu: kmx61: Don't ignore kmx61_set_power_state errors

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> ..except while in an error handler, where there is nothing
> to be done anyway.
> 
> Signed-off-by: Daniel Baluta 
Reviewed-by: Hartmut Knaack 
> ---
>  drivers/iio/imu/kmx61.c | 11 +--
>  1 file changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index fe0cee7..e9cbd91 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -830,7 +830,12 @@ static int kmx61_read_raw(struct iio_dev *indio_dev,
>   }
>   mutex_lock(>lock);
>  
> - kmx61_set_power_state(data, true, chan->address);
> + ret = kmx61_set_power_state(data, true, chan->address);
> + if (ret) {
> + mutex_unlock(>lock);
> + return ret;
> + }
> +
>   ret = kmx61_read_measurement(data, base_reg, chan->scan_index);
>   if (ret < 0) {
>   kmx61_set_power_state(data, false, chan->address);
> @@ -839,9 +844,11 @@ static int kmx61_read_raw(struct iio_dev *indio_dev,
>   }
>   *val = sign_extend32(ret >> chan->scan_type.shift,
>chan->scan_type.realbits - 1);
> - kmx61_set_power_state(data, false, chan->address);
> + ret = kmx61_set_power_state(data, false, chan->address);
>  
>   mutex_unlock(>lock);
> + if (ret)
> + return ret;
>   return IIO_VAL_INT;
>   case IIO_CHAN_INFO_SCALE:
>   switch (chan->type) {
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/10] iio: imu: kmx61: Save odr_bits for later use

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
> Signed-off-by: Daniel Baluta 
Reviewed-by: Hartmut Knaack 
> ---
>  drivers/iio/imu/kmx61.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 972424b..fe0cee7 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -465,6 +465,8 @@ static int kmx61_set_odr(struct kmx61_data *data, int 
> val, int val2, u8 device)
>   if (ret < 0)
>   return ret;
>  
> + data->odr_bits = odr_bits;
> +
>   if (device & KMX61_ACC) {
>   ret = kmx61_set_wake_up_odr(data, val, val2);
>   if (ret)
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 03/10] iio: imu: kmx61: Enhance error handling

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 This fixes parts of kmx61 error handling to make code easier to read and to be
 more consistent with IIO coding conventions:
   * prefer as single point for error handling instead of duplicating code
   for each function
   * directly return a value from a case branch instead of breaking
   * fix error message for writing REG_CTRL1
 
 Also, add separate error paths for 
 kmx61_trigger_setup/iio_triggered_buffer_setup
 calls.
Some issues remain in this one, please see inline. Otherwise looking good.

 
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
  drivers/iio/imu/kmx61.c | 100 
 +---
  1 file changed, 43 insertions(+), 57 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index e9cbd91..4fc4f63 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -656,11 +656,7 @@ static int kmx61_setup_new_data_interrupt(struct 
 kmx61_data *data,
   return ret;
   }
  
 - ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
 - if (ret)
 - return ret;
 -
 - return 0;
 + return kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
  }
  
  static int kmx61_chip_update_thresholds(struct kmx61_data *data)
 @@ -678,12 +674,10 @@ static int kmx61_chip_update_thresholds(struct 
 kmx61_data *data)
   ret = i2c_smbus_write_byte_data(data-client,
   KMX61_REG_WUF_THRESH,
   data-wake_thresh);
 - if (ret  0) {
 + if (ret  0)
   dev_err(data-client-dev, Error writing reg_wuf_thresh\n);
 - return ret;
 - }
  
 - return 0;
 + return ret;
  }
  
  static int kmx61_setup_any_motion_interrupt(struct kmx61_data *data,
 @@ -737,11 +731,7 @@ static int kmx61_setup_any_motion_interrupt(struct 
 kmx61_data *data,
   return ret;
   }
   mode |= KMX61_ACT_STBY_BIT;
 - ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
 - if (ret)
 - return ret;
 -
 - return 0;
 + return kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
  }
  
  /**
 @@ -924,10 +914,10 @@ static int kmx61_read_event(struct iio_dev *indio_dev,
   switch (info) {
   case IIO_EV_INFO_VALUE:
   *val = data-wake_thresh;
 - break;
 + return IIO_VAL_INT;
   case IIO_EV_INFO_PERIOD:
   *val = data-wake_duration;
 - break;
 + return IIO_VAL_INT;
   default:
   return -EINVAL;
   }
Down below this line is still a return IIO_VAL_INT, which is now obsolete.
 @@ -950,10 +940,10 @@ static int kmx61_write_event(struct iio_dev *indio_dev,
   switch (info) {
   case IIO_EV_INFO_VALUE:
   data-wake_thresh = val;
 - break;
 + return IIO_VAL_INT;
   case IIO_EV_INFO_PERIOD:
   data-wake_duration = val;
 - break;
 + return IIO_VAL_INT;
   default:
   return -EINVAL;
   }
Same obsolete return exists below this line.
 @@ -978,7 +968,7 @@ static int kmx61_write_event_config(struct iio_dev 
 *indio_dev,
  int state)
  {
   struct kmx61_data *data = kmx61_get_data(indio_dev);
 - int ret;
 + int ret = 0;
  
   if (state  data-ev_enable_state)
   return 0;
 @@ -987,27 +977,25 @@ static int kmx61_write_event_config(struct iio_dev 
 *indio_dev,
  
   if (!state  data-motion_trig_on) {
   data-ev_enable_state = 0;
 - mutex_unlock(data-lock);
 - return 0;
 + goto err_unlock;
   }
  
   ret = kmx61_set_power_state(data, state, KMX61_ACC);
 - if (ret  0) {
 - mutex_unlock(data-lock);
 - return ret;
 - }
 + if (ret  0)
 + goto err_unlock;
  
   ret = kmx61_setup_any_motion_interrupt(data, state, KMX61_ACC);
   if (ret  0) {
   kmx61_set_power_state(data, false, KMX61_ACC);
 - mutex_unlock(data-lock);
 - return ret;
 + goto err_unlock;
   }
  
   data-ev_enable_state = state;
 +
 +err_unlock:
   mutex_unlock(data-lock);
  
 - return 0;
 + return ret;
  }
  
  static int kmx61_acc_validate_trigger(struct iio_dev *indio_dev,
 @@ -1066,8 +1054,7 @@ static int kmx61_data_rdy_trigger_set_state(struct 
 iio_trigger *trig,
  
   if (!state  data-ev_enable_state  data-motion_trig_on) {
   data-motion_trig_on = false;
 - mutex_unlock(data-lock);
 - return 0;
 + goto err_unlock;
   }
  
  
 @@ -1077,10 +1064,8 @@ static int kmx61_data_rdy_trigger_set_state(struct 
 iio_trigger *trig,
   device = KMX61_MAG;
  
   ret = kmx61_set_power_state(data, state, device);
 - if (ret  0) {
 - 

Re: [PATCH 09/10] iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 odr_bits values are between 0 and 11, so we can use the index
 in kmx61_samp_freq_table instead of odr_bits structure member.
Basically looking good, but I would feel more comfortable to check
against the boundaries of the table. Please see inline.

 
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
  drivers/iio/imu/kmx61.c | 64 
 -
  1 file changed, 26 insertions(+), 38 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index eb3900e..98369eb 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -169,19 +169,18 @@ u16 kmx61_uscale_table[] = {9582, 19163, 38326};
  static const struct {
   int val;
   int val2;
 - u8 odr_bits;
 -} kmx61_samp_freq_table[] = { {12, 50, 0x00},
 - {25, 0, 0x01},
 - {50, 0, 0x02},
 - {100, 0, 0x03},
 - {200, 0, 0x04},
 - {400, 0, 0x05},
 - {800, 0, 0x06},
 - {1600, 0, 0x07},
 - {0, 781000, 0x08},
 - {1, 563000, 0x09},
 - {3, 125000, 0x0A},
 - {6, 25, 0x0B} };
 +} kmx61_samp_freq_table[] = { {12, 50},
 + {25, 0},
 + {50, 0},
 + {100, 0},
 + {200, 0},
 + {400, 0},
 + {800, 0},
 + {1600, 0},
 + {0, 781000},
 + {1, 563000},
 + {3, 125000},
 + {6, 25} };
  
  static const struct {
   int val;
 @@ -302,24 +301,10 @@ static int kmx61_convert_freq_to_bit(int val, int val2)
   for (i = 0; i  ARRAY_SIZE(kmx61_samp_freq_table); i++)
   if (val == kmx61_samp_freq_table[i].val 
   val2 == kmx61_samp_freq_table[i].val2)
 - return kmx61_samp_freq_table[i].odr_bits;
 - return -EINVAL;
 -}
 -
 -static int kmx61_convert_bit_to_freq(u8 odr_bits, int *val, int *val2)
 -{
 - int i;
 -
 - for (i = 0; i  ARRAY_SIZE(kmx61_samp_freq_table); i++)
 - if (odr_bits == kmx61_samp_freq_table[i].odr_bits) {
 - *val = kmx61_samp_freq_table[i].val;
 - *val2 = kmx61_samp_freq_table[i].val2;
 - return 0;
 - }
 + return i;
   return -EINVAL;
  }
  
 -
  static int kmx61_convert_wake_up_odr_to_bit(int val, int val2)
  {
   int i;
 @@ -478,7 +463,7 @@ static int kmx61_set_odr(struct kmx61_data *data, int 
 val, int val2, u8 device)
  
  static int kmx61_get_odr(struct kmx61_data *data, int *val, int *val2,
u8 device)
 -{int i;
 +{
   u8 lodr_bits;
  
   if (device  KMX61_ACC)
 @@ -490,13 +475,13 @@ static int kmx61_get_odr(struct kmx61_data *data, int 
 *val, int *val2,
   else
   return -EINVAL;
  
 - for (i = 0; i  ARRAY_SIZE(kmx61_samp_freq_table); i++)
 - if (lodr_bits == kmx61_samp_freq_table[i].odr_bits) {
 - *val = kmx61_samp_freq_table[i].val;
 - *val2 = kmx61_samp_freq_table[i].val2;
 - return 0;
 - }
 - return -EINVAL;
 + if (lodr_bits  0xB)
Since we use it as an index, I regard it safer to check against
ARRAY_SIZE(kmx61_samp_freq_table) rather than a fix value.

 + return -EINVAL;
 +
 + *val = kmx61_samp_freq_table[lodr_bits].val;
 + *val2 = kmx61_samp_freq_table[lodr_bits].val2;
 +
 + return 0;
  }
  
  static int kmx61_set_range(struct kmx61_data *data, u8 range)
 @@ -580,8 +565,11 @@ static int kmx61_chip_init(struct kmx61_data *data)
   }
   data-odr_bits = ret;
  
 - /* set output data rate for wake up (motion detection) function */
 - ret = kmx61_convert_bit_to_freq(data-odr_bits, val, val2);
 + /*
 +  * set output data rate for wake up (motion detection) function
 +  * to match data rate for accelerometer sampling
 +  */
 + ret = kmx61_get_odr(data, val, val2, KMX61_ACC);
   if (ret  0)
   return ret;
  
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 02/10] iio: imu: kmx61: Don't ignore kmx61_set_power_state errors

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 ..except while in an error handler, where there is nothing
 to be done anyway.
 
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Reviewed-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/imu/kmx61.c | 11 +--
  1 file changed, 9 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index fe0cee7..e9cbd91 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -830,7 +830,12 @@ static int kmx61_read_raw(struct iio_dev *indio_dev,
   }
   mutex_lock(data-lock);
  
 - kmx61_set_power_state(data, true, chan-address);
 + ret = kmx61_set_power_state(data, true, chan-address);
 + if (ret) {
 + mutex_unlock(data-lock);
 + return ret;
 + }
 +
   ret = kmx61_read_measurement(data, base_reg, chan-scan_index);
   if (ret  0) {
   kmx61_set_power_state(data, false, chan-address);
 @@ -839,9 +844,11 @@ static int kmx61_read_raw(struct iio_dev *indio_dev,
   }
   *val = sign_extend32(ret  chan-scan_type.shift,
chan-scan_type.realbits - 1);
 - kmx61_set_power_state(data, false, chan-address);
 + ret = kmx61_set_power_state(data, false, chan-address);
  
   mutex_unlock(data-lock);
 + if (ret)
 + return ret;
   return IIO_VAL_INT;
   case IIO_CHAN_INFO_SCALE:
   switch (chan-type) {
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/10] iio: imu: kmx61: Drop unused device parameter

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Reviewed-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/imu/kmx61.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index 2652179..332ee67 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -681,7 +681,7 @@ static int kmx61_chip_update_thresholds(struct kmx61_data 
 *data)
  }
  
  static int kmx61_setup_any_motion_interrupt(struct kmx61_data *data,
 - bool status, u8 device)
 + bool status)
  {
   u8 mode;
   int ret;
 @@ -984,7 +984,7 @@ static int kmx61_write_event_config(struct iio_dev 
 *indio_dev,
   if (ret  0)
   goto err_unlock;
  
 - ret = kmx61_setup_any_motion_interrupt(data, state, KMX61_ACC);
 + ret = kmx61_setup_any_motion_interrupt(data, state);
   if (ret  0) {
   kmx61_set_power_state(data, false, KMX61_ACC);
   goto err_unlock;
 @@ -1070,7 +1070,7 @@ static int kmx61_data_rdy_trigger_set_state(struct 
 iio_trigger *trig,
   if (data-acc_dready_trig == trig || data-mag_dready_trig == trig)
   ret = kmx61_setup_new_data_interrupt(data, state, device);
   else
 - ret = kmx61_setup_any_motion_interrupt(data, state, KMX61_ACC);
 + ret = kmx61_setup_any_motion_interrupt(data, state);
   if (ret  0) {
   kmx61_set_power_state(data, false, device);
   goto err_unlock;
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 04/10] iio: imu: kmx61: Fixup parameters alignment

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Acked-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/imu/kmx61.c | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index 4fc4f63..2652179 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -926,11 +926,11 @@ static int kmx61_read_event(struct iio_dev *indio_dev,
  }
  
  static int kmx61_write_event(struct iio_dev *indio_dev,
 - const struct iio_chan_spec *chan,
 - enum iio_event_type type,
 - enum iio_event_direction dir,
 - enum iio_event_info info,
 - int val, int val2)
 +  const struct iio_chan_spec *chan,
 +  enum iio_event_type type,
 +  enum iio_event_direction dir,
 +  enum iio_event_info info,
 +  int val, int val2)
  {
   struct kmx61_data *data = kmx61_get_data(indio_dev);
  
 @@ -962,10 +962,10 @@ static int kmx61_read_event_config(struct iio_dev 
 *indio_dev,
  }
  
  static int kmx61_write_event_config(struct iio_dev *indio_dev,
 -const struct iio_chan_spec *chan,
 -enum iio_event_type type,
 -enum iio_event_direction dir,
 -int state)
 + const struct iio_chan_spec *chan,
 + enum iio_event_type type,
 + enum iio_event_direction dir,
 + int state)
  {
   struct kmx61_data *data = kmx61_get_data(indio_dev);
   int ret = 0;
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 07/10] iio: imu: kmx61: Fix device initialization when setting trigger state

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Acked-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/imu/kmx61.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index 30825cf..5b5be2b 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -1057,8 +1057,7 @@ static int kmx61_data_rdy_trigger_set_state(struct 
 iio_trigger *trig,
   goto err_unlock;
   }
  
 -
 - if (data-acc_dready_trig == trig || data-motion_trig)
 + if (data-acc_dready_trig == trig || data-motion_trig == trig)
   device = KMX61_ACC;
   else
   device = KMX61_MAG;
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 08/10] iio: imu: kmx61: Remove unnecessary REG_INS1 read

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 Useful in the debugging phase, not needed now.
 
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Acked-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/imu/kmx61.c | 2 --
  1 file changed, 2 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index 5b5be2b..eb3900e 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -1196,8 +1196,6 @@ ack_intr:
   if (ret  0)
   dev_err(data-client-dev, Error reading reg_inl\n);
  
 - ret = i2c_smbus_read_byte_data(data-client, KMX61_REG_INS1);
 -
   return IRQ_HANDLED;
  }
  
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 06/10] iio: imu: kmx61: Use false instead of 0 for ev_enable_state

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Acked-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/imu/kmx61.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index 332ee67..30825cf 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -976,7 +976,7 @@ static int kmx61_write_event_config(struct iio_dev 
 *indio_dev,
   mutex_lock(data-lock);
  
   if (!state  data-motion_trig_on) {
 - data-ev_enable_state = 0;
 + data-ev_enable_state = false;
   goto err_unlock;
   }
  
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 01/10] iio: imu: kmx61: Save odr_bits for later use

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Reviewed-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/imu/kmx61.c | 2 ++
  1 file changed, 2 insertions(+)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index 972424b..fe0cee7 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -465,6 +465,8 @@ static int kmx61_set_odr(struct kmx61_data *data, int 
 val, int val2, u8 device)
   if (ret  0)
   return ret;
  
 + data-odr_bits = odr_bits;
 +
   if (device  KMX61_ACC) {
   ret = kmx61_set_wake_up_odr(data, val, val2);
   if (ret)
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/10] iio: imu: kmx61: Use correct base when reading data

[Hartmut Knaack]

Daniel Baluta schrieb am 23.12.2014 um 14:22:
 We have two IIO devices and we need to adjust the base
 when reading data.
 
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
Reviewed-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/imu/kmx61.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index 98369eb..6178cea 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -1210,12 +1210,18 @@ static irqreturn_t kmx61_trigger_handler(int irq, 
 void *p)
   struct iio_dev *indio_dev = pf-indio_dev;
   struct kmx61_data *data = kmx61_get_data(indio_dev);
   int bit, ret, i = 0;
 + u8 base;
   s16 buffer[8];
  
 + if (indio_dev == data-acc_indio_dev)
 + base = KMX61_ACC_XOUT_L;
 + else
 + base = KMX61_MAG_XOUT_L;
 +
   mutex_lock(data-lock);
   for_each_set_bit(bit, indio_dev-buffer-scan_mask,
indio_dev-masklength) {
 - ret = kmx61_read_measurement(data, KMX61_ACC_XOUT_L, bit);
 + ret = kmx61_read_measurement(data, base, bit);
   if (ret  0) {
   mutex_unlock(data-lock);
   goto err;
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 3/7] iio: Add support for DA9150 GPADC

[Hartmut Knaack]

Adam Thomson schrieb am 22.12.2014 um 17:51:
 This patch adds support for DA9150 Charger  Fuel-Gauge IC GPADC.
 
 Signed-off-by: Adam Thomson adam.thomson.opensou...@diasemi.com
Reviewed-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/adc/Kconfig|   9 +
  drivers/iio/adc/Makefile   |   1 +
  drivers/iio/adc/da9150-gpadc.c | 409 
 +
  3 files changed, 419 insertions(+)
  create mode 100644 drivers/iio/adc/da9150-gpadc.c
 
 diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
 index 0f79e47..6e00b81 100644
 --- a/drivers/iio/adc/Kconfig
 +++ b/drivers/iio/adc/Kconfig
 @@ -135,6 +135,15 @@ config AXP288_ADC
 device. Depending on platform configuration, this general purpose ADC 
 can
 be used for sampling sensors such as thermal resistors.
 
 +config DA9150_GPADC
 + tristate Dialog DA9150 GPADC driver support
 + depends on MFD_DA9150
 + help
 +   Say yes here to build support for Dialog DA9150 GPADC.
 +
 +   This driver can also be built as a module. If chosen, the module name
 +   will be da9150-gpadc.
 +
  config EXYNOS_ADC
   tristate Exynos ADC driver support
   depends on ARCH_EXYNOS || ARCH_S3C24XX || ARCH_S3C64XX || (OF  
 COMPILE_TEST)
 diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
 index 701fdb7..d56ee9b 100644
 --- a/drivers/iio/adc/Makefile
 +++ b/drivers/iio/adc/Makefile
 @@ -15,6 +15,7 @@ obj-$(CONFIG_AD7887) += ad7887.o
  obj-$(CONFIG_AD799X) += ad799x.o
  obj-$(CONFIG_AT91_ADC) += at91_adc.o
  obj-$(CONFIG_AXP288_ADC) += axp288_adc.o
 +obj-$(CONFIG_DA9150_GPADC) += da9150-gpadc.o
  obj-$(CONFIG_EXYNOS_ADC) += exynos_adc.o
  obj-$(CONFIG_LP8788_ADC) += lp8788_adc.o
  obj-$(CONFIG_MAX1027) += max1027.o
 diff --git a/drivers/iio/adc/da9150-gpadc.c b/drivers/iio/adc/da9150-gpadc.c
 new file mode 100644
 index 000..3f7bc81
 --- /dev/null
 +++ b/drivers/iio/adc/da9150-gpadc.c
 @@ -0,0 +1,409 @@
 +/*
 + * DA9150 GPADC Driver
 + *
 + * Copyright (c) 2014 Dialog Semiconductor
 + *
 + * Author: Adam Thomson adam.thomson.opensou...@diasemi.com
 + *
 + * This program is free software; you can redistribute  it and/or modify it
 + * under  the terms of  the GNU General  Public License as published by the
 + * Free Software Foundation;  either version 2 of the  License, or (at your
 + * option) any later version.
 + */
 +
 +#include linux/kernel.h
 +#include linux/slab.h
 +#include linux/module.h
 +#include linux/platform_device.h
 +#include linux/interrupt.h
 +#include linux/mutex.h
 +#include linux/completion.h
 +#include linux/iio/iio.h
 +#include linux/iio/machine.h
 +#include linux/iio/driver.h
 +#include linux/mfd/da9150/core.h
 +#include linux/mfd/da9150/registers.h
 +
 +/* Channels */
 +enum da9150_gpadc_hw_channel {
 + DA9150_GPADC_HW_CHAN_GPIOA_2V = 0,
 + DA9150_GPADC_HW_CHAN_GPIOA_2V_,
 + DA9150_GPADC_HW_CHAN_GPIOB_2V,
 + DA9150_GPADC_HW_CHAN_GPIOB_2V_,
 + DA9150_GPADC_HW_CHAN_GPIOC_2V,
 + DA9150_GPADC_HW_CHAN_GPIOC_2V_,
 + DA9150_GPADC_HW_CHAN_GPIOD_2V,
 + DA9150_GPADC_HW_CHAN_GPIOD_2V_,
 + DA9150_GPADC_HW_CHAN_IBUS_SENSE,
 + DA9150_GPADC_HW_CHAN_IBUS_SENSE_,
 + DA9150_GPADC_HW_CHAN_VBUS_DIV,
 + DA9150_GPADC_HW_CHAN_VBUS_DIV_,
 + DA9150_GPADC_HW_CHAN_ID,
 + DA9150_GPADC_HW_CHAN_ID_,
 + DA9150_GPADC_HW_CHAN_VSYS,
 + DA9150_GPADC_HW_CHAN_VSYS_,
 + DA9150_GPADC_HW_CHAN_GPIOA_6V,
 + DA9150_GPADC_HW_CHAN_GPIOA_6V_,
 + DA9150_GPADC_HW_CHAN_GPIOB_6V,
 + DA9150_GPADC_HW_CHAN_GPIOB_6V_,
 + DA9150_GPADC_HW_CHAN_GPIOC_6V,
 + DA9150_GPADC_HW_CHAN_GPIOC_6V_,
 + DA9150_GPADC_HW_CHAN_GPIOD_6V,
 + DA9150_GPADC_HW_CHAN_GPIOD_6V_,
 + DA9150_GPADC_HW_CHAN_VBAT,
 + DA9150_GPADC_HW_CHAN_VBAT_,
 + DA9150_GPADC_HW_CHAN_TBAT,
 + DA9150_GPADC_HW_CHAN_TBAT_,
 + DA9150_GPADC_HW_CHAN_TJUNC_CORE,
 + DA9150_GPADC_HW_CHAN_TJUNC_CORE_,
 + DA9150_GPADC_HW_CHAN_TJUNC_OVP,
 + DA9150_GPADC_HW_CHAN_TJUNC_OVP_,
 +};
 +
 +enum da9150_gpadc_channel {
 + DA9150_GPADC_CHAN_GPIOA = 0,
 + DA9150_GPADC_CHAN_GPIOB,
 + DA9150_GPADC_CHAN_GPIOC,
 + DA9150_GPADC_CHAN_GPIOD,
 + DA9150_GPADC_CHAN_IBUS,
 + DA9150_GPADC_CHAN_VBUS,
 + DA9150_GPADC_CHAN_ID,
 + DA9150_GPADC_CHAN_VSYS,
 + DA9150_GPADC_CHAN_VBAT,
 + DA9150_GPADC_CHAN_TBAT,
 + DA9150_GPADC_CHAN_TJUNC_CORE,
 + DA9150_GPADC_CHAN_TJUNC_OVP,
 +};
 +
 +/* Private data */
 +struct da9150_gpadc {
 + struct da9150 *da9150;
 + struct device *dev;
 +
 + struct mutex lock;
 + struct completion complete;
 +};
 +
 +
 +static irqreturn_t da9150_gpadc_irq(int irq, void *data)
 +{
 +
 + struct da9150_gpadc *gpadc = data;
 +
 + complete(gpadc-complete);
 +
 + return IRQ_HANDLED;
 +}
 +
 +static int da9150_gpadc_read_adc(struct da9150_gpadc *gpadc, int hw_chan)
 +{
 + u8 result_regs[2];
 + int result;
 +
 + mutex_lock(gpadc-lock);
 +
 + /* Set channel

Re: [PATCH v3 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Jonathan Cameron schrieb am 26.12.2014 um 12:51:
> On 15/12/14 11:39, Nikolaus Schulz wrote:
>> The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
>> interface.
>>
>> Changes in v3:
>> * Small fixes in the documentation of struct dac8554_state
>> * Replace some magic constants with macros
>> * Replace memset on powerdown state arrays with explicit loop
>> * If probing fails due to invalid DT data, return -EINVAL instead of
>>   -ENODEV
>> * Add driver dependency on regulator support
>> * Move regulator_get_voltage call from probe time to dac8554_read_raw
>> * Rename _(read|write)_raw argument "mask" to "info"
>> * Make iio_chan_spec variable static
>> * DT: add vendor prefix to device specific "address" property
>> * Whitespace fixes
>>
>> Changes in v2:
>> * Use DMA-safe buffer for SPI transfer
>> * Normalize powerdown_mode name "hi-z" to "three_state" as per
>>   ABI/testing/sysfs-bus-iio
>> * Register device late in probe function
>> * Avoid powerdown broadcast update, which touches all DAC on the bus
>>
>> Signed-off-by: Nikolaus Schulz 
> A slightly inconsistency inline (you only allow for chip addresses up
> to 2 rather than 3)
> 
> Otherwise, looks good - though we'll want Mark to say if he is fine with
> the addressing bit of the device tree file and you to drop the line at
> the top as asked for.
> 
> Thanks,
> 
> Jonathan
>> ---
>>  drivers/iio/dac/Kconfig  |  11 ++
>>  drivers/iio/dac/Makefile |   1 +
>>  drivers/iio/dac/ti-dac8554.c | 381 
>> +++
>>  3 files changed, 393 insertions(+)
>>  create mode 100644 drivers/iio/dac/ti-dac8554.c
>>
>> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
>> index 2236ea2..d3b21c853b5 100644
>> --- a/drivers/iio/dac/Kconfig
>> +++ b/drivers/iio/dac/Kconfig
>> @@ -181,4 +181,15 @@ config MCP4922
>>To compile this driver as a module, choose M here: the module
>>will be called mcp4922.
>>  
>> +config TI_DAC8554
>> +tristate "TI DAC8554 driver"
>> +depends on SPI
>> +depends on OF
>> +depends on REGULATOR
>> +help
>> +  Say yes here to build the driver for the TI DAC8554.
>> +
>> +  To compile this driver as a module, choose M here: the module
>> +  will be called ti-dac8554.
>> +
>>  endmenu
>> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
>> index 52be7e1..b98d79a 100644
>> --- a/drivers/iio/dac/Makefile
>> +++ b/drivers/iio/dac/Makefile
>> @@ -20,3 +20,4 @@ obj-$(CONFIG_MAX517) += max517.o
>>  obj-$(CONFIG_MAX5821) += max5821.o
>>  obj-$(CONFIG_MCP4725) += mcp4725.o
>>  obj-$(CONFIG_MCP4922) += mcp4922.o
>> +obj-$(CONFIG_TI_DAC8554) += ti-dac8554.o
>> diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
>> new file mode 100644
>> index 000..84b9f42
>> --- /dev/null
>> +++ b/drivers/iio/dac/ti-dac8554.c
>> @@ -0,0 +1,381 @@
>> +/*
>> + * TI DAC8554 Digital to Analog Converter SPI driver
>> + *
>> + * Copyright (C) 2014 Avionic Design GmbH
>> + *
>> + * Based on ad5446r_spi.c
>> + * Copyright (C) 2010,2011 Analog Devices Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#define DAC8554_DRIVERNAME  "ti-dac8554"
>> +#define DAC8554_DAC_CHANNELS4
>> +#define DAC8554_DATABITS16
>> +
>> +/* Load commands */
>> +#define DAC8554_CMD_STORE_DAC_N 0x0
>> +#define DAC8554_CMD_UPDATE_DAC_N0x1
>> +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL  0x2
>> +#define DAC8554_CMD_UPDATE_BROADCAST0x3
>> +
>> +#define DAC8554_BROADCAST_USE_SRDATA0x2
>> +
>> +/* Powerdown modes (PD1 | PD2 bits) */
>> +#define DAC8554_PWRDN_HIZ   0x0
>> +#define DAC8554_PWRDN_1K0x1
>> +#define DAC8554_PWRDN_100K  0x2
>> +
>> +/* Input shift register composition */
>> +#define DAC8554_ADDR_TO_SR(addr)((addr) << 22)
>> +#define DAC8554_CMD_TO_SR(cmd)  ((cmd) << 20)
>> +#define DAC8554_CHAN_TO_SR(chan)((chan) << 17)
>> +#define DAC8554_PWRDN_TO_SR(mode)   (BIT(16) | (mode) << 14)
>> +
>> +/**
>> + * struct dac8554_state - driver instance specific data
>> + * @spi:SPI device
>> + * @reg:supply regulator
>> + * @addr:   two-bit chip address
>> + * @val:channel data
>> + * @powerdown:  channel powerdown flag
>> + * @powerdown_mode: channel powerdown mode
>> + * @xfer:   SPI transfer buffer
>> + */
>> +struct dac8554_state {
>> +struct spi_device   *spi;
>> +struct regulator*reg;
>> +unsignedaddr;
>> +u16 

Re: [PATCH v3 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Jonathan Cameron schrieb am 26.12.2014 um 12:51:
 On 15/12/14 11:39, Nikolaus Schulz wrote:
 The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
 interface.

 Changes in v3:
 * Small fixes in the documentation of struct dac8554_state
 * Replace some magic constants with macros
 * Replace memset on powerdown state arrays with explicit loop
 * If probing fails due to invalid DT data, return -EINVAL instead of
   -ENODEV
 * Add driver dependency on regulator support
 * Move regulator_get_voltage call from probe time to dac8554_read_raw
 * Rename _(read|write)_raw argument mask to info
 * Make iio_chan_spec variable static
 * DT: add vendor prefix to device specific address property
 * Whitespace fixes

 Changes in v2:
 * Use DMA-safe buffer for SPI transfer
 * Normalize powerdown_mode name hi-z to three_state as per
   ABI/testing/sysfs-bus-iio
 * Register device late in probe function
 * Avoid powerdown broadcast update, which touches all DAC on the bus

 Signed-off-by: Nikolaus Schulz nikolaus.sch...@avionic-design.de
 A slightly inconsistency inline (you only allow for chip addresses up
 to 2 rather than 3)
 
 Otherwise, looks good - though we'll want Mark to say if he is fine with
 the addressing bit of the device tree file and you to drop the line at
 the top as asked for.
 
 Thanks,
 
 Jonathan
 ---
  drivers/iio/dac/Kconfig  |  11 ++
  drivers/iio/dac/Makefile |   1 +
  drivers/iio/dac/ti-dac8554.c | 381 
 +++
  3 files changed, 393 insertions(+)
  create mode 100644 drivers/iio/dac/ti-dac8554.c

 diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
 index 2236ea2..d3b21c853b5 100644
 --- a/drivers/iio/dac/Kconfig
 +++ b/drivers/iio/dac/Kconfig
 @@ -181,4 +181,15 @@ config MCP4922
To compile this driver as a module, choose M here: the module
will be called mcp4922.
  
 +config TI_DAC8554
 +tristate TI DAC8554 driver
 +depends on SPI
 +depends on OF
 +depends on REGULATOR
 +help
 +  Say yes here to build the driver for the TI DAC8554.
 +
 +  To compile this driver as a module, choose M here: the module
 +  will be called ti-dac8554.
 +
  endmenu
 diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
 index 52be7e1..b98d79a 100644
 --- a/drivers/iio/dac/Makefile
 +++ b/drivers/iio/dac/Makefile
 @@ -20,3 +20,4 @@ obj-$(CONFIG_MAX517) += max517.o
  obj-$(CONFIG_MAX5821) += max5821.o
  obj-$(CONFIG_MCP4725) += mcp4725.o
  obj-$(CONFIG_MCP4922) += mcp4922.o
 +obj-$(CONFIG_TI_DAC8554) += ti-dac8554.o
 diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
 new file mode 100644
 index 000..84b9f42
 --- /dev/null
 +++ b/drivers/iio/dac/ti-dac8554.c
 @@ -0,0 +1,381 @@
 +/*
 + * TI DAC8554 Digital to Analog Converter SPI driver
 + *
 + * Copyright (C) 2014 Avionic Design GmbH
 + *
 + * Based on ad5446r_spi.c
 + * Copyright (C) 2010,2011 Analog Devices Inc.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/spi/spi.h
 +#include linux/regulator/consumer.h
 +#include linux/module.h
 +#include linux/iio/iio.h
 +#include linux/of.h
 +
 +#define DAC8554_DRIVERNAME  ti-dac8554
 +#define DAC8554_DAC_CHANNELS4
 +#define DAC8554_DATABITS16
 +
 +/* Load commands */
 +#define DAC8554_CMD_STORE_DAC_N 0x0
 +#define DAC8554_CMD_UPDATE_DAC_N0x1
 +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL  0x2
 +#define DAC8554_CMD_UPDATE_BROADCAST0x3
 +
 +#define DAC8554_BROADCAST_USE_SRDATA0x2
 +
 +/* Powerdown modes (PD1 | PD2 bits) */
 +#define DAC8554_PWRDN_HIZ   0x0
 +#define DAC8554_PWRDN_1K0x1
 +#define DAC8554_PWRDN_100K  0x2
 +
 +/* Input shift register composition */
 +#define DAC8554_ADDR_TO_SR(addr)((addr)  22)
 +#define DAC8554_CMD_TO_SR(cmd)  ((cmd)  20)
 +#define DAC8554_CHAN_TO_SR(chan)((chan)  17)
 +#define DAC8554_PWRDN_TO_SR(mode)   (BIT(16) | (mode)  14)
 +
 +/**
 + * struct dac8554_state - driver instance specific data
 + * @spi:SPI device
 + * @reg:supply regulator
 + * @addr:   two-bit chip address
 + * @val:channel data
 + * @powerdown:  channel powerdown flag
 + * @powerdown_mode: channel powerdown mode
 + * @xfer:   SPI transfer buffer
 + */
 +struct dac8554_state {
 +struct spi_device   *spi;
 +struct regulator*reg;
 +unsignedaddr;
 +u16 val[DAC8554_DAC_CHANNELS];
 +boolpowerdown[DAC8554_DAC_CHANNELS];
 +u8  powerdown_mode[DAC8554_DAC_CHANNELS];
 

Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized

[Hartmut Knaack]

Daniel Baluta schrieb am 18.12.2014 um 18:16:
> When using ACPI, if acpi_match_device fails then chipset enum will be
> uninitialized and _def_array[chipset] will point to some bad address.
> 
> This fixes the following compilation warning:
> 
> drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’:
> drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used
> uninitialized in this function [-Wmaybe-uninitialized]
>   data->def =ak_def_array[chipset];
> 
> Reported-by: Octavian Purdila 
> Signed-off-by: Daniel Baluta 
> ---
> This is a RFC because while I'm pretty sure that chipset should be initialized
> with AK_MAX_TYPE in ak8975_match_acpi_device, I am not sure if we can live 
> with
> a NULL return value of ak8975_match_acpi_device. Current implementation 
> ignores
> return value of ak8975_match_acpi_device.
This seems to be the actual problem: these _match_acpi_device functions return
NULL on failure, and this should be checked for.

> 
> The same situation is for kxcjk-1013, bmc150-accel, bmg160 and possible other
> drivers.
> 
>  drivers/iio/magnetometer/ak8975.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/iio/magnetometer/ak8975.c 
> b/drivers/iio/magnetometer/ak8975.c
> index 0d10a4b..cdf9e77 100644
> --- a/drivers/iio/magnetometer/ak8975.c
> +++ b/drivers/iio/magnetometer/ak8975.c
> @@ -716,6 +716,7 @@ static const char *ak8975_match_acpi_device(struct device 
> *dev,
>  {
>   const struct acpi_device_id *id;
>  
> + *chipset =K_MAX_TYPE;
>   id =cpi_match_device(dev->driver->acpi_match_table, dev);
>   if (!id)
>   return NULL;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized

[Hartmut Knaack]

Daniel Baluta schrieb am 18.12.2014 um 18:16:
 When using ACPI, if acpi_match_device fails then chipset enum will be
 uninitialized and ak_def_array[chipset] will point to some bad address.
 
 This fixes the following compilation warning:
 
 drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’:
 drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used
 uninitialized in this function [-Wmaybe-uninitialized]
   data-def =ak_def_array[chipset];
 
 Reported-by: Octavian Purdila octavian.purd...@intel.com
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
 This is a RFC because while I'm pretty sure that chipset should be initialized
 with AK_MAX_TYPE in ak8975_match_acpi_device, I am not sure if we can live 
 with
 a NULL return value of ak8975_match_acpi_device. Current implementation 
 ignores
 return value of ak8975_match_acpi_device.
This seems to be the actual problem: these _match_acpi_device functions return
NULL on failure, and this should be checked for.

 
 The same situation is for kxcjk-1013, bmc150-accel, bmg160 and possible other
 drivers.
 
  drivers/iio/magnetometer/ak8975.c | 1 +
  1 file changed, 1 insertion(+)
 
 diff --git a/drivers/iio/magnetometer/ak8975.c 
 b/drivers/iio/magnetometer/ak8975.c
 index 0d10a4b..cdf9e77 100644
 --- a/drivers/iio/magnetometer/ak8975.c
 +++ b/drivers/iio/magnetometer/ak8975.c
 @@ -716,6 +716,7 @@ static const char *ak8975_match_acpi_device(struct device 
 *dev,
  {
   const struct acpi_device_id *id;
  
 + *chipset =K_MAX_TYPE;
   id =cpi_match_device(dev-driver-acpi_match_table, dev);
   if (!id)
   return NULL;
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Nikolaus Schulz schrieb am 15.12.2014 um 12:39:
> The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
> interface.
> 
> Changes in v3:
> * Small fixes in the documentation of struct dac8554_state
> * Replace some magic constants with macros
> * Replace memset on powerdown state arrays with explicit loop
> * If probing fails due to invalid DT data, return -EINVAL instead of
>   -ENODEV
> * Add driver dependency on regulator support
> * Move regulator_get_voltage call from probe time to dac8554_read_raw
> * Rename _(read|write)_raw argument "mask" to "info"
> * Make iio_chan_spec variable static
> * DT: add vendor prefix to device specific "address" property
> * Whitespace fixes
> 
> Changes in v2:
> * Use DMA-safe buffer for SPI transfer
> * Normalize powerdown_mode name "hi-z" to "three_state" as per
>   ABI/testing/sysfs-bus-iio
> * Register device late in probe function
> * Avoid powerdown broadcast update, which touches all DAC on the bus
> 
> Signed-off-by: Nikolaus Schulz 
Reviewed-by: Hartmut Knaack 
> ---
>  drivers/iio/dac/Kconfig  |  11 ++
>  drivers/iio/dac/Makefile |   1 +
>  drivers/iio/dac/ti-dac8554.c | 381 
> +++
>  3 files changed, 393 insertions(+)
>  create mode 100644 drivers/iio/dac/ti-dac8554.c
> 
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index 2236ea2..d3b21c853b5 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -181,4 +181,15 @@ config MCP4922
> To compile this driver as a module, choose M here: the module
> will be called mcp4922.
>  
> +config TI_DAC8554
> + tristate "TI DAC8554 driver"
> + depends on SPI
> + depends on OF
> + depends on REGULATOR
> + help
> +   Say yes here to build the driver for the TI DAC8554.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called ti-dac8554.
> +
>  endmenu
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 52be7e1..b98d79a 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -20,3 +20,4 @@ obj-$(CONFIG_MAX517) += max517.o
>  obj-$(CONFIG_MAX5821) += max5821.o
>  obj-$(CONFIG_MCP4725) += mcp4725.o
>  obj-$(CONFIG_MCP4922) += mcp4922.o
> +obj-$(CONFIG_TI_DAC8554) += ti-dac8554.o
> diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
> new file mode 100644
> index 000..84b9f42
> --- /dev/null
> +++ b/drivers/iio/dac/ti-dac8554.c
> @@ -0,0 +1,381 @@
> +/*
> + * TI DAC8554 Digital to Analog Converter SPI driver
> + *
> + * Copyright (C) 2014 Avionic Design GmbH
> + *
> + * Based on ad5446r_spi.c
> + * Copyright (C) 2010,2011 Analog Devices Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DAC8554_DRIVERNAME   "ti-dac8554"
> +#define DAC8554_DAC_CHANNELS 4
> +#define DAC8554_DATABITS 16
> +
> +/* Load commands */
> +#define DAC8554_CMD_STORE_DAC_N  0x0
> +#define DAC8554_CMD_UPDATE_DAC_N 0x1
> +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL   0x2
> +#define DAC8554_CMD_UPDATE_BROADCAST 0x3
> +
> +#define DAC8554_BROADCAST_USE_SRDATA 0x2
> +
> +/* Powerdown modes (PD1 | PD2 bits) */
> +#define DAC8554_PWRDN_HIZ0x0
> +#define DAC8554_PWRDN_1K 0x1
> +#define DAC8554_PWRDN_100K   0x2
> +
> +/* Input shift register composition */
> +#define DAC8554_ADDR_TO_SR(addr) ((addr) << 22)
> +#define DAC8554_CMD_TO_SR(cmd)   ((cmd) << 20)
> +#define DAC8554_CHAN_TO_SR(chan) ((chan) << 17)
> +#define DAC8554_PWRDN_TO_SR(mode)(BIT(16) | (mode) << 14)
> +
> +/**
> + * struct dac8554_state - driver instance specific data
> + * @spi: SPI device
> + * @reg: supply regulator
> + * @addr:two-bit chip address
> + * @val: channel data
> + * @powerdown:   channel powerdown flag
> + * @powerdown_mode:  channel powerdown mode
> + * @xfer:SPI transfer buffer
> + */
> +struct dac8554_state {
> + struct spi_device   *spi;
> + struct regulator*reg;
> + unsignedaddr;
&

Re: [PATCH v3 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Nikolaus Schulz schrieb am 15.12.2014 um 12:39:
 The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
 interface.
 
 Changes in v3:
 * Small fixes in the documentation of struct dac8554_state
 * Replace some magic constants with macros
 * Replace memset on powerdown state arrays with explicit loop
 * If probing fails due to invalid DT data, return -EINVAL instead of
   -ENODEV
 * Add driver dependency on regulator support
 * Move regulator_get_voltage call from probe time to dac8554_read_raw
 * Rename _(read|write)_raw argument mask to info
 * Make iio_chan_spec variable static
 * DT: add vendor prefix to device specific address property
 * Whitespace fixes
 
 Changes in v2:
 * Use DMA-safe buffer for SPI transfer
 * Normalize powerdown_mode name hi-z to three_state as per
   ABI/testing/sysfs-bus-iio
 * Register device late in probe function
 * Avoid powerdown broadcast update, which touches all DAC on the bus
 
 Signed-off-by: Nikolaus Schulz nikolaus.sch...@avionic-design.de
Reviewed-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/dac/Kconfig  |  11 ++
  drivers/iio/dac/Makefile |   1 +
  drivers/iio/dac/ti-dac8554.c | 381 
 +++
  3 files changed, 393 insertions(+)
  create mode 100644 drivers/iio/dac/ti-dac8554.c
 
 diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
 index 2236ea2..d3b21c853b5 100644
 --- a/drivers/iio/dac/Kconfig
 +++ b/drivers/iio/dac/Kconfig
 @@ -181,4 +181,15 @@ config MCP4922
 To compile this driver as a module, choose M here: the module
 will be called mcp4922.
  
 +config TI_DAC8554
 + tristate TI DAC8554 driver
 + depends on SPI
 + depends on OF
 + depends on REGULATOR
 + help
 +   Say yes here to build the driver for the TI DAC8554.
 +
 +   To compile this driver as a module, choose M here: the module
 +   will be called ti-dac8554.
 +
  endmenu
 diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
 index 52be7e1..b98d79a 100644
 --- a/drivers/iio/dac/Makefile
 +++ b/drivers/iio/dac/Makefile
 @@ -20,3 +20,4 @@ obj-$(CONFIG_MAX517) += max517.o
  obj-$(CONFIG_MAX5821) += max5821.o
  obj-$(CONFIG_MCP4725) += mcp4725.o
  obj-$(CONFIG_MCP4922) += mcp4922.o
 +obj-$(CONFIG_TI_DAC8554) += ti-dac8554.o
 diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
 new file mode 100644
 index 000..84b9f42
 --- /dev/null
 +++ b/drivers/iio/dac/ti-dac8554.c
 @@ -0,0 +1,381 @@
 +/*
 + * TI DAC8554 Digital to Analog Converter SPI driver
 + *
 + * Copyright (C) 2014 Avionic Design GmbH
 + *
 + * Based on ad5446r_spi.c
 + * Copyright (C) 2010,2011 Analog Devices Inc.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/spi/spi.h
 +#include linux/regulator/consumer.h
 +#include linux/module.h
 +#include linux/iio/iio.h
 +#include linux/of.h
 +
 +#define DAC8554_DRIVERNAME   ti-dac8554
 +#define DAC8554_DAC_CHANNELS 4
 +#define DAC8554_DATABITS 16
 +
 +/* Load commands */
 +#define DAC8554_CMD_STORE_DAC_N  0x0
 +#define DAC8554_CMD_UPDATE_DAC_N 0x1
 +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL   0x2
 +#define DAC8554_CMD_UPDATE_BROADCAST 0x3
 +
 +#define DAC8554_BROADCAST_USE_SRDATA 0x2
 +
 +/* Powerdown modes (PD1 | PD2 bits) */
 +#define DAC8554_PWRDN_HIZ0x0
 +#define DAC8554_PWRDN_1K 0x1
 +#define DAC8554_PWRDN_100K   0x2
 +
 +/* Input shift register composition */
 +#define DAC8554_ADDR_TO_SR(addr) ((addr)  22)
 +#define DAC8554_CMD_TO_SR(cmd)   ((cmd)  20)
 +#define DAC8554_CHAN_TO_SR(chan) ((chan)  17)
 +#define DAC8554_PWRDN_TO_SR(mode)(BIT(16) | (mode)  14)
 +
 +/**
 + * struct dac8554_state - driver instance specific data
 + * @spi: SPI device
 + * @reg: supply regulator
 + * @addr:two-bit chip address
 + * @val: channel data
 + * @powerdown:   channel powerdown flag
 + * @powerdown_mode:  channel powerdown mode
 + * @xfer:SPI transfer buffer
 + */
 +struct dac8554_state {
 + struct spi_device   *spi;
 + struct regulator*reg;
 + unsignedaddr;
 + u16 val[DAC8554_DAC_CHANNELS];
 + boolpowerdown[DAC8554_DAC_CHANNELS];
 + u8  powerdown_mode[DAC8554_DAC_CHANNELS];
 +
 + /*
 +  * DMA (thus cache coherency maintenance) requires the
 +  * transfer buffers to live in their own cache lines.
 +  */
 + u8  xfer[3] cacheline_aligned;
 +};
 +
 +static int dac8554_spi_write(struct

Re: [PATCH v3 5/5] iio: common: ssp_sensors: Add sensorhub gyroscope sensor

[Hartmut Knaack]

Karol Wrona schrieb am 05.12.2014 um 20:54:
> This patch adds gyroscope iio driver which uses sensorhub as data
> provider.
> 
This one has got a more serious issue.
> Change-Id: Ia16bc92159d062a29957de8e62ea3fefdcd7985a
> Signed-off-by: Karol Wrona 
> Acked-by: Kyungmin Park 
> ---
>  drivers/iio/gyro/Makefile  |2 +
>  drivers/iio/gyro/ssp_gyro_sensor.c |  202 
> 
>  2 files changed, 204 insertions(+)
>  create mode 100644 drivers/iio/gyro/ssp_gyro_sensor.c
> 

> +static int ssp_gyro_probe(struct platform_device *pdev)
> +{
> + int ret;
> + struct iio_dev *indio_dev;
> + struct ssp_sensor_data *spd;
> +
> + indio_dev = iio_device_alloc(sizeof(*spd));
Need to use devm_iio_device_alloc(), since iio_device_free() has been dropped.
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + spd = iio_priv(indio_dev);
> +
> + spd->process_data = ssp_process_gyro_data;
> + spd->type = SSP_GYROSCOPE_SENSOR;
> +
> + indio_dev->name = ssp_gyro_name;
> + indio_dev->dev.parent = >dev;
> + indio_dev->info = _gyro_iio_info;
> + indio_dev->modes = INDIO_BUFFER_HARDWARE;
> + indio_dev->channels = ssp_gyro_channels;
> + indio_dev->num_channels = ARRAY_SIZE(ssp_gyro_channels);
> +
> + ret = ssp_common_setup_buffer(indio_dev, _gyro_buffer_ops);
> + if (ret < 0) {
> + dev_err(>dev, "Buffer setup fail\n");
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, indio_dev);
> +
> + ret = iio_device_register(indio_dev);
> + if (ret < 0) {
> + iio_buffer_unregister(indio_dev);
> + iio_kfifo_free(indio_dev->buffer);
> + return ret;
> + };
> +
> + /* similar to accel */
> + ssp_register_consumer(indio_dev, SSP_GYROSCOPE_SENSOR);
> +
> + return 0;
> +}
> +
> +static int ssp_gyro_remove(struct platform_device *pdev)
> +{
> + struct iio_dev *indio_dev = platform_get_drvdata(pdev);
> +
> + iio_device_unregister(indio_dev);
> + iio_buffer_unregister(indio_dev);
> + iio_kfifo_free(indio_dev->buffer);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id ssp_gyro_id_table[] = {
> + {
> + .compatible = "samsung,mpu6500-gyro",
> + },
> + {},
> +};
> +
> +static struct platform_driver ssp_gyro_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = SSP_GYROSCOPE_NAME,
> + .of_match_table = ssp_gyro_id_table,
> + },
> + .probe = ssp_gyro_probe,
> + .remove = ssp_gyro_remove,
> +};
> +
> +module_platform_driver(ssp_gyro_driver);
> +
> +MODULE_AUTHOR("Karol Wrona ");
> +MODULE_DESCRIPTION("Samsung sensorhub gyroscopes driver");
> +MODULE_LICENSE("GPL");
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/5] iio: common: ssp_sensors: Add sensorhub accelerometer sensor

[Hartmut Knaack]

Karol Wrona schrieb am 05.12.2014 um 20:54:
> This patch adds accelerometer iio driver which uses sensorhub as data
> provider.
> 
Also looking very good now. One more whitespace issue remaining.
> Change-Id: I4686741b7401ec5cbf4b5d0f2a5cc146fbe24d53
> Signed-off-by: Karol Wrona 
> Acked-by: Kyungmin Park 
> ---
>  drivers/iio/accel/Makefile   |1 +
>  drivers/iio/accel/ssp_accel_sensor.c |  203 
> ++
>  2 files changed, 204 insertions(+)
>  create mode 100644 drivers/iio/accel/ssp_accel_sensor.c
> 

> +static struct platform_driver ssp_accel_driver = {
> + .driver = {
> + .owner = THIS_MODULE,
> + .name = SSP_ACCEL_NAME,
> + .of_match_table = ssp_accel_id_table,
> + },
> + .probe = ssp_accel_probe,
> + .remove =  ssp_accel_remove,
Double whitespace.
> +};
> +
> +module_platform_driver(ssp_accel_driver);
> +
> +MODULE_AUTHOR("Karol Wrona ");
> +MODULE_DESCRIPTION("Samsung sensorhub accelerometers driver");
> +MODULE_LICENSE("GPL");
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 3/5] iio: common: ssp_sensors: Add sensorhub iio commons

[Hartmut Knaack]

Karol Wrona schrieb am 05.12.2014 um 20:54:
> This patch adds common library for sensorhub iio drivers.
> 
Looks good to me, overall. Just one very small nitpick.
> Change-Id: I1038cb31c051f7e8ffde696a4121518daa5af081
> Signed-off-by: Karol Wrona 
> Acked-by: Kyungmin Park 
> ---
>  drivers/iio/common/ssp_sensors/ssp_iio.c|   82 
> +++
>  drivers/iio/common/ssp_sensors/ssp_iio_sensor.h |   56 
>  2 files changed, 138 insertions(+)
>  create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio.c
>  create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
> 

> +/* Converts time in ms to frequency */
> +static inline void ssp_convert_to_freq(u32 time, int *integer_part,
> +int *fractional)
> +{
> + if (time == 0) {
> + *fractional = 0;
> + *integer_part = 0;
> + return;
> + }
> +
> + *integer_part = SSP_DIVIDEND / time;
> + *fractional = do_div(*integer_part, SSP_DIVISOR);
> +}
> +
> +/* Converts frequency to time in ms*/
Missing whitespace at end of comment.
> +static inline int ssp_convert_to_time(int integer_part, int fractional)
> +{
> + u64 value;
> +
> + value = integer_part * SSP_DIVISOR + fractional;
> + if (value == 0)
> + return 0;
> +
> + return div_u64(SSP_DIVIDEND, value);
> +}
> +#endif /* __SSP_IIO_SENSOR_H__ */
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/5] iio: common: ssp_sensors: Add sensorhub driver

[Hartmut Knaack]

Karol Wrona schrieb am 05.12.2014 um 20:54:
> Sensorhub  is MCU dedicated to collect data and manage several sensors.
> Sensorhub is a spi device which provides a layer for IIO devices. It provides
> some data parsing and common mechanism for sensorhub sensors.
> 
> Adds common sensorhub library for sensorhub driver and iio drivers
> which uses sensorhub MCU to communicate with sensors.
> 
Looks very good now, mainly some new and old minor style issues remaining, see
inline.
> Change-Id: I4f066e9f3f477d4f6faabd4507be98e32f79e344
> Signed-off-by: Karol Wrona 
> Acked-by: Kyungmin Park 
> ---
>  drivers/iio/common/Kconfig   |1 +
>  drivers/iio/common/Makefile  |1 +
>  drivers/iio/common/ssp_sensors/Kconfig   |   24 ++
>  drivers/iio/common/ssp_sensors/Makefile  |6 +
>  drivers/iio/common/ssp_sensors/ssp.h |  254 +++
>  drivers/iio/common/ssp_sensors/ssp_dev.c |  693 
> ++
>  drivers/iio/common/ssp_sensors/ssp_spi.c |  644 +++
>  include/linux/iio/common/ssp_sensors.h   |   80 
>  8 files changed, 1703 insertions(+)
>  create mode 100644 drivers/iio/common/ssp_sensors/Kconfig
>  create mode 100644 drivers/iio/common/ssp_sensors/Makefile
>  create mode 100644 drivers/iio/common/ssp_sensors/ssp.h
>  create mode 100644 drivers/iio/common/ssp_sensors/ssp_dev.c
>  create mode 100644 drivers/iio/common/ssp_sensors/ssp_spi.c
>  create mode 100644 include/linux/iio/common/ssp_sensors.h
> 
> diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig
> index 0b6e97d..790f106 100644
> --- a/drivers/iio/common/Kconfig
> +++ b/drivers/iio/common/Kconfig
> @@ -3,4 +3,5 @@
>  #
>  
>  source "drivers/iio/common/hid-sensors/Kconfig"
> +source "drivers/iio/common/ssp_sensors/Kconfig"
>  source "drivers/iio/common/st_sensors/Kconfig"
> diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile
> index 3112df0..b1e4d9c 100644
> --- a/drivers/iio/common/Makefile
> +++ b/drivers/iio/common/Makefile
> @@ -8,4 +8,5 @@
>  
>  # When adding new entries keep the list in alphabetical order
>  obj-y += hid-sensors/
> +obj-y += ssp_sensors/
>  obj-y += st_sensors/
> diff --git a/drivers/iio/common/ssp_sensors/Kconfig 
> b/drivers/iio/common/ssp_sensors/Kconfig
> new file mode 100644
> index 000..c1d054e
> --- /dev/null
> +++ b/drivers/iio/common/ssp_sensors/Kconfig
> @@ -0,0 +1,24 @@
> +#
> +# SSP sensor drivers and commons configuration
> +#
> +menu "SSP Sensor Common"
> +
> +config IIO_SSP_SENSOR
> + tristate "Commons for all SSP Sensor IIO drivers"
> + depends on SSP_SENSORS
Shouldn't the individual sensor driver depend on the commons?
> + select IIO_BUFFER
> + select IIO_KFIFO_BUF
> + help
> +   Say yes here to build commons for SSP sensors.
It's tristate, so please provide module information.
> +
> +config SSP_SENSORS
Prefix with IIO_?
> + tristate "Samsung Sensorhub driver"
> + depends on SPI
> + help
> +   SSP driver for sensorhub.
> +   If you say yes here you get ssp support for
> +   sensorhub.
> +   To compile this driver as a module, choose M here: the
> +   module will be called sensorhub.
> +
> +endmenu
> diff --git a/drivers/iio/common/ssp_sensors/Makefile 
> b/drivers/iio/common/ssp_sensors/Makefile
> new file mode 100644
> index 000..7aede30
> --- /dev/null
> +++ b/drivers/iio/common/ssp_sensors/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for SSP sensor drivers and commons.
> +#
> +
> +obj-$(CONFIG_IIO_SSP_SENSOR) += ssp_iio.o
> +obj-$(CONFIG_SSP_SENSORS)+= ssp_dev.o ssp_spi.o
> diff --git a/drivers/iio/common/ssp_sensors/ssp.h 
> b/drivers/iio/common/ssp_sensors/ssp.h
> new file mode 100644
> index 000..b2fbc82
> --- /dev/null
> +++ b/drivers/iio/common/ssp_sensors/ssp.h
> @@ -0,0 +1,254 @@
> +/*
> + *  Copyright (C) 2014, Samsung Electronics Co. Ltd. All Rights Reserved.
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License as published by
> + *  the Free Software Foundation; either version 2 of the License, or
> + *  (at your option) any later version.
> + *
> + *  This program is distributed in the hope that 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.
> + *
> + */
> +
> +#ifndef __SSP_SENSORHUB_H__
> +#define __SSP_SENSORHUB_H__
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define SSP_DEVICE_ID0x55
> +
> +#ifdef SSP_DBG
> +#define ssp_dbg(format, ...) pr_info("[SSP] "format, ##__VA_ARGS__)
> +#else
> +#define ssp_dbg(format, ...)
> +#endif
> +
> +#define SSP_SW_RESET_TIME3000
> +/* Sensor polling in ms */
> +#define SSP_DEFAULT_POLLING_DELAY200
> +#define SSP_DEFAULT_RETRIES  3
> 

Re: [PATCH v3 1/5] iio: common: ssp_sensors: Add sensorhub driver

[Hartmut Knaack]

Karol Wrona schrieb am 05.12.2014 um 20:54:
 Sensorhub  is MCU dedicated to collect data and manage several sensors.
 Sensorhub is a spi device which provides a layer for IIO devices. It provides
 some data parsing and common mechanism for sensorhub sensors.
 
 Adds common sensorhub library for sensorhub driver and iio drivers
 which uses sensorhub MCU to communicate with sensors.
 
Looks very good now, mainly some new and old minor style issues remaining, see
inline.
 Change-Id: I4f066e9f3f477d4f6faabd4507be98e32f79e344
 Signed-off-by: Karol Wrona k.wr...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/iio/common/Kconfig   |1 +
  drivers/iio/common/Makefile  |1 +
  drivers/iio/common/ssp_sensors/Kconfig   |   24 ++
  drivers/iio/common/ssp_sensors/Makefile  |6 +
  drivers/iio/common/ssp_sensors/ssp.h |  254 +++
  drivers/iio/common/ssp_sensors/ssp_dev.c |  693 
 ++
  drivers/iio/common/ssp_sensors/ssp_spi.c |  644 +++
  include/linux/iio/common/ssp_sensors.h   |   80 
  8 files changed, 1703 insertions(+)
  create mode 100644 drivers/iio/common/ssp_sensors/Kconfig
  create mode 100644 drivers/iio/common/ssp_sensors/Makefile
  create mode 100644 drivers/iio/common/ssp_sensors/ssp.h
  create mode 100644 drivers/iio/common/ssp_sensors/ssp_dev.c
  create mode 100644 drivers/iio/common/ssp_sensors/ssp_spi.c
  create mode 100644 include/linux/iio/common/ssp_sensors.h
 
 diff --git a/drivers/iio/common/Kconfig b/drivers/iio/common/Kconfig
 index 0b6e97d..790f106 100644
 --- a/drivers/iio/common/Kconfig
 +++ b/drivers/iio/common/Kconfig
 @@ -3,4 +3,5 @@
  #
  
  source drivers/iio/common/hid-sensors/Kconfig
 +source drivers/iio/common/ssp_sensors/Kconfig
  source drivers/iio/common/st_sensors/Kconfig
 diff --git a/drivers/iio/common/Makefile b/drivers/iio/common/Makefile
 index 3112df0..b1e4d9c 100644
 --- a/drivers/iio/common/Makefile
 +++ b/drivers/iio/common/Makefile
 @@ -8,4 +8,5 @@
  
  # When adding new entries keep the list in alphabetical order
  obj-y += hid-sensors/
 +obj-y += ssp_sensors/
  obj-y += st_sensors/
 diff --git a/drivers/iio/common/ssp_sensors/Kconfig 
 b/drivers/iio/common/ssp_sensors/Kconfig
 new file mode 100644
 index 000..c1d054e
 --- /dev/null
 +++ b/drivers/iio/common/ssp_sensors/Kconfig
 @@ -0,0 +1,24 @@
 +#
 +# SSP sensor drivers and commons configuration
 +#
 +menu SSP Sensor Common
 +
 +config IIO_SSP_SENSOR
 + tristate Commons for all SSP Sensor IIO drivers
 + depends on SSP_SENSORS
Shouldn't the individual sensor driver depend on the commons?
 + select IIO_BUFFER
 + select IIO_KFIFO_BUF
 + help
 +   Say yes here to build commons for SSP sensors.
It's tristate, so please provide module information.
 +
 +config SSP_SENSORS
Prefix with IIO_?
 + tristate Samsung Sensorhub driver
 + depends on SPI
 + help
 +   SSP driver for sensorhub.
 +   If you say yes here you get ssp support for
 +   sensorhub.
 +   To compile this driver as a module, choose M here: the
 +   module will be called sensorhub.
 +
 +endmenu
 diff --git a/drivers/iio/common/ssp_sensors/Makefile 
 b/drivers/iio/common/ssp_sensors/Makefile
 new file mode 100644
 index 000..7aede30
 --- /dev/null
 +++ b/drivers/iio/common/ssp_sensors/Makefile
 @@ -0,0 +1,6 @@
 +#
 +# Makefile for SSP sensor drivers and commons.
 +#
 +
 +obj-$(CONFIG_IIO_SSP_SENSOR) += ssp_iio.o
 +obj-$(CONFIG_SSP_SENSORS)+= ssp_dev.o ssp_spi.o
 diff --git a/drivers/iio/common/ssp_sensors/ssp.h 
 b/drivers/iio/common/ssp_sensors/ssp.h
 new file mode 100644
 index 000..b2fbc82
 --- /dev/null
 +++ b/drivers/iio/common/ssp_sensors/ssp.h
 @@ -0,0 +1,254 @@
 +/*
 + *  Copyright (C) 2014, Samsung Electronics Co. Ltd. All Rights Reserved.
 + *
 + *  This program is free software; you can redistribute it and/or modify
 + *  it under the terms of the GNU General Public License as published by
 + *  the Free Software Foundation; either version 2 of the License, or
 + *  (at your option) any later version.
 + *
 + *  This program is distributed in the hope that 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.
 + *
 + */
 +
 +#ifndef __SSP_SENSORHUB_H__
 +#define __SSP_SENSORHUB_H__
 +
 +#include linux/delay.h
 +#include linux/gpio.h
 +#include linux/iio/common/ssp_sensors.h
 +#include linux/iio/iio.h
 +#include linux/spi/spi.h
 +
 +#define SSP_DEVICE_ID0x55
 +
 +#ifdef SSP_DBG
 +#define ssp_dbg(format, ...) pr_info([SSP] format, ##__VA_ARGS__)
 +#else
 +#define ssp_dbg(format, ...)
 +#endif
 +
 +#define SSP_SW_RESET_TIME3000
 +/* Sensor polling in ms */
 +#define SSP_DEFAULT_POLLING_DELAY200
 +#define SSP_DEFAULT_RETRIES  3
 +#define 

Re: [PATCH v3 3/5] iio: common: ssp_sensors: Add sensorhub iio commons

[Hartmut Knaack]

Karol Wrona schrieb am 05.12.2014 um 20:54:
 This patch adds common library for sensorhub iio drivers.
 
Looks good to me, overall. Just one very small nitpick.
 Change-Id: I1038cb31c051f7e8ffde696a4121518daa5af081
 Signed-off-by: Karol Wrona k.wr...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/iio/common/ssp_sensors/ssp_iio.c|   82 
 +++
  drivers/iio/common/ssp_sensors/ssp_iio_sensor.h |   56 
  2 files changed, 138 insertions(+)
  create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio.c
  create mode 100644 drivers/iio/common/ssp_sensors/ssp_iio_sensor.h
 

 +/* Converts time in ms to frequency */
 +static inline void ssp_convert_to_freq(u32 time, int *integer_part,
 +int *fractional)
 +{
 + if (time == 0) {
 + *fractional = 0;
 + *integer_part = 0;
 + return;
 + }
 +
 + *integer_part = SSP_DIVIDEND / time;
 + *fractional = do_div(*integer_part, SSP_DIVISOR);
 +}
 +
 +/* Converts frequency to time in ms*/
Missing whitespace at end of comment.
 +static inline int ssp_convert_to_time(int integer_part, int fractional)
 +{
 + u64 value;
 +
 + value = integer_part * SSP_DIVISOR + fractional;
 + if (value == 0)
 + return 0;
 +
 + return div_u64(SSP_DIVIDEND, value);
 +}
 +#endif /* __SSP_IIO_SENSOR_H__ */
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 4/5] iio: common: ssp_sensors: Add sensorhub accelerometer sensor

[Hartmut Knaack]

Karol Wrona schrieb am 05.12.2014 um 20:54:
 This patch adds accelerometer iio driver which uses sensorhub as data
 provider.
 
Also looking very good now. One more whitespace issue remaining.
 Change-Id: I4686741b7401ec5cbf4b5d0f2a5cc146fbe24d53
 Signed-off-by: Karol Wrona k.wr...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/iio/accel/Makefile   |1 +
  drivers/iio/accel/ssp_accel_sensor.c |  203 
 ++
  2 files changed, 204 insertions(+)
  create mode 100644 drivers/iio/accel/ssp_accel_sensor.c
 

 +static struct platform_driver ssp_accel_driver = {
 + .driver = {
 + .owner = THIS_MODULE,
 + .name = SSP_ACCEL_NAME,
 + .of_match_table = ssp_accel_id_table,
 + },
 + .probe = ssp_accel_probe,
 + .remove =  ssp_accel_remove,
Double whitespace.
 +};
 +
 +module_platform_driver(ssp_accel_driver);
 +
 +MODULE_AUTHOR(Karol Wrona k.wr...@samsung.com);
 +MODULE_DESCRIPTION(Samsung sensorhub accelerometers driver);
 +MODULE_LICENSE(GPL);
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 5/5] iio: common: ssp_sensors: Add sensorhub gyroscope sensor

[Hartmut Knaack]

Karol Wrona schrieb am 05.12.2014 um 20:54:
 This patch adds gyroscope iio driver which uses sensorhub as data
 provider.
 
This one has got a more serious issue.
 Change-Id: Ia16bc92159d062a29957de8e62ea3fefdcd7985a
 Signed-off-by: Karol Wrona k.wr...@samsung.com
 Acked-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/iio/gyro/Makefile  |2 +
  drivers/iio/gyro/ssp_gyro_sensor.c |  202 
 
  2 files changed, 204 insertions(+)
  create mode 100644 drivers/iio/gyro/ssp_gyro_sensor.c
 

 +static int ssp_gyro_probe(struct platform_device *pdev)
 +{
 + int ret;
 + struct iio_dev *indio_dev;
 + struct ssp_sensor_data *spd;
 +
 + indio_dev = iio_device_alloc(sizeof(*spd));
Need to use devm_iio_device_alloc(), since iio_device_free() has been dropped.
 + if (!indio_dev)
 + return -ENOMEM;
 +
 + spd = iio_priv(indio_dev);
 +
 + spd-process_data = ssp_process_gyro_data;
 + spd-type = SSP_GYROSCOPE_SENSOR;
 +
 + indio_dev-name = ssp_gyro_name;
 + indio_dev-dev.parent = pdev-dev;
 + indio_dev-info = ssp_gyro_iio_info;
 + indio_dev-modes = INDIO_BUFFER_HARDWARE;
 + indio_dev-channels = ssp_gyro_channels;
 + indio_dev-num_channels = ARRAY_SIZE(ssp_gyro_channels);
 +
 + ret = ssp_common_setup_buffer(indio_dev, ssp_gyro_buffer_ops);
 + if (ret  0) {
 + dev_err(pdev-dev, Buffer setup fail\n);
 + return ret;
 + }
 +
 + platform_set_drvdata(pdev, indio_dev);
 +
 + ret = iio_device_register(indio_dev);
 + if (ret  0) {
 + iio_buffer_unregister(indio_dev);
 + iio_kfifo_free(indio_dev-buffer);
 + return ret;
 + };
 +
 + /* similar to accel */
 + ssp_register_consumer(indio_dev, SSP_GYROSCOPE_SENSOR);
 +
 + return 0;
 +}
 +
 +static int ssp_gyro_remove(struct platform_device *pdev)
 +{
 + struct iio_dev *indio_dev = platform_get_drvdata(pdev);
 +
 + iio_device_unregister(indio_dev);
 + iio_buffer_unregister(indio_dev);
 + iio_kfifo_free(indio_dev-buffer);
 +
 + return 0;
 +}
 +
 +static const struct of_device_id ssp_gyro_id_table[] = {
 + {
 + .compatible = samsung,mpu6500-gyro,
 + },
 + {},
 +};
 +
 +static struct platform_driver ssp_gyro_driver = {
 + .driver = {
 + .owner = THIS_MODULE,
 + .name = SSP_GYROSCOPE_NAME,
 + .of_match_table = ssp_gyro_id_table,
 + },
 + .probe = ssp_gyro_probe,
 + .remove = ssp_gyro_remove,
 +};
 +
 +module_platform_driver(ssp_gyro_driver);
 +
 +MODULE_AUTHOR(Karol Wrona k.wr...@samsung.com);
 +MODULE_DESCRIPTION(Samsung sensorhub gyroscopes driver);
 +MODULE_LICENSE(GPL);
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 6/6] iio: imu: kmx61: Add support for any motion trigger

[Hartmut Knaack]

Daniel Baluta schrieb am 03.12.2014 um 14:31:
> We use WUFE (Wake Up from Sleep Engine) and BTSE (Back to Sleep Engine)
> to detect general motion input.
> 
A few recommendations, issues and questions inline.
> Signed-off-by: Daniel Baluta 
> ---
>  drivers/iio/imu/kmx61.c | 433 
> +++-
>  1 file changed, 426 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 0f6816a..972424b 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -30,6 +31,8 @@
>  #define KMX61_IRQ_NAME "kmx61_event"
>  
>  #define KMX61_REG_WHO_AM_I   0x00
> +#define KMX61_REG_INS1   0x01
> +#define KMX61_REG_INS2   0x02
>  
>  /*
>   * three 16-bit accelerometer output registers for X/Y/Z axis
> @@ -63,20 +66,36 @@
>  #define KMX61_REG_INL0x28
>  #define KMX61_REG_STBY   0x29
>  #define KMX61_REG_CTRL1  0x2A
> +#define KMX61_REG_CTRL2  0x2B
>  #define KMX61_REG_ODCNTL 0x2C
>  #define KMX61_REG_INC1   0x2D
>  
> +#define KMX61_REG_WUF_THRESH 0x3D
> +#define KMX61_REG_WUF_TIMER  0x3E
> +
>  #define KMX61_ACC_STBY_BIT   BIT(0)
>  #define KMX61_MAG_STBY_BIT   BIT(1)
>  #define KMX61_ACT_STBY_BIT   BIT(7)
>  
>  #define KMX61_ALL_STBY   (KMX61_ACC_STBY_BIT | 
> KMX61_MAG_STBY_BIT)
>  
> +#define KMX61_REG_INS1_BIT_WUFS  BIT(1)
> +
> +#define KMX61_REG_INS2_BIT_ZPBIT(0)
> +#define KMX61_REG_INS2_BIT_ZNBIT(1)
> +#define KMX61_REG_INS2_BIT_YPBIT(2)
> +#define KMX61_REG_INS2_BIT_YNBIT(3)
> +#define KMX61_REG_INS2_BIT_XPBIT(4)
> +#define KMX61_REG_INS2_BIT_XNBIT(5)
> +
>  #define KMX61_REG_CTRL1_GSEL_MASK0x03
>  
>  #define KMX61_REG_CTRL1_BIT_RES  BIT(4)
>  #define KMX61_REG_CTRL1_BIT_DRDYEBIT(5)
> +#define KMX61_REG_CTRL1_BIT_WUFE BIT(6)
> +#define KMX61_REG_CTRL1_BIT_BTSE BIT(7)
>  
> +#define KMX61_REG_INC1_BIT_WUFS  BIT(0)
>  #define KMX61_REG_INC1_BIT_DRDYM BIT(1)
>  #define KMX61_REG_INC1_BIT_DRDYA BIT(2)
>  #define KMX61_REG_INC1_BIT_IEN   BIT(5)
> @@ -86,6 +105,11 @@
>  #define KMX61_ACC_ODR_MASK   0x0F
>  #define KMX61_MAG_ODR_MASK   0xF0
>  
> +#define KMX61_OWUF_MASK  0x7
> +
> +#define KMX61_DEFAULT_WAKE_THRESH1
> +#define KMX61_DEFAULT_WAKE_DURATION  1
> +
>  #define KMX61_SLEEP_DELAY_MS 2000
>  
>  #define KMX61_CHIP_ID0x12
> @@ -111,11 +135,16 @@ struct kmx61_data {
>   /* config bits */
>   u8 range;
>   u8 odr_bits;
> + u8 wake_thresh;
> + u8 wake_duration;
>  
>   /* accelerometer specific data */
>   struct iio_dev *acc_indio_dev;
>   struct iio_trigger *acc_dready_trig;
> + struct iio_trigger *motion_trig;
>   bool acc_dready_trig_on;
> + bool motion_trig_on;
> + bool ev_enable_state;
>  
>   /* magnetometer specific data */
>   struct iio_dev *mag_indio_dev;
> @@ -154,6 +183,23 @@ static const struct {
>   {3, 125000, 0x0A},
>   {6, 25, 0x0B} };
>  
> +static const struct {
> + int val;
> + int val2;
> + int odr_bits;
> +} kmx61_wake_up_odr_table[] = { {0, 781000, 0x00},
> +  {1, 563000, 0x01},
> +  {3, 125000, 0x02},
> +  {6, 25, 0x03},
> +  {12, 50, 0x04},
> +  {25, 0, 0x05},
> +  {50, 0, 0x06},
> +  {100, 0, 0x06},
> +  {200, 0, 0x06},
> +  {400, 0, 0x06},
> +  {800, 0, 0x06},
> +  {1600, 0, 0x06} };
Is it intentional, that values above 50 share the same odr_bits?
> +
>  static IIO_CONST_ATTR(accel_scale_available, "0.009582 0.019163 0.038326");
>  static IIO_CONST_ATTR(magn_scale_available, "0.001465");
>  static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
> @@ -179,6 +225,14 @@ static const struct attribute_group 
> kmx61_mag_attribute_group = {
>   .attrs = kmx61_mag_attributes,
>  };
>  
> +static const struct iio_event_spec kmx61_event = {
> + .type = IIO_EV_TYPE_THRESH,
> + .dir = IIO_EV_DIR_EITHER,
> + .mask_separate = BIT(IIO_EV_INFO_VALUE) |
> +  BIT(IIO_EV_INFO_ENABLE) |
> +  BIT(IIO_EV_INFO_PERIOD),
> +};
> +
>  #define KMX61_ACC_CHAN(_axis) { \
>   .type = IIO_ACCEL, \
>   .modified = 1, \
> @@ -195,6 +249,8 @@ static const struct attribute_group 
> kmx61_mag_attribute_group = {
>   .shift = 4, \
>   .endianness = IIO_LE, \
>   }, \
> + .event_spec = _event, \
> + 

Re: [PATCH v4 6/6] iio: imu: kmx61: Add support for any motion trigger

[Hartmut Knaack]

Daniel Baluta schrieb am 03.12.2014 um 14:31:
 We use WUFE (Wake Up from Sleep Engine) and BTSE (Back to Sleep Engine)
 to detect general motion input.
 
A few recommendations, issues and questions inline.
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
  drivers/iio/imu/kmx61.c | 433 
 +++-
  1 file changed, 426 insertions(+), 7 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index 0f6816a..972424b 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -20,6 +20,7 @@
  #include linux/pm_runtime.h
  #include linux/iio/iio.h
  #include linux/iio/sysfs.h
 +#include linux/iio/events.h
  #include linux/iio/trigger.h
  #include linux/iio/buffer.h
  #include linux/iio/triggered_buffer.h
 @@ -30,6 +31,8 @@
  #define KMX61_IRQ_NAME kmx61_event
  
  #define KMX61_REG_WHO_AM_I   0x00
 +#define KMX61_REG_INS1   0x01
 +#define KMX61_REG_INS2   0x02
  
  /*
   * three 16-bit accelerometer output registers for X/Y/Z axis
 @@ -63,20 +66,36 @@
  #define KMX61_REG_INL0x28
  #define KMX61_REG_STBY   0x29
  #define KMX61_REG_CTRL1  0x2A
 +#define KMX61_REG_CTRL2  0x2B
  #define KMX61_REG_ODCNTL 0x2C
  #define KMX61_REG_INC1   0x2D
  
 +#define KMX61_REG_WUF_THRESH 0x3D
 +#define KMX61_REG_WUF_TIMER  0x3E
 +
  #define KMX61_ACC_STBY_BIT   BIT(0)
  #define KMX61_MAG_STBY_BIT   BIT(1)
  #define KMX61_ACT_STBY_BIT   BIT(7)
  
  #define KMX61_ALL_STBY   (KMX61_ACC_STBY_BIT | 
 KMX61_MAG_STBY_BIT)
  
 +#define KMX61_REG_INS1_BIT_WUFS  BIT(1)
 +
 +#define KMX61_REG_INS2_BIT_ZPBIT(0)
 +#define KMX61_REG_INS2_BIT_ZNBIT(1)
 +#define KMX61_REG_INS2_BIT_YPBIT(2)
 +#define KMX61_REG_INS2_BIT_YNBIT(3)
 +#define KMX61_REG_INS2_BIT_XPBIT(4)
 +#define KMX61_REG_INS2_BIT_XNBIT(5)
 +
  #define KMX61_REG_CTRL1_GSEL_MASK0x03
  
  #define KMX61_REG_CTRL1_BIT_RES  BIT(4)
  #define KMX61_REG_CTRL1_BIT_DRDYEBIT(5)
 +#define KMX61_REG_CTRL1_BIT_WUFE BIT(6)
 +#define KMX61_REG_CTRL1_BIT_BTSE BIT(7)
  
 +#define KMX61_REG_INC1_BIT_WUFS  BIT(0)
  #define KMX61_REG_INC1_BIT_DRDYM BIT(1)
  #define KMX61_REG_INC1_BIT_DRDYA BIT(2)
  #define KMX61_REG_INC1_BIT_IEN   BIT(5)
 @@ -86,6 +105,11 @@
  #define KMX61_ACC_ODR_MASK   0x0F
  #define KMX61_MAG_ODR_MASK   0xF0
  
 +#define KMX61_OWUF_MASK  0x7
 +
 +#define KMX61_DEFAULT_WAKE_THRESH1
 +#define KMX61_DEFAULT_WAKE_DURATION  1
 +
  #define KMX61_SLEEP_DELAY_MS 2000
  
  #define KMX61_CHIP_ID0x12
 @@ -111,11 +135,16 @@ struct kmx61_data {
   /* config bits */
   u8 range;
   u8 odr_bits;
 + u8 wake_thresh;
 + u8 wake_duration;
  
   /* accelerometer specific data */
   struct iio_dev *acc_indio_dev;
   struct iio_trigger *acc_dready_trig;
 + struct iio_trigger *motion_trig;
   bool acc_dready_trig_on;
 + bool motion_trig_on;
 + bool ev_enable_state;
  
   /* magnetometer specific data */
   struct iio_dev *mag_indio_dev;
 @@ -154,6 +183,23 @@ static const struct {
   {3, 125000, 0x0A},
   {6, 25, 0x0B} };
  
 +static const struct {
 + int val;
 + int val2;
 + int odr_bits;
 +} kmx61_wake_up_odr_table[] = { {0, 781000, 0x00},
 +  {1, 563000, 0x01},
 +  {3, 125000, 0x02},
 +  {6, 25, 0x03},
 +  {12, 50, 0x04},
 +  {25, 0, 0x05},
 +  {50, 0, 0x06},
 +  {100, 0, 0x06},
 +  {200, 0, 0x06},
 +  {400, 0, 0x06},
 +  {800, 0, 0x06},
 +  {1600, 0, 0x06} };
Is it intentional, that values above 50 share the same odr_bits?
 +
  static IIO_CONST_ATTR(accel_scale_available, 0.009582 0.019163 0.038326);
  static IIO_CONST_ATTR(magn_scale_available, 0.001465);
  static IIO_CONST_ATTR_SAMP_FREQ_AVAIL(
 @@ -179,6 +225,14 @@ static const struct attribute_group 
 kmx61_mag_attribute_group = {
   .attrs = kmx61_mag_attributes,
  };
  
 +static const struct iio_event_spec kmx61_event = {
 + .type = IIO_EV_TYPE_THRESH,
 + .dir = IIO_EV_DIR_EITHER,
 + .mask_separate = BIT(IIO_EV_INFO_VALUE) |
 +  BIT(IIO_EV_INFO_ENABLE) |
 +  BIT(IIO_EV_INFO_PERIOD),
 +};
 +
  #define KMX61_ACC_CHAN(_axis) { \
   .type = IIO_ACCEL, \
   .modified = 1, \
 @@ -195,6 +249,8 @@ static const struct attribute_group 
 kmx61_mag_attribute_group = {
   .shift = 4, \
   .endianness = IIO_LE, \
   }, \
 + .event_spec = kmx61_event, \
 + 

Re: [PATCH v4 5/6] iio: imu: kmx61: Add support for data ready triggers

[Hartmut Knaack]

Daniel Baluta schrieb am 03.12.2014 um 14:31:
> This creates a data ready trigger per IIO device.
> 
I found some issues here, and some recommendations. See inline.

> Signed-off-by: Daniel Baluta 
> ---
>  drivers/iio/imu/Kconfig |   2 +
>  drivers/iio/imu/kmx61.c | 295 
> +++-
>  2 files changed, 296 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
> index db4221d..5e610f7 100644
> --- a/drivers/iio/imu/Kconfig
> +++ b/drivers/iio/imu/Kconfig
> @@ -28,6 +28,8 @@ config ADIS16480
>  config KMX61
>   tristate "Kionix KMX61 6-axis accelerometer and magnetometer"
>   depends on I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
>   help
> Say Y here if you want to build a driver for Kionix KMX61 6-axis
> accelerometer and magnetometer.
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index f69ae5a7..0f6816a 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -20,9 +20,14 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
> +#include 
>  
>  #define KMX61_DRV_NAME "kmx61"
>  #define KMX61_GPIO_NAME "kmx61_int"
> +#define KMX61_IRQ_NAME "kmx61_event"
>  
>  #define KMX61_REG_WHO_AM_I   0x00
>  
> @@ -55,9 +60,11 @@
>  #define KMX61_MAG_ZOUT_L 0x16
>  #define KMX61_MAG_ZOUT_H 0x17
>  
> +#define KMX61_REG_INL0x28
>  #define KMX61_REG_STBY   0x29
>  #define KMX61_REG_CTRL1  0x2A
>  #define KMX61_REG_ODCNTL 0x2C
> +#define KMX61_REG_INC1   0x2D
>  
>  #define KMX61_ACC_STBY_BIT   BIT(0)
>  #define KMX61_MAG_STBY_BIT   BIT(1)
> @@ -67,6 +74,13 @@
>  
>  #define KMX61_REG_CTRL1_GSEL_MASK0x03
>  
> +#define KMX61_REG_CTRL1_BIT_RES  BIT(4)
> +#define KMX61_REG_CTRL1_BIT_DRDYEBIT(5)
> +
> +#define KMX61_REG_INC1_BIT_DRDYM BIT(1)
> +#define KMX61_REG_INC1_BIT_DRDYA BIT(2)
> +#define KMX61_REG_INC1_BIT_IEN   BIT(5)
> +
>  #define KMX61_ACC_ODR_SHIFT  0
>  #define KMX61_MAG_ODR_SHIFT  4
>  #define KMX61_ACC_ODR_MASK   0x0F
> @@ -100,9 +114,13 @@ struct kmx61_data {
>  
>   /* accelerometer specific data */
>   struct iio_dev *acc_indio_dev;
> + struct iio_trigger *acc_dready_trig;
> + bool acc_dready_trig_on;
>  
>   /* magnetometer specific data */
>   struct iio_dev *mag_indio_dev;
> + struct iio_trigger *mag_dready_trig;
> + bool mag_dready_trig_on;
>  };
>  
>  enum kmx61_range {
> @@ -466,6 +484,69 @@ static int kmx61_chip_init(struct kmx61_data *data)
>   return 0;
>  }
>  
> +static int kmx61_setup_new_data_interrupt(struct kmx61_data *data,
> +   bool status, u8 device)
> +{
> + u8 mode;
> + int ret;
> +
> + ret = kmx61_get_mode(data, , KMX61_ACC | KMX61_MAG);
> + if (ret < 0)
> + return ret;
> +
> + ret = kmx61_set_mode(data, KMX61_ALL_STBY, KMX61_ACC | KMX61_MAG, true);
> + if (ret < 0)
> + return ret;
> +
> + ret = i2c_smbus_read_byte_data(data->client, KMX61_REG_INC1);
> + if (ret < 0) {
> + dev_err(>client->dev, "Error reading reg_ctrl1\n");
> + return ret;
> + }
> +
> + if (status) {
> + ret |= KMX61_REG_INC1_BIT_IEN;
> + if (device & KMX61_ACC)
> + ret |= KMX61_REG_INC1_BIT_DRDYA;
> + if (device & KMX61_MAG)
> + ret |=  KMX61_REG_INC1_BIT_DRDYM;
> + } else {
> + ret &= ~KMX61_REG_INC1_BIT_IEN;
> + if (device & KMX61_ACC)
> + ret &= ~KMX61_REG_INC1_BIT_DRDYA;
> + if (device & KMX61_MAG)
> + ret &= ~KMX61_REG_INC1_BIT_DRDYM;
> + }
> + ret = i2c_smbus_write_byte_data(data->client, KMX61_REG_INC1, ret);
> + if (ret < 0) {
> + dev_err(>client->dev, "Error writing reg_int_ctrl1\n");
> + return ret;
> + }
> +
> + ret = i2c_smbus_read_byte_data(data->client, KMX61_REG_CTRL1);
> + if (ret < 0) {
> + dev_err(>client->dev, "Error reading reg_ctrl1\n");
> + return ret;
> + }
> +
> + if (status)
> + ret |= KMX61_REG_CTRL1_BIT_DRDYE;
> + else
> + ret &= ~KMX61_REG_CTRL1_BIT_DRDYE;
> +
> + ret = i2c_smbus_write_byte_data(data->client, KMX61_REG_CTRL1, ret);
> + if (ret < 0) {
> + dev_err(>client->dev, "Error writing reg_ctrl1\n");
> + return ret;
> + }
> +
> + ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
> + if (ret)
> + return ret;
> +
> + return 0;
No need to check ret here, could be simply: return kmx61_set_mode(...);
> +}
> +
>  /**
>   * kmx61_set_power_state() - set power state for kmx61 @device
>   * @data - kmx61 device private pointer
> @@ -626,11 +707,34 @@ static int kmx61_write_raw(struct iio_dev *indio_dev,
>  

Re: [PATCH v4 3/6] iio: imu: kmx61: Add PM runtime support

[Hartmut Knaack]

Daniel Baluta schrieb am 03.12.2014 um 14:31:
> By default both sensors are ACTIVE, in this way the driver
> will work even if CONFIG_PM_RUNTIME is not selected.
> 
Since kmx61_set_power_state() can return error codes, wouldn't it be better to
handle them (as long as you are not using it in an error handler)?
Thanks,

Hartmut
> Signed-off-by: Daniel Baluta 
> ---
>  drivers/iio/imu/kmx61.c | 114 
> +++-
>  1 file changed, 112 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> index 893f7c8..7536043 100644
> --- a/drivers/iio/imu/kmx61.c
> +++ b/drivers/iio/imu/kmx61.c
> @@ -15,6 +15,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  #include 
>  #include 
>  
> @@ -69,6 +71,8 @@
>  #define KMX61_ACC_ODR_MASK   0x0F
>  #define KMX61_MAG_ODR_MASK   0xF0
>  
> +#define KMX61_SLEEP_DELAY_MS 2000
> +
>  #define KMX61_CHIP_ID0x12
>  
>  /* KMX61 devices */
> @@ -85,6 +89,10 @@ struct kmx61_data {
>   bool acc_stby;
>   bool mag_stby;
>  
> + /* power state */
> + bool acc_ps;
> + bool mag_ps;
> +
>   /* config bits */
>   u8 range;
>   u8 odr_bits;
> @@ -457,6 +465,58 @@ static int kmx61_chip_init(struct kmx61_data *data)
>   return 0;
>  }
>  
> +/**
> + * kmx61_set_power_state() - set power state for kmx61 @device
> + * @data - kmx61 device private pointer
> + * @on - power state to be set for @device
> + * @device - bitmask indicating device for which @on state needs to be set
> + *
> + * Notice that when ACC power state needs to be set to ON and MAG is in
> + * OPERATION then we know that kmx61_runtime_resume was already called
> + * so we must set ACC OPERATION mode here. The same happens when MAG power
> + * state needs to be set to ON and ACC is in OPERATION.
> + */
> +static int kmx61_set_power_state(struct kmx61_data *data, bool on, u8 device)
> +{
> +#ifdef CONFIG_PM_RUNTIME
> + int ret;
> +
> + if (device & KMX61_ACC) {
> + if (on && !data->acc_ps && !data->mag_stby) {
> + ret = kmx61_set_mode(data, 0, KMX61_ACC, true);
> + if (ret < 0)
> + return ret;
> + }
> + data->acc_ps = on;
> + }
> + if (device & KMX61_MAG) {
> + if (on && !data->mag_ps && !data->acc_stby) {
> + ret = kmx61_set_mode(data, 0, KMX61_MAG, true);
> + if (ret < 0)
> + return ret;
> + }
> + data->mag_ps = on;
> + }
> +
> + if (on) {
> + ret = pm_runtime_get_sync(>client->dev);
> + } else {
> + pm_runtime_mark_last_busy(>client->dev);
> + ret = pm_runtime_put_autosuspend(>client->dev);
> + }
> + if (ret < 0) {
> + dev_err(>client->dev,
> + "Failed: kmx61_set_power_state for %d, ret %d\n",
> + on, ret);
> + if (on)
> + pm_runtime_put_noidle(>client->dev);
> +
> + return ret;
> + }
> +#endif
> + return 0;
> +}
> +
>  static int kmx61_read_measurement(struct kmx61_data *data, u8 base, u8 
> offset)
>  {
>   int ret;
> @@ -491,13 +551,16 @@ static int kmx61_read_raw(struct iio_dev *indio_dev,
>   }
>   mutex_lock(>lock);
>  
> + kmx61_set_power_state(data, true, chan->address);
>   ret = kmx61_read_measurement(data, base_reg, chan->scan_index);
>   if (ret < 0) {
> + kmx61_set_power_state(data, false, chan->address);
>   mutex_unlock(>lock);
>   return ret;
>   }
>   *val = sign_extend32(ret >> chan->scan_type.shift,
>chan->scan_type.realbits - 1);
> + kmx61_set_power_state(data, false, chan->address);
>  
>   mutex_unlock(>lock);
>   return IIO_VAL_INT;
> @@ -693,12 +756,22 @@ static int kmx61_probe(struct i2c_client *client,
>   ret = iio_device_register(data->mag_indio_dev);
>   if (ret < 0) {
>   dev_err(>dev, "Failed to register mag iio device\n");
> - goto err_iio_unregister;
> + goto err_iio_unregister_acc;
>   }
>  
> + ret = pm_runtime_set_active(>dev);
> + if (ret < 0)
> + goto err_iio_unregister_mag;
> +
> + pm_runtime_enable(>dev);
> + pm_runtime_set_autosuspend_delay(>dev, KMX61_SLEEP_DELAY_MS);
> + pm_runtime_use_autosuspend(>dev);
> +
>   return 0;
>  
> -err_iio_unregister:
> +err_iio_unregister_mag:
> + iio_device_unregister(data->mag_indio_dev);
> +err_iio_unregister_acc:
>   iio_device_unregister(data->acc_indio_dev);
>  err_chip_uninit:
>   kmx61_set_mode(data, KMX61_ALL_STBY, KMX61_ACC | KMX61_MAG, true);
> @@ -709,6 +782,10 @@ static int kmx61_remove(struct 

Re: [PATCH v4 1/6] iio: imu: Add support for Kionix KMX61 sensor

[Hartmut Knaack]

Daniel Baluta schrieb am 03.12.2014 um 14:31:
> Minimal implementation for KMX61 6-axis accelerometer/magnetometer. It exports
> raw accel/magn readings together with scale and sampling frequency.
> 
> This driver uses two IIO devices one for accelerometer and one for 
> magnetometer.
> 
Hi Daniel,
I think you dropped slightly too much code. In kmx61_set_odr() you stored the 
set
odr bits in data->odr_bits previously, but now it's gone. But kmx61_get_odr()
accesses data->odr_bits, which now remains in the state from driver 
initialization.
Other than that, it's looking good.
Thanks,

Hartmut
> Datasheet will be available at:
> http://www.kionix.com/6-axis-accelerometer-magnetometer/kmx61
> 
> Signed-off-by: Daniel Baluta 
> ---
>  drivers/iio/imu/Kconfig  |   9 +
>  drivers/iio/imu/Makefile |   2 +
>  drivers/iio/imu/kmx61.c  | 691 
> +++
>  3 files changed, 702 insertions(+)
>  create mode 100644 drivers/iio/imu/kmx61.c
> 
> diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
> index 2b0e451..db4221d 100644
> --- a/drivers/iio/imu/Kconfig
> +++ b/drivers/iio/imu/Kconfig
> @@ -25,6 +25,15 @@ config ADIS16480
> Say yes here to build support for Analog Devices ADIS16375, ADIS16480,
> ADIS16485, ADIS16488 inertial sensors.
>  
> +config KMX61
> + tristate "Kionix KMX61 6-axis accelerometer and magnetometer"
> + depends on I2C
> + help
> +   Say Y here if you want to build a driver for Kionix KMX61 6-axis
> +   accelerometer and magnetometer.
> +   To compile this driver as module, choose M here: the module will
> +   be called kmx61.
> +
>  source "drivers/iio/imu/inv_mpu6050/Kconfig"
>  
>  endmenu
> diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile
> index 114d2c1..e1e6e3d 100644
> --- a/drivers/iio/imu/Makefile
> +++ b/drivers/iio/imu/Makefile
> @@ -14,3 +14,5 @@ adis_lib-$(CONFIG_IIO_ADIS_LIB_BUFFER) += adis_buffer.o
>  obj-$(CONFIG_IIO_ADIS_LIB) += adis_lib.o
>  
>  obj-y += inv_mpu6050/
> +
> +obj-$(CONFIG_KMX61) += kmx61.o
> diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
> new file mode 100644
> index 000..5b44371
> --- /dev/null
> +++ b/drivers/iio/imu/kmx61.c
> @@ -0,0 +1,691 @@
> +/*
> + * KMX61 - Kionix 6-axis Accelerometer/Magnetometer
> + *
> + * Copyright (c) 2014, Intel Corporation.
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License.  See the file COPYING in the main
> + * directory of this archive for more details.
> + *
> + * IIO driver for KMX61 (7-bit I2C slave address 0x0E or 0x0F).
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define KMX61_DRV_NAME "kmx61"
> +
> +#define KMX61_REG_WHO_AM_I   0x00
> +
> +/*
> + * three 16-bit accelerometer output registers for X/Y/Z axis
> + * we use only XOUT_L as a base register, all other addresses
> + * can be obtained by applying an offset and are provided here
> + * only for clarity.
> + */
> +#define KMX61_ACC_XOUT_L 0x0A
> +#define KMX61_ACC_XOUT_H 0x0B
> +#define KMX61_ACC_YOUT_L 0x0C
> +#define KMX61_ACC_YOUT_H 0x0D
> +#define KMX61_ACC_ZOUT_L 0x0E
> +#define KMX61_ACC_ZOUT_H 0x0F
> +
> +/*
> + * one 16-bit temperature output register
> + */
> +#define KMX61_TEMP_L 0x10
> +#define KMX61_TEMP_H 0x11
> +
> +/*
> + * three 16-bit magnetometer output registers for X/Y/Z axis
> + */
> +#define KMX61_MAG_XOUT_L 0x12
> +#define KMX61_MAG_XOUT_H 0x13
> +#define KMX61_MAG_YOUT_L 0x14
> +#define KMX61_MAG_YOUT_H 0x15
> +#define KMX61_MAG_ZOUT_L 0x16
> +#define KMX61_MAG_ZOUT_H 0x17
> +
> +#define KMX61_REG_STBY   0x29
> +#define KMX61_REG_CTRL1  0x2A
> +#define KMX61_REG_ODCNTL 0x2C
> +
> +#define KMX61_ACC_STBY_BIT   BIT(0)
> +#define KMX61_MAG_STBY_BIT   BIT(1)
> +#define KMX61_ACT_STBY_BIT   BIT(7)
> +
> +#define KMX61_ALL_STBY   (KMX61_ACC_STBY_BIT | 
> KMX61_MAG_STBY_BIT)
> +
> +#define KMX61_REG_CTRL1_GSEL_MASK0x03
> +
> +#define KMX61_ACC_ODR_SHIFT  0
> +#define KMX61_MAG_ODR_SHIFT  4
> +#define KMX61_ACC_ODR_MASK   0x0F
> +#define KMX61_MAG_ODR_MASK   0xF0
> +
> +#define KMX61_CHIP_ID0x12
> +
> +/* KMX61 devices */
> +#define KMX61_ACC0x01
> +#define KMX61_MAG0x02
> +
> +struct kmx61_data {
> + struct i2c_client *client;
> +
> + /* serialize access to non-atomic ops, e.g set_mode */
> + struct mutex lock;
> +
> + /* standby state */
> + bool acc_stby;
> + bool mag_stby;
> +
> + /* config bits */
> + u8 range;
> + u8 odr_bits;
> +
> + /* accelerometer specific data */
> + struct iio_dev *acc_indio_dev;
> +
> + /* magnetometer specific data */
> + struct iio_dev *mag_indio_dev;
> +};
> +
> +enum kmx61_range {
> + KMX61_RANGE_2G,
> + KMX61_RANGE_4G,
> + KMX61_RANGE_8G,
> +};
> +
> +enum kmx61_axis {
> + KMX61_AXIS_X,
> + 

Re: [PATCH 4/4] iio: dht11: Fix out-of-bounds read

[Hartmut Knaack]

Richard Weinberger schrieb am 03.12.2014 um 00:32:
> As we access i-1 we must not start with i=0.
> 
> Signed-off-by: Richard Weinberger 
Acked-by: Hartmut Knaack 
> ---
>  drivers/iio/humidity/dht11.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht11.c
> index fbcd7cb..5dfe71b 100644
> --- a/drivers/iio/humidity/dht11.c
> +++ b/drivers/iio/humidity/dht11.c
> @@ -90,7 +90,7 @@ static int dht11_decode(struct dht11 *dht11, int offset)
>   unsigned char temp_int, temp_dec, hum_int, hum_dec, checksum;
>  
>   /* Calculate timestamp resolution */
> - for (i = 0; i < dht11->num_edges; ++i) {
> + for (i = 1; i < dht11->num_edges; ++i) {
>   t = dht11->edges[i].ts - dht11->edges[i-1].ts;
>   if (t > 0 && t < timeres)
>   timeres = t;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] iio: dht11: Add locking

[Hartmut Knaack]

Richard Weinberger schrieb am 03.12.2014 um 00:32:
> Make sure that the read function is not interrupted...
There is already a mutex iio_dev->info_exist_lock used to serialize
iio_channel_read(), which in turn accesses _read_raw(). See [1].

[1]http://lxr.free-electrons.com/ident?i=iio_channel_read
> 
> Signed-off-by: Richard Weinberger 
> ---
>  drivers/iio/humidity/dht11.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht11.c
> index d8771f5..168ebc4 100644
> --- a/drivers/iio/humidity/dht11.c
> +++ b/drivers/iio/humidity/dht11.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -57,6 +58,7 @@ struct dht11 {
>   int irq;
>  
>   struct completion   completion;
> + struct mutexlock;
>  
>   s64 timestamp;
>   int temperature;
> @@ -145,6 +147,7 @@ static int dht11_read_raw(struct iio_dev *iio_dev,
>   struct dht11 *dht11 = iio_priv(iio_dev);
>   int ret;
>  
> + mutex_lock(>lock);
>   if (dht11->timestamp + DHT11_DATA_VALID_TIME < iio_get_time_ns()) {
>   reinit_completion(>completion);
>  
> @@ -185,6 +188,7 @@ static int dht11_read_raw(struct iio_dev *iio_dev,
>   ret = -EINVAL;
>  err:
>   dht11->num_edges = -1;
> + mutex_unlock(>lock);
>   return ret;
>  }
>  
> @@ -268,6 +272,7 @@ static int dht11_probe(struct platform_device *pdev)
>   platform_set_drvdata(pdev, iio);
>  
>   init_completion(>completion);
> + mutex_init(>lock);
>   iio->name = pdev->name;
>   iio->dev.parent = >dev;
>   iio->info = _iio_info;
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] iio: dht11: Add locking

[Hartmut Knaack]

Richard Weinberger schrieb am 03.12.2014 um 00:32:
 Make sure that the read function is not interrupted...
There is already a mutex iio_dev-info_exist_lock used to serialize
iio_channel_read(), which in turn accesses _read_raw(). See [1].

[1]http://lxr.free-electrons.com/ident?i=iio_channel_read
 
 Signed-off-by: Richard Weinberger rich...@nod.at
 ---
  drivers/iio/humidity/dht11.c | 5 +
  1 file changed, 5 insertions(+)
 
 diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht11.c
 index d8771f5..168ebc4 100644
 --- a/drivers/iio/humidity/dht11.c
 +++ b/drivers/iio/humidity/dht11.c
 @@ -29,6 +29,7 @@
  #include linux/wait.h
  #include linux/bitops.h
  #include linux/completion.h
 +#include linux/mutex.h
  #include linux/delay.h
  #include linux/gpio.h
  #include linux/of_gpio.h
 @@ -57,6 +58,7 @@ struct dht11 {
   int irq;
  
   struct completion   completion;
 + struct mutexlock;
  
   s64 timestamp;
   int temperature;
 @@ -145,6 +147,7 @@ static int dht11_read_raw(struct iio_dev *iio_dev,
   struct dht11 *dht11 = iio_priv(iio_dev);
   int ret;
  
 + mutex_lock(dht11-lock);
   if (dht11-timestamp + DHT11_DATA_VALID_TIME  iio_get_time_ns()) {
   reinit_completion(dht11-completion);
  
 @@ -185,6 +188,7 @@ static int dht11_read_raw(struct iio_dev *iio_dev,
   ret = -EINVAL;
  err:
   dht11-num_edges = -1;
 + mutex_unlock(dht11-lock);
   return ret;
  }
  
 @@ -268,6 +272,7 @@ static int dht11_probe(struct platform_device *pdev)
   platform_set_drvdata(pdev, iio);
  
   init_completion(dht11-completion);
 + mutex_init(dht11-lock);
   iio-name = pdev-name;
   iio-dev.parent = pdev-dev;
   iio-info = dht11_iio_info;
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 4/4] iio: dht11: Fix out-of-bounds read

[Hartmut Knaack]

Richard Weinberger schrieb am 03.12.2014 um 00:32:
 As we access i-1 we must not start with i=0.
 
 Signed-off-by: Richard Weinberger rich...@nod.at
Acked-by: Hartmut Knaack knaac...@gmx.de
 ---
  drivers/iio/humidity/dht11.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/iio/humidity/dht11.c b/drivers/iio/humidity/dht11.c
 index fbcd7cb..5dfe71b 100644
 --- a/drivers/iio/humidity/dht11.c
 +++ b/drivers/iio/humidity/dht11.c
 @@ -90,7 +90,7 @@ static int dht11_decode(struct dht11 *dht11, int offset)
   unsigned char temp_int, temp_dec, hum_int, hum_dec, checksum;
  
   /* Calculate timestamp resolution */
 - for (i = 0; i  dht11-num_edges; ++i) {
 + for (i = 1; i  dht11-num_edges; ++i) {
   t = dht11-edges[i].ts - dht11-edges[i-1].ts;
   if (t  0  t  timeres)
   timeres = t;
 

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/6] iio: imu: Add support for Kionix KMX61 sensor

[Hartmut Knaack]

Daniel Baluta schrieb am 03.12.2014 um 14:31:
 Minimal implementation for KMX61 6-axis accelerometer/magnetometer. It exports
 raw accel/magn readings together with scale and sampling frequency.
 
 This driver uses two IIO devices one for accelerometer and one for 
 magnetometer.
 
Hi Daniel,
I think you dropped slightly too much code. In kmx61_set_odr() you stored the 
set
odr bits in data-odr_bits previously, but now it's gone. But kmx61_get_odr()
accesses data-odr_bits, which now remains in the state from driver 
initialization.
Other than that, it's looking good.
Thanks,

Hartmut
 Datasheet will be available at:
 http://www.kionix.com/6-axis-accelerometer-magnetometer/kmx61
 
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
  drivers/iio/imu/Kconfig  |   9 +
  drivers/iio/imu/Makefile |   2 +
  drivers/iio/imu/kmx61.c  | 691 
 +++
  3 files changed, 702 insertions(+)
  create mode 100644 drivers/iio/imu/kmx61.c
 
 diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
 index 2b0e451..db4221d 100644
 --- a/drivers/iio/imu/Kconfig
 +++ b/drivers/iio/imu/Kconfig
 @@ -25,6 +25,15 @@ config ADIS16480
 Say yes here to build support for Analog Devices ADIS16375, ADIS16480,
 ADIS16485, ADIS16488 inertial sensors.
  
 +config KMX61
 + tristate Kionix KMX61 6-axis accelerometer and magnetometer
 + depends on I2C
 + help
 +   Say Y here if you want to build a driver for Kionix KMX61 6-axis
 +   accelerometer and magnetometer.
 +   To compile this driver as module, choose M here: the module will
 +   be called kmx61.
 +
  source drivers/iio/imu/inv_mpu6050/Kconfig
  
  endmenu
 diff --git a/drivers/iio/imu/Makefile b/drivers/iio/imu/Makefile
 index 114d2c1..e1e6e3d 100644
 --- a/drivers/iio/imu/Makefile
 +++ b/drivers/iio/imu/Makefile
 @@ -14,3 +14,5 @@ adis_lib-$(CONFIG_IIO_ADIS_LIB_BUFFER) += adis_buffer.o
  obj-$(CONFIG_IIO_ADIS_LIB) += adis_lib.o
  
  obj-y += inv_mpu6050/
 +
 +obj-$(CONFIG_KMX61) += kmx61.o
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 new file mode 100644
 index 000..5b44371
 --- /dev/null
 +++ b/drivers/iio/imu/kmx61.c
 @@ -0,0 +1,691 @@
 +/*
 + * KMX61 - Kionix 6-axis Accelerometer/Magnetometer
 + *
 + * Copyright (c) 2014, Intel Corporation.
 + *
 + * This file is subject to the terms and conditions of version 2 of
 + * the GNU General Public License.  See the file COPYING in the main
 + * directory of this archive for more details.
 + *
 + * IIO driver for KMX61 (7-bit I2C slave address 0x0E or 0x0F).
 + *
 + */
 +
 +#include linux/module.h
 +#include linux/i2c.h
 +#include linux/iio/iio.h
 +#include linux/iio/sysfs.h
 +
 +#define KMX61_DRV_NAME kmx61
 +
 +#define KMX61_REG_WHO_AM_I   0x00
 +
 +/*
 + * three 16-bit accelerometer output registers for X/Y/Z axis
 + * we use only XOUT_L as a base register, all other addresses
 + * can be obtained by applying an offset and are provided here
 + * only for clarity.
 + */
 +#define KMX61_ACC_XOUT_L 0x0A
 +#define KMX61_ACC_XOUT_H 0x0B
 +#define KMX61_ACC_YOUT_L 0x0C
 +#define KMX61_ACC_YOUT_H 0x0D
 +#define KMX61_ACC_ZOUT_L 0x0E
 +#define KMX61_ACC_ZOUT_H 0x0F
 +
 +/*
 + * one 16-bit temperature output register
 + */
 +#define KMX61_TEMP_L 0x10
 +#define KMX61_TEMP_H 0x11
 +
 +/*
 + * three 16-bit magnetometer output registers for X/Y/Z axis
 + */
 +#define KMX61_MAG_XOUT_L 0x12
 +#define KMX61_MAG_XOUT_H 0x13
 +#define KMX61_MAG_YOUT_L 0x14
 +#define KMX61_MAG_YOUT_H 0x15
 +#define KMX61_MAG_ZOUT_L 0x16
 +#define KMX61_MAG_ZOUT_H 0x17
 +
 +#define KMX61_REG_STBY   0x29
 +#define KMX61_REG_CTRL1  0x2A
 +#define KMX61_REG_ODCNTL 0x2C
 +
 +#define KMX61_ACC_STBY_BIT   BIT(0)
 +#define KMX61_MAG_STBY_BIT   BIT(1)
 +#define KMX61_ACT_STBY_BIT   BIT(7)
 +
 +#define KMX61_ALL_STBY   (KMX61_ACC_STBY_BIT | 
 KMX61_MAG_STBY_BIT)
 +
 +#define KMX61_REG_CTRL1_GSEL_MASK0x03
 +
 +#define KMX61_ACC_ODR_SHIFT  0
 +#define KMX61_MAG_ODR_SHIFT  4
 +#define KMX61_ACC_ODR_MASK   0x0F
 +#define KMX61_MAG_ODR_MASK   0xF0
 +
 +#define KMX61_CHIP_ID0x12
 +
 +/* KMX61 devices */
 +#define KMX61_ACC0x01
 +#define KMX61_MAG0x02
 +
 +struct kmx61_data {
 + struct i2c_client *client;
 +
 + /* serialize access to non-atomic ops, e.g set_mode */
 + struct mutex lock;
 +
 + /* standby state */
 + bool acc_stby;
 + bool mag_stby;
 +
 + /* config bits */
 + u8 range;
 + u8 odr_bits;
 +
 + /* accelerometer specific data */
 + struct iio_dev *acc_indio_dev;
 +
 + /* magnetometer specific data */
 + struct iio_dev *mag_indio_dev;
 +};
 +
 +enum kmx61_range {
 + KMX61_RANGE_2G,
 + KMX61_RANGE_4G,
 + KMX61_RANGE_8G,
 +};
 +
 +enum kmx61_axis {
 + KMX61_AXIS_X,
 + KMX61_AXIS_Y,
 + KMX61_AXIS_Z,
 +};
 +
 +u16 kmx61_uscale_table[] = {9582, 19163, 

Re: [PATCH v4 3/6] iio: imu: kmx61: Add PM runtime support

[Hartmut Knaack]

Daniel Baluta schrieb am 03.12.2014 um 14:31:
 By default both sensors are ACTIVE, in this way the driver
 will work even if CONFIG_PM_RUNTIME is not selected.
 
Since kmx61_set_power_state() can return error codes, wouldn't it be better to
handle them (as long as you are not using it in an error handler)?
Thanks,

Hartmut
 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
  drivers/iio/imu/kmx61.c | 114 
 +++-
  1 file changed, 112 insertions(+), 2 deletions(-)
 
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index 893f7c8..7536043 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -15,6 +15,8 @@
  #include linux/i2c.h
  #include linux/acpi.h
  #include linux/gpio/consumer.h
 +#include linux/interrupt.h
 +#include linux/pm_runtime.h
  #include linux/iio/iio.h
  #include linux/iio/sysfs.h
  
 @@ -69,6 +71,8 @@
  #define KMX61_ACC_ODR_MASK   0x0F
  #define KMX61_MAG_ODR_MASK   0xF0
  
 +#define KMX61_SLEEP_DELAY_MS 2000
 +
  #define KMX61_CHIP_ID0x12
  
  /* KMX61 devices */
 @@ -85,6 +89,10 @@ struct kmx61_data {
   bool acc_stby;
   bool mag_stby;
  
 + /* power state */
 + bool acc_ps;
 + bool mag_ps;
 +
   /* config bits */
   u8 range;
   u8 odr_bits;
 @@ -457,6 +465,58 @@ static int kmx61_chip_init(struct kmx61_data *data)
   return 0;
  }
  
 +/**
 + * kmx61_set_power_state() - set power state for kmx61 @device
 + * @data - kmx61 device private pointer
 + * @on - power state to be set for @device
 + * @device - bitmask indicating device for which @on state needs to be set
 + *
 + * Notice that when ACC power state needs to be set to ON and MAG is in
 + * OPERATION then we know that kmx61_runtime_resume was already called
 + * so we must set ACC OPERATION mode here. The same happens when MAG power
 + * state needs to be set to ON and ACC is in OPERATION.
 + */
 +static int kmx61_set_power_state(struct kmx61_data *data, bool on, u8 device)
 +{
 +#ifdef CONFIG_PM_RUNTIME
 + int ret;
 +
 + if (device  KMX61_ACC) {
 + if (on  !data-acc_ps  !data-mag_stby) {
 + ret = kmx61_set_mode(data, 0, KMX61_ACC, true);
 + if (ret  0)
 + return ret;
 + }
 + data-acc_ps = on;
 + }
 + if (device  KMX61_MAG) {
 + if (on  !data-mag_ps  !data-acc_stby) {
 + ret = kmx61_set_mode(data, 0, KMX61_MAG, true);
 + if (ret  0)
 + return ret;
 + }
 + data-mag_ps = on;
 + }
 +
 + if (on) {
 + ret = pm_runtime_get_sync(data-client-dev);
 + } else {
 + pm_runtime_mark_last_busy(data-client-dev);
 + ret = pm_runtime_put_autosuspend(data-client-dev);
 + }
 + if (ret  0) {
 + dev_err(data-client-dev,
 + Failed: kmx61_set_power_state for %d, ret %d\n,
 + on, ret);
 + if (on)
 + pm_runtime_put_noidle(data-client-dev);
 +
 + return ret;
 + }
 +#endif
 + return 0;
 +}
 +
  static int kmx61_read_measurement(struct kmx61_data *data, u8 base, u8 
 offset)
  {
   int ret;
 @@ -491,13 +551,16 @@ static int kmx61_read_raw(struct iio_dev *indio_dev,
   }
   mutex_lock(data-lock);
  
 + kmx61_set_power_state(data, true, chan-address);
   ret = kmx61_read_measurement(data, base_reg, chan-scan_index);
   if (ret  0) {
 + kmx61_set_power_state(data, false, chan-address);
   mutex_unlock(data-lock);
   return ret;
   }
   *val = sign_extend32(ret  chan-scan_type.shift,
chan-scan_type.realbits - 1);
 + kmx61_set_power_state(data, false, chan-address);
  
   mutex_unlock(data-lock);
   return IIO_VAL_INT;
 @@ -693,12 +756,22 @@ static int kmx61_probe(struct i2c_client *client,
   ret = iio_device_register(data-mag_indio_dev);
   if (ret  0) {
   dev_err(client-dev, Failed to register mag iio device\n);
 - goto err_iio_unregister;
 + goto err_iio_unregister_acc;
   }
  
 + ret = pm_runtime_set_active(client-dev);
 + if (ret  0)
 + goto err_iio_unregister_mag;
 +
 + pm_runtime_enable(client-dev);
 + pm_runtime_set_autosuspend_delay(client-dev, KMX61_SLEEP_DELAY_MS);
 + pm_runtime_use_autosuspend(client-dev);
 +
   return 0;
  
 -err_iio_unregister:
 +err_iio_unregister_mag:
 + iio_device_unregister(data-mag_indio_dev);
 +err_iio_unregister_acc:
   iio_device_unregister(data-acc_indio_dev);
  err_chip_uninit:
   kmx61_set_mode(data, KMX61_ALL_STBY, KMX61_ACC | KMX61_MAG, true);
 @@ -709,6 +782,10 @@ static int kmx61_remove(struct 

Re: [PATCH v4 5/6] iio: imu: kmx61: Add support for data ready triggers

[Hartmut Knaack]

Daniel Baluta schrieb am 03.12.2014 um 14:31:
 This creates a data ready trigger per IIO device.
 
I found some issues here, and some recommendations. See inline.

 Signed-off-by: Daniel Baluta daniel.bal...@intel.com
 ---
  drivers/iio/imu/Kconfig |   2 +
  drivers/iio/imu/kmx61.c | 295 
 +++-
  2 files changed, 296 insertions(+), 1 deletion(-)
 
 diff --git a/drivers/iio/imu/Kconfig b/drivers/iio/imu/Kconfig
 index db4221d..5e610f7 100644
 --- a/drivers/iio/imu/Kconfig
 +++ b/drivers/iio/imu/Kconfig
 @@ -28,6 +28,8 @@ config ADIS16480
  config KMX61
   tristate Kionix KMX61 6-axis accelerometer and magnetometer
   depends on I2C
 + select IIO_BUFFER
 + select IIO_TRIGGERED_BUFFER
   help
 Say Y here if you want to build a driver for Kionix KMX61 6-axis
 accelerometer and magnetometer.
 diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
 index f69ae5a7..0f6816a 100644
 --- a/drivers/iio/imu/kmx61.c
 +++ b/drivers/iio/imu/kmx61.c
 @@ -20,9 +20,14 @@
  #include linux/pm_runtime.h
  #include linux/iio/iio.h
  #include linux/iio/sysfs.h
 +#include linux/iio/trigger.h
 +#include linux/iio/buffer.h
 +#include linux/iio/triggered_buffer.h
 +#include linux/iio/trigger_consumer.h
  
  #define KMX61_DRV_NAME kmx61
  #define KMX61_GPIO_NAME kmx61_int
 +#define KMX61_IRQ_NAME kmx61_event
  
  #define KMX61_REG_WHO_AM_I   0x00
  
 @@ -55,9 +60,11 @@
  #define KMX61_MAG_ZOUT_L 0x16
  #define KMX61_MAG_ZOUT_H 0x17
  
 +#define KMX61_REG_INL0x28
  #define KMX61_REG_STBY   0x29
  #define KMX61_REG_CTRL1  0x2A
  #define KMX61_REG_ODCNTL 0x2C
 +#define KMX61_REG_INC1   0x2D
  
  #define KMX61_ACC_STBY_BIT   BIT(0)
  #define KMX61_MAG_STBY_BIT   BIT(1)
 @@ -67,6 +74,13 @@
  
  #define KMX61_REG_CTRL1_GSEL_MASK0x03
  
 +#define KMX61_REG_CTRL1_BIT_RES  BIT(4)
 +#define KMX61_REG_CTRL1_BIT_DRDYEBIT(5)
 +
 +#define KMX61_REG_INC1_BIT_DRDYM BIT(1)
 +#define KMX61_REG_INC1_BIT_DRDYA BIT(2)
 +#define KMX61_REG_INC1_BIT_IEN   BIT(5)
 +
  #define KMX61_ACC_ODR_SHIFT  0
  #define KMX61_MAG_ODR_SHIFT  4
  #define KMX61_ACC_ODR_MASK   0x0F
 @@ -100,9 +114,13 @@ struct kmx61_data {
  
   /* accelerometer specific data */
   struct iio_dev *acc_indio_dev;
 + struct iio_trigger *acc_dready_trig;
 + bool acc_dready_trig_on;
  
   /* magnetometer specific data */
   struct iio_dev *mag_indio_dev;
 + struct iio_trigger *mag_dready_trig;
 + bool mag_dready_trig_on;
  };
  
  enum kmx61_range {
 @@ -466,6 +484,69 @@ static int kmx61_chip_init(struct kmx61_data *data)
   return 0;
  }
  
 +static int kmx61_setup_new_data_interrupt(struct kmx61_data *data,
 +   bool status, u8 device)
 +{
 + u8 mode;
 + int ret;
 +
 + ret = kmx61_get_mode(data, mode, KMX61_ACC | KMX61_MAG);
 + if (ret  0)
 + return ret;
 +
 + ret = kmx61_set_mode(data, KMX61_ALL_STBY, KMX61_ACC | KMX61_MAG, true);
 + if (ret  0)
 + return ret;
 +
 + ret = i2c_smbus_read_byte_data(data-client, KMX61_REG_INC1);
 + if (ret  0) {
 + dev_err(data-client-dev, Error reading reg_ctrl1\n);
 + return ret;
 + }
 +
 + if (status) {
 + ret |= KMX61_REG_INC1_BIT_IEN;
 + if (device  KMX61_ACC)
 + ret |= KMX61_REG_INC1_BIT_DRDYA;
 + if (device  KMX61_MAG)
 + ret |=  KMX61_REG_INC1_BIT_DRDYM;
 + } else {
 + ret = ~KMX61_REG_INC1_BIT_IEN;
 + if (device  KMX61_ACC)
 + ret = ~KMX61_REG_INC1_BIT_DRDYA;
 + if (device  KMX61_MAG)
 + ret = ~KMX61_REG_INC1_BIT_DRDYM;
 + }
 + ret = i2c_smbus_write_byte_data(data-client, KMX61_REG_INC1, ret);
 + if (ret  0) {
 + dev_err(data-client-dev, Error writing reg_int_ctrl1\n);
 + return ret;
 + }
 +
 + ret = i2c_smbus_read_byte_data(data-client, KMX61_REG_CTRL1);
 + if (ret  0) {
 + dev_err(data-client-dev, Error reading reg_ctrl1\n);
 + return ret;
 + }
 +
 + if (status)
 + ret |= KMX61_REG_CTRL1_BIT_DRDYE;
 + else
 + ret = ~KMX61_REG_CTRL1_BIT_DRDYE;
 +
 + ret = i2c_smbus_write_byte_data(data-client, KMX61_REG_CTRL1, ret);
 + if (ret  0) {
 + dev_err(data-client-dev, Error writing reg_ctrl1\n);
 + return ret;
 + }
 +
 + ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
 + if (ret)
 + return ret;
 +
 + return 0;
No need to check ret here, could be simply: return kmx61_set_mode(...);
 +}
 +
  /**
   * kmx61_set_power_state() - set power state for kmx61 @device
   * @data - kmx61 device private pointer
 @@ -626,11 +707,34 @@ static int kmx61_write_raw(struct iio_dev *indio_dev,
   

Re: [PATCH v2 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Hartmut Knaack schrieb am 13.12.2014 um 12:18:
> Nikolaus Schulz schrieb am 12.12.2014 um 16:58:
>> On Sat, Dec 06, 2014 at 12:36:19PM +0100, Hartmut Knaack wrote:
>>> Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
>>>> The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
>>>> interface.
>>>>
>>>> Changes in v2:
>>>> * Use DMA-safe buffer for SPI transfer
>>>> * Normalize powerdown_mode name "hi-z" to "three_state" as per
>>>>   ABI/testing/sysfs-bus-iio
>>>> * Register device late in probe function
>>>> * Avoid powerdown broadcast update, which touches all DAC on the bus
>>> There are a few issues left, please see my comments inline.
>>>>
>>>> Signed-off-by: Nikolaus Schulz 
>>>> ---
>>>>  drivers/iio/dac/Kconfig  |  10 ++
>>>>  drivers/iio/dac/Makefile |   1 +
>>>>  drivers/iio/dac/ti-dac8554.c | 374 
>>>> +++
>>>>  3 files changed, 385 insertions(+)
>>>>  create mode 100644 drivers/iio/dac/ti-dac8554.c
>> [...]
>>>> diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
>>>> new file mode 100644
>>>> index 000..fca751f
>>>> --- /dev/null
>>>> +++ b/drivers/iio/dac/ti-dac8554.c
>>>> @@ -0,0 +1,374 @@
>>>> +/*
>>>> + * TI DAC8554 Digital to Analog Converter SPI driver
>>>> + *
>>>> + * Copyright (C) 2014 Avionic Design GmbH
>>>> + *
>>>> + * Based on ad5446r_spi.c
>>>> + * Copyright (C) 2010,2011 Analog Devices Inc.
>>>> + *
>>>> + * This program is free software; you can redistribute it and/or modify
>>>> + * it under the terms of the GNU General Public License version 2 as
>>>> + * published by the Free Software Foundation.
>>>> + */
>>>> +
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +#include 
>>>> +
>>>> +#define DAC8554_DRIVERNAME"ti-dac8554"
>>>> +#define DAC8554_DAC_CHANNELS  4
>>>> +
>>>> +/* Load commands */
>>>> +#define DAC8554_CMD_STORE_DAC_N   0x0
>>>> +#define DAC8554_CMD_UPDATE_DAC_N  0x1
>>>> +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL0x2
>>>> +#define DAC8554_CMD_UPDATE_BROADCAST  0x3
>>>> +
>>>> +#define DAC8554_BROADCAST_USE_SRDATA  0x2
>>> Add a blank line here.
>>
>> Fixed.
>>
>>>> +/* Powerdown modes (ORed PD1|PD2 bits) */
>>> It took my some time to figure out ORed. I think you could drop it and just
>>> mention (PD1 | PD2 bits).
>>
>> Agreed, and fixed.
>>
>>>> +#define DAC8554_PWRDN_HIZ 0x0
>>>> +#define DAC8554_PWRDN_1K  0x1
>>>> +#define DAC8554_PWRDN_100K0x2
>>>> +
>>>> +#define DAC8554_PWRDN_TO_SR(mode) (BIT(16) | (mode) << 14)
>>>> +
>>>> +/**
>>>> + * struct dac8554_state - driver instance specific data
>>>> + * @spi:  spi_device
>>> SPI device?
>>
>> Yes, fixed.
>>
>>>> + * @reg:  supply regulator
>>>> + * @addr: two-bit chip address
>>>> + * @vref_mv:  reference voltage in millivolt
>>>> + * @val   DAC/channel data
>>> DAC channel data?
>>
>> "channel data" will do, actually.
>>
>>>> + * @powerdown channel powerdown flag
>>>> + * @powerdown_modechannel powerdown mode
>>>> + * @xfer  SPI transfer buffer
>>> Half of the comments are with colon, the other half are missing it.
>>
>> Fixed.
>>
>>>> + */
>>>> +struct dac8554_state {
>>>> +  struct spi_device   *spi;
>>>> +  struct regulator*reg;
>>>> +  unsignedaddr;
>>>> +  unsignedvref_mv;
>>>> +  u16 val[DAC8554_DAC_CHANNELS];
>>>> +  boolpowerdown[DAC8554_DAC_CHANNELS];
>>>> +  u8  powerdown_mode[DAC8554_DAC_CHANNELS];
>>>> +
>>>> +  /*

Re: [PATCH v2 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Nikolaus Schulz schrieb am 12.12.2014 um 16:58:
> On Sat, Dec 06, 2014 at 12:36:19PM +0100, Hartmut Knaack wrote:
>> Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
>>> The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
>>> interface.
>>>
>>> Changes in v2:
>>> * Use DMA-safe buffer for SPI transfer
>>> * Normalize powerdown_mode name "hi-z" to "three_state" as per
>>>   ABI/testing/sysfs-bus-iio
>>> * Register device late in probe function
>>> * Avoid powerdown broadcast update, which touches all DAC on the bus
>> There are a few issues left, please see my comments inline.
>>>
>>> Signed-off-by: Nikolaus Schulz 
>>> ---
>>>  drivers/iio/dac/Kconfig  |  10 ++
>>>  drivers/iio/dac/Makefile |   1 +
>>>  drivers/iio/dac/ti-dac8554.c | 374 
>>> +++
>>>  3 files changed, 385 insertions(+)
>>>  create mode 100644 drivers/iio/dac/ti-dac8554.c
> [...]
>>> diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
>>> new file mode 100644
>>> index 000..fca751f
>>> --- /dev/null
>>> +++ b/drivers/iio/dac/ti-dac8554.c
>>> @@ -0,0 +1,374 @@
>>> +/*
>>> + * TI DAC8554 Digital to Analog Converter SPI driver
>>> + *
>>> + * Copyright (C) 2014 Avionic Design GmbH
>>> + *
>>> + * Based on ad5446r_spi.c
>>> + * Copyright (C) 2010,2011 Analog Devices Inc.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define DAC8554_DRIVERNAME "ti-dac8554"
>>> +#define DAC8554_DAC_CHANNELS   4
>>> +
>>> +/* Load commands */
>>> +#define DAC8554_CMD_STORE_DAC_N0x0
>>> +#define DAC8554_CMD_UPDATE_DAC_N   0x1
>>> +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL 0x2
>>> +#define DAC8554_CMD_UPDATE_BROADCAST   0x3
>>> +
>>> +#define DAC8554_BROADCAST_USE_SRDATA   0x2
>> Add a blank line here.
> 
> Fixed.
> 
>>> +/* Powerdown modes (ORed PD1|PD2 bits) */
>> It took my some time to figure out ORed. I think you could drop it and just
>> mention (PD1 | PD2 bits).
> 
> Agreed, and fixed.
> 
>>> +#define DAC8554_PWRDN_HIZ  0x0
>>> +#define DAC8554_PWRDN_1K   0x1
>>> +#define DAC8554_PWRDN_100K 0x2
>>> +
>>> +#define DAC8554_PWRDN_TO_SR(mode)  (BIT(16) | (mode) << 14)
>>> +
>>> +/**
>>> + * struct dac8554_state - driver instance specific data
>>> + * @spi:   spi_device
>> SPI device?
> 
> Yes, fixed.
> 
>>> + * @reg:   supply regulator
>>> + * @addr:  two-bit chip address
>>> + * @vref_mv:   reference voltage in millivolt
>>> + * @valDAC/channel data
>> DAC channel data?
> 
> "channel data" will do, actually.
> 
>>> + * @powerdown  channel powerdown flag
>>> + * @powerdown_mode channel powerdown mode
>>> + * @xfer   SPI transfer buffer
>> Half of the comments are with colon, the other half are missing it.
> 
> Fixed.
> 
>>> + */
>>> +struct dac8554_state {
>>> +   struct spi_device   *spi;
>>> +   struct regulator*reg;
>>> +   unsignedaddr;
>>> +   unsignedvref_mv;
>>> +   u16 val[DAC8554_DAC_CHANNELS];
>>> +   boolpowerdown[DAC8554_DAC_CHANNELS];
>>> +   u8  powerdown_mode[DAC8554_DAC_CHANNELS];
>>> +
>>> +   /*
>>> +* DMA (thus cache coherency maintenance) requires the
>>> +* transfer buffers to live in their own cache lines.
>>> +*/
>>> +   u8  xfer[3] cacheline_aligned;
>>> +};
>>> +
>>> +static int dac8554_spi_write(struct dac8554_state *st,
>>> +unsigned cmd,
>>> +unsigned chan_addr,
>>> 

Re: [PATCH v2 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Nikolaus Schulz schrieb am 12.12.2014 um 16:58:
 On Sat, Dec 06, 2014 at 12:36:19PM +0100, Hartmut Knaack wrote:
 Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
 The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
 interface.

 Changes in v2:
 * Use DMA-safe buffer for SPI transfer
 * Normalize powerdown_mode name hi-z to three_state as per
   ABI/testing/sysfs-bus-iio
 * Register device late in probe function
 * Avoid powerdown broadcast update, which touches all DAC on the bus
 There are a few issues left, please see my comments inline.

 Signed-off-by: Nikolaus Schulz nikolaus.sch...@avionic-design.de
 ---
  drivers/iio/dac/Kconfig  |  10 ++
  drivers/iio/dac/Makefile |   1 +
  drivers/iio/dac/ti-dac8554.c | 374 
 +++
  3 files changed, 385 insertions(+)
  create mode 100644 drivers/iio/dac/ti-dac8554.c
 [...]
 diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
 new file mode 100644
 index 000..fca751f
 --- /dev/null
 +++ b/drivers/iio/dac/ti-dac8554.c
 @@ -0,0 +1,374 @@
 +/*
 + * TI DAC8554 Digital to Analog Converter SPI driver
 + *
 + * Copyright (C) 2014 Avionic Design GmbH
 + *
 + * Based on ad5446r_spi.c
 + * Copyright (C) 2010,2011 Analog Devices Inc.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/spi/spi.h
 +#include linux/regulator/consumer.h
 +#include linux/module.h
 +#include linux/iio/iio.h
 +#include linux/of.h
 +
 +#define DAC8554_DRIVERNAME ti-dac8554
 +#define DAC8554_DAC_CHANNELS   4
 +
 +/* Load commands */
 +#define DAC8554_CMD_STORE_DAC_N0x0
 +#define DAC8554_CMD_UPDATE_DAC_N   0x1
 +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL 0x2
 +#define DAC8554_CMD_UPDATE_BROADCAST   0x3
 +
 +#define DAC8554_BROADCAST_USE_SRDATA   0x2
 Add a blank line here.
 
 Fixed.
 
 +/* Powerdown modes (ORed PD1|PD2 bits) */
 It took my some time to figure out ORed. I think you could drop it and just
 mention (PD1 | PD2 bits).
 
 Agreed, and fixed.
 
 +#define DAC8554_PWRDN_HIZ  0x0
 +#define DAC8554_PWRDN_1K   0x1
 +#define DAC8554_PWRDN_100K 0x2
 +
 +#define DAC8554_PWRDN_TO_SR(mode)  (BIT(16) | (mode)  14)
 +
 +/**
 + * struct dac8554_state - driver instance specific data
 + * @spi:   spi_device
 SPI device?
 
 Yes, fixed.
 
 + * @reg:   supply regulator
 + * @addr:  two-bit chip address
 + * @vref_mv:   reference voltage in millivolt
 + * @valDAC/channel data
 DAC channel data?
 
 channel data will do, actually.
 
 + * @powerdown  channel powerdown flag
 + * @powerdown_mode channel powerdown mode
 + * @xfer   SPI transfer buffer
 Half of the comments are with colon, the other half are missing it.
 
 Fixed.
 
 + */
 +struct dac8554_state {
 +   struct spi_device   *spi;
 +   struct regulator*reg;
 +   unsignedaddr;
 +   unsignedvref_mv;
 +   u16 val[DAC8554_DAC_CHANNELS];
 +   boolpowerdown[DAC8554_DAC_CHANNELS];
 +   u8  powerdown_mode[DAC8554_DAC_CHANNELS];
 +
 +   /*
 +* DMA (thus cache coherency maintenance) requires the
 +* transfer buffers to live in their own cache lines.
 +*/
 +   u8  xfer[3] cacheline_aligned;
 +};
 +
 +static int dac8554_spi_write(struct dac8554_state *st,
 +unsigned cmd,
 +unsigned chan_addr,
 +unsigned val)
 +{
 +   u32 data;
 +
 +   /*
 +* The input shift register is 24 bits wide. The 8 MSB are
 +* control bits, followed by 16 data bits.
 +* The first two bits A1 and A0 address a DAC8554 chip.
 +* The next two are the command bits, LD1 and LD0.
 +* After a don't-care-bit, the next two bits select the channel.
 +* The final control bit PD0 is a flag signalling if the data
 +* bits encode a powerdown mode. We merge PD0 with the adjacent
 +* data bits.
 +*/
 +
 +   if (cmd  3 || chan_addr  3 ||
 +   (val  0x  (val  ~DAC8554_PWRDN_TO_SR(3
 +   return -EINVAL;
 +
 +   data =st-addr  22) | (cmd  20) | (chan_addr  17) | val;
 Could be more readable by using definition for the magic shifts, or macros.
 
 Hmm. The magic is all concentrated at this place, and the variable names
 tell the story, so I figured that's ok.  But, why not: fixed.
 
 +   st-xfer[0] =ata  16;
 +   st-xfer[1] =ata  8;
 +   st-xfer[2] =ata;
 +
 +   return spi_write(st-spi, st-xfer, sizeof(st-xfer));
 +}
 +
 +static int dac8554_read_raw(struct iio_dev *indio_dev

Re: [PATCH v2 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Hartmut Knaack schrieb am 13.12.2014 um 12:18:
 Nikolaus Schulz schrieb am 12.12.2014 um 16:58:
 On Sat, Dec 06, 2014 at 12:36:19PM +0100, Hartmut Knaack wrote:
 Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
 The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
 interface.

 Changes in v2:
 * Use DMA-safe buffer for SPI transfer
 * Normalize powerdown_mode name hi-z to three_state as per
   ABI/testing/sysfs-bus-iio
 * Register device late in probe function
 * Avoid powerdown broadcast update, which touches all DAC on the bus
 There are a few issues left, please see my comments inline.

 Signed-off-by: Nikolaus Schulz nikolaus.sch...@avionic-design.de
 ---
  drivers/iio/dac/Kconfig  |  10 ++
  drivers/iio/dac/Makefile |   1 +
  drivers/iio/dac/ti-dac8554.c | 374 
 +++
  3 files changed, 385 insertions(+)
  create mode 100644 drivers/iio/dac/ti-dac8554.c
 [...]
 diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
 new file mode 100644
 index 000..fca751f
 --- /dev/null
 +++ b/drivers/iio/dac/ti-dac8554.c
 @@ -0,0 +1,374 @@
 +/*
 + * TI DAC8554 Digital to Analog Converter SPI driver
 + *
 + * Copyright (C) 2014 Avionic Design GmbH
 + *
 + * Based on ad5446r_spi.c
 + * Copyright (C) 2010,2011 Analog Devices Inc.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/spi/spi.h
 +#include linux/regulator/consumer.h
 +#include linux/module.h
 +#include linux/iio/iio.h
 +#include linux/of.h
 +
 +#define DAC8554_DRIVERNAMEti-dac8554
 +#define DAC8554_DAC_CHANNELS  4
 +
 +/* Load commands */
 +#define DAC8554_CMD_STORE_DAC_N   0x0
 +#define DAC8554_CMD_UPDATE_DAC_N  0x1
 +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL0x2
 +#define DAC8554_CMD_UPDATE_BROADCAST  0x3
 +
 +#define DAC8554_BROADCAST_USE_SRDATA  0x2
 Add a blank line here.

 Fixed.

 +/* Powerdown modes (ORed PD1|PD2 bits) */
 It took my some time to figure out ORed. I think you could drop it and just
 mention (PD1 | PD2 bits).

 Agreed, and fixed.

 +#define DAC8554_PWRDN_HIZ 0x0
 +#define DAC8554_PWRDN_1K  0x1
 +#define DAC8554_PWRDN_100K0x2
 +
 +#define DAC8554_PWRDN_TO_SR(mode) (BIT(16) | (mode)  14)
 +
 +/**
 + * struct dac8554_state - driver instance specific data
 + * @spi:  spi_device
 SPI device?

 Yes, fixed.

 + * @reg:  supply regulator
 + * @addr: two-bit chip address
 + * @vref_mv:  reference voltage in millivolt
 + * @val   DAC/channel data
 DAC channel data?

 channel data will do, actually.

 + * @powerdown channel powerdown flag
 + * @powerdown_modechannel powerdown mode
 + * @xfer  SPI transfer buffer
 Half of the comments are with colon, the other half are missing it.

 Fixed.

 + */
 +struct dac8554_state {
 +  struct spi_device   *spi;
 +  struct regulator*reg;
 +  unsignedaddr;
 +  unsignedvref_mv;
 +  u16 val[DAC8554_DAC_CHANNELS];
 +  boolpowerdown[DAC8554_DAC_CHANNELS];
 +  u8  powerdown_mode[DAC8554_DAC_CHANNELS];
 +
 +  /*
 +   * DMA (thus cache coherency maintenance) requires the
 +   * transfer buffers to live in their own cache lines.
 +   */
 +  u8  xfer[3] cacheline_aligned;
 +};
 +
 +static int dac8554_spi_write(struct dac8554_state *st,
 +   unsigned cmd,
 +   unsigned chan_addr,
 +   unsigned val)
 +{
 +  u32 data;
 +
 +  /*
 +   * The input shift register is 24 bits wide. The 8 MSB are
 +   * control bits, followed by 16 data bits.
 +   * The first two bits A1 and A0 address a DAC8554 chip.
 +   * The next two are the command bits, LD1 and LD0.
 +   * After a don't-care-bit, the next two bits select the channel.
 +   * The final control bit PD0 is a flag signalling if the data
 +   * bits encode a powerdown mode. We merge PD0 with the adjacent
 +   * data bits.
 +   */
 +
 +  if (cmd  3 || chan_addr  3 ||
 +  (val  0x  (val  ~DAC8554_PWRDN_TO_SR(3
 +  return -EINVAL;
 +
 +  data =st-addr  22) | (cmd  20) | (chan_addr  17) | val;
 Could be more readable by using definition for the magic shifts, or macros.

 Hmm. The magic is all concentrated at this place, and the variable names
 tell the story, so I figured that's ok.  But, why not: fixed.

 +  st-xfer[0] =ata  16;
 +  st-xfer[1] =ata  8;
 +  st-xfer[2] =ata;
 +
 +  return spi_write(st-spi, st-xfer, sizeof(st-xfer));
 +}
 +
 +static int dac8554_read_raw(struct iio_dev *indio_dev

Re: [PATCH v2 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
> The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
> interface.
> 
> Changes in v2:
> * Use DMA-safe buffer for SPI transfer
> * Normalize powerdown_mode name "hi-z" to "three_state" as per
>   ABI/testing/sysfs-bus-iio
> * Register device late in probe function
> * Avoid powerdown broadcast update, which touches all DAC on the bus
There are a few issues left, please see my comments inline.
> 
> Signed-off-by: Nikolaus Schulz 
> ---
>  drivers/iio/dac/Kconfig  |  10 ++
>  drivers/iio/dac/Makefile |   1 +
>  drivers/iio/dac/ti-dac8554.c | 374 
> +++
>  3 files changed, 385 insertions(+)
>  create mode 100644 drivers/iio/dac/ti-dac8554.c
> 
> diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
> index 2236ea2..1689260 100644
> --- a/drivers/iio/dac/Kconfig
> +++ b/drivers/iio/dac/Kconfig
> @@ -181,4 +181,14 @@ config MCP4922
> To compile this driver as a module, choose M here: the module
> will be called mcp4922.
>  
> +config TI_DAC8554
> + tristate "TI DAC8554 driver"
> + depends on SPI
> + depends on OF
> + help
> +   Say yes here to build the driver for the TI DAC8554.
> +
> +   To compile this driver as a module, choose M here: the module
> +   will be called ti-dac8554.
> +
>  endmenu
> diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
> index 52be7e1..b98d79a 100644
> --- a/drivers/iio/dac/Makefile
> +++ b/drivers/iio/dac/Makefile
> @@ -20,3 +20,4 @@ obj-$(CONFIG_MAX517) += max517.o
>  obj-$(CONFIG_MAX5821) += max5821.o
>  obj-$(CONFIG_MCP4725) += mcp4725.o
>  obj-$(CONFIG_MCP4922) += mcp4922.o
> +obj-$(CONFIG_TI_DAC8554) += ti-dac8554.o
> diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
> new file mode 100644
> index 000..fca751f
> --- /dev/null
> +++ b/drivers/iio/dac/ti-dac8554.c
> @@ -0,0 +1,374 @@
> +/*
> + * TI DAC8554 Digital to Analog Converter SPI driver
> + *
> + * Copyright (C) 2014 Avionic Design GmbH
> + *
> + * Based on ad5446r_spi.c
> + * Copyright (C) 2010,2011 Analog Devices Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DAC8554_DRIVERNAME   "ti-dac8554"
> +#define DAC8554_DAC_CHANNELS 4
> +
> +/* Load commands */
> +#define DAC8554_CMD_STORE_DAC_N  0x0
> +#define DAC8554_CMD_UPDATE_DAC_N 0x1
> +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL   0x2
> +#define DAC8554_CMD_UPDATE_BROADCAST 0x3
> +
> +#define DAC8554_BROADCAST_USE_SRDATA 0x2
Add a blank line here.
> +/* Powerdown modes (ORed PD1|PD2 bits) */
It took my some time to figure out ORed. I think you could drop it and just
mention (PD1 | PD2 bits).
> +#define DAC8554_PWRDN_HIZ0x0
> +#define DAC8554_PWRDN_1K 0x1
> +#define DAC8554_PWRDN_100K   0x2
> +
> +#define DAC8554_PWRDN_TO_SR(mode)(BIT(16) | (mode) << 14)
> +
> +/**
> + * struct dac8554_state - driver instance specific data
> + * @spi: spi_device
SPI device?
> + * @reg: supply regulator
> + * @addr:two-bit chip address
> + * @vref_mv: reference voltage in millivolt
> + * @val  DAC/channel data
DAC channel data?
> + * @powerdownchannel powerdown flag
> + * @powerdown_mode   channel powerdown mode
> + * @xfer SPI transfer buffer
Half of the comments are with colon, the other half are missing it.
> + */
> +struct dac8554_state {
> + struct spi_device   *spi;
> + struct regulator*reg;
> + unsignedaddr;
> + unsignedvref_mv;
> + u16 val[DAC8554_DAC_CHANNELS];
> + boolpowerdown[DAC8554_DAC_CHANNELS];
> + u8  powerdown_mode[DAC8554_DAC_CHANNELS];
> +
> + /*
> +  * DMA (thus cache coherency maintenance) requires the
> +  * transfer buffers to live in their own cache lines.
> +  */
> + u8  xfer[3] cacheline_aligned;
> +};
> +
> +static int dac8554_spi_write(struct dac8554_state *st,
> +  unsigned cmd,
> +  unsigned chan_addr,
> +  unsigned val)
> +{
> + u32 data;
> +
> + /*
> +  * The input shift register is 24 bits wide. The 8 MSB are
> +  * control bits, followed by 16 data bits.
> +  * The first two bits A1 and A0 address a DAC8554 chip.
> +  * The next two are the command bits, LD1 and LD0.
> +  * After a don't-care-bit, the next two bits select the 

Re: [PATCH v2 2/2] iio: add driver for the TI DAC8554

[Hartmut Knaack]

Nikolaus Schulz schrieb am 24.11.2014 um 20:50:
 The TI DAC8554 is a quad-channel Digital-to-Analog Converter with an SPI
 interface.
 
 Changes in v2:
 * Use DMA-safe buffer for SPI transfer
 * Normalize powerdown_mode name hi-z to three_state as per
   ABI/testing/sysfs-bus-iio
 * Register device late in probe function
 * Avoid powerdown broadcast update, which touches all DAC on the bus
There are a few issues left, please see my comments inline.
 
 Signed-off-by: Nikolaus Schulz nikolaus.sch...@avionic-design.de
 ---
  drivers/iio/dac/Kconfig  |  10 ++
  drivers/iio/dac/Makefile |   1 +
  drivers/iio/dac/ti-dac8554.c | 374 
 +++
  3 files changed, 385 insertions(+)
  create mode 100644 drivers/iio/dac/ti-dac8554.c
 
 diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
 index 2236ea2..1689260 100644
 --- a/drivers/iio/dac/Kconfig
 +++ b/drivers/iio/dac/Kconfig
 @@ -181,4 +181,14 @@ config MCP4922
 To compile this driver as a module, choose M here: the module
 will be called mcp4922.
  
 +config TI_DAC8554
 + tristate TI DAC8554 driver
 + depends on SPI
 + depends on OF
 + help
 +   Say yes here to build the driver for the TI DAC8554.
 +
 +   To compile this driver as a module, choose M here: the module
 +   will be called ti-dac8554.
 +
  endmenu
 diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
 index 52be7e1..b98d79a 100644
 --- a/drivers/iio/dac/Makefile
 +++ b/drivers/iio/dac/Makefile
 @@ -20,3 +20,4 @@ obj-$(CONFIG_MAX517) += max517.o
  obj-$(CONFIG_MAX5821) += max5821.o
  obj-$(CONFIG_MCP4725) += mcp4725.o
  obj-$(CONFIG_MCP4922) += mcp4922.o
 +obj-$(CONFIG_TI_DAC8554) += ti-dac8554.o
 diff --git a/drivers/iio/dac/ti-dac8554.c b/drivers/iio/dac/ti-dac8554.c
 new file mode 100644
 index 000..fca751f
 --- /dev/null
 +++ b/drivers/iio/dac/ti-dac8554.c
 @@ -0,0 +1,374 @@
 +/*
 + * TI DAC8554 Digital to Analog Converter SPI driver
 + *
 + * Copyright (C) 2014 Avionic Design GmbH
 + *
 + * Based on ad5446r_spi.c
 + * Copyright (C) 2010,2011 Analog Devices Inc.
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/spi/spi.h
 +#include linux/regulator/consumer.h
 +#include linux/module.h
 +#include linux/iio/iio.h
 +#include linux/of.h
 +
 +#define DAC8554_DRIVERNAME   ti-dac8554
 +#define DAC8554_DAC_CHANNELS 4
 +
 +/* Load commands */
 +#define DAC8554_CMD_STORE_DAC_N  0x0
 +#define DAC8554_CMD_UPDATE_DAC_N 0x1
 +#define DAC8554_CMD_STORE_DAC_N_UPDATE_ALL   0x2
 +#define DAC8554_CMD_UPDATE_BROADCAST 0x3
 +
 +#define DAC8554_BROADCAST_USE_SRDATA 0x2
Add a blank line here.
 +/* Powerdown modes (ORed PD1|PD2 bits) */
It took my some time to figure out ORed. I think you could drop it and just
mention (PD1 | PD2 bits).
 +#define DAC8554_PWRDN_HIZ0x0
 +#define DAC8554_PWRDN_1K 0x1
 +#define DAC8554_PWRDN_100K   0x2
 +
 +#define DAC8554_PWRDN_TO_SR(mode)(BIT(16) | (mode)  14)
 +
 +/**
 + * struct dac8554_state - driver instance specific data
 + * @spi: spi_device
SPI device?
 + * @reg: supply regulator
 + * @addr:two-bit chip address
 + * @vref_mv: reference voltage in millivolt
 + * @val  DAC/channel data
DAC channel data?
 + * @powerdownchannel powerdown flag
 + * @powerdown_mode   channel powerdown mode
 + * @xfer SPI transfer buffer
Half of the comments are with colon, the other half are missing it.
 + */
 +struct dac8554_state {
 + struct spi_device   *spi;
 + struct regulator*reg;
 + unsignedaddr;
 + unsignedvref_mv;
 + u16 val[DAC8554_DAC_CHANNELS];
 + boolpowerdown[DAC8554_DAC_CHANNELS];
 + u8  powerdown_mode[DAC8554_DAC_CHANNELS];
 +
 + /*
 +  * DMA (thus cache coherency maintenance) requires the
 +  * transfer buffers to live in their own cache lines.
 +  */
 + u8  xfer[3] cacheline_aligned;
 +};
 +
 +static int dac8554_spi_write(struct dac8554_state *st,
 +  unsigned cmd,
 +  unsigned chan_addr,
 +  unsigned val)
 +{
 + u32 data;
 +
 + /*
 +  * The input shift register is 24 bits wide. The 8 MSB are
 +  * control bits, followed by 16 data bits.
 +  * The first two bits A1 and A0 address a DAC8554 chip.
 +  * The next two are the command bits, LD1 and LD0.
 +  * After a don't-care-bit, the next two bits select the channel.
 +  * The final