tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: argument of pci_msi[x]_count()



Hi,

On 2015/08/13 6:33, David Young wrote:
> On Thu, Aug 13, 2015 at 06:56:34AM +1000, matthew green wrote:
>>> I don't have a problem with it, I was just questioning the rationale
>>> about passing pci_attach_args to functions...
>>
>> the original pci(9) interfaces didn't do this, but a 3rd member of
>> pci_attach_args{} was needed for a new change, so someone (i forget
>> now, but CVS will tell you) changed it to pass the structure itself,
>> since this was only called during autoconfig when this structure was
>> actually available.
>>
>> doing it outside of autoconfig is not a good idea, though, so any
>> function that is usefully callable outside of attach probably should
>> take specific arguments instead of pci_attach_args{}.
> 
> ISTR a hairy wi(4) bug came about because *_attach_args was passed
> outside attach!  [I may have introduced that bug, too. :-)]
> 
> It sounds to me like the emerging consensus is that it's best to pass
> only the chipset+memory tag, if that's all you need, to each MSI/MSI-X
> function.

I think pci_msi{,x}_alloc() is only called during autoconfig like
pci_intr_map(), so I think they should have pci_attach_args argument.
In implementation side, pci_msix_alloc{,_exact,_map} need
pci_attach_args because they call pci_mapreg_submap().
# pci_mapreg_submap() use pa->pa_flags

In contrast, pci_msi{,x}_count() can be called outside of autoconfig
because they are utility function which simply read pci config space.
In implementation side, they call pci_get_capability() and
pci_conf_read() only. Therefore, I think pci_msi{,x}_count() should
use pci_chipset_tag_t and pcitag_t instead of pci_attach_args.

Why pci_msi{,}_count() use pci_attach_args at present? It is my
mistake, sorry...


Thanks,

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

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

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


Home | Main Index | Thread Index | Old Index