In message <[EMAIL PROTECTED]> "Justin T. Gibbs" writes:
: >The problem with a read/seek interface is that you are consuming a
: >resource (a memory window) while you are using it.
: Yes, but this is the client's resource to use anyway.

IIRC, it is shared at the bridge, so the client driver needs to
conserve this resource.  The comment was more of a thnking out loud
for the need to have an open and close (or in this case map and unmap)
around its use.

: >You'd need an
: >open/close on top of that as well to properly map things in to start
: >and then free them at the end.  Plus you might want a ftell sort of
: >interface as well.  I'll likely punt on the seek/ftell part.
: I think it was Jonathan that mentioned that at times when you read
: one entry you want to skip to another entry that it may reference.
: I don't have the spec to know, but that is why I thought the flexibility
: of having a seeking interface might be necessary.

That's one reason that I'd want the callback interface.  There are
pointers in CIS to other CIS entries that the driver shouldn't care
about.  However, these are relatively rare, but do appear in
multi-function cards (at least for 16-bit cards) and so would likely
need to be taken care of.  I could have something that would skip
ahead, but it wouldn't be a fully general seek/ftell function.  That
moves more of the processing into the driver than I'd rather see, but
I don't see a clean way around it.

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).

And if you provide this, then people will want to just look at the cis
entries for their function only next, which is another interface.  Or
they will want to search for a certain kind of cis entry.  I'm
disinclined to make this interface too rich.

Oh, and I'd have to make sure that the CIS pointers were sane, which
can be hard.  One of the problems with the NetBSD code, at least in
the past, is that it was too believing that the CIS entries would be
compliant with the specs.  So certain 16-bit cards would crash the

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).


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

Reply via email to