From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: "Christian König" <deathsimple@vodafone.de>
Cc: helgaas@kernel.org,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
dri-devel@lists.freedesktop.org,
Platform Driver <platform-driver-x86@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/4] PCI: add functionality for resizing resources v3
Date: Wed, 26 Apr 2017 20:00:34 +0300 [thread overview]
Message-ID: <CAHp75VfSFBYgHRsX2JSH0zdSEW8VvXbNMVvBBsD9kKgzGr-v2w@mail.gmail.com> (raw)
In-Reply-To: <1493126394-1239-3-git-send-email-deathsimple@vodafone.de>
On Tue, Apr 25, 2017 at 4:19 PM, Christian König
<deathsimple@vodafone.de> wrote:
> From: Christian König <christian.koenig@amd.com>
>
> This allows device drivers to request resizing their BARs.
>
> The function only tries to reprogram the windows of the bridge directly above
> the requesting device and only the BAR of the same type (usually mem, 64bit,
> prefetchable). This is done to make sure not to disturb other drivers by
> changing the BARs of their devices.
>
> If reprogramming the bridge BAR fails the old status is restored and -ENOSPC
> returned to the calling device driver.
> +int pci_reassign_bridge_resources(struct pci_dev *bridge, unsigned long type)
> +{
> + const unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
> + IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
> +
Redundant.
> + struct pci_dev_resource *dev_res;
> + LIST_HEAD(saved);
> + LIST_HEAD(added);
> + LIST_HEAD(failed);
> + unsigned i;
unsigned int i;
> + int ret = 0;
> +
> + /* Walk to the root BUS, releasing bridge BARs when possible */
> + while (1) {
This raises red flag. Care to refactor?
Also do {} while () syntax allows faster to get that the loop body
goes at least once.
> + for (i = PCI_BRIDGE_RESOURCES; i < PCI_BRIDGE_RESOURCE_END;
> + i++) {
> + struct resource *res = &bridge->resource[i];
> +
> + if ((res->flags & type_mask) != (type & type_mask))
I would rather go with
if ((res->flags ^ type) & type_mask)
> + continue;
> +
> + /* Ignore BARs which are still in use */
> + if (res->child)
> + continue;
> +
> + ret = add_to_list(&saved, bridge, res, 0, 0);
> + if (ret)
> + goto cleanup;
> +
> + if (res->parent)
> + release_resource(res);
> + res->start = 0;
> + res->end = 0;
> + dev_info(&bridge->dev, "BAR %d: released %pR\n",
> + i, res);
I doesn't make much sense to me after zeroing a range.
> + break;
> + }
> + if (i == PCI_BRIDGE_RESOURCE_END)
> + break;
> +
> + if (!bridge->bus || !bridge->bus->self)
> + break;
> +
> + bridge = bridge->bus->self;
> + }
> +
> + if (list_empty(&saved))
> + return -ENOENT;
> +
> + __pci_bus_size_bridges(bridge->subordinate, &added);
> + __pci_bridge_assign_resources(bridge, &added, &failed);
> + BUG_ON(!list_empty(&added));
> +
> + if (!list_empty(&failed)) {
> + ret = -ENOSPC;
> + goto cleanup;
> + }
> +
> +
Remove extra empty line.
> + list_for_each_entry(dev_res, &saved, list) {
> + /* Skip the bridge we just assigned resources for. */
> + if (bridge == dev_res->dev)
> + continue;
> +
> + bridge = dev_res->dev;
> + pci_setup_bridge(bridge->subordinate);
> + }
> +
> + free_list(&saved);
> + free_list(&failed);
> + return ret;
You might re-use two lines with below, but perhaps better to show
which case returns 0 explicitly and drop assignment ret = 0 above.
> +
> +cleanup:
> + /* restore size and flags */
> + list_for_each_entry(dev_res, &failed, list) {
> + struct resource *res = dev_res->res;
> +
> + res->start = dev_res->start;
> + res->end = dev_res->end;
> + res->flags = dev_res->flags;
> + }
> + free_list(&failed);
> +
> + /* Revert to the old configuration */
> + list_for_each_entry(dev_res, &saved, list) {
> + struct resource *res = dev_res->res;
> +
> + bridge = dev_res->dev;
> + i = res - bridge->resource;
> +
> + res->start = dev_res->start;
> + res->end = dev_res->end;
> + res->flags = dev_res->flags;
> +
> + pci_claim_resource(bridge, i);
> + pci_setup_bridge(bridge->subordinate);
> + }
> + free_list(&saved);
> +
> + return ret;
> +}
> +void pci_release_resource(struct pci_dev *dev, int resno)
> +{
> + struct resource *res = dev->resource + resno;
> +
> + release_resource(res);
> + res->end = resource_size(res) - 1;
> + res->start = 0;
> + res->flags |= IORESOURCE_UNSET;
> + dev_info(&dev->dev, "BAR %d: released %pR\n", resno, res);
Makes little sense to me after you cleared information out.
> +}
> +EXPORT_SYMBOL(pci_release_resource);
> +
> +int pci_resize_resource(struct pci_dev *dev, int resno, int size)
> +{
> + struct resource *res = dev->resource + resno;
> + u64 bytes = 1ULL << (size + 20);
> + res->end = res->start + (1ULL << (old + 20)) - 1;
Perhaps macro or helper?
static inline u64 rbar_size_to_bytes(size)
{
return 1ULL << (size + 20);
}
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2017-04-26 17:00 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-25 13:19 Resizeable PCI BAR support V4 Christian König
2017-04-25 13:19 ` [PATCH 1/4] PCI: add resizeable BAR infrastructure v4 Christian König
2017-04-25 15:00 ` Alex Deucher
2017-04-26 16:45 ` Andy Shevchenko
2017-05-02 14:56 ` Christian König
2017-04-25 13:19 ` [PATCH 2/4] PCI: add functionality for resizing resources v3 Christian König
2017-04-26 17:00 ` Andy Shevchenko [this message]
2017-05-02 15:51 ` Christian König
2017-05-02 20:27 ` Andy Shevchenko
2017-05-04 9:23 ` Christian König
2017-05-04 10:15 ` Andy Shevchenko
2017-05-04 16:44 ` Andy Shevchenko
2017-04-25 13:19 ` [PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v2 Christian König
2017-04-25 15:00 ` Alex Deucher
2017-04-26 17:18 ` Andy Shevchenko
2017-04-25 13:19 ` [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access v2 Christian König
2017-04-25 14:34 ` Alex Deucher
2017-04-25 15:09 ` Christian König
2017-04-25 15:14 ` Alex Deucher
2017-04-25 16:22 ` Christian König
2017-04-25 16:29 ` Alex Deucher
2017-04-25 14:25 ` Resizeable PCI BAR support V4 Andy Shevchenko
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=CAHp75VfSFBYgHRsX2JSH0zdSEW8VvXbNMVvBBsD9kKgzGr-v2w@mail.gmail.com \
--to=andy.shevchenko@gmail.com \
--cc=deathsimple@vodafone.de \
--cc=dri-devel@lists.freedesktop.org \
--cc=helgaas@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=platform-driver-x86@vger.kernel.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).