[PATCH 2/4] PCI: add functionality for resizing resources v2

Christian König deathsimple at vodafone.de
Tue Apr 11 09:14:29 UTC 2017


Sorry for the delayed response, have been busy with other stuff recently.

Am 13.03.2017 um 17:43 schrieb Andy Shevchenko:
>> v2: rebase on changes in rbar support
> This kind of comments usually goes after --- delimiter below.

That would remove it from the commit message which I don't want.


>> +       unsigned i;
>> +       int ret = 0;
>> +
>> +       /* Release all children from the matching bridge resource */
>> +       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))
> IIUC it would be
> if ((res->flags ^ type) & type_mask)
>
> (I consider 'diff' as XOR operation is more understandable, but it's up to you)

I think like it is is easier to read.


>> +               res->start = saved.start;
>> +               res->end = saved.end;
>> +               res->flags = saved.flags;
> Would
>   *res = saved;
> work?

No, res also contains a bunch of pointers into the tree which we should 
not override.

>> +int pci_resize_resource(struct pci_dev *dev, int resno, int size)
>> +{
>> +       struct resource *res = dev->resource + resno;
>> +       u32 sizes = pci_rbar_get_possible_sizes(dev, resno);
>> +       int old = pci_rbar_get_current_size(dev, resno);
>> +       u64 bytes = 1ULL << (size + 20);
>> +       int ret = 0;
>> +
> I would put
>   sizes = pci_rbar_get_possible_sizes(dev, resno);
> here

Good idea, done.


>> +       if (!sizes)
>> +               return -ENOTSUPP;
>> +
>> +       if (!(sizes & (1 << size)))
> BIT(size) ?

Done.

> and
>   old = pci_rbar_get_current_size(dev, resno);
> here

Good idea as well.

>> +error_resize:
>> +       pci_rbar_set_size(dev, resno, old);
>> +       res->end = res->start + (1ULL << (old + 20)) - 1;
> BIT_ULL(old + 20) ?

Nope, that is actually a size in bytes. Not a bitfield. So while BIT_ULL 
yields the right result it would be harder to understand.

Christian.



More information about the amd-gfx mailing list