From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg KH Date: Wed, 29 Jun 2005 23:26:33 +0000 Subject: Re: How to find hotplug slot of PCI dev? Message-Id: <20050629232633.GA19189@kroah.com> List-Id: References: <20050629230019.GP28499@austin.ibm.com> In-Reply-To: <20050629230019.GP28499@austin.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Wed, Jun 29, 2005 at 06:00:19PM -0500, Linas Vepstas wrote: > On Wed, Jun 29, 2005 at 03:44:38PM -0700, Greg KH was heard to remark: > > On Wed, Jun 29, 2005 at 05:05:08PM -0500, Linas Vepstas wrote: > > > > > > Hi, > > > > > > I can't think of any easy way of (generically) finding the pointer to > > > struct hotplug_slot if I have a pointer to struct pci_dev in hand. > > > > There is no way, sorry. Remember, multiple pci_dev can point to a > > single hotplug slot. > > Right. I have I pointer to a pci_dev. I want to find the pointer to the > hotplug slot its in. Again, not possible. > > > I am sorely tempted to write a generic patch to > > > drivers/pci/hotplug/pci_hotplug_core.c to add this support > > > (getting it from each of the hotplug arch'es). Should I? > > > If I submit sucha patch, would it get rejected out of hand > > > as a bad idea? > > > > > > I need this for the generic fallback PCI error recovery support; > > > > Why? > > I don't understand the question... > > Because after discussions on the LKML, everyone decided that this > code should be written in as generic a way as possible, rather > than arch-dependent, because there will soon be a variety of PCI > chipsets that will be able to detect PCI errors. True. > > > I have a pointer to the device; if its in a hotplug slot, > > > I want to toggle power to it. > > > > No you do not. That's a userspace policy, not something the kernel > > should do. > > Argh. I thought we've run around the table a few times on this issue > already. It is impossible for userspace to recover from PCI errors. > The canonical example is the failure of a disk system underneath a block > device. Yes, but don't go power-cycling the whole pci slot on me. That's just insane. > All other bus errors are handled in the device drivers; for example, > scsi errors are handled by scsi drivers and/or scsi-generic code. > fiber-channel errors are handled by the fiber channel controllers. > Ethernet hangs are handled by ethernet watchdogs in each ethernet > driver. I think its unrealistic at this point to try to turn PCI > error recovery into a userspace policy. Ok, but again, realize that multiple pci_dev can point to the same pci hotplug slot. Are you going to want to power-cycle all of them (think multi-port ethernet card, multi-controller usb device, multi-device scsi card, etc.) That's just a bad idea. We did go back and forth a few times about this, yes, and I still think that you need to notify userspace that something bad is happening, and let it do the complex stuff if it wants to. And, if you think you can do some simple things in your driver, do that. But please, don't go power-cycling a pci device, that is just mean, and is probably against the PCI hotplug spec also. thanks, greg k-h ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ 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