* [PATCH RESEND] thermal: power_allocator: req_range multiplication should be a 64 bit type
@ 2015-12-01 15:15 Javi Merino
2015-12-19 13:49 ` Javi Merino
0 siblings, 1 reply; 3+ messages in thread
From: Javi Merino @ 2015-12-01 15:15 UTC (permalink / raw)
To: linux-pm; +Cc: dan.carpenter, edubezval, Javi Merino, Zhang Rui
req_range is declared as a u64 to cope with overflows in the
multiplication of two u32. As both req_power and power_range are u32,
we need to make sure the multiplication is done with u64 types.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Cc: Zhang Rui <rui.zhang@intel.com>
Cc: Eduardo Valentin <edubezval@gmail.com>
Signed-off-by: Javi Merino <javi.merino@arm.com>
---
drivers/thermal/power_allocator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/thermal/power_allocator.c b/drivers/thermal/power_allocator.c
index 1246aa6fcab0..2f1a863a8e15 100644
--- a/drivers/thermal/power_allocator.c
+++ b/drivers/thermal/power_allocator.c
@@ -301,7 +301,7 @@ static void divvy_up_power(u32 *req_power, u32 *max_power, int num_actors,
capped_extra_power = 0;
extra_power = 0;
for (i = 0; i < num_actors; i++) {
- u64 req_range = req_power[i] * power_range;
+ u64 req_range = (u64)req_power[i] * power_range;
granted_power[i] = DIV_ROUND_CLOSEST_ULL(req_range,
total_req_power);
--
1.9.1
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH RESEND] thermal: power_allocator: req_range multiplication should be a 64 bit type
2015-12-01 15:15 [PATCH RESEND] thermal: power_allocator: req_range multiplication should be a 64 bit type Javi Merino
@ 2015-12-19 13:49 ` Javi Merino
2016-01-13 16:10 ` Javi Merino
0 siblings, 1 reply; 3+ messages in thread
From: Javi Merino @ 2015-12-19 13:49 UTC (permalink / raw)
To: edubezval, Zhang Rui; +Cc: dan.carpenter, linux-pm
Eduardo, Rui,
On Tue, Dec 01, 2015 at 03:15:23PM +0000, Javi Merino wrote:
> req_range is declared as a u64 to cope with overflows in the
> multiplication of two u32. As both req_power and power_range are u32,
> we need to make sure the multiplication is done with u64 types.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Eduardo Valentin <edubezval@gmail.com>
> Signed-off-by: Javi Merino <javi.merino@arm.com>
> ---
> drivers/thermal/power_allocator.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Any comments on this? If not, can it be merged?
Thanks,
Javi
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH RESEND] thermal: power_allocator: req_range multiplication should be a 64 bit type
2015-12-19 13:49 ` Javi Merino
@ 2016-01-13 16:10 ` Javi Merino
0 siblings, 0 replies; 3+ messages in thread
From: Javi Merino @ 2016-01-13 16:10 UTC (permalink / raw)
To: edubezval, Zhang Rui; +Cc: dan.carpenter, linux-pm
On Sat, Dec 19, 2015 at 01:49:58PM +0000, Javi Merino wrote:
> Eduardo, Rui,
>
> On Tue, Dec 01, 2015 at 03:15:23PM +0000, Javi Merino wrote:
> > req_range is declared as a u64 to cope with overflows in the
> > multiplication of two u32. As both req_power and power_range are u32,
> > we need to make sure the multiplication is done with u64 types.
> >
> > Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> > Cc: Zhang Rui <rui.zhang@intel.com>
> > Cc: Eduardo Valentin <edubezval@gmail.com>
> > Signed-off-by: Javi Merino <javi.merino@arm.com>
> > ---
> > drivers/thermal/power_allocator.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Any comments on this? If not, can it be merged?
If there are no objections, can this be merged?
Thanks,
Javi
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-01-13 16:10 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-12-01 15:15 [PATCH RESEND] thermal: power_allocator: req_range multiplication should be a 64 bit type Javi Merino
2015-12-19 13:49 ` Javi Merino
2016-01-13 16:10 ` Javi Merino
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).