* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-07 16:00 ` Gustavo A. R. Silva 0 siblings, 0 replies; 32+ messages in thread From: Gustavo A. R. Silva @ 2018-02-07 16:00 UTC (permalink / raw) To: Mark Brown, Eric Anholt, Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list Cc: linux-spi, linux-rpi-kernel, linux-arm-kernel, linux-kernel, Gustavo A. R. Silva Add suffix ULL to constant 9 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type unsigned long long (64 bits, unsigned). The expression tfr->len * 9 * 1000000 is currently being evaluated using 32-bit arithmetic. Addresses-Coverity-ID: 1339619 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> --- drivers/spi/spi-bcm2835aux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c index 7428091..a768c23 100644 --- a/drivers/spi/spi-bcm2835aux.c +++ b/drivers/spi/spi-bcm2835aux.c @@ -363,7 +363,7 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, * chunk getting transferred - in our case the chunk size * is 3 bytes, so we approximate this by 9 bits/byte */ - xfer_time_us = tfr->len * 9 * 1000000; + xfer_time_us = tfr->len * 9ULL * 1000000; do_div(xfer_time_us, spi_used_hz); /* run in polling mode for short transfers */ -- 2.7.4 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-07 16:00 ` Gustavo A. R. Silva 0 siblings, 0 replies; 32+ messages in thread From: Gustavo A. R. Silva @ 2018-02-07 16:00 UTC (permalink / raw) To: linux-arm-kernel Add suffix ULL to constant 9 in order to give the compiler complete information about the proper arithmetic to use. Notice that this constant is used in a context that expects an expression of type unsigned long long (64 bits, unsigned). The expression tfr->len * 9 * 1000000 is currently being evaluated using 32-bit arithmetic. Addresses-Coverity-ID: 1339619 Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> --- drivers/spi/spi-bcm2835aux.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c index 7428091..a768c23 100644 --- a/drivers/spi/spi-bcm2835aux.c +++ b/drivers/spi/spi-bcm2835aux.c @@ -363,7 +363,7 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, * chunk getting transferred - in our case the chunk size * is 3 bytes, so we approximate this by 9 bits/byte */ - xfer_time_us = tfr->len * 9 * 1000000; + xfer_time_us = tfr->len * 9ULL * 1000000; do_div(xfer_time_us, spi_used_hz); /* run in polling mode for short transfers */ -- 2.7.4 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit 2018-02-07 16:00 ` Gustavo A. R. Silva @ 2018-02-08 8:22 ` Eric Anholt -1 siblings, 0 replies; 32+ messages in thread From: Eric Anholt @ 2018-02-08 8:22 UTC (permalink / raw) To: Gustavo A. R. Silva, Mark Brown, Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list Cc: linux-spi, linux-rpi-kernel, linux-arm-kernel, linux-kernel, Gustavo A. R. Silva [-- Attachment #1: Type: text/plain, Size: 725 bytes --] "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes: > Add suffix ULL to constant 9 in order to give the compiler complete > information about the proper arithmetic to use. Notice that this > constant is used in a context that expects an expression of type > unsigned long long (64 bits, unsigned). > > The expression tfr->len * 9 * 1000000 is currently being evaluated > using 32-bit arithmetic. > > Addresses-Coverity-ID: 1339619 > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> The effect looks like it would be that we would have chosen polling mode instead of waiting for interrupts for some transfers >477 seconds. Seems like a good fix for an unlikely bug. Reviewed-by: Eric Anholt <eric@anholt.net> [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 832 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-08 8:22 ` Eric Anholt 0 siblings, 0 replies; 32+ messages in thread From: Eric Anholt @ 2018-02-08 8:22 UTC (permalink / raw) To: linux-arm-kernel "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes: > Add suffix ULL to constant 9 in order to give the compiler complete > information about the proper arithmetic to use. Notice that this > constant is used in a context that expects an expression of type > unsigned long long (64 bits, unsigned). > > The expression tfr->len * 9 * 1000000 is currently being evaluated > using 32-bit arithmetic. > > Addresses-Coverity-ID: 1339619 > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> The effect looks like it would be that we would have chosen polling mode instead of waiting for interrupts for some transfers >477 seconds. Seems like a good fix for an unlikely bug. Reviewed-by: Eric Anholt <eric@anholt.net> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 832 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180208/e27ae2aa/attachment.sig> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit 2018-02-08 8:22 ` Eric Anholt @ 2018-02-12 17:57 ` Gustavo A. R. Silva -1 siblings, 0 replies; 32+ messages in thread From: Gustavo A. R. Silva @ 2018-02-12 17:57 UTC (permalink / raw) To: Eric Anholt, Gustavo A. R. Silva, Mark Brown, Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list Cc: linux-spi, linux-rpi-kernel, linux-arm-kernel, linux-kernel Hi Eric, On 02/08/2018 02:22 AM, Eric Anholt wrote: > "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes: > >> Add suffix ULL to constant 9 in order to give the compiler complete >> information about the proper arithmetic to use. Notice that this >> constant is used in a context that expects an expression of type >> unsigned long long (64 bits, unsigned). >> >> The expression tfr->len * 9 * 1000000 is currently being evaluated >> using 32-bit arithmetic. >> >> Addresses-Coverity-ID: 1339619 >> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> > > The effect looks like it would be that we would have chosen polling mode > instead of waiting for interrupts for some transfers >477 seconds. > Seems like a good fix for an unlikely bug. > > Reviewed-by: Eric Anholt <eric@anholt.net> > Thank you for your review. -- Gustavo ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 17:57 ` Gustavo A. R. Silva 0 siblings, 0 replies; 32+ messages in thread From: Gustavo A. R. Silva @ 2018-02-12 17:57 UTC (permalink / raw) To: linux-arm-kernel Hi Eric, On 02/08/2018 02:22 AM, Eric Anholt wrote: > "Gustavo A. R. Silva" <gustavo@embeddedor.com> writes: > >> Add suffix ULL to constant 9 in order to give the compiler complete >> information about the proper arithmetic to use. Notice that this >> constant is used in a context that expects an expression of type >> unsigned long long (64 bits, unsigned). >> >> The expression tfr->len * 9 * 1000000 is currently being evaluated >> using 32-bit arithmetic. >> >> Addresses-Coverity-ID: 1339619 >> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> > > The effect looks like it would be that we would have chosen polling mode > instead of waiting for interrupts for some transfers >477 seconds. > Seems like a good fix for an unlikely bug. > > Reviewed-by: Eric Anholt <eric@anholt.net> > Thank you for your review. -- Gustavo ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit 2018-02-07 16:00 ` Gustavo A. R. Silva (?) @ 2018-02-08 9:54 ` Ard Biesheuvel -1 siblings, 0 replies; 32+ messages in thread From: Ard Biesheuvel @ 2018-02-08 9:54 UTC (permalink / raw) To: Gustavo A. R. Silva Cc: Mark Brown, Eric Anholt, Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Linux Kernel Mailing List, Gustavo A. R. Silva, linux-rpi-kernel, linux-arm-kernel, linux-spi On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> wrote: > Add suffix ULL to constant 9 in order to give the compiler complete > information about the proper arithmetic to use. Notice that this > constant is used in a context that expects an expression of type > unsigned long long (64 bits, unsigned). > > The expression tfr->len * 9 * 1000000 is currently being evaluated > using 32-bit arithmetic. > > Addresses-Coverity-ID: 1339619 What does this number mean? If it is an index into some internal database, please remove it. > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> > --- > drivers/spi/spi-bcm2835aux.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c > index 7428091..a768c23 100644 > --- a/drivers/spi/spi-bcm2835aux.c > +++ b/drivers/spi/spi-bcm2835aux.c > @@ -363,7 +363,7 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, > * chunk getting transferred - in our case the chunk size > * is 3 bytes, so we approximate this by 9 bits/byte > */ > - xfer_time_us = tfr->len * 9 * 1000000; > + xfer_time_us = tfr->len * 9ULL * 1000000; > do_div(xfer_time_us, spi_used_hz); > > /* run in polling mode for short transfers */ > -- > 2.7.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-08 9:54 ` Ard Biesheuvel 0 siblings, 0 replies; 32+ messages in thread From: Ard Biesheuvel @ 2018-02-08 9:54 UTC (permalink / raw) To: linux-arm-kernel On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> wrote: > Add suffix ULL to constant 9 in order to give the compiler complete > information about the proper arithmetic to use. Notice that this > constant is used in a context that expects an expression of type > unsigned long long (64 bits, unsigned). > > The expression tfr->len * 9 * 1000000 is currently being evaluated > using 32-bit arithmetic. > > Addresses-Coverity-ID: 1339619 What does this number mean? If it is an index into some internal database, please remove it. > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> > --- > drivers/spi/spi-bcm2835aux.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c > index 7428091..a768c23 100644 > --- a/drivers/spi/spi-bcm2835aux.c > +++ b/drivers/spi/spi-bcm2835aux.c > @@ -363,7 +363,7 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, > * chunk getting transferred - in our case the chunk size > * is 3 bytes, so we approximate this by 9 bits/byte > */ > - xfer_time_us = tfr->len * 9 * 1000000; > + xfer_time_us = tfr->len * 9ULL * 1000000; > do_div(xfer_time_us, spi_used_hz); > > /* run in polling mode for short transfers */ > -- > 2.7.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel at lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-08 9:54 ` Ard Biesheuvel 0 siblings, 0 replies; 32+ messages in thread From: Ard Biesheuvel @ 2018-02-08 9:54 UTC (permalink / raw) To: Gustavo A. R. Silva Cc: Stefan Wahren, Florian Fainelli, Scott Branden, Ray Jui, Linux Kernel Mailing List, linux-spi, Eric Anholt, Mark Brown, bcm-kernel-feedback-list, linux-rpi-kernel, Gustavo A. R. Silva, linux-arm-kernel On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> wrote: > Add suffix ULL to constant 9 in order to give the compiler complete > information about the proper arithmetic to use. Notice that this > constant is used in a context that expects an expression of type > unsigned long long (64 bits, unsigned). > > The expression tfr->len * 9 * 1000000 is currently being evaluated > using 32-bit arithmetic. > > Addresses-Coverity-ID: 1339619 What does this number mean? If it is an index into some internal database, please remove it. > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> > --- > drivers/spi/spi-bcm2835aux.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c > index 7428091..a768c23 100644 > --- a/drivers/spi/spi-bcm2835aux.c > +++ b/drivers/spi/spi-bcm2835aux.c > @@ -363,7 +363,7 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, > * chunk getting transferred - in our case the chunk size > * is 3 bytes, so we approximate this by 9 bits/byte > */ > - xfer_time_us = tfr->len * 9 * 1000000; > + xfer_time_us = tfr->len * 9ULL * 1000000; > do_div(xfer_time_us, spi_used_hz); > > /* run in polling mode for short transfers */ > -- > 2.7.4 > > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit 2018-02-08 9:54 ` Ard Biesheuvel @ 2018-02-12 18:04 ` Gustavo A. R. Silva -1 siblings, 0 replies; 32+ messages in thread From: Gustavo A. R. Silva @ 2018-02-12 18:04 UTC (permalink / raw) To: Ard Biesheuvel, Gustavo A. R. Silva Cc: Mark Brown, Eric Anholt, Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Linux Kernel Mailing List, linux-rpi-kernel, linux-arm-kernel, linux-spi Hi Ard, On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: > On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> wrote: >> Add suffix ULL to constant 9 in order to give the compiler complete >> information about the proper arithmetic to use. Notice that this >> constant is used in a context that expects an expression of type >> unsigned long long (64 bits, unsigned). >> >> The expression tfr->len * 9 * 1000000 is currently being evaluated >> using 32-bit arithmetic. >> >> Addresses-Coverity-ID: 1339619 > > What does this number mean? If it is an index into some internal > database, please remove it. > This is a unique Coverity identifier. We want to keep information like public Bugzilla IDs and tools like Coverity on the commit message. Thanks -- Gustavo ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 18:04 ` Gustavo A. R. Silva 0 siblings, 0 replies; 32+ messages in thread From: Gustavo A. R. Silva @ 2018-02-12 18:04 UTC (permalink / raw) To: linux-arm-kernel Hi Ard, On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: > On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> wrote: >> Add suffix ULL to constant 9 in order to give the compiler complete >> information about the proper arithmetic to use. Notice that this >> constant is used in a context that expects an expression of type >> unsigned long long (64 bits, unsigned). >> >> The expression tfr->len * 9 * 1000000 is currently being evaluated >> using 32-bit arithmetic. >> >> Addresses-Coverity-ID: 1339619 > > What does this number mean? If it is an index into some internal > database, please remove it. > This is a unique Coverity identifier. We want to keep information like public Bugzilla IDs and tools like Coverity on the commit message. Thanks -- Gustavo ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit 2018-02-12 18:04 ` Gustavo A. R. Silva @ 2018-02-12 18:45 ` Ard Biesheuvel -1 siblings, 0 replies; 32+ messages in thread From: Ard Biesheuvel @ 2018-02-12 18:45 UTC (permalink / raw) To: Gustavo A. R. Silva Cc: Gustavo A. R. Silva, Mark Brown, Eric Anholt, Stefan Wahren, Florian Fainelli, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Linux Kernel Mailing List, linux-rpi-kernel, linux-arm-kernel, linux-spi On 12 February 2018 at 18:04, Gustavo A. R. Silva <garsilva@embeddedor.com> wrote: > Hi Ard, > > On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >> >> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> >> wrote: >>> >>> Add suffix ULL to constant 9 in order to give the compiler complete >>> information about the proper arithmetic to use. Notice that this >>> constant is used in a context that expects an expression of type >>> unsigned long long (64 bits, unsigned). >>> >>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>> using 32-bit arithmetic. >>> >>> Addresses-Coverity-ID: 1339619 >> >> >> What does this number mean? If it is an index into some internal >> database, please remove it. >> > > This is a unique Coverity identifier. We want to keep information like > public Bugzilla IDs and tools like Coverity on the commit message. > Who is 'we' in this case? And how is this id to any benefit of other people that have been excluded from 'we'? If you add identifiers like this, make sure that they don't only make sense to the in-crowd. For instance, you could replace this with a http link to the database entry if you really must. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 18:45 ` Ard Biesheuvel 0 siblings, 0 replies; 32+ messages in thread From: Ard Biesheuvel @ 2018-02-12 18:45 UTC (permalink / raw) To: linux-arm-kernel On 12 February 2018 at 18:04, Gustavo A. R. Silva <garsilva@embeddedor.com> wrote: > Hi Ard, > > On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >> >> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> >> wrote: >>> >>> Add suffix ULL to constant 9 in order to give the compiler complete >>> information about the proper arithmetic to use. Notice that this >>> constant is used in a context that expects an expression of type >>> unsigned long long (64 bits, unsigned). >>> >>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>> using 32-bit arithmetic. >>> >>> Addresses-Coverity-ID: 1339619 >> >> >> What does this number mean? If it is an index into some internal >> database, please remove it. >> > > This is a unique Coverity identifier. We want to keep information like > public Bugzilla IDs and tools like Coverity on the commit message. > Who is 'we' in this case? And how is this id to any benefit of other people that have been excluded from 'we'? If you add identifiers like this, make sure that they don't only make sense to the in-crowd. For instance, you could replace this with a http link to the database entry if you really must. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:10 ` Florian Fainelli 0 siblings, 0 replies; 32+ messages in thread From: Florian Fainelli @ 2018-02-12 19:10 UTC (permalink / raw) To: Ard Biesheuvel, Gustavo A. R. Silva Cc: Gustavo A. R. Silva, Mark Brown, Eric Anholt, Stefan Wahren, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Linux Kernel Mailing List, linux-rpi-kernel, linux-arm-kernel, linux-spi On 02/12/2018 10:45 AM, Ard Biesheuvel wrote: > On 12 February 2018 at 18:04, Gustavo A. R. Silva > <garsilva@embeddedor.com> wrote: >> Hi Ard, >> >> On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >>> >>> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> >>> wrote: >>>> >>>> Add suffix ULL to constant 9 in order to give the compiler complete >>>> information about the proper arithmetic to use. Notice that this >>>> constant is used in a context that expects an expression of type >>>> unsigned long long (64 bits, unsigned). >>>> >>>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>>> using 32-bit arithmetic. >>>> >>>> Addresses-Coverity-ID: 1339619 >>> >>> >>> What does this number mean? If it is an index into some internal >>> database, please remove it. >>> >> >> This is a unique Coverity identifier. We want to keep information like >> public Bugzilla IDs and tools like Coverity on the commit message. >> > > Who is 'we' in this case? And how is this id to any benefit of other > people that have been excluded from 'we'? We is probably the greater Linux community here. > > If you add identifiers like this, make sure that they don't only make > sense to the in-crowd. For instance, you could replace this with a > http link to the database entry if you really must. I don't think it is that easy to extract good URLs from the public Linux coverity instance which is why referring to coverity IDs is being done AFAICT. -- Florian ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:10 ` Florian Fainelli 0 siblings, 0 replies; 32+ messages in thread From: Florian Fainelli @ 2018-02-12 19:10 UTC (permalink / raw) To: linux-arm-kernel On 02/12/2018 10:45 AM, Ard Biesheuvel wrote: > On 12 February 2018 at 18:04, Gustavo A. R. Silva > <garsilva@embeddedor.com> wrote: >> Hi Ard, >> >> On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >>> >>> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> >>> wrote: >>>> >>>> Add suffix ULL to constant 9 in order to give the compiler complete >>>> information about the proper arithmetic to use. Notice that this >>>> constant is used in a context that expects an expression of type >>>> unsigned long long (64 bits, unsigned). >>>> >>>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>>> using 32-bit arithmetic. >>>> >>>> Addresses-Coverity-ID: 1339619 >>> >>> >>> What does this number mean? If it is an index into some internal >>> database, please remove it. >>> >> >> This is a unique Coverity identifier. We want to keep information like >> public Bugzilla IDs and tools like Coverity on the commit message. >> > > Who is 'we' in this case? And how is this id to any benefit of other > people that have been excluded from 'we'? We is probably the greater Linux community here. > > If you add identifiers like this, make sure that they don't only make > sense to the in-crowd. For instance, you could replace this with a > http link to the database entry if you really must. I don't think it is that easy to extract good URLs from the public Linux coverity instance which is why referring to coverity IDs is being done AFAICT. -- Florian ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:10 ` Florian Fainelli 0 siblings, 0 replies; 32+ messages in thread From: Florian Fainelli @ 2018-02-12 19:10 UTC (permalink / raw) To: Ard Biesheuvel, Gustavo A. R. Silva Cc: Gustavo A. R. Silva, Mark Brown, Eric Anholt, Stefan Wahren, Ray Jui, Scott Branden, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Linux Kernel Mailing List, linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel, linux-spi-u79uwXL29TY76Z2rM5mHXA On 02/12/2018 10:45 AM, Ard Biesheuvel wrote: > On 12 February 2018 at 18:04, Gustavo A. R. Silva > <garsilva-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org> wrote: >> Hi Ard, >> >> On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >>> >>> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org> >>> wrote: >>>> >>>> Add suffix ULL to constant 9 in order to give the compiler complete >>>> information about the proper arithmetic to use. Notice that this >>>> constant is used in a context that expects an expression of type >>>> unsigned long long (64 bits, unsigned). >>>> >>>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>>> using 32-bit arithmetic. >>>> >>>> Addresses-Coverity-ID: 1339619 >>> >>> >>> What does this number mean? If it is an index into some internal >>> database, please remove it. >>> >> >> This is a unique Coverity identifier. We want to keep information like >> public Bugzilla IDs and tools like Coverity on the commit message. >> > > Who is 'we' in this case? And how is this id to any benefit of other > people that have been excluded from 'we'? We is probably the greater Linux community here. > > If you add identifiers like this, make sure that they don't only make > sense to the in-crowd. For instance, you could replace this with a > http link to the database entry if you really must. I don't think it is that easy to extract good URLs from the public Linux coverity instance which is why referring to coverity IDs is being done AFAICT. -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:11 ` Ard Biesheuvel 0 siblings, 0 replies; 32+ messages in thread From: Ard Biesheuvel @ 2018-02-12 19:11 UTC (permalink / raw) To: Florian Fainelli Cc: Gustavo A. R. Silva, Gustavo A. R. Silva, Mark Brown, Eric Anholt, Stefan Wahren, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Linux Kernel Mailing List, linux-rpi-kernel, linux-arm-kernel, linux-spi On 12 February 2018 at 19:10, Florian Fainelli <f.fainelli@gmail.com> wrote: > On 02/12/2018 10:45 AM, Ard Biesheuvel wrote: >> On 12 February 2018 at 18:04, Gustavo A. R. Silva >> <garsilva@embeddedor.com> wrote: >>> Hi Ard, >>> >>> On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >>>> >>>> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> >>>> wrote: >>>>> >>>>> Add suffix ULL to constant 9 in order to give the compiler complete >>>>> information about the proper arithmetic to use. Notice that this >>>>> constant is used in a context that expects an expression of type >>>>> unsigned long long (64 bits, unsigned). >>>>> >>>>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>>>> using 32-bit arithmetic. >>>>> >>>>> Addresses-Coverity-ID: 1339619 >>>> >>>> >>>> What does this number mean? If it is an index into some internal >>>> database, please remove it. >>>> >>> >>> This is a unique Coverity identifier. We want to keep information like >>> public Bugzilla IDs and tools like Coverity on the commit message. >>> >> >> Who is 'we' in this case? And how is this id to any benefit of other >> people that have been excluded from 'we'? > > We is probably the greater Linux community here. > >> >> If you add identifiers like this, make sure that they don't only make >> sense to the in-crowd. For instance, you could replace this with a >> http link to the database entry if you really must. > > I don't think it is that easy to extract good URLs from the public Linux > coverity instance which is why referring to coverity IDs is being done > AFAICT. Ah ok, pardon my ignorance then. I wasn't aware there is a public Linux coverity instance. Got a link? ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:11 ` Ard Biesheuvel 0 siblings, 0 replies; 32+ messages in thread From: Ard Biesheuvel @ 2018-02-12 19:11 UTC (permalink / raw) To: linux-arm-kernel On 12 February 2018 at 19:10, Florian Fainelli <f.fainelli@gmail.com> wrote: > On 02/12/2018 10:45 AM, Ard Biesheuvel wrote: >> On 12 February 2018 at 18:04, Gustavo A. R. Silva >> <garsilva@embeddedor.com> wrote: >>> Hi Ard, >>> >>> On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >>>> >>>> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> >>>> wrote: >>>>> >>>>> Add suffix ULL to constant 9 in order to give the compiler complete >>>>> information about the proper arithmetic to use. Notice that this >>>>> constant is used in a context that expects an expression of type >>>>> unsigned long long (64 bits, unsigned). >>>>> >>>>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>>>> using 32-bit arithmetic. >>>>> >>>>> Addresses-Coverity-ID: 1339619 >>>> >>>> >>>> What does this number mean? If it is an index into some internal >>>> database, please remove it. >>>> >>> >>> This is a unique Coverity identifier. We want to keep information like >>> public Bugzilla IDs and tools like Coverity on the commit message. >>> >> >> Who is 'we' in this case? And how is this id to any benefit of other >> people that have been excluded from 'we'? > > We is probably the greater Linux community here. > >> >> If you add identifiers like this, make sure that they don't only make >> sense to the in-crowd. For instance, you could replace this with a >> http link to the database entry if you really must. > > I don't think it is that easy to extract good URLs from the public Linux > coverity instance which is why referring to coverity IDs is being done > AFAICT. Ah ok, pardon my ignorance then. I wasn't aware there is a public Linux coverity instance. Got a link? ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:11 ` Ard Biesheuvel 0 siblings, 0 replies; 32+ messages in thread From: Ard Biesheuvel @ 2018-02-12 19:11 UTC (permalink / raw) To: Florian Fainelli Cc: Gustavo A. R. Silva, Gustavo A. R. Silva, Mark Brown, Eric Anholt, Stefan Wahren, Ray Jui, Scott Branden, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Linux Kernel Mailing List, linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel, linux-spi-u79uwXL29TY76Z2rM5mHXA On 12 February 2018 at 19:10, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > On 02/12/2018 10:45 AM, Ard Biesheuvel wrote: >> On 12 February 2018 at 18:04, Gustavo A. R. Silva >> <garsilva-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org> wrote: >>> Hi Ard, >>> >>> On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >>>> >>>> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org> >>>> wrote: >>>>> >>>>> Add suffix ULL to constant 9 in order to give the compiler complete >>>>> information about the proper arithmetic to use. Notice that this >>>>> constant is used in a context that expects an expression of type >>>>> unsigned long long (64 bits, unsigned). >>>>> >>>>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>>>> using 32-bit arithmetic. >>>>> >>>>> Addresses-Coverity-ID: 1339619 >>>> >>>> >>>> What does this number mean? If it is an index into some internal >>>> database, please remove it. >>>> >>> >>> This is a unique Coverity identifier. We want to keep information like >>> public Bugzilla IDs and tools like Coverity on the commit message. >>> >> >> Who is 'we' in this case? And how is this id to any benefit of other >> people that have been excluded from 'we'? > > We is probably the greater Linux community here. > >> >> If you add identifiers like this, make sure that they don't only make >> sense to the in-crowd. For instance, you could replace this with a >> http link to the database entry if you really must. > > I don't think it is that easy to extract good URLs from the public Linux > coverity instance which is why referring to coverity IDs is being done > AFAICT. Ah ok, pardon my ignorance then. I wasn't aware there is a public Linux coverity instance. Got a link? -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:14 ` Florian Fainelli 0 siblings, 0 replies; 32+ messages in thread From: Florian Fainelli @ 2018-02-12 19:14 UTC (permalink / raw) To: Ard Biesheuvel, Florian Fainelli Cc: Gustavo A. R. Silva, Gustavo A. R. Silva, Mark Brown, Eric Anholt, Stefan Wahren, Ray Jui, Scott Branden, bcm-kernel-feedback-list, Linux Kernel Mailing List, linux-rpi-kernel, linux-arm-kernel, linux-spi On 02/12/2018 11:11 AM, Ard Biesheuvel wrote: > On 12 February 2018 at 19:10, Florian Fainelli <f.fainelli@gmail.com> wrote: >> On 02/12/2018 10:45 AM, Ard Biesheuvel wrote: >>> On 12 February 2018 at 18:04, Gustavo A. R. Silva >>> <garsilva@embeddedor.com> wrote: >>>> Hi Ard, >>>> >>>> On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >>>>> >>>>> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> >>>>> wrote: >>>>>> >>>>>> Add suffix ULL to constant 9 in order to give the compiler complete >>>>>> information about the proper arithmetic to use. Notice that this >>>>>> constant is used in a context that expects an expression of type >>>>>> unsigned long long (64 bits, unsigned). >>>>>> >>>>>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>>>>> using 32-bit arithmetic. >>>>>> >>>>>> Addresses-Coverity-ID: 1339619 >>>>> >>>>> >>>>> What does this number mean? If it is an index into some internal >>>>> database, please remove it. >>>>> >>>> >>>> This is a unique Coverity identifier. We want to keep information like >>>> public Bugzilla IDs and tools like Coverity on the commit message. >>>> >>> >>> Who is 'we' in this case? And how is this id to any benefit of other >>> people that have been excluded from 'we'? >> >> We is probably the greater Linux community here. >> >>> >>> If you add identifiers like this, make sure that they don't only make >>> sense to the in-crowd. For instance, you could replace this with a >>> http link to the database entry if you really must. >> >> I don't think it is that easy to extract good URLs from the public Linux >> coverity instance which is why referring to coverity IDs is being done >> AFAICT. > > Ah ok, pardon my ignorance then. I wasn't aware there is a public > Linux coverity instance. Got a link? It requires you to sign up to get notifications and have a dashboard, does this link work for you? https://scan.coverity.com/projects/linux?tab=overview -- Florian ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:14 ` Florian Fainelli 0 siblings, 0 replies; 32+ messages in thread From: Florian Fainelli @ 2018-02-12 19:14 UTC (permalink / raw) To: linux-arm-kernel On 02/12/2018 11:11 AM, Ard Biesheuvel wrote: > On 12 February 2018 at 19:10, Florian Fainelli <f.fainelli@gmail.com> wrote: >> On 02/12/2018 10:45 AM, Ard Biesheuvel wrote: >>> On 12 February 2018 at 18:04, Gustavo A. R. Silva >>> <garsilva@embeddedor.com> wrote: >>>> Hi Ard, >>>> >>>> On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >>>>> >>>>> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo@embeddedor.com> >>>>> wrote: >>>>>> >>>>>> Add suffix ULL to constant 9 in order to give the compiler complete >>>>>> information about the proper arithmetic to use. Notice that this >>>>>> constant is used in a context that expects an expression of type >>>>>> unsigned long long (64 bits, unsigned). >>>>>> >>>>>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>>>>> using 32-bit arithmetic. >>>>>> >>>>>> Addresses-Coverity-ID: 1339619 >>>>> >>>>> >>>>> What does this number mean? If it is an index into some internal >>>>> database, please remove it. >>>>> >>>> >>>> This is a unique Coverity identifier. We want to keep information like >>>> public Bugzilla IDs and tools like Coverity on the commit message. >>>> >>> >>> Who is 'we' in this case? And how is this id to any benefit of other >>> people that have been excluded from 'we'? >> >> We is probably the greater Linux community here. >> >>> >>> If you add identifiers like this, make sure that they don't only make >>> sense to the in-crowd. For instance, you could replace this with a >>> http link to the database entry if you really must. >> >> I don't think it is that easy to extract good URLs from the public Linux >> coverity instance which is why referring to coverity IDs is being done >> AFAICT. > > Ah ok, pardon my ignorance then. I wasn't aware there is a public > Linux coverity instance. Got a link? It requires you to sign up to get notifications and have a dashboard, does this link work for you? https://scan.coverity.com/projects/linux?tab=overview -- Florian ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:14 ` Florian Fainelli 0 siblings, 0 replies; 32+ messages in thread From: Florian Fainelli @ 2018-02-12 19:14 UTC (permalink / raw) To: Ard Biesheuvel, Florian Fainelli Cc: Gustavo A. R. Silva, Gustavo A. R. Silva, Mark Brown, Eric Anholt, Stefan Wahren, Ray Jui, Scott Branden, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, Linux Kernel Mailing List, linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel, linux-spi-u79uwXL29TY76Z2rM5mHXA On 02/12/2018 11:11 AM, Ard Biesheuvel wrote: > On 12 February 2018 at 19:10, Florian Fainelli <f.fainelli-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: >> On 02/12/2018 10:45 AM, Ard Biesheuvel wrote: >>> On 12 February 2018 at 18:04, Gustavo A. R. Silva >>> <garsilva-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org> wrote: >>>> Hi Ard, >>>> >>>> On 02/08/2018 03:54 AM, Ard Biesheuvel wrote: >>>>> >>>>> On 7 February 2018 at 16:00, Gustavo A. R. Silva <gustavo-L1vi/lXTdts+Va1GwOuvDg@public.gmane.org> >>>>> wrote: >>>>>> >>>>>> Add suffix ULL to constant 9 in order to give the compiler complete >>>>>> information about the proper arithmetic to use. Notice that this >>>>>> constant is used in a context that expects an expression of type >>>>>> unsigned long long (64 bits, unsigned). >>>>>> >>>>>> The expression tfr->len * 9 * 1000000 is currently being evaluated >>>>>> using 32-bit arithmetic. >>>>>> >>>>>> Addresses-Coverity-ID: 1339619 >>>>> >>>>> >>>>> What does this number mean? If it is an index into some internal >>>>> database, please remove it. >>>>> >>>> >>>> This is a unique Coverity identifier. We want to keep information like >>>> public Bugzilla IDs and tools like Coverity on the commit message. >>>> >>> >>> Who is 'we' in this case? And how is this id to any benefit of other >>> people that have been excluded from 'we'? >> >> We is probably the greater Linux community here. >> >>> >>> If you add identifiers like this, make sure that they don't only make >>> sense to the in-crowd. For instance, you could replace this with a >>> http link to the database entry if you really must. >> >> I don't think it is that easy to extract good URLs from the public Linux >> coverity instance which is why referring to coverity IDs is being done >> AFAICT. > > Ah ok, pardon my ignorance then. I wasn't aware there is a public > Linux coverity instance. Got a link? It requires you to sign up to get notifications and have a dashboard, does this link work for you? https://scan.coverity.com/projects/linux?tab=overview -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit 2018-02-07 16:00 ` Gustavo A. R. Silva (?) @ 2018-02-12 19:31 ` Trent Piepho -1 siblings, 0 replies; 32+ messages in thread From: Trent Piepho @ 2018-02-12 19:31 UTC (permalink / raw) To: gustavo, bcm-kernel-feedback-list, stefan.wahren, f.fainelli, broonie, eric, rjui, sbranden Cc: linux-spi, linux-rpi-kernel, linux-kernel, linux-arm-kernel, garsilva On Wed, 2018-02-07 at 10:00 -0600, Gustavo A. R. Silva wrote: > Add suffix ULL to constant 9 in order to give the compiler complete > information about the proper arithmetic to use. Notice that this > constant is used in a context that expects an expression of type > unsigned long long (64 bits, unsigned). > > The expression tfr->len * 9 * 1000000 is currently being evaluated > using 32-bit arithmetic. > > Addresses-Coverity-ID: 1339619 > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> > --- > drivers/spi/spi-bcm2835aux.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c > index 7428091..a768c23 100644 > --- a/drivers/spi/spi-bcm2835aux.c > +++ b/drivers/spi/spi-bcm2835aux.c > @@ -363,7 +363,7 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, > * chunk getting transferred - in our case the chunk size > * is 3 bytes, so we approximate this by 9 bits/byte > */ > - xfer_time_us = tfr->len * 9 * 1000000; > + xfer_time_us = tfr->len * 9ULL * 1000000; > do_div(xfer_time_us, spi_used_hz); > > /* run in polling mode for short transfers */ if (xfer_time_us < BCM2835_AUX_SPI_POLLING_LIMIT_US) If one looks at the logic as a whole... tfr->len * 9ULL * 100000 / spi_used_hz < 30 A little algebra can change that into: tfr->len < spi_used_hz / 300000 So rather than add more 64-bit math, it can be removed entirely. Both the length and speed are 32 bits and there's no need to multiply them into something larger than might need 64 bits. ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:31 ` Trent Piepho 0 siblings, 0 replies; 32+ messages in thread From: Trent Piepho @ 2018-02-12 19:31 UTC (permalink / raw) To: linux-arm-kernel On Wed, 2018-02-07 at 10:00 -0600, Gustavo A. R. Silva wrote: > Add suffix ULL to constant 9 in order to give the compiler complete > information about the proper arithmetic to use. Notice that this > constant is used in a context that expects an expression of type > unsigned long long (64 bits, unsigned). > > The expression tfr->len * 9 * 1000000 is currently being evaluated > using 32-bit arithmetic. > > Addresses-Coverity-ID: 1339619 > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> > --- > drivers/spi/spi-bcm2835aux.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c > index 7428091..a768c23 100644 > --- a/drivers/spi/spi-bcm2835aux.c > +++ b/drivers/spi/spi-bcm2835aux.c > @@ -363,7 +363,7 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, > * chunk getting transferred - in our case the chunk size > * is 3 bytes, so we approximate this by 9 bits/byte > */ > - xfer_time_us = tfr->len * 9 * 1000000; > + xfer_time_us = tfr->len * 9ULL * 1000000; > do_div(xfer_time_us, spi_used_hz); > > /* run in polling mode for short transfers */ if (xfer_time_us < BCM2835_AUX_SPI_POLLING_LIMIT_US) If one looks@the logic as a whole... tfr->len * 9ULL * 100000 / spi_used_hz < 30 A little algebra can change that into: tfr->len < spi_used_hz / 300000 So rather than add more 64-bit math, it can be removed entirely. Both the length and speed are 32 bits and there's no need to multiply them into something larger than might need 64 bits. ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit @ 2018-02-12 19:31 ` Trent Piepho 0 siblings, 0 replies; 32+ messages in thread From: Trent Piepho @ 2018-02-12 19:31 UTC (permalink / raw) To: gustavo-L1vi/lXTdts+Va1GwOuvDg, bcm-kernel-feedback-list-dY08KVG/lbpWk0Htik3J/w, stefan.wahren-eS4NqCHxEME, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w, broonie-DgEjT+Ai2ygdnm+yROfE0A, eric-WhKQ6XTQaPysTnJN9+BGXg, rjui-dY08KVG/lbpWk0Htik3J/w, sbranden-dY08KVG/lbpWk0Htik3J/w Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, garsilva-L1vi/lXTdts+Va1GwOuvDg [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="utf-8", Size: 1755 bytes --] On Wed, 2018-02-07 at 10:00 -0600, Gustavo A. R. Silva wrote: > Add suffix ULL to constant 9 in order to give the compiler complete > information about the proper arithmetic to use. Notice that this > constant is used in a context that expects an expression of type > unsigned long long (64 bits, unsigned). > > The expression tfr->len * 9 * 1000000 is currently being evaluated > using 32-bit arithmetic. > > Addresses-Coverity-ID: 1339619 > Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com> > --- > drivers/spi/spi-bcm2835aux.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c > index 7428091..a768c23 100644 > --- a/drivers/spi/spi-bcm2835aux.c > +++ b/drivers/spi/spi-bcm2835aux.c > @@ -363,7 +363,7 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, > * chunk getting transferred - in our case the chunk size > * is 3 bytes, so we approximate this by 9 bits/byte > */ > - xfer_time_us = tfr->len * 9 * 1000000; > + xfer_time_us = tfr->len * 9ULL * 1000000; > do_div(xfer_time_us, spi_used_hz); > > /* run in polling mode for short transfers */ if (xfer_time_us < BCM2835_AUX_SPI_POLLING_LIMIT_US) If one looks at the logic as a whole... tfr->len * 9ULL * 100000 / spi_used_hz < 30 A little algebra can change that into: tfr->len < spi_used_hz / 300000 So rather than add more 64-bit math, it can be removed entirely. Both the length and speed are 32 bits and there's no need to multiply them into something larger than might need 64 bits. N§²æìr¸yúèØb²X¬¶Ç§vØ^)Þº{.nÇ+·¥{±²¢Ø^nr¡ö¦zË\x1aëh¨èÚ&¢îý»\x05ËÛÔØï¦v¬Îf\x1dp)¹¹br ê+Ê+zf£¢·h§~Ûiÿûàz¹\x1e®w¥¢¸?¨èÚ&¢)ߢ^[f ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc 2018-02-12 19:31 ` Trent Piepho @ 2018-02-12 19:38 ` Trent Piepho -1 siblings, 0 replies; 32+ messages in thread From: Trent Piepho @ 2018-02-12 19:38 UTC (permalink / raw) To: linux-spi, linux-rpi-kernel, linux-arm-kernel, linux-kernel Cc: Gustavo A . R . Silva, Mark Brown, Eric Anholt, Stefan Wahren, Florian Fainelli, Ray Jui, Trent Piepho We want to check for xfers that are over 30 microseconds. Rather than find how many µs a xfer will take, instead find how many bytes can be transferred in 30 µs. The latter must be less than 32 bits (since our clock speed is limited to 32 bits), while the former involves 64 bit quantities and more arithmetic operations. Signed-off-by: Trent Piepho <tpiepho@impinj.com> --- drivers/spi/spi-bcm2835aux.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c index 7428091d3f5b..1431cb98fe40 100644 --- a/drivers/spi/spi-bcm2835aux.c +++ b/drivers/spi/spi-bcm2835aux.c @@ -321,7 +321,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, struct bcm2835aux_spi *bs = spi_master_get_devdata(master); unsigned long spi_hz, clk_hz, speed; unsigned long spi_used_hz; - unsigned long long xfer_time_us; /* calculate the registers to handle * @@ -358,20 +357,21 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, bs->rx_len = tfr->len; bs->pending = 0; - /* calculate the estimated time in us the transfer runs - * note that there are are 2 idle clocks after each - * chunk getting transferred - in our case the chunk size - * is 3 bytes, so we approximate this by 9 bits/byte + /* Calculate the estimated time in us the transfer runs. Note that + * there are are 2 idle clocks cycles after each chunk getting + * transferred - in our case the chunk size is 3 bytes, so we + * approximate this by 9 cycles/byte. This is used to find the number + * of Hz per byte per polling limit. E.g., we can transfer 1 byte in + * 30 µs per 300,000 Hz of bus clock. */ - xfer_time_us = tfr->len * 9 * 1000000; - do_div(xfer_time_us, spi_used_hz); - +#define HZ_PER_BYTE ((9 * 1000000) / BCM2835_AUX_SPI_POLLING_LIMIT_US) /* run in polling mode for short transfers */ - if (xfer_time_us < BCM2835_AUX_SPI_POLLING_LIMIT_US) + if (tfr->len < spi_used_hz / HZ_PER_BYTE) return bcm2835aux_spi_transfer_one_poll(master, spi, tfr); /* run in interrupt mode for all others */ return bcm2835aux_spi_transfer_one_irq(master, spi, tfr); +#undef HZ_PER_BYTE } static int bcm2835aux_spi_prepare_message(struct spi_master *master, -- 2.14.3 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc @ 2018-02-12 19:38 ` Trent Piepho 0 siblings, 0 replies; 32+ messages in thread From: Trent Piepho @ 2018-02-12 19:38 UTC (permalink / raw) To: linux-arm-kernel We want to check for xfers that are over 30 microseconds. Rather than find how many ?s a xfer will take, instead find how many bytes can be transferred in 30 ?s. The latter must be less than 32 bits (since our clock speed is limited to 32 bits), while the former involves 64 bit quantities and more arithmetic operations. Signed-off-by: Trent Piepho <tpiepho@impinj.com> --- drivers/spi/spi-bcm2835aux.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c index 7428091d3f5b..1431cb98fe40 100644 --- a/drivers/spi/spi-bcm2835aux.c +++ b/drivers/spi/spi-bcm2835aux.c @@ -321,7 +321,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, struct bcm2835aux_spi *bs = spi_master_get_devdata(master); unsigned long spi_hz, clk_hz, speed; unsigned long spi_used_hz; - unsigned long long xfer_time_us; /* calculate the registers to handle * @@ -358,20 +357,21 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, bs->rx_len = tfr->len; bs->pending = 0; - /* calculate the estimated time in us the transfer runs - * note that there are are 2 idle clocks after each - * chunk getting transferred - in our case the chunk size - * is 3 bytes, so we approximate this by 9 bits/byte + /* Calculate the estimated time in us the transfer runs. Note that + * there are are 2 idle clocks cycles after each chunk getting + * transferred - in our case the chunk size is 3 bytes, so we + * approximate this by 9 cycles/byte. This is used to find the number + * of Hz per byte per polling limit. E.g., we can transfer 1 byte in + * 30 ?s per 300,000 Hz of bus clock. */ - xfer_time_us = tfr->len * 9 * 1000000; - do_div(xfer_time_us, spi_used_hz); - +#define HZ_PER_BYTE ((9 * 1000000) / BCM2835_AUX_SPI_POLLING_LIMIT_US) /* run in polling mode for short transfers */ - if (xfer_time_us < BCM2835_AUX_SPI_POLLING_LIMIT_US) + if (tfr->len < spi_used_hz / HZ_PER_BYTE) return bcm2835aux_spi_transfer_one_poll(master, spi, tfr); /* run in interrupt mode for all others */ return bcm2835aux_spi_transfer_one_irq(master, spi, tfr); +#undef HZ_PER_BYTE } static int bcm2835aux_spi_prepare_message(struct spi_master *master, -- 2.14.3 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc @ 2018-02-14 16:04 ` Mark Brown 0 siblings, 0 replies; 32+ messages in thread From: Mark Brown @ 2018-02-14 16:04 UTC (permalink / raw) To: Trent Piepho Cc: linux-spi, linux-rpi-kernel, linux-arm-kernel, linux-kernel, Gustavo A . R . Silva, Eric Anholt, Stefan Wahren, Florian Fainelli, Ray Jui [-- Attachment #1: Type: text/plain, Size: 505 bytes --] On Mon, Feb 12, 2018 at 11:38:14AM -0800, Trent Piepho wrote: > We want to check for xfers that are over 30 microseconds. Rather than > find how many µs a xfer will take, instead find how many bytes can be > transferred in 30 µs. The latter must be less than 32 bits (since our > clock speed is limited to 32 bits), while the former involves 64 bit > quantities and more arithmetic operations. Please don't bury patches in the middle of existing threads, it makes it much harder to find them. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* [PATCH] spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc @ 2018-02-14 16:04 ` Mark Brown 0 siblings, 0 replies; 32+ messages in thread From: Mark Brown @ 2018-02-14 16:04 UTC (permalink / raw) To: linux-arm-kernel On Mon, Feb 12, 2018 at 11:38:14AM -0800, Trent Piepho wrote: > We want to check for xfers that are over 30 microseconds. Rather than > find how many ?s a xfer will take, instead find how many bytes can be > transferred in 30 ?s. The latter must be less than 32 bits (since our > clock speed is limited to 32 bits), while the former involves 64 bit > quantities and more arithmetic operations. Please don't bury patches in the middle of existing threads, it makes it much harder to find them. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180214/0cb94b3d/attachment-0001.sig> ^ permalink raw reply [flat|nested] 32+ messages in thread
* Re: [PATCH] spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc @ 2018-02-14 16:04 ` Mark Brown 0 siblings, 0 replies; 32+ messages in thread From: Mark Brown @ 2018-02-14 16:04 UTC (permalink / raw) To: Trent Piepho Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA, linux-rpi-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Gustavo A . R . Silva, Eric Anholt, Stefan Wahren, Florian Fainelli, Ray Jui [-- Attachment #1: Type: text/plain, Size: 505 bytes --] On Mon, Feb 12, 2018 at 11:38:14AM -0800, Trent Piepho wrote: > We want to check for xfers that are over 30 microseconds. Rather than > find how many µs a xfer will take, instead find how many bytes can be > transferred in 30 µs. The latter must be less than 32 bits (since our > clock speed is limited to 32 bits), while the former involves 64 bit > quantities and more arithmetic operations. Please don't bury patches in the middle of existing threads, it makes it much harder to find them. [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] ^ permalink raw reply [flat|nested] 32+ messages in thread
* Applied "spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc" to the spi tree 2018-02-12 19:38 ` Trent Piepho @ 2018-02-14 16:28 ` Mark Brown -1 siblings, 0 replies; 32+ messages in thread From: Mark Brown @ 2018-02-14 16:28 UTC (permalink / raw) To: Trent Piepho Cc: Mark Brown, linux-spi, linux-rpi-kernel, linux-arm-kernel, linux-kernel, Gustavo A . R . Silva, Mark Brown, Eric Anholt, Stefan Wahren, Florian Fainelli, Ray Jui, linux-spi [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 3598 bytes --] The patch spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc has been applied to the spi tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From d704afffe65c8fab424963c1ba4ec4364c2d6a82 Mon Sep 17 00:00:00 2001 From: Trent Piepho <tpiepho@impinj.com> Date: Mon, 12 Feb 2018 11:38:14 -0800 Subject: [PATCH] spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We want to check for xfers that are over 30 microseconds. Rather than find how many µs a xfer will take, instead find how many bytes can be transferred in 30 µs. The latter must be less than 32 bits (since our clock speed is limited to 32 bits), while the former involves 64 bit quantities and more arithmetic operations. Signed-off-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: Mark Brown <broonie@kernel.org> --- drivers/spi/spi-bcm2835aux.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c index 7428091d3f5b..1431cb98fe40 100644 --- a/drivers/spi/spi-bcm2835aux.c +++ b/drivers/spi/spi-bcm2835aux.c @@ -321,7 +321,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, struct bcm2835aux_spi *bs = spi_master_get_devdata(master); unsigned long spi_hz, clk_hz, speed; unsigned long spi_used_hz; - unsigned long long xfer_time_us; /* calculate the registers to handle * @@ -358,20 +357,21 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, bs->rx_len = tfr->len; bs->pending = 0; - /* calculate the estimated time in us the transfer runs - * note that there are are 2 idle clocks after each - * chunk getting transferred - in our case the chunk size - * is 3 bytes, so we approximate this by 9 bits/byte + /* Calculate the estimated time in us the transfer runs. Note that + * there are are 2 idle clocks cycles after each chunk getting + * transferred - in our case the chunk size is 3 bytes, so we + * approximate this by 9 cycles/byte. This is used to find the number + * of Hz per byte per polling limit. E.g., we can transfer 1 byte in + * 30 µs per 300,000 Hz of bus clock. */ - xfer_time_us = tfr->len * 9 * 1000000; - do_div(xfer_time_us, spi_used_hz); - +#define HZ_PER_BYTE ((9 * 1000000) / BCM2835_AUX_SPI_POLLING_LIMIT_US) /* run in polling mode for short transfers */ - if (xfer_time_us < BCM2835_AUX_SPI_POLLING_LIMIT_US) + if (tfr->len < spi_used_hz / HZ_PER_BYTE) return bcm2835aux_spi_transfer_one_poll(master, spi, tfr); /* run in interrupt mode for all others */ return bcm2835aux_spi_transfer_one_irq(master, spi, tfr); +#undef HZ_PER_BYTE } static int bcm2835aux_spi_prepare_message(struct spi_master *master, -- 2.16.1 ^ permalink raw reply related [flat|nested] 32+ messages in thread
* Applied "spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc" to the spi tree @ 2018-02-14 16:28 ` Mark Brown 0 siblings, 0 replies; 32+ messages in thread From: Mark Brown @ 2018-02-14 16:28 UTC (permalink / raw) To: linux-arm-kernel The patch spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc has been applied to the spi tree at https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted. You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed. If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced. Please add any relevant lists and maintainers to the CCs when replying to this mail. Thanks, Mark >From d704afffe65c8fab424963c1ba4ec4364c2d6a82 Mon Sep 17 00:00:00 2001 From: Trent Piepho <tpiepho@impinj.com> Date: Mon, 12 Feb 2018 11:38:14 -0800 Subject: [PATCH] spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit We want to check for xfers that are over 30 microseconds. Rather than find how many ??s a xfer will take, instead find how many bytes can be transferred in 30 ??s. The latter must be less than 32 bits (since our clock speed is limited to 32 bits), while the former involves 64 bit quantities and more arithmetic operations. Signed-off-by: Trent Piepho <tpiepho@impinj.com> Signed-off-by: Mark Brown <broonie@kernel.org> --- drivers/spi/spi-bcm2835aux.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/spi/spi-bcm2835aux.c b/drivers/spi/spi-bcm2835aux.c index 7428091d3f5b..1431cb98fe40 100644 --- a/drivers/spi/spi-bcm2835aux.c +++ b/drivers/spi/spi-bcm2835aux.c @@ -321,7 +321,6 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, struct bcm2835aux_spi *bs = spi_master_get_devdata(master); unsigned long spi_hz, clk_hz, speed; unsigned long spi_used_hz; - unsigned long long xfer_time_us; /* calculate the registers to handle * @@ -358,20 +357,21 @@ static int bcm2835aux_spi_transfer_one(struct spi_master *master, bs->rx_len = tfr->len; bs->pending = 0; - /* calculate the estimated time in us the transfer runs - * note that there are are 2 idle clocks after each - * chunk getting transferred - in our case the chunk size - * is 3 bytes, so we approximate this by 9 bits/byte + /* Calculate the estimated time in us the transfer runs. Note that + * there are are 2 idle clocks cycles after each chunk getting + * transferred - in our case the chunk size is 3 bytes, so we + * approximate this by 9 cycles/byte. This is used to find the number + * of Hz per byte per polling limit. E.g., we can transfer 1 byte in + * 30 ??s per 300,000 Hz of bus clock. */ - xfer_time_us = tfr->len * 9 * 1000000; - do_div(xfer_time_us, spi_used_hz); - +#define HZ_PER_BYTE ((9 * 1000000) / BCM2835_AUX_SPI_POLLING_LIMIT_US) /* run in polling mode for short transfers */ - if (xfer_time_us < BCM2835_AUX_SPI_POLLING_LIMIT_US) + if (tfr->len < spi_used_hz / HZ_PER_BYTE) return bcm2835aux_spi_transfer_one_poll(master, spi, tfr); /* run in interrupt mode for all others */ return bcm2835aux_spi_transfer_one_irq(master, spi, tfr); +#undef HZ_PER_BYTE } static int bcm2835aux_spi_prepare_message(struct spi_master *master, -- 2.16.1 ^ permalink raw reply related [flat|nested] 32+ messages in thread
end of thread, other threads:[~2018-02-14 16:29 UTC | newest] Thread overview: 32+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2018-02-07 16:00 [PATCH] spi: bcm2835aux: use 64-bit arithmetic instead of 32-bit Gustavo A. R. Silva 2018-02-07 16:00 ` Gustavo A. R. Silva 2018-02-08 8:22 ` Eric Anholt 2018-02-08 8:22 ` Eric Anholt 2018-02-12 17:57 ` Gustavo A. R. Silva 2018-02-12 17:57 ` Gustavo A. R. Silva 2018-02-08 9:54 ` Ard Biesheuvel 2018-02-08 9:54 ` Ard Biesheuvel 2018-02-08 9:54 ` Ard Biesheuvel 2018-02-12 18:04 ` Gustavo A. R. Silva 2018-02-12 18:04 ` Gustavo A. R. Silva 2018-02-12 18:45 ` Ard Biesheuvel 2018-02-12 18:45 ` Ard Biesheuvel 2018-02-12 19:10 ` Florian Fainelli 2018-02-12 19:10 ` Florian Fainelli 2018-02-12 19:10 ` Florian Fainelli 2018-02-12 19:11 ` Ard Biesheuvel 2018-02-12 19:11 ` Ard Biesheuvel 2018-02-12 19:11 ` Ard Biesheuvel 2018-02-12 19:14 ` Florian Fainelli 2018-02-12 19:14 ` Florian Fainelli 2018-02-12 19:14 ` Florian Fainelli 2018-02-12 19:31 ` Trent Piepho 2018-02-12 19:31 ` Trent Piepho 2018-02-12 19:31 ` Trent Piepho 2018-02-12 19:38 ` [PATCH] spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc Trent Piepho 2018-02-12 19:38 ` Trent Piepho 2018-02-14 16:04 ` Mark Brown 2018-02-14 16:04 ` Mark Brown 2018-02-14 16:04 ` Mark Brown 2018-02-14 16:28 ` Applied "spi: bcm2835aux: Avoid 64-bit arithmetic in xfer len calc" to the spi tree Mark Brown 2018-02-14 16:28 ` Mark Brown
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.