Potential issue with some implementations of pci_resource_start()

Potential issue with some implementations of pci_resource_start()

[James.Smart]

According to Documentation/pci.txt: pci_resource_start() is to return the bus start address of the bar. It should essentially be a portable way to obtain the bar value without reading PCI config space directly.

We have encountered at least 2 platforms (HP Integrity (IA-64) Olympia rx8620 partition, and a dual-processor IBM eServer pSeries p615) - where the contents of pci_resource_start() vary from the contents of the BARs in config space. For example:
on IA64 Olympia: pci_resource_start(pcidev,0) = 0x00000f0030040000; pci bar0 word 0xf0040004, bar1 word 0x0 
On PPC eServer:  pci_resource_start(pcidev,0) = 0x000003fd80000000; pci bar0 word 0xc0000004, bar1 word 0x0 

We have demonstrated this on both the 2.4.21 and 2.6.5 kernels.

Are these platform bugs that need to be corrected ? or is it a change in the pci_resource_start() definition ?

-- James

Re: Potential issue with some implementations of pci_resource_start()

[Jes Sorensen]

>>>>> "James" == James Smart <James.Smart@Emulex.Com> writes:

James> According to Documentation/pci.txt: pci_resource_start() is to
James> return the bus start address of the bar. It should essentially
James> be a portable way to obtain the bar value without reading PCI
James> config space directly.

According to Documentation/pci.txt:
pci_resource_start()            Returns bus start address for a given
PCI region

James> We have encountered at least 2 platforms (HP Integrity (IA-64)
James> Olympia rx8620 partition, and a dual-processor IBM eServer
James> pSeries p615) - where the contents of pci_resource_start() vary
James> from the contents of the BARs in config space. For example: on
James> IA64 Olympia: pci_resource_start(pcidev,0) =
James> 0x00000f0030040000; pci bar0 word 0xf0040004, bar1 word 0x0 On
James> PPC eServer: pci_resource_start(pcidev,0) = 0x000003fd80000000;
James> pci bar0 word 0xc0000004, bar1 word 0x0

James> We have demonstrated this on both the 2.4.21 and 2.6.5 kernels.

James> Are these platform bugs that need to be corrected ? or is it a
James> change in the pci_resource_start() definition ?

pci_resource_start will rather give you a cookie that you can pass to
iomap() (ioremap() in the old API) etc. You shouldn't be relying on
the physical bar content for anything in a Linux driver.

Are you unable to access the space after mapping it?

Cheers,
Jes

Re: Potential issue with some implementations of pci_resource_start()

[linux-os]

On Tue, 16 Nov 2004 James.Smart@Emulex.Com wrote:

>
> According to Documentation/pci.txt: pci_resource_start() is to return the bus start address of the bar. It should essentially be a portable way to obtain the bar value without reading PCI config space directly.
>
> We have encountered at least 2 platforms (HP Integrity (IA-64) Olympia rx8620 partition, and a dual-processor IBM eServer pSeries p615) - where the contents of pci_resource_start() vary from the contents of the BARs in config space. For example:
> on IA64 Olympia: pci_resource_start(pcidev,0) = 0x00000f0030040000; pci bar0 word 0xf0040004, bar1 word 0x0
> On PPC eServer:  pci_resource_start(pcidev,0) = 0x000003fd80000000; pci bar0 word 0xc0000004, bar1 word 0x0
>
> We have demonstrated this on both the 2.4.21 and 2.6.5 kernels.
>
> Are these platform bugs that need to be corrected ? or is it a change in the pci_resource_start() definition ?
>
> -- James

pic_resource_start() is supposed to give you something that
ioremap() can use. On 64-bit platforms it is unlikely to be
a physical address, but a "cookie" that ioremap() knows about.

If you want the physical address you are going to have to read
the registers directly. It will give you a number that is useless
as an address, though.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by John Ashcroft.
                  98.36% of all statistics are fiction.

RE: Potential issue with some implementations of pci_resource_start()

[James.Smart]

I started to - but had no idea what pci_resource_end() would correspond to. I'm guessing it's "cookie + N" where N is the size of the BAR. However, this seems really odd and would only be used to calculate the size of N. I figured someone actually in tune with the pci subsytem was better qualified to write the summary.

-- James


> -----Original Message-----
> From: Greg KH [mailto:greg@kroah.com]
> Sent: Wednesday, November 17, 2004 12:45 PM
> To: Smart, James
> Cc: linux-kernel@vger.kernel.org; linux-os@chaos.analogic.com;
> jes@wildopensource.com
> Subject: Re: Potential issue with some implementations of
> pci_resource_start()
> 
> 
> On Wed, Nov 17, 2004 at 09:18:27AM -0500, 
> James.Smart@Emulex.Com wrote:
> > 
> > Can someone please update Documentation/pci.txt so that it 
> has correct
> > definitions for pci_resource_start() and pci_resource_end()...
> 
> Patches gladly accepted for this.  And as you now know exactly what is
> missing, you might be the best person to write such a patch :)
> 
> thanks,
> 
> greg k-h
> 

Re: Potential issue with some implementations of pci_resource_start()

[Greg KH]

On Wed, Nov 17, 2004 at 09:18:27AM -0500, James.Smart@Emulex.Com wrote:
> 
> Can someone please update Documentation/pci.txt so that it has correct
> definitions for pci_resource_start() and pci_resource_end()...

Patches gladly accepted for this.  And as you now know exactly what is
missing, you might be the best person to write such a patch :)

thanks,

greg k-h

RE: Potential issue with some implementations of pci_resource_start()

[James.Smart]

Ok, the question was to flush out what to expect from pci_resource_start(), and if it is functioning as desired, update the documentation to reflect what it actually returns. It is too ambiguous as is (and in many cases, it is the contents of the bar register). The fact it's a cookie is not well known, as it was not the definition I received from private questions to several kernel developers.

Can someone please update Documentation/pci.txt so that it has correct definitions for pci_resource_start() and pci_resource_end()...

FYI: In our case, we have an adapter that can use adapter or host memory for messaging. It detects the use of adapter memory by comparing the bus address given by the driver to it's bar values. So yes - we had to read the config space registers directly to give the adapter the proper values.

-- James S


> From: jes@trained-monkey.org [mailto:jes@trained-monkey.org]
>
> James> Are these platform bugs that need to be corrected ? or is it a
> James> change in the pci_resource_start() definition ?
> 
> pci_resource_start will rather give you a cookie that you can pass to
> iomap() (ioremap() in the old API) etc. You shouldn't be relying on
> the physical bar content for anything in a Linux driver.
> 
> Cheers,
> Jes


> From: linux-os [mailto:linux-os@chaos.analogic.com]
> 
> pic_resource_start() is supposed to give you something that
> ioremap() can use. On 64-bit platforms it is unlikely to be
> a physical address, but a "cookie" that ioremap() knows about.
> 
> If you want the physical address you are going to have to read
> the registers directly. It will give you a number that is useless
> as an address, though.
> 
> Cheers,
> Dick Johnson