Bjorn Helgaas wrote:
> On Wednesday 22 October 2008 08:44:24 am Yu Zhao wrote:
>> Bjorn Helgaas wrote:
>>> On Wednesday 22 October 2008 02:40:41 am Yu Zhao wrote:
>>>> This patch moves all definitions of the PCI resource names to an 'enum',
>>>> and also replaces some hard-coded resource variables with symbol
>>>> names. This change eases introduction of device specific resources.
>>> Thanks for removing a bunch of magic numbers from the code.
>>>
>>>>  static void
>>>>  pci_restore_bars(struct pci_dev *dev)
>>>>  {
>>>> -  int i, numres;
>>>> -
>>>> -  switch (dev->hdr_type) {
>>>> -  case PCI_HEADER_TYPE_NORMAL:
>>>> -          numres = 6;
>>>> -          break;
>>>> -  case PCI_HEADER_TYPE_BRIDGE:
>>>> -          numres = 2;
>>>> -          break;
>>>> -  case PCI_HEADER_TYPE_CARDBUS:
>>>> -          numres = 1;
>>>> -          break;
>>>> -  default:
>>>> -          /* Should never get here, but just in case... */
>>>> -          return;
>>>> -  }
>>>> +  int i;
>>>>  
>>>> -  for (i = 0; i < numres; i++)
>>>> +  for (i = 0; i < PCI_BRIDGE_RESOURCES; i++)
>>>>            pci_update_resource(dev, i);
>>>>  }
>>> The behavior of this function used to depend on dev->hdr_type.  Now
>>> we don't look at hdr_type at all, so we do the same thing for all
>>> devices.
>>>
>>> For example, for a CardBus device, we used to call pci_update_resource()
>>> only for BAR 0; now we call it for BARs 0-6.
>>>
>>> Maybe this is safe, but I can't tell from the patch, so I think you
>>> should explain *why* it's safe in the changelog.
>> It's safe because pci_update_resource() will ignore unused resources. 
>> E.g., for a Cardbus, only BAR 0 is used and its 'flags' is set, then 
>> pci_update_resource() only updates it. BAR 1-6 are ignored since their 
>> 'flags' are 0.
>>
>> I'll put more explanation in the changelog.
> 
> This is a logically separate change from merely substituting enum
> names for magic numbers, so you might even consider splitting it
> into a separate patch.  Better bisection and all that, you know :-)

Will do.

Thanks,
Yu
_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/virtualization

Reply via email to