* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-2.6:
  SCSI: fix race in device_create
  USB: Core: fix race in device_create
  USB: Phidget: fix race in device_create
  s390: fix race in device_create
  SOUND: fix race in device_create
  UIO: fix race in device_create
  Power Supply: fix race in device_create
  LEDS: fix race in device_create
  IB: fix race in device_create
  ide: fix race in device_create
  fbdev: fix race in device_create
  mm: bdi: fix race in bdi_class device creation
  Driver core: add device_create_vargs and device_create_drvdata

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx:
  iop-adma: fixup some kzalloc/memset confusions
  fsldma: update the fsldma driver MAINTAINERS info

1) Remove an explicit memset(.., 0, ...) to a variable allocated with
kzalloc (i.e. 'dest').

2) Allocate 'src' with kmalloc instead of kzalloc as all elements of the
'src' buffer are initialized in a 'for(...)' loop just after.

3) remove useless 'sizeof(u8)', which always returns 1, when computing the
size of the memory to be allocated.
Signed-off-by: NChristophe Jaillet <christophe.jaillet@wanadoo.fr>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

Add Li Yang as the new maintainer for fsldma driver and update
my email address.
Acked-by: NLi Yang <leoli@freescale.com>
Signed-off-by: NZhang Wei <zw@zh-kernel.org>
Signed-off-by: NDan Williams <dan.j.williams@intel.com>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().  It fixes the problem in all of the scsi
drivers that need it.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Doug Gilbert <dgilbert@interlog.com>
Cc: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().

Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().  It fixes all 3 phidget drivers, which all have
the same problem.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Sean Young <sean@mess.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Jaroslav Kysela <perex@perex.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Hans J. Koch <hjk@linutronix.de>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Anton Vorontsov <cbou@mail.ru>
Cc: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Richard Purdie <rpurdie@rpsys.net>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().

Cc: Kay Sievers <kay.sievers@vrfy.org>
Reviewed-by: NRoland Dreier <rolandd@cisco.com>
Cc: Sean Hefty <sean.hefty@intel.com>
Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().

Cc: Kay Sievers <kay.sievers@vrfy.org>
Acked-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_drvdata().

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: James Simmons <jsimmons@infradead.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

There is a race from when a device is created with device_create() and
then the drvdata is set with a call to dev_set_drvdata() in which a
sysfs file could be open, yet the drvdata will be NULL, causing all
sorts of bad things to happen.

This patch fixes the problem by using the new function,
device_create_vargs().

Many thanks to Arthur Jones <ajones@riverbed.com> for reporting the bug,
and testing patches out.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Cc: Arthur Jones <ajones@riverbed.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Miklos Szeredi <mszeredi@suse.cz>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

We want to have the drvdata field set properly when creating the device
as sysfs callbacks can assume it is present and it can race the later
setting of this field.

So, create two new functions, deviec_create_vargs() and
device_create_drvdata() that take this new field.

device_create_drvdata() will go away in 2.6.27 as the drvdata field will
just be moved to the device_create() call as it should be.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
  PCI: correct mailing list address
  PCI: Correct last two HP entries in the bfsort whitelist

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: prevent userspace from accessing shut down devices
  ieee1394: sbp2: use correct size of command descriptor block

vidiocgmbuf() does this:
        mutex_lock(&fh->cap.vb_lock);
        retval = videobuf_mmap_setup(&fh->cap, gbuffers, gbufsize,
                                     V4L2_MEMORY_MMAP);

and videobuf_mmap_setup() then just does
        mutex_lock(&q->vb_lock);
        ret = __videobuf_mmap_setup(q, bcount, bsize, memory);
        mutex_unlock(&q->vb_lock);

which is an obvious double-take deadlock.

This patch fixes this by having vidiocgmbuf() just call the
__videobuf_mmap_setup function instead.
Acked-by: NMauro Carvalho Chehab <mchehab@infradead.org>
Reported-by: NKoos Vriezen <koos.vriezen@gmail.com>
Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

If userspace ignores the POLLERR bit from poll(), and only attempts to
read() the device when POLLIN is set, it can still make ioctl() calls on
a device that has been removed from the system.  The node_id and
generation returned by GET_INFO will be outdated, but INITIATE_BUS_RESET
would still cause a bus reset, and GET_CYCLE_TIMER will return data.
And if you guess the correct generation to use, you can send requests to
a different device on the bus, and get responses back.

This patch prevents open, ioctl, compat_ioctl, and mmap against shutdown
devices.
Signed-off-by: NJay Fenlason <fenlason@redhat.com>
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

