On Sun, Oct 16, 2011 at 04:35:11PM -0700, Yinghai Lu wrote:
> On 10/16/2011 08:55 AM, Greg KH wrote:
>
> > On Sat, Oct 15, 2011 at 10:34:03PM -0700, Yinghai Lu wrote:
> >> On 10/15/2011 07:39 PM, Greg KH wrote:
> >>
> >>>
> >>> No, we already have a way to do this, this is not acceptable, sorry.
> >>>
> >>
> >>
> >> hope this one is ok...
> >
> > Nope, not at all, don't use #ifdef in .c files.
> >
> > Again, we have a way to do this, built into sysfs, that can dynamically
> > know to add or not add, attributes when they are registered with the
> > system.
>
> thank you for the comments.
>
> i got it. now introduce device type for pci dev.
>
> please check if this one is what you want.
>
> [PATCH -v3 8/8] PCI, sys: only create rescan under /sys/.../pci/devices/... for pci bridges
>
> Current code will create rescan for every pci device,
> that is not right. the device is already there, there is no reason to rescan it.
>
> So only have rescan for pci bridges. less confusing
>
> Also the rescan will rescan bridge's secondary bus instead of primary bus.
>
> -v3: Use device_type for pci dev.
>
> Signed-off-by: Yinghai Lu <yinghai@xxxxxxxxxx>
>
> ---
> drivers/pci/pci-sysfs.c | 39 +++++++++++++++++++++++++++++++++++++--
> drivers/pci/pci.h | 1 +
> drivers/pci/probe.c | 1 +
> 3 files changed, 39 insertions(+), 2 deletions(-)
>
> Index: linux-2.6/drivers/pci/pci-sysfs.c
> ===================================================================
> --- linux-2.6.orig/drivers/pci/pci-sysfs.c
> +++ linux-2.6/drivers/pci/pci-sysfs.c
> @@ -303,12 +303,15 @@ dev_rescan_store(struct device *dev, str
>
> if (val) {
> mutex_lock(&pci_remove_rescan_mutex);
> - pci_rescan_bus(pdev->bus);
> + pci_rescan_bus(pdev->subordinate);
> mutex_unlock(&pci_remove_rescan_mutex);
> }
> return count;
> }
This chunk is separate from the rest of the patch, right?
Please split this up into doing one thing per patch please.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-pci" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
