Date: Tue, 21 Nov 2000 14:25:33 -0700 From: Warner Losh <imp@village.org> To: "Justin T. Gibbs" <gibbs@scsiguy.com> Cc: wpaul@FreeBSD.ORG (Bill Paul), freebsd-current@FreeBSD.ORG Subject: Re: Getting at cardbus CIS data from inside drivers Message-ID: <200011212125.OAA37742@harmony.village.org> In-Reply-To: Your message of "Tue, 21 Nov 2000 14:07:53 MST." <200011212107.eALL7r466624@aslan.scsiguy.com> References: <200011212107.eALL7r466624@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200011212107.eALL7r466624@aslan.scsiguy.com> "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 system. 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). Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200011212125.OAA37742>