Merge branch 'linus' into xen-64bit

		$ cd /sys/firmware/acpi/interrupts

		$ grep . *

		error:	     0

		ff_gbl_lock:0

		ff_pmtimer:0

		ff_pwr_btn:0

		ff_rt_clk:0

		ff_slp_btn:0

		gpe00:0

		gpe01:0

		gpe02:0

		gpe03:0

		gpe04:0

		gpe05:0

		gpe06:0

		gpe07:0

		gpe08:0

		gpe09:174

		gpe0A:0

		gpe0B:0

		gpe0C:0

		gpe0D:0

		gpe0E:0

		gpe0F:0

		gpe10:0

		gpe11:60

		gpe12:0

		gpe13:0

		gpe14:0

		gpe15:0

		gpe16:0

		gpe17:0

		gpe18:0

		gpe19:7

		gpe1A:0

		gpe1B:0

		gpe1C:0

		gpe1D:0

		gpe1E:0

		gpe1F:0

		gpe_all:241

		sci:241

		ff_gbl_lock:	   0   enable

		ff_pmtimer:	  0  invalid

		ff_pwr_btn:	  0   enable

		ff_rt_clk:	 2  disable

		ff_slp_btn:	  0  invalid

		gpe00:	     0	invalid

		gpe01:	     0	 enable

		gpe02:	   108	 enable

		gpe03:	     0	invalid

		gpe04:	     0	invalid

		gpe05:	     0	invalid

		gpe06:	     0	 enable

		gpe07:	     0	 enable

		gpe08:	     0	invalid

		gpe09:	     0	invalid

		gpe0A:	     0	invalid

		gpe0B:	     0	invalid

		gpe0C:	     0	invalid

		gpe0D:	     0	invalid

		gpe0E:	     0	invalid

		gpe0F:	     0	invalid

		gpe10:	     0	invalid

		gpe11:	     0	invalid

		gpe12:	     0	invalid

		gpe13:	     0	invalid

		gpe14:	     0	invalid

		gpe15:	     0	invalid

		gpe16:	     0	invalid

		gpe17:	  1084	 enable

		gpe18:	     0	 enable

		gpe19:	     0	invalid

		gpe1A:	     0	invalid

		gpe1B:	     0	invalid

		gpe1C:	     0	invalid

		gpe1D:	     0	invalid

		gpe1E:	     0	invalid

		gpe1F:	     0	invalid

		gpe_all:    1192

		sci:	1194

		sci - The total number of times the ACPI SCI

		has claimed an interrupt.

		error - an interrupt that can't be accounted for above.

		invalid: it's either a wakeup GPE or a GPE/Fixed Event that

			doesn't have an event handler.

		disable: the GPE/Fixed Event is valid but disabled.

		enable: the GPE/Fixed Event is valid and enabled.

		Root has permission to clear any of these counters.  Eg.

		# echo 0 > gpe11

		None of these counters has an effect on the function

		of the system, they are simply statistics.

		Besides this, user can also write specific strings to these files

		to enable/disable/clear ACPI interrupts in user space, which can be

		used to debug some ACPI interrupt storm issues.

		Note that only writting to VALID GPE/Fixed Event is allowed,

		i.e. user can only change the status of runtime GPE and

		Fixed Event with event handler installed.

		Let's take power button fixed event for example, please kill acpid

		and other user space applications so that the machine won't shutdown

		when pressing the power button.

		# cat ff_pwr_btn

		0

		# press the power button for 3 times;

		# cat ff_pwr_btn

		3

		# echo disable > ff_pwr_btn

		# cat ff_pwr_btn

		disable

		# press the power button for 3 times;

		# cat ff_pwr_btn

		disable

		# echo enable > ff_pwr_btn

		# cat ff_pwr_btn

		4

		/*

		 * this is because the status bit is set even if the enable bit is cleared,

		 * and it triggers an ACPI fixed event when the enable bit is set again

		 */

		# press the power button for 3 times;

		# cat ff_pwr_btn

		7

		# echo disable > ff_pwr_btn

		# press the power button for 3 times;

		# echo clear > ff_pwr_btn	/* clear the status bit */

		# echo disable > ff_pwr_btn

		# cat ff_pwr_btn

		7

