qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 1/3] pci: move check for existing devfn into new


From: Mark Cave-Ayland
Subject: Re: [Qemu-devel] [PATCH 1/3] pci: move check for existing devfn into new pci_bus_devfn_available() helper
Date: Mon, 10 Jul 2017 13:44:53 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0

On 10/07/17 08:24, Marcel Apfelbaum wrote:

> On 07/07/2017 10:44, Mark Cave-Ayland wrote:
>> Also touch up the logic in do_pci_register_device() accordingly.
>>
>> Signed-off-by: Mark Cave-Ayland <address@hidden>
>> ---
>>   hw/pci/pci.c |   14 ++++++++++++--
>>   1 file changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/hw/pci/pci.c b/hw/pci/pci.c
>> index 0c6f74a..04e6edb 100644
>> --- a/hw/pci/pci.c
>> +++ b/hw/pci/pci.c
>> @@ -951,6 +951,15 @@ uint16_t pci_requester_id(PCIDevice *dev)
>>       return pci_req_id_cache_extract(&dev->requester_id_cache);
>>   }
>>
> 
> 
> Hi Mark,
> 
>> +static bool pci_bus_devfn_available(PCIBus *bus, int devfn)
>> +{
>> +    if (bus->devices[devfn]) {
>> +        return false;
>> +    } else {
>> +        return true;
>> +    }
>> +}
>> +
> The function may simply return bus->devices[devfn], right?
> (the return type should take care of the rest)
> 
> 
> 
>>   /* -1 for devfn means auto assign */
>>   static PCIDevice *do_pci_register_device(PCIDevice *pci_dev, PCIBus
>> *bus,
>>                                            const char *name, int devfn,
>> @@ -974,14 +983,15 @@ static PCIDevice
>> *do_pci_register_device(PCIDevice *pci_dev, PCIBus *bus,
>>       if (devfn < 0) {
>>           for(devfn = bus->devfn_min ; devfn < ARRAY_SIZE(bus->devices);
>>               devfn += PCI_FUNC_MAX) {
>> -            if (!bus->devices[devfn])
>> +            if (pci_bus_devfn_available(bus, devfn)) {
> 
> I am all for making the code more readable, but in this
> case I am not sure if it worth it. "bus->devices[devfn]"
> is self explanatory, but maybe is a matter of taste.

Yes I agree that on its own it comes across as a more cosmetic patch,
however I felt that it made the final logic in patch 3 much more
readable in terms of determining the behaviour for reserved vs.
unavailable slots.

Does anyone else have any strong opinions?


ATB,

Mark.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]