* [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address @ 2015-10-06 14:43 Lee Jones 2015-10-06 14:43 ` [PATCH 2/3] hwrng: st: Report correct FIFO size Lee Jones ` (2 more replies) 0 siblings, 3 replies; 10+ messages in thread From: Lee Jones @ 2015-10-06 14:43 UTC (permalink / raw) To: linux-arm-kernel, linux-kernel Cc: kernel, herbert, peter, festevam, pankaj.dev, daniel.thompson, Lee Jones 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* [PATCH 2/3] hwrng: st: Report correct FIFO size 2015-10-06 14:43 [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Lee Jones @ 2015-10-06 14:43 ` Lee Jones 2015-10-06 15:48 ` Daniel Thompson 2015-10-06 14:44 ` [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Lee Jones 2015-10-06 15:24 ` [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Herbert Xu 2 siblings, 1 reply; 10+ messages in thread From: Lee Jones @ 2015-10-06 14:43 UTC (permalink / raw) To: linux-arm-kernel, linux-kernel Cc: kernel, herbert, peter, festevam, pankaj.dev, daniel.thompson, Lee Jones The values supplied to the 'read random data from FIFO' arithmetic are not correct. The value fed in to initialise the iterator describes the FIFO depth, but then the iterator is treated in Bytes and subsequently increased by 2 in value for every read word. This means only 4 of the 8 available values are being read during each invocation of .read(). This change increased the device bandwidth by a factor of 2. Reported-by: Daniel Thompson <daniel.thompson@linaro.org> Signed-off-by: Lee Jones <lee.jones@linaro.org> --- drivers/char/hw_random/st-rng.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c index 8c8a435..44480fe 100644 --- a/drivers/char/hw_random/st-rng.c +++ b/drivers/char/hw_random/st-rng.c @@ -29,8 +29,9 @@ #define ST_RNG_STATUS_BAD_ALTERNANCE BIT(1) #define ST_RNG_STATUS_FIFO_FULL BIT(5) -#define ST_RNG_FIFO_SIZE 8 #define ST_RNG_SAMPLE_SIZE 2 /* 2 Byte (16bit) samples */ +#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)) -- 1.9.1 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 2/3] hwrng: st: Report correct FIFO size 2015-10-06 14:43 ` [PATCH 2/3] hwrng: st: Report correct FIFO size Lee Jones @ 2015-10-06 15:48 ` Daniel Thompson 2015-10-06 15:23 ` Lee Jones 0 siblings, 1 reply; 10+ messages in thread From: Daniel Thompson @ 2015-10-06 15:48 UTC (permalink / raw) To: Lee Jones, linux-arm-kernel, linux-kernel Cc: kernel, herbert, peter, festevam, pankaj.dev On 06/10/15 15:43, Lee Jones wrote: > The values supplied to the 'read random data from FIFO' arithmetic > are not correct. The value fed in to initialise the iterator > describes the FIFO depth, but then the iterator is treated in > Bytes and subsequently increased by 2 in value for every read > word. This means only 4 of the 8 available values are being read > during each invocation of .read(). > > This change increased the device bandwidth by a factor of 2. > > Reported-by: Daniel Thompson <daniel.thompson@linaro.org> > Signed-off-by: Lee Jones <lee.jones@linaro.org> > --- > drivers/char/hw_random/st-rng.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c > index 8c8a435..44480fe 100644 > --- a/drivers/char/hw_random/st-rng.c > +++ b/drivers/char/hw_random/st-rng.c > @@ -29,8 +29,9 @@ > #define ST_RNG_STATUS_BAD_ALTERNANCE BIT(1) > #define ST_RNG_STATUS_FIFO_FULL BIT(5) > > -#define ST_RNG_FIFO_SIZE 8 > #define ST_RNG_SAMPLE_SIZE 2 /* 2 Byte (16bit) samples */ > +#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)) This change doubles the timeout and doesn't mention it in the changelog. Changing the order of 2/3 and 3/3 would avoid this. Other than that: Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Daniel. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 2/3] hwrng: st: Report correct FIFO size 2015-10-06 15:48 ` Daniel Thompson @ 2015-10-06 15:23 ` Lee Jones 0 siblings, 0 replies; 10+ messages in thread From: Lee Jones @ 2015-10-06 15:23 UTC (permalink / raw) To: Daniel Thompson Cc: linux-arm-kernel, linux-kernel, kernel, herbert, peter, festevam, pankaj.dev On Tue, 06 Oct 2015, Daniel Thompson wrote: > On 06/10/15 15:43, Lee Jones wrote: > >The values supplied to the 'read random data from FIFO' arithmetic > >are not correct. The value fed in to initialise the iterator > >describes the FIFO depth, but then the iterator is treated in > >Bytes and subsequently increased by 2 in value for every read > >word. This means only 4 of the 8 available values are being read > >during each invocation of .read(). > > > >This change increased the device bandwidth by a factor of 2. > > > >Reported-by: Daniel Thompson <daniel.thompson@linaro.org> > >Signed-off-by: Lee Jones <lee.jones@linaro.org> > >--- > > drivers/char/hw_random/st-rng.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > >diff --git a/drivers/char/hw_random/st-rng.c b/drivers/char/hw_random/st-rng.c > >index 8c8a435..44480fe 100644 > >--- a/drivers/char/hw_random/st-rng.c > >+++ b/drivers/char/hw_random/st-rng.c > >@@ -29,8 +29,9 @@ > > #define ST_RNG_STATUS_BAD_ALTERNANCE BIT(1) > > #define ST_RNG_STATUS_FIFO_FULL BIT(5) > > > >-#define ST_RNG_FIFO_SIZE 8 > > #define ST_RNG_SAMPLE_SIZE 2 /* 2 Byte (16bit) samples */ > >+#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)) > > This change doubles the timeout and doesn't mention it in the > changelog. The next patch renders this point moot. > Changing the order of 2/3 and 3/3 would avoid this. Right, if this is a real concern the patches can be applied in a different order. > Other than that: > > Reviewed-by: Daniel Thompson <daniel.thompson@linaro.org> Thanking you. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH 3/3] hwrng: st: Use real-world device timings for timeout 2015-10-06 14:43 [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Lee Jones 2015-10-06 14:43 ` [PATCH 2/3] hwrng: st: Report correct FIFO size Lee Jones @ 2015-10-06 14:44 ` Lee Jones 2015-10-06 19:37 ` Russell King - ARM Linux 2015-10-06 15:24 ` [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Herbert Xu 2 siblings, 1 reply; 10+ messages in thread From: Lee Jones @ 2015-10-06 14:44 UTC (permalink / raw) To: linux-arm-kernel, linux-kernel Cc: kernel, herbert, peter, festevam, pankaj.dev, daniel.thompson, Lee Jones 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 ^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout 2015-10-06 14:44 ` [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Lee Jones @ 2015-10-06 19:37 ` Russell King - ARM Linux 2015-10-06 20:51 ` Lee Jones 0 siblings, 1 reply; 10+ messages in thread From: Russell King - ARM Linux @ 2015-10-06 19:37 UTC (permalink / raw) To: Lee Jones Cc: linux-arm-kernel, linux-kernel, peter, kernel, daniel.thompson, pankaj.dev, festevam, herbert 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout 2015-10-06 19:37 ` Russell King - ARM Linux @ 2015-10-06 20:51 ` Lee Jones 2015-10-06 20:56 ` Russell King - ARM Linux 0 siblings, 1 reply; 10+ messages in thread From: Lee Jones @ 2015-10-06 20:51 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-arm-kernel, linux-kernel, peter, kernel, daniel.thompson, pankaj.dev, festevam, herbert 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout 2015-10-06 20:51 ` Lee Jones @ 2015-10-06 20:56 ` Russell King - ARM Linux 2015-10-07 7:53 ` Lee Jones 0 siblings, 1 reply; 10+ messages in thread From: Russell King - ARM Linux @ 2015-10-06 20:56 UTC (permalink / raw) To: Lee Jones Cc: linux-arm-kernel, linux-kernel, peter, kernel, daniel.thompson, pankaj.dev, festevam, herbert 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. ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH 3/3] hwrng: st: Use real-world device timings for timeout 2015-10-06 20:56 ` Russell King - ARM Linux @ 2015-10-07 7:53 ` Lee Jones 0 siblings, 0 replies; 10+ messages in thread From: Lee Jones @ 2015-10-07 7:53 UTC (permalink / raw) To: Russell King - ARM Linux Cc: linux-arm-kernel, linux-kernel, peter, kernel, daniel.thompson, pankaj.dev, festevam, herbert 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address 2015-10-06 14:43 [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Lee Jones 2015-10-06 14:43 ` [PATCH 2/3] hwrng: st: Report correct FIFO size Lee Jones 2015-10-06 14:44 ` [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Lee Jones @ 2015-10-06 15:24 ` Herbert Xu 2 siblings, 0 replies; 10+ messages in thread From: Herbert Xu @ 2015-10-06 15:24 UTC (permalink / raw) To: Lee Jones Cc: linux-arm-kernel, linux-kernel, kernel, peter, festevam, pankaj.dev, daniel.thompson 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-10-07 7:53 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-10-06 14:43 [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Lee Jones 2015-10-06 14:43 ` [PATCH 2/3] hwrng: st: Report correct FIFO size Lee Jones 2015-10-06 15:48 ` Daniel Thompson 2015-10-06 15:23 ` Lee Jones 2015-10-06 14:44 ` [PATCH 3/3] hwrng: st: Use real-world device timings for timeout Lee Jones 2015-10-06 19:37 ` Russell King - ARM Linux 2015-10-06 20:51 ` Lee Jones 2015-10-06 20:56 ` Russell King - ARM Linux 2015-10-07 7:53 ` Lee Jones 2015-10-06 15:24 ` [RESEND 1/3] hwrng: st: dt: Fix trivial typo in node address Herbert Xu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).