Commit 6fd03301 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6 

* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core-2.6: (64 commits)
  debugfs: use specified mode to possibly mark files read/write only
  debugfs: Fix terminology inconsistency of dir name to mount debugfs filesystem.
  xen: remove driver_data direct access of struct device from more drivers
  usb: gadget: at91_udc: remove driver_data direct access of struct device
  uml: remove driver_data direct access of struct device
  block/ps3: remove driver_data direct access of struct device
  s390: remove driver_data direct access of struct device
  parport: remove driver_data direct access of struct device
  parisc: remove driver_data direct access of struct device
  of_serial: remove driver_data direct access of struct device
  mips: remove driver_data direct access of struct device
  ipmi: remove driver_data direct access of struct device
  infiniband: ehca: remove driver_data direct access of struct device
  ibmvscsi: gadget: at91_udc: remove driver_data direct access of struct device
  hvcs: remove driver_data direct access of struct device
  xen block: remove driver_data direct access of struct device
  thermal: remove driver_data direct access of struct device
  scsi: remove driver_data direct access of struct device
  pcmcia: remove driver_data direct access of struct device
  PCIE: remove driver_data direct access of struct device
  ...

Manually fix up trivial conflicts due to different direct driver_data
direct access fixups in drivers/block/{ps3disk.c,ps3vram.c}
parents cd5232bd e4792aa3

Documentation/DocBook/debugobjects.tmpl

+1 −1
Original line number Diff line number Diff line
@@ -106,7 +106,7 @@ 
      number of errors are printk'ed including a full stack trace.

    </para>

    <para>

      The statistics are available via debugfs/debug_objects/stats.

      The statistics are available via /sys/kernel/debug/debug_objects/stats.

      They provide information about the number of warnings and the

      number of successful fixups along with information about the

      usage of the internal tracking objects and the state of the

Documentation/cdrom/packet-writing.txt

+1 −1
Original line number Diff line number Diff line
@@ -117,7 +117,7 @@ Using the pktcdvd debugfs interface 


To read pktcdvd device infos in human readable form, do:



	# cat /debug/pktcdvd/pktcdvd[0-7]/info

	# cat /sys/kernel/debug/pktcdvd/pktcdvd[0-7]/info



For a description of the debugfs interface look into the file:

Documentation/driver-model/device.txt

+32 −0
Original line number Diff line number Diff line
@@ -162,3 +162,35 @@ device_remove_file(dev,&dev_attr_power); 


The file name will be 'power' with a mode of 0644 (-rw-r--r--).



Word of warning:  While the kernel allows device_create_file() and

device_remove_file() to be called on a device at any time, userspace has

strict expectations on when attributes get created.  When a new device is

registered in the kernel, a uevent is generated to notify userspace (like

udev) that a new device is available.  If attributes are added after the

device is registered, then userspace won't get notified and userspace will

not know about the new attributes.



This is important for device driver that need to publish additional

attributes for a device at driver probe time.  If the device driver simply

calls device_create_file() on the device structure passed to it, then

userspace will never be notified of the new attributes.  Instead, it should

probably use class_create() and class->dev_attrs to set up a list of

desired attributes in the modules_init function, and then in the .probe()

hook, and then use device_create() to create a new device as a child

of the probed device.  The new device will generate a new uevent and

properly advertise the new attributes to userspace.



For example, if a driver wanted to add the following attributes:

struct device_attribute mydriver_attribs[] = {

	__ATTR(port_count, 0444, port_count_show),

	__ATTR(serial_number, 0444, serial_number_show),

	NULL

};



Then in the module init function is would do:

	mydriver_class = class_create(THIS_MODULE, "my_attrs");

	mydriver_class.dev_attr = mydriver_attribs;



And assuming 'dev' is the struct device passed into the probe hook, the driver

probe function would do something like:

	create_device(&mydriver_class, dev, chrdev, &private_data, "my_name");

Documentation/fault-injection/fault-injection.txt

+35 −35
Original line number Diff line number Diff line
@@ -29,16 +29,16 @@ o debugfs entries 
fault-inject-debugfs kernel module provides some debugfs entries for runtime

configuration of fault-injection capabilities.



- /debug/fail*/probability:

- /sys/kernel/debug/fail*/probability:



	likelihood of failure injection, in percent.

	Format: <percent>



	Note that one-failure-per-hundred is a very high error rate

	for some testcases.  Consider setting probability=100 and configure

	/debug/fail*/interval for such testcases.

	/sys/kernel/debug/fail*/interval for such testcases.



- /debug/fail*/interval:

- /sys/kernel/debug/fail*/interval:



	specifies the interval between failures, for calls to

	should_fail() that pass all the other tests.
@@ -46,18 +46,18 @@ configuration of fault-injection capabilities. 
	Note that if you enable this, by setting interval>1, you will

	probably want to set probability=100.



- /debug/fail*/times:

- /sys/kernel/debug/fail*/times:



	specifies how many times failures may happen at most.

	A value of -1 means "no limit".



- /debug/fail*/space:

- /sys/kernel/debug/fail*/space:



	specifies an initial resource "budget", decremented by "size"

	on each call to should_fail(,size).  Failure injection is

	suppressed until "space" reaches zero.



- /debug/fail*/verbose

- /sys/kernel/debug/fail*/verbose



	Format: { 0 | 1 | 2 }

	specifies the verbosity of the messages when failure is
