joda@pdc.kth.se (Johan Danielsson) writes:
> +    struct cardbus_attach_args *ca = aux;
> +    if(PCI_CLASS(ca->ca_class) == PCI_CLASS_COMMUNICATIONS &&
> +       PCI_SUBCLASS(ca->ca_class) == PCI_SUBCLASS_COMMUNICATIONS_SERIAL)
> +	return 1;
> +    return 0;

This is not right.

(1) it's not clear to me that all devices which report that
class/subclass actually provide (only) a 16x50 interface at BAR 10.
Inability to rely on this even for single-port devices is what drove
me to create 'puc'.  If there is a PCI standard document which says
that you can expect these values to mean 16x50 at BAR @ 0x10, i'd
_love_ to see it.  Perhaps it's dependent on the programming interface
field.

(2) COMMUNICATIONS/MODEM (0x03) has several programming interfaces
which are standardized to provide 16x50-compatible device via the BAR
@ 0x10.  You should take them into account.

Do the cardbus standards say anything relevant here, in a way that's
more specific than PCI?


> +    if(cardbus_mapreg_map(csc->ct, CARDBUS_BASE0_REG, 
> +			  PCI_MAPREG_TYPE_IO, 
> +			  0, &iot, &ioh, &adr, NULL) != 0)
> +	panic("io alloc");

Who's to say it'll be I/O?  At the very least, the PCI 2.2 spec
specifically indicates (on page 261) that the 16x50-compatible
COMMUNICATIONS/MODEM devices mapped via the BAR @ 0x10 may be in
either memory OR I/O space.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.