linux-kernel - Re: [PATCH 2/2] iio: dht11: IRQ fixes

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: <E1Xvn2b-0001CH-PM@stardust.g4.wien.funkfeuer.at>
Date:	Tue, 02 Dec 2014 13:58:53 +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: [PATCH 2/2] iio: dht11: IRQ fixes

Richard Weinberger writes:
> Harald,
> 
> Am 02.12.2014 um 11:19 schrieb Harald Geyer:
> > Hi Richard,
> > 
> > thanks for the patch.
> > 
> > I think (haven't tried yet) that your patch changes the number of
> > edges recorded per transmission. So probably the decoding function
> > needs to be adapted too...
> 
> Can you explain your thought?
> I'll happily dig into that.

Part of the reason to have the IRQ enabled during output was to
get consistent timestamps (all timestamps would be taken via the
same codepath). While this isn't essential, the current code expects
that the start command we generate is in the list of edges. I think
your changes will cause that start command not to be in the list of
edges.

Note: There have been issues with some sensors (DHT11s?) not to
send proper start bits, so the driver tries to be liberal about
what it expects and you probably haven't seen any decoding errors
if your sample sensor works to specification. (Now that I come to
think about it: Undefined behaviour of IRQs on output lines could
have been involved too...)

This is a bit of a mess and I'd rather clean this up than add more
to it. Maybe I'm overly fussy about this, but it has bitten me in
the past.

Since it seems you have some interesst in working on these parts,
let me mention an unrelated issue: The DHT22 stops sending data
after a random time (think of days here) which AFAIK only can be
worked around by power-cycling the sensor. I mean to add something
for this to the driver but couln't make up my mind about what the
proper ABI for this would be, so right now I'm using some userspace
hack for this. (The issue was already discussed on the linux-iio
mailing list a few month ago, if you want to look into this.
Anyway: You have been warned ... ;)  

> > I won't be able to ACK this before testing on real HW. Of course
> > confirmation that your changes work reliably on both DHT11 and DHT22
> > will do as well. The debuging code present in the initial submission
> > of the driver might be helpful to anybody trying to verify the
> > timing.
> 
> I have only DHT22 sensors. Of course I've tested the driver with these.

Ok, so I'll test DHT11 first. It would still be nice to confirm how
many edges are recorded from DHT22 though.

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