linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <matthew@wil.cx>
To: eran liberty <eran.liberty@gmail.com>
Cc: Eran Liberty <liberty@extricom.com>,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org,
	Jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: [PATCH 2.6.26] PCI: refuse to re-add a device to a bus upon pci_scan_child_bus()
Date: Tue, 22 Jul 2008 05:49:30 -0600	[thread overview]
Message-ID: <20080722114929.GA7337@parisc-linux.org> (raw)
In-Reply-To: <ffc2b1d40807220121r44823a89jf0126bc1f5273443@mail.gmail.com>

On Tue, Jul 22, 2008 at 11:21:06AM +0300, eran liberty wrote:
> > I think this is your real problem, that you're rescanning the entire
> > bus.  I don't think that's the route we'd recommend taking.
> 
> My stating point was that I have loaded a new design into a
> programmable device which sits on the pci device. The new design can
> implement numerous pci devices or non at all. I can think of an easy
> way (or clean one) to scan only the programmable device. Scanning the
> whole bus seemed reasonable.

That's what pci_scan_slot() is for.  It scans the first function at the
device number, then (if the header indicates it's a multifunction
device) scans the other functions associated with that device.  eg you
could call pci_scan_slot(bus, 0x30) and it will create function 06.0
(and potentially 06.1, 06.2, ...)

You presumably already have the devfn for the existing device since
you're able to call pci_remove_bus_device().

> > Why don't you call pci_scan_slot() instead?  You won't get the benefit of
> > pcibios_fixup_bus(), but I'm not convinced that's safe to call on a bus
> > that's already been scanned.
> 
> As said its not exactly a slot its more like a regular pci device that
> someone suddenly welded into the pci bus. Its not a hotplug as well,
> and I do not want to give up on the pcibios_fixup_bus()

Why not?  What architecture are you using?  What does
pcibios_fixup_bus() do for you?

(as a side-note, I'd like to reimplement the pcibios_fixup_*() routines;
I think a lot of what they do can be done more generically these days.
It'll take a while and isn't high on my priority list).

> As it is, with my patch applied i successfully go over the bus and
> remove my own devices before I reprogram the
> programmable device.
> 
> while ((dev = pci_get_device(PCI_VENDOR_ID_MYCOMP,PCI_DEVICE_ID_MYDEV,NULL))
> != NULL) {
> 	pci_remove_bus_device(dev);
> 	pci_dev_put(dev);
> }
> 
> Load a new design into it.
> 
> Then scan the entire bus and add the newly discovered devices.
> 
> bus = null;
> while ((bus = pci_find_next_bus(bus)) != NULL) {
> 	pci_scan_child_bus(bus);
> 	pci_bus_assign_resources(bus);
> 	pci_bus_add_devices(bus);
> }
> 
> As seen here, this sequence of instructions seems very intuitive. It
> will fail without the patch upon pci_bus_add_devices().

Seems utterly unintuitive to me.  You're doing a lot of unnecessary work
here, and if you have two cards in your machine, you'll take away both
of them when you reload either of them.

What you should do is cache the pci_bus and the devfn at startup:

static struct pci_bus *my_bus;
static int my_devfn;

	struct pci_dev *dev = pci_get_device(PCI_VENDOR_ID_MYCOMP,
					PCI_DEVICE_ID_MYDEV, NULL);
	if (!dev)
		return -ENODEV;
	my_bus = dev->bus;
	my_devfn = dev->devfn;
	pci_dev_put(dev);

when you want to remove it:

	for (func = 0; func < 8; func++)
		struct pci_dev *dev = pci_get_slot(my_bus, my_devfn + func);
		if (!dev)
			continue;
		pci_remove_bus_device(dev);
		pci_dev_put(dev);
	}

when you want to rescan it:

	pci_scan_slot(my_bus, my_devfn);

