The pci_mapreg_map() manual page indicates that you can map a ROM using
PCI_MAPREG_TYPE_ROM.

Currently this won't work.  There is no PCI_MAPREG_TYPE_ROM macro defined.

I'd like to first propose that we fix this.  I'm volunteering to do it.

The next problem is that PCI_MAPREG_TYPE_ROM needs to have a value
assigned to it.  This is where it gets sticky:

1) Currently all other PCI_MAPREG_TYPE_xxx values correspond to actual
values that can be placed in a BAR (base address register).   (This
includes btw,  PCI_MAPREG_ROM_ENABLE)

2) The ROM BAR at 0x30 has a different definition for which bits it can
use.  E.g. bit 0 in the ROM bar enables the address decoder, whereas in
an IO/Memory bar it indicates that the BAR is for IO address decoding.

3) There are no "unused" bits for me to use and stay within the current
defined bit patterns for PCI BARs.


Okay, so my *proposal* here is to use an illegal ("reserved") bit
pattern for PCI_MAPREG_TYPE_MEM and call it PCI_MAPREG_MEM_TYPE_ROM,
that pattern will be 0x6.  If you look in the PCI specs, that pattern is
not legal for a memory address decoder.

The second bit is that I will create PCI_MAPREG_TYPE_ROM that will be
defined as PCI_MAPREG_TYPE_MEMORY | PCI_MAPREG_MEM_TYPE_ROM.

I think will add the necessary logic to handle this all properly.

The ugliness from this stems that I'll be leveraging the PCI_MAPREG_TYPE
field in an "inconsistent" way because those bits will never get passed
as is to the device.

The only other solutions I can see to this are to

a) create another argument to pci_mapreg_map() that indicates the
mapping register type *separately* from the address decoder bits,

b) create a "switch" table where the pci mapreg_map() argument is not
necessarily the same as the bits in the PCI registers, or

c) create some new function, pci_mapreg_map_rom() or somesuch, that does
the right thing without disrupting anything else, and change the
documentation to reflect this (and change the documentation to match)

Hopefully this isn't another bikeshed. :-)

    - Garrett

-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191