Boaz Harrosh wrote:
> cmd->cmd_len is now guarantied to be set properly at all cases.
> And some commands you want to support will not be set correctly
> by COMMAND_SIZE().
Signed-off-by: NStefan Richter <stefanr@s5r6.in-berlin.de>

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6:
  [ALSA] hda - Fix ASUS P5GD1 model
  [ALSA] hda - Fix ALC262 fujitsu model
  snd-pcsp: use HRTIMER_CB_SOFTIRQ

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid:
  HID: remove CVS keywords
  HID: Add iMON LCDs to blacklist
  HID: add Microchip PICKit 1 and PICkit 2 to blacklist
  HID: split Numlock emulation quirk from HID_QUIRK_APPLE_HAS_FN.

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc:
  [POWERPC] Update defconfigs for desktop/server systems
  [POWERPC] Fix mpc8377_mds.dts DMA nodes to match spec
  [POWERPC] Update arch/powerpc/boot/.gitignore
  [POWERPC] Remove generated files on make clean
  [POWERPC] powerpc/mm/hash_low_32.S: Remove CVS keyword
  [POWERPC] Update Cell MAINTAINERS entry, add spufs entry
  lmb: Fix compile warning

* git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes:
  [GFS2] Prefer strlcpy() over snprintf()
  [GFS2] Fix cast from unsigned int to s64
  [GFS2] filesystem consistency error from do_strip

The x86_64 pgd_bad(), pud_bad(), pmd_bad() inlines have differed from
their x86_32 counterparts in a couple of ways: they've been unnecessarily
weak (e.g. letting 0 or 1 count as good), and were typed as unsigned long.
Strengthen them and return int.

The PAE pmd_bad was too weak before, allowing any junk in the upper half;
but got strengthened by the patch correcting its ~PAGE_MASK to ~PTE_MASK.
The PAE pud_bad already said ~PTE_MASK; and since it folds into pgd_bad,
and we don't set the protection bits at that level, it'll do as is.
Signed-off-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use PTE_MASK to extract mfn from pte.
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use ~PTE_MASK to extract the non-pfn parts of the pte (ie, the pte
flags), rather than constructing an ad-hoc mask.
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

_PAGE_CHG_MASK is defined as the set of bits not updated by
pte_modify(); specifically, the pfn itself, and the Accessed and Dirty
bits (which are updated by hardware).
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Use PTE_MASK in 3-level pagetables (ie, 32-bit PAE).
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Put the definitions of __(VIRTUAL|PHYSICAL)_MASK before their uses.
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Fix the warning:

include2/asm/pgtable.h: In function `pte_modify':
include2/asm/pgtable.h:290: warning: left shift count >= width of type

On 32-bit PAE the virtual and physical addresses are both 32-bits,
so it ends up evaluating 1<<32.  Do the shift as a 64-bit shift then
cast to the appropriate size.  This should all be done at compile time,
and so have no effect on generated code.
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Define PTE_MASK so that it contains a meaningful value for all x86
pagetable configurations.  Previously it was defined as a "long" which
means that it was too short to cover a 32-bit PAE pte entry.

It is now defined as a pteval_t, which is an integer type long enough
to contain a full pte (or pmd, pud, pgd).

This fixes an Xorg crash on 32-bit x86 with PAE due to corruption of the
NX bit in mprotect due to the incorrect type/value of PTE_MASK reported
by Hugh Dickins:

  "Yes, thanks Jeremy: I've checked that each stage builds and runs X on
   my boxes here, x86_32 and x86_32+PAE and x86_64.  (So even 1/8 is
   enough to fix the PAT pte_modify issue, though 2/8 then fixes
   compiler warnings.)"
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Tested-by: NHugh Dickins <hugh@veritas.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

This patch removes CVS keywords that weren't updated for a long time
from comments.
Signed-off-by: NAdrian Bunk <bunk@kernel.org>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

The new iMON LCDs from SoundGraph need to be blacklisted from HID in order to
be used by lirc.
Signed-off-by: NDylan R Semler <dylan.semler@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Microchip PICkit 1 and PICKit 2 USB Programmers are USB HID class of device but
they are not real HID device. They are now supported by libusb based programs
like the following programs.

pk2 and pk2cmd Linux port:
	http://home.pacbell.net/theposts/picmicro/
usb_pickit:
	http://tfc.duke.free.fr/pickit.html
usb_pickit original version:
	http://charm.cs.uiuc.edu/users/olawlor/projects/2003/microchip/

Therefore it ispreferred to blacklist them.
Signed-off-by: NXiaofan Chen <xiaofanc@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Since 2.6.25 the HID_QUIRK_APPLE_HAS_FN quirk is enabled even for
non-laptop Apple keyboards of the Aluminium series. The USB version of
these don't need Numlock emulation, like the laptop (and Aluminium
Wireless) do, as they have a proper keypad.

This patch splits the Numlock emulation for Apple keyboards in a
different quirk flag, so that it can be enabled for all the keyboards
but the Aluminium USB ones.

If the Numlock emulation is enabled for Aluminium USB keyboards, the
JKL and UIO keys become the numeric pad, and the rest of the keyboard
is disabled, included the key used to disable Numlock.

Additionally, these keyboard should not have a Numlock at all, as the
Numlock key is instead replaced by the 'Clear' key as usual for Apple
USB keyboards.
Signed-off-by: NDiego 'Flameeyes' Petteno <flameeyes@gmail.com>
Signed-off-by: NJiri Kosina <jkosina@suse.cz>

Signed-off-by: NPaul Mackerras <paulus@samba.org>