pandora-kernel.git
10 years agotwl4030_charger: ack and ratelimit monitoring events pandora-39
Grazvydas Ignotas [Sat, 4 Jun 2011 16:40:44 +0000 (19:40 +0300)]
twl4030_charger: ack and ratelimit monitoring events

10 years agoadd pandora's defconfigs
Grazvydas Ignotas [Tue, 31 May 2011 22:22:17 +0000 (01:22 +0300)]
add pandora's defconfigs

There are 2 defconfigs now:
- arch/arm/configs/omap3_pandora_defconfig
  proposed kernel config to be used for kernel in firmware
- arch/arm/configs/omap3_pandora_debug_defconfig
  defconfig with debugging options enabled and most stuff built in
  for quick debug sessions.

10 years agopower_supply: twl4030: allow USB charging by default
Grazvydas Ignotas [Sat, 26 Feb 2011 18:00:08 +0000 (20:00 +0200)]
power_supply: twl4030: allow USB charging by default

This is disabled in mainline because we don't know amount of current
host device can provide, but enabling it here regardless like we did
with 2.6.27.

10 years agopandora: setup fn keys for hacked twl4030_keypad
Grazvydas Ignotas [Sat, 26 Jun 2010 20:10:18 +0000 (23:10 +0300)]
pandora: setup fn keys for hacked twl4030_keypad

10 years agoinput: add hackish fn handling to twl4030_keypad
Grazvydas Ignotas [Sat, 26 Jun 2010 20:03:59 +0000 (23:03 +0300)]
input: add hackish fn handling to twl4030_keypad

10 years agopandora: add leds_pwm platform data
Grazvydas Ignotas [Sun, 27 Jun 2010 18:36:11 +0000 (21:36 +0300)]
pandora: add leds_pwm platform data

10 years agoleds: add TWL4030 PWM LED driver
Grazvydas Ignotas [Sun, 27 Jun 2010 16:59:03 +0000 (19:59 +0300)]
leds: add TWL4030 PWM LED driver

Some code contributed by Urja Rannikko <urjaman@gmail.com>

10 years agopandora: add backlight platform data
Grazvydas Ignotas [Mon, 21 Jun 2010 21:43:25 +0000 (00:43 +0300)]
pandora: add backlight platform data

10 years agopandora_bl: add backlight type
Grazvydas Ignotas [Wed, 1 Jun 2011 10:28:13 +0000 (13:28 +0300)]
pandora_bl: add backlight type

this appeared in .39 and needs to be filled to avoid warning.

10 years agobacklight: add backlight driver for pandora
Grazvydas Ignotas [Mon, 21 Jun 2010 21:29:10 +0000 (00:29 +0300)]
backlight: add backlight driver for pandora

This is fine-tuned driver for pandora's backlight connected to
TWL4030 PWM0 and LED driver chip.

10 years agopandora: add vsense platform data
Grazvydas Ignotas [Sun, 20 Jun 2010 19:30:21 +0000 (22:30 +0300)]
pandora: add vsense platform data

10 years agoinput: add VSense (analog controller) driver
Grazvydas Ignotas [Sun, 20 Jun 2010 18:34:00 +0000 (21:34 +0300)]
input: add VSense (analog controller) driver

This drives analog nubs on pandora.

10 years agopandora: create proc entry early
Grazvydas Ignotas [Tue, 22 Jun 2010 20:40:52 +0000 (23:40 +0300)]
pandora: create proc entry early

this will avoid needing to handle it in drivers.

10 years agoadd Pandora Linux logo :)
Grazvydas Ignotas [Sun, 20 Jun 2010 19:57:19 +0000 (22:57 +0300)]
add Pandora Linux logo :)

10 years agomusb VBUS workaround
Grazvydas Ignotas [Wed, 6 Oct 2010 22:12:09 +0000 (01:12 +0300)]
musb VBUS workaround

For some reason VBUS never falls after cable is disconnected
on pandora. The voltage can be even measured with a multimeter.
This is not the case on a friend's beagle. So this hack was written
to work around this.

10 years agoaufs: aufs2.1 kbuild patch for linux-2.6.39
aufs project [Mon, 30 May 2011 16:07:41 +0000 (19:07 +0300)]
aufs: aufs2.1 kbuild patch for linux-2.6.39

10 years agoaufs: aufs2.1 standalone patch for linux-2.6.39
aufs project [Mon, 30 May 2011 16:07:29 +0000 (19:07 +0300)]
aufs: aufs2.1 standalone patch for linux-2.6.39

10 years agoaufs: aufs2.1 base patch for linux-2.6.39
aufs project [Mon, 30 May 2011 16:03:11 +0000 (19:03 +0300)]
aufs: aufs2.1 base patch for linux-2.6.39

10 years agoaufs: add files
aufs project [Mon, 30 May 2011 15:57:49 +0000 (18:57 +0300)]
aufs: add files

10 years agoAdd power-off support for the TWL4030 companion
Bernhard Wörndl-Aichriedler [Sat, 15 May 2010 14:34:05 +0000 (16:34 +0200)]
Add power-off support for the TWL4030 companion

This patch adds support for the power-off on shutdown feature of the TWL4030

10 years agoomap: mmc: Adjust dto to eliminate timeout errors
Steve Sakoman [Wed, 12 Jan 2011 13:54:55 +0000 (05:54 -0800)]
omap: mmc: Adjust dto to eliminate timeout errors

A number of SD card types were experiencing timeout errors.  This
could also lead to data corruption in some cases.

This fix proposed by Sukumar Ghoral of TI.

10 years agoEnabling Hwmon driver for twl4030-madc
Keerthy [Tue, 3 May 2011 19:44:50 +0000 (01:14 +0530)]
Enabling Hwmon driver for twl4030-madc

Signed-off-by: Keerthy <j-keerthy@ti.com>
10 years agoomap: pandora: fix NAND support
Grazvydas Ignotas [Fri, 3 Jun 2011 20:12:23 +0000 (23:12 +0300)]
omap: pandora: fix NAND support

Commit d5ce2b65 "omap3630: nand: fix device size to work in polled mode"
changed values for .devsize in nand platform data, now we have to pass
NAND_BUSWIDTH_16 instead of '1' to select 16bit NAND.

Update pandora's platform data accordingly, also specify appropriate
transfer type.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
10 years agotwl4030_charger: fix warnings
Grazvydas Ignotas [Fri, 3 Jun 2011 10:59:40 +0000 (13:59 +0300)]
twl4030_charger: fix warnings

Fix warnings emitted by some versions of gcc:
drivers/power/twl4030_charger.c:490: warning: overflow in implicit constant conversion
drivers/power/twl4030_charger.c:498: warning: overflow in implicit constant conversion

While at it, also fix module_param permissions and a typo in my name.

Signed-off-by: Grazvydas Ignotas <notasas@gmail.com>
10 years agoOMAP2/3: hwmod: fix the i2c-reset timeout during bootup
Avinash.H.M [Fri, 20 May 2011 15:46:24 +0000 (21:16 +0530)]
OMAP2/3: hwmod: fix the i2c-reset timeout during bootup

The sequence of _ocp_softreset doesn't work for i2c. The i2c module has a
special sequence to reset the module. The sequence is
 - Disable the I2C.
 - Write to SOFTRESET bit.
 - Enable the I2C.
 - Poll on the RESETDONE bit.
The sequence is implemented as a function and the i2c_class is updated with
the correct 'reset' pointer.  omap_hwmod_softreset function is implemented
which triggers the softreset by writing into sysconfig register. On following
this sequence, i2c module resets properly and timeouts are not seen.

Cc: Rajendra Nayak <rnayak@ti.com>
Cc: Paul Walmsley <paul@pwsan.com>
Cc: Benoit Cousson <b-cousson@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
Signed-off-by: Avinash.H.M <avinashhm@ti.com>
10 years agoI2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c
Andy Green [Mon, 30 May 2011 14:43:00 +0000 (07:43 -0700)]
I2C: OMAP2+: Set hwmod flags to only allow 16-bit accesses to i2c

Peter Maydell noticed when running under QEMU he was getting
errors reporting 32-bit access to I2C peripheral unit registers
that are documented to be 8 or 16-bit only[1][2]

The I2C driver is blameless as it wraps its accesses in a
function using __raw_writew and __raw_readw, it turned out it
is the hwmod stuff.

However the hwmod code already has a flag to force a
perhipheral unit to only be accessed using 16-bit operations.

This patch applies the 16-bit only flag to the 2430,
OMAP3xxx and OMAP44xx hwmod structs.  2420 was already
correctly marked up as 16-bit.

The 2430 change will need testing by TI as arranged
in the comments to the previous patch version.

When the 16-bit flag is or-ed with other flags, it is placed
first as requested in comments.

[1] OMAP4430 Technical reference manual section 23.1.6.2
[2] OMAP3530 Techincal reference manual section 18.6

Cc: patches@linaro.org
Cc: Ben Dooks <ben-linux@fluff.org>
Reported-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Andy Green <andy.green@linaro.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Kevin Hilman <khilman@ti.com>
10 years agowl1251: Add support for idle mode
Jarkko Nikula [Mon, 4 Apr 2011 08:04:58 +0000 (11:04 +0300)]
wl1251: Add support for idle mode

On Nokia N900 the wl1251 consumes the most power when the interface is up
but not associated to access point (that supports PSM). In terms of battery
current consumption, the consumption is ~180 mA higher when the interface is
up but not associated and only ~5 mA higher when associated compared to
interface down and driver not loaded cases.

This patch adds support for the mac80211 idle notifications. Chip is put into
idle very much the same way when entering into PSM by utilizing the Extreme
Low Power (ELP) mode. I.e. idle is entered by setting necessary conditions
in wl1251_ps_set_mode followed by a call to wl1251_ps_elp_sleep.

It seems it is just enough the authorize ELP mode followed by
CMD_DISCONNECT (thanks to Kalle Valo about the idea to use it).
Without disconnect command the chip remains somewhat active and stays
consuming ~20 mA. Idle mode is left by same way than PSM. The wl1251_join
call is used to revert the CMD_DISCONNECT. Without it association to AP
doesn't work when trying second time.

With this patch the interface up but not associated case the battery current
consumption is less than 1 mA higher compared to interface down case.

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
10 years agowl1251: Prepare for idle mode support
Jarkko Nikula [Mon, 4 Apr 2011 08:04:57 +0000 (11:04 +0300)]
wl1251: Prepare for idle mode support

