Merge branch 'driver-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

If no 2.6.x.y kernel is available, then the highest numbered 2.6.x

kernel is the current stable kernel.

2.6.x.y are maintained by the "stable" team <stable@kernel.org>, and are

released as needs dictate.  The normal release period is approximately 

2.6.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and

are released as needs dictate.  The normal release period is approximately

two weeks, but it can be longer if there are no pressing problems.  A

security-related problem, instead, can cause a release to happen almost

instantly.

   the linux-kernel list.

 - If you are fixing a bug, think about whether the fix should go into the

   next stable update.  If so, stable@kernel.org should get a copy of the

   patch.  Also add a "Cc: stable@kernel.org" to the tags within the patch

   itself; that will cause the stable team to get a notification when your

   fix goes into the mainline.

   next stable update.  If so, stable@vger.kernel.org should get a copy of

   the patch.  Also add a "Cc: stable@vger.kernel.org" to the tags within

   the patch itself; that will cause the stable team to get a notification

   when your fix goes into the mainline.

When selecting recipients for a patch, it is good to have an idea of who

you think will eventually accept the patch and get it merged.  While it

  devm_ioremap()

  devm_ioremap_nocache()

  devm_iounmap()

  devm_request_and_ioremap() : checks resource, requests region, ioremaps

  pcim_iomap()

  pcim_iounmap()

  pcim_iomap_table()	: array of mapped addresses indexed by BAR

N, followed by a newline.  If written to, it will accept either upper- or

lower-case values, or 1 or 0.  Any other input will be silently ignored.

Finally, a block of arbitrary binary data can be exported with:

Another option is exporting a block of arbitrary binary data, with

this structure and function:

    struct debugfs_blob_wrapper {

	void *data;

any code which does so in the mainline.  Note that all files created with

debugfs_create_blob() are read-only.

If you want to dump a block of registers (something that happens quite

often during development, even if little such code reaches mainline.

Debugfs offers two functions: one to make a registers-only file, and

another to insert a register block in the middle of another sequential

file.

    struct debugfs_reg32 {

	char *name;

	unsigned long offset;

    };

    struct debugfs_regset32 {

	struct debugfs_reg32 *regs;

	int nregs;

	void __iomem *base;

    };

    struct dentry *debugfs_create_regset32(const char *name, mode_t mode,

				     struct dentry *parent,

				     struct debugfs_regset32 *regset);

    int debugfs_print_regs32(struct seq_file *s, struct debugfs_reg32 *regs,

			 int nregs, void __iomem *base, char *prefix);

The "base" argument may be 0, but you may want to build the reg32 array

using __stringify, and a number of register names (macros) are actually

byte offsets over a base for the register block.

There are a couple of other directory-oriented helper functions:

    struct dentry *debugfs_rename(struct dentry *old_dir, 

STABLE BRANCH

M:	Greg Kroah-Hartman <greg@kroah.com>

L:	stable@kernel.org

L:	stable@vger.kernel.org

S:	Maintained

STAGING SUBSYSTEM