@@ -65,17 +65,17 @@ configuration of fault-injection capabilities. 
	log line per failure; '2' will print a call trace too -- useful

	to debug the problems revealed by fault injection.



- /debug/fail*/task-filter:

- /sys/kernel/debug/fail*/task-filter:



	Format: { 'Y' | 'N' }

	A value of 'N' disables filtering by process (default).

	Any positive value limits failures to only processes indicated by

	/proc/<pid>/make-it-fail==1.



- /debug/fail*/require-start:

- /debug/fail*/require-end:

- /debug/fail*/reject-start:

- /debug/fail*/reject-end:

- /sys/kernel/debug/fail*/require-start:

- /sys/kernel/debug/fail*/require-end:

- /sys/kernel/debug/fail*/reject-start:

- /sys/kernel/debug/fail*/reject-end:



	specifies the range of virtual addresses tested during

	stacktrace walking.  Failure is injected only if some caller
@@ -84,26 +84,26 @@ configuration of fault-injection capabilities. 
	Default required range is [0,ULONG_MAX) (whole of virtual address space).

	Default rejected range is [0,0).



- /debug/fail*/stacktrace-depth:

- /sys/kernel/debug/fail*/stacktrace-depth:



	specifies the maximum stacktrace depth walked during search

	for a caller within [require-start,require-end) OR

	[reject-start,reject-end).



- /debug/fail_page_alloc/ignore-gfp-highmem:

- /sys/kernel/debug/fail_page_alloc/ignore-gfp-highmem:



	Format: { 'Y' | 'N' }

	default is 'N', setting it to 'Y' won't inject failures into

	highmem/user allocations.



- /debug/failslab/ignore-gfp-wait:

- /debug/fail_page_alloc/ignore-gfp-wait:

- /sys/kernel/debug/failslab/ignore-gfp-wait:

- /sys/kernel/debug/fail_page_alloc/ignore-gfp-wait:



	Format: { 'Y' | 'N' }

	default is 'N', setting it to 'Y' will inject failures

	only into non-sleep allocations (GFP_ATOMIC allocations).



- /debug/fail_page_alloc/min-order:

- /sys/kernel/debug/fail_page_alloc/min-order:



	specifies the minimum page allocation order to be injected

	failures.
@@ -166,13 +166,13 @@ o Inject slab allocation failures into module init/exit code 
#!/bin/bash



FAILTYPE=failslab

echo Y > /debug/$FAILTYPE/task-filter

echo 10 > /debug/$FAILTYPE/probability

echo 100 > /debug/$FAILTYPE/interval

echo -1 > /debug/$FAILTYPE/times

echo 0 > /debug/$FAILTYPE/space

echo 2 > /debug/$FAILTYPE/verbose

echo 1 > /debug/$FAILTYPE/ignore-gfp-wait

echo Y > /sys/kernel/debug/$FAILTYPE/task-filter

echo 10 > /sys/kernel/debug/$FAILTYPE/probability

echo 100 > /sys/kernel/debug/$FAILTYPE/interval

echo -1 > /sys/kernel/debug/$FAILTYPE/times

echo 0 > /sys/kernel/debug/$FAILTYPE/space

echo 2 > /sys/kernel/debug/$FAILTYPE/verbose

echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait



faulty_system()

{
@@ -217,20 +217,20 @@ then 
	exit 1

fi



cat /sys/module/$module/sections/.text > /debug/$FAILTYPE/require-start

cat /sys/module/$module/sections/.data > /debug/$FAILTYPE/require-end

cat /sys/module/$module/sections/.text > /sys/kernel/debug/$FAILTYPE/require-start

cat /sys/module/$module/sections/.data > /sys/kernel/debug/$FAILTYPE/require-end



echo N > /debug/$FAILTYPE/task-filter

echo 10 > /debug/$FAILTYPE/probability

echo 100 > /debug/$FAILTYPE/interval

echo -1 > /debug/$FAILTYPE/times

echo 0 > /debug/$FAILTYPE/space

echo 2 > /debug/$FAILTYPE/verbose

echo 1 > /debug/$FAILTYPE/ignore-gfp-wait

echo 1 > /debug/$FAILTYPE/ignore-gfp-highmem

echo 10 > /debug/$FAILTYPE/stacktrace-depth

echo N > /sys/kernel/debug/$FAILTYPE/task-filter

echo 10 > /sys/kernel/debug/$FAILTYPE/probability

echo 100 > /sys/kernel/debug/$FAILTYPE/interval

echo -1 > /sys/kernel/debug/$FAILTYPE/times

echo 0 > /sys/kernel/debug/$FAILTYPE/space

echo 2 > /sys/kernel/debug/$FAILTYPE/verbose

echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-wait

echo 1 > /sys/kernel/debug/$FAILTYPE/ignore-gfp-highmem

echo 10 > /sys/kernel/debug/$FAILTYPE/stacktrace-depth



trap "echo 0 > /debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT

trap "echo 0 > /sys/kernel/debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT



echo "Injecting errors into the module $module... (interrupt to stop)"

sleep 1000000

Documentation/firmware_class/README

+2 −1
Original line number Diff line number Diff line
@@ -77,7 +77,8 @@ 
   seconds for the whole load operation.



 - request_firmware_nowait() is also provided for convenience in

   non-user contexts.

   user contexts to request firmware asynchronously, but can't be called

   in atomic contexts.





 about in-kernel persistence:

CRA Git | Maintained and supported by SUSTech CRA and CCSE