Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
On Wed, Mar 01, 2017 at 03:37:03PM -0700, Logan Gunthorpe wrote: > On 01/03/17 03:26 PM, Keith Busch wrote: > > I think this is from using the managed device resource API to request the > > irq actions. The scope of the resource used to be tied to the pci_dev's > > dev, but now it's the new switchec class dev, which has a different > > lifetime while open references exist, so it's not releasing the irq's. > > The scope of the IRQ was originally tied to the pci_dev. Then in v4 I > tied it to the switchtec device in order to try and keep using the pci > device after unbind. This didn't work, so I switched it back to using > the pci_dev. (This seems to be the way most drivers work anyway.) Okay, I see. Was mistakenliy looking at v4. The v5 looks right. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 0/4] New Microsemi PCI Switch Management Driver
On Wed, Mar 01, 2017 at 03:41:20PM -0600, Bjorn Helgaas wrote: > On Sat, Feb 25, 2017 at 11:53:13PM -0700, Logan Gunthorpe wrote: > > Changes since v4: > > > > * Turns out pushing the pci release code into the device release > > function didn't work as I would have liked. If you try to unbind the > > device with an instance open, then you hit a kernel bug at > > drivers/pci/msi.c:371. (This didn't occur in v3.) > > This is in free_msi_irqs(): > > 368for_each_pci_msi_entry(entry, dev) > 369if (entry->irq) > 370for (i = 0; i < entry->nvec_used; i++) > 371BUG_ON(irq_has_action(entry->irq + i)); > > I don't think this is indicating a bug in the PCI core (although I do > think a BUG_ON() here is an excessive response). I think it's an > indication that the driver didn't disconnect its ISR. Without more > details of the failure it's hard to tell if the BUG_ON is a symptom of > a problem in the driver or what. > > An "alive" flag feels racy, and I can't tell if it's really the best > way to deal with this, or if it's just avoiding the issue. There must > be other drivers with the same cleanup issue -- do they handle it the > same way? I think this is from using the managed device resource API to request the irq actions. The scope of the resource used to be tied to the pci_dev's dev, but now it's the new switchec class dev, which has a different lifetime while open references exist, so it's not releasing the irq's. One thing about the BUG_ON that is confusing me is how it's getting to free_msi_irq's BUG in v4 or v5. I don't see any part releasing the allocated ones. Maybe the devres API is harder to use than having the driver manage all the resources... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/1] MicroSemi Switchtec management interface driver
On Sat, Dec 17, 2016 at 10:09:22AM -0700, Logan Gunthorpe wrote: > Microsemi's "Switchtec" line of PCI switch devices is already > supported by the kernel with standard PCI switch drivers. However, the > Switchtec device advertises a special management endpoint which > enables some additional functionality. This includes: > > * Packet and Byte Counters > * Firmware Upgrades > * Event and Error logs > * Querying port link status > * Custom user firmware commands > > This patch introduces the switchtec kernel module which provides > pci driver that exposes a char device. The char device provides > userspace access to this interface through read, write and (optionally) > poll calls. Currently no ioctls have been implemented but a couple > may be added in a later revision. > > A short text file is provided which documents the switchtec driver > and outlines the semantics of using the char device. Some of this would be simplified if you use the managed device API's: devm_request_irq, pcim_enable_device, pcim_iomap, etc... -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
