Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1240499 > unrolled thread

[RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address

Back to article view | Back to linux.kernel

Contents

  [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Lee Jones <lee.jones@linaro.org> - 2015-10-06 16:50 +0200
    [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Lee Jones <lee.jones@linaro.org> - 2015-10-06 16:50 +0200
      Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-06 21:40 +0200
        Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Russell King - ARM Linux <linux@arm.linux.org.uk> - 2015-10-06 23:00 +0200
          Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Lee Jones <lee.jones@linaro.org> - 2015-10-07 10:00 +0200
        Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Lee Jones <lee.jones@linaro.org> - 2015-10-06 23:00 +0200
    Re: [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Herbert Xu <herbert@gondor.apana.org.au> - 2015-10-06 17:40 +0200

#1240499 — [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address

DT nodes should not append their addresses with '0x'.

Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 Documentation/devicetree/bindings/rng/st,rng.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/rng/st,rng.txt b/Documentation/devicetree/bindings/rng/st,rng.txt
index dbc64e6..35734bc 100644
--- a/Documentation/devicetree/bindings/rng/st,rng.txt
+++ b/Documentation/devicetree/bindings/rng/st,rng.txt
@@ -8,7 +8,7 @@ clocks		: Phandle to device's clock (See: ../clocks/clock-bindings.txt)
 
 Example:
 
-rng@0xfee80000 {
+rng@fee80000 {
 	compatible      = "st,rng";
 	reg		= <0xfee80000 0x1000>;
 	clocks          = <&clk_sysin>;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1240501 — [PATCH 3/3] hwrng: st: Use real-world device timings for timeout

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.

Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
 drivers/char/hw_random/st-rng.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c
index 44480fe..3b1432c 100644
--- a/drivers/char/hw_random/st-rng.c
+++ b/drivers/char/hw_random/st-rng.c
@@ -33,8 +33,13 @@
 #define ST_RNG_FIFO_DEPTH		8
 #define ST_RNG_FIFO_SIZE		(ST_RNG_FIFO_DEPTH * ST_RNG_SAMPLE_SIZE)
 
-/* Samples are available every 0.667us, which we round to 1us */
-#define ST_RNG_FILL_FIFO_TIMEOUT   (1 * (ST_RNG_FIFO_SIZE / ST_RNG_SAMPLE_SIZE))
+/*
+ * 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
 
 struct st_rng_data {
 	void __iomem	*base;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1240890 — Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1240987 — Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout

On Tue, Oct 06, 2015 at 09:51:22PM +0100, Lee Jones wrote:
> On Tue, 06 Oct 2015, Russell King - ARM Linux wrote:
> > 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?
> 
> I measured it using ktime.  Hopefully that was adequate.
> 
> > > +/*
> > > + * 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. :)
> 
> Thanks for the info.  I did do testing, again using ktime, to make
> sure and on our platform (is it platform specific?) I measured
> udelay(1) to be ~1100ns.  After moving to a 12us timeout and reading
> many MBs of randomness I am yet to receive any more timeouts.

If you happen to fall back to the software timing loop, udelay(1) will not
be >=1us anymore, but will be slightly shorter.

That's because the loops_per_jiffy value is calculated as the number of
loops between each timer interrupt - so the period being measured is the
timer period, minus the time it takes for the timer interrupt to run.
The latter is indeterminant.  Consequently, the loops_per_jiffy estimate
is always slightly under the real number of loops-per-jiffy, so delays
generated by udelay() and friends will always be slightly short.

The faster your HZ value, the bigger the error.  The longer the interrupt
handler takes, the bigger the error.

IIRC, Linus recommends a x2 factor on delays, especially timeouts generated
by these functions.

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1241209 — Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout

On Tue, 06 Oct 2015, Russell King - ARM Linux wrote:

> On Tue, Oct 06, 2015 at 09:51:22PM +0100, Lee Jones wrote:
> > On Tue, 06 Oct 2015, Russell King - ARM Linux wrote:
> > > 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?
> > 
> > I measured it using ktime.  Hopefully that was adequate.
> > 
> > > > +/*
> > > > + * 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. :)
> > 
> > Thanks for the info.  I did do testing, again using ktime, to make
> > sure and on our platform (is it platform specific?) I measured
> > udelay(1) to be ~1100ns.  After moving to a 12us timeout and reading
> > many MBs of randomness I am yet to receive any more timeouts.
> 
> If you happen to fall back to the software timing loop, udelay(1) will not
> be >=1us anymore, but will be slightly shorter.
> 
> That's because the loops_per_jiffy value is calculated as the number of
> loops between each timer interrupt - so the period being measured is the
> timer period, minus the time it takes for the timer interrupt to run.
> The latter is indeterminant.  Consequently, the loops_per_jiffy estimate
> is always slightly under the real number of loops-per-jiffy, so delays
> generated by udelay() and friends will always be slightly short.
> 
> The faster your HZ value, the bigger the error.  The longer the interrupt
> handler takes, the bigger the error.

Thanks for taking the time to explain.

> IIRC, Linus recommends a x2 factor on delays, especially timeouts generated
> by these functions.

In this implementation it shouldn't matter too much either way.  Even
when the timeouts were prolific, bandwidth was not reduced due to the
quick turn-round of the subsystem.  I don't foresee any impact on
bandwidth if we were to raise the timeout either; in fact, I doubt
we'd ever see a timeout again.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1240993 — Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout

On Tue, 06 Oct 2015, Russell King - ARM Linux wrote:
> 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?

I measured it using ktime.  Hopefully that was adequate.

> > +/*
> > + * 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. :)

Thanks for the info.  I did do testing, again using ktime, to make
sure and on our platform (is it platform specific?) I measured
udelay(1) to be ~1100ns.  After moving to a 12us timeout and reading
many MBs of randomness I am yet to receive any more timeouts.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1240595

On Tue, Oct 06, 2015 at 03:43:58PM +0100, Lee Jones wrote:
> DT nodes should not append their addresses with '0x'.
> 
> Suggested-by: Stephen Boyd <sboyd@codeaurora.org>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>

If this is supposed to go in via the crypto tree it needs to be
posted to linux-crypto@vger.kernel.org.

Thanks,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web