lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFA9rWMPpU3j4dYAQrofFL0PmTmKuOe28itQAMiuezrFc6k4=g@mail.gmail.com>
Date:	Mon, 3 Aug 2015 13:45:54 +0300
From:	Cristina Georgiana Opriceana <cristina.opriceana@...il.com>
To:	Hartmut Knaack <knaack.h@....de>
Cc:	Jonathan Cameron <jic23@...nel.org>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Peter Meerwald <pmeerw@...erw.net>,
	"linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
	linux-kernel@...r.kernel.org,
	Daniel Baluta <daniel.baluta@...el.com>
Subject: Re: [PATCH 2/6] iio: buffer: Fix kernel docs warnings

On Sun, Aug 2, 2015 at 10:46 PM, Hartmut Knaack <knaack.h@....de> wrote:
> 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.opriceana@...il.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?
>
I sent a patch changing the return value in case that no device is bound

Cristina
>>
>>>>   */
>>>>  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 majordomo@...r.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 majordomo@...r.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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