From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: pbathija@amcc.com
Cc: linux-scsi@vger.kernel.org, linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources
Date: Tue, 15 Sep 2009 20:29:38 +1000 [thread overview]
Message-ID: <1253010578.8375.220.camel@pasglop> (raw)
In-Reply-To: <1252455333-9925-1-git-send-email-pbathija@amcc.com>
> diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
> index 5d496a9..d5b0f15 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -1510,11 +1510,12 @@ static int
> mpt_mapresources(MPT_ADAPTER *ioc)
> {
> u8 __iomem *mem;
> + u8 __iomem *port;
> int ii;
> - unsigned long mem_phys;
> - unsigned long port;
> - u32 msize;
> - u32 psize;
> + phys_addr_t mem_phys;
> + phys_addr_t port_phys;
> + resource_size_t msize;
> + resource_size_t psize;
Is phys_addr_t defined for all archs nowadays ? Why not use
resource_size_t for everything ? resource_size_t is a bit of a misnomer,
it's not a type supposed to reference a "size" but really a physical
address (or a size)... it's been called resource_size_t I believe
because it's "sized" appropriately for holding a physical address.
Cheers,
Ben.
WARNING: multiple messages have this Message-ID (diff)
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: pbathija@amcc.com
Cc: linuxppc-dev@ozlabs.org, linux-scsi@vger.kernel.org
Subject: Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources
Date: Tue, 15 Sep 2009 20:29:38 +1000 [thread overview]
Message-ID: <1253010578.8375.220.camel@pasglop> (raw)
In-Reply-To: <1252455333-9925-1-git-send-email-pbathija@amcc.com>
> diff --git a/drivers/message/fusion/mptbase.c b/drivers/message/fusion/mptbase.c
> index 5d496a9..d5b0f15 100644
> --- a/drivers/message/fusion/mptbase.c
> +++ b/drivers/message/fusion/mptbase.c
> @@ -1510,11 +1510,12 @@ static int
> mpt_mapresources(MPT_ADAPTER *ioc)
> {
> u8 __iomem *mem;
> + u8 __iomem *port;
> int ii;
> - unsigned long mem_phys;
> - unsigned long port;
> - u32 msize;
> - u32 psize;
> + phys_addr_t mem_phys;
> + phys_addr_t port_phys;
> + resource_size_t msize;
> + resource_size_t psize;
Is phys_addr_t defined for all archs nowadays ? Why not use
resource_size_t for everything ? resource_size_t is a bit of a misnomer,
it's not a type supposed to reference a "size" but really a physical
address (or a size)... it's been called resource_size_t I believe
because it's "sized" appropriately for holding a physical address.
Cheers,
Ben.
next prev parent reply other threads:[~2009-09-15 10:29 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-09 0:15 [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources pbathija
2009-09-15 10:29 ` Benjamin Herrenschmidt [this message]
2009-09-15 10:29 ` Benjamin Herrenschmidt
-- strict thread matches above, loose matches on Subject: below --
2009-09-15 22:25 pbathija
2009-11-05 13:43 ` Josh Boyer
2009-11-05 13:43 ` Josh Boyer
2009-11-05 16:07 ` James Bottomley
2009-11-05 16:07 ` James Bottomley
2009-11-05 16:25 ` Josh Boyer
2009-11-05 16:25 ` Josh Boyer
2009-11-05 20:00 ` Benjamin Herrenschmidt
2009-11-06 4:59 ` Desai, Kashyap
2009-11-06 4:59 ` Desai, Kashyap
2009-11-06 5:49 ` Pravin Bathija
2009-11-06 5:49 ` Pravin Bathija
2009-11-06 5:57 ` Pravin Bathija
2009-11-06 5:57 ` Pravin Bathija
2009-11-18 0:16 pbathija
2009-11-18 0:16 ` pbathija
2009-11-18 5:41 ` Benjamin Herrenschmidt
2009-11-18 5:41 ` Benjamin Herrenschmidt
2009-12-03 1:51 Pravin Bathija
2009-12-03 1:51 ` Pravin Bathija
2009-12-03 2:59 ` Benjamin Herrenschmidt
2009-12-03 5:26 ` Desai, Kashyap
2009-12-03 5:26 ` Desai, Kashyap
2009-12-03 8:56 ` Wolfgang Denk
2009-12-03 8:56 ` Wolfgang Denk
2009-12-03 23:21 ` Pravin Bathija
2009-12-03 23:21 ` Pravin Bathija
2009-12-03 23:48 ` Benjamin Herrenschmidt
2009-12-03 23:48 ` Benjamin Herrenschmidt
2009-12-10 15:43 ` James Bottomley
2009-12-10 15:43 ` James Bottomley
2009-12-10 16:36 ` Anatolij Gustschin
2009-12-10 16:36 ` Anatolij Gustschin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1253010578.8375.220.camel@pasglop \
--to=benh@kernel.crashing.org \
--cc=linux-scsi@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=pbathija@amcc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.