Greg Kroah-Hartman [Wed, 4 Dec 2013 19:07:15 +0000 (11:07 -0800)]
Linux 3.12.3
Nanno Langstraat [Mon, 14 Oct 2013 14:07:15 +0000 (16:07 +0200)]
HID: apple: option to swap the 'Option' ("Alt") and 'Command' ("Flag") keys.
commit
43c831468b3d26dbe8f2e061ccaf1abaf9cc1b8b upstream.
Use case: people who use both Apple and PC keyboards regularly, and desire to
keep&use their PC muscle memory.
A particular use case: an Apple compact external keyboard connected to a PC
laptop. (This use case can't be covered well by X.org key remappings etc.)
Signed-off-by: Nanno Langstraat <langstr@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tristan Rice [Tue, 12 Nov 2013 18:06:23 +0000 (19:06 +0100)]
HID: enable Mayflash USB Gamecube Adapter
commit
e17f5d7667c5414b8f12a93ef14aae0824bd2beb upstream.
This is a patch that adds the new Mayflash Gamecube Controller to USB adapter
(ID 1a34:f705 ACRUX) to the ACRUX driver (drivers/hid/hid-axff.c) with full
force feedback support.
Signed-off-by: Tristan Rice <rice@outerearth.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Anders F. U. Kiær [Mon, 21 Oct 2013 21:42:22 +0000 (23:42 +0200)]
HID: add support for LEETGION Hellion Gaming Mouse
commit
f1a4914bd04911fbeaee23445112adae8977144a upstream.
Added id, bindings and comments for Holtek USB ID 04d9:a072
LEETGION Hellion Gaming mouse to use the same corrections of the report
descriptor as Holtek 04d9:a067. As the mouse exceed HID_MAX_USAGES at the
same offsets in the reported descriptor.
Tested on the hardware.
Signed-off-by: Anders F. U. Kiær <ablacksheep@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Achatz [Fri, 8 Nov 2013 13:12:00 +0000 (14:12 +0100)]
HID: roccat: add missing special driver declarations
commit
e078809df5611600965f4d3420c3256260fc3e3d upstream.
Forgot two special driver declarations and sorted the list.
Signed-off-by: Stefan Achatz <erazor_de@users.sourceforge.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Achatz [Sun, 3 Nov 2013 05:25:33 +0000 (06:25 +0100)]
HID: roccat: fix Coverity CID 141438
commit
7be63f20b00840a6f1c718dcee00855688d64acd upstream.
Add missing switch breaks.
Signed-off-by: Stefan Achatz <erazor_de@users.sourceforge.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Stefan Achatz [Mon, 28 Oct 2013 17:52:03 +0000 (18:52 +0100)]
HID: roccat: add new device return value
commit
14fc4290df2fb94a28f39dab9ed32feaa5527bef upstream.
Ryos uses a new return value for critical errors, others have been
confirmed.
Signed-off-by: Stefan Achatz <erazor_de@users.sourceforge.net>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Howells [Tue, 18 Jun 2013 16:40:44 +0000 (17:40 +0100)]
X.509: Remove certificate date checks
commit
124df926090b32a998483f6e43ebeccdbe5b5302 upstream.
Remove the certificate date checks that are performed when a certificate is
parsed. There are two checks: a valid from and a valid to. The first check is
causing a lot of problems with system clocks that don't keep good time and the
second places an implicit expiry date upon the kernel when used for module
signing, so do we really need them?
Signed-off-by: David Howells <dhowells@redhat.com>
cc: David Woodhouse <dwmw2@infradead.org>
cc: Rusty Russell <rusty@rustcorp.com.au>
cc: Josh Boyer <jwboyer@redhat.com>
cc: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 07:29:42 +0000 (04:29 -0300)]
media: s5h1420: Don't use dynamic static allocation
commit
9736a89dafe07359d9c86bf9c3b815a250b354bc upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/s5h1420.c:851:1: warning: 's5h1420_tuner_i2c_tuner_xfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this frontend, only ttpci uses it. The maximum
number of messages there is two, on I2C read operations. As the logic
can add an extra operation, change the size to 3.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 08:05:18 +0000 (05:05 -0300)]
media: dvb-frontends: Don't use dynamic static allocation
commit
8393796dfa4cf5dffcceec464c7789bec3a2f471 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/itd1000.c:69:1: warning: 'itd1000_write_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/mt312.c:126:1: warning: 'mt312_write' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/nxt200x.c:111:1: warning: 'nxt200x_writebytes' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stb6100.c:216:1: warning: 'stb6100_write_reg_range.constprop.3' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stv6110.c:98:1: warning: 'stv6110_write_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/stv6110x.c:85:1: warning: 'stv6110x_write_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda18271c2dd.c:147:1: warning: 'WriteRegs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/zl10039.c:119:1: warning: 'zl10039_write' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 08:11:47 +0000 (05:11 -0300)]
media: dvb-frontends: Don't use dynamic static allocation
commit
37ebaf6891ee81687bb558e8375c0712d8264ed8 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/af9013.c:77:1: warning: 'af9013_wr_regs_i2c' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:188:1: warning: 'af9033_wr_reg_val_tab' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/af9033.c:68:1: warning: 'af9033_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/bcm3510.c:230:1: warning: 'bcm3510_do_hab_cmd' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/cxd2820r_core.c:84:1: warning: 'cxd2820r_rd_regs_i2c.isra.1' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2830.c:56:1: warning: 'rtl2830_wr' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/rtl2832.c:187:1: warning: 'rtl2832_wr' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:52:1: warning: 'tda10071_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/dvb-frontends/tda10071.c:84:1: warning: 'tda10071_rd_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 08:14:58 +0000 (05:14 -0300)]
media: stb0899_drv: Don't use dynamic static allocation
commit
ba4746423488aafa435739c32bfe0758f3dd5d77 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stb0899_drv.c:540:1: warning: 'stb0899_write_regs' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 08:17:01 +0000 (05:17 -0300)]
media: stv0367: Don't use dynamic static allocation
commit
9aca4fb0571ce9cfef680ceb08d19dd008015307 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stv0367.c:791:1: warning: 'stv0367_writeregs.constprop.4' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 08:18:49 +0000 (05:18 -0300)]
media: stv090x: Don't use dynamic static allocation
commit
f7a35df15b1f7de7823946aebc9164854e66ea07 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/dvb-frontends/stv090x.c:750:1: warning: 'stv090x_write_regs.constprop.6' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 09:07:42 +0000 (06:07 -0300)]
media: tuners: Don't use dynamic static allocation
commit
f1baab870f6e93b668af7b34d6f6ba49f1b0e982 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/e4000.c:50:1: warning: 'e4000_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/e4000.c:83:1: warning: 'e4000_rd_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:66:1: warning: 'fc2580_wr_regs.constprop.1' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/fc2580.c:98:1: warning: 'fc2580_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:57:1: warning: 'tda18212_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18212.c:90:1: warning: 'tda18212_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:60:1: warning: 'tda18218_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/tuners/tda18218.c:92:1: warning: 'tda18218_rd_regs.constprop.0' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 09:13:11 +0000 (06:13 -0300)]
media: tuner-xc2028: Don't use dynamic static allocation
commit
56ac033725ec93a45170caf3979eb2b1211a59a8 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/tuners/tuner-xc2028.c:651:1: warning: 'load_firmware' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this driver, the maximum limit is 80, used only
on tm6000 driver. This limit is due to the size of the USB control URBs.
Ok, it would be theoretically possible to use a bigger size on PCI
devices, but the firmware load time is already good enough. Anyway,
if some usage requires more, it is just a matter of also increasing
the buffer size at load_firmware().
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 09:20:16 +0000 (06:20 -0300)]
media: v4l2-async: Don't use dynamic static allocation
commit
24e9a47e14f0a97ee97abc3dd86b2ef254448a17 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/v4l2-core/v4l2-async.c:238:1: warning: 'v4l2_async_notifier_unregister' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In this specific case, there's a hard limit imposed by V4L2_MAX_SUBDEVS,
with is currently 128. That means that the buffer size can be up to
128x8 = 1024 bytes (on a 64bits kernel), with is too big for stack.
Worse than that, someone could increase it and cause real troubles.
So, let's use dynamically allocated data, instead.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 11:16:47 +0000 (08:16 -0300)]
media: lirc_zilog: Don't use dynamic static allocation
commit
ac5b4b6bf0c84c48d7e2e3fce22e35b04282ba76 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
ompilation complains about it on some archs:
drivers/staging/media/lirc/lirc_zilog.c:967:1: warning: 'read' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be 64. That should
be more than enough.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Fri, 1 Nov 2013 16:09:47 +0000 (13:09 -0300)]
media: cx18: struct i2c_client is too big for stack
commit
1d212cf0c2d89adf3d0a6d62d729076f49f087dc upstream.
drivers/media/pci/cx18/cx18-driver.c: In function 'cx18_read_eeprom':
drivers/media/pci/cx18/cx18-driver.c:357:1: warning: the frame size of 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=]
That happens because the routine allocates 256 bytes for an eeprom buffer, plus
the size of struct i2c_client, with is big.
Change the logic to dynamically allocate/deallocate space for struct i2c_client,
instead of using the stack.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 09:17:47 +0000 (06:17 -0300)]
media: cimax2: Don't use dynamic static allocation
commit
278ba83a3a1932805be726bdd7dfb3156286d33a upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/pci/cx23885/cimax2.c:149:1: warning: 'netup_write_i2c' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer. Considering that I2C
transfers are generally limited, and that devices used on USB has a
max data length of 64 bytes for the control URBs.
So, it seem safe to use 64 bytes as the hard limit for all those devices.
On most cases, the limit is a way lower than that, but this limit
is small enough to not affect the Kernel stack, and it is a no brain
limit, as using smaller ones would require to either carefully each
driver or to take a look on each datasheet.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 08:51:59 +0000 (05:51 -0300)]
media: av7110_hw: Don't use dynamic static allocation
commit
5bf30b3bc4ff80ef71a733a1f459cca4fa507892 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/pci/ttpci/av7110_hw.c:510:1: warning: 'av7110_fw_cmd' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer.
In the specific case of this driver, the maximum fw command size
is 6 + 2, as checked using:
$ git grep -A1 av7110_fw_cmd drivers/media/pci/ttpci/
So, use 8 for the buffer size.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 10:18:09 +0000 (07:18 -0300)]
media: cxusb: Don't use dynamic static allocation
commit
64f7ef8afbf89f3c72c4d2472e4914ca198c0668 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb/cxusb.c:209:1: warning: 'cxusb_i2c_xfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/cxusb.c:69:1: warning: 'cxusb_ctrl_msg' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (64 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 10:23:49 +0000 (07:23 -0300)]
media: dibusb-common: Don't use dynamic static allocation
commit
1d7fa359d4c0fbb2756fa01cc47212908d90b7b0 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb/dibusb-common.c:124:1: warning: 'dibusb_i2c_msg' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (64 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 10:43:40 +0000 (07:43 -0300)]
media: dw2102: Don't use dynamic static allocation
commit
0065a79a8698a953e4b201c5fce8db8940530578 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb/dw2102.c:368:1: warning: 'dw2102_earda_i2c_transfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/dw2102.c:449:1: warning: 'dw2104_i2c_transfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/dw2102.c:512:1: warning: 'dw3101_i2c_transfer' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb/dw2102.c:621:1: warning: 's6x0_i2c_transfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (64 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 10:52:04 +0000 (07:52 -0300)]
media: af9015: Don't use dynamic static allocation
commit
65e2f1cb3fe0f0630834b9517ba8f631936f325c upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/af9015.c:433:1: warning: 'af9015_eeprom_hash' uses dynamic stack allocation [enabled by default]
In this specific case, it is a gcc bug, as the size is a const, but
it is easy to just change it from const to a #define, getting rid of
the gcc warning.
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 11:07:12 +0000 (08:07 -0300)]
media: af9035: Don't use dynamic static allocation
commit
7760e148350bf6df95662bc0db3734e9d991cb03 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/af9035.c:142:1: warning: 'af9035_wr_regs' uses dynamic stack allocation [enabled by default]
drivers/media/usb/dvb-usb-v2/af9035.c:305:1: warning: 'af9035_i2c_master_xfer' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (64 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Reviewed-by: Antti Palosaari <crope@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mauro Carvalho Chehab [Sat, 2 Nov 2013 11:13:02 +0000 (08:13 -0300)]
media: mxl111sf: Don't use dynamic static allocation
commit
c98300a0e8cf160aaea60bc05d2cd156a7666173 upstream.
Dynamic static allocation is evil, as Kernel stack is too low, and
compilation complains about it on some archs:
drivers/media/usb/dvb-usb-v2/mxl111sf.c:74:1: warning: 'mxl111sf_ctrl_msg' uses dynamic stack allocation [enabled by default]
Instead, let's enforce a limit for the buffer to be the max size of
a control URB payload data (64 bytes).
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Reviewed-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <m.chehab@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Wed, 13 Nov 2013 20:25:35 +0000 (15:25 -0500)]
drm/radeon/vm: don't attempt to update ptes if ib allocation fails
commit
4cc948b94a222c310ae089c36718aac7a03aec90 upstream.
If we fail to allocate an indirect buffer (ib) when updating
the ptes, return an error instead of trying to use the ib.
Avoids a null pointer dereference.
Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=58621
v2 (chk): rebased on drm-fixes-3.12 for stable inclusion
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Walleij [Wed, 27 Nov 2013 07:47:02 +0000 (08:47 +0100)]
gpio: pl061: move irqdomain initialization
commit
2ba3154d9cb13697b97723cce75633b48adfe826 upstream.
The PL061 driver had the irqdomain initialization in an unfortunate
place: when used with device tree (and thus passing the base IRQ
0) the driver would work, as this registers an irqdomain and waits
for mappings to be done dynamically as the devices request their
IRQs, whereas when booting using platform data the irqdomain core
would attempt to allocate IRQ descriptors dynamically (which works
fine) but also to associate the irq_domain_associate_many() on all
IRQs, which in turn will call the mapping function which at this
point will try to set the type of the IRQ and then tries to acquire
a non-initialized spinlock yielding a backtrace like this:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.13.0-rc1+ #652
Backtrace:
[<
c0016f0c>] (dump_backtrace) from [<
c00172ac>] (show_stack+0x18/0x1c)
r6:
c798ace0 r5:
00000000 r4:
c78257e0 r3:
00200140
[<
c0017294>] (show_stack) from [<
c0329ea0>] (dump_stack+0x20/0x28)
[<
c0329e80>] (dump_stack) from [<
c004fa80>] (__lock_acquire+0x1c0/0x1b80)
[<
c004f8c0>] (__lock_acquire) from [<
c0051970>] (lock_acquire+0x6c/0x80)
r10:
00000000 r9:
c0455234 r8:
00000060 r7:
c047d798 r6:
600000d3 r5:
00000000
r4:
c782c000
[<
c0051904>] (lock_acquire) from [<
c032e484>] (_raw_spin_lock_irqsave+0x60/0x74)
r6:
c01a1100 r5:
800000d3 r4:
c798acd0
[<
c032e424>] (_raw_spin_lock_irqsave) from [<
c01a1100>] (pl061_irq_type+0x28/0x)
r6:
00000000 r5:
00000000 r4:
c798acd0
[<
c01a10d8>] (pl061_irq_type) from [<
c0059ef4>] (__irq_set_trigger+0x70/0x104)
r6:
00000000 r5:
c01a10d8 r4:
c046da1c r3:
c01a10d8
[<
c0059e84>] (__irq_set_trigger) from [<
c005b348>] (irq_set_irq_type+0x40/0x60)
r10:
c043240c r8:
00000060 r7:
00000000 r6:
c046da1c r5:
00000060 r4:
00000000
[<
c005b308>] (irq_set_irq_type) from [<
c01a1208>] (pl061_irq_map+0x40/0x54)
r6:
c79693c0 r5:
c798acd0 r4:
00000060
[<
c01a11c8>] (pl061_irq_map) from [<
c005d27c>] (irq_domain_associate+0xc0/0x190)
r5:
00000060 r4:
c046da1c
[<
c005d1bc>] (irq_domain_associate) from [<
c005d604>] (irq_domain_associate_man)
r8:
00000008 r7:
00000000 r6:
c79693c0 r5:
00000060 r4:
00000000
[<
c005d5d0>] (irq_domain_associate_many) from [<
c005d864>] (irq_domain_add_simp)
r8:
c046578c r7:
c035b72c r6:
c79693c0 r5:
00000060 r4:
00000008 r3:
00000008
[<
c005d814>] (irq_domain_add_simple) from [<
c01a1380>] (pl061_probe+0xc4/0x22c)
r6:
00000060 r5:
c0464380 r4:
c798acd0
[<
c01a12bc>] (pl061_probe) from [<
c01c0450>] (amba_probe+0x74/0xe0)
r10:
c043240c r9:
c0455234 r8:
00000000 r7:
c047d7f8 r6:
c047d744 r5:
00000000
r4:
c0464380
This moves the irqdomain initialization to a point where the spinlock
and GPIO chip are both fully propulated, so the callbacks can be used
without crashes.
I had some problem reproducing the crash, as the devm_kzalloc():ed
zeroed memory would seemingly mask the spinlock as something OK,
but by poisoning the lock like this:
u32 *dum;
dum = (u32 *) &chip->lock;
*dum = 0xaaaaaaaaU;
I could reproduce, fix and test the patch.
Reported-by: Russell King <linux@arm.linux.org.uk>
Cc: Rob Herring <robherring2@gmail.com>
Cc: Haojian Zhuang <haojian.zhuang@linaro.org>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simon Wood [Thu, 10 Oct 2013 14:20:12 +0000 (08:20 -0600)]
HID: lg: fix ReportDescriptor for Logitech Formula Vibration
commit
7f50547059bd55ac6a98c29fd1989421bdc36ec9 upstream.
By default the Logitech Formula Vibration presents a combined accel/brake
axis ('Y'). This patch modifies the HID descriptor to present seperate
accel/brake axes ('Y' and 'Z').
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simon Wood [Wed, 6 Nov 2013 19:30:41 +0000 (12:30 -0700)]
HID:hid-lg4ff: Switch autocentering off when strength is set to zero.
commit
d2c02da549b468bbb28e67d269bd3c9e10683ff5 upstream.
When the autocenter is set to zero, this patch issues a command to
totally disable the autocenter - this results in less resistance
in the wheel.
Reported-by: Elias Vanderstuyft <elias.vds@gmail.com>
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Simon Wood [Wed, 6 Nov 2013 19:30:40 +0000 (12:30 -0700)]
HID:hid-lg4ff: Scale autocentering force properly on Logitech wheel
commit
f8c231569a7a455dfa1907294a46ba52b3aa8859 upstream.
Adjust the scaling and lineartity to match that of the Windows
driver (from MOMO testing).
Reported-by: Elias Vanderstuyft <elias.vds@gmail.com>
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
KaiChung Cheng [Thu, 21 Nov 2013 09:04:30 +0000 (10:04 +0100)]
HID: multicouh: add PID VID to support 1 new Wistron optical touch device
commit
bf9d121efc18c30caa2caad85358cf9408eca117 upstream.
This patch adds PID VID to support for the Wistron Inc. Optical touch panel.
Signed-off-by: KaiChung Cheng <kenny_cheng@wistron.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Srinivas Pandruvada [Sat, 26 Oct 2013 17:04:09 +0000 (10:04 -0700)]
HID: hid-sensor-hub: fix report size
commit
d4b1bba76171cb783e32441b28462fe841073ed8 upstream.
Most of the hid sensor field size is reported in report_size field
in the report descriptor. For rotation fusion sensor the quaternion
data is 16 byte field, the report size was set to 4 and report
count field is set to 4. So the total size is 16 bytes. But the current
driver has a bug and not taking account for report count field. This
causes user space to see only 4 bytes of data sent via IIO interface.
The number of bytes in a field needs to take account of report_count
field. Need to multiply report_size and report_count to get total
number of bytes.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Forest Bond [Mon, 21 Oct 2013 16:38:49 +0000 (12:38 -0400)]
HID: hid-multitouch: add support for SiS panels
commit
a6802e008e19845fd9669511b895f7515ef9c48b upstream.
Add support for SiS multitouch panels.
Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Elias Vanderstuyft [Mon, 7 Oct 2013 16:48:12 +0000 (19:48 +0300)]
HID: logitech - lg2ff: Add IDs for Formula Vibration Feedback Wheel
commit
bd04363d3990c0727b7512a79a08c68436878bb0 upstream.
Add USB IDs for Logitech Formula Vibration Feedback Wheel (046d:ca04).
The lg2ff force feedback subdriver is used for vibration and
HID_GD_MULTIAXIS is set to avoid deadzone like other Logitech wheels.
Kconfig description etc are also updated accordingly.
Signed-off-by: Elias Vanderstuyft <Elias.vds@gmail.com>
[anssi.hannula@iki.fi: added description and CCs]
Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
Signed-off-by: Simon Wood <simon@mungewell.org>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Luosong [Wed, 2 Oct 2013 09:20:00 +0000 (11:20 +0200)]
HID: multitouch: Fix GeneralTouch products and add more PIDs
commit
7b2262920db2b98fe2cd32cde52141f02fd9eecf upstream.
GeneralTouch products should use the quirk SLOT_IS_CONTACTID
instead of SLOT_IS_CONTACTNUMBER.
Adding PIDs 0101,e100,0102,0106,010a from the new products.
Tested on new and older products by GeneralTouch engineers.
Signed-off-by: Luosong <android@generaltouch.com>
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Whitehouse [Thu, 21 Nov 2013 18:47:57 +0000 (18:47 +0000)]
GFS2: Fix ref count bug relating to atomic_open
commit
ea0341e071527d5cec350917b01ab901af09d758 upstream.
In the case that atomic_open calls finish_no_open() with
the dentry that was supplied to gfs2_atomic_open() an
extra reference count is required. This patch fixes that
issue preventing a bug trap triggering at umount time.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kuninori Morimoto [Wed, 25 Sep 2013 01:55:22 +0000 (18:55 -0700)]
sh: ecovec: fixup compile error on sdhi
commit
357002b9c09e5332c9fcd4fa3d3c0fa00ca6ae4f upstream.
afa2c9407f8908 ("sh: ecovec24: Use MMC/SDHI CD and RO GPIO") added
.tmio_flags = TMIO_MMC_USE_GPIO_CD on sh_mobile_sdhi_info, but it needs
<linux/mfd/tmio.h> header. This patch adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Reviewed-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mark Langsdorf [Tue, 1 Oct 2013 15:30:24 +0000 (10:30 -0500)]
cpufreq: highbank-cpufreq: Enable Midway/ECX-2000
commit
fbbc5bfb44a22e7a8ef753a1c8dfb448d7ac8b85 upstream.
Calxeda's new ECX-2000 part uses the same cpufreq interface as highbank,
so add it to the driver's compatibility list.
This is a minor change that can safely be applied to the 3.10 and 3.11
stable trees.
Signed-off-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wei WANG [Fri, 13 Sep 2013 09:45:43 +0000 (17:45 +0800)]
mfd: rtsx: Modify rts5249_optimize_phy
commit
26b818511c6562ce372566c219a2ef1afea35fe6 upstream.
In some platforms, specially Thinkpad series, rts5249 won't be
initialized properly. So we need adjust some phy parameters to
improve the compatibility issue.
It is a little different between simulation and real chip. We have
no idea about which configuration is better before tape-out. We set
default settings according to simulation, but need to tune these
parameters after getting the real chip.
I can't explain every change in detail here. The below information is
just a rough description:
PHY_REG_REV: Disable internal clkreq_tx, enable rx_pwst
PHY_BPCR: No change, just turn the magic number to macro definitions
PHY_PCR: Change OOBS sensitivity, from 60mV to 90mV
PHY_RCR2: Control charge-pump current automatically
PHY_FLD4: Use TX cmu reference clock
PHY_RDR: Change RXDSEL from 30nF to 1.9nF
PHY_RCR1: Change the duration between adp_st and asserting cp_en from
0.32 us to 0.64us
PHY_FLD3: Adjust internal timers
PHY_TUNE: Fine tune the regulator12 output voltage
Signed-off-by: Wei WANG <wei_wang@realsil.com.cn>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Cc: Chris Ball <cjb@laptop.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
James Ralston [Mon, 4 Nov 2013 17:31:20 +0000 (09:31 -0800)]
mfd: lpc_ich: Add Device IDs for Intel Wildcat Point-LP PCH
commit
5e90169c5a02da69a1ef721bea7a823e9e48fcb6 upstream.
This patch adds the TCO Watchdog Device IDs for the
Intel Wildcat Point-LP PCH.
Signed-off-by: James Ralston <james.d.ralston@intel.com>
Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Forest Bond [Mon, 21 Oct 2013 16:38:18 +0000 (12:38 -0400)]
Input: usbtouchscreen: ignore eGalax/D-Wav/EETI HIDs
commit
ae2aa3a512fa5f50f67feba9e66bc2efb394bd63 upstream.
The HID driver now handles these devices, regardless of what protocol
the device claims it supports.
Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Forest Bond [Mon, 21 Oct 2013 16:38:02 +0000 (12:38 -0400)]
HID: don't ignore eGalax/D-Wav/EETI HIDs
commit
95d50b6c5e18ff7351c5f2a6ff53afaed5f7e664 upstream.
Certain devices with class HID, protocol None did not work with the HID
driver at one point, and as a result were bound to usbtouchscreen
instead as of commit 139ebe8 ("Input: usbtouchscreen - fix eGalax HID
ignoring"). This change was prompted by the following report:
https://lkml.org/lkml/2009/1/25/127
Unfortunately, the device mentioned in this report is no longer
available for testing.
We've recently discovered that some devices with class HID, protocol
None do not work with usbtouchscreen, but do work with usbhid. Here is
the report that made this evident:
http://comments.gmane.org/gmane.linux.kernel.input/31710
Driver binding for these devices has flip-flopped a few times, so both
of the above reports were regressions.
This situation would appear to leave us with no easy way to bind every
device to the right driver. However, in my own testing with several
devices I have not found a device with class HID that does not work with
the current HID driver. It is my belief that changes to the HID driver
since the original report have likely fixed the issue(s) that made it
unsuitable at the time, and that we should prefer it over usbtouchscreen
for these devices. In particular, HID quirks affecting these devices
were added/removed in the following commits since then:
fe6065d HID: add multi-input quirk for eGalax Touchcontroller
77933c3 Merge branch 'egalax' into for-linus
ebd11fe HID: Add quirk for eGalax touch controler.
d34c4aa HID: add no-get quirk for eGalax touch controller
This patch makes the HID driver no longer ignore eGalax/D-Wav/EETI
devices with class HID. If there are in fact devices with class HID
that still do not work with the HID driver, we will see another round of
regressions. In that case I propose we investigate why the device is
not working with the HID driver rather than re-introduce regressions for
functioning HID devices by again binding them to usbtouchscreen.
The corresponding change to usbtouchscreen will be made separately.
Signed-off-by: Forest Bond <forest.bond@rapidrollout.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tom Gundersen [Thu, 31 Oct 2013 07:33:54 +0000 (00:33 -0700)]
Input: i8042 - add PNP modaliases
commit
78551277e4df57864b0b0e7f85c23ede2be2edb8 upstream.
This allows the module to be autoloaded in the common case.
In order to work on non-PnP systems the module should be compiled in or
loaded unconditionally at boot (c.f. modules-load.d(5)), as before.
Signed-off-by: Tom Gundersen <teg@jklm.no>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Joseph Salisbury [Wed, 16 Oct 2013 16:19:40 +0000 (09:19 -0700)]
Input: cypress_ps2 - do not consider data bad if palm is detected
commit
5df682b297f6b23ec35615ed7bb50cbb25d25869 upstream.
If hardware (or firmware) detects palm on the surface of the device it does
not mean that the data packet is bad from the protocol standpoint. Instead
of reporting PSMOUSE_BAD_DATA in this case simply threat it as if nothing
touches the surface.
BugLink: http://bugs.launchpad.net/bugs/1229361
Signed-off-by: Joseph Salisbury <joseph.salisbury@canonical.com>
Tested-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Stone [Thu, 31 Oct 2013 07:25:34 +0000 (00:25 -0700)]
Input: evdev - fall back to vmalloc for client event buffer
commit
92eb77d0ffbaa71b501a0a8dabf09a351bf4267f upstream.
evdev always tries to allocate the event buffer for clients using
kzalloc rather than vmalloc, presumably to avoid mapping overhead where
possible. However, drivers like bcm5974, which claims support for
reporting 16 fingers simultaneously, can have an extraordinarily large
buffer. The resultant contiguous order-4 allocation attempt fails due
to fragmentation, and the device is thus unusable until reboot.
Try kzalloc if we can to avoid the mapping overhead, but if that fails,
fall back to vzalloc.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dmitry Torokhov [Fri, 15 Nov 2013 01:36:42 +0000 (17:36 -0800)]
Revert "Input: ALPS - add support for model found on Dell XT2"
commit
936816161978ca716a56c5e553c68f25972b1e3a upstream.
This reverts commit
5beea882e64121dfe3b33145767d3302afa784d5 as it
breaks trackpoint operation on XT2.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt (Red Hat) [Tue, 26 Nov 2013 14:22:54 +0000 (09:22 -0500)]
tracing: Allow events to have NULL strings
commit
4e58e54754dc1fec21c3a9e824bc108b05fdf46e upstream.
If an TRACE_EVENT() uses __assign_str() or __get_str on a NULL pointer
then the following oops will happen:
BUG: unable to handle kernel NULL pointer dereference at (null)
IP: [<
c127a17b>] strlen+0x10/0x1a
*pde =
00000000 ^M
Oops: 0000 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.13.0-rc1-test+ #2
Hardware name: /DG965MQ, BIOS MQ96510J.86A.0372.2006.0605.1717 06/05/2006^M
task:
f5cde9f0 ti:
f5e5e000 task.ti:
f5e5e000
EIP: 0060:[<
c127a17b>] EFLAGS:
00210046 CPU: 1
EIP is at strlen+0x10/0x1a
EAX:
00000000 EBX:
c2472da8 ECX:
ffffffff EDX:
c2472da8
ESI:
c1c5e5fc EDI:
00000000 EBP:
f5e5fe84 ESP:
f5e5fe80
DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0:
8005003b CR2:
00000000 CR3:
01f32000 CR4:
000007d0
Stack:
f5f18b90 f5e5feb8 c10687a8 0759004f 00000005 00000005 00000005 00200046
00000002 00000000 c1082a93 f56c7e28 c2472da8 c1082a93 f5e5fee4 c106bc61^M
00000000 c1082a93 00000000 00000000 00000001 00200046 00200082 00000000
Call Trace:
[<
c10687a8>] ftrace_raw_event_lock+0x39/0xc0
[<
c1082a93>] ? ktime_get+0x29/0x69
[<
c1082a93>] ? ktime_get+0x29/0x69
[<
c106bc61>] lock_release+0x57/0x1a5
[<
c1082a93>] ? ktime_get+0x29/0x69
[<
c10824dd>] read_seqcount_begin.constprop.7+0x4d/0x75
[<
c1082a93>] ? ktime_get+0x29/0x69^M
[<
c1082a93>] ktime_get+0x29/0x69
[<
c108a46a>] __tick_nohz_idle_enter+0x1e/0x426
[<
c10690e8>] ? lock_release_holdtime.part.19+0x48/0x4d
[<
c10bc184>] ? time_hardirqs_off+0xe/0x28
[<
c1068c82>] ? trace_hardirqs_off_caller+0x3f/0xaf
[<
c108a8cb>] tick_nohz_idle_enter+0x59/0x62
[<
c1079242>] cpu_startup_entry+0x64/0x192
[<
c102299c>] start_secondary+0x277/0x27c
Code: 90 89 c6 89 d0 88 c4 ac 38 e0 74 09 84 c0 75 f7 be 01 00 00 00 89 f0 48 5e 5d c3 55 89 e5 57 66 66 66 66 90 83 c9 ff 89 c7 31 c0 <f2> ae f7 d1 8d 41 ff 5f 5d c3 55 89 e5 57 66 66 66 66 90 31 ff
EIP: [<
c127a17b>] strlen+0x10/0x1a SS:ESP 0068:
f5e5fe80
CR2:
0000000000000000
---[ end trace
01bc47bf519ec1b2 ]---
New tracepoints have been added that have allowed for NULL pointers
being assigned to strings. To fix this, change the TRACE_EVENT() code
to check for NULL and if it is, it will assign "(null)" to it instead
(similar to what glibc printf does).
Reported-by: Shuah Khan <shuah.kh@samsung.com>
Reported-by: Jovi Zhangwei <jovi.zhangwei@gmail.com>
Link: http://lkml.kernel.org/r/CAGdX0WFeEuy+DtpsJzyzn0343qEEjLX97+o1VREFkUEhndC+5Q@mail.gmail.com
Link: http://lkml.kernel.org/r/528D6972.9010702@samsung.com
Fixes:
9cbf117662e2 ("tracing/events: provide string with undefined size support")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Thu, 28 Nov 2013 10:05:28 +0000 (11:05 +0100)]
ALSA: hda - Check leaf nodes to find aamix amps
commit
2ded3e5b61d61d0bc90bebb8004db6184c7db6eb upstream.
The current generic parser assumes blindly that the volume and mute
amps are found in the aamix node itself. But on some codecs,
typically Analog Devices ones, the aamix amps are separately
implemented in each leaf node of the aamix node, and the current
driver can't establish the correct amp controls. This is a regression
compared with the previous static quirks.
This patch extends the search for the amps to the leaf nodes for
allowing the aamix controls again on such codecs.
In this implementation, I didn't code to loop through the whole paths,
since usually one depth should suffice, and we can't search too
deeply, as it may result in the conflicting control assignments.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65641
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Thu, 28 Nov 2013 14:21:21 +0000 (15:21 +0100)]
ALSA: hda - Initialize missing bass speaker pin for ASUS AIO ET2700
commit
1f0bbf03cb829162ec8e6d03c98aaaed88c6f534 upstream.
Add a fixup entry for the missing bass speaker pin 0x16 on ASUS ET2700
AiO desktop. The channel map will be added in the next patch, so that
this can be backported easily to stable kernels.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65961
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 26 Nov 2013 07:33:45 +0000 (08:33 +0100)]
ALSA: hda - Create Headhpone Mic Jack Mode when really needed
commit
ced4cefc75fdb8be95eaee325ad0f6b2fc0a484b upstream.
When a headphone jack is configurable as input, the generic parser
tries to make it retaskable as Headphone Mic. The switching can be
done smoothly if Capture Source control exists (i.e. there is another
input source). Or when user explicitly enables the creation of jack
mode controls, "Headhpone Mic Jack Mode" will be created accordingly.
However, if the headphone mic is the only input source, we have to
create "Headphone Mic Jack Mode" control because there is no capture
source selection. Otherwise, the generic parser assumes that the
input is constantly enabled, thus the headphone is permanently set
as input. This situation happens on the old MacBook Airs where no
input is supported properly, for example.
This patch fixes the problem: now "Headphone Mic Jack Mode" is created
when such an input selection isn't possible.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65681
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 26 Nov 2013 07:44:26 +0000 (08:44 +0100)]
ALSA: hda - Fix hp-mic mode without VREF bits
commit
16c0cefe8951b2c4b824fd06011ac1b359b1ab3b upstream.
When the hp mic pin has no VREF bits, the driver forgot to set PIN_IN
bit. Spotted during debugging old MacBook Airs.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=65681
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kailang Yang [Tue, 26 Nov 2013 07:17:50 +0000 (15:17 +0800)]
ALSA: hda/realtek - Add support of ALC231 codec
commit
ba4c4d0a9021ab034554d532a98133d668b87599 upstream.
It's compatible with ALC269.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kailang Yang [Tue, 26 Nov 2013 07:41:40 +0000 (15:41 +0800)]
ALSA: hda/realtek - Set pcbeep amp for ALC668
commit
9ad54547cf6f4410eba83bb95dfd2a0966718d6d upstream.
Set the missing pcbeep default amp for ALC668.
Signed-off-by: Kailang Yang <kailang@realtek.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Zijlstra [Tue, 26 Nov 2013 14:03:41 +0000 (15:03 +0100)]
cpuset: Fix memory allocator deadlock
commit
0fc0287c9ed1ffd3706f8b4d9b314aa102ef1245 upstream.
Juri hit the below lockdep report:
[ 4.303391] ======================================================
[ 4.303392] [ INFO: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected ]
[ 4.303394] 3.12.0-dl-peterz+ #144 Not tainted
[ 4.303395] ------------------------------------------------------
[ 4.303397] kworker/u4:3/689 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 4.303399] (&p->mems_allowed_seq){+.+...}, at: [<
ffffffff8114e63c>] new_slab+0x6c/0x290
[ 4.303417]
[ 4.303417] and this task is already holding:
[ 4.303418] (&(&q->__queue_lock)->rlock){..-...}, at: [<
ffffffff812d2dfb>] blk_execute_rq_nowait+0x5b/0x100
[ 4.303431] which would create a new lock dependency:
[ 4.303432] (&(&q->__queue_lock)->rlock){..-...} -> (&p->mems_allowed_seq){+.+...}
[ 4.303436]
[ 4.303898] the dependencies between the lock to be acquired and SOFTIRQ-irq-unsafe lock:
[ 4.303918] -> (&p->mems_allowed_seq){+.+...} ops: 2762 {
[ 4.303922] HARDIRQ-ON-W at:
[ 4.303923] [<
ffffffff8108ab9a>] __lock_acquire+0x65a/0x1ff0
[ 4.303926] [<
ffffffff8108cbe3>] lock_acquire+0x93/0x140
[ 4.303929] [<
ffffffff81063dd6>] kthreadd+0x86/0x180
[ 4.303931] [<
ffffffff816ded6c>] ret_from_fork+0x7c/0xb0
[ 4.303933] SOFTIRQ-ON-W at:
[ 4.303933] [<
ffffffff8108abcc>] __lock_acquire+0x68c/0x1ff0
[ 4.303935] [<
ffffffff8108cbe3>] lock_acquire+0x93/0x140
[ 4.303940] [<
ffffffff81063dd6>] kthreadd+0x86/0x180
[ 4.303955] [<
ffffffff816ded6c>] ret_from_fork+0x7c/0xb0
[ 4.303959] INITIAL USE at:
[ 4.303960] [<
ffffffff8108a884>] __lock_acquire+0x344/0x1ff0
[ 4.303963] [<
ffffffff8108cbe3>] lock_acquire+0x93/0x140
[ 4.303966] [<
ffffffff81063dd6>] kthreadd+0x86/0x180
[ 4.303969] [<
ffffffff816ded6c>] ret_from_fork+0x7c/0xb0
[ 4.303972] }
Which reports that we take mems_allowed_seq with interrupts enabled. A
little digging found that this can only be from
cpuset_change_task_nodemask().
This is an actual deadlock because an interrupt doing an allocation will
hit get_mems_allowed()->...->__read_seqcount_begin(), which will spin
forever waiting for the write side to complete.
Cc: John Stultz <john.stultz@linaro.org>
Cc: Mel Gorman <mgorman@suse.de>
Reported-by: Juri Lelli <juri.lelli@gmail.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Tested-by: Juri Lelli <juri.lelli@gmail.com>
Acked-by: Li Zefan <lizefan@huawei.com>
Acked-by: Mel Gorman <mgorman@suse.de>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Wed, 27 Nov 2013 23:16:21 +0000 (18:16 -0500)]
cgroup: fix cgroup_subsys_state leak for seq_files
commit
e605b36575e896edd8161534550c9ea021b03bc0 upstream.
If a cgroup file implements either read_map() or read_seq_string(),
such file is served using seq_file by overriding file->f_op to
cgroup_seqfile_operations, which also overrides the release method to
single_release() from cgroup_file_release().
Because cgroup_file_open() didn't use to acquire any resources, this
used to be fine, but since
f7d58818ba42 ("cgroup: pin
cgroup_subsys_state when opening a cgroupfs file"), cgroup_file_open()
pins the css (cgroup_subsys_state) which is put by
cgroup_file_release(). The patch forgot to update the release path
for seq_files and each open/release cycle leaks a css reference.
Fix it by updating cgroup_file_release() to also handle seq_files and
using it for seq_file release path too.
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Fri, 22 Nov 2013 22:14:39 +0000 (17:14 -0500)]
cgroup: use a dedicated workqueue for cgroup destruction
commit
e5fca243abae1445afbfceebda5f08462ef869d3 upstream.
Since
be44562613851 ("cgroup: remove synchronize_rcu() from
cgroup_diput()"), cgroup destruction path makes use of workqueue. css
freeing is performed from a work item from that point on and a later
commit,
ea15f8ccdb430 ("cgroup: split cgroup destruction into two
steps"), moves css offlining to workqueue too.
As cgroup destruction isn't depended upon for memory reclaim, the
destruction work items were put on the system_wq; unfortunately, some
controller may block in the destruction path for considerable duration
while holding cgroup_mutex. As large part of destruction path is
synchronized through cgroup_mutex, when combined with high rate of
cgroup removals, this has potential to fill up system_wq's max_active
of 256.
Also, it turns out that memcg's css destruction path ends up queueing
and waiting for work items on system_wq through work_on_cpu(). If
such operation happens while system_wq is fully occupied by cgroup
destruction work items, work_on_cpu() can't make forward progress
because system_wq is full and other destruction work items on
system_wq can't make forward progress because the work item waiting
for work_on_cpu() is holding cgroup_mutex, leading to deadlock.
This can be fixed by queueing destruction work items on a separate
workqueue. This patch creates a dedicated workqueue -
cgroup_destroy_wq - for this purpose. As these work items shouldn't
have inter-dependencies and mostly serialized by cgroup_mutex anyway,
giving high concurrency level doesn't buy anything and the workqueue's
@max_active is set to 1 so that destruction work items are executed
one by one on each CPU.
Hugh Dickins: Because cgroup_init() is run before init_workqueues(),
cgroup_destroy_wq can't be allocated from cgroup_init(). Do it from a
separate core_initcall(). In the future, we probably want to reorder
so that workqueue init happens before cgroup_init().
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Hugh Dickins <hughd@google.com>
Reported-by: Shawn Bohrer <shawn.bohrer@gmail.com>
Link: http://lkml.kernel.org/r/20131111220626.GA7509@sbohrermbp13-local.rgmadvisors.com
Link: http://lkml.kernel.org/g/alpine.LNX.2.00.1310301606080.2333@eggly.anvils
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tejun Heo [Thu, 5 Sep 2013 16:30:04 +0000 (12:30 -0400)]
workqueue: fix ordered workqueues in NUMA setups
commit
8a2b75384444488fc4f2cbb9f0921b6a0794838f upstream.
An ordered workqueue implements execution ordering by using single
pool_workqueue with max_active == 1. On a given pool_workqueue, work
items are processed in FIFO order and limiting max_active to 1
enforces the queued work items to be processed one by one.
Unfortunately,
4c16bd327c ("workqueue: implement NUMA affinity for
unbound workqueues") accidentally broke this guarantee by applying
NUMA affinity to ordered workqueues too. On NUMA setups, an ordered
workqueue would end up with separate pool_workqueues for different
nodes. Each pool_workqueue still limits max_active to 1 but multiple
work items may be executed concurrently and out of order depending on
which node they are queued to.
Fix it by using dedicated ordered_wq_attrs[] when creating ordered
workqueues. The new attrs match the unbound ones except that no_numa
is always set thus forcing all NUMA nodes to share the default
pool_workqueue.
While at it, add sanity check in workqueue creation path which
verifies that an ordered workqueues has only the default
pool_workqueue.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Libin <huawei.libin@huawei.com>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Heiko Carstens [Thu, 21 Nov 2013 15:22:17 +0000 (16:22 +0100)]
s390/uaccess: add missing page table walk range check
commit
71a86ef055f569b93bc6901f007bdf447dbf515f upstream.
When translating a user space address, the address must be checked against
the ASCE limit of the process. If the address is larger than the maximum
address that is reachable with the ASCE, an ASCE type exception must be
generated.
The current code simply ignored the higher order bits. This resulted in an
address wrap around in user space instead of an exception in user space.
Reviewed-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Catalin Marinas [Wed, 27 Nov 2013 16:59:27 +0000 (16:59 +0000)]
arm64: Move PTE_PROT_NONE higher up
commit
3676f9ef5481d614f8c5c857f5319755be248268 upstream.
PTE_PROT_NONE means that a pte is present but does not have any
read/write attributes. However, setting the memory type like
pgprot_writecombine() is allowed and such bits overlap with
PTE_PROT_NONE. This causes mmap/munmap issues in drivers that change the
vma->vm_pg_prot on PROT_NONE mappings.
This patch reverts the PTE_FILE/PTE_PROT_NONE shift in commit
59911ca4325d (ARM64: mm: Move PTE_PROT_NONE bit) and moves PTE_PROT_NONE
together with the other software bits.
Signed-off-by: Steve Capper <steve.capper@linaro.org>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Steve Capper <steve.capper@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frank Zago [Wed, 13 Nov 2013 22:53:00 +0000 (22:53 +0000)]
iio:accel:kxsd9 fix missing mutex unlock
commit
0ee005c7dc2803125275e24598f0fb37775a6af3 upstream.
This will leave a lock held after reading from the device, preventing
any further reads.
Signed-off-by: Frank Zago <frank@zago.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Michael Neuling [Mon, 25 Nov 2013 00:12:20 +0000 (11:12 +1100)]
powerpc/signals: Improved mark VSX not saved with small contexts fix
commit
ec67ad82814bee92251fd963bf01c7a173856555 upstream.
In a recent patch:
commit
c13f20ac48328b05cd3b8c19e31ed6c132b44b42
Author: Michael Neuling <mikey@neuling.org>
powerpc/signals: Mark VSX not saved with small contexts
We fixed an issue but an improved solution was later discussed after the patch
was merged.
Firstly, this patch doesn't handle the 64bit signals case, which could also hit
this issue (but has never been reported).
Secondly, the original patch isn't clear what MSR VSX should be set to. The
new approach below always clears the MSR VSX bit (to indicate no VSX is in the
context) and sets it only in the specific case where VSX is available (ie. when
VSX has been used and the signal context passed has space to provide the
state).
This reverts the original patch and replaces it with the improved solution. It
also adds a 64 bit version.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Herrmann [Tue, 26 Nov 2013 12:58:18 +0000 (13:58 +0100)]
HID: uhid: fix leak for 64/32 UHID_CREATE
commit
80897aa787ecd58eabb29deab7cbec9249c9b7e6 upstream.
UHID allows short writes so user-space can omit unused fields. We
automatically set them to 0 in the kernel. However, the 64/32 bit
compat-handler didn't do that in the UHID_CREATE fallback. This will
reveal random kernel heap data (of random size, even) to user-space.
Fixes:
befde0226a59 ('HID: uhid: make creating devices work on 64/32 systems')
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Wed, 27 Nov 2013 23:34:18 +0000 (10:34 +1100)]
md: test mddev->flags more safely in md_check_recovery.
commit
142d44c310819e1965ca70b4d55d7679f5797e25 upstream.
commit
7a0a5355cbc71efa md: Don't test all of mddev->flags at once.
made most tests on mddev->flags safer, but missed one.
When
commit
260fa034ef7a4ff8b7306 md: avoid deadlock when dirty buffers during md_stop.
added MD_STILL_CLOSED, this caused md_check_recovery to misbehave.
It can think there is something to do but find nothing. This can
lead to the md thread spinning during array shutdown.
https://bugzilla.kernel.org/show_bug.cgi?id=65721
Reported-and-tested-by: Richard W.M. Jones <rjones@redhat.com>
Fixes:
260fa034ef7a4ff8b7306
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
majianpeng [Thu, 14 Nov 2013 04:16:19 +0000 (15:16 +1100)]
md/raid5: Before freeing old multi-thread worker, it should flush them.
commit
d206dcfa9809ec3409483e93b5e362f801fa0c27 upstream.
When changing group_thread_cnt from sysfs entry, the kernel can oops.
The kernel messages are:
[ 740.961389] BUG: unable to handle kernel NULL pointer dereference at
0000000000000008
[ 740.961444] IP: [<
ffffffff81062570>] process_one_work+0x30/0x500
[ 740.961476] PGD
b9013067 PUD
b651e067 PMD 0
[ 740.961503] Oops: 0000 [#1] SMP
[ 740.961525] Modules linked in: netconsole e1000e ptp pps_core
[ 740.961577] CPU: 0 PID: 3683 Comm: kworker/u8:5 Not tainted 3.12.0+ #23
[ 740.961602] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS 080015 11/09/2011
[ 740.961646] task:
ffff88013abe0000 ti:
ffff88013a246000 task.ti:
ffff88013a246000
[ 740.961673] RIP: 0010:[<
ffffffff81062570>] [<
ffffffff81062570>] process_one_work+0x30/0x500
[ 740.961708] RSP: 0018:
ffff88013a247e08 EFLAGS:
00010086
[ 740.961730] RAX:
ffff8800b912b400 RBX:
ffff88013a61e680 RCX:
ffff8800b912b400
[ 740.961757] RDX:
ffff8800b912b600 RSI:
ffff8800b912b600 RDI:
ffff88013a61e680
[ 740.961782] RBP:
ffff88013a247e48 R08:
ffff88013a246000 R09:
000000000002c09d
[ 740.961808] R10:
000000000000010f R11:
0000000000000000 R12:
ffff88013b00cc00
[ 740.961833] R13:
0000000000000000 R14:
ffff88013b00cf80 R15:
ffff88013a61e6b0
[ 740.961861] FS:
0000000000000000(0000) GS:
ffff88013fc00000(0000) knlGS:
0000000000000000
[ 740.961893] CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
[ 740.962001] CR2:
00000000000000b8 CR3:
00000000b24fe000 CR4:
00000000000407f0
[ 740.962001] Stack:
[ 740.962001]
0000000000000008 ffff8800b912b600 ffff88013b00cc00 ffff88013a61e680
[ 740.962001]
ffff88013b00cc00 ffff88013b00cc18 ffff88013b00cf80 ffff88013a61e6b0
[ 740.962001]
ffff88013a247eb8 ffffffff810639c6 0000000000012a80 ffff88013a247fd8
[ 740.962001] Call Trace:
[ 740.962001] [<
ffffffff810639c6>] worker_thread+0x206/0x3f0
[ 740.962001] [<
ffffffff810637c0>] ? manage_workers+0x2c0/0x2c0
[ 740.962001] [<
ffffffff81069656>] kthread+0xc6/0xd0
[ 740.962001] [<
ffffffff81069590>] ? kthread_freezable_should_stop+0x70/0x70
[ 740.962001] [<
ffffffff81722ffc>] ret_from_fork+0x7c/0xb0
[ 740.962001] [<
ffffffff81069590>] ? kthread_freezable_should_stop+0x70/0x70
[ 740.962001] Code: 89 e5 41 57 41 56 41 55 45 31 ed 41 54 53 48 89 fb 48 83 ec 18 48 8b 06 4c 8b 67 48 48 89 c1 30 c9 a8 04 4c 0f 45 e9 80 7f 58 00 <49> 8b 45 08 44 8b b0 00 01 00 00 78 0c 41 f6 44 24 10 04 0f 84
[ 740.962001] RIP [<
ffffffff81062570>] process_one_work+0x30/0x500
[ 740.962001] RSP <
ffff88013a247e08>
[ 740.962001] CR2:
0000000000000008
[ 740.962001] ---[ end trace
39181460000748de ]---
[ 740.962001] Kernel panic - not syncing: Fatal exception
This can happen if there are some stripes left, fewer than MAX_STRIPE_BATCH.
A worker is queued to handle them.
But before calling raid5_do_work, raid5d handles those
stripes making conf->active_stripe = 0.
So mddev_suspend() can return.
We might then free old worker resources before the queued
raid5_do_work() handled them. When it runs, it crashes.
raid5d() raid5_store_group_thread_cnt()
queue_work mddev_suspend()
handle_strips
active_stripe=0
free(old worker resources)
process_one_work
raid5_do_work
To avoid this, we should only flush the worker resources before freeing them.
This fixes a bug introduced in 3.12 so is suitable for the 3.12.x
stable series.
Fixes:
b721420e8719131896b009b11edbbd27
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Reviewed-by: Shaohua Li <shli@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
NeilBrown [Thu, 14 Nov 2013 04:16:15 +0000 (15:16 +1100)]
md: fix calculation of stacking limits on level change.
commit
02e5f5c0a0f726e66e3d8506ea1691e344277969 upstream.
The various ->run routines of md personalities assume that the 'queue'
has been initialised by the blk_set_stacking_limits() call in
md_alloc().
However when the level is changed (by level_store()) the ->run routine
for the new level is called for an array which has already had the
stacking limits modified. This can result in incorrect final
settings.
So call blk_set_stacking_limits() before ->run in level_store().
A specific consequence of this bug is that it causes
discard_granularity to be set incorrectly when reshaping a RAID4 to a
RAID0.
This is suitable for any -stable kernel since 3.3 in which
blk_set_stacking_limits() was introduced.
Reported-and-tested-by: "Baldysiak, Pawel" <pawel.baldysiak@intel.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
majianpeng [Thu, 14 Nov 2013 04:16:15 +0000 (15:16 +1100)]
raid5: Use slow_path to release stripe when mddev->thread is null
commit
ad4068de49862b083ac2a15bc50689bb30ce3e44 upstream.
When release_stripe() is called in grow_one_stripe(), the
mddev->thread is null. So it will omit one wakeup this thread to
release stripe.
For this condition, use slow_path to release stripe.
Bug was introduced in 3.12
Fixes:
773ca82fa1ee58dd1bf88b
Signed-off-by: Jianpeng Ma <majianpeng@gmail.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steve French [Sat, 16 Nov 2013 02:41:32 +0000 (20:41 -0600)]
setfacl removes part of ACL when setting POSIX ACLs to Samba
commit
b1d93356427be6f050dc55c86eb019d173700af6 upstream.
setfacl over cifs mounts can remove the default ACL when setting the
(non-default part of) the ACL and vice versa (we were leaving at 0
rather than setting to -1 the count field for the unaffected
half of the ACL. For example notice the setfacl removed
the default ACL in this sequence:
steven@steven-GA-970A-DS3:~/cifs-2.6$ getfacl /mnt/test-dir ; setfacl
-m default:user:test:rwx,user:test:rwx /mnt/test-dir
getfacl: Removing leading '/' from absolute path names
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:test:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
steven@steven-GA-970A-DS3:~/cifs-2.6$ getfacl /mnt/test-dir
getfacl: Removing leading '/' from absolute path names
user::rwx
user:test:rwx
group::r-x
mask::rwx
other::r-x
Signed-off-by: Steve French <smfrench@gmail.com>
Acked-by: Jeremy Allison <jra@samba.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Herrmann [Mon, 28 Oct 2013 16:47:53 +0000 (17:47 +0100)]
HID: wiimote: fix inverted pro-controller axes
commit
0abda6fa81dced031e3df31ac29bfb253549c2d1 upstream.
The analog-stick vertical axes are inverted. Fix that! Otherwise, games
and other gamepad applications need to carry their own fixups (which they
thankfully haven't done, yet).
Reported-by: Rafael Brune <mail@rbrune.de>
Tested-by: Rafael Brune <mail@rbrune.de>
Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Robert Richter [Thu, 10 Oct 2013 16:23:38 +0000 (18:23 +0200)]
edac, highbank: Fix interrupt setup of mem and l2 controller
commit
a72b8859fd3941cc1d2940d5c43026d2c6fb959e upstream.
Register and enable interrupts after the edac registration. Otherwise
incomming ecc error interrupts lead to crashes during device setup.
Fixing this in drivers for mc and l2.
Signed-off-by: Robert Richter <robert.richter@linaro.org>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Signed-off-by: Robert Richter <rric@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicholas Bellinger [Wed, 13 Nov 2013 02:05:07 +0000 (18:05 -0800)]
ib_isert: Avoid duplicate iscsit_increment_maxcmdsn call
commit
04d9cd1224e5bc9d6146bab2866cdc81deb9b509 upstream.
This patch avoids a duplicate iscsit_increment_maxcmdsn() call for
ISER_IB_RDMA_WRITE within isert_map_rdma() + isert_reg_rdma_frwr(),
which will already be occuring once during isert_put_datain() ->
iscsit_build_rsp_pdu() operation.
It also removes the local conn->stat_sn assignment + increment,
and changes the third parameter to iscsit_build_rsp_pdu() to
signal this should be done by iscsi_target_mode code.
Tested-by: Moussa Ba <moussaba@micron.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jerome Glisse [Tue, 12 Nov 2013 15:51:16 +0000 (10:51 -0500)]
radeon: workaround pinning failure on low ram gpu
commit
97b6ff6be9da7675aab339334fda996d6c5077d9 upstream.
GPU with low amount of ram can fails at pinning new framebuffer before
unpinning old one. On such failure, retry with unpinning old one before
pinning new one allowing to work around the issue. This is somewhat
ugly but only affect those old GPU we care about.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Thu, 14 Nov 2013 15:17:34 +0000 (10:17 -0500)]
drm/radeon: adjust TN dpm parameters for stability (v2)
commit
958b84fb3bef193198538b5c5902fa687cc8363f upstream.
Adjust some of the TN dpm settings for stability. Enabling
these features causes hangs and other stability problems
on certain boards.
v2: leave uvd dpm enabled
Bug:
https://bugzilla.kernel.org/show_bug.cgi?id=63101
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Samuel Li [Tue, 19 Nov 2013 20:04:45 +0000 (15:04 -0500)]
drm/radeon: hook up backlight functions for CI and KV family.
commit
7272c9d2286525d4c6bce788243cf2b6f306d15c upstream.
Fixes crashes when handling atif events due to the lack of a
callback being registered.
Signed-off-by: Samuel Li <samuel.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jerome Glisse [Wed, 6 Nov 2013 22:42:02 +0000 (17:42 -0500)]
radeon/i2c: do not count reg index in number of i2c byte we are writing.
commit
fae009d15a44e5f1d938340facf4b8bc7dc69a09 upstream.
Useless to count the register index in number of bytes we are writing.
Fixes a regression with hw i2c enabled.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Thu, 31 Oct 2013 20:43:27 +0000 (16:43 -0400)]
drm/radeon: don't share PPLLs on DCE4.1
commit
70471860ff9f335c60c004d42ebd48945bfa5403 upstream.
Sharing PPLLs seems to cause problems on some boards.
Bug:
https://bugs.freedesktop.org/show_bug.cgi?id=45334
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Wed, 30 Oct 2013 11:56:05 +0000 (12:56 +0100)]
drm/radeon: fix UVD destroy IB size
commit
727ddc84a1373bf06b2fa261f44e38fb0faf5340 upstream.
The parameter is in bytes not dwords.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Christian König [Wed, 30 Oct 2013 11:56:04 +0000 (12:56 +0100)]
drm/radeon: activate UVD clocks before sending the destroy msg
commit
c154a76311293f9671439286834aa325b7ef59fe upstream.
Make sure the UVD clocks are still active before sending
the destroy message, otherwise the hw might hang.
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alex Deucher [Mon, 28 Oct 2013 14:56:23 +0000 (10:56 -0400)]
drm/radeon/si: fix define for MC_SEQ_TRAIN_WAKEUP_CNTL
commit
d5693761b2b4ff530c8af8af9ec55b6eae76e617 upstream.
Typo in the register offset.
Noticed-by: Sylvain BERTRAND <sylware@legeek.net>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ben Skeggs [Wed, 13 Nov 2013 05:18:32 +0000 (15:18 +1000)]
drm/nouveau: when bailing out of a pushbuf ioctl, do not remove previous fence
commit
9360bd1112d8874d21942e2ae74f5416b00a8db6 upstream.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Mon, 18 Nov 2013 06:38:16 +0000 (07:38 +0100)]
drm/i915: Replicate BIOS eDP bpp clamping hack for hsw
commit
1021442098ee9328fdd4d113d63a3a7f2f40c37b upstream.
Haswell's DDI encoders have their own ->get_config callback and in
commit
c6cd2ee2d59111a07cd9199564c9bdcb2d11e5cf
Author: Jani Nikula <jani.nikula@intel.com>
Date: Mon Oct 21 10:52:07 2013 +0300
drm/i915/dp: workaround BIOS eDP bpp clamping issue
we've forgotten to replicate this hack. So let's do it that.
Note for backporters: The above commit and all it's depencies need to
be backported first.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71049
Tested-by: Gökçen Eraslan <gokcen.eraslan@gmail.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Sat, 16 Nov 2013 15:00:09 +0000 (16:00 +0100)]
drm/i915: restore the early forcewake cleanup
commit
ef46e0d247da0a7a408573aa15870e231bbd4af2 upstream.
Some BIOS just leak the forcewak bits, which we clean up.
Unfortunately this has been broken in
commit
521198a2e7095c8c7daa8d7d3a76a110c346be6f
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Fri Aug 23 16:52:30 2013 +0300
drm/i915: sanitize forcewake registers on reset
To make this work both for resets and for BIOS takeover just add the
forcewake clearing call back to intel_uncore_early_sanitize.
We need to clear the forcewake in early sanitize so that the forcewak
dance in intel_uncore_init (to figure out whether we have mt or legacy
forcewake on ivb) works. That cleanup fits in nicely with the general
topic of early_sanitize to prepare for the very first mmio ops.
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Jörg Otte <jrg.otte@gmail.com>
Cc: Jörg Otte <jrg.otte@gmail.com>
References: https://lkml.org/lkml/2013/11/16/40
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Mon, 4 Nov 2013 07:13:45 +0000 (08:13 +0100)]
drm/i915: flush cursors harder
commit
b2ea8ef559b4d94190009f3651b5b3ab7c05afd3 upstream.
Apparently they need the same treatment as primary planes. This fixes
modesetting failures because of stuck cursors (!) on Thomas' i830M
machine.
I've figured while at it I'll also roll it out for the ivb 3 pipe
version of this function. I didn't do this for i845/i865 since Bspec
says the update mechanism works differently, and there's some
additional rules about what can be updated in which order.
Tested-by: Thomas Richter <thor@math.tu-berlin.de>
Cc: Thomas Richter <thor@math.tu-berlin.de>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniel Vetter [Tue, 8 Oct 2013 10:25:42 +0000 (12:25 +0200)]
drm/i915/dvo: call ->mode_set callback only when the port is running
commit
48f34e10169dbb3dd7a19af64e328492b7f54af4 upstream.
The ns2501 controller seems to need the dpll and dvo port to accept
the timing update commands. Quick testing on my x30 here seems to
indicate that other dvo controllers don't mind. So let's move the
->mode_set callback to a place where we have the port up and running
already.
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Thomas Richter <thor@math.tu-berlin.de>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Wed, 30 Oct 2013 10:29:50 +0000 (03:29 -0700)]
drm/ttm: Fix ttm_bo_move_memcpy
commit
da95c788ef0c645378ffccb7060a0df1a33aee38 upstream.
All error paths will want to keep the mm node, so handle this at the
function exit. This fixes an ioremap failure error path.
Also add some comments to make the function a bit easier to understand.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jakob Bornecrantz [Wed, 30 Oct 2013 09:46:56 +0000 (02:46 -0700)]
drm/ttm: Handle in-memory region copies
commit
9a0599ddeae012a771bba5e23393fc52d8a59d89 upstream.
Fix the case where the ttm pointer may be NULL causing
a NULL pointer dereference.
Signed-off-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Thomas Hellström <thellstrom@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Mon, 28 Oct 2013 09:02:19 +0000 (02:02 -0700)]
drm/ttm: Fix memory type compatibility check
commit
59c8e66378fb78adbcd05f0d09783dde6fef282b upstream.
Also check the busy placements before deciding to move a buffer object.
Failing to do this may result in a completely unneccessary move within a
single memory type.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Hellstrom [Tue, 12 Nov 2013 08:09:54 +0000 (00:09 -0800)]
drm/vmwgfx: Resource evict fixes
commit
ea029c28deadc33d2af4baf26810dd5fc44d4926 upstream.
Fix an error message that was incorrectly blaming device resource id
shortage.
Also make sure we correctly catch resource eviction errors, that
could otherwise lead to evictable resources temporarily not being on the
LRU list.
Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com>
Reviewed-by: Jakob Bornecrantz <jakob@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt (Red Hat) [Tue, 26 Nov 2013 01:59:46 +0000 (20:59 -0500)]
ftrace: Fix function graph with loading of modules
commit
8a56d7761d2d041ae5e8215d20b4167d8aa93f51 upstream.
Commit
8c4f3c3fa9681 "ftrace: Check module functions being traced on reload"
fixed module loading and unloading with respect to function tracing, but
it missed the function graph tracer. If you perform the following
# cd /sys/kernel/debug/tracing
# echo function_graph > current_tracer
# modprobe nfsd
# echo nop > current_tracer
You'll get the following oops message:
------------[ cut here ]------------
WARNING: CPU: 2 PID: 2910 at /linux.git/kernel/trace/ftrace.c:1640 __ftrace_hash_rec_update.part.35+0x168/0x1b9()
Modules linked in: nfsd exportfs nfs_acl lockd ipt_MASQUERADE sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables uinput snd_hda_codec_idt
CPU: 2 PID: 2910 Comm: bash Not tainted 3.13.0-rc1-test #7
Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M., BIOS SDBLI944.86P 05/08/2007
0000000000000668 ffff8800787efcf8 ffffffff814fe193 ffff88007d500000
0000000000000000 ffff8800787efd38 ffffffff8103b80a 0000000000000668
ffffffff810b2b9a ffffffff81a48370 0000000000000001 ffff880037aea000
Call Trace:
[<
ffffffff814fe193>] dump_stack+0x4f/0x7c
[<
ffffffff8103b80a>] warn_slowpath_common+0x81/0x9b
[<
ffffffff810b2b9a>] ? __ftrace_hash_rec_update.part.35+0x168/0x1b9
[<
ffffffff8103b83e>] warn_slowpath_null+0x1a/0x1c
[<
ffffffff810b2b9a>] __ftrace_hash_rec_update.part.35+0x168/0x1b9
[<
ffffffff81502f89>] ? __mutex_lock_slowpath+0x364/0x364
[<
ffffffff810b2cc2>] ftrace_shutdown+0xd7/0x12b
[<
ffffffff810b47f0>] unregister_ftrace_graph+0x49/0x78
[<
ffffffff810c4b30>] graph_trace_reset+0xe/0x10
[<
ffffffff810bf393>] tracing_set_tracer+0xa7/0x26a
[<
ffffffff810bf5e1>] tracing_set_trace_write+0x8b/0xbd
[<
ffffffff810c501c>] ? ftrace_return_to_handler+0xb2/0xde
[<
ffffffff811240a8>] ? __sb_end_write+0x5e/0x5e
[<
ffffffff81122aed>] vfs_write+0xab/0xf6
[<
ffffffff8150a185>] ftrace_graph_caller+0x85/0x85
[<
ffffffff81122dbd>] SyS_write+0x59/0x82
[<
ffffffff8150a185>] ftrace_graph_caller+0x85/0x85
[<
ffffffff8150a2d2>] system_call_fastpath+0x16/0x1b
---[ end trace
940358030751eafb ]---
The above mentioned commit didn't go far enough. Well, it covered the
function tracer by adding checks in __register_ftrace_function(). The
problem is that the function graph tracer circumvents that (for a slight
efficiency gain when function graph trace is running with a function
tracer. The gain was not worth this).
The problem came with ftrace_startup() which should always be called after
__register_ftrace_function(), if you want this bug to be completely fixed.
Anyway, this solution moves __register_ftrace_function() inside of
ftrace_startup() and removes the need to call them both.
Reported-by: Dave Wysochanski <dwysocha@redhat.com>
Fixes:
ed926f9b35cd ("ftrace: Use counters to enable functions to trace")
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mattia Dongili [Mon, 25 Nov 2013 22:43:50 +0000 (07:43 +0900)]
sony-laptop: do not scribble keyboard backlight registers on resume
commit
b975dc3689fc6a3718ad288ce080924f9cb7e176 upstream.
Follow-up to commit
294d31e8227c ("sony-laptop: don't change keyboard
backlight settings"): avoid messing up the state on resume. Leave it to
what was before suspending as it's anyway likely that we still don't
know what value we should write to the EC registers. This fix is also
required in 3.12
Tested-by: Karol Babioch <karol@babioch.de>
Signed-off-by: Mattia Dongili <malattia@linux.it>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Tim Harvey [Wed, 6 Nov 2013 05:17:25 +0000 (21:17 -0800)]
regulator: pfuze100: allow misprogrammed ID
commit
88baf7148e899db7e0b676e4363647f50e48eaed upstream.
prior to week 08 of 2013 Freescale misprogrammed between 1 and 3% of
PFUZE1000 parts with a ID=0x8 instead of the expected ID=0x0
Signed-off-by: Tim Harvey <tharvey@gateworks.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Williams [Fri, 8 Nov 2013 19:39:44 +0000 (13:39 -0600)]
prism54: set netdev type to "wlan"
commit
8e3ffa471091c560deb6738ed9ab7445b7a5fd04 upstream.
Userspace uses the netdev devtype for stuff like device naming and type
detection. Be nice and set it. Remove the pointless #if/#endif around
SET_NETDEV_DEV too.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Thu, 7 Nov 2013 18:59:46 +0000 (13:59 -0500)]
n_tty: Ensure reader restarts worker for next reader
commit
42458f41d08f0873299e830464c1232a6839297d upstream.
A departing reader must restart a flush_to_ldisc() worker _before_
the next reader enters the read loop; this is to avoid the new reader
concluding no more i/o is available and prematurely exiting, when the
old reader simply hasn't re-started the worker yet.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Tue, 19 Nov 2013 13:46:27 +0000 (08:46 -0500)]
tty: Reset hupped state on open
commit
d4855e1fc03c2bb32dd64badf51cec5a2a26ab2a upstream.
A common security idiom is to hangup the current tty (via vhangup())
after forking but before execing a root shell. This hangs up any
existing opens which other processes may have and ensures subsequent
opens have the necessary permissions to open the root shell tty/pty.
Reset the TTY_HUPPED state after the driver has successfully
returned the opened tty (perform the reset while the tty is locked
to avoid racing with concurrent hangups).
Reported-by: Heorhi Valakhanovich <valahanovich@tut.by>
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Tested-by: Heorhi Valakhanovich <valahanovich@tut.by>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Fri, 8 Nov 2013 14:42:18 +0000 (09:42 -0500)]
n_tty: Fix echo overrun tail computation
commit
6f2225363c205e186c1465c2c7c84f17c1635504 upstream.
Commit
cbfd0340ae1993378fd47179db949e050e16e697,
'n_tty: Process echoes in blocks', introduced an error when
consuming the echo buffer tail to prevent buffer overrun, where
the incorrect operation code byte is checked to determine how
far to advance the tail to the next echo byte.
Check the correct byte for the echo operation code byte.
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roel Kluin [Fri, 11 Oct 2013 20:08:49 +0000 (22:08 +0200)]
tty: incorrect test of echo_buf() result for ECHO_OP_START
commit
c476f6584b0011741b4f0316f1ac4aa3a99403e1 upstream.
test echo_buf() result for ECHO_OP_START
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Acked-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peter Hurley [Fri, 22 Nov 2013 12:16:25 +0000 (07:16 -0500)]
n_tty: Fix 4096-byte canonical reads
commit
c77569d2f3ef7844ee4ac7005a57da6898b302a8 upstream.
Although the maximum allowable canonical line is specified to
be 255 bytes (MAX_CANON), the practical limit has actually been
the size of the line discipline read buffer (N_TTY_BUF_SIZE == 4096).
Commit
32f13521ca68bc624ff6effc77f308a52b038bf0,
n_tty: Line copy to user buffer in canonical mode, limited the
line copy to 4095 bytes. With a completely full line discipline
read buffer and a userspace buffer > 4095, _no_ data was copied,
and the read() syscall returned 0, indicating EOF.
Fix the interval arithmetic to compute the correct number of bytes
to copy to userspace in the range [1..4096].
Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andreas Bießmann [Thu, 24 Oct 2013 10:31:04 +0000 (12:31 +0200)]
avr32: fix out-of-range jump in large kernels
commit
d617b338bbfdd77e9cbd8e7dc949cee3dd73d575 upstream.
This patch fixes following error (for big kernels):
---8<---
arch/avr32/boot/u-boot/head.o: In function `no_tag_table':
(.init.text+0x44): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `panic' defined in .text.unlikely section in kernel/built-in.o
arch/avr32/kernel/built-in.o: In function `bad_return':
(.ex.text+0x236): relocation truncated to fit: R_AVR32_22H_PCREL against symbol `panic' defined in .text.unlikely section in kernel/built-in.o
--->8---
It comes up when the kernel increases and 'panic()' is too far away to fit in
the +/- 2MiB range. Which in turn issues from the 21-bit displacement in
'br{cond4}' mnemonic which is one of the two ways to do jumps (rjmp has just
10-bit displacement and therefore a way smaller range). This fact was stated
before in
8d29b7b9f81d6b83d869ff054e6c189d6da73f1f.
One solution to solve this is to add a local storage for the symbol address
and just load the $pc with that value.
Signed-off-by: Andreas Bießmann <andreas@biessmann.de>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andreas Bießmann [Thu, 24 Oct 2013 10:31:03 +0000 (12:31 +0200)]
avr32: setup crt for early panic()
commit
7a2a74f4b856993218aa7cdeeb6c3103101340db upstream.
Before the CRT was (fully) set up in kernel_entry (bss cleared before in
_start, but also not before jump to panic() in no_tag_table case).
This patch fixes this up to have a fully working CRT when branching to panic()
in no_tag_table.
Signed-off-by: Andreas Bießmann <andreas@biessmann.de>
Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>