From: Greg Kroah-Hartman Date: Mon, 13 Aug 2012 18:59:41 +0000 (-0700) Subject: 3.5-stable patches X-Git-Tag: v3.5.2~7 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=33b2ff74d909a0bbc5040e276ae87132835f3ecf;p=thirdparty%2Fkernel%2Fstable-queue.git 3.5-stable patches added patches: arm-clk-imx31-fix-the-keypad-clock-name.patch arm-dts-imx53-ard-add-regulators-for-lan9220.patch arm-imx-enable-emi_slow_gate-clock-for-imx5.patch arm-mxs-remove-mmap_min_addr-setting-from-mxs_defconfig.patch arm-pxa-remove-irq_to_gpio-from-ezx-pcap-driver.patch cfg80211-process-pending-events-when-unregistering-net-device.patch e1000e-nic-goes-up-and-immediately-goes-down.patch input-eeti_ts-pass-gpio-value-instead-of-irq.patch input-wacom-bamboo-one-1024-pressure-fix.patch iwlwifi-disable-greenfield-transmissions-as-a-workaround.patch printk-fix-calculation-of-length-used-to-discard-records.patch rt61pci-fix-null-pointer-dereference-in-config_lna_gain.patch tun-don-t-zeroize-sock-file-on-detach.patch yama-higher-restrictions-should-block-ptrace_traceme.patch --- diff --git a/queue-3.5/arm-clk-imx31-fix-the-keypad-clock-name.patch b/queue-3.5/arm-clk-imx31-fix-the-keypad-clock-name.patch new file mode 100644 index 00000000000..8f1639247c1 --- /dev/null +++ b/queue-3.5/arm-clk-imx31-fix-the-keypad-clock-name.patch @@ -0,0 +1,33 @@ +From 8cc7a2b9f75355f60922db4adf27742ba7f2f6bc Mon Sep 17 00:00:00 2001 +From: Fabio Estevam +Date: Thu, 26 Jul 2012 16:08:53 -0300 +Subject: ARM: clk-imx31: Fix the keypad clock name + +From: Fabio Estevam + +commit 8cc7a2b9f75355f60922db4adf27742ba7f2f6bc upstream. + +Fix the keypad clock name, in order to fix the following error: + +imx-keypad imx-keypad: failed to get keypad clock +imx-keypad: probe of imx-keypad failed with error -2 + +Signed-off-by: Fabio Estevam +Signed-off-by: Sascha Hauer +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-imx/clk-imx31.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm/mach-imx/clk-imx31.c ++++ b/arch/arm/mach-imx/clk-imx31.c +@@ -129,7 +129,7 @@ int __init mx31_clocks_init(unsigned lon + clk_register_clkdev(clk[nfc], NULL, "mxc_nand.0"); + clk_register_clkdev(clk[ipu_gate], NULL, "ipu-core"); + clk_register_clkdev(clk[ipu_gate], NULL, "mx3_sdc_fb"); +- clk_register_clkdev(clk[kpp_gate], "kpp", NULL); ++ clk_register_clkdev(clk[kpp_gate], NULL, "imx-keypad"); + clk_register_clkdev(clk[usb_div_post], "per", "mxc-ehci.0"); + clk_register_clkdev(clk[usb_gate], "ahb", "mxc-ehci.0"); + clk_register_clkdev(clk[ipg], "ipg", "mxc-ehci.0"); diff --git a/queue-3.5/arm-dts-imx53-ard-add-regulators-for-lan9220.patch b/queue-3.5/arm-dts-imx53-ard-add-regulators-for-lan9220.patch new file mode 100644 index 00000000000..95c7c2f115b --- /dev/null +++ b/queue-3.5/arm-dts-imx53-ard-add-regulators-for-lan9220.patch @@ -0,0 +1,55 @@ +From 1eec0c569523782392b5e6245effddb626213b8c Mon Sep 17 00:00:00 2001 +From: Shawn Guo +Date: Thu, 2 Aug 2012 22:48:39 +0800 +Subject: ARM: dts: imx53-ard: add regulators for lan9220 + +From: Shawn Guo + +commit 1eec0c569523782392b5e6245effddb626213b8c upstream. + +Since commit c7e963f (net/smsc911x: Add regulator support), the lan9220 +device tree probe fails on imx53-ard board, because the commit makes +VDD33A and VDDVARIO supplies mandatory for the driver. + +Add a fixed dummy 3V3 supplying lan9220 to fix the regression. + +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/boot/dts/imx53-ard.dts | 20 ++++++++++++++++++++ + 1 file changed, 20 insertions(+) + +--- a/arch/arm/boot/dts/imx53-ard.dts ++++ b/arch/arm/boot/dts/imx53-ard.dts +@@ -66,10 +66,30 @@ + interrupt-parent = <&gpio2>; + interrupts = <31>; + reg-io-width = <4>; ++ /* ++ * VDD33A and VDDVARIO of LAN9220 are supplied by ++ * SW4_3V3 of LTC3589. Before the regulator driver ++ * for this PMIC is available, we use a fixed dummy ++ * 3V3 regulator to get LAN9220 driver probing work. ++ */ ++ vdd33a-supply = <®_3p3v>; ++ vddvario-supply = <®_3p3v>; + smsc,irq-push-pull; + }; + }; + ++ regulators { ++ compatible = "simple-bus"; ++ ++ reg_3p3v: 3p3v { ++ compatible = "regulator-fixed"; ++ regulator-name = "3P3V"; ++ regulator-min-microvolt = <3300000>; ++ regulator-max-microvolt = <3300000>; ++ regulator-always-on; ++ }; ++ }; ++ + gpio-keys { + compatible = "gpio-keys"; + diff --git a/queue-3.5/arm-imx-enable-emi_slow_gate-clock-for-imx5.patch b/queue-3.5/arm-imx-enable-emi_slow_gate-clock-for-imx5.patch new file mode 100644 index 00000000000..3229fdb3f51 --- /dev/null +++ b/queue-3.5/arm-imx-enable-emi_slow_gate-clock-for-imx5.patch @@ -0,0 +1,37 @@ +From 68b0562df90a76ba964423986b2472c7e791729a Mon Sep 17 00:00:00 2001 +From: Shawn Guo +Date: Thu, 2 Aug 2012 22:28:49 +0800 +Subject: ARM: imx: enable emi_slow_gate clock for imx5 + +From: Shawn Guo + +commit 68b0562df90a76ba964423986b2472c7e791729a upstream. + +The imx5 common clock migration causes a regression with smsc911x +driver on imx53-ard board, where a smsc lan9220 controller gets +connected on imx53 with EIM interface. EIM needs clock emi_slow_gate +to be functional. In the new imx5 clock driver, there is no use count +incremented for the clock by enabling it, so the framework closes the +clock at late init time and makes EIM stop working then. + +Enable emi_slow_gate in clock driver initialization to fix the +regression. + +Signed-off-by: Shawn Guo +Acked-by: Sascha Hauer +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-imx/clk-imx51-imx53.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/arm/mach-imx/clk-imx51-imx53.c ++++ b/arch/arm/mach-imx/clk-imx51-imx53.c +@@ -293,6 +293,7 @@ static void __init mx5_clocks_common_ini + clk_prepare_enable(clk[aips_tz2]); /* fec */ + clk_prepare_enable(clk[spba]); + clk_prepare_enable(clk[emi_fast_gate]); /* fec */ ++ clk_prepare_enable(clk[emi_slow_gate]); /* eim */ + clk_prepare_enable(clk[tmax1]); + clk_prepare_enable(clk[tmax2]); /* esdhc2, fec */ + clk_prepare_enable(clk[tmax3]); /* esdhc1, esdhc4 */ diff --git a/queue-3.5/arm-mxs-remove-mmap_min_addr-setting-from-mxs_defconfig.patch b/queue-3.5/arm-mxs-remove-mmap_min_addr-setting-from-mxs_defconfig.patch new file mode 100644 index 00000000000..cd9f2f425d8 --- /dev/null +++ b/queue-3.5/arm-mxs-remove-mmap_min_addr-setting-from-mxs_defconfig.patch @@ -0,0 +1,49 @@ +From 3bed491c8d28329e34f8a31e3fe64d03f3a350f1 Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Fri, 3 Aug 2012 20:54:48 +0200 +Subject: ARM: mxs: Remove MMAP_MIN_ADDR setting from mxs_defconfig + +From: Marek Vasut + +commit 3bed491c8d28329e34f8a31e3fe64d03f3a350f1 upstream. + +The CONFIG_DEFAULT_MMAP_MIN_ADDR was set to 65536 in mxs_defconfig, +this caused severe breakage of userland applications since the upper +limit for ARM is 32768. By default CONFIG_DEFAULT_MMAP_MIN_ADDR is +set to 4096 and can also be changed via /proc/sys/vm/mmap_min_addr +if needed. + +Quoting Russell King [1]: + +"4096 is also fine for ARM too. There's not much point in having +defconfigs change it - that would just be pure noise in the config +files." + +the CONFIG_DEFAULT_MMAP_MIN_ADDR can be removed from the defconfig +altogether. + +This problem was introduced by commit cde7c41 (ARM: configs: add +defconfig for mach-mxs). + +[1] http://marc.info/?l=linux-arm-kernel&m=134401593807820&w=2 + +Signed-off-by: Marek Vasut +Cc: Russell King +Cc: Wolfgang Denk +Signed-off-by: Shawn Guo +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/configs/mxs_defconfig | 1 - + 1 file changed, 1 deletion(-) + +--- a/arch/arm/configs/mxs_defconfig ++++ b/arch/arm/configs/mxs_defconfig +@@ -33,7 +33,6 @@ CONFIG_NO_HZ=y + CONFIG_HIGH_RES_TIMERS=y + CONFIG_PREEMPT_VOLUNTARY=y + CONFIG_AEABI=y +-CONFIG_DEFAULT_MMAP_MIN_ADDR=65536 + CONFIG_AUTO_ZRELADDR=y + CONFIG_FPE_NWFPE=y + CONFIG_NET=y diff --git a/queue-3.5/arm-pxa-remove-irq_to_gpio-from-ezx-pcap-driver.patch b/queue-3.5/arm-pxa-remove-irq_to_gpio-from-ezx-pcap-driver.patch new file mode 100644 index 00000000000..2093f11ef9d --- /dev/null +++ b/queue-3.5/arm-pxa-remove-irq_to_gpio-from-ezx-pcap-driver.patch @@ -0,0 +1,53 @@ +From 59ee93a528b94ef4e81a08db252b0326feff171f Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Sun, 5 Aug 2012 14:58:37 +0000 +Subject: ARM: pxa: remove irq_to_gpio from ezx-pcap driver + +From: Arnd Bergmann + +commit 59ee93a528b94ef4e81a08db252b0326feff171f upstream. + +The irq_to_gpio function was removed from the pxa platform +in linux-3.2, and this driver has been broken since. + +There is actually no in-tree user of this driver that adds +this platform device, but the driver can and does get enabled +on some platforms. + +Without this patch, building ezx_defconfig results in: + +drivers/mfd/ezx-pcap.c: In function 'pcap_isr_work': +drivers/mfd/ezx-pcap.c:205:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration] + +Signed-off-by: Arnd Bergmann +Acked-by: Haojian Zhuang +Cc: Samuel Ortiz +Cc: Daniel Ribeiro +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/mfd/ezx-pcap.c | 2 +- + include/linux/mfd/ezx-pcap.h | 1 + + 2 files changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/mfd/ezx-pcap.c ++++ b/drivers/mfd/ezx-pcap.c +@@ -202,7 +202,7 @@ static void pcap_isr_work(struct work_st + } + local_irq_enable(); + ezx_pcap_write(pcap, PCAP_REG_MSR, pcap->msr); +- } while (gpio_get_value(irq_to_gpio(pcap->spi->irq))); ++ } while (gpio_get_value(pdata->gpio)); + } + + static void pcap_irq_handler(unsigned int irq, struct irq_desc *desc) +--- a/include/linux/mfd/ezx-pcap.h ++++ b/include/linux/mfd/ezx-pcap.h +@@ -16,6 +16,7 @@ struct pcap_subdev { + struct pcap_platform_data { + unsigned int irq_base; + unsigned int config; ++ int gpio; + void (*init) (void *); /* board specific init */ + int num_subdevs; + struct pcap_subdev *subdevs; diff --git a/queue-3.5/cfg80211-process-pending-events-when-unregistering-net-device.patch b/queue-3.5/cfg80211-process-pending-events-when-unregistering-net-device.patch new file mode 100644 index 00000000000..c3f81664fb5 --- /dev/null +++ b/queue-3.5/cfg80211-process-pending-events-when-unregistering-net-device.patch @@ -0,0 +1,65 @@ +From 1f6fc43e621167492ed4b7f3b4269c584c3d6ccc Mon Sep 17 00:00:00 2001 +From: Daniel Drake +Date: Thu, 2 Aug 2012 18:41:48 +0100 +Subject: cfg80211: process pending events when unregistering net device + +From: Daniel Drake + +commit 1f6fc43e621167492ed4b7f3b4269c584c3d6ccc upstream. + +libertas currently calls cfg80211_disconnected() when it is being +brought down. This causes an event to be allocated, but since the +wdev is already removed from the rdev by the time that the event +processing work executes, the event is never processed or freed. +http://article.gmane.org/gmane.linux.kernel.wireless.general/95666 + +Fix this leak, and other possible situations, by processing the event +queue when a device is being unregistered. Thanks to Johannes Berg for +the suggestion. + +Signed-off-by: Daniel Drake +Reviewed-by: Johannes Berg +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + net/wireless/core.c | 5 +++++ + net/wireless/core.h | 1 + + net/wireless/util.c | 2 +- + 3 files changed, 7 insertions(+), 1 deletion(-) + +--- a/net/wireless/core.c ++++ b/net/wireless/core.c +@@ -974,6 +974,11 @@ static int cfg80211_netdev_notifier_call + */ + synchronize_rcu(); + INIT_LIST_HEAD(&wdev->list); ++ /* ++ * Ensure that all events have been processed and ++ * freed. ++ */ ++ cfg80211_process_wdev_events(wdev); + break; + case NETDEV_PRE_UP: + if (!(wdev->wiphy->interface_modes & BIT(wdev->iftype))) +--- a/net/wireless/core.h ++++ b/net/wireless/core.h +@@ -426,6 +426,7 @@ int cfg80211_change_iface(struct cfg8021 + struct net_device *dev, enum nl80211_iftype ntype, + u32 *flags, struct vif_params *params); + void cfg80211_process_rdev_events(struct cfg80211_registered_device *rdev); ++void cfg80211_process_wdev_events(struct wireless_dev *wdev); + + int cfg80211_can_change_interface(struct cfg80211_registered_device *rdev, + struct wireless_dev *wdev, +--- a/net/wireless/util.c ++++ b/net/wireless/util.c +@@ -716,7 +716,7 @@ void cfg80211_upload_connect_keys(struct + wdev->connect_keys = NULL; + } + +-static void cfg80211_process_wdev_events(struct wireless_dev *wdev) ++void cfg80211_process_wdev_events(struct wireless_dev *wdev) + { + struct cfg80211_event *ev; + unsigned long flags; diff --git a/queue-3.5/e1000e-nic-goes-up-and-immediately-goes-down.patch b/queue-3.5/e1000e-nic-goes-up-and-immediately-goes-down.patch new file mode 100644 index 00000000000..d461fa83f65 --- /dev/null +++ b/queue-3.5/e1000e-nic-goes-up-and-immediately-goes-down.patch @@ -0,0 +1,39 @@ +From b7ec70be01a87f2c85df3ae11046e74f9b67e323 Mon Sep 17 00:00:00 2001 +From: Tushar Dave +Date: Tue, 31 Jul 2012 02:02:43 +0000 +Subject: e1000e: NIC goes up and immediately goes down + +From: Tushar Dave + +commit b7ec70be01a87f2c85df3ae11046e74f9b67e323 upstream. + +Found that commit d478eb44 was a bad commit. +If the link partner is transmitting codeword (even if NULL codeword), +then the RXCW.C bit will be set so check for RXCW.CW is unnecessary. +Ref: RH BZ 840642 + +Reported-by: Fabio Futigami +Signed-off-by: Tushar Dave +CC: Marcelo Ricardo Leitner +Tested-by: Aaron Brown +Signed-off-by: Peter P Waskiewicz Jr +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/ethernet/intel/e1000e/82571.c | 4 +--- + 1 file changed, 1 insertion(+), 3 deletions(-) + +--- a/drivers/net/ethernet/intel/e1000e/82571.c ++++ b/drivers/net/ethernet/intel/e1000e/82571.c +@@ -1601,10 +1601,8 @@ static s32 e1000_check_for_serdes_link_8 + * auto-negotiation in the TXCW register and disable + * forced link in the Device Control register in an + * attempt to auto-negotiate with our link partner. +- * If the partner code word is null, stop forcing +- * and restart auto negotiation. + */ +- if ((rxcw & E1000_RXCW_C) || !(rxcw & E1000_RXCW_CW)) { ++ if (rxcw & E1000_RXCW_C) { + /* Enable autoneg, and unforce link up */ + ew32(TXCW, mac->txcw); + ew32(CTRL, (ctrl & ~E1000_CTRL_SLU)); diff --git a/queue-3.5/input-eeti_ts-pass-gpio-value-instead-of-irq.patch b/queue-3.5/input-eeti_ts-pass-gpio-value-instead-of-irq.patch new file mode 100644 index 00000000000..bef9ed1d97d --- /dev/null +++ b/queue-3.5/input-eeti_ts-pass-gpio-value-instead-of-irq.patch @@ -0,0 +1,142 @@ +From 4eef6cbfcc03b294d9d334368a851b35b496ce53 Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Mon, 30 Apr 2012 16:21:37 +0000 +Subject: Input: eeti_ts: pass gpio value instead of IRQ + +From: Arnd Bergmann + +commit 4eef6cbfcc03b294d9d334368a851b35b496ce53 upstream. + +The EETI touchscreen asserts its IRQ line as soon as it has data in its +internal buffers. The line is automatically deasserted once all data has +been read via I2C. Hence, the driver has to monitor the GPIO line and +cannot simply rely on the interrupt handler reception. + +In the current implementation of the driver, irq_to_gpio() is used to +determine the GPIO number from the i2c_client's IRQ value. + +As irq_to_gpio() is not available on all platforms, this patch changes +this and makes the driver ignore the passed in IRQ. Instead, a GPIO is +added to the platform_data struct and gpio_to_irq is used to derive the +IRQ from that GPIO. If this fails, bail out. The driver is only able to +work in environments where the touchscreen GPIO can be mapped to an +IRQ. + +Without this patch, building raumfeld_defconfig results in: + +drivers/input/touchscreen/eeti_ts.c: In function 'eeti_ts_irq_active': +drivers/input/touchscreen/eeti_ts.c:65:2: error: implicit declaration of function 'irq_to_gpio' [-Werror=implicit-function-declaration] + +Signed-off-by: Daniel Mack +Signed-off-by: Arnd Bergmann +Cc: Dmitry Torokhov +Cc: Sven Neumann +Cc: linux-input@vger.kernel.org +Cc: Haojian Zhuang +Signed-off-by: Greg Kroah-Hartman + +--- + arch/arm/mach-pxa/raumfeld.c | 2 +- + drivers/input/touchscreen/eeti_ts.c | 21 +++++++++++++-------- + include/linux/input/eeti_ts.h | 1 + + 3 files changed, 15 insertions(+), 9 deletions(-) + +--- a/arch/arm/mach-pxa/raumfeld.c ++++ b/arch/arm/mach-pxa/raumfeld.c +@@ -953,12 +953,12 @@ static struct i2c_board_info raumfeld_co + + static struct eeti_ts_platform_data eeti_ts_pdata = { + .irq_active_high = 1, ++ .irq_gpio = GPIO_TOUCH_IRQ, + }; + + static struct i2c_board_info raumfeld_controller_i2c_board_info __initdata = { + .type = "eeti_ts", + .addr = 0x0a, +- .irq = PXA_GPIO_TO_IRQ(GPIO_TOUCH_IRQ), + .platform_data = &eeti_ts_pdata, + }; + +--- a/drivers/input/touchscreen/eeti_ts.c ++++ b/drivers/input/touchscreen/eeti_ts.c +@@ -48,7 +48,7 @@ struct eeti_ts_priv { + struct input_dev *input; + struct work_struct work; + struct mutex mutex; +- int irq, irq_active_high; ++ int irq_gpio, irq, irq_active_high; + }; + + #define EETI_TS_BITDEPTH (11) +@@ -62,7 +62,7 @@ struct eeti_ts_priv { + + static inline int eeti_ts_irq_active(struct eeti_ts_priv *priv) + { +- return gpio_get_value(irq_to_gpio(priv->irq)) == priv->irq_active_high; ++ return gpio_get_value(priv->irq_gpio) == priv->irq_active_high; + } + + static void eeti_ts_read(struct work_struct *work) +@@ -157,7 +157,7 @@ static void eeti_ts_close(struct input_d + static int __devinit eeti_ts_probe(struct i2c_client *client, + const struct i2c_device_id *idp) + { +- struct eeti_ts_platform_data *pdata; ++ struct eeti_ts_platform_data *pdata = client->dev.platform_data; + struct eeti_ts_priv *priv; + struct input_dev *input; + unsigned int irq_flags; +@@ -199,9 +199,12 @@ static int __devinit eeti_ts_probe(struc + + priv->client = client; + priv->input = input; +- priv->irq = client->irq; ++ priv->irq_gpio = pdata->irq_gpio; ++ priv->irq = gpio_to_irq(pdata->irq_gpio); + +- pdata = client->dev.platform_data; ++ err = gpio_request_one(pdata->irq_gpio, GPIOF_IN, client->name); ++ if (err < 0) ++ goto err1; + + if (pdata) + priv->irq_active_high = pdata->irq_active_high; +@@ -215,13 +218,13 @@ static int __devinit eeti_ts_probe(struc + + err = input_register_device(input); + if (err) +- goto err1; ++ goto err2; + + err = request_irq(priv->irq, eeti_ts_isr, irq_flags, + client->name, priv); + if (err) { + dev_err(&client->dev, "Unable to request touchscreen IRQ.\n"); +- goto err2; ++ goto err3; + } + + /* +@@ -233,9 +236,11 @@ static int __devinit eeti_ts_probe(struc + device_init_wakeup(&client->dev, 0); + return 0; + +-err2: ++err3: + input_unregister_device(input); + input = NULL; /* so we dont try to free it below */ ++err2: ++ gpio_free(pdata->irq_gpio); + err1: + input_free_device(input); + kfree(priv); +--- a/include/linux/input/eeti_ts.h ++++ b/include/linux/input/eeti_ts.h +@@ -2,6 +2,7 @@ + #define LINUX_INPUT_EETI_TS_H + + struct eeti_ts_platform_data { ++ int irq_gpio; + unsigned int irq_active_high; + }; + diff --git a/queue-3.5/input-wacom-bamboo-one-1024-pressure-fix.patch b/queue-3.5/input-wacom-bamboo-one-1024-pressure-fix.patch new file mode 100644 index 00000000000..ffeef821493 --- /dev/null +++ b/queue-3.5/input-wacom-bamboo-one-1024-pressure-fix.patch @@ -0,0 +1,40 @@ +From 6dc463511d4a690f01a9248df3b384db717e0b1c Mon Sep 17 00:00:00 2001 +From: Chris Bagwell +Date: Tue, 12 Jun 2012 00:25:48 -0700 +Subject: Input: wacom - Bamboo One 1024 pressure fix + +From: Chris Bagwell + +commit 6dc463511d4a690f01a9248df3b384db717e0b1c upstream. + +Bamboo One's with ID of 0x6a and 0x6b were added with correct +indication of 1024 pressure levels but the Graphire packet routine +was only looking at 9 bits. Increased to 10 bits. + +This bug caused these devices to roll over to zero pressure at half +way mark. + +The other devices using this routine only support 256 or 512 range +and look to fix unused bits at zero. + +Signed-off-by: Chris Bagwell +Reported-by: Tushant Mirchandani +Reviewed-by: Ping Cheng +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/tablet/wacom_wac.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/input/tablet/wacom_wac.c ++++ b/drivers/input/tablet/wacom_wac.c +@@ -248,7 +248,7 @@ static int wacom_graphire_irq(struct wac + input_report_abs(input, ABS_X, le16_to_cpup((__le16 *)&data[2])); + input_report_abs(input, ABS_Y, le16_to_cpup((__le16 *)&data[4])); + if (wacom->tool[0] != BTN_TOOL_MOUSE) { +- input_report_abs(input, ABS_PRESSURE, data[6] | ((data[7] & 0x01) << 8)); ++ input_report_abs(input, ABS_PRESSURE, data[6] | ((data[7] & 0x03) << 8)); + input_report_key(input, BTN_TOUCH, data[1] & 0x01); + input_report_key(input, BTN_STYLUS, data[1] & 0x02); + input_report_key(input, BTN_STYLUS2, data[1] & 0x04); diff --git a/queue-3.5/iwlwifi-disable-greenfield-transmissions-as-a-workaround.patch b/queue-3.5/iwlwifi-disable-greenfield-transmissions-as-a-workaround.patch new file mode 100644 index 00000000000..9ef2179f7e6 --- /dev/null +++ b/queue-3.5/iwlwifi-disable-greenfield-transmissions-as-a-workaround.patch @@ -0,0 +1,49 @@ +From 50e2a30cf6fcaeb2d27360ba614dd169a10041c5 Mon Sep 17 00:00:00 2001 +From: Johannes Berg +Date: Sun, 5 Aug 2012 18:31:46 +0200 +Subject: iwlwifi: disable greenfield transmissions as a workaround + +From: Johannes Berg + +commit 50e2a30cf6fcaeb2d27360ba614dd169a10041c5 upstream. + +There's a bug that causes the rate scaling to get stuck +when it has to use single-stream rates with a peer that +can do GF and SGI; the two are incompatible so we can't +use them together, but that causes the algorithm to not +work at all, it always rejects updates. + +Disable greenfield for now to prevent that problem. + +Reviewed-by: Emmanuel Grumbach +Tested-by: Cesar Eduardo Barros +Signed-off-by: Johannes Berg +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/iwlwifi/iwl-agn-rs.c | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +--- a/drivers/net/wireless/iwlwifi/iwl-agn-rs.c ++++ b/drivers/net/wireless/iwlwifi/iwl-agn-rs.c +@@ -709,11 +709,14 @@ static int rs_toggle_antenna(u32 valid_a + */ + static bool rs_use_green(struct ieee80211_sta *sta) + { +- struct iwl_station_priv *sta_priv = (void *)sta->drv_priv; +- struct iwl_rxon_context *ctx = sta_priv->ctx; +- +- return (sta->ht_cap.cap & IEEE80211_HT_CAP_GRN_FLD) && +- !(ctx->ht.non_gf_sta_present); ++ /* ++ * There's a bug somewhere in this code that causes the ++ * scaling to get stuck because GF+SGI can't be combined ++ * in SISO rates. Until we find that bug, disable GF, it ++ * has only limited benefit and we still interoperate with ++ * GF APs since we can always receive GF transmissions. ++ */ ++ return false; + } + + /** diff --git a/queue-3.5/printk-fix-calculation-of-length-used-to-discard-records.patch b/queue-3.5/printk-fix-calculation-of-length-used-to-discard-records.patch new file mode 100644 index 00000000000..320347e305c --- /dev/null +++ b/queue-3.5/printk-fix-calculation-of-length-used-to-discard-records.patch @@ -0,0 +1,51 @@ +From e3756477aec028427fec767957c0d4b6cfb87208 Mon Sep 17 00:00:00 2001 +From: Jeff Mahoney +Date: Fri, 10 Aug 2012 15:07:09 -0400 +Subject: printk: Fix calculation of length used to discard records + +From: Jeff Mahoney + +commit e3756477aec028427fec767957c0d4b6cfb87208 upstream. + +While tracking down a weird buffer overflow issue in a program that +looked to be sane, I started double checking the length returned by +syslog(SYSLOG_ACTION_READ_ALL, ...) to make sure it wasn't overflowing +the buffer. + +Sure enough, it was. I saw this in strace: + + 11339 syslog(SYSLOG_ACTION_READ_ALL, "<5>[244017.708129] REISERFS (dev"..., 8192) = 8279 + +It turns out that the loops that calculate how much space the entries +will take when they're copied don't include the newlines and prefixes +that will be included in the final output since prev flags is passed as +zero. + +This patch properly accounts for it and fixes the overflow. + +Signed-off-by: Jeff Mahoney +Signed-off-by: Linus Torvalds +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/printk.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/kernel/printk.c ++++ b/kernel/printk.c +@@ -999,6 +999,7 @@ static int syslog_print_all(char __user + struct log *msg = log_from_idx(idx); + + len += msg_print_text(msg, prev, true, NULL, 0); ++ prev = msg->flags; + idx = log_next(idx); + seq++; + } +@@ -1011,6 +1012,7 @@ static int syslog_print_all(char __user + struct log *msg = log_from_idx(idx); + + len -= msg_print_text(msg, prev, true, NULL, 0); ++ prev = msg->flags; + idx = log_next(idx); + seq++; + } diff --git a/queue-3.5/rt61pci-fix-null-pointer-dereference-in-config_lna_gain.patch b/queue-3.5/rt61pci-fix-null-pointer-dereference-in-config_lna_gain.patch new file mode 100644 index 00000000000..f0b4b9ca867 --- /dev/null +++ b/queue-3.5/rt61pci-fix-null-pointer-dereference-in-config_lna_gain.patch @@ -0,0 +1,36 @@ +From deee0214def5d8a32b8112f11d9c2b1696e9c0cb Mon Sep 17 00:00:00 2001 +From: Stanislaw Gruszka +Date: Fri, 3 Aug 2012 12:49:14 +0200 +Subject: rt61pci: fix NULL pointer dereference in config_lna_gain + +From: Stanislaw Gruszka + +commit deee0214def5d8a32b8112f11d9c2b1696e9c0cb upstream. + +We can not pass NULL libconf->conf->channel to rt61pci_config() as it +is dereferenced unconditionally in rt61pci_config_lna_gain() subroutine. + +Resolves: +https://bugzilla.kernel.org/show_bug.cgi?id=44361 + +Reported-and-tested-by: +Signed-off-by: Stanislaw Gruszka +Signed-off-by: John W. Linville +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/wireless/rt2x00/rt61pci.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/drivers/net/wireless/rt2x00/rt61pci.c ++++ b/drivers/net/wireless/rt2x00/rt61pci.c +@@ -2243,8 +2243,7 @@ static void rt61pci_txdone(struct rt2x00 + + static void rt61pci_wakeup(struct rt2x00_dev *rt2x00dev) + { +- struct ieee80211_conf conf = { .flags = 0 }; +- struct rt2x00lib_conf libconf = { .conf = &conf }; ++ struct rt2x00lib_conf libconf = { .conf = &rt2x00dev->hw->conf }; + + rt61pci_config(rt2x00dev, &libconf, IEEE80211_CONF_CHANGE_PS); + } diff --git a/queue-3.5/series b/queue-3.5/series index cbd3a9a8757..a342a6f2d36 100644 --- a/queue-3.5/series +++ b/queue-3.5/series @@ -66,3 +66,17 @@ target-add-range-checking-to-unmap-emulation.patch target-fix-reading-of-data-length-fields-for-unmap-commands.patch target-fix-possible-integer-underflow-in-unmap-emulation.patch target-check-number-of-unmap-descriptors-against-our-limit.patch +arm-clk-imx31-fix-the-keypad-clock-name.patch +arm-imx-enable-emi_slow_gate-clock-for-imx5.patch +arm-mxs-remove-mmap_min_addr-setting-from-mxs_defconfig.patch +arm-dts-imx53-ard-add-regulators-for-lan9220.patch +arm-pxa-remove-irq_to_gpio-from-ezx-pcap-driver.patch +cfg80211-process-pending-events-when-unregistering-net-device.patch +printk-fix-calculation-of-length-used-to-discard-records.patch +tun-don-t-zeroize-sock-file-on-detach.patch +yama-higher-restrictions-should-block-ptrace_traceme.patch +iwlwifi-disable-greenfield-transmissions-as-a-workaround.patch +e1000e-nic-goes-up-and-immediately-goes-down.patch +input-eeti_ts-pass-gpio-value-instead-of-irq.patch +input-wacom-bamboo-one-1024-pressure-fix.patch +rt61pci-fix-null-pointer-dereference-in-config_lna_gain.patch diff --git a/queue-3.5/tun-don-t-zeroize-sock-file-on-detach.patch b/queue-3.5/tun-don-t-zeroize-sock-file-on-detach.patch new file mode 100644 index 00000000000..05f65f0341f --- /dev/null +++ b/queue-3.5/tun-don-t-zeroize-sock-file-on-detach.patch @@ -0,0 +1,48 @@ +From 66d1b9263a371abd15806c53f486f0645ef31a8f Mon Sep 17 00:00:00 2001 +From: Stanislav Kinsbursky +Date: Thu, 9 Aug 2012 02:50:40 +0000 +Subject: tun: don't zeroize sock->file on detach + +From: Stanislav Kinsbursky + +commit 66d1b9263a371abd15806c53f486f0645ef31a8f upstream. + +This is a fix for bug, introduced in 3.4 kernel by commit +1ab5ecb90cb6a3df1476e052f76a6e8f6511cb3d ("tun: don't hold network +namespace by tun sockets"), which, among other things, replaced simple +sock_put() by sk_release_kernel(). Below is sequence, which leads to +oops for non-persistent devices: + +tun_chr_close() +tun_detach() <== tun->socket.file = NULL +tun_free_netdev() +sk_release_sock() +sock_release(sock->file == NULL) +iput(SOCK_INODE(sock)) <== dereference on NULL pointer + +This patch just removes zeroing of socket's file from __tun_detach(). +sock_release() will do this. + +Reported-by: Ruan Zhijie +Tested-by: Ruan Zhijie +Acked-by: Al Viro +Acked-by: Eric Dumazet +Acked-by: Yuchung Cheng +Signed-off-by: Stanislav Kinsbursky +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/net/tun.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/net/tun.c ++++ b/drivers/net/tun.c +@@ -185,7 +185,6 @@ static void __tun_detach(struct tun_stru + netif_tx_lock_bh(tun->dev); + netif_carrier_off(tun->dev); + tun->tfile = NULL; +- tun->socket.file = NULL; + netif_tx_unlock_bh(tun->dev); + + /* Drop read queue */ diff --git a/queue-3.5/yama-higher-restrictions-should-block-ptrace_traceme.patch b/queue-3.5/yama-higher-restrictions-should-block-ptrace_traceme.patch new file mode 100644 index 00000000000..23572091577 --- /dev/null +++ b/queue-3.5/yama-higher-restrictions-should-block-ptrace_traceme.patch @@ -0,0 +1,126 @@ +From 9d8dad742ad1c74d7e7210ee05d0b44961d5ea16 Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Thu, 9 Aug 2012 19:01:26 -0700 +Subject: Yama: higher restrictions should block PTRACE_TRACEME + +From: Kees Cook + +commit 9d8dad742ad1c74d7e7210ee05d0b44961d5ea16 upstream. + +The higher ptrace restriction levels should be blocking even +PTRACE_TRACEME requests. The comments in the LSM documentation are +misleading about when the checks happen (the parent does not go through +security_ptrace_access_check() on a PTRACE_TRACEME call). + +Signed-off-by: Kees Cook +Signed-off-by: James Morris +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/security/Yama.txt | 14 ++++++------- + include/linux/security.h | 2 - + security/yama/yama_lsm.c | 41 ++++++++++++++++++++++++++++++++++++++++ + 3 files changed, 48 insertions(+), 9 deletions(-) + +--- a/Documentation/security/Yama.txt ++++ b/Documentation/security/Yama.txt +@@ -46,14 +46,13 @@ restrictions, it can call prctl(PR_SET_P + so that any otherwise allowed process (even those in external pid namespaces) + may attach. + +-These restrictions do not change how ptrace via PTRACE_TRACEME operates. +- +-The sysctl settings are: ++The sysctl settings (writable only with CAP_SYS_PTRACE) are: + + 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other + process running under the same uid, as long as it is dumpable (i.e. + did not transition uids, start privileged, or have called +- prctl(PR_SET_DUMPABLE...) already). ++ prctl(PR_SET_DUMPABLE...) already). Similarly, PTRACE_TRACEME is ++ unchanged. + + 1 - restricted ptrace: a process must have a predefined relationship + with the inferior it wants to call PTRACE_ATTACH on. By default, +@@ -61,12 +60,13 @@ The sysctl settings are: + classic criteria is also met. To change the relationship, an + inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare + an allowed debugger PID to call PTRACE_ATTACH on the inferior. ++ Using PTRACE_TRACEME is unchanged. + + 2 - admin-only attach: only processes with CAP_SYS_PTRACE may use ptrace +- with PTRACE_ATTACH. ++ with PTRACE_ATTACH, or through children calling PTRACE_TRACEME. + +-3 - no attach: no processes may use ptrace with PTRACE_ATTACH. Once set, +- this sysctl cannot be changed to a lower value. ++3 - no attach: no processes may use ptrace with PTRACE_ATTACH nor via ++ PTRACE_TRACEME. Once set, this sysctl value cannot be changed. + + The original children-only logic was based on the restrictions in grsecurity. + +--- a/include/linux/security.h ++++ b/include/linux/security.h +@@ -1242,8 +1242,6 @@ static inline void security_free_mnt_opt + * Check that the @parent process has sufficient permission to trace the + * current process before allowing the current process to present itself + * to the @parent process for tracing. +- * The parent process will still have to undergo the ptrace_access_check +- * checks before it is allowed to trace this one. + * @parent contains the task_struct structure for debugger process. + * Return 0 if permission is granted. + * @capget: +--- a/security/yama/yama_lsm.c ++++ b/security/yama/yama_lsm.c +@@ -290,10 +290,51 @@ static int yama_ptrace_access_check(stru + return rc; + } + ++/** ++ * yama_ptrace_traceme - validate PTRACE_TRACEME calls ++ * @parent: task that will become the ptracer of the current task ++ * ++ * Returns 0 if following the ptrace is allowed, -ve on error. ++ */ ++static int yama_ptrace_traceme(struct task_struct *parent) ++{ ++ int rc; ++ ++ /* If standard caps disallows it, so does Yama. We should ++ * only tighten restrictions further. ++ */ ++ rc = cap_ptrace_traceme(parent); ++ if (rc) ++ return rc; ++ ++ /* Only disallow PTRACE_TRACEME on more aggressive settings. */ ++ switch (ptrace_scope) { ++ case YAMA_SCOPE_CAPABILITY: ++ if (!ns_capable(task_user_ns(parent), CAP_SYS_PTRACE)) ++ rc = -EPERM; ++ break; ++ case YAMA_SCOPE_NO_ATTACH: ++ rc = -EPERM; ++ break; ++ } ++ ++ if (rc) { ++ char name[sizeof(current->comm)]; ++ printk_ratelimited(KERN_NOTICE ++ "ptraceme of pid %d was attempted by: %s (pid %d)\n", ++ current->pid, ++ get_task_comm(name, parent), ++ parent->pid); ++ } ++ ++ return rc; ++} ++ + static struct security_operations yama_ops = { + .name = "yama", + + .ptrace_access_check = yama_ptrace_access_check, ++ .ptrace_traceme = yama_ptrace_traceme, + .task_prctl = yama_task_prctl, + .task_free = yama_task_free, + };