Date: Mon, 27 Nov 2000 23:54:25 -0700 From: Warner Losh <imp@village.org> To: Jonathan Chen <jon@spock.org> Cc: "Justin T. Gibbs" <gibbs@scsiguy.com>, Bill Paul <wpaul@FreeBSD.ORG>, freebsd-current@FreeBSD.ORG Subject: Re: Getting at cardbus CIS data from inside drivers Message-ID: <200011280654.XAA08288@harmony.village.org> In-Reply-To: Your message of "Mon, 27 Nov 2000 17:13:20 EST." <20001127171320.D2669@spock.org> References: <20001127171320.D2669@spock.org> <200011211932.MAA36176@harmony.village.org> <200011212028.eALKSk465978@aslan.scsiguy.com>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <20001127171320.D2669@spock.org> Jonathan Chen writes: : As I see it, there are several ways this can be implemented, with several : issues to consider. : 1) How is the information passed? : a) callback : b) driver code calling cardbus_get_cistuple(dev, tuplenum) Yes. I think there's a strong preference for 1b. It also follows the card services model in the standard. : 2) When is the information passed? : a) before probe (for callback) : b) between probe and attach (for callback) : c) automatically after attach (for callback) : d) when child requests (for either) The 16bit code reads the CIS before the probe so that information in the CIS can be used during the probe to answer the probe question "Is this my device?". The 16-bit code currently uses the callback mechanism, but it is done at the request time (eg, go read the cis, and give me a callback to this function for each tuple). : 3) When is the information read? : a) Once when CIS is read and parsed initially by the bridge, and once : when it's time to pass the info to child. : b) Only once when CIS is read and parsed initially by the bridge. CIS : info is stored in malloc'ed kernel memory : c) This point may be moot if the cardbus bus does not read CIS, or if : the bridge reading/parsing CIS step is delayed. When needed, I think is the answer. There's no reason not to re-read the CIS occasionally, as it is fairly cheap to do so. There is a reason not to read it during normal operations of the driver (since it ties up a memory slot that might otherwise be used by the driver), but that's up to the driver to deside. : Personally, I am somewhat torn between using callback or not, but I'm : leaning more towards using an interface like cardbus_get_cistuple(). I'm leaning that way myself (cf other posts I've made). : The reasoning behind this is that we may not know when, if ever, a driver : would need CIS data. It might need this information in the probe code : (unlikely for correctly implemented cardbus hardware and driver set, but : IMHO we should keep the interface for cardbus and pccard the same, and : pccard drivers might need this functionality) Having callbacks before : attach that are actually useful might introduce a whole lot of messiness we : don't need. Right, callbacks were never intended to be a oneshot at some magic point during the probe/attach process, but rather a one per tuple callback in response to a specific request by the driver to read the CIS. : As for point 3, I think that we should read the CIS prior to probe or : attach of the child driver, and save the information in memory. My : reasoning is that we can't be sure whether we can map and read the CIS : after the driver is in control. For all we know the hardware might have : been put into some mode where CIS reading would be turned off. True a : driver programmer can get around that, but why not just stick it in the : ivars to begin with? Much of the parsed information in the 16-bit case is saved in the ivars, but the whole CIS isn't. We could save the whole CIS chain in the ivars, except for one important issue. registers. The pccard standard allows, and specifically talks about, CIS values that the parsing program doesn't understand. Vendors are free to have a CIS value of, say, 129 (any value >= 128, save 255) and have it be the registers for the hardware that cause things to happen when read/written. This isn't very common (although the raylan driver comes closest), but it can happen. We could just ignore these tuples completely (which is what we're supposed to do anyway, per the spec), but that would leave driver writers out in the cold when it comes time access these tuples. Of course my tuple reading api I posted earlier didn't allow for this (I read the standard on my two plane trips this weekend) as it copied the CIS out to a user buffer. But most of this is moot because most drivers will just want to grab a network ID or a model number and won't care about the rest of the CIS space. 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?200011280654.XAA08288>