linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: cardmgr and hotplug interplay
Date: Sun, 29 Sep 2002 01:29:57 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-103326322306858@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-103316376119993@msgid-missing>

Hi,

> However, after I been through both the documentation for pcmcia-cs and
> for linux-hotplug, I'm still confused about what to expect about them
> working together.  ...

The last time this came up, the expectation was that for 2.4 'cardmgr' would
handle the ISA style cards (non-PCI), and hotplugging would handle CardBus
ones (standard PCI hotplugging).

Plus, someone threatened to teach the kernel how to hotplug those non-PCI
devices.  As of 2.5.39 that might come almost for free when they get
merged into the driver model framework, but I don't know how much of that
has gotten started (or what happens then with cardmgr and related tools).


> My situation is as follows: I have a laptop where I so far have been
> using it with a wireless LAN card which is administrated by pcmcia-cs
> (cardmgr).  I have just brought an ieee1394 (firewire) cardbus card
> and using that with the laptop I became aware of hotplug.
> 
> When I insert the ieee1394 is correctly detected by the hotplug system
> which uses /etc/hotplug/pci.agent to load the kernel modules (ohci1394
> and ieee1394) for the ieee1394 (well, actually it loads all
> pci-modules due to the restrictions of /usr/bin/pcimodules.  This is
> reflected as follow in the syslog

You can disable 'pcimodules' (mv !$ !$-) if that bothers you, but you'd
need to plug things in again after boot to have everything take notice.
Of course a patch to 'pcimodules' would be good too ... :)


> cardmgr recognizes that card is inserted by writing
>   
>   socket 1: CardBus hotplug device
> 
> on the console, but it never executes the script /etc/pcmcia/ieee1394

Right:  normal PCI hotplugging is used, so instead the script
/etc/hotplug/pci/ieee1394 gets run (if it's present).

> When I remove the card, it is again hotplug's PCI system that take of
> the removal, though not very gracefully: 
> 
>   Sep 27 17:23:54 pan kernel: cs: cb_free(bus 7)
>   Sep 27 17:23:54 pan /etc/hotplug/pci.agent: PCI remove event not supported

Right, there's this little problem where there's no reliable way to know
when a module is really no longer needed.  The kernel module system doesn't
pay attention to whether or not the driver is bound to a device ... only
whether it's got a nonzero refcount, and that usually happens only when
some application opens a file to access that driver. Since modutils will
happily remove drivers for devices you haven't yet opened, it's really not
practical to ask it to ever remove drivers.

As I recall things, cardmgr is tracking this issue for the (one or two...)
PCMCIA drivers it loads.  Some of the module changes in 2.5 should IMO include
fixes so that driver unload can work reasonably ... it's not quite clear to
me what's happening there.


> so basically nothing is done (as one would also expect from
> /etc/hotplug/pci.agent).  I don't get any messages from cardmgr. To complete
> the picture ohci1394 also generates some error messages, but I take
> that it just a bug/feature of the driver not prepared for losing it's
> hardware.

Yes.  I had to teach the EHCI driver about that.  It turns out that it's
almost guaranteed that if the hardware gets removed, PCI reads will
return all-ones.  So every place that firewire driver accesses the
device registers, it should check ... and be prepared to clean up.
You have all the equipment you need to generate a patch for that!


> So at this point I have two questions concerning how these packages
> are supposed to work together:
> 1) Is the above behavior indeed correct, i.e., that since hotplug knows
>    the device, cardmgr steps down and does nothing.

That's certainly what I expect to happen.


> 2) I have all respect for the work that the hotplug developers has put
>    into the hotplug system.  But it appears that cardmgr still
>    provides a better handling of the cardbus cards (I haven't tried,
>    but I assume that it would be capable of removing the driver
>    afterwards).  Is there a way letting it not try to handle cardbus
>    cards?

I wouldn't know, but keep in mind that if you go that route you're
suddenly in the business of maintaining lots of entries in that
/etc/pcmcia/config file that are exactly in sync with all the
MODULE_DEVICE_TABLE entries in the PCI drivers ... most of which
are part of the kernel distribution, not the pcmcia package.  That
doesn't sound very much "better"!  :)

I believe that once the module remove issues go away, hotplug can
make the 'rmmod' calls it currently avoids making.  Meanwhile,
the cost of having such modules around is pretty minor, and you
can always 'rmmod' by hand ... you've got to be smarter than rmmod
about whether all the driver's hardware is really gone!

- Dave





-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  reply	other threads:[~2002-09-29  1:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-27 21:49 cardmgr and hotplug interplay Peter Møller Neergaard
2002-09-29  1:29 ` David Brownell [this message]
2002-09-30 17:15 ` dhinds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-103326322306858@msgid-missing \
    --to=david-b@pacbell.net \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).