Re: [Patch] PCI: check szhi when sz is 0 for 64 bit pref mem

From: Andrew Morton
Date: Mon Nov 06 2006 - 17:05:14 EST


On Fri, 3 Nov 2006 21:27:35 -0800
"Yinghai Lu" <yinghai.lu@xxxxxxx> wrote:

> For co-prcessor with mem installed, the ram will be treated to pref mem.

What is "pref mem"?

> Under 64bit kernel, when 64bit pref mem size is above 4G, sz from pci_size in low bits, will get 0,
> at this point, we need to check szhi too. Otherwise the pre-set value by firmware can not be read
> to resrource struct, it will skip that resource, and try to hi 32 bit as another 32bit resource.
>
> Cc: Myles Watson <myles@xxxxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Yinghai Lu <yinghai.lu@xxxxxxx>
>
>
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -165,8 +165,13 @@ static void pci_read_bases(struct pci_de
> l = 0;
> if ((l & PCI_BASE_ADDRESS_SPACE) == PCI_BASE_ADDRESS_SPACE_MEMORY) {
> sz = pci_size(l, sz, (u32)PCI_BASE_ADDRESS_MEM_MASK);
> - if (!sz)
> - continue;
> + /* for 64bit pref, sz could be 0, if the real size is bigger than 4G,
> + so need to check szhi for it
> + */
> + if ((l & (PCI_BASE_ADDRESS_SPACE | PCI_BASE_ADDRESS_MEM_TYPE_MASK))
> + != (PCI_BASE_ADDRESS_SPACE_MEMORY | PCI_BASE_ADDRESS_MEM_TYPE_64))
> + if (!sz)
> + continue;
> res->start = l & PCI_BASE_ADDRESS_MEM_MASK;
> res->flags |= l & ~PCI_BASE_ADDRESS_MEM_MASK;
> } else {
> @@ -188,6 +193,12 @@ static void pci_read_bases(struct pci_de
> szhi = pci_size(lhi, szhi, 0xffffffff);
> next++;
> #if BITS_PER_LONG == 64
> + if( !sz && !szhi) {
> + res->start = 0;
> + res->end = 0;
> + res->flags = 0;
> + continue;
> + }
> res->start |= ((unsigned long) lhi) << 32;
> res->end = res->start + sz;
> if (szhi) {

I don't really understand what this patch does.

We have a PCI device with a 64-bit BAR and the size is also 64-bit and is
larger than 4G, yes?

But the code appears to already be attempting to handle such devices.
Confused.

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