linux-kernel - [PATCH v5 00/13] PCI core learns hotplug

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 20 Mar 2009 14:55:50 -0600
From:	Alex Chiang <achiang@...com>
To:	jbarnes@...tuousgeek.org
Cc:	achiang@...com, kaneshige.kenji@...fujitsu.com,
	xyzzy@...akeasy.org, linux-pci@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: [PATCH v5 00/13] PCI core learns hotplug

Here is v5 of this series that addresses the review comments from v4.

I've pushed out a new test tree that contains the updated series for
testing. The tree consists of:

	Linus's v2.6.28
	+ Jesse's linux-next queue (as of 19 March 2009)
	+ the 13 patches in this series

It does not contain the sysfs callback patch that is required for
interface torture tests. That can be had here:

	http://thread.gmane.org/gmane.linux.kernel/806648

You can pull my tree here:

  git://git.kernel.org/pub/scm/linux/kernel/git/achiang/pci-hotplug.git test-20090319

This is also a nice chance to test the shiny new patchwork instance
that we have running on kernel.org that we hope to use for linux-pci
in the future:

	http://patchwork.kernel.org/project/linux-pci/list/

I still haven't figured out the locking issue that Kenji-san pointed
out from last time, because I haven't been able to reproduce it.

Any further testing/review is welcomed and appreciated.

Thanks!

/ac

v4 -> v5:
	- acquire pci_bus_sem when walking device list in pci_rescan_bus
	- keep CONFIG_HOTPLUG (instead of CONFIG_HOTPLUG_PCI)
	- comment why we need device_schedule_callback()
	- remove CAP_SYS_ADMIN check
	- do not remove primary bus in remove_callback()
	- do not enable bridges multiple times
	- checkpatch cleanups

v3 -> v4:
	- protect sysfs interfaces with mutex
	- undo changes in pci_do_scan_bus
	- introduce pci_rescan_bus instead
	- do not initialize bridges more than once

v2 -> v3:
	- properly remove device with internal bridge
	- added Kenji Kaneshige's pci_is_root_bus() interface
	- dropped whitespace cleanups for another time

v1 -> v2:
	- incorporated lots of Trent Piepho's work
	- beefed up pci_do_scan_bus as heavy lifter for rescanning
	- small bugfixes folded into earlier patches to get everything working

---

Alex Chiang (9):
      PCI Hotplug: schedule fakephp for feature removal
      PCI Hotplug: rename legacy_fakephp to fakephp
      PCI: Introduce /sys/bus/pci/devices/.../rescan
      PCI: Introduce /sys/bus/pci/devices/.../remove
      PCI: Introduce /sys/bus/pci/rescan
      PCI: Introduce pci_rescan_bus()
      PCI: do not enable bridges more than once
      PCI: do not initialize bridges more than once
      PCI: always scan child buses

Kenji Kaneshige (1):
      PCI: pci_is_root_bus helper

Trent Piepho (3):
      PCI Hotplug: restore fakephp interface with complete reimplementation
      PCI: pci_scan_slot() returns newly found devices
      PCI: don't scan existing devices


 Documentation/ABI/testing/sysfs-bus-pci    |   27 ++
 Documentation/feature-removal-schedule.txt |   33 ++
 Documentation/filesystems/sysfs-pci.txt    |   10 +
 drivers/pci/bus.c                          |    6 
 drivers/pci/hotplug/fakephp.c              |  443 +++++++---------------------
 drivers/pci/pci-driver.c                   |    1 
 drivers/pci/pci-sysfs.c                    |   81 +++++
 drivers/pci/pci.h                          |    6 
 drivers/pci/probe.c                        |  112 +++++--
 drivers/pci/setup-bus.c                    |    3 
 include/linux/pci.h                        |   12 +
 11 files changed, 356 insertions(+), 378 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/