From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Pravin Bathija" Subject: RE: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources. Date: Thu, 5 Nov 2009 21:49:41 -0800 Message-ID: <9D1E2BDCB5C57B46B56E6D80843439EB09350F76@SDCEXCHANGE01.ad.amcc.com> References: <1253053555-25097-1-git-send-email-pbathija@amcc.com><20091105134330.GA30489@zod.rchland.ibm.com><1257437226.2753.64.camel@mulgrave.site> <1257451218.13611.114.camel@pasglop> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============2630111549212023024==" Return-path: Content-class: urn:content-classes:message List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linuxppc-dev-bounces+glppd-linuxppc64-dev=m.gmane.org@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+glppd-linuxppc64-dev=m.gmane.org@lists.ozlabs.org To: Benjamin Herrenschmidt , James Bottomley Cc: Eric.Moore@lsi.com, linux-scsi@vger.kernel.org, linuxppc-dev@ozlabs.org List-Id: linux-scsi@vger.kernel.org This is a multi-part message in MIME format. --===============2630111549212023024== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5EA5.2A4CB319" This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5EA5.2A4CB319 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org] Sent: Thu 11/5/2009 12:00 PM To: James Bottomley Cc: Josh Boyer; Eric.Moore@lsi.com; Pravin Bathija; = linux-scsi@vger.kernel.org; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit = resources. =20 On Thu, 2009-11-05 at 10:07 -0600, James Bottomley wrote: > > > ioc->memmap =3D mem; > > >- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem =3D %p, mem_phys = =3D %lx\n", > > >- ioc->name, mem, mem_phys)); > > >+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem =3D %p, mem_phys = =3D %llx\n", > > >+ ioc->name, mem, (u64)mem_phys)); > > > > > > ioc->mem_phys =3D mem_phys; > > > ioc->chip =3D (SYSIF_REGS __iomem *)mem; > > > > > > /* Save Port IO values in case we need to do downloadboot */ > > >- ioc->pio_mem_phys =3D port; > > >+ port =3D ioremap(port_phys, psize); > > >+ if (port =3D=3D NULL) { > > >+ printk(MYIOC_s_ERR_FMT " : ERROR - Unable to map adapter" > > >+ " port !\n", ioc->name); > > >+ return -EINVAL; >=20 > So this looks problematic on a few platforms ... what happens to > platforms that have no IO space? They automatically fail here and it > looks like the adapter never attaches. > Yup, that part of the patch looks wrong. > However, a mechanical replacement of unsigned long's with > resource_size_t to hold physical addresses should be fine despite the > lack of feedback from LSI. > Pravin, that ioremap definitely seems like it has nothing to do there, > port IO is already remapped for you by the core PCI code and should = work > "as is". Please respin without that change. > Cheers, >Ben. Thanks for the input. Will make the suggested changes and re-submit the = patch. Regards, Pravin ------_=_NextPart_001_01CA5EA5.2A4CB319 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit = resources.

-----Original Message-----
From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org<= /A>]
Sent: Thu 11/5/2009 12:00 PM
To: James Bottomley
Cc: Josh Boyer; Eric.Moore@lsi.com; Pravin Bathija; = linux-scsi@vger.kernel.org; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit = resources.

On Thu, 2009-11-05 at 10:07 -0600, James Bottomley wrote:

