On Mar 2, 2012, at 1:08 AM, Liu Gang wrote:

> For the file "arch/powerpc/sysdev/fsl_rmu.c", there will be some compile
> errors while using the corenet64_smp_defconfig:
> 
> .../fsl_rmu.c:315: error: cast from pointer to integer of different size
> .../fsl_rmu.c:320: error: cast to pointer from integer of different size
> .../fsl_rmu.c:320: error: cast to pointer from integer of different size
> .../fsl_rmu.c:320: error: cast to pointer from integer of different size
> .../fsl_rmu.c:330: error: cast to pointer from integer of different size
> .../fsl_rmu.c:332: error: cast to pointer from integer of different size
> .../fsl_rmu.c:339: error: cast to pointer from integer of different size
> .../fsl_rmu.c:340: error: cast to pointer from integer of different size
> .../fsl_rmu.c:341: error: cast to pointer from integer of different size
> .../fsl_rmu.c:348: error: cast to pointer from integer of different size
> .../fsl_rmu.c:348: error: cast to pointer from integer of different size
> .../fsl_rmu.c:348: error: cast to pointer from integer of different size
> .../fsl_rmu.c:659: error: cast from pointer to integer of different size
> .../fsl_rmu.c:659: error: format '%8.8x' expects type 'unsigned int',
>                  but argument 5 has type 'size_t'
> .../fsl_rmu.c:985: error: cast from pointer to integer of different size
> .../fsl_rmu.c:997: error: cast to pointer from integer of different size
> 
> Rewrote the corresponding code with the support of 64bit building.
> 
> Signed-off-by: Liu Gang <gang....@freescale.com>
> Signed-off-by: Shaohui Xie <shaohui....@freescale.com>
> Signed-off-by: Paul Gortmaker <paul.gortma...@windriver.com>
> ---
> arch/powerpc/sysdev/fsl_rmu.c |   11 ++++++-----
> 1 files changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/powerpc/sysdev/fsl_rmu.c b/arch/powerpc/sysdev/fsl_rmu.c
> index 1548578..468011e 100644
> --- a/arch/powerpc/sysdev/fsl_rmu.c
> +++ b/arch/powerpc/sysdev/fsl_rmu.c
> @@ -311,8 +311,8 @@ fsl_rio_dbell_handler(int irq, void *dev_instance)
> 
>       /* XXX Need to check/dispatch until queue empty */
>       if (dsr & DOORBELL_DSR_DIQI) {
> -             u32 dmsg =
> -                     (u32) fsl_dbell->dbell_ring.virt +
> +             unsigned long dmsg =
> +                     (unsigned long) fsl_dbell->dbell_ring.virt +
>                       (in_be32(&fsl_dbell->dbell_regs->dqdpar) & 0xfff);
>               struct rio_dbell *dbell;
>               int found = 0;
> @@ -657,7 +657,8 @@ fsl_add_outb_message(struct rio_mport *mport, struct 
> rio_dev *rdev, int mbox,
>       int ret = 0;
> 
>       pr_debug("RIO: fsl_add_outb_message(): destid %4.4x mbox %d buffer " \
> -              "%8.8x len %8.8x\n", rdev->destid, mbox, (int)buffer, len);
> +              "%8.8lx len %8.8zx\n", rdev->destid, mbox,
> +             (unsigned long)buffer, len);
>       if ((len < 8) || (len > RIO_MAX_MSG_SIZE)) {
>               ret = -EINVAL;
>               goto out;

For this case it seems as if some cast should be added to DBELL_* macros

> @@ -972,7 +973,7 @@ out:
> void *fsl_get_inb_message(struct rio_mport *mport, int mbox)
> {
>       struct fsl_rmu *rmu = GET_RMM_HANDLE(mport);
> -     u32 phys_buf, virt_buf;
> +     unsigned long phys_buf, virt_buf;

Do you really want to change phys_buf to an 'unsigned long'?

Should virt_buf really be void * here?

>       void *buf = NULL;
>       int buf_idx;
> 
> @@ -982,7 +983,7 @@ void *fsl_get_inb_message(struct rio_mport *mport, int 
> mbox)
>       if (phys_buf == in_be32(&rmu->msg_regs->ifqepar))
>               goto out2;
> 
> -     virt_buf = (u32) rmu->msg_rx_ring.virt + (phys_buf
> +     virt_buf = (unsigned long) rmu->msg_rx_ring.virt + (phys_buf
>                                               - rmu->msg_rx_ring.phys);
>       buf_idx = (phys_buf - rmu->msg_rx_ring.phys) / RIO_MAX_MSG_SIZE;
>       buf = rmu->msg_rx_ring.virt_buffer[buf_idx];

The memcpy later could remove a cast if you make virt_buf a void *.

> -- 
> 1.7.0.4
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to