From: Sinan Kaya <okaya@codeaurora.org>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: linux-pci@vger.kernel.org, timur@codeaurora.org,
linux-kernel@vger.kernel.org, linux-arm-msm@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH V6 2/2] PCI: handle CRS returned by device after FLR
Date: Wed, 2 Aug 2017 14:16:51 -0400 [thread overview]
Message-ID: <563c7f28-851b-b531-34d0-2cee252766d0@codeaurora.org> (raw)
In-Reply-To: <20170802114924.18dd30e2@w520.home>
On 8/2/2017 1:49 PM, Alex Williamson wrote:
> On Wed, 2 Aug 2017 13:18:24 -0400
[snip]
>> static void pci_flr_wait(struct pci_dev *dev)
>> {
>> - int i = 0;
>> + u32 sleep = 1000, total = 0;
>> u32 id;
>> + bool ret;
>>
>> if (dev->is_virtfn) {
>> msleep(100);
>> return;
>> }
>>
>> + /* don't touch the HW before waiting 100ms */
>> + msleep(100);
>> +
>
>
> Wouldn't it be better as:
>
Sure, that looks reasonable.
> msleep(100);
>
> if (dev->is_virtfn)
> return;
>
> Perhaps with a spec reference in a comment why we don't care about
> checking config space for the vf.
The spec reference is in the commit message of
"PCI: limit FLR wait time to 100ms maximum"
where I introduce this check. Do you prefer a reference in the code?
I was under the impression that commit messages are used for these
kind of documentation.
>
>> do {
>> - msleep(100);
>> - pci_read_config_dword(dev, PCI_COMMAND, &id);
>> - } while (i++ < 10 && id == ~0);
>> -
>> - if (id == ~0)
>> - dev_warn(&dev->dev, "Failed to return from FLR\n");
>> - else if (i > 1)
>> - dev_info(&dev->dev, "Required additional %dms to return from FLR\n",
>> - (i - 1) * 100);
>> + ret = pci_bus_read_dev_vendor_id(dev->bus, dev->devfn, &id,
>> + sleep);
>> + if (ret)
>> + break;
>> + total += sleep;
>> + sleep *= 2;
>> + } while (total < 60000 && !ret);
>> +
>> + if (!ret)
>> + dev_warn(&dev->dev, "Failed to return from FLR after %ds\n",
>> + total);
>> + else if (total)
>> + dev_info(&dev->dev, "Required additional %ds to return from FLR\n",
>> + total);
>> }
>
> I'm not a big fan. Nested exponential backoff is pretty nasty. Are
> there users of pci_bus_read_dev_vendor_id() that don't want a "still
> trying" message? It seems better to add that to the function than try
> to wrap this bandage around it. Thanks,
I can work towards that if Bjorn doesn't have any objections.
>
> Alex
>
--
Sinan Kaya
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2017-08-02 18:16 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-02 17:18 [PATCH V6 1/2] PCI: limit FLR wait time to 100ms maximum Sinan Kaya
2017-08-02 17:18 ` [PATCH V6 2/2] PCI: handle CRS returned by device after FLR Sinan Kaya
2017-08-02 17:21 ` Sinan Kaya
2017-08-02 17:49 ` Alex Williamson
2017-08-02 18:16 ` Sinan Kaya [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=563c7f28-851b-b531-34d0-2cee252766d0@codeaurora.org \
--to=okaya@codeaurora.org \
--cc=alex.williamson@redhat.com \
--cc=bhelgaas@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=timur@codeaurora.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).