Merge branch 'fix' of git://git.kernel.org/pub/scm/linux/kernel/git/ycmiao/pxa-linux-2.6

What:           /sys/class/usb_host/usb_hostN/wusb_chid

What:           /sys/class/uwb_rc/uwbN/wusbhc/wusb_chid

Date:           July 2008

KernelVersion:  2.6.27

Contact:        David Vrabel <david.vrabel@csr.com>

                Set an all zero CHID to stop the host controller.

What:           /sys/class/usb_host/usb_hostN/wusb_trust_timeout

What:           /sys/class/uwb_rc/uwbN/wusbhc/wusb_trust_timeout

Date:           July 2008

KernelVersion:  2.6.27

Contact:        David Vrabel <david.vrabel@csr.com>

Bernhard Kaindl enhanced firescope to support accessing 64-bit machines

from 32-bit firescope and vice versa:

- ftp://ftp.suse.de/private/bk/firewire/tools/firescope-0.2.2.tar.bz2

- http://halobates.de/firewire/firescope-0.2.2.tar.bz2

and he implemented fast system dump (alpha version - read README.txt):

- ftp://ftp.suse.de/private/bk/firewire/tools/firedump-0.1.tar.bz2

- http://halobates.de/firewire/firedump-0.1.tar.bz2

There is also a gdb proxy for firewire which allows to use gdb to access

data which can be referenced from symbols found by gdb in vmlinux:

- ftp://ftp.suse.de/private/bk/firewire/tools/fireproxy-0.33.tar.bz2

- http://halobates.de/firewire/fireproxy-0.33.tar.bz2

The latest version of this gdb proxy (fireproxy-0.34) can communicate (not

yet stable) with kgdb over an memory-based communication module (kgdbom).

Notes

-----

Documentation and specifications: ftp://ftp.suse.de/private/bk/firewire/docs

Documentation and specifications: http://halobates.de/firewire/

FireWire is a trademark of Apple Inc. - for more information please refer to:

http://en.wikipedia.org/wiki/FireWire

	will also allow making ALSA OSS emulation independent of

	sound_core.  The dependency will be broken then too.

Who:	Tejun Heo <tj@kernel.org>

----------------------------

What:	Support for VMware's guest paravirtuliazation technique [VMI] will be

	dropped.

When:	2.6.37 or earlier.

Why:	With the recent innovations in CPU hardware acceleration technologies

	from Intel and AMD, VMware ran a few experiments to compare these

	techniques to guest paravirtualization technique on VMware's platform.

	These hardware assisted virtualization techniques have outperformed the

	performance benefits provided by VMI in most of the workloads. VMware

	expects that these hardware features will be ubiquitous in a couple of

	years, as a result, VMware has started a phased retirement of this

	feature from the hypervisor. We will be removing this feature from the

	Kernel too. Right now we are targeting 2.6.37 but can retire earlier if

	technical reasons (read opportunity to remove major chunk of pvops)

	arise.

	Please note that VMI has always been an optimization and non-VMI kernels

	still work fine on VMware's platform.

	Latest versions of VMware's product which support VMI are,

	Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence

	releases for these products will continue supporting VMI.

	For more details about VMI retirement take a look at this,

	http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html

Who:	Alok N Kataria <akataria@vmware.com>

----------------------------

Using flexible arrays in the kernel

Last updated for 2.6.31

Last updated for 2.6.32

Jonathan Corbet <corbet@lwn.net>

Large contiguous memory allocations can be unreliable in the Linux kernel.

the current code, using flags to ask for high memory is likely to lead to

notably unpleasant side effects.

It is also possible to define flexible arrays at compile time with:

    DEFINE_FLEX_ARRAY(name, element_size, total);

This macro will result in a definition of an array with the given name; the

element size and total will be checked for validity at compile time.

Storing data into a flexible array is accomplished with a call to:

    int flex_array_put(struct flex_array *array, unsigned int element_nr,

Note that it is possible to get back a valid pointer for an element which

has never been stored in the array.  Memory for array elements is allocated

one page at a time; a single allocation could provide memory for several

adjacent elements.  The flexible array code does not know if a specific

element has been written; it only knows if the associated memory is

present.  So a flex_array_get() call on an element which was never stored

in the array has the potential to return a pointer to random data.  If the

caller does not have a separate way to know which elements were actually

stored, it might be wise, at least, to add GFP_ZERO to the flags argument

to ensure that all elements are zeroed.

There is no way to remove a single element from the array.  It is possible,

though, to remove all elements with a call to:

adjacent elements.  Flexible array elements are normally initialized to the

value FLEX_ARRAY_FREE (defined as 0x6c in <linux/poison.h>), so errors

involving that number probably result from use of unstored array entries.

Note that, if array elements are allocated with __GFP_ZERO, they will be

initialized to zero and this poisoning will not happen.

Individual elements in the array can be cleared with:

    int flex_array_clear(struct flex_array *array, unsigned int element_nr);

This function will set the given element to FLEX_ARRAY_FREE and return

zero.  If storage for the indicated element is not allocated for the array,

flex_array_clear() will return -EINVAL instead.  Note that clearing an

element does not release the storage associated with it; to reduce the

allocated size of an array, call:

    int flex_array_shrink(struct flex_array *array);

The return value will be the number of pages of memory actually freed.

This function works by scanning the array for pages containing nothing but

FLEX_ARRAY_FREE bytes, so (1) it can be expensive, and (2) it will not work

if the array's pages are allocated with __GFP_ZERO.

It is possible to remove all elements of an array with a call to:

    void flex_array_free_parts(struct flex_array *array);

W:	http://www.linux1394.org/

T:	git git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git

S:	Maintained

F:	Documentation/debugging-via-ohci1394.txt

F:	drivers/ieee1394/

IEEE 1394 RAW I/O DRIVER

M:	"David S. Miller" <davem@davemloft.net>

L:	netdev@vger.kernel.org

W:	http://www.linuxfoundation.org/en/Net

W:	http://patchwork.ozlabs.org/project/netdev/list/

T:	git git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6.git

S:	Maintained

F:	net/

M:	Paul Mackerras <paulus@samba.org>

M:	Ingo Molnar <mingo@elte.hu>

S:	Supported

F:	kernel/perf_event.c

F:	include/linux/perf_event.h

F:	arch/*/*/kernel/perf_event.c

F:	arch/*/include/asm/perf_event.h

F:	arch/*/lib/perf_event.c

F:	arch/*/kernel/perf_callchain.c

F:	tools/perf/

PERSONALITY HANDLING

M:	Christoph Hellwig <hch@infradead.org>

F:	drivers/vlynq/vlynq.c

F:	include/linux/vlynq.h

VMWARE VMXNET3 ETHERNET DRIVER

M:     Shreyas Bhatewara <sbhatewara@vmware.com>

M:     VMware, Inc. <pv-drivers@vmware.com>

L:     netdev@vger.kernel.org

S:     Maintained

F:     drivers/net/vmxnet3/

VOLTAGE AND CURRENT REGULATOR FRAMEWORK

M:	Liam Girdwood <lrg@slimlogic.co.uk>

M:	Mark Brown <broonie@opensource.wolfsonmicro.com>