PCMCIA _detach called after _config - Portable

This is a discussion on PCMCIA _detach called after _config - Portable ; Hi. I'm writing driver for a new PCMCIA card. I'm almost there, but not quite. The driver is registered (register_pccard_driver()) and the _attach and I get an insertion event to my event handler. The trouble is, as soon as I ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: PCMCIA _detach called after _config

  1. PCMCIA _detach called after _config

    Hi.

    I'm writing driver for a new PCMCIA card. I'm almost there, but not
    quite. The driver is registered (register_pccard_driver()) and the
    _attach and I get an insertion event to my event handler.

    The trouble is, as soon as I return from servicing the insertion event
    (calling my _config routine), the _detach routine gets called. If I
    understand the internals, this means that an unbind was done.

    Anyone know why cardmgr would do this? I see an error in the messages
    file:
    cardmgr[2383]: get dev info on socket 1 failed: No such device
    However, I believe that is occurring before it calls my _attach
    routine and generates the insertion event.

    Failing any ideas, where can I find the source to cardmgr? I don't
    see a source RPM for the on the RH9 SRPM CDs and Sourceforge doesn't
    seem to know anything about cardmgr.
    Thanks,
    Steve

  2. Re: PCMCIA _detach called after _config

    On Wed, 29 Oct 2003 12:16:45 -0800, Steve Schefter typed:

    > Failing any ideas, where can I find the source to cardmgr? I don't see
    > a source RPM for the on the RH9 SRPM CDs and Sourceforge doesn't seem to
    > know anything about cardmgr.


    Install the kernel-source-.i386.rpm

    Or look here; http://pcmcia-cs.sourceforge.net/

    --
    SCO + RICO Act = Justice

    Hi! I'm a .sig virus! Copy me to your .sig!


  3. Re: PCMCIA _detach called after _config

    Steve Schefter wrote:
    > Hi.


    > I'm writing driver for a new PCMCIA card. I'm almost there, but not
    > quite. The driver is registered (register_pccard_driver()) and the
    > _attach and I get an insertion event to my event handler.


    > The trouble is, as soon as I return from servicing the insertion event
    > (calling my _config routine), the _detach routine gets called. If I
    > understand the internals, this means that an unbind was done.


    > Anyone know why cardmgr would do this?


    Does your config routine fill in the "dev" field of the dev_link
    structure, to point to a dev_node_t structure? That information gets
    passed to cardmgr; if you don't fill it in, cardmgr says, the driver
    did not configure a device, so it gets unbound.

    > Failing any ideas, where can I find the source to cardmgr? I don't
    > see a source RPM for the on the RH9 SRPM CDs and Sourceforge doesn't
    > seem to know anything about cardmgr.


    Sourceforge knows about pcmcia-cs

    -- Dave

  4. Re: PCMCIA _detach called after _config

    Lenard wrote in message news:...
    > On Wed, 29 Oct 2003 12:16:45 -0800, Steve Schefter typed:
    >
    > > Failing any ideas, where can I find the source to cardmgr? I don't see
    > > a source RPM for the on the RH9 SRPM CDs and Sourceforge doesn't seem to
    > > know anything about cardmgr.

    >
    > Install the kernel-source-.i386.rpm


    That's for kernel source. cardmgr, being a user-space thing, isn't in
    there.

    >
    > Or look here; http://pcmcia-cs.sourceforge.net/


    Thanks. That's what I've been working with to this point.

    I discovered after posting this yesterday, that the source for cardmgr
    is indeed with the pcmcia driver (kernel level) in one tarball on
    sourceforge. I guess I'm just a little too used to the other
    protocols (ISDN, X.25, etc) where the user level utilities are kept in
    a separate tarball from the driver source. This is handy, just not
    what I expected from past experience.

    Having put some debugging in the pcmcia module and cardmgr, it turns
    out that it was because I wasn't filling in the dev_node_t structure.
    I also see that just as I go back to post this "found it" reply, Dave
    suggested this would be the problem. Thanks anyways Dave!

    Steve

+ Reply to Thread