linux-kernel - Re: w1_ds2408 linux driver

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 19 Feb 2013 15:20:34 +0000
From:	Jean-Francois Dagenais <DagenaisJ@...atest.com>
To:	Olivier KSIKES <olivier@...rods.com>
CC:	"zbr@...emap.net" <zbr@...emap.net>,
	open list <linux-kernel@...r.kernel.org>
Subject: Re: w1_ds2408 linux driver

Hi Olivier,

I'm forwarding this to Evgeniy and the linux-kernel mailing list as this thread
may have historical value.

On 2013-02-19, at 9:44 AM, Olivier KSIKES wrote:

> Dear Mr Dagenais,
> 
> I have just tried your w1-ds2408 linux driver on a TP link mini router running openwrt with w1-gpio. I was able to successfully update a 2408 outputs by writing a byte to the /output file.
> However, I would like to drive an LCD screen, and this method seems limited to 3/4 chars per second.

Yikes!

> 
> I had little more luck driving the 2408 thru the generic w1 driver (using the rw file), where I reached around 25 bytes/s.

This is a big surprise to me... Are you sure about the result, i.e. that no
errors are occurring?

> This is however far from the actual 1wire bus capabilities.

Indeed. Did you try turning on the "dev_dbg" prints using "#define DEBUG" at the
top of the file? This will give you clues as to whether bus errors are occurring
and retries are made.

> 
> Thus, I'm wondering if there is a faster way to output a series of bytes to the 2408 using your driver?
> Is there any doc available apart from w1_ds2408.c comments?

A quick inspection of the w1_ds2408 driver reveals that for each byte write
operation, we need to write 3 bytes, then read 1, then a bus reset, then the
resume command (1byte) and after this we go back to read back to see if the
value we wrote worked, which is again 3 bytes written, and 1 read. This is
certainly much longer that doing it the easy way and may be a bit paranoid. I
could see a patch that would make this double checking optional, say when the
module is build with "#define DEBUG" or perhaps with a module option in the
Kconfig which would have the double checking behaviour on by default.

The reason I designed it this way is because 1-wire busses tend to be close to
flaky. Certainly the environment I developed the driver in was flaky. Finally we
resolved the issues with pull-ups and what not, but there are other examples
where the 1-wire bus spec is stretched a bit by certain component.

Having a Kconfig value could enable the double check code to be present for
stabilization purposes, and then turned off once things work so it can run
faster.

Send a patch!

> 
> With best regards and congratulations for your great work,
> 
> Olivier Ksikes

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