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:08:31 +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:
> >> 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.

I guess we should include timeres into the warning message.

Also I guess now is the time to think about a smarter decoder.

Thanks a lot for your effort.
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/