pci_map_rom bug?

pci_map_rom bug?

[Jesse Barnes]

Jon, it looks like the loop at the bottom of pci_map_rom is busted?

        do {
                void __iomem *pds;
                /* Standard PCI ROMs start out with these bytes 55 AA */
                if (readb(image) != 0x55)
                        break;
                if (readb(image + 1) != 0xAA)
                        break;
                /* get the PCI data structure and check its signature */
                pds = image + readw(image + 24);
                if (readb(pds) != 'P')
                        break;
                if (readb(pds + 1) != 'C')
                        break;
                if (readb(pds + 2) != 'I')
                        break;
                if (readb(pds + 3) != 'R')
                        break;
                last_image = readb(pds + 21) & 0x80;
                /* this length is reliable */
                image += readw(pds + 16) * 512;
        } while (!last_image);

It looks like it's trying to verify all the ROMs on a given PCI device rather 
than just the one we just ioremap'd above.  Should this check just be inline 
and the loop deleted?  In that case, all of the breaks would turn into return 
NULLs (though the code should probably be refactored to make that a little 
clearer) along with an iounmap?

Thanks,
Jesse

Re: pci_map_rom bug?

[Jon Smirl]

On Wed, 16 Feb 2005 16:00:47 -0800, Jesse Barnes <jbarnes@sgi.com> wrote:
> It looks like it's trying to verify all the ROMs on a given PCI device rather
> than just the one we just ioremap'd above.  Should this check just be inline
> and the loop deleted?  In that case, all of the breaks would turn into return
> NULLs (though the code should probably be refactored to make that a little
> clearer) along with an iounmap?

The ROM experts on linux-pci supplied that code. It is legal to have
multiple images in a ROM for different formats, x86, OpenFirmware,
proprietary. The loop is adding all of the images together. Above we
IO remapped the entire PCI window which may be 64K and it contained
two images each at 20K. The extra loop returns the smaller size. This
lets the copy_rom case allocate 40K of memory instead of 64K.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: pci_map_rom bug?

[Jesse Barnes]

On Thursday, February 17, 2005 8:29 am, Jon Smirl wrote:
> On Wed, 16 Feb 2005 16:00:47 -0800, Jesse Barnes <jbarnes@sgi.com> wrote:
> > It looks like it's trying to verify all the ROMs on a given PCI device
> > rather than just the one we just ioremap'd above.  Should this check just
> > be inline and the loop deleted?  In that case, all of the breaks would
> > turn into return NULLs (though the code should probably be refactored to
> > make that a little clearer) along with an iounmap?
>
> The ROM experts on linux-pci supplied that code. It is legal to have
> multiple images in a ROM for different formats, x86, OpenFirmware,
> proprietary. The loop is adding all of the images together. Above we
> IO remapped the entire PCI window which may be 64K and it contained
> two images each at 20K. The extra loop returns the smaller size. This
> lets the copy_rom case allocate 40K of memory instead of 64K.

Ah, ok, but we still have the situation that cause me to post the cleanup 
patch in the first place--pci_map_rom succeeds, but the first two bytes 
aren't 0x55aa but 0x0303...  Any ideas?

Jesse

Re: pci_map_rom bug?

[Jon Smirl]

On Thu, 17 Feb 2005 09:14:04 -0800, Jesse Barnes <jbarnes@sgi.com> wrote:
> Ah, ok, but we still have the situation that cause me to post the cleanup
> patch in the first place--pci_map_rom succeeds, but the first two bytes
> aren't 0x55aa but 0x0303...  Any ideas?

Check for returned size of zero and ignore the ROM?

> 
> Jesse
> 


-- 
Jon Smirl
jonsmirl@gmail.com