public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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?


-

  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