search for: isr_on

...l. On a PIC-class platform we can probably consider it to be a design flaw if the programmer doesn't know whether a function pointer will be dereferenced from interrupt context or not. This suggests that for any function whose address is taken, there could be a required annotation such as ISR_ONLY or NONISR_ONLY. The compiler could use this to do the right thing without any heroic static analysis or dynamic binding. John

...obably consider it to be a design > flaw if > the programmer doesn't know whether a function pointer will be > dereferenced from interrupt context or not. This suggests that for > any > function whose address is taken, there could be a required > annotation such > as ISR_ONLY or NONISR_ONLY. The compiler could use this to do the > right > thing without any heroic static analysis or dynamic binding. > That could work as well; however, for the PIC16, I'd still be tempted to go with a descriptor table for function pointers. Otherwise, a function poin...

...- dev->msi_enabled ? "MSI" : "", > - dev->msix_enabled ? "MSI/X" : "", > + pci_dev_msi_enabled(dev, MSI_TYPE) ? "MSI" : "", > + pci_dev_msi_enabled(dev, MSIX_TYPE) ? "MSI/X" : "", > dev_data->isr_on ? "enable" : "disable", > enable ? "enable" : "disable"); > > @@ -90,8 +90,8 @@ out: > dev_data->irq_name, > dev_data->irq, > pci_is_enabled(dev) ? "on" : "off", > - dev->msi_enabled ? "MSI&...

...- dev->msi_enabled ? "MSI" : "", > - dev->msix_enabled ? "MSI/X" : "", > + pci_dev_msi_enabled(dev, MSI_TYPE) ? "MSI" : "", > + pci_dev_msi_enabled(dev, MSIX_TYPE) ? "MSI/X" : "", > dev_data->isr_on ? "enable" : "disable", > enable ? "enable" : "disable"); > > @@ -90,8 +90,8 @@ out: > dev_data->irq_name, > dev_data->irq, > pci_is_enabled(dev) ? "on" : "off", > - dev->msi_enabled ? "MSI&...

...: "off", - dev->msi_enabled ? "MSI" : "", - dev->msix_enabled ? "MSI/X" : "", + pci_dev_msi_enabled(dev, MSI_TYPE) ? "MSI" : "", + pci_dev_msi_enabled(dev, MSIX_TYPE) ? "MSI/X" : "", dev_data->isr_on ? "enable" : "disable", enable ? "enable" : "disable"); @@ -90,8 +90,8 @@ out: dev_data->irq_name, dev_data->irq, pci_is_enabled(dev) ? "on" : "off", - dev->msi_enabled ? "MSI" : "", - dev->m...

...sdev) + if (!psdev) { + err = -ENOENT; goto out; + } dev_data = pci_get_drvdata(psdev->dev); - if (!dev_data) + if (!dev_data) { + err = -ENOENT; goto out; + } dev_dbg(&psdev->dev->dev, "%s fake irq handler: %d->%d\n", dev_data->irq_name, dev_data->isr_on,

...sdev) + if (!psdev) { + err = -ENOENT; goto out; + } dev_data = pci_get_drvdata(psdev->dev); - if (!dev_data) + if (!dev_data) { + err = -ENOENT; goto out; + } dev_dbg(&psdev->dev->dev, "%s fake irq handler: %d->%d\n", dev_data->irq_name, dev_data->isr_on,

Hi Ali, Thanks for bringing this up. You're definitely under very tight design constraints from the hardware. I can certainly sympathize. I think two design elements are being conflated here, and it would be worthwhile splitting them out. For correctness, you need to make sure any routines called from an ISR don't clobber equivalent routines called from mainline code. For

Up front I apologize for the lengthy email. Since our patch was not accepted, Chris asked us to follow up with this issue on llvm-dev. For the sake of completeness, let me give a bit of background and the problems that we are facing. I tried to capture as much as possible here so Please do give us feedback. Don't take your stack for granted.... PIC16 has very poor pointer handling, hence

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use

Hi all, The series is a draft of generic MSI driver that supports PCI and Non-PCI device which have MSI capability. If you're not interested it, sorry for the noise. The series is based on Linux-3.16-rc1. MSI was introduced in PCI Spec 2.2. Currently, kernel MSI driver codes are bonding with PCI device. Because MSI has a lot advantages in design. More and more non-PCI devices want to use