RFC for WL1251 idle mode support brought a few issues that are worth to
update before adding the idle mode support.

Since the idle mode can reuse the code that is now used in Power Save Mode
(PSM), the flag psm in struct wl1251 is changed to variable station_mode
to be able to distinguish between PSM and idle modes.

As the station mode is different than the power power save mode command
that is sent to chip, the enum wl1251_cmd_ps_mod values are used only when
communicating with the chip and new enum wl1251_station_mode values are used
inside the driver.

Confusing comment about psm and elp relation is removed since the PSM is
actually activated by putting the chip into Entreme Low Power (ELP) mode.

Signed-off-by: Jarkko Nikula <jhnikula@gmail.com>
Acked-by: Kalle Valo <kvalo@adurom.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
10 years agobq27x00_battery: Name of cycle count property
Pali Rohár [Sat, 30 Apr 2011 21:59:35 +0000 (23:59 +0200)]
bq27x00_battery: Name of cycle count property

This patch fix using correct property POWER_SUPPLY_PROP_CYCLE_COUNT
for cycle count instead POWER_SUPPLY_PROP_CHARGE_COUNTER

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
Tested-by: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Anton Vorontsov <cbouatmailru@gmail.com>
10 years agomtd: omap2: mtd split nand_scan in ident and tail
Jan Weitzel [Tue, 19 Apr 2011 14:15:34 +0000 (16:15 +0200)]
mtd: omap2: mtd split nand_scan in ident and tail

nand_scan calls nand_scan_tail and here we got a ecc.layout and calculate
oobavail for this layout. After calling nand_scan, we change the layout pointer
if OMAP_ECC_HAMMING_CODE_HW_ROMCODE is set. This results in not calcluated
oobavail. Mountig as jffs2 is not possible.

To fix that nand_scan has to split up in nand_scan_ident and nand_scan_tail
setting ecc.layout between these calls. So nand_scan_tail calculates oobvail
for the used layout. This is also done in serveral other platforms.

Signed-off-by: Jan Weitzel <j.weitzel@phytec.de>
Reviewed-by: Vimal Singh <vimal.newwork@gmail.com>
Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
10 years agoLinux 2.6.39.1 v2.6.39.1
Greg Kroah-Hartman [Fri, 3 Jun 2011 00:34:20 +0000 (09:34 +0900)]
Linux 2.6.39.1

10 years agoAppArmor: fix oops in apparmor_setprocattr
Kees Cook [Tue, 31 May 2011 18:31:41 +0000 (11:31 -0700)]
AppArmor: fix oops in apparmor_setprocattr

commit a5b2c5b2ad5853591a6cac6134cd0f599a720865 upstream.

When invalid parameters are passed to apparmor_setprocattr a NULL deref
oops occurs when it tries to record an audit message. This is because
it is passing NULL for the profile parameter for aa_audit. But aa_audit
now requires that the profile passed is not NULL.

Fix this by passing the current profile on the task that is trying to
setprocattr.

Signed-off-by: Kees Cook <kees@ubuntu.com>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Signed-off-by: James Morris <jmorris@namei.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoext4: Use schedule_timeout_interruptible() for waiting in lazyinit thread
Lukas Czerner [Fri, 20 May 2011 17:49:04 +0000 (13:49 -0400)]
ext4: Use schedule_timeout_interruptible() for waiting in lazyinit thread

commit 4ed5c033c11b33149d993734a6a8de1016e8f03f upstream.

In order to make lazyinit eat approx. 10% of io bandwidth at max, we
are sleeping between zeroing each single inode table. For that purpose
we are using timer which wakes up thread when it expires. It is set
via add_timer() and this may cause troubles in the case that thread
has been woken up earlier and in next iteration we call add_timer() on
still running timer hence hitting BUG_ON in add_timer(). We could fix
that by using mod_timer() instead however we can use
schedule_timeout_interruptible() for waiting and hence simplifying
things a lot.

This commit exchange the old "waiting mechanism" with simple
schedule_timeout_interruptible(), setting the time to sleep. Hence we
do not longer need li_wait_daemon waiting queue and others, so get rid
of it.

Addresses-Red-Hat-Bugzilla: #699708

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoext4: fix possible use-after-free in ext4_remove_li_request()
Lukas Czerner [Fri, 20 May 2011 17:55:29 +0000 (13:55 -0400)]
ext4: fix possible use-after-free in ext4_remove_li_request()

commit 1bb933fb1fa8e4cb337a0d5dfd2ff4c0dc2073e8 upstream.

We need to take reference to the s_li_request after we take a mutex,
because it might be freed since then, hence result in accessing old
already freed memory. Also we should protect the whole
ext4_remove_li_request() because ext4_li_info might be in the process of
being freed in ext4_lazyinit_thread().

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoblock: don't block events on excl write for non-optical devices
Tejun Heo [Thu, 21 Apr 2011 18:54:46 +0000 (20:54 +0200)]
block: don't block events on excl write for non-optical devices

commit d4dc210f69bcb0b4bef5a83b1c323817be89bad1 upstream.

Disk event code automatically blocks events on excl write.  This is
primarily to avoid issuing polling commands while burning is in
progress.  This behavior doesn't fit other types of devices with
removeable media where polling commands don't have adverse side
effects and door locking usually doesn't exist.

This patch introduces new genhd flag which controls the auto-blocking
behavior and uses it to enable auto-blocking only on optical devices.

Note for stable: 2.6.38 and later only

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoxen mmu: fix a race window causing leave_mm BUG()
Tian, Kevin [Thu, 12 May 2011 02:56:08 +0000 (10:56 +0800)]
xen mmu: fix a race window causing leave_mm BUG()

commit 7899891c7d161752f29abcc9bc0a9c6c3a3af26c upstream.

There's a race window in xen_drop_mm_ref, where remote cpu may exit
dirty bitmap between the check on this cpu and the point where remote
cpu handles drop request. So in drop_other_mm_ref we need check
whether TLB state is still lazy before calling into leave_mm. This
bug is rarely observed in earlier kernel, but exaggerated by the
commit 831d52bc153971b70e64eccfbed2b232394f22f8
("x86, mm: avoid possible bogus tlb entries by clearing prev mm_cpumask after switching mm")
which clears bitmap after changing the TLB state. the call trace is as below:

---------------------------------
kernel BUG at arch/x86/mm/tlb.c:61!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/system/xen_memory/xen_memory0/info/current_kb
CPU 1
Modules linked in: 8021q garp xen_netback xen_blkback blktap blkback_pagemap nbd bridge stp llc autofs4 ipmi_devintf ipmi_si ipmi_msghandler lockd sunrpc bonding ipv6 xenfs dm_multipath video output sbs sbshc parport_pc lp parport ses enclosure snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device serio_raw bnx2 snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iTCO_wdt snd soundcore snd_page_alloc i2c_i801 iTCO_vendor_support i2c_core pcs pkr pata_acpi ata_generic ata_piix shpchp mptsas mptscsih mptbase [last unloaded: freq_table]
Pid: 25581, comm: khelper Not tainted 2.6.32.36fixxen #1 Tecal RH2285
RIP: e030:[<ffffffff8103a3cb>]  [<ffffffff8103a3cb>] leave_mm+0x15/0x46
RSP: e02b:ffff88002805be48  EFLAGS: 00010046
RAX: 0000000000000000 RBX: 0000000000000001 RCX: ffff88015f8e2da0
RDX: ffff88002805be78 RSI: 0000000000000000 RDI: 0000000000000001
RBP: ffff88002805be48 R08: ffff88009d662000 R09: dead000000200200
R10: dead000000100100 R11: ffffffff814472b2 R12: ffff88009bfc1880
R13: ffff880028063020 R14: 00000000000004f6 R15: 0000000000000000
FS:  00007f62362d66e0(0000) GS:ffff880028058000(0000) knlGS:0000000000000000
CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000003aabc11909 CR3: 000000009b8ca000 CR4: 0000000000002660
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 00000000000000 00
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process khelper (pid: 25581, threadinfo ffff88007691e000, task ffff88009b92db40)
Stack:
 ffff88002805be68 ffffffff8100e4ae 0000000000000001 ffff88009d733b88
