| Message ID | 749e6480-aed6-041c-0209-8dc74c07f344@cogentembedded.com (mailing list archive) |
|---|---|
| State | Accepted |
| Delegated to: | Geert Uytterhoeven |
| Headers | show |
| Series | clocksource: sh_cmt: fix clocksource width for 32-bit machines | expand |
On 09/10/2018 11:22 PM, Sergei Shtylyov wrote: > The driver seems to abuse *unsigned long* not only for the (32-bit) > register values but also for the 'sh_cmt_channel::total_cycles' which > needs to always be 64-bit -- as a result, the clocksource's mask is > needlessly clamped down to 32-bits on the 32-bit machines... I thought this bug was present from the start but no... > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Fixes: 19bdc9d061bc ("clocksource: sh_cmt clocksource support") [...] MBR, Sergei
On Mon, Sep 10, 2018 at 11:34:49PM +0300, Sergei Shtylyov wrote: > On 09/10/2018 11:22 PM, Sergei Shtylyov wrote: > > > The driver seems to abuse *unsigned long* not only for the (32-bit) > > register values but also for the 'sh_cmt_channel::total_cycles' which > > needs to always be 64-bit -- as a result, the clocksource's mask is > > needlessly clamped down to 32-bits on the 32-bit machines... > > I thought this bug was present from the start but no... > > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> > > Fixes: 19bdc9d061bc ("clocksource: sh_cmt clocksource support") Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
On 10/09/2018 22:22, Sergei Shtylyov wrote: > The driver seems to abuse *unsigned long* not only for the (32-bit) > register values but also for the 'sh_cmt_channel::total_cycles' which > needs to always be 64-bit -- as a result, the clocksource's mask is > needlessly clamped down to 32-bits on the 32-bit machines... > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> > > --- > This patch is against the 'tip.git' repo's 'timers/core' branch plus the fixup > for the 64-bit machines reposted last Saturday... Why not against timers/urgent ?
Hello! On 09/13/2018 04:25 PM, Daniel Lezcano wrote: >> The driver seems to abuse *unsigned long* not only for the (32-bit) >> register values but also for the 'sh_cmt_channel::total_cycles' which >> needs to always be 64-bit -- as a result, the clocksource's mask is >> needlessly clamped down to 32-bits on the 32-bit machines... >> >> Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> >> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> >> >> --- >> This patch is against the 'tip.git' repo's 'timers/core' branch plus the fixup >> for the 64-bit machines reposted last Saturday... > > Why not against timers/urgent ? Mhm... nothing blows up because of this apparently (the bug is quite old). MBR, Sergei
On Mon, Sep 10, 2018 at 10:23 PM Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> wrote: > The driver seems to abuse *unsigned long* not only for the (32-bit) > register values but also for the 'sh_cmt_channel::total_cycles' which > needs to always be 64-bit -- as a result, the clocksource's mask is > needlessly clamped down to 32-bits on the 32-bit machines... > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Gr{oetje,eeting}s, Geert
On 10/09/2018 22:22, Sergei Shtylyov wrote: > The driver seems to abuse *unsigned long* not only for the (32-bit) > register values but also for the 'sh_cmt_channel::total_cycles' which > needs to always be 64-bit -- as a result, the clocksource's mask is > needlessly clamped down to 32-bits on the 32-bit machines... > > Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> > Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> > > --- Applied for 4.20, thanks.
Index: tip/drivers/clocksource/sh_cmt.c =================================================================== --- tip.orig/drivers/clocksource/sh_cmt.c +++ tip/drivers/clocksource/sh_cmt.c @@ -108,7 +108,7 @@ struct sh_cmt_channel { raw_spinlock_t lock; struct clock_event_device ced; struct clocksource cs; - unsigned long total_cycles; + u64 total_cycles; bool cs_enabled; }; @@ -613,8 +613,8 @@ static u64 sh_cmt_clocksource_read(struc { struct sh_cmt_channel *ch = cs_to_sh_cmt(cs); unsigned long flags; - unsigned long value; u32 has_wrapped; + u64 value; u32 raw; raw_spin_lock_irqsave(&ch->lock, flags); @@ -688,7 +688,7 @@ static int sh_cmt_register_clocksource(s cs->disable = sh_cmt_clocksource_disable; cs->suspend = sh_cmt_clocksource_suspend; cs->resume = sh_cmt_clocksource_resume; - cs->mask = CLOCKSOURCE_MASK(sizeof(unsigned long) * 8); + cs->mask = CLOCKSOURCE_MASK(sizeof(u64) * 8); cs->flags = CLOCK_SOURCE_IS_CONTINUOUS; dev_info(&ch->cmt->pdev->dev, "ch%u: used as clock source\n",
The driver seems to abuse *unsigned long* not only for the (32-bit) register values but also for the 'sh_cmt_channel::total_cycles' which needs to always be 64-bit -- as a result, the clocksource's mask is needlessly clamped down to 32-bits on the 32-bit machines... Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> --- This patch is against the 'tip.git' repo's 'timers/core' branch plus the fixup for the 64-bit machines reposted last Saturday... drivers/clocksource/sh_cmt.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)