Patrick Welche <prlw1@newn.cam.ac.uk> writes:

> #define pcmcia_cis_read_1(tuple, idx0)                  \
>     (bus_space_read_1((tuple)->memt, (tuple)->memh, (tuple)->mult*(idx0)))
> 
>      u_int8_t
>      bus_space_read_1(bus_space_tag_t space, bus_space_handle_t handle,
>              bus_size_t offset);
> 
> - How do I find out what the u_int8_t by bus_space_read_1 returned is/means?
>   (not mentioned in bus_space(9))

It's the byte read from the bus. It's not explicitly mentioned, but I
think it's pretty clear...

> - Why is it reading 1 byte with read_1, but the offset is going up in twos
>   as tuple.mult=2 ? Did that want to be read_2 ?

No. PCMCIA permits cards that only support 8-bit-wide accesses, but
uses addresses two bytes apart. It is a little weird.

> - What happens when tuple.ptr points outside of the memory mapped in tuple.memh?
>   as it seems offset=2*ptr, and ptr keeps being incremented ad infinitum if
>   code always==null..

A well-formed set of CIS information will end with CIS_TUPLE_END. It's
true that a malformed CIS would cause problems for us here. If you
wanted to be paranoid, you could insert a check that the total
advancement of tuple.ptr is less than PCMCIA_CIS_SIZE/tuple.mult.

        - Nathan