jonathan@Pescadero.dsg.stanford.edu said:
> Uhm. Can you suggest suitable, separate, #define names and values for
> the "set payload" portion , hich I beleive is 0x5000 (values for other
> sizes would be nice, is it log2) and the "reset error status", 0x000f
> << 16? 

For accuracy, this is not the payload size but the maximum size of
data the card can request with one memory read transaction. That
request can be replied by multiple "completions" carrying a payload
each which are limited by the "max payload" size.
According to cube's config space dump, this card supports only 128
bytes payload which is the minimum allowed by the standard.
As I understand it, the payload things should be handled by the BIOS
so that kernels w/o PCIexpress knowledge get a reasonably working
system (but I'm not sure what BIOSes really do).

Also, clearing the sticky error bits looks pointless to me because
error reporting doesn't get enabled anyway.

Payload / read request sizes are log2, with an offset of 7,
something like 2^(n+7) where n is a 3-bit field. The absolute
maximum is 4096, thus 6 and 7 are reserved values for n.
The field is named "Max_Read_Request_Size" in the spec, so I'd
call it PCECAP_CSR_MAXREADREQUESTSIZE or so.
(I'd personally prefer a little helper function for setting it, with
comments explaining what's going on. Bit shifting with xxx_SHIFT
and xxx_MASK macros doesn't give readable code.)

> * Add #defines for offsets 0x08 and 0x0a inside a PCI-e capability,
>   maybe PCI_PCIECAP_DEV_STS and PCI_PCE_CAP_DEV_CTL

Since we can only do 32-bit PCI config space accesses, a separate
definition for the status part isn't useful.
(btw, the PCI power management definitions could be cleant up,
and the pci_powerstate() function doesn't look that useful anyway.
Instead, the "can't wake up from D3" stuff could be centralized.)

best regards
Matthias