- 04 Dec, 2013 40 commits
-
-
Stanislaw Gruszka authored
commit c1de4a95 upstream. 4965 version of Eric patch "iwl3945: better skb management in rx path". It fixes several problems : 1) skb->truesize is underestimated. We really consume PAGE_SIZE bytes for a fragment, not the frame length. 2) 128 bytes of initial headroom is a bit low and forces reallocations. 3) We can avoid consuming a full page for small enough frames. Signed-off-by:
Stanislaw Gruszka <sgruszka@redhat.com> Acked-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Eric Dumazet authored
commit 45fe142c upstream. Steinar reported reallocations of skb->head with IPv6, leading to a warning in skb_try_coalesce() It turns out iwl3945 has several problems : 1) skb->truesize is underestimated. We really consume PAGE_SIZE bytes for a fragment, not the frame length. 2) 128 bytes of initial headroom is a bit low and forces reallocations. 3) We can avoid consuming a full page for small enough frames. Reported-by:
Steinar H. Gunderson <sesse@google.com> Signed-off-by:
-
Johannes Koch authored
commit b43ea806 upstream. Patch to make TeVii S471 cards use the ts2020 tuner, since ds3000 driver no longer contains tuning code. Signed-off-by:
Johannes Koch <johannes@ortsraum.de> Signed-off-by:
Mauro Carvalho Chehab <m.chehab@samsung.com> Signed-off-by:
-
Michal Kubecek authored
commit c13a84a8 upstream. Commit 68b80f11 (netfilter: nf_nat: fix RCU races) introduced RCU protection for freeing extension data when reallocation moves them to a new location. We need the same protection when freeing them in nf_ct_ext_free() in order to prevent a use-after-free by other threads referencing a NAT extension data via bysource list. Signed-off-by:
Michal Kubecek <mkubecek@suse.cz> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by:
-
Emmanuel Grumbach authored
commit 8ca95995 upstream. This triggers automatic bug reports and add no valuable information. Print a simple error instead and drop the host command. Signed-off-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
Alex Deucher authored
commit b852c985 upstream. HW ACR support may have issues on some older chips, so use SW ACR for now until we've tested further. Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> CC: Rafał Miłecki <zajec5@gmail.com> Signed-off-by:
-
Alex Deucher authored
commit ee0fec31 upstream. Use the hw generated values rather than calculating them in the driver. There may be some older r6xx asics where this doesn't work correctly. This remains to be seen. See bug: https://bugs.freedesktop.org/show_bug.cgi?id=69675Signed-off-by:
-
Alex Deucher authored
commit e7d12c2f upstream. The drm code that calculates the 1001 clocks rounds up rather than truncating. This allows the table to match properly on those modes. See bug: https://bugs.freedesktop.org/show_bug.cgi?id=69675Signed-off-by:
-
Alex Deucher authored
commit 062c2e43 upstream. Avoid losing precision. See bug: https://bugs.freedesktop.org/show_bug.cgi?id=69675 v2: fix math as per Anssi's comments. Signed-off-by:
-
Nanno Langstraat authored
commit 43c83146 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:
-
Tristan Rice authored
commit e17f5d76 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:
-
Stefan Achatz authored
commit e078809d upstream. Forgot two special driver declarations and sorted the list. Signed-off-by:
Stefan Achatz <erazor_de@users.sourceforge.net> Signed-off-by:
-
Stefan Achatz authored
commit 7be63f20 upstream. Add missing switch breaks. Signed-off-by:
-
Stefan Achatz authored
commit 14fc4290 upstream. Ryos uses a new return value for critical errors, others have been confirmed. Signed-off-by:
-
David Howells authored
commit 124df926 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:
-
Mauro Carvalho Chehab authored
commit 9736a89d 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:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit 8393796d 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 authored
commit 37ebaf68 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:
Antti Palosaari <crope@iki.fi> Signed-off-by:
-
Mauro Carvalho Chehab authored
commit ba474642 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 authored
commit 9aca4fb0 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 authored
commit f7a35df1 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 authored
commit f1baab87 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 authored
commit 56ac0337 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 authored
commit ac5b4b6b 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 authored
commit 1d212cf0 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 authored
commit 278ba83a 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 authored
commit 5bf30b3b 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 authored
commit 64f7ef8a 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 authored
commit 1d7fa359 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 authored
commit 0065a79a 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 authored
commit 65e2f1cb 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 authored
commit 7760e148 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 authored
commit c98300a0 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:
-
Johannes Berg authored
commit 79845c66 upstream. Since rdev->sched_scan_req is dereferenced outside the lock protecting it, this might be done at the wrong time, causing crashes. Move the dereference to where it should be - inside the RTNL locked section. Reviewed-by:
-
Alex Deucher authored
commit 4cc948b9 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:
-
Tejun Heo authored
commit e5fca243 upstream. Since be445626 ("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, ea15f8cc ("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 Cc: stable@vger.kernel.org # v3.9+ Signed-off-by:
-
Linus Walleij authored
commit 2ba3154d 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:
-
Simon Wood authored
commit 7f505470 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:
-
Simon Wood authored
commit 114a55cf upstream. Re-arrange code slightly to ensure that device properties are configured before calling auto-center command. Reported-by:
Michal Malý <madcatxster@prifuk.cz> Signed-off-by:
-
Simon Wood authored
commit d2c02da5 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:
-
