linux-kernel - Re: iio: dht11 Updates

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: <E1XwYwk-00019x-LZ@stardust.g4.wien.funkfeuer.at>
Date:	Thu, 04 Dec 2014 17:08:02 +0100
From:	Harald Geyer <harald@...ib.org>
To:	Richard Weinberger <richard@....at>
cc:	jic23@...nel.org, knaack.h@....de, lars@...afoo.de,
	pmeerw@...erw.net, sanjeev_sharma@...tor.com,
	linux-iio@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: iio: dht11 Updates

Richard Weinberger writes:
> Harald,
> 
> Am 03.12.2014 um 13:18 schrieb Harald Geyer:
> > Hi Richard,
> > 
> > thanks for all the work you put into this!
> > 
> > Richard Weinberger writes:
> >> Please see my current patches for your driver.
> >> As discussed in an earlier mail I'm testing with the DHT22 sensor only.
> >> With the IRQ changes I see 84 edges.
> > 
> > This still surprises me. With the IRQ changes I would expect the
> > preamble to be 2 edges only. I must be missing something. Can you
> > explain this to me?
> 
> Did some more tests.
> With my IRQ changes applied I get as stated 84 edges,
> without I get 85. So we're only losing one edge.

Ok, finally had time to look into this and it's a simple off-by-one
issue (no bug) that confused me:
Without your patch the full number of edges per data transmission
is 86. But since the last edge is not significant, we only store
85 edges. - There should be a comment about this in the source...

With your patch the preamble is shortened by two edges as expected,
but since there is a workaround for sensors where the preamble wasn't
properly recorded, nobody notices unless they are looking closely at
the number of edges recorded. The next thing to do is check on DHT11
if the workaround is still needed.

Note that the old behaviour was nice for debugging wiring problems:
With my standard setup (3.3V, pin drive strenght 4 mA) I got the
following:
supply not connected: 0 edges (sensor always pulls the data line low)
data not connected: 2 edges (we only see the signal we generate ourselves)
gnd not connected: random amount of edges

With the new behaviour we will get 0 edges in both of the first two
cases. So we are really losing a tiny bit of functionality... :-(

HTH,
Harald
--
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/