From owner-freebsd-current Tue Nov 21 13:25:45 2000 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 3DF1037B4C5; Tue, 21 Nov 2000 13:25:39 -0800 (PST) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.0/8.11.0) with ESMTP id eALLPYQ32507; Tue, 21 Nov 2000 14:25:35 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA37742; Tue, 21 Nov 2000 14:25:34 -0700 (MST) Message-Id: <200011212125.OAA37742@harmony.village.org> To: "Justin T. Gibbs" Subject: Re: Getting at cardbus CIS data from inside drivers Cc: wpaul@FreeBSD.ORG (Bill Paul), freebsd-current@FreeBSD.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> Date: Tue, 21 Nov 2000 14:25:33 -0700 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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