search for: msi_request

...rgument so the driver does not have to worry about it. We can add additional wrappers like that as needed. > >>> What I'd envision as the API from the device driver perspective is something > >>> as simple like this: > >>> > >>> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, > >>> unsigned long flags, const char *name, struct device *dev); > >>> > >>> which would get an msi descriptor that is valid for this device (dev) > >>> connected to a particular msi_chip, and associat...

...devices that works without IRQ numbers. > I don't think we should touch the PCI interfaces at this point. OK, I got it. >>> What I'd envision as the API from the device driver perspective is something >>> as simple like this: >>> >>> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >>> unsigned long flags, const char *name, struct device *dev); >>> >>> which would get an msi descriptor that is valid for this device (dev) >>> connected to a particular msi_chip, and associate a handler function...

...devices that works without IRQ numbers. > I don't think we should touch the PCI interfaces at this point. OK, I got it. >>> What I'd envision as the API from the device driver perspective is something >>> as simple like this: >>> >>> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >>> unsigned long flags, const char *name, struct device *dev); >>> >>> which would get an msi descriptor that is valid for this device (dev) >>> connected to a particular msi_chip, and associate a handler function...

...But msi_write_message() maybe necessary, some xxx_set_affinity() functions and restore functions need the msi_write_message() to rewrite the address and data. > What I'd envision as the API from the device driver perspective is something > as simple like this: > > struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, > unsigned long flags, const char *name, struct device *dev); > > which would get an msi descriptor that is valid for this device (dev) > connected to a particular msi_chip, and associate a handler function > with it. The device drive...

...But msi_write_message() maybe necessary, some xxx_set_affinity() functions and restore functions need the msi_write_message() to rewrite the address and data. > What I'd envision as the API from the device driver perspective is something > as simple like this: > > struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, > unsigned long flags, const char *name, struct device *dev); > > which would get an msi descriptor that is valid for this device (dev) > connected to a particular msi_chip, and associate a handler function > with it. The device drive...

...he first argument for convenience and consistency. I don't think you actually need msi_read_message(), and we could avoid msi_write_message() by doing it the other way round. What I'd envision as the API from the device driver perspective is something as simple like this: struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, unsigned long flags, const char *name, struct device *dev); which would get an msi descriptor that is valid for this device (dev) connected to a particular msi_chip, and associate a handler function with it. The device driver can call that function...

...e the address and data. Makes sense. I'd have to think about it more, but I think you are right about the affinity APIs needing this. > > What I'd envision as the API from the device driver perspective is something > > as simple like this: > > > > struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, > > unsigned long flags, const char *name, struct device *dev); > > > > which would get an msi descriptor that is valid for this device (dev) > > connected to a particular msi_chip, and associate a handler function > >...

...x_set_affinity() functions and >> restore functions need the msi_write_message() to rewrite the address and data. >> >>> What I'd envision as the API from the device driver perspective is something >>> as simple like this: >>> >>> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >>> unsigned long flags, const char *name, struct device *dev); >>> >>> which would get an msi descriptor that is valid for this device (dev) >>> connected to a particular msi_chip, and associate a handler function...

...aybe necessary, some xxx_set_affinity() functions and > restore functions need the msi_write_message() to rewrite the address and data. > >> What I'd envision as the API from the device driver perspective is something >> as simple like this: >> >> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >> unsigned long flags, const char *name, struct device *dev); >> >> which would get an msi descriptor that is valid for this device (dev) >> connected to a particular msi_chip, and associate a handler function >> with i...

...aybe necessary, some xxx_set_affinity() functions and > restore functions need the msi_write_message() to rewrite the address and data. > >> What I'd envision as the API from the device driver perspective is something >> as simple like this: >> >> struct msi_desc *msi_request(struct msi_chip *chip, irq_handler_t handler, >> unsigned long flags, const char *name, struct device *dev); >> >> which would get an msi descriptor that is valid for this device (dev) >> connected to a particular msi_chip, and associate a handler function >> with i...

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