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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to