linux-kernel - Re: [W1] a driver for DS2405 chip

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]

Date:	Thu, 04 Nov 2010 21:01:49 +0100
From:	Maciej Szmigiero <mhej@...pl>
To:	Ben Nizette <bn@...sdigital.com>
CC:	Jonathan Cameron <jic23@....ac.uk>, johnpol@....mipt.ru,
	linux-kernel@...r.kernel.org,
	David Brownell <dbrownell@...rs.sourceforge.net>
Subject: Re: [W1] a driver for DS2405 chip

W dniu 03.11.2010 11:54, Ben Nizette pisze:
> 
> On 03/11/2010, at 6:53 AM, Maciej Szmigiero wrote:
> 
>> W dniu 01.11.2010 13:35, Jonathan Cameron pisze:
>>> On 10/28/10 21:52, Maciej Szmigiero wrote:
>>>> [W1] a driver for DS2405 chip
>>>>
>>>> This is a driver for DS2405 1-wire single-channel addressable switch / PIO.
>>>> DS2405 can also work as single-channel binary remote sensor.
>>> Perhaps handle this as a gpio chip? (be it a fairly limited one)
>>> To my mind it would make it more generally useful...
>>
>> I think the GPIO infrastructure is meant for on-system GPIOs, where 1-wire devices are mostly 
>> used for remote data acquisition.
> 
> Nope!  The contents of drivers/gpio is split roughly 50/50 between on- and off-chip gpio expanders. 
> 
>> That's probably why w1_therm (for 1-wire thermometers) is not integrated with HWMON subsystem.
> 
> Don't know why this is but kinda sounds like it should be looked at more closely - conceptually 1-W is just another bus like, eg, SPI.
> 
> 	--Ben.

Looking at GPIO subsystem I think it's not a best solution for this device. One reason is that GPIOs are
identified by integer which is either #defined by platform (as Documentation/gpio.txt says) or assigned randomly.

First approach obviously doesn't fit, as I'm yet to find anybody using ds2405 for anything platform-related.
Second leads to problems in locating particular device (numbers will depend on order of detection/plugging).
In contrast with that, 1W subsystem provides clear and unique identification for every device as it appears under
its hardware address.

In addition to that the chip removal code (gpiochip_remove() function) does not sleep when removal fails due
to chip being in use, returning EBUSY instead. 
This leads to inefficient unplugging (like trying to remove chip in loop hoping that finally somebody releases it).
Probably this loop will also have to check if device reappeared, so the driver doesn't try to register new instance of chip
while there is still one in existence.
Note that Documentation/gpio.txt says "Removing a GPIO controller should be rare; use gpiochip_remove() when it is unavoidable".
Characteristics of long W1 buses cause devices to disappear and reappear from time to time so it won't be a "rare" operation here.

And all this added complexity for what? - to replace two tiny attributes under device sysfs directory?

Maciej Szmigiero
--
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/