(this only handles one programmable card.  The basic idea could be
extended to handle multiple cards if you need to do that).

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

  reply	other threads:[~2008-07-22 11:49 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-18 14:18 2.6.24-rc4: pci_remove_bus_device() => pci_scan_child_bus() => pci_bus_add_devices bug? Eran Liberty
2008-07-20 10:31 ` [PATCH 2.6.24-rc4] PCI: refuse to re-add a device to a bus upon pci_scan_child_bus() Eran Liberty
2008-07-20 16:48   ` Eran Liberty
2008-07-21 19:18 ` [PATCH 2.6.26] " Eran Liberty
2008-07-21 19:49   ` Matthew Wilcox
2008-07-22  8:21     ` eran liberty
2008-07-22 11:49       ` Matthew Wilcox [this message]
2008-07-22 13:08         ` Eran Liberty
2008-07-22 13:14         ` Eran Liberty
2008-07-22 14:13           ` Matthew Wilcox
2008-07-22 15:25             ` Eran Liberty
2008-07-22 16:52               ` Matthew Wilcox
2008-07-22 17:41                 ` Eran Liberty
2008-07-22 18:11                   ` Matthew Wilcox
2008-07-23 18:31                     ` Eran Liberty
2008-07-27 11:01                       ` Eran Liberty
2008-07-27 15:08                         ` Matthew Wilcox
2008-08-18  8:08 ` ftrace introduces instability into kernel 2.6.27(-rc2,-rc3) Eran Liberty
2008-08-18 15:07   ` Steven Rostedt
2008-08-18 15:47     ` Mathieu Desnoyers
2008-08-18 16:12       ` Steven Rostedt
2008-08-18 17:04         ` Mathieu Desnoyers
2008-08-18 17:21       ` Scott Wood
2008-08-18 18:27         ` Steven Rostedt
2008-08-18 18:29           ` Scott Wood
2008-08-19  1:53           ` Benjamin Herrenschmidt
2008-08-19  2:28             ` Steven Rostedt
2008-08-19  2:39               ` Benjamin Herrenschmidt
2008-08-19  2:41                 ` Steven Rostedt
2008-08-19  2:47                   ` Mathieu Desnoyers
2008-08-19  3:32                     ` Steven Rostedt
2008-08-19  3:36                       ` Mathieu Desnoyers
2008-08-19  4:00                         ` Steven Rostedt
2008-08-19 16:47                     ` Steven Rostedt
2008-08-19 17:34                       ` Mathieu Desnoyers
2008-08-19 21:08                         ` Steven Rostedt
2008-08-20  9:40                           ` Nick Piggin
2008-08-19 21:47                         ` Benjamin Herrenschmidt
2008-08-19 23:58                           ` Jeremy Fitzhardinge
2008-08-20  1:17                             ` Benjamin Herrenschmidt
2008-08-19  2:56                 ` Benjamin Herrenschmidt
2008-08-19  3:12                   ` Steven Rostedt
2008-08-19  4:17                     ` Benjamin Herrenschmidt
2008-08-20  7:18                       ` Benjamin Herrenschmidt
2008-08-20 13:14                         ` Steven Rostedt
2008-08-20 13:19                           ` Steven Rostedt
2008-08-20 13:36                             ` Eran Liberty
2008-08-20 13:43                               ` Steven Rostedt
2008-08-20 14:02                                 ` Eran Liberty
2008-08-20 14:55                                   ` Jon Smirl
2008-08-20 15:23                                     ` Steven Rostedt
2008-08-20 18:23                                     ` Eran Liberty
2008-08-20 18:33                                       ` Steven Rostedt
2008-08-20 15:27                                   ` Steven Rostedt
2008-08-20 21:37                                   ` Benjamin Herrenschmidt
2008-08-20 14:16                           ` Josh Boyer
2008-08-20 14:22                             ` Steven Rostedt
2008-08-20 14:50                               ` Josh Boyer
2008-09-15 16:30                                 ` [PATCH 2.6.26] SERIAL DRIVER: Handle Multiple consecutive sysrq from the serial Eran Liberty
2008-09-17 23:46                                   ` Andrew Morton
2008-09-18  6:58                                     ` Eran Liberty
2008-08-20 21:36                           ` ftrace introduces instability into kernel 2.6.27(-rc2,-rc3) Benjamin Herrenschmidt
2008-08-20 21:44                             ` Steven Rostedt
2008-08-18 18:47         ` Steven Rostedt
2008-08-18 18:56           ` Scott Wood
2008-08-18 19:28             ` Steven Rostedt
2008-08-18 18:25     ` Eran Liberty
2008-08-18 18:41       ` Mathieu Desnoyers
2008-08-19  1:54         ` Benjamin Herrenschmidt
2008-08-19  9:56         ` Eran Liberty
2008-08-19 13:02           ` Mathieu Desnoyers
2008-08-19 21:46             ` Benjamin Herrenschmidt
2008-08-18 18:50       ` Steven Rostedt
2008-08-19 12:09         ` Eran Liberty
2008-08-19 13:05           ` Mathieu Desnoyers
2008-08-19 14:21             ` Eran Liberty
2008-08-19 14:42               ` Mathieu Desnoyers
2008-08-19 20:15           ` Steven Rostedt
2008-08-20 11:18             ` Eran Liberty
2008-08-20 13:12               ` Steven Rostedt
2008-08-19  1:51     ` Benjamin Herrenschmidt

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=20080722114929.GA7337@parisc-linux.org \
    --to=matthew@wil.cx \
    --cc=eran.liberty@gmail.com \
    --cc=jbarnes@virtuousgeek.org \
    --cc=liberty@extricom.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@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).