Re: [PATCH 2/16 v6] PCI: define PCI resource names in an 'enum'

[Yu Zhao]

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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/