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:	Wed, 03 Dec 2014 15:29:26 +0100
From:	Richard Weinberger <richard@....at>
To:	Harald Geyer <harald@...ib.org>
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

Am 03.12.2014 um 15:08 schrieb Harald Geyer:
> 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:
>>>> I have also a question on your driver. Why you increment
>>>> DHT11_DATA_BIT_LOW/timeres by one in the ambiguity check?
>>>>
>>>>         threshold = DHT11_DATA_BIT_HIGH / timeres;
>>>>         if (DHT11_DATA_BIT_LOW/timeres + 1 >= threshold)
>>>>                 pr_err("dht11: WARNING: decoding ambiguous\n");
>>>
>>> This is to take ambiguity of when the bit started relativ to the
>>> clock ticks into account. For example with common 32kHz clocks:
>>> DHT11_DATA_BIT_LOW / timeres = 0
>>> DHT11_DATA_BIT_HIGH / timeres = 2
>>> but since the bit might not start at a clock tick the actual t of
>>> a low bit can be either 0 or 1 while the actual t of a high bit
>>> can be either 2 or 3.
>>>
>>> This case is fine.
>>>
>>> But if we had a 38kHz clock:
>>> DHT11_DATA_BIT_LOW / timeres = 1    t can be 1 or 2
>>> DHT11_DATA_BIT_HIGH / timeres = 2   t can be 2 or 3
>>> so we have an ambiguity. The ambiguity could be removed by a smarter
>>> decoder, that looks at the t of other bits, but I'm not going to do
>>> that unless somebody is promising to test it on affected hardware.
>>>
>>> Feel free to add some comment about this to the code.
>>
>> Will do, thanks a lot for the explanation.
>>
>> 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.

It happens around 33% of all reads.
BTW: I'm using the DHT22's on my Beaglebone Black.
So the board should be "sane".
But I'll test them on another board too, just to be sure...

> I guess we should include timeres into the warning message.

I'll add some diagnose printk()s to find out.

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