lkml.org 
[lkml]   [2018]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v5 3/3] PCI: Introduce the disable_acs_redir parameter


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

\
 
 \ /
  Last update: 2018-07-10 21:28    [W:0.053 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site