From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752794AbbJFTiM (ORCPT ); Tue, 6 Oct 2015 15:38:12 -0400 Received: from pandora.arm.linux.org.uk ([78.32.30.218]:43579 "EHLO pandora.arm.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752166AbbJFTiL (ORCPT ); Tue, 6 Oct 2015 15:38:11 -0400 Date: Tue, 6 Oct 2015 20:37:57 +0100 From: Russell King - ARM Linux To: Lee Jones Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, peter@korsgaard.com, kernel@stlinux.com, daniel.thompson@linaro.org, pankaj.dev@st.com, festevam@gmail.com, herbert@gondor.apana.org.au Subject: Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Message-ID: <20151006193757.GY21513@n2100.arm.linux.org.uk> References: <1444142640-14721-1-git-send-email-lee.jones@linaro.org> <1444142640-14721-3-git-send-email-lee.jones@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1444142640-14721-3-git-send-email-lee.jones@linaro.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 06, 2015 at 03:44:00PM +0100, Lee Jones wrote: > Samples are documented to be available every 0.667us, so in theory > the 8 sample deep FIFO should take 5.336us to fill. However, during > thorough testing, it became apparent that filling the FIFO actually > takes closer to 12us. Is that measured? > +/* > + * Samples are documented to be available every 0.667us, so in theory > + * the 8 sample deep FIFO should take 5.336us to fill. However, during > + * thorough testing, it became apparent that filling the FIFO actually > + * takes closer to 12us. > + */ > +#define ST_RNG_FILL_FIFO_TIMEOUT 12 I hope you're not using such a precise figure with udelay(). udelay() is not guaranteed to give exactly (or even at least) the delay you request. It's defined to give an approximate delay. Many people have a problem understanding that, so I won't explain why it is that way, just accept that it is and move on... it's not going to magically get "fixed" because someone has just learnt about this. :) -- FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.