From: Andrew Morton <andrewm@uow.edu.au>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: David Hinds <dhinds@sonic.net>,
Jeff Garzik <jgarzik@mandrakesoft.mandrakesoft.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] network driver updates
Date: Thu, 15 Feb 2001 22:49:22 +1100 [thread overview]
Message-ID: <3A8BC242.2C62DAA1@uow.edu.au> (raw)
In-Reply-To: <Pine.LNX.3.96.1010214020707.28011E-100000@mandrakesoft.mandrakesoft.com> <3A8A7159.AF0E6180@colorfullife.com> <3A8A8937.A77BA18D@uow.edu.au> <20010214093859.B20503@sonic.net> <3A8AC6B6.9790FF9C@colorfullife.com>
Manfred Spraul wrote:
>
> David Hinds wrote:
> >
> > Say the driver is linked into the kernel. Hot plug drivers should not
> > all complain about not finding their hardware.
> >
>
> That's handled by pci_module_init(), check <linux/pci.h>:
> if CONFIG_HOTPLUG is enabled, then pci_module_init() never returns with
> -ENODEV.
>
> Which means that eisa cards will never be probed in a hotplug enabled
> kernel.
>
> And loading the current 3c59x.c into a non CONFIG_HOTPLUG non EISA
> kernel results in a disconnected driver:
> it's _not_ registered as a pci driver, pci_module_init() calls
> pci_unregister_driver().
That's what we want to happen, isn't it? If it's not a hotplug
kernel and the hardware isn't there at boot time, don't register
the PCI driver. But still scan for EISA devices. That's what
the patch I sent yesterday does. Here it is:
static int __init vortex_init (void)
{
int pci_rc, eisa_rc;
pci_rc = pci_module_init(&vortex_driver);
eisa_rc = vortex_eisa_init();
if (pci_rc == 0)
vortex_have_pci = 1;
if (eisa_rc > 0)
vortex_have_eisa = 1;
return (vortex_have_pci + vortex_have_eisa) ? 0 : -ENODEV;
}
Really, vortex_have_pci should be called
vortex_have_pci_or_hotplug_and_dont_have_pci.
Look. When the driver's init_module() method is called
there are four combinations which must be catered for
(ignoring EISA):
CONFIG_HOTPLUG=n, MODULE=false
If the hardware isn't there, don't register
the pci_driver. It can't _do_ anything.
CONFIG_HOTPLUG=n, MODULE=true
If the hardware isn't there, barf. modprobe will
remove the driver again.
CONFIG_HOTPLUG=y, MODULE=false
If the hardware isn't there, register the pci
driver, because the hardware may appear later
CONFIG_HOTPLUG=y, MODULE=true
If the hardware isn't there, barf. modprobe will remove
the driver. Later, when the hardware is inserted, another
modprobe will succeed.
This is what yesterday's patch implements.
Now, the thing I don't understand about David's design is the
final one. What 3c575_cb does is:
CONFIG_HOTPLUG=y, MODULE=true
If the hardware isn't there, register the driver and
hang around.
Why?
BTW: How come CONFIG_PCMCIA requires CONFIG_HOTPLUG? Doesn't
it make sense to be able to have glued-in Cardbus devices?
-
next prev parent reply other threads:[~2001-02-15 11:40 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.3.96.1010214020707.28011E-100000@mandrakesoft.mandrakesoft.com>
2001-02-14 11:51 ` [PATCH] network driver updates Manfred Spraul
2001-02-14 11:54 ` Jeff Garzik
2001-02-14 13:13 ` Arnaldo Carvalho de Melo
2001-02-14 12:00 ` Jeff Garzik
2001-02-14 13:33 ` Andrew Morton
2001-02-14 17:38 ` David Hinds
2001-02-14 17:54 ` Jeff Garzik
2001-02-14 17:56 ` Manfred Spraul
2001-02-15 11:49 ` Andrew Morton [this message]
2001-02-15 17:08 ` David Hinds
2001-02-15 22:16 ` Andrew Morton
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=3A8BC242.2C62DAA1@uow.edu.au \
--to=andrewm@uow.edu.au \
--cc=dhinds@sonic.net \
--cc=jgarzik@mandrakesoft.mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=manfred@colorfullife.com \
/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