On Thu, 2013-08-08 at 18:38 +1000, Benjamin Herrenschmidt wrote: > For example the generic irq_chip is orthogonal to irq remapping via > irq_domain. It's possible to instanciate irq_chips without device nodes, > and with a completely different firmware representation (ACPI ?). It > should be the same with msi-chip. In fact, to a large extent, the original irq_domain was also orthogonal to the device-tree ... I did add the ability to match a device-node with an irq domain but that has always been just an optional addition, it was possible (and should still be though I haven't looked in a while) to create irq domains completely independently of the device-tree. Now there is one thing that might sway me ... if you can show me (sorry don't have the bandwidth to look in details and scrutinize the patch) that overall, having the msi_chip in the domain as an optional facility does indeed overall make the code *much* smaller than keeping them separate, and for more than just your use case. One reason I don't like the allocator being in irq domain is that it really only is useful for a subset of the different types of domains around. For example, on power server, I have a unique domain accross the fabric (irqs are special powerbus messages that are encoded in a 24 bit number), but each "source" (a PCI host bridge for example) gets a subset of that domain, typically a fixed range. So your allocator would only be useful to that case if: - It can be used to allocate within specific boundaries - It works with radix based domains This is just an example... I don't like bolting a facility (allocation) in a lawyer originally designed to do something else (mapping) unless that facility is directly useful to the vast majority of the users of the layer in question. In fact, there is an argument to be made to provide a generic bitmap allocator specialized for MSIs. MSIs have quirks ... alignment constraints for multiple MSI-non-X for example, which might potentially benefit in having an allocator with some smarts to limit fragmentation. That sort of things.... Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