config_item_type.

	struct configfs_group_operations {

		struct config_item *(*make_item)(struct config_group *group,

						 const char *name);

		struct config_group *(*make_group)(struct config_group *group,

						   const char *name);

		int (*make_item)(struct config_group *group,

				 const char *name,

				 struct config_item **new_item);

		int (*make_group)(struct config_group *group,

				  const char *name,

				  struct config_group **new_group);

		int (*commit_item)(struct config_item *item);

		void (*disconnect_notify)(struct config_group *group,

					  struct config_item *item);

	return item ? container_of(to_config_group(item), struct simple_children, group) : NULL;

}

static struct config_item *simple_children_make_item(struct config_group *group, const char *name)

static int simple_children_make_item(struct config_group *group, const char *name, struct config_item **new_item)

{

	struct simple_child *simple_child;

	simple_child = kzalloc(sizeof(struct simple_child), GFP_KERNEL);

	if (!simple_child)

		return NULL;

		return -ENOMEM;

	config_item_init_type_name(&simple_child->item, name,

	simple_child->storeme = 0;

	return &simple_child->item;

	*new_item = &simple_child->item;

	return 0;

}

static struct configfs_attribute simple_children_attr_description = {

 * children of its own.

 */

static struct config_group *group_children_make_group(struct config_group *group, const char *name)

static int group_children_make_group(struct config_group *group, const char *name, struct config_group **new_group)

{

	struct simple_children *simple_children;

	simple_children = kzalloc(sizeof(struct simple_children),

				  GFP_KERNEL);

	if (!simple_children)

		return NULL;

		return -ENOMEM;

	config_group_init_type_name(&simple_children->group, name,

				    &simple_children_type);

	return &simple_children->group;

	*new_group = &simple_children->group;

	return 0;

}

static struct configfs_attribute group_children_attr_description = {

Introduction

=============

UBIFS file-system stands for UBI File System. UBI stands for "Unsorted

Block Images". UBIFS is a flash file system, which means it is designed

to work with flash devices. It is important to understand, that UBIFS

is completely different to any traditional file-system in Linux, like

Ext2, XFS, JFS, etc. UBIFS represents a separate class of file-systems

which work with MTD devices, not block devices. The other Linux

file-system of this class is JFFS2.

To make it more clear, here is a small comparison of MTD devices and

block devices.

1 MTD devices represent flash devices and they consist of eraseblocks of

  rather large size, typically about 128KiB. Block devices consist of

  small blocks, typically 512 bytes.

2 MTD devices support 3 main operations - read from some offset within an

  eraseblock, write to some offset within an eraseblock, and erase a whole

  eraseblock. Block  devices support 2 main operations - read a whole

  block and write a whole block.

3 The whole eraseblock has to be erased before it becomes possible to

  re-write its contents. Blocks may be just re-written.

4 Eraseblocks become worn out after some number of erase cycles -

  typically 100K-1G for SLC NAND and NOR flashes, and 1K-10K for MLC

  NAND flashes. Blocks do not have the wear-out property.

5 Eraseblocks may become bad (only on NAND flashes) and software should

  deal with this. Blocks on hard drives typically do not become bad,

  because hardware has mechanisms to substitute bad blocks, at least in

  modern LBA disks.

It should be quite obvious why UBIFS is very different to traditional

file-systems.

UBIFS works on top of UBI. UBI is a separate software layer which may be

found in drivers/mtd/ubi. UBI is basically a volume management and

wear-leveling layer. It provides so called UBI volumes which is a higher

level abstraction than a MTD device. The programming model of UBI devices

is very similar to MTD devices - they still consist of large eraseblocks,

they have read/write/erase operations, but UBI devices are devoid of

limitations like wear and bad blocks (items 4 and 5 in the above list).

In a sense, UBIFS is a next generation of JFFS2 file-system, but it is

very different and incompatible to JFFS2. The following are the main

differences.

* JFFS2 works on top of MTD devices, UBIFS depends on UBI and works on

  top of UBI volumes.

* JFFS2 does not have on-media index and has to build it while mounting,

  which requires full media scan. UBIFS maintains the FS indexing

  information on the flash media and does not require full media scan,

  so it mounts many times faster than JFFS2.

* JFFS2 is a write-through file-system, while UBIFS supports write-back,

  which makes UBIFS much faster on writes.

Similarly to JFFS2, UBIFS supports on-the-flight compression which makes

it possible to fit quite a lot of data to the flash.

Similarly to JFFS2, UBIFS is tolerant of unclean reboots and power-cuts.

It does not need stuff like ckfs.ext2. UBIFS automatically replays its

journal and recovers from crashes, ensuring that the on-flash data

structures are consistent.

UBIFS scales logarithmically (most of the data structures it uses are

trees), so the mount time and memory consumption do not linearly depend

on the flash size, like in case of JFFS2. This is because UBIFS

maintains the FS index on the flash media. However, UBIFS depends on

UBI, which scales linearly. So overall UBI/UBIFS stack scales linearly.

Nevertheless, UBI/UBIFS scales considerably better than JFFS2.

The authors of UBIFS believe, that it is possible to develop UBI2 which

would scale logarithmically as well. UBI2 would support the same API as UBI,

but it would be binary incompatible to UBI. So UBIFS would not need to be

changed to use UBI2

Mount options

=============

(*) == default.

norm_unmount (*)	commit on unmount; the journal is committed

			when the file-system is unmounted so that the

			next mount does not have to replay the journal

			and it becomes very fast;

fast_unmount		do not commit on unmount; this option makes

			unmount faster, but the next mount slower

			because of the need to replay the journal.

Quick usage instructions

========================

The UBI volume to mount is specified using "ubiX_Y" or "ubiX:NAME" syntax,

where "X" is UBI device number, "Y" is UBI volume number, and "NAME" is

UBI volume name.

Mount volume 0 on UBI device 0 to /mnt/ubifs:

$ mount -t ubifs ubi0_0 /mnt/ubifs

Mount "rootfs" volume of UBI device 0 to /mnt/ubifs ("rootfs" is volume

name):

$ mount -t ubifs ubi0:rootfs /mnt/ubifs

The following is an example of the kernel boot arguments to attach mtd0

to UBI and mount volume "rootfs":

ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs

Module Parameters for Debugging

===============================

When UBIFS has been compiled with debugging enabled, there are 3 module

parameters that are available to control aspects of testing and debugging.

The parameters are unsigned integers where each bit controls an option.

The parameters are:

debug_msgs	Selects which debug messages to display, as follows:

		Message Type				Flag value

		General messages			1

		Journal messages			2

		Mount messages				4

		Commit messages				8

		LEB search messages			16

		Budgeting messages			32

		Garbage collection messages		64

		Tree Node Cache (TNC) messages		128

		LEB properties (lprops) messages	256

		Input/output messages			512

		Log messages				1024

		Scan messages				2048

		Recovery messages			4096

debug_chks	Selects extra checks that UBIFS can do while running:

		Check					Flag value

		General checks				1

		Check Tree Node Cache (TNC)		2

		Check indexing tree size		4

		Check orphan area			8

		Check old indexing tree			16

		Check LEB properties (lprops)		32

		Check leaf nodes and inodes		64

debug_tsts	Selects a mode of testing, as follows:

		Test mode				Flag value

		Force in-the-gaps method		2

		Failure mode for recovery testing	4

For example, set debug_msgs to 5 to display General messages and Mount

messages.

References

==========

UBIFS documentation and FAQ/HOWTO at the MTD web site:

http://www.linux-mtd.infradead.org/doc/ubifs.html

http://www.linux-mtd.infradead.org/faq/ubifs.html

The MAX6874/MAX6875 ignores address bit 0, so this driver attaches to multiple

addresses.  For example, for address 0x50, it also reserves 0x51.

The even-address instance is called 'max6875', the odd one is 'max6875 subclient'.

The even-address instance is called 'max6875', the odd one is 'dummy'.

Programming the chip using i2c-dev