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]

Date:	Thu, 04 Dec 2014 14:45:32 +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:
> Am 03.12.2014 um 15:08 schrieb Harald Geyer:
> >> I was asking because I see the "dht11: WARNING: decoding ambiguous"
> >> very often. (with and without my patches)
> > 
> > Yes, your patches shouldn't have any effect on this.
> > "very often" in the sense of "not always"? This would be very surprising,
> > because this would involve variable length clock ticks, i think.
> > 
> > I guess we should include timeres into the warning message.
> > 
> > Also I guess now is the time to think about a smarter decoder.

I was wrong.

> Another question. Your driver defines:
> #define DHT11_DATA_BIT_LOW      27000
> #define DHT11_DATA_BIT_HIGH     70000
> 
> If I read the manual [0] correctly these constants are T_h0/1.
> Why did you use 27000 for T_h0?
>
> [0] http://meteobox.tk/files/AM2302.pdf

It's a compromise between data sheets for various slightly different
sensors. In particular the data sheet for AM2303 specifies
26-28us, so it's just in the middle. But note that DHT11_DATA_BIT_LOW
isn't used in the actual decoding. Just for printing the warning.

But looking at your data sheet I see the we currently use a start
command that's outside the specified range... I will have to look
up where the current 80ms value was suggested.

> Setting it to 26000 (the typical value as stated by the manual),
> I get the "decoding ambiguous" warning *always*. Setting it higher
> makes the message go away.

If you misstyped "always" and "go away" then this is to be expected.

Also I think I now understand what is going on:
Your board most probably has a clock much faster then 32kH and when
we calculate timeres, we don't actually calculate the timestamp
resolution but the length of the shortest pulse. The decoding
algorithm is robust in such cases, but it generates wrong warnings.

The proper fix is to drop messages about clock speed from the
decoding functin. If we want to keep such diagnostics, we should
have them at probe() time. - This will also resolve our disagreement
about proper formatting of log messages about clock issues. :)

Optionally we can drop the calculation of timeres and just use a
constant threshold.

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/