Re: change MSI/MSI-X APIs

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

Hi,

On 2015/05/13 1:40, Terry Moore wrote:
>> From: tech-kern-owner%NetBSD.org@localhost [mailto:tech-kern-owner%NetBSD.org@localhost] On
>> Behalf Of Kengo NAKAHARA
>> On 2015/05/11 23:18, Christos Zoulas wrote:
>>> Can't we have a:
>>>
>>> 	int pci_intr_map(struct pci_attach_args *pa, pci_intr_handle_t *ih);
>>>
>>> for the drivers that have only one interrupt, and:
>>>
>>> 	int pci_intr_vector_map(struct pci_attach_args *pa,
>>> 	    pci_intr_handle_t **ihp, size_t *nih);
>>>
>>> for drivers that can handle more than one?
>>
>> Because some device drivers must select INTx, MSI, or MSI-X depending
>> on using devices; e.g. some devices have errata about MSI-X,
>> so the device driver cannot use MSI-X even if the devices have
>> MSI-X capability. In addition, some other the device drivers should
>> use MSI-X and INTx only since some devices have errata about MSI.
>> In a similar way, other device drivers should use MSI-X and MSI only.
>>
>> These selection logic codes can be done only in the device drivers
>> codes, therefore it is required for the device drivers to be able to
>> select interrupt types by allocation APIs.
> 
> I completely understand that *some* devices have this problem. But many
> devices do not. It seems that the current API penalizes drivers for devices
> that are done correctly. Would it not make more sense to make drivers more
> complex only for devices that require the complexity?
> 
> One way to handle this without multiplying APIs unnecessarily is to have a
> flags argument to pci_intr_map() and pci_intr_vector_map() that allows the
> driver to restrict the mapping. The driver for the broken case would have to
> fill out more of the interrupt structure, but the simple driver could be
> simple.
> 
> I'm sure there are even better ways to handle this variation; just making a
> concrete example of how it might be done.

What do you think about below pci_intr_alloc() API?
    http://mail-index.netbsd.org/tech-kern/2015/05/18/msg018725.html

I think this API simplify for many device drivers to use, however I am
unsure this API meets your pointing out.
Could you comment?


Thanks,

-- 
//////////////////////////////////////////////////////////////////////
Internet Initiative Japan Inc.

Device Engineering Section,
Core Product Development Department,
Product Division,
Technology Unit

Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>