In message <[EMAIL PROTECTED]> 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

: 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


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

Reply via email to