[PATCH] GICv3: Fixing 32 bit compatibility

[PATCH] GICv3: Fixing 32 bit compatibility

[Robert Richter]

From: Robert Richter <rrichter@cavium.com>

Fixing 32 bit compatibility by using ULL for u64 constants.

Signed-off-by: Robert Richter <rrichter@cavium.com>
---
 drivers/irqchip/irq-gic-v3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 57eaa5a0b1e3..9e13c87c7dfe 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -441,7 +441,7 @@ static u16 gic_compute_target_list(int *base_cpu, const struct cpumask *mask,
 
 		mpidr = cpu_logical_map(cpu);
 
-		if (cluster_id != (mpidr & ~0xffUL)) {
+		if (cluster_id != (mpidr & ~0xffULL)) {
 			cpu--;
 			goto out;
 		}
@@ -479,7 +479,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
 	smp_wmb();
 
 	for_each_cpu_mask(cpu, *mask) {
-		u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
+		u64 cluster_id = cpu_logical_map(cpu) & ~0xffULL;
 		u16 tlist;
 
 		tlist = gic_compute_target_list(&cpu, mask, cluster_id);
-- 
2.0.1

Re: [PATCH] GICv3: Fixing 32 bit compatibility

[Marc Zyngier]

Hi Robert,

On 08/09/14 15:11, Robert Richter wrote:
> From: Robert Richter <rrichter@cavium.com>
> 
> Fixing 32 bit compatibility by using ULL for u64 constants.
> 
> Signed-off-by: Robert Richter <rrichter@cavium.com>
> ---
>  drivers/irqchip/irq-gic-v3.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 57eaa5a0b1e3..9e13c87c7dfe 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -441,7 +441,7 @@ static u16 gic_compute_target_list(int *base_cpu, const struct cpumask *mask,
>  
>  		mpidr = cpu_logical_map(cpu);
>  
> -		if (cluster_id != (mpidr & ~0xffUL)) {
> +		if (cluster_id != (mpidr & ~0xffULL)) {
>  			cpu--;
>  			goto out;
>  		}
> @@ -479,7 +479,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
>  	smp_wmb();
>  
>  	for_each_cpu_mask(cpu, *mask) {
> -		u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
> +		u64 cluster_id = cpu_logical_map(cpu) & ~0xffULL;
>  		u16 tlist;
>  
>  		tlist = gic_compute_target_list(&cpu, mask, cluster_id);
> 

Yeah, and there are many more. I'm currently sitting on a rather long
queue of GICv3-related 32bit patches. I'll try to get that posted shortly.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[PATCH] ITS: Fixing 32 bit compatibility

[Robert Richter]

Marc,

On 08.09.14 16:11:19, Robert Richter wrote:
> From: Robert Richter <rrichter@cavium.com>
> 
> Fixing 32 bit compatibility by using ULL for u64 constants.

the same is true for gicv3-its (branch 'gicv3/its' of
git://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms). See
the patch below. You may merge the fixes with your patches or apply it
on top of yours.

-Robert



>From 38a71030b9b93a14afada6979c709f6addac5112 Mon Sep 17 00:00:00 2001
From: Robert Richter <rrichter@cavium.com>
Date: Tue, 26 Aug 2014 18:08:56 +0200
Subject: [PATCH] ITS: Fixing 32 bit compatibility

Fixing 32 bit compatibility by using ULL for u64 constants.

Signed-off-by: Robert Richter <rrichter@cavium.com>
---
 drivers/irqchip/irq-gic-v3-its.c | 28 ++++++++++++++--------------
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c
index 26927521fc28..2fda6935ad32 100644
--- a/drivers/irqchip/irq-gic-v3-its.c
+++ b/drivers/irqchip/irq-gic-v3-its.c
@@ -173,55 +173,55 @@ static struct rdist *gic_rdist;
 
 static void its_encode_cmd(struct its_cmd_block *cmd, u8 cmd_nr)
 {
-	cmd->raw_cmd[0] &= ~0xffUL;
+	cmd->raw_cmd[0] &= ~0xffULL;
 	cmd->raw_cmd[0] |= cmd_nr;
 }
 
 static void its_encode_devid(struct its_cmd_block *cmd, u32 devid)
 {
-	cmd->raw_cmd[0] &= 0xffffffffUL;
+	cmd->raw_cmd[0] &= 0xffffffffULL;
 	cmd->raw_cmd[0] |= ((u64)devid) << 32;
 }
 
 static void its_encode_event_id(struct its_cmd_block *cmd, u32 id)
 {
-	cmd->raw_cmd[1] &= ~0xffffffffUL;
+	cmd->raw_cmd[1] &= ~0xffffffffULL;
 	cmd->raw_cmd[1] |= id;
 }
 
 static void its_encode_phys_id(struct its_cmd_block *cmd, u32 phys_id)
 {
-	cmd->raw_cmd[1] &= 0xffffffffUL;
+	cmd->raw_cmd[1] &= 0xffffffffULL;
 	cmd->raw_cmd[1] |= ((u64)phys_id) << 32;
 }
 
 static void its_encode_size(struct its_cmd_block *cmd, u8 size)
 {
-	cmd->raw_cmd[1] &= ~0xffUL;
-	cmd->raw_cmd[1] |= size & 0xff;
+	cmd->raw_cmd[1] &= ~0xffULL;
+	cmd->raw_cmd[1] |= size;
 }
 
 static void its_encode_itt(struct its_cmd_block *cmd, u64 itt_addr)
 {
-	cmd->raw_cmd[2] &= ~0xffffffffffffUL;
-	cmd->raw_cmd[2] |= itt_addr & 0xffffffffff00UL;
+	cmd->raw_cmd[2] &= ~0xffffffffffffULL;
+	cmd->raw_cmd[2] |= itt_addr & 0xffffffffff00ULL;
 }
 
 static void its_encode_valid(struct its_cmd_block *cmd, int valid)
 {
-	cmd->raw_cmd[2] &= ~(1UL << 63);
+	cmd->raw_cmd[2] &= ~(1ULL << 63);
 	cmd->raw_cmd[2] |= ((u64)!!valid) << 63;
 }
 
 static void its_encode_target(struct its_cmd_block *cmd, u64 target_addr)
 {
-	cmd->raw_cmd[2] &= ~(0xffffffffUL << 16);
-	cmd->raw_cmd[2] |= (target_addr & (0xffffffffUL << 16));
+	cmd->raw_cmd[2] &= ~(0xffffffffULL << 16);
+	cmd->raw_cmd[2] |= (target_addr & (0xffffffffULL << 16));
 }
 
 static void its_encode_collection(struct its_cmd_block *cmd, u16 col)
 {
-	cmd->raw_cmd[2] &= ~0xffffUL;
+	cmd->raw_cmd[2] &= ~0xffffULL;
 	cmd->raw_cmd[2] |= col;
 }
 
@@ -1221,8 +1221,8 @@ static int its_msi_setup_irq(struct msi_chip *chip,
 
 	addr = its->phys_base + GITS_TRANSLATER;
 
-	msg.address_lo		= addr & ((1UL << 32) - 1);
-	msg.address_hi		= addr >> 32;
+	msg.address_lo		= (u32)addr;
+	msg.address_hi		= (u32)(addr >> 32);
 	msg.data		= vec_nr;
 
 	write_msi_msg(irq, &msg);
-- 
2.0.1

Re: [PATCH] GICv3: Fixing 32 bit compatibility

[Uwe Kleine-König]

Hello Robert,

On Mon, Sep 08, 2014 at 04:11:19PM +0200, Robert Richter wrote:
> From: Robert Richter <rrichter@cavium.com>
> 
> Fixing 32 bit compatibility by using ULL for u64 constants.
> 
> Signed-off-by: Robert Richter <rrichter@cavium.com>
> ---
>  drivers/irqchip/irq-gic-v3.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> index 57eaa5a0b1e3..9e13c87c7dfe 100644
> --- a/drivers/irqchip/irq-gic-v3.c
> +++ b/drivers/irqchip/irq-gic-v3.c
> @@ -441,7 +441,7 @@ static u16 gic_compute_target_list(int *base_cpu, const struct cpumask *mask,
>  
>  		mpidr = cpu_logical_map(cpu);
>  
> -		if (cluster_id != (mpidr & ~0xffUL)) {
> +		if (cluster_id != (mpidr & ~0xffULL)) {
>  			cpu--;
>  			goto out;
>  		}
> @@ -479,7 +479,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
>  	smp_wmb();
>  
>  	for_each_cpu_mask(cpu, *mask) {
> -		u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
> +		u64 cluster_id = cpu_logical_map(cpu) & ~0xffULL;
This doesn't change anything, does it?

I wonder if it would be cleaner to use (u64)0xff here. Or still better
put the determination of the current cluster id(?) into a static inline
function?

Further, apart from arm and arm64 all other arch defining
cpu_logical_map (m32r, mips, mn10300, parisc, sh, sparc, um,
xtensa) return an int. (Three of them return just the cpu parameter
which at least for irq-gic-v3 is an int, too.)

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH] GICv3: Fixing 32 bit compatibility

[Robert Richter]

On 09.09.14 10:00:42, Uwe Kleine-König wrote:
> On Mon, Sep 08, 2014 at 04:11:19PM +0200, Robert Richter wrote:

> > @@ -479,7 +479,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> >     smp_wmb();
> >  
> >     for_each_cpu_mask(cpu, *mask) {
> > -           u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
> > +           u64 cluster_id = cpu_logical_map(cpu) & ~0xffULL;
> This doesn't change anything, does it?

It does, not in 64 bit but in 32 bit there unsigned long is 32
bit. So, bit masks are broken if you compile a 32 bit kernel.

> I wonder if it would be cleaner to use (u64)0xff here.

No, that's ULL for. This is commonly used in x86 too.

-Robert

Re: [PATCH] GICv3: Fixing 32 bit compatibility

[Uwe Kleine-König]

On Tue, Sep 09, 2014 at 11:12:01AM +0200, Robert Richter wrote:
> On 09.09.14 10:00:42, Uwe Kleine-König wrote:
> > On Mon, Sep 08, 2014 at 04:11:19PM +0200, Robert Richter wrote:
> 
> > > @@ -479,7 +479,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> > >     smp_wmb();
> > >  
> > >     for_each_cpu_mask(cpu, *mask) {
> > > -           u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
> > > +           u64 cluster_id = cpu_logical_map(cpu) & ~0xffULL;
> > This doesn't change anything, does it?
> 
> It does, not in 64 bit but in 32 bit there unsigned long is 32
> bit. So, bit masks are broken if you compile a 32 bit kernel.
Can you make an example where the result actually changes?

> > I wonder if it would be cleaner to use (u64)0xff here.
> 
> No, that's ULL for. This is commonly used in x86 too.
I don't care much here, but I'd say ULL is to force an unsigned long
long. If you want to make it obvious that you want a 64bit value, a cast
to u64 makes this more clear.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH] GICv3: Fixing 32 bit compatibility

[Robert Richter]

On 09.09.14 11:19:12, Uwe Kleine-König wrote:
> On Tue, Sep 09, 2014 at 11:12:01AM +0200, Robert Richter wrote:
> > On 09.09.14 10:00:42, Uwe Kleine-König wrote:
> > > On Mon, Sep 08, 2014 at 04:11:19PM +0200, Robert Richter wrote:
> > 
> > > > @@ -479,7 +479,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> > > >     smp_wmb();
> > > >  
> > > >     for_each_cpu_mask(cpu, *mask) {
> > > > -           u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
> > > > +           u64 cluster_id = cpu_logical_map(cpu) & ~0xffULL;
> > > This doesn't change anything, does it?
> > 
> > It does, not in 64 bit but in 32 bit there unsigned long is 32
> > bit. So, bit masks are broken if you compile a 32 bit kernel.
> Can you make an example where the result actually changes?

Upper 32 bits will be cleared above.

> > > I wonder if it would be cleaner to use (u64)0xff here.
> > 
> > No, that's ULL for. This is commonly used in x86 too.
> I don't care much here, but I'd say ULL is to force an unsigned long
> long. If you want to make it obvious that you want a 64bit value, a cast
> to u64 makes this more clear.

ULL is no cast at all.

-Robert

Re: [PATCH] GICv3: Fixing 32 bit compatibility

[Uwe Kleine-König]

On Tue, Sep 09, 2014 at 11:26:53AM +0200, Robert Richter wrote:
> On 09.09.14 11:19:12, Uwe Kleine-König wrote:
> > On Tue, Sep 09, 2014 at 11:12:01AM +0200, Robert Richter wrote:
> > > On 09.09.14 10:00:42, Uwe Kleine-König wrote:
> > > > On Mon, Sep 08, 2014 at 04:11:19PM +0200, Robert Richter wrote:
> > > 
> > > > > @@ -479,7 +479,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> > > > >     smp_wmb();
> > > > >  
> > > > >     for_each_cpu_mask(cpu, *mask) {
> > > > > -           u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
> > > > > +           u64 cluster_id = cpu_logical_map(cpu) & ~0xffULL;
> > > > This doesn't change anything, does it?
> > > 
> > > It does, not in 64 bit but in 32 bit there unsigned long is 32
> > > bit. So, bit masks are broken if you compile a 32 bit kernel.
> > Can you make an example where the result actually changes?
> 
> Upper 32 bits will be cleared above.
ah, I missed the ~ while thinking about the difference.

> > > > I wonder if it would be cleaner to use (u64)0xff here.
> > > 
> > > No, that's ULL for. This is commonly used in x86 too.
> > I don't care much here, but I'd say ULL is to force an unsigned long
> > long. If you want to make it obvious that you want a 64bit value, a cast
> > to u64 makes this more clear.
> 
> ULL is no cast at all.
That's irrelevant here if it's a cast or not. It makes the constant be
an unsigned long long one.

If you want an unsigned long long value, use ULL (or a cast to unsigned
long long if the value permits), if you want an u64 use a cast to u64.

Probably it doesn't make sense to continue to argue here. The type of
cpu_logical_map(cpu) varies per architecture but is always <= 64 bits
wide and IIRC unsigned long long is guaranteed to be >= 64 bits wide so
everything is fine with your patch today.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Re: [PATCH] GICv3: Fixing 32 bit compatibility

[Jason Cooper]

On Mon, Sep 08, 2014 at 03:24:12PM +0100, Marc Zyngier wrote:
> Hi Robert,
> 
> On 08/09/14 15:11, Robert Richter wrote:
> > From: Robert Richter <rrichter@cavium.com>
> > 
> > Fixing 32 bit compatibility by using ULL for u64 constants.
> > 
> > Signed-off-by: Robert Richter <rrichter@cavium.com>
> > ---
> >  drivers/irqchip/irq-gic-v3.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
> > index 57eaa5a0b1e3..9e13c87c7dfe 100644
> > --- a/drivers/irqchip/irq-gic-v3.c
> > +++ b/drivers/irqchip/irq-gic-v3.c
> > @@ -441,7 +441,7 @@ static u16 gic_compute_target_list(int *base_cpu, const struct cpumask *mask,
> >  
> >  		mpidr = cpu_logical_map(cpu);
> >  
> > -		if (cluster_id != (mpidr & ~0xffUL)) {
> > +		if (cluster_id != (mpidr & ~0xffULL)) {
> >  			cpu--;
> >  			goto out;
> >  		}
> > @@ -479,7 +479,7 @@ static void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
> >  	smp_wmb();
> >  
> >  	for_each_cpu_mask(cpu, *mask) {
> > -		u64 cluster_id = cpu_logical_map(cpu) & ~0xffUL;
> > +		u64 cluster_id = cpu_logical_map(cpu) & ~0xffULL;
> >  		u16 tlist;
> >  
> >  		tlist = gic_compute_target_list(&cpu, mask, cluster_id);
> > 
> 
> Yeah, and there are many more. I'm currently sitting on a rather long
> queue of GICv3-related 32bit patches. I'll try to get that posted shortly.

I'll hold off until you post a complete series then.

thx,

Jason.