<0> ffff88002805be98 ffffffff81087224 ffff88002805be78 ffff88002805be78
<0> ffff88015f808360 00000000000004f6 ffff88002805bea8 ffffffff81010108
Call Trace:
 <IRQ>
 [<ffffffff8100e4ae>] drop_other_mm_ref+0x2a/0x53
 [<ffffffff81087224>] generic_smp_call_function_single_interrupt+0xd8/0xfc
 [<ffffffff81010108>] xen_call_function_single_interrupt+0x13/0x28
 [<ffffffff810a936a>] handle_IRQ_event+0x66/0x120
 [<ffffffff810aac5b>] handle_percpu_irq+0x41/0x6e
 [<ffffffff8128c1c0>] __xen_evtchn_do_upcall+0x1ab/0x27d
 [<ffffffff8128dd11>] xen_evtchn_do_upcall+0x33/0x46
 [<ffffffff81013efe>] xen_do_hyper visor_callback+0x1e/0x30
 <EOI>
 [<ffffffff814472b2>] ? _spin_unlock_irqrestore+0x15/0x17
 [<ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff81113f71>] ? flush_old_exec+0x3ac/0x500
 [<ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
 [<ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
 [<ffffffff8115115d>] ? load_elf_binary+0x398/0x17ef
 [<ffffffff81042fcf>] ? need_resched+0x23/0x2d
 [<ffffffff811f4648>] ? process_measurement+0xc0/0xd7
 [<ffffffff81150dc5>] ? load_elf_binary+0x0/0x17ef
 [<ffffffff81113094>] ? search_binary_handler+0xc8/0x255
 [<ffffffff81114362>] ? do_execve+0x1c3/0x29e
 [<ffffffff8101155d>] ? sys_execve+0x43/0x5d
 [<ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
 [<ffffffff81013e28>] ? kernel_execve+0x68/0xd0
 [<ffffffff 8106fc45>] ? __call_usermodehelper+0x0/0x6f
 [<ffffffff8100f8cf>] ? xen_restore_fl_direct_end+0x0/0x1
 [<ffffffff8106fb64>] ? ____call_usermodehelper+0x113/0x11e
 [<ffffffff81013daa>] ? child_rip+0xa/0x20
 [<ffffffff8106fc45>] ? __call_usermodehelper+0x0/0x6f
 [<ffffffff81012f91>] ? int_ret_from_sys_call+0x7/0x1b
 [<ffffffff8101371d>] ? retint_restore_args+0x5/0x6
 [<ffffffff81013da0>] ? child_rip+0x0/0x20
Code: 41 5e 41 5f c9 c3 55 48 89 e5 0f 1f 44 00 00 e8 17 ff ff ff c9 c3 55 48 89 e5 0f 1f 44 00 00 65 8b 04 25 c8 55 01 00 ff c8 75 04 <0f> 0b eb fe 65 48 8b 34 25 c0 55 01 00 48 81 c6 b8 02 00 00 e8
RIP  [<ffffffff8103a3cb>] leave_mm+0x15/0x46
 RSP <ffff88002805be48>
---[ end trace ce9cee6832a9c503 ]---

Tested-by: Maoxiaoyun<tinnycloud@hotmail.com>
Signed-off-by: Kevin Tian <kevin.tian@intel.com>
[v1: Fleshed out the git description a bit]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoxen/setup: Ignore E820_UNUSABLE when setting 1-1 mappings.
Konrad Rzeszutek Wilk [Tue, 12 Apr 2011 11:57:15 +0000 (07:57 -0400)]
xen/setup: Ignore E820_UNUSABLE when setting 1-1 mappings.

commit 15bfc094517db2ddf38ca7ed47f3a1c0ad24f7c4 upstream.

When we parse the raw E820, the Xen hypervisor can set "E820_RAM"
to "E820_UNUSABLE" if the mem=X argument is used. As such we
should _not_ consider the E820_UNUSABLE as an 1-1 identity
mapping, but instead use the same case as for E820_RAM.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoxen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit
Daniel Kiper [Wed, 11 May 2011 20:34:38 +0000 (22:34 +0200)]
xen/setup: Fix for incorrect xen_extra_mem_start initialization under 32-bit

commit 0f16d0dfcdb5aab97d9e368f008b070b5b3ec6d3 upstream.

git commit 24bdb0b62cc82120924762ae6bc85afc8c3f2b26 (xen: do not create
the extra e820 region at an addr lower than 4G) does not take into
account that ifdef CONFIG_X86_32 instead of e820_end_of_low_ram_pfn()
find_low_pfn_range() is called (both calls are from arch/x86/kernel/setup.c).
find_low_pfn_range() behaves correctly and does not require change in
xen_extra_mem_start initialization. Additionally, if xen_extra_mem_start
is initialized in the same way as ifdef CONFIG_X86_64 then memory hotplug
support for Xen balloon driver (under development) is broken.

Signed-off-by: Daniel Kiper <dkiper@net-space.pl>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoxen/p2m: Create entries in the P2M_MFN trees's to track 1-1 mappings
Konrad Rzeszutek Wilk [Fri, 1 Apr 2011 19:18:48 +0000 (15:18 -0400)]
xen/p2m: Create entries in the P2M_MFN trees's to track 1-1 mappings

commit 8c5950881c3b5e6e350e4b0438a8ccc513d90df9 upstream.

.. when applicable. We need to track in the p2m_mfn and
p2m_mfn_p the MFNs and pointers, respectivly, for the P2M entries
that are allocated for the identity mappings. Without this,
a PV domain with an E820 that triggers the 1-1 mapping to kick in,
won't be able to be restored as the P2M won't have the identity
mappings.

Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoPCI: Add quirk for setting valid class for TI816X Endpoint
Hemant Pedanekar [Tue, 5 Apr 2011 07:02:50 +0000 (12:32 +0530)]
PCI: Add quirk for setting valid class for TI816X Endpoint

commit 63c4408074cbcc070ac17fc10e524800eb9bd0b0 upstream.

TI816X (common name for DM816x/C6A816x/AM389x family) devices configured
to boot as PCIe Endpoint have class code = 0. This makes kernel PCI bus
code to skip allocating BARs to these devices resulting into following
type of error when trying to enable them:

"Device 0000:01:00.0 not available because of resource collisions"

The device cannot be operated because of the above issue.

This patch adds a ID specific (TI VENDOR ID and 816X DEVICE ID based)
'early' fixup quirk to replace class code with
PCI_CLASS_MULTIMEDIA_VIDEO as class.

Signed-off-by: Hemant Pedanekar <hemantp@ti.com>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agonfs41: Correct offset for LAYOUTCOMMIT
Vitaliy Gusev [Thu, 19 May 2011 21:34:46 +0000 (01:34 +0400)]
nfs41: Correct offset for LAYOUTCOMMIT

commit 4b8ee2b82e8b0b6e17ee33feb74fcdb5c6d8dbdd upstream.

A client sends offset to MDS as it was seen by DS. As result,
file size after copy is only half of original file size in case
of 2 DS.

Signed-off-by: Vitaliy Gusev <gusev.vitaliy@nexenta.com>
Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoNFSv4.1: Fix the handling of NFS4ERR_SEQ_MISORDERED errors
Trond Myklebust [Thu, 26 May 2011 18:26:35 +0000 (14:26 -0400)]
NFSv4.1: Fix the handling of NFS4ERR_SEQ_MISORDERED errors

commit 444f72fe7e7b5f4db34cee933fa3546ebb8e9122 upstream.

Currently, the call to nfs4_schedule_session_recovery() will actually just
result in a test of the lease when what we really want is to force a
session reset.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoNFSv4: Handle expired stateids when the lease is still valid
Trond Myklebust [Thu, 26 May 2011 18:26:35 +0000 (14:26 -0400)]
NFSv4: Handle expired stateids when the lease is still valid

commit 0ced63d1a245ac11241a5d37932e6d04d9c8040d upstream.

Currently, if the server returns NFS4ERR_EXPIRED in reply to a READ or
WRITE, but the RENEW test determines that the lease is still active, we
fail to recover and end up looping forever in a READ/WRITE + RENEW death
spiral.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoSUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback...
Trond Myklebust [Sat, 19 Mar 2011 00:21:23 +0000 (20:21 -0400)]
SUNRPC: Deal with the lack of a SYN_SENT sk->sk_state_change callback...

commit fe19a96b10032035a35779f42ad59e35d6dd8ffd upstream.

The TCP connection state code depends on the state_change() callback
being called when the SYN_SENT state is set. However the networking layer
doesn't actually call us back in that case.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agodrm/radeon/kms: add wait idle ioctl for eg->cayman
Dave Airlie [Thu, 19 May 2011 04:14:43 +0000 (14:14 +1000)]
drm/radeon/kms: add wait idle ioctl for eg->cayman

commit 97bfd0acd32e9639c9136e03955d574655d5cc2b upstream.

None of the latest GPUs had this hooked up, this is necessary for
correct operation in a lot of cases, however we should test this on a few
GPUs in these families as we've had problems in this area before.

Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agodrm/radeon/kms: fix tile_config value reported to userspace on cayman.
Dave Airlie [Thu, 19 May 2011 04:14:41 +0000 (14:14 +1000)]
drm/radeon/kms: fix tile_config value reported to userspace on cayman.

commit cde5083b051e9c66c99a8764aefbc13349e7730d upstream.

cayman is reporting the wrong tile config value to userspace, this
causes piglit mipmap generation tests to fail.

Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agodrm/radeon/kms: fix incorrect comparison in cayman setup code.
Dave Airlie [Thu, 19 May 2011 04:14:40 +0000 (14:14 +1000)]
drm/radeon/kms: fix incorrect comparison in cayman setup code.

commit c289cff10a265ec4afe4396425297ff979a840b5 upstream.

This was leading to a bogus value being programmed to the backend
routing register.

Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agodrm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when asked
Alex Deucher [Thu, 19 May 2011 15:07:57 +0000 (11:07 -0400)]
drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when asked

commit f25a5c63bfa017498c9adecb24d649ae96ba5c68 upstream.

This needs to be explicitly set on btc.  It's set by default
on evergreen/fusion, so it fine to just unconditionally enable it for
all chips.

Signed-off-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agodrm/radeon/cayman: setup hdp to invalidate and flush when asked
Dave Airlie [Thu, 19 May 2011 04:14:42 +0000 (14:14 +1000)]
drm/radeon/cayman: setup hdp to invalidate and flush when asked

commit 0b65f83f9d2fab47b9b6040fe75fc2cfc73032d4 upstream.

On cayman we need to set the bit to cause HDP flushes to invalidate the
HDP cache also.

Reviewed-by: Alex Deucher <alexdeucher@gmail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agodrm/i915: fix user irq miss in BSD ring on g4x
Boqun Feng [Mon, 16 May 2011 08:02:39 +0000 (16:02 +0800)]
drm/i915: fix user irq miss in BSD ring on g4x

commit 5bfa1063a775836a84f97e4df863fc36e1f856ad upstream.

On g4x, user interrupt in BSD ring is missed.
This is because though g4x and ironlake share the same bsd_ring,
their interrupt control interfaces have _two_ differences.

1.different irq enable/disable functions:
On g4x are i915_enable_irq and i915_disable_irq.
On ironlake are ironlake_enable_irq and ironlake_disable_irq.
2.different irq flag:
On g4x user interrupt flag in BSD ring on is I915_BSD_USER_INTERRUPT.
On ironlake is GT_BSD_USER_INTERRUPT

Old bsd_ring_get/put_irq call ring_get_irq and ring_get_irq.
ring_get_irq and ring_put_irq only call ironlake_enable/disable_irq.
So comes the irq miss on g4x.

To fix this, as other rings' code do, conditionally call different
functions(i915_enable/disable_irq and ironlake_enable/disable_irq)
and use different interrupt flags in bsd_ring_get/put_irq.

Signed-off-by: Boqun Feng <boqun.feng@intel.com>
Reviewed-by: Xiang, Haihao <haihao.xiang@intel.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agobrd: handle on-demand devices correctly
Namhyung Kim [Thu, 26 May 2011 19:06:50 +0000 (21:06 +0200)]
brd: handle on-demand devices correctly

commit af46566885a373b0a526932484cd8fef8de7b598 upstream.

When finding or allocating a ram disk device, brd_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example (I set CONFIG_BLK_DEV_RAM_COUNT=4
for simplicity) :

$ sudo modprobe brd max_part=15
$ ls -l /dev/ram*
brw-rw---- 1 root disk 1,  0 2011-05-25 15:41 /dev/ram0
brw-rw---- 1 root disk 1, 16 2011-05-25 15:41 /dev/ram1
brw-rw---- 1 root disk 1, 32 2011-05-25 15:41 /dev/ram2
brw-rw---- 1 root disk 1, 48 2011-05-25 15:41 /dev/ram3
$ sudo mknod /dev/ram4 b 1 64
$ sudo dd if=/dev/zero of=/dev/ram4 bs=4k count=256
256+0 records in
256+0 records out
1048576 bytes (1.0 MB) copied, 0.00215578 s, 486 MB/s
namhyung@leonhard:linux$ ls -l /dev/ram*
brw-rw---- 1 root disk 1,    0 2011-05-25 15:41 /dev/ram0
brw-rw---- 1 root disk 1,   16 2011-05-25 15:41 /dev/ram1
brw-rw---- 1 root disk 1,   32 2011-05-25 15:41 /dev/ram2
brw-rw---- 1 root disk 1,   48 2011-05-25 15:41 /dev/ram3
brw-r--r-- 1 root root 1,   64 2011-05-25 15:45 /dev/ram4
brw-rw---- 1 root disk 1, 1024 2011-05-25 15:44 /dev/ram64

After this patch, /dev/ram4 - instead of /dev/ram64 - was
accessed correctly.

In addition, 'range' passed to blk_register_region() should
include all range of dev_t that RAMDISK_MAJOR can address.
It does not need to be limited by partition numbers unless
'rd_nr' param was specified.

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agobrd: limit 'max_part' module param to DISK_MAX_PARTS
Namhyung Kim [Thu, 26 May 2011 19:06:50 +0000 (21:06 +0200)]
brd: limit 'max_part' module param to DISK_MAX_PARTS

commit 315980c8688c4b06713c1a5fe9d64cdf8ab57a72 upstream.

The 'max_part' parameter controls the number of maximum partition
a brd device can have. However if a user specifies very large
value it would exceed the limitation of device minor number and
can cause a kernel panic (or, at least, produce invalid device
nodes in some cases).

On my desktop system, following command kills the kernel. On qemu,
it triggers similar oops but the kernel was alive:

$ sudo modprobe brd max_part=100000
 BUG: unable to handle kernel NULL pointer dereference at 0000000000000058
 IP: [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
 PGD 7af1067 PUD 7b19067 PMD 0
 Oops: 0000 [#1] SMP
 last sysfs file:
 CPU 0
 Modules linked in: brd(+)

 Pid: 44, comm: insmod Tainted: G        W   2.6.39-qemu+ #158 Bochs Bochs
 RIP: 0010:[<ffffffff81110a9a>]  [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
 RSP: 0018:ffff880007b15d78  EFLAGS: 00000286
 RAX: ffff880007b05478 RBX: ffff880007a52760 RCX: ffff880007b15dc8
 RDX: ffff880007a4f900 RSI: ffff880007b15e48 RDI: ffff880007a52760
 RBP: ffff880007b15da8 R08: 0000000000000002 R09: 0000000000000000
 R10: ffff880007b15e48 R11: ffff880007b05478 R12: 0000000000000000
 R13: ffff880007b05478 R14: 0000000000400920 R15: 0000000000000063
 FS:  0000000002160880(0063) GS:ffff880007c00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000058 CR3: 0000000007b1c000 CR4: 00000000000006b0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
 Process insmod (pid: 44, threadinfo ffff880007b14000, task ffff880007acb980)
 Stack:
  ffff880007b15dc8 ffff880007b05478 ffff880007b15da8 00000000fffffffe
  ffff880007a52760 ffff880007b05478 ffff880007b15de8 ffffffff81143c0a
  0000000000400920 ffff880007a52760 ffff880007b05478 0000000000000000
 Call Trace:
  [<ffffffff81143c0a>] kobject_add_internal+0xdf/0x1a0
  [<ffffffff81143da1>] kobject_add_varg+0x41/0x50
  [<ffffffff81143e6b>] kobject_add+0x64/0x66
  [<ffffffff8113bbe7>] blk_register_queue+0x5f/0xb8
  [<ffffffff81140f72>] add_disk+0xdf/0x289
  [<ffffffffa00040df>] brd_init+0xdf/0x1aa [brd]
  [<ffffffffa0004000>] ? 0xffffffffa0003fff
  [<ffffffffa0004000>] ? 0xffffffffa0003fff
  [<ffffffff8100020a>] do_one_initcall+0x7a/0x12e
  [<ffffffff8108516c>] sys_init_module+0x9c/0x1dc
  [<ffffffff812ff4bb>] system_call_fastpath+0x16/0x1b
 Code: 89 e5 41 55 41 54 53 48 89 fb 48 83 ec 18 48 85 ff 75 04 0f 0b eb fe 48 8b 47 18 49 c7 c4 70 1e 4d 81 48 85 c0 74 04 4c 8b 60 30
  8b 44 24 58 45 31 ed 0f b6 c4 85 c0 74 0d 48 8b 43 28 48 89
 RIP  [<ffffffff81110a9a>] sysfs_create_dir+0x2d/0xae
  RSP <ffff880007b15d78>
 CR2: 0000000000000058
 ---[ end trace aebb1175ce1f6739 ]---

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoatm: expose ATM device index in sysfs
Dan Williams [Fri, 27 May 2011 04:51:54 +0000 (04:51 +0000)]
atm: expose ATM device index in sysfs

commit e7a46b4d0839c2a3aa2e0ae0b145f293f6738498 upstream.

It's currently exposed only through /proc which, besides requiring
screen-scraping, doesn't allow userspace to distinguish between two
identical ATM adapters with different ATM indexes.  The ATM device index
is required when using PPPoATM on a system with multiple ATM adapters.

Signed-off-by: Dan Williams <dcbw@redhat.com>
Reviewed-by: Eric Dumazet <eric.dumazet@gmail.com>
Tested-by: David Woodhouse <dwmw2@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agotmpfs: fix race between truncate and writepage
Hugh Dickins [Sat, 28 May 2011 20:14:09 +0000 (13:14 -0700)]
tmpfs: fix race between truncate and writepage

commit 826267cf1e6c6899eda1325a19f1b1d15c558b20 upstream.

While running fsx on tmpfs with a memhog then swapoff, swapoff was hanging
(interruptibly), repeatedly failing to locate the owner of a 0xff entry in
the swap_map.

Although shmem_writepage() does abandon when it sees incoming page index
is beyond eof, there was still a window in which shmem_truncate_range()
could come in between writepage's dropping lock and updating swap_map,
find the half-completed swap_map entry, and in trying to free it,
leave it in a state that swap_shmem_alloc() could not correct.

Arguably a bug in __swap_duplicate()'s and swap_entry_free()'s handling
of the different cases, but easiest to fix by moving swap_shmem_alloc()
under cover of the lock.

More interesting than the bug: it's been there since 2.6.33, why could
I not see it with earlier kernels?  The mmotm of two weeks ago seems to
have some magic for generating races, this is just one of three I found.

With yesterday's git I first saw this in mainline, bisected in search of
that magic, but the easy reproducibility evaporated.  Oh well, fix the bug.

Signed-off-by: Hugh Dickins <hughd@google.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dcache_area
Will Deacon [Thu, 26 May 2011 10:20:19 +0000 (11:20 +0100)]
ARM: 6941/1: cache: ensure MVA is cacheline aligned in flush_kern_dcache_area

commit a248b13b21ae00b97638b4f435c8df3075808b5d upstream.

The v6 and v7 implementations of flush_kern_dcache_area do not align
the passed MVA to the size of a cacheline in the data cache. If a
misaligned address is used, only a subset of the requested area will
be flushed. This has been observed to cause failures in SMP boot where
the secondary_data initialised by the primary CPU is not cacheline
aligned, causing the secondary CPUs to read incorrect values for their
pgd and stack pointers.

This patch ensures that the base address is cacheline aligned before
flushing the d-cache.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agodm mpath: do not fail paths after integrity errors
Martin K. Petersen [Sun, 29 May 2011 12:02:55 +0000 (13:02 +0100)]
dm mpath: do not fail paths after integrity errors

commit 6f13f6fba76edc7d0e7580c5deee829d59a41b2f upstream.

Integrity errors need to be passed to the owner of the integrity
metadata for processing. Consequently EILSEQ should be passed up the
stack.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agodm table: reject devices without request fns
Milan Broz [Sun, 29 May 2011 12:02:52 +0000 (13:02 +0100)]
dm table: reject devices without request fns

commit f4808ca99a203f20b4475601748e44b25a65bdec upstream.

This patch adds a check that a block device has a request function
defined before it is used.  Otherwise, misconfiguration can cause an oops.

Because we are allowing devices with zero size e.g. an offline multipath
device as in commit 2cd54d9bedb79a97f014e86c0da393416b264eb3
("dm: allow offline devices") there needs to be an additional check
to ensure devices are initialised.  Some block devices, like a loop
device without a backing file, exist but have no request function.

Reproducer is trivial: dm-mirror on unbound loop device
(no backing file on loop devices)

dmsetup create x --table "0 8 mirror core 2 8 sync 2 /dev/loop0 0 /dev/loop1 0"

and mirror resync will immediatelly cause OOps.

BUG: unable to handle kernel NULL pointer dereference at   (null)
 ? generic_make_request+0x2bd/0x590
 ? kmem_cache_alloc+0xad/0x190
 submit_bio+0x53/0xe0
 ? bio_add_page+0x3b/0x50
 dispatch_io+0x1ca/0x210 [dm_mod]
 ? read_callback+0x0/0xd0 [dm_mirror]
 dm_io+0xbb/0x290 [dm_mod]
 do_mirror+0x1e0/0x748 [dm_mirror]

Signed-off-by: Milan Broz <mbroz@redhat.com>
Reported-by: Zdenek Kabelac <zkabelac@redhat.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoidle governor: Avoid lock acquisition to read pm_qos before entering idle
Tim Chen [Fri, 11 Feb 2011 20:49:04 +0000 (12:49 -0800)]
idle governor: Avoid lock acquisition to read pm_qos before entering idle

commit 333c5ae9948194428fe6c5ef5c088304fc98263b upstream.

Thanks to the reviews and comments by Rafael, James, Mark and Andi.
Here's version 2 of the patch incorporating your comments and also some
update to my previous patch comments.

I noticed that before entering idle state, the menu idle governor will
look up the current pm_qos target value according to the list of qos
requests received.  This look up currently needs the acquisition of a
lock to access the list of qos requests to find the qos target value,
slowing down the entrance into idle state due to contention by multiple
cpus to access this list.  The contention is severe when there are a lot
of cpus waking and going into idle.  For example, for a simple workload
that has 32 pair of processes ping ponging messages to each other, where
64 cpu cores are active in test system, I see the following profile with
37.82% of cpu cycles spent in contention of pm_qos_lock:

-     37.82%          swapper  [kernel.kallsyms]          [k]
_raw_spin_lock_irqsave
   - _raw_spin_lock_irqsave
      - 95.65% pm_qos_request
           menu_select
           cpuidle_idle_call
         - cpu_idle
              99.98% start_secondary

A better approach will be to cache the updated pm_qos target value so
reading it does not require lock acquisition as in the patch below.
With this patch the contention for pm_qos_lock is removed and I saw a
2.2X increase in throughput for my message passing workload.

Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com>
Acked-by: Andi Kleen <ak@linux.intel.com>
Acked-by: James Bottomley <James.Bottomley@suse.de>
Acked-by: mark gross <markgross@thegnar.org>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agocpuidle: menu: fixed wrapping timers at 4.294 seconds
Tero Kristo [Thu, 24 Feb 2011 15:19:23 +0000 (17:19 +0200)]
cpuidle: menu: fixed wrapping timers at 4.294 seconds

commit 7467571f4480b273007517b26297c07154c73924 upstream.

Cpuidle menu governor is using u32 as a temporary datatype for storing
nanosecond values which wrap around at 4.294 seconds. This causes errors
in predicted sleep times resulting in higher than should be C state
selection and increased power consumption. This also breaks cpuidle
state residency statistics.

Signed-off-by: Tero Kristo <tero.kristo@nokia.com>
Signed-off-by: Len Brown <len.brown@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agohwmon: (pmbus) Initialize sysfs attributes
Guenter Roeck [Tue, 24 May 2011 19:16:40 +0000 (12:16 -0700)]
hwmon: (pmbus) Initialize sysfs attributes

commit eec752b2b99c794766926a9bac59b0d7df5b09c2 upstream.

Initialize sysfs attrs before device_create_file() call to suppress
lockdep_init_map() warning:

WARNING: at kernel/lockdep.c:2701 lockdep_init_map+0x12d/0x140()

Reviewed-by: Robert Coulson <robert.coulson@ericsson.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoi8k: Avoid lahf in 64-bit code
Luca Tettamanti [Wed, 25 May 2011 18:43:31 +0000 (20:43 +0200)]
i8k: Avoid lahf in 64-bit code

commit bc1f419c76a2d6450413ce4349f4e4a07be011d5 upstream.

i8k uses lahf to read the flag register in 64-bit code; early x86-64
CPUs, however, lack this instruction and we get an invalid opcode
exception at runtime.
Use pushf to load the flag register into the stack instead.

Signed-off-by: Luca Tettamanti <kronos.it@gmail.com>
Reported-by: Jeff Rickman <jrickman@myamigos.us>
Tested-by: Jeff Rickman <jrickman@myamigos.us>
Tested-by: Harry G McGavran Jr <w5pny@arrl.net>
Cc: Massimo Dal Zotto <dz@debian.org>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoSet cred->user_ns in key_replace_session_keyring
Serge E. Hallyn [Thu, 26 May 2011 20:25:05 +0000 (15:25 -0500)]
Set cred->user_ns in key_replace_session_keyring

commit f7285b5d631fd6096b11c6af0058ed3a2b30ef4e upstream.

Since this cred was not created with copy_creds(), it needs to get
initialized.  Otherwise use of syscall(__NR_keyctl, KEYCTL_SESSION_TO_PARENT);
can lead to a NULL deref.  Thanks to Robert for finding this.

But introduced by commit 47a150edc2a ("Cache user_ns in struct cred").

Signed-off-by: Serge E. Hallyn <serge.hallyn@canonical.com>
Reported-by: Robert Święcki <robert@swiecki.net>
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agokbuild: Fix GNU make v3.80 compatibility
Kevin Cernekee [Tue, 10 May 2011 22:47:16 +0000 (15:47 -0700)]
kbuild: Fix GNU make v3.80 compatibility

commit 43f67c98161c65f1b2e3af3a9ce6741850072c06 upstream.

According to Documentation/Changes, the kernel should be buildable with
GNU make 3.80+.  Commit 88d7be031f9f975bb3f50a0b5ef3796a671e7edf (kbuild:
Use a single clean rule for kernel and external modules) introduced the
"$(or" construct, which requires make 3.81.  This causes "make clean" to
malfunction when it is used with external modules.

Replace "$(or" with an equivalent "$(if" expression, to restore backward
compatibility.

Signed-off-by: Kevin Cernekee <cernekee@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoUBIFS: fix a rare memory leak in ro to rw remounting path
Artem Bityutskiy [Fri, 6 May 2011 14:08:56 +0000 (17:08 +0300)]
UBIFS: fix a rare memory leak in ro to rw remounting path

commit eaeee242c531cd4b0a4a46e8b5dd7ef504380c42 upstream.

When re-mounting from R/O mode to R/W mode and the LEB count in the superblock
is not up-to date, because for the underlying UBI volume became larger, we
re-write the superblock. We allocate RAM for these purposes, but never free it.
So this is a memory leak, although very rare one.

Signed-off-by: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoeCryptfs: Allow 2 scatterlist entries for encrypted filenames
Tyler Hicks [Tue, 17 May 2011 05:50:33 +0000 (00:50 -0500)]
eCryptfs: Allow 2 scatterlist entries for encrypted filenames

commit 8d08dab786ad5cc2aca2bf870de370144b78c85a upstream.

The buffers allocated while encrypting and decrypting long filenames can
sometimes straddle two pages. In this situation, virt_to_scatterlist()
will return -ENOMEM, causing the operation to fail and the user will get
scary error messages in their logs:

kernel: ecryptfs_write_tag_70_packet: Internal error whilst attempting
to convert filename memory to scatterlist; expected rc = 1; got rc =
[-12]. block_aligned_filename_size = [272]
kernel: ecryptfs_encrypt_filename: Error attempting to generate tag 70
packet; rc = [-12]
kernel: ecryptfs_encrypt_and_encode_filename: Error attempting to
encrypt filename; rc = [-12]
kernel: ecryptfs_lookup: Error attempting to encrypt and encode
filename; rc = [-12]

The solution is to allow up to 2 scatterlist entries to be used.

Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoeCryptfs: Clear i_nlink in rmdir
Tyler Hicks [Fri, 29 Apr 2011 21:26:27 +0000 (16:26 -0500)]
eCryptfs: Clear i_nlink in rmdir

commit 07850552b92b3637fa56767b5e460b4238014447 upstream.

eCryptfs wasn't clearing the eCryptfs inode's i_nlink after a successful
vfs_rmdir() on the lower directory. This resulted in the inode evict and
destroy paths to be missed.

https://bugs.launchpad.net/ecryptfs/+bug/723518

Signed-off-by: Tyler Hicks <tyhicks@linux.vnet.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agop54usb: add zoom 4410 usbid
Christian Lamparter [Fri, 13 May 2011 19:47:23 +0000 (21:47 +0200)]
p54usb: add zoom 4410 usbid

commit 9368a9a2378ab721f82f59430a135b4ce4ff5109 upstream.

Reported-by: Mark Davis <marked86@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agomfd: Fix omap usbhs crash when rmmoding ehci or ohci
Keshava Munegowda [Mon, 16 May 2011 08:54:58 +0000 (14:24 +0530)]
mfd: Fix omap usbhs crash when rmmoding ehci or ohci

commit 6eb6fbbf3eca6dfba73e72de5ab2eeb52ae41f7a upstream.

The disabling of clocks and freeing GPIO are changed
to fix the occurrence of the crash of rmmod of ehci and ohci
drivers. The GPIOs should be freed after the spin locks are
unlocked.

Signed-off-by: Keshava Munegowda <keshava_mgowda@ti.com>
Acked-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agosh: fixup fpu.o compile order
Kuninori Morimoto [Fri, 15 Apr 2011 07:44:27 +0000 (16:44 +0900)]
sh: fixup fpu.o compile order

commit a375b15164dd9264f724ad941825e52c90145151 upstream.

arch_ptrace() was modified to reference init_fpu() to fix up xstate
initialization, which overlooked the fact that there are configurations
that don't enable any of hard FPU support or emulation, resulting in
build errors on DSP parts.

Given that init_fpu() simply sets up the xstate slab cache and is
side-stepped entirely for the DSP case, we can simply always build in the
helper and fix up the references.

Reported-by: Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agosh: clkfwk: fixup clk_rate_table_build parameter in div6 clock
Kuninori Morimoto [Thu, 14 Apr 2011 08:13:53 +0000 (17:13 +0900)]
sh: clkfwk: fixup clk_rate_table_build parameter in div6 clock

commit 52c10ad22b7e317960b4d411c9a9ddeaf3d5ae39 upstream.

div6 clock should not use arch_flags for clk_rate_table_build,
because SH_CLK_DIV6_EXT doesn't care .arch_flags.
clk->freq_table[] will be all CPUFREQ_ENTRY_INVALID without this patch.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agocx88: hold device lock during sub-driver initialization
Jonathan Nieder [Sun, 1 May 2011 09:29:56 +0000 (06:29 -0300)]
cx88: hold device lock during sub-driver initialization

commit 1d6213ab995c61f7d1d81cf6cf876acf15d6e714 upstream.

cx8802_blackbird_probe makes a device node for the mpeg sub-device
before it has been added to dev->drvlist.  If the device is opened
during that time, the open succeeds but request_acquire cannot be
called, so the reference count remains zero.  Later, when the device
is closed, the reference count becomes negative --- uh oh.

Close the race by holding core->lock during probe and not releasing
until the device is in drvlist and initialization finished.
Previously the BKL prevented this race.

Reported-by: Andreas Huber <hobrom@gmx.at>
Tested-by: Andi Huber <hobrom@gmx.at>
Tested-by: Marlon de Boer <marlon@hyves.nl>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agocx88: fix locking of sub-driver operations
Jonathan Nieder [Sun, 1 May 2011 09:29:37 +0000 (06:29 -0300)]
cx88: fix locking of sub-driver operations

commit 1fe70e963028f34ba5e32488a7870ff4b410b19b upstream.

The BKL conversion of this driver seems to have gone wrong.
Loading the cx88-blackbird driver deadlocks.

The cause: mpeg_ops::open in the cx2388x blackbird driver acquires the
device lock and calls the sub-driver's request_acquire, which tries to
acquire the lock again.  Fix it by clarifying the semantics of
request_acquire, request_release, advise_acquire, and advise_release:
now all will rely on the caller to acquire the device lock.

Based on work by Ben Hutchings <ben@decadent.org.uk>.

Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=31962

Reported-by: Andi Huber <hobrom@gmx.at>
Tested-by: Andi Huber <hobrom@gmx.at>
Tested-by: Marlon de Boer <marlon@hyves.nl>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agocx88: protect per-device driver list with device lock
Jonathan Nieder [Sun, 1 May 2011 09:29:16 +0000 (06:29 -0300)]
cx88: protect per-device driver list with device lock

commit 8a317a8760cfffa8185b56ff59fb4b6c58488d79 upstream.

The BKL conversion of this driver seems to have gone wrong.  Various
uses of the sub-device and driver lists appear to be subject to race
conditions.

In particular, some functions access drvlist without a relevant lock
held, which will race against removal of drivers.  Let's start with
that --- clean up by consistently protecting dev->drvlist with
dev->core->lock, noting driver functions that require the device lock
to be held or not to be held.

After this patch, there are still some races --- e.g.,
cx8802_blackbird_remove can run between the time the blackbird driver
is acquired and the time it is used in mpeg_release, and there's a
similar race in cx88_dvb_bus_ctrl.  Later patches will address the
remaining known races and the deadlock noticed by Andi.  This patch
just makes the semantics clearer in preparation for those later
changes.

Based on work by Ben Hutchings <ben@decadent.org.uk>.

Tested-by: Andi Huber <hobrom@gmx.at>
Tested-by: Marlon de Boer <marlon@hyves.nl>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoDiBxxxx: get rid of DMA buffer on stack
Olivier Grenie [Tue, 3 May 2011 15:27:33 +0000 (12:27 -0300)]
DiBxxxx: get rid of DMA buffer on stack

commit 5a0deeed5741117ee8625d6305d0034e219f102c upstream.

This patch removes the remaining on-stack buffer for USB DMA transfer.
This patch also reduces the stack memory usage.

Cc: Florian Mickler <florian@mickler.org>
Signed-off-by: Olivier Grenie <olivier.grenie@dibcom.fr>
Signed-off-by: Patrick Boettcher <patrick.boettcher@dibcom.fr>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoUSB: remove remaining usages of hcd->state from usbcore and fix regression
Alan Stern [Tue, 17 May 2011 21:27:12 +0000 (17:27 -0400)]
USB: remove remaining usages of hcd->state from usbcore and fix regression

commit 69fff59de4d844f8b4c2454c3c23d32b69dcbfd7 upstream.

This patch (as1467) removes the last usages of hcd->state from
usbcore.  We no longer check to see if an interrupt handler finds that
a controller has died; instead we rely on host controller drivers to
make an explicit call to usb_hc_died().

This fixes a regression introduced by commit
9b37596a2e860404503a3f2a6513db60c296bfdc (USB: move usbcore away from
hcd->state).  It used to be that when a controller shared an IRQ with
another device and an interrupt arrived while hcd->state was set to
HC_STATE_HALT, the interrupt handler would be skipped.  The commit
removed that test; as a result the current code doesn't skip calling
the handler and ends up believing the controller has died, even though
it's only temporarily stopped.  The solution is to ignore HC_STATE_HALT
following the handler's return.

As a consequence of this change, several of the host controller
drivers need to be modified.  They can no longer implicitly rely on
usbcore realizing that a controller has died because of hcd->state.
The patch adds calls to usb_hc_died() in the appropriate places.

The patch also changes a few of the interrupt handlers.  They don't
expect to be called when hcd->state is equal to HC_STATE_HALT, even if
the controller is still alive.  Early returns were added to avoid any
confusion.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Manuel Lauss <manuel.lauss@googlemail.com>
CC: Rodolfo Giometti <giometti@linux.it>
CC: Olav Kongas <ok@artecdesign.ee>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoOHCI: fix regression caused by nVidia shutdown workaround
Alan Stern [Mon, 16 May 2011 16:15:19 +0000 (12:15 -0400)]
OHCI: fix regression caused by nVidia shutdown workaround

commit 2b7aaf503d56216b847c8265421d2a7d9b42df3e upstream.

This patch (as1463) fixes a regression caused by commit
3df7169e73fc1d71a39cffeacc969f6840cdf52b (OHCI: work around for nVidia
shutdown problem).

The original problem encountered by people using NVIDIA chipsets was
that USB devices were not turning off when the system shut down.  For
example, the LED on an optical mouse would remain on, draining a
laptop's battery.  The problem was caused by a bug in the chipset; an
OHCI controller in the Reset state would continue to drive a bus reset
signal even after system shutdown.  The workaround was to put the
controllers into the Suspend state instead.

It turns out that later NVIDIA chipsets do not suffer from this bug.
Instead some have the opposite bug: If a system is shut down while an
OHCI controller is in the Suspend state, USB devices remain powered!
On other systems, shutting down with a Suspended controller causes the
system to reboot immediately.  Thus, working around the original bug
on some machines exposes other bugs on other machines.

The best solution seems to be to limit the workaround to OHCI
controllers with a low-numbered PCI product ID.  I don't know exactly
at what point NVIDIA changed their chipsets; the value used here is a
guess.  So far it was worked out okay for all the people who have
tested it.

This fixes Bugzilla #35032.

Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Tested-by: Andre "Osku" Schmidt <andre.osku.schmidt@googlemail.com>
Tested-by: Yury Siamashka <yurand2@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoUSB: option: add support for Huawei E353 device
Marcin Gałczyński [Sun, 15 May 2011 09:41:54 +0000 (11:41 +0200)]
USB: option: add support for Huawei E353 device

commit 610ba42f29c3dfa46a05ff8c2cadc29f544ff76d upstream.

I am sharing patch to the devices/usb/serial/option.c. This allows
operation of Huawei E353 broadband modem using the “option” driver. The
patch simply adds new constant with proper product ID and an entry to
usb_device_id. I worked on the 2.6.38.6 sources. Tested on Dell inspiron
1764 (i3 core cpu) and brand new Huawei E353 modem, Fedora 15 beta.

Looking at the type of change, i doubt it has potential to introduce
problems in other parts of kernel or the driver itself.

Signed-off-by: Marcin Galczynski <marcin@galczynski.pl>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoxhci: Fix memory leak bug when dropping endpoints
Sarah Sharp [Fri, 13 May 2011 01:06:37 +0000 (18:06 -0700)]
xhci: Fix memory leak bug when dropping endpoints

commit 834cb0fc4712a3b21c6b8c5cb55bd13607191311 upstream.

When the USB core wants to change to an alternate interface setting that
doesn't include an active endpoint, or de-configuring the device, the xHCI
driver needs to issue a Configure Endpoint command to tell the host to
drop some endpoints from the schedule.  After the command completes, the
xHCI driver needs to free rings for any endpoints that were dropped.

Unfortunately, the xHCI driver wasn't actually freeing the endpoint rings
for dropped endpoints.  The rings would be freed if the endpoint's
information was simply changed (and a new ring was installed), but dropped
endpoints never had their rings freed.  This caused errors when the ring
segment DMA pool was freed when the xHCI driver was unloaded:

[ 5582.883995] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff88003371d000 busy
[ 5582.884002] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033716000 busy
[ 5582.884011] xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880033455000 busy
[ 5582.884018] xhci_hcd 0000:06:00.0: Freed segment pool
[ 5582.884026] xhci_hcd 0000:06:00.0: Freed device context pool
[ 5582.884033] xhci_hcd 0000:06:00.0: Freed small stream array pool
[ 5582.884038] xhci_hcd 0000:06:00.0: Freed medium stream array pool
[ 5582.884048] xhci_hcd 0000:06:00.0: xhci_stop completed - status = 1
[ 5582.884061] xhci_hcd 0000:06:00.0: USB bus 3 deregistered
[ 5582.884193] xhci_hcd 0000:06:00.0: PCI INT A disabled

Fix this issue and free endpoint rings when their endpoints are
successfully dropped.

This patch should be backported to kernels as old as 2.6.31.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoxhci: Fix memory leak in ring cache deallocation.
Sarah Sharp [Mon, 16 May 2011 20:09:08 +0000 (13:09 -0700)]
xhci: Fix memory leak in ring cache deallocation.

commit 30f89ca021c3e584b61bc5a14eede89f74b2e826 upstream.

When an endpoint ring is freed, it is either cached in a per-device ring
cache, or simply freed if the ring cache is full.  If the ring was added
to the cache, then virt_dev->num_rings_cached is incremented.  The cache
is designed to hold up to 31 endpoint rings, in array indexes 0 to 30.
When the device is freed (when the slot was disabled),
xhci_free_virt_device() is called, it would free the cached rings in
array indexes 0 to virt_dev->num_rings_cached.

Unfortunately, the original code in xhci_free_or_cache_endpoint_ring()
would put the first entry into the ring cache in array index 1, instead of
array index 0.  This was caused by the second assignment to rings_cached:

rings_cached = virt_dev->num_rings_cached;
if (rings_cached < XHCI_MAX_RINGS_CACHED) {
virt_dev->num_rings_cached++;
rings_cached = virt_dev->num_rings_cached;
virt_dev->ring_cache[rings_cached] =
virt_dev->eps[ep_index].ring;

This meant that when the device was freed, cached rings with indexes 0 to
N would be freed, and the last cached ring in index N+1 would not be
freed.  When the driver was unloaded, this caused interesting messages
like:

xhci_hcd 0000:06:00.0: dma_pool_destroy xHCI ring segments, ffff880063040000 busy

This should be queued to stable kernels back to 2.6.33.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoxhci: Fix full speed bInterval encoding.
Sarah Sharp [Fri, 13 May 2011 20:10:01 +0000 (13:10 -0700)]
xhci: Fix full speed bInterval encoding.

commit b513d44751bfb609a3c20463f764c8ce822d63e9 upstream.

Dmitry's patch

dfa49c4ad120a784ef1ff0717168aa79f55a483a USB: xhci - fix math in xhci_get_endpoint_interval()

introduced a bug.  The USB 2.0 spec says that full speed isochronous endpoints'
bInterval must be decoded as an exponent to a power of two (e.g. interval =
2^(bInterval - 1)).  Full speed interrupt endpoints, on the other hand, don't
use exponents, and the interval in frames is encoded straight into bInterval.

Dmitry's patch was supposed to fix up the full speed isochronous to parse
bInterval as an exponent, but instead it changed the *interrupt* endpoint
bInterval decoding.  The isochronous endpoint encoding was the same.

This caused full speed devices with interrupt endpoints (including mice, hubs,
and USB to ethernet devices) to fail under NEC 0.96 xHCI host controllers:

[  100.909818] xhci_hcd 0000:06:00.0: add ep 0x83, slot id 1, new drop flags = 0x0, new add flags = 0x99, new slot info = 0x38100000
[  100.909821] xhci_hcd 0000:06:00.0: xhci_check_bandwidth called for udev ffff88011f0ea000
...
[  100.910187] xhci_hcd 0000:06:00.0: ERROR: unexpected command completion code 0x11.
[  100.910190] xhci_hcd 0000:06:00.0: xhci_reset_bandwidth called for udev ffff88011f0ea000

When the interrupt endpoint was added and a Configure Endpoint command was
issued to the host, the host controller would return a very odd error message
(0x11 means "Slot Not Enabled", which isn't true because the slot was enabled).
Probably the host controller was getting very confused with the bad encoding.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dtor@vmware.com>
Reported-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Tested-by: Thomas Lindroth <thomas.lindroth@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agousb: gadget: rndis: don't test against req->length
Felipe Balbi [Fri, 13 May 2011 13:53:48 +0000 (16:53 +0300)]
usb: gadget: rndis: don't test against req->length

commit 472b91274a6c6857877b5caddb875dcb5ecdfcb8 upstream.

composite.c always sets req->length to zero
and expects function driver's setup handlers
to return the amount of bytes to be used
on req->length. If we test against req->length
w_length will always be greater than req->length
thus making us always stall that particular
SEND_ENCAPSULATED_COMMAND request.

Tested against a Windows XP SP3.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agousb/gadget: at91sam9g20 fix end point max packet size
Jean-Christophe PLAGNIOL-VILLARD [Fri, 13 May 2011 15:03:02 +0000 (17:03 +0200)]
usb/gadget: at91sam9g20 fix end point max packet size

commit bf1f0a05d472e33dda8e5e69525be1584cdbd03a upstream.

on 9g20 they are the same as the 9260

Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoxhci: Fix bug in control transfer cancellation.
Sarah Sharp [Fri, 6 May 2011 02:08:09 +0000 (19:08 -0700)]
xhci: Fix bug in control transfer cancellation.

commit 3abeca998a44205cfd837fa0bf1f7c24f8294acb upstream.

When the xHCI driver attempts to cancel a transfer, it issues a Stop
Endpoint command and waits for the host controller to indicate which TRB
it was in the middle of processing.  The host will put an event TRB with
completion code COMP_STOP on the event ring if it stops on a control
transfer TRB (or other types of transfer TRBs).  The ring handling code
is supposed to set ep->stopped_trb to the TRB that the host stopped on
when this happens.

Unfortunately, there is a long-standing bug in the control transfer
completion code.  It doesn't actually check to see if COMP_STOP is set
before attempting to process the transfer based on which part of the
control TD completed.  So when we get an event on the data phase of the
control TRB with COMP_STOP set, it thinks it's a normal completion of
the transfer and doesn't set ep->stopped_td or ep->stopped_trb.

When the ring handling code goes on to process the completion of the Stop
Endpoint command, it sees that ep->stopped_trb is not a part of the TD
it's trying to cancel.  It thinks the hardware has its enqueue pointer
somewhere further up in the ring, and thinks it's safe to turn the control
TRBs into no-op TRBs.  Since the hardware was in the middle of the control
TRBs to be cancelled, the proper software behavior is to issue a Set TR
dequeue pointer command.

It turns out that the NEC host controllers can handle active TRBs being
set to no-op TRBs after a stop endpoint command, but other host
controllers have issues with this out-of-spec software behavior.  Fix this
behavior.

This patch should be backported to kernels as far back as 2.6.31, but it
may be a bit challenging, since process_ctrl_td() was introduced in some
refactoring done in 2.6.36, and some endian-safe patches added in 2.6.40
that touch the same lines.

Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoUSB: cdc_acm: Fix oops when Droids MuIn LCD is connected
Erik Slagter [Wed, 11 May 2011 10:06:55 +0000 (12:06 +0200)]
USB: cdc_acm: Fix oops when Droids MuIn LCD is connected

commit fd5054c169d29747a44b4e1419ff47f57ae82dbc upstream.

The Droids MuIn LCD operates like a serial remote terminal.
Data received are displayed directly on the LCD. This patch
fixes the kernel null pointer oops when it is plugged in.

Add NO_DATA_INTERFACE quirk to tell the driver that "control"
and "data" interfaces are not separated for this device, which
prevents dereferencing a null pointer in the device probe code.

Signed-off-by: Erik Slagter <erik@slagter.name>
Signed-off-by: Maxin B. John <maxin.john@gmail.com>
Tested-by: Erik Slagter <erik@slagter.name>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoBind only modem AT command endpoint to option module.
Marius B. Kotsbak [Mon, 21 Mar 2011 22:27:21 +0000 (23:27 +0100)]
Bind only modem AT command endpoint to option module.

commit 15b2f3204a5c878c32939094775fb7349f707263 upstream.

Network interface is handled by upcoming gt_b3730 module.

Removed "GT-B3710" from comment, it is another modem with another USB ID.

Signed-off-by: Marius B. Kotsbak <marius@kotsbak.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoUSB: gamin_gps: Fix for data transfer problems in native mode
Hermann Kneissel [Fri, 29 Apr 2011 06:58:43 +0000 (08:58 +0200)]
USB: gamin_gps: Fix for data transfer problems in native mode

commit b4026c4584cd70858d4d3450abfb1cd0714d4f32 upstream.

This patch fixes a problem where data received from the gps is sometimes
transferred incompletely to the serial port. If used in native mode now
all data received via the bulk queue will be forwarded to the serial
port.

Signed-off-by: Hermann Kneissel <herkne@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoUSB: gadget: g_multi: fixed vendor and product ID in inf files
Michal Nazarewicz [Tue, 26 Apr 2011 17:08:36 +0000 (19:08 +0200)]
USB: gadget: g_multi: fixed vendor and product ID in inf files

commit 7701846fd52f86dffe50715e0e63154088b7c982 upstream.

Commit 1c6529e92b "USB: gadget: g_multi: fixed vendor and
product ID" replaced g_multi's vendor and product ID with
proper ID's from Linux Foundation.  This commit now updates
INF files in the Documentation/usb directory which were
omitted in the original commit.

Signed-off-by: Michal Nazarewicz <mina86@mina86.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoUSB: serial: ftdi_sio: adding support for TavIR STK500
Benedek László [Wed, 20 Apr 2011 01:22:21 +0000 (03:22 +0200)]
USB: serial: ftdi_sio: adding support for TavIR STK500

commit 37909fe588c9e09ab57cd267e98678a17ceda64a upstream.

Adding support for the TavIR STK500 (id 0403:FA33)
Atmel AVR programmer device based on FTDI FT232RL.

Signed-off-by: Benedek László <benedekl@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoUSB: moto_modem: Add USB identifier for the Motorola VE240.
Elizabeth Jennifer Myers [Sat, 16 Apr 2011 18:49:51 +0000 (14:49 -0400)]
USB: moto_modem: Add USB identifier for the Motorola VE240.

commit 3938a0b32dc12229e76735679b37095bc2bc1578 upstream.

Tested on my phone, the ttyUSB device is created and is fully
functional.

Signed-off-by: Elizabeth Jennifer Myers <elizabeth@sporksirc.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoUSB: CP210x Add 4 Device IDs for AC-Services Devices
Craig Shelley [Sun, 20 Mar 2011 13:51:13 +0000 (13:51 +0000)]
USB: CP210x Add 4 Device IDs for AC-Services Devices

commit 4eff0b40a7174896b860312910e0db51f2dcc567 upstream.

This patch adds 4 device IDs for CP2102 based devices manufactured by
AC-Services. See http://www.ac-services.eu for further info.

Signed-off-by: Craig Shelley <craig@microtron.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoi2c/writing-clients: Fix foo_driver.id_table
Vikram Narayanan [Tue, 24 May 2011 18:58:48 +0000 (20:58 +0200)]
i2c/writing-clients: Fix foo_driver.id_table

commit 3116c86033079a1d4d4e84c40028f96b614843b8 upstream.

The i2c_device_id structure variable's name is not used in the
i2c_driver structure.

Signed-off-by: Vikram Narayanan <vikram186@gmail.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoi2c: tegra: Enable new slave mode.
Kenneth Waters [Mon, 25 Apr 2011 18:29:54 +0000 (12:29 -0600)]
i2c: tegra: Enable new slave mode.

commit 65a1a0ace554d61ea5a90377a54df1505275c1b1 upstream.

For Tegra i2c controller to function properly new slave mode must be
enabled.

swarren notes:

In particular, I found this was needed when working on enabling the
Tegra audio driver on the Seaboard board. There are two different PCB
layouts for this board; a "clamshell" version, which works just fine
without this change, and the original non-clamshell version, which needs
this change in order for I2C to operate correctly. Without it, I2C
probing fails for some devices, e.g. with:

wm8903 0-001a: Device with ID register 0 is not a WM8903
wm8903 0-001a: asoc: failed to probe CODEC wm8903.0-001a: -19
asoc: failed to instantiate card tegra-wm8903: -19
ALSA device list:
  No soundcards found.

Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoloop: handle on-demand devices correctly
Namhyung Kim [Tue, 24 May 2011 14:48:55 +0000 (16:48 +0200)]
loop: handle on-demand devices correctly

commit a1c15c59feee36267c43142a41152fbf7402afb6 upstream.

When finding or allocating a loop device, loop_probe() did not take
partition numbers into account so that it can result to a different
device. Consider following example:

$ sudo modprobe loop max_part=15
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7,   0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7,  16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7,  32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7,  48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7,  64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7,  80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7,  96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7, 112 2011-05-24 22:16 /dev/loop7
$ sudo mknod /dev/loop8 b 7 128
$ sudo losetup /dev/loop8 ~/temp/disk-with-3-parts.img
$ sudo losetup -a
/dev/loop128: [0805]:278201 (/home/namhyung/temp/disk-with-3-parts.img)
$ ls -l /dev/loop*
brw-rw---- 1 root disk 7,    0 2011-05-24 22:16 /dev/loop0
brw-rw---- 1 root disk 7,   16 2011-05-24 22:16 /dev/loop1
brw-rw---- 1 root disk 7, 2048 2011-05-24 22:18 /dev/loop128
brw-rw---- 1 root disk 7, 2049 2011-05-24 22:18 /dev/loop128p1
brw-rw---- 1 root disk 7, 2050 2011-05-24 22:18 /dev/loop128p2
brw-rw---- 1 root disk 7, 2051 2011-05-24 22:18 /dev/loop128p3
brw-rw---- 1 root disk 7,   32 2011-05-24 22:16 /dev/loop2
brw-rw---- 1 root disk 7,   48 2011-05-24 22:16 /dev/loop3
brw-rw---- 1 root disk 7,   64 2011-05-24 22:16 /dev/loop4
brw-rw---- 1 root disk 7,   80 2011-05-24 22:16 /dev/loop5
brw-rw---- 1 root disk 7,   96 2011-05-24 22:16 /dev/loop6
brw-rw---- 1 root disk 7,  112 2011-05-24 22:16 /dev/loop7
brw-r--r-- 1 root root 7,  128 2011-05-24 22:17 /dev/loop8

After this patch, /dev/loop8 - instead of /dev/loop128 - was
accessed correctly.

In addition, 'range' passed to blk_register_region() should
include all range of dev_t that LOOP_MAJOR can address. It does
not need to be limited by partition numbers unless 'max_loop'
param was specified.

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoloop: limit 'max_part' module param to DISK_MAX_PARTS
Namhyung Kim [Tue, 24 May 2011 14:48:54 +0000 (16:48 +0200)]
loop: limit 'max_part' module param to DISK_MAX_PARTS

commit 78f4bb367fd147a0e7e3998ba6e47109999d8814 upstream.

The 'max_part' parameter controls the number of maximum partition
a loop block device can have. However if a user specifies very
large value it would exceed the limitation of device minor number
and can cause a kernel panic (or, at least, produce invalid
device nodes in some cases).

On my desktop system, following command kills the kernel. On qemu,
it triggers similar oops but the kernel was alive:

$ sudo modprobe loop max_part0000
 ------------[ cut here ]------------
 kernel BUG at /media/Linux_Data/project/linux/fs/sysfs/group.c:65!
 invalid opcode: 0000 [#1] SMP
 last sysfs file:
 CPU 0
 Modules linked in: loop(+)

 Pid: 43, comm: insmod Tainted: G        W   2.6.39-qemu+ #155 Bochs Bochs
 RIP: 0010:[<ffffffff8113ce61>]  [<ffffffff8113ce61>] internal_create_group=
+0x2a/0x170
 RSP: 0018:ffff880007b3fde8  EFLAGS: 00000246
 RAX: 00000000ffffffef RBX: ffff880007b3d878 RCX: 00000000000007b4
 RDX: ffffffff8152da50 RSI: 0000000000000000 RDI: ffff880007b3d878
 RBP: ffff880007b3fe38 R08: ffff880007b3fde8 R09: 0000000000000000
 R10: ffff88000783b4a8 R11: ffff880007b3d878 R12: ffffffff8152da50
 R13: ffff880007b3d868 R14: 0000000000000000 R15: ffff880007b3d800
 FS:  0000000002137880(0063) GS:ffff880007c00000(0000) knlGS:00000000000000=
00
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000422680 CR3: 0000000007b50000 CR4: 00000000000006b0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 0000000000000000 DR7: 0000000000000000
 Process insmod (pid: 43, threadinfo ffff880007b3e000, task ffff880007afb9c=
0)
 Stack:
  ffff880007b3fe58 ffffffff811e66dd ffff880007b3fe58 ffffffff811e570b
  0000000000000010 ffff880007b3d800 ffff880007a7b390 ffff880007b3d868
  0000000000400920 ffff880007b3d800 ffff880007b3fe48 ffffffff8113cfc8
 Call Trace:
  [<ffffffff811e66dd>] ? device_add+0x4bc/0x5af
  [<ffffffff811e570b>] ? dev_set_name+0x3c/0x3e
  [<ffffffff8113cfc8>] sysfs_create_group+0xe/0x12
  [<ffffffff810b420e>] blk_trace_init_sysfs+0x14/0x16
  [<ffffffff8116a090>] blk_register_queue+0x47/0xf7
  [<ffffffff8116f527>] add_disk+0xdf/0x290
  [<ffffffffa00060eb>] loop_init+0xeb/0x1b8 [loop]
  [<ffffffffa0006000>] ? 0xffffffffa0005fff
  [<ffffffff8100020a>] do_one_initcall+0x7a/0x12e
  [<ffffffff81096804>] sys_init_module+0x9c/0x1e0
  [<ffffffff813329bb>] system_call_fastpath+0x16/0x1b
 Code: c3 55 48 89 e5 41 57 41 56 41 89 f6 41 55 41 54 49 89 d4 53 48 89 fb=
 48 83 ec 28 48 85 ff 74 0b 85 f6 75 0b 48 83 7f 30 00 75 14 <0f> 0b eb fe =
48 83 7f 30 00 b9 ea ff ff ff 0f 84 18 01 00 00 49
 RIP  [<ffffffff8113ce61>] internal_create_group+0x2a/0x170
  RSP <ffff880007b3fde8>
 ---[ end trace a123eb592043acad ]---

Signed-off-by: Namhyung Kim <namhyung@gmail.com>
Cc: Laurent Vivier <Laurent.Vivier@bull.net>
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agomm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath()
Andrew Barry [Wed, 25 May 2011 00:12:52 +0000 (17:12 -0700)]
mm/page_alloc.c: prevent unending loop in __alloc_pages_slowpath()

commit cfa54a0fcfc1017c6f122b6f21aaba36daa07f71 upstream.

I believe I found a problem in __alloc_pages_slowpath, which allows a
process to get stuck endlessly looping, even when lots of memory is
available.

Running an I/O and memory intensive stress-test I see a 0-order page
allocation with __GFP_IO and __GFP_WAIT, running on a system with very
little free memory.  Right about the same time that the stress-test gets
killed by the OOM-killer, the utility trying to allocate memory gets stuck
in __alloc_pages_slowpath even though most of the systems memory was freed
by the oom-kill of the stress-test.

The utility ends up looping from the rebalance label down through the
wait_iff_congested continiously.  Because order=0,
__alloc_pages_direct_compact skips the call to get_page_from_freelist.
Because all of the reclaimable memory on the system has already been
reclaimed, __alloc_pages_direct_reclaim skips the call to
get_page_from_freelist.  Since there is no __GFP_FS flag, the block with
__alloc_pages_may_oom is skipped.  The loop hits the wait_iff_congested,
then jumps back to rebalance without ever trying to
get_page_from_freelist.  This loop repeats infinitely.

The test case is pretty pathological.  Running a mix of I/O stress-tests
that do a lot of fork() and consume all of the system memory, I can pretty
reliably hit this on 600 nodes, in about 12 hours.  32GB/node.

Signed-off-by: Andrew Barry <abarry@cray.com>
Signed-off-by: Minchan Kim <minchan.kim@gmail.com>
Reviewed-by: Rik van Riel<riel@redhat.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoHID: magicmouse: ignore 'ivalid report id' while switching modes
Jiri Kosina [Thu, 19 May 2011 15:58:07 +0000 (17:58 +0200)]
HID: magicmouse: ignore 'ivalid report id' while switching modes

commit 23746a66d7d9e73402c68ef00d708796b97ebd72 upstream.

The device reponds with 'invalid report id' when feature report switching it
into multitouch mode is sent to it.

This has been silently ignored before 0825411ade ("HID: bt: Wait for ACK
on Sent Reports"), but since this commit, it propagates -EIO from the _raw
callback .

So let the driver ignore -EIO as response to 0xd7,0x01 report, as that's
how the device reacts in normal mode.

Sad, but following reality.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=35022

Tested-by: Chase Douglas <chase.douglas@canonical.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoASoC: fix raumfeld platform
Daniel Mack [Tue, 24 May 2011 12:10:32 +0000 (14:10 +0200)]
ASoC: fix raumfeld platform

commit 477a66948ef8683f182682cc68e8520baf8a5b43 upstream.

Commit f0fba2ad (ASoC: multi-component - ASoC Multi-Component Support)
broke support for Raumfeld platforms as it didn't take into account the
different hardware features on individual devices.

In particular, Raumfeld speakers have no S/PDIF output, so the members
of the snd_soc_card struct must be set dynamically.

Signed-off-by: Daniel Mack <zonque@gmail.com>
Acked-by: Liam Girdwood <lrg@slimlogic.co.uk>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoASoC: Add some missing volume update bit sets for wm_hubs devices
Mark Brown [Sun, 15 May 2011 19:18:38 +0000 (12:18 -0700)]
ASoC: Add some missing volume update bit sets for wm_hubs devices

commit fb5af53d421d80725172427e9076f6e889603df6 upstream.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoASoC: Ensure output PGA is enabled for line outputs in wm_hubs
Mark Brown [Sun, 15 May 2011 00:21:28 +0000 (17:21 -0700)]
ASoC: Ensure output PGA is enabled for line outputs in wm_hubs

commit d0b48af6c2b887354d0893e598d92911ce52620e upstream.

Also fix a left/right typo while we're at it.

Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Acked-by: Liam Girdwood <lrg@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
10 years agoALSA: hda - Use LPIB for ATI/AMD chipsets as default
Takashi Iwai [Fri, 20 May 2011 14:29:09 +0000 (16:29 +0200)]
ALSA: hda - Use LPIB for ATI/AMD chipsets as default

commit 50e3bbf9898840eead86f90a43b3625a2b2f4112 upstream.

ATI and AMD chipsets seem not providing the proper position-buffer
information, and it also doesn't provide FIFO register required by
VIACOMBO fix.  It's better to use LPIB for these.

Reported-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>