On 10/07/18 01:19 PM, Alex Williamson wrote:
> Note that these devices don't have an ACS capability, so they should
> drop out just as any other device without an ACS capability would.
> Should pci_disable_acs_redir() perhaps issue the pci_warn() for all
> such devices, removing this device specific disable function?
Ok, that sounds like a good idea.
> Kind of cumbersome, and as above, maybe the reverse path is optional.
> I wonder if there's a better callback we should use or if we should not
> rely on quirks providing both.
Well, keep in mind enable_acs() and disable_acs_redir() are not inverse
operations. The disable function is only disabling specific ACS bits to
enable redirect -- which are not the same bits being set by the enable
function.
>> { 0 }
>> };
>>
>> int pci_dev_specific_enable_acs(struct pci_dev *dev)
>> {
>> - const struct pci_dev_enable_acs *i;
>> + const struct pci_dev_acs_ops *i;
>> int ret;
>>
>> - for (i = pci_dev_enable_acs; i->enable_acs; i++) {
>> + for (i = pci_dev_acs_ops; i->enable_acs; i++) {
>
> Perhaps this would walk via ARRAY_SIZE if we decide one or the other
> callback is optional.
> Test i->disable_acs_redir?
Yes, both points make sense if we start saying the operations are optional.
> static inline version for !CONFIG_PCI_QUIRKS? Thanks,
Oops, yes, I forgot that.
Logan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
