From: Christoph Hellwig <hch@infradead.org>
To: "chas williams (contractor)" <chas@cmf.nrl.navy.mil>
Cc: netdev@oss.sgi.com, davem@redhat.com
Subject: Re: [PATCH][ATM]: [ambassador] eliminate pci_find_device()
Date: Thu, 21 Oct 2004 12:38:41 +0100 [thread overview]
Message-ID: <20041021113841.GA3720@infradead.org> (raw)
In-Reply-To: <200410211126.i9LBQbFT008844@ginger.cmf.nrl.navy.mil>
> // Did one of our cards generate the interrupt?
> - while (dev) {
> + list_for_each(p, &amb_devs) {
> + dev = list_entry(p, struct amb_dev, entry);
> if (dev == dev_id)
> break;
> - dev = dev->prev;
> + dev = NULL;
> }
> // impossible - unless we add the device to our list after both
> // registering the IRQ handler for it and enabling interrupts, AND
this debug check is superflous.
>
> @@ -1554,19 +1556,19 @@
>
> /********** housekeeping **********/
> static void do_housekeeping (unsigned long arg) {
> - amb_dev * dev = amb_devs;
> + amb_dev * dev;
> + struct list_head *p;
> // data is set to zero at module unload
> (void) arg;
>
> if (housekeeping.data) {
> - while (dev) {
> + list_for_each(p, &amb_devs) {
> + dev = list_entry(p, struct amb_dev, entry);
this really should be a per-device timer - or even better using
schedule_delayed_work()
With these two changes you could get rid of amb_devs easily. If you still
want to keep it for some reason at least use list_for_each_entry.
> + list_del(&dev->entry);
> +
> + PRINTD(DBG_INFO|DBG_INIT, "closing %p (atm_dev = %p)", dev, dev->atm_dev);
> + // the drain should not be necessary
> + drain_rx_pools(dev);
> + interrupts_off(dev);
> + amb_reset(dev, 0);
> + free_irq(dev->irq, dev);
> + pci_disable_device(pci_dev);
> + destroy_queues(dev);
> + atm_dev_deregister(dev->atm_dev);
> + kfree(dev);
> + pci_release_region(pci_dev, 1);
this doesn't look correct (without knowing the atm subsystem in detail), in
general you need to unregister from the subsystem first so you don't get
new work, and then you can start tearing the hardware down.
Also disabling the device before releasing the regions doesn't make too much
sense to me, even if it may be valid.
next prev parent reply other threads:[~2004-10-21 11:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-21 11:26 [PATCH][ATM]: [ambassador] eliminate pci_find_device() chas williams (contractor)
2004-10-21 11:38 ` Christoph Hellwig [this message]
2004-10-21 11:51 ` chas williams (contractor)
2004-10-22 1:29 ` chas williams (contractor)
2004-10-22 5:14 ` David S. Miller
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=20041021113841.GA3720@infradead.org \
--to=hch@infradead.org \
--cc=chas@cmf.nrl.navy.mil \
--cc=davem@redhat.com \
--cc=netdev@oss.sgi.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;
as well as URLs for NNTP newsgroup(s).