> IIRC, and I haven't looked it up, the CIS entries that would be
> problematical have two next pointers.  One is for the next function,
> while the other is for the first entry specific to this function.  The
> driver code could look at the CIS entry to tell what to do, and if it
> was the wrong function, call
>       cis_skip_this_function(dev, cookie, cis);
> which would skip this function and position the read pointer hidden in
> the cookie to point to the first entry in the next function's cis (or
> more accurately, the first entry in the series of entries that are
> specific to that function).

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.

> It is complications like this that lead me to want to not allow CIS
> reading at all, but rather provide the commonly parsed information
> easily to the driver.  I don't want drivers groveling through all this
> stuff to find an ethernet address when the bus is able to parse the
> CIS and return this on request.  Having said that, and based on my
> experience with some really whacko hardware in the 16-bit world, I
> think that I can't justify this stand because it makes writing a
> device driver for whacked out hardware impossible w/o gross hacks (cf
> older revs of if_xe.c).

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.

... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E

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

Reply via email to