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] [day] [month] [year] [list]
Message-ID: <4E9EE68F.6040506@metafoo.de>
Date:	Wed, 19 Oct 2011 17:02:39 +0200
From:	Lars-Peter Clausen <lars@...afoo.de>
To:	Jonathan Cameron <jic23@....ac.uk>
CC:	linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
	linus.ml.walleij@...il.com, zdevai@...il.com,
	linux@....linux.org.uk, arnd@...db.de,
	broonie@...nsource.wolfsonmicro.com, gregkh@...e.de
Subject: Re: [PATCH 3/6] IIO:CORE add global list of registered IIO devices.

On 10/19/2011 03:46 PM, Jonathan Cameron wrote:
> On 10/18/11 21:33, Jonathan Cameron wrote:
>> On 10/18/11 19:25, Lars-Peter Clausen wrote:
>>> On 10/18/2011 05:29 PM, Jonathan Cameron wrote:
>>>> Needed for inkernel interfaces.
>>>>
>>>
>>> The bus_type structure keeps a list of all devices registered on that bus, so
>>> you should be able to use bus_for_each_dev and bus_find_device for iterating
>>> over the iio devices.
>> I hadn't realised that but don't think it will work anyway. There are several
>> other things than iio_dev based devices that sit on our bus unfortunately.
>> None are in these initial merges but they will turn up later.
>> The most common are iio_triggers but there are also a few weird ones such
>> as the event generator for the dummy driver and the sysfstrig control device.  
>> We could play some games to allow these to be identified, but it's going
>> to be a mess. Probably easier to just maintain a second list as we are doing
>> here.  Interesting suggestion though. Thanks and feel free to point out if there
>> is a simple way around the identification issue.
> Actually looking into it this morning - this is trivial to do.
> We can just check that the device_type is set appropriately before doing anything
> else.
> 
> Thanks Lars-Peter your suggestion is should clean things up nicely.
> 
> New version coming up.

Yes, this should work. The device class iter functions already allow
filtering on the device type, so it might even make sense to add generic
device bus iterator functions which allow this as well, but this is probably
something for later.

>>>
>>>> Signed-off-by: Jonathan Cameron <jic23@....ac.uk>
>>>> ---
>>>>  drivers/iio/iio.c       |    9 +++++++++
>>>>  include/linux/iio/iio.h |    1 +
>>>>  2 files changed, 10 insertions(+), 0 deletions(-)
>>>>
>>>> diff --git a/drivers/iio/iio.c b/drivers/iio/iio.c
>>>> index 9e6acc1..246a093 100644
>>>> --- a/drivers/iio/iio.c
>>>> +++ b/drivers/iio/iio.c
>>>> @@ -15,6 +15,9 @@
>>>>  #include <linux/iio/iio.h>
>>>>  #include <linux/iio/sysfs.h>
>>>>  
>>>> +static DEFINE_MUTEX(iio_device_list_lock);
>>>> +static LIST_HEAD(iio_device_list);
>>>> +
>>>>  static DEFINE_IDA(iio_ida);
>>>>  
>>>>  static struct bus_type iio_bus_type = {
>>>> @@ -91,6 +94,9 @@ static void iio_dev_release(struct device *device)
>>>>  {
>>>>  	struct iio_dev *indio_dev = container_of(device, struct iio_dev, dev);
>>>>  	iio_device_unregister_sysfs(indio_dev);
>>>> +	mutex_lock(&iio_device_list_lock);
>>>> +	list_del(&indio_dev->dev_list_entry);
>>>> +	mutex_unlock(&iio_device_list_lock);
>>>>  }
>>>>  
>>>>  static struct device_type iio_dev_type = {
>>>> @@ -559,6 +565,9 @@ int iio_device_register(struct iio_dev *indio_dev)
>>>>  	if (ret)
>>>>  		goto error_free_sysfs;
>>>>  
>>>> +	mutex_lock(&iio_device_list_lock);
>>>> +	list_add(&indio_dev->dev_list_entry, &iio_device_list);
>>>> +	mutex_unlock(&iio_device_list_lock);
>>>>  	return 0;
>>>>  
>>>>  error_free_sysfs:
>>>> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
>>>> index beedc5c..f14e7dc 100644
>>>> --- a/include/linux/iio/iio.h
>>>> +++ b/include/linux/iio/iio.h
>>>> @@ -192,6 +192,7 @@ struct iio_info {
>>>>   * @info:		[DRIVER] callbacks and constant info from driver
>>>>   * @groups:		[INTERN] attribute groups
>>>>   * @groupcounter:	[INTERN] index of next attribute group
>>>> + * @dev_list_entry:	[INTERN] entry in global list of iio devices
>>>>   **/
>>>>  struct iio_dev {
>>>>  	int				id;
>>>
>>> --
>>> 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