In message <[EMAIL PROTECTED]> Mike Smith writes:
: No; the CIS parser should know which function it's being called on behalf 
: of, and simply elide the tuples that don't relate to that function.

This isn't always the right thing to do.  At least in the 16-bit
world, there are drivers that want to look at the CIS entries for the
other function of the card for various reasons (some of them need to
know what kind of modem is present, iirc, to initalize some things in
a non-standard way, the example was the NetBSD driver mhz, iirc).  I
don't wish to preclude that.

: Export the commonly-known stuff through the "right" interface
: (eg. cardbus_get_cistuple(dev, CARDBUS_CIS_STATION_ADDRESS)) and then 
: provide a backdoor (cardbus_get_cistuple(dev, CARSBUS_CIS_RAW + index)) 
: for the evil side, perhaps.

Right now pccard exports this as:
        uchar8_t ether_addr[ETEHR_ADDR_LEN];
        pccard_get_ether(dev, ether_addr);

where pccard_get_ether is generated by really ugly, but usefully
stolen from pci, macros in dev/pccard/pccardvar.h.  The OLDCARD code
set this from the userland after parsing the CIS.  NEWCARD currently
doesn't implement this correctly, but will need to do so shortly.

I'd like to do exactly the same thing for cardbus:
        uchar8_t ether_addr[ETEHR_ADDR_LEN];
        cardbus_get_ether(dev, ether_addr);
to make things easy.

I don't think that we can easily do the index thing for CIS entries,
for reasons that I've talked about before.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to