fusion problems on 64bit hosts

fusion problems on 64bit hosts

[Christoph Hellwig]

compiling fusion on ppc64 gives:

drivers/message/fusion/mptbase.c: In function `mpt_interrupt':
drivers/message/fusion/mptbase.c:360: warning: cast to pointer from integer of different size
drivers/message/fusion/mptbase.c:384: warning: cast to pointer from integer of different size
drivers/message/fusion/mptlan.c: In function `lan_reply':
drivers/message/fusion/mptlan.c:214: warning: cast from pointer to integer of different size

This is because of:

#if defined(__alpha__) || defined(__sparc_v9__) || defined(__ia64__) || defined(__x86_64__)
#define CAST_U32_TO_PTR(x)      ((void *)(u64)x)
#define CAST_PTR_TO_U32(x)      ((u32)(u64)x)
#else
#define CAST_U32_TO_PTR(x)      ((void *)x)
#define CAST_PTR_TO_U32(x)      ((u32)x)
#endif

which shuts the warning up on some 64bit architectures but doesn't solve
the problem.  You're trying to keep a 64bit pointer in a 32bit hardware
register which can't work on 64bit architectures (the code if for the
networking and target modules that few people use)

The right fix is to only store a 32bit lookup key for some datastructure
in the register and use it as lookup key in the intr handler.

RE: fusion problems on 64bit hosts

[Moore, Eric Dean]

On Saturday, September 25, 2004 7:57 AM, Christoph Hellwig wrote:
> 
> compiling fusion on ppc64 gives:
> 
> drivers/message/fusion/mptbase.c: In function `mpt_interrupt':
> drivers/message/fusion/mptbase.c:360: warning: cast to 
> pointer from integer of different size
> drivers/message/fusion/mptbase.c:384: warning: cast to 
> pointer from integer of different size
> drivers/message/fusion/mptlan.c: In function `lan_reply':
> drivers/message/fusion/mptlan.c:214: warning: cast from 
> pointer to integer of different size
> 
> This is because of:
> 
> #if defined(__alpha__) || defined(__sparc_v9__) || 
> defined(__ia64__) || defined(__x86_64__)
> #define CAST_U32_TO_PTR(x)      ((void *)(u64)x)
> #define CAST_PTR_TO_U32(x)      ((u32)(u64)x)
> #else
> #define CAST_U32_TO_PTR(x)      ((void *)x)
> #define CAST_PTR_TO_U32(x)      ((u32)x)
> #endif
> 
> which shuts the warning up on some 64bit architectures but 
> doesn't solve
> the problem.  You're trying to keep a 64bit pointer in a 
> 32bit hardware
> register which can't work on 64bit architectures (the code if for the
> networking and target modules that few people use)
> 
> The right fix is to only store a 32bit lookup key for some 
> datastructure
> in the register and use it as lookup key in the intr handler.
>

No, we are not keeping a 64bit pointer in a 32bit hardware register.
IMO we can solve this issue by adding ppc64 to define above.

Here is my explanation:
The Reply Message can come in two forms.  (1) Address Reply (2) Context
Reply,
also known as Turbo Reply.  The Address Reply means that the previous
command probally 
had issues completing, or maybe it completed and the Firmware is returning
more detailed info about the request, thus a address is returned in the
RequestFifo pointing to 
Reply Message Frame containing infomation about the request.  A context
reply means the previous
command completed successfully, and the RequestFifo returns a 32bit
MessageContext field 
copied from the original message frame.

For Address Reply, the lower 32 bit physical address is in the
ioc->chip->ReplyFifo register. 
The high 32bit physical address is set when we did the IOCInit config frame 
during driver load time.  If we get a Context Reply, the
ioc->chip->ReplyFifo contains 
protocal dependent data.  In this driver, this is how we define the protocal
dependend data:

Bits 15-0 are index to the orignal request 
Bits 24-16 is callback index.  

The compile errors your refering to { line 360 and 384 in mptbase.c } and {
line 214
in mptlan.c} are context replys.

Therefore the typecasting is used to so both types of Reply Messages (
address and context)
can work thru same callback handlers via MptCallbacks[cb_idx](ioc, mf, mr),
line 427 in mptbase.c







 

RE: fusion problems on 64bit hosts

[James Bottomley]

On Mon, 2004-09-27 at 18:12, Moore, Eric Dean wrote:
> No, we are not keeping a 64bit pointer in a 32bit hardware register.
> IMO we can solve this issue by adding ppc64 to define above.

Assuming this is the correct thing to do, what's wrong with predicating
on 

#ifdef __LP64__

instead?

That way you don't have to keep this list of 64 bit architectures up to
date

James

Re: fusion problems on 64bit hosts

[Christoph Hellwig]

On Mon, Sep 27, 2004 at 06:20:43PM -0400, James Bottomley wrote:
> On Mon, 2004-09-27 at 18:12, Moore, Eric Dean wrote:
> > No, we are not keeping a 64bit pointer in a 32bit hardware register.
> > IMO we can solve this issue by adding ppc64 to define above.
> 
> Assuming this is the correct thing to do, what's wrong with predicating
> on 
> 
> #ifdef __LP64__

that's only defined for parisc and ia64. the correct thing is

#if BITS_PER_LONG == 64


but I don't like what you're doing here.  I'd rather see two callbacks for
different types of data.