> > >   ioc->memmap =3D mem;
> > >-  dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = =3D %p, mem_phys =3D %lx\n",
> > >-      ioc->name, mem, = mem_phys));
> > >+  dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = =3D %p, mem_phys =3D %llx\n",
> > >+      ioc->name, mem, = (u64)mem_phys));
> > >
> > >   ioc->mem_phys =3D mem_phys;
> > >   ioc->chip =3D (SYSIF_REGS __iomem *)mem;
> > >
> > >   /* Save Port IO values in case we need to do = downloadboot */
> > >-  ioc->pio_mem_phys =3D port;
> > >+  port =3D ioremap(port_phys, psize);
> > >+  if (port =3D=3D NULL) {
> > >+          = printk(MYIOC_s_ERR_FMT " : ERROR - Unable to map adapter"
> > >+          =         " port !\n", = ioc->name);
> > >+          return = -EINVAL;
>
> So this looks problematic on a few platforms ... what happens = to
> platforms that have no IO space?  They automatically fail here = and it
> looks like the adapter never attaches.

> Yup, that part of the patch looks wrong.

> However, a mechanical replacement of unsigned long's with
> resource_size_t to hold physical addresses should be fine despite = the
> lack of feedback from LSI.

> Pravin, that ioremap definitely seems like it has nothing to do = there,
> port IO is already remapped for you by the core PCI code and should = work
> "as is". Please respin without that change.

> Cheers,
>Ben.

Thanks for the input. Will make the suggested changes and re-submit the = patch.

Regards,
Pravin



------_=_NextPart_001_01CA5EA5.2A4CB319-- --===============2630111549212023024== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev --===============2630111549212023024==-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from sdcmail01.amcc.com (sdcmail01.amcc.com [198.137.200.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "Messaging Gateway Appliance Demo Cert", Issuer "Messaging Gateway Appliance Demo Cert" (not verified)) by ozlabs.org (Postfix) with ESMTPS id EA3D3B7B65 for ; Fri, 6 Nov 2009 17:01:33 +1100 (EST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA5EA5.2A4CB319" Subject: RE: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit resources. Date: Thu, 5 Nov 2009 21:49:41 -0800 Message-ID: <9D1E2BDCB5C57B46B56E6D80843439EB09350F76@SDCEXCHANGE01.ad.amcc.com> References: <1253053555-25097-1-git-send-email-pbathija@amcc.com><20091105134330.GA30489@zod.rchland.ibm.com><1257437226.2753.64.camel@mulgrave.site> <1257451218.13611.114.camel@pasglop> From: "Pravin Bathija" To: "Benjamin Herrenschmidt" , "James Bottomley" Cc: Eric.Moore@lsi.com, linux-scsi@vger.kernel.org, linuxppc-dev@ozlabs.org List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------_=_NextPart_001_01CA5EA5.2A4CB319 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable -----Original Message----- From: Benjamin Herrenschmidt [mailto:benh@kernel.crashing.org] Sent: Thu 11/5/2009 12:00 PM To: James Bottomley Cc: Josh Boyer; Eric.Moore@lsi.com; Pravin Bathija; = linux-scsi@vger.kernel.org; linuxppc-dev@ozlabs.org Subject: Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit = resources. =20 On Thu, 2009-11-05 at 10:07 -0600, James Bottomley wrote: > > > ioc->memmap =3D mem; > > >- dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem =3D %p, mem_phys = =3D %lx\n", > > >- ioc->name, mem, mem_phys)); > > >+ dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem =3D %p, mem_phys = =3D %llx\n", > > >+ ioc->name, mem, (u64)mem_phys)); > > > > > > ioc->mem_phys =3D mem_phys; > > > ioc->chip =3D (SYSIF_REGS __iomem *)mem; > > > > > > /* Save Port IO values in case we need to do downloadboot */ > > >- ioc->pio_mem_phys =3D port; > > >+ port =3D ioremap(port_phys, psize); > > >+ if (port =3D=3D NULL) { > > >+ printk(MYIOC_s_ERR_FMT " : ERROR - Unable to map adapter" > > >+ " port !\n", ioc->name); > > >+ return -EINVAL; >=20 > So this looks problematic on a few platforms ... what happens to > platforms that have no IO space? They automatically fail here and it > looks like the adapter never attaches. > Yup, that part of the patch looks wrong. > However, a mechanical replacement of unsigned long's with > resource_size_t to hold physical addresses should be fine despite the > lack of feedback from LSI. > Pravin, that ioremap definitely seems like it has nothing to do there, > port IO is already remapped for you by the core PCI code and should = work > "as is". Please respin without that change. > Cheers, >Ben. Thanks for the input. Will make the suggested changes and re-submit the = patch. Regards, Pravin ------_=_NextPart_001_01CA5EA5.2A4CB319 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit = resources.

-----Original Message-----
From: Benjamin Herrenschmidt [
mailto:benh@kernel.crashing.org<= /A>]
Sent: Thu 11/5/2009 12:00 PM
To: James Bottomley
Cc: Josh Boyer; Eric.Moore@lsi.com; Pravin Bathija; = linux-scsi@vger.kernel.org; linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] [SCSI] mpt fusion: Fix 32 bit platforms with 64 bit = resources.

On Thu, 2009-11-05 at 10:07 -0600, James Bottomley wrote:

> > >   ioc->memmap =3D mem;
> > >-  dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = =3D %p, mem_phys =3D %lx\n",
> > >-      ioc->name, mem, = mem_phys));
> > >+  dinitprintk(ioc, printk(MYIOC_s_INFO_FMT "mem = =3D %p, mem_phys =3D %llx\n",
> > >+      ioc->name, mem, = (u64)mem_phys));
> > >
> > >   ioc->mem_phys =3D mem_phys;
> > >   ioc->chip =3D (SYSIF_REGS __iomem *)mem;
> > >
> > >   /* Save Port IO values in case we need to do = downloadboot */
> > >-  ioc->pio_mem_phys =3D port;
> > >+  port =3D ioremap(port_phys, psize);
> > >+  if (port =3D=3D NULL) {
> > >+          = printk(MYIOC_s_ERR_FMT " : ERROR - Unable to map adapter"
> > >+          =         " port !\n", = ioc->name);
> > >+          return = -EINVAL;
>
> So this looks problematic on a few platforms ... what happens = to
> platforms that have no IO space?  They automatically fail here = and it
> looks like the adapter never attaches.

> Yup, that part of the patch looks wrong.

> However, a mechanical replacement of unsigned long's with
> resource_size_t to hold physical addresses should be fine despite = the
> lack of feedback from LSI.

> Pravin, that ioremap definitely seems like it has nothing to do = there,
> port IO is already remapped for you by the core PCI code and should = work
> "as is". Please respin without that change.

> Cheers,
>Ben.

Thanks for the input. Will make the suggested changes and re-submit the = patch.

Regards,
Pravin



------_=_NextPart_001_01CA5EA5.2A4CB319--