- 04 Dec, 2013 40 commits
-
-
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 <m.chehab@samsung.com> Reviewed-by:
Hans Verkuil <hans.verkuil@cisco.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
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:
Antti Palosaari <crope@iki.fi> 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 24e9a47e 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 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:
-
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:
Alex Deucher <alexander.deucher@amd.com> 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:
Jiri Kosina <jkosina@suse.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:
-
Simon Wood authored
commit f8c23156 upstream. Adjust the scaling and lineartity to match that of the Windows driver (from MOMO testing). Reported-by:
-
KaiChung Cheng authored
commit bf9d121e 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:
-
Srinivas Pandruvada authored
commit d4b1bba7 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:
-
Forest Bond authored
commit a6802e00 upstream. Add support for SiS multitouch panels. Signed-off-by:
Forest Bond <forest.bond@rapidrollout.com> Signed-off-by:
-
Elias Vanderstuyft authored
commit bd04363d 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:
Anssi Hannula <anssi.hannula@iki.fi> Signed-off-by:
-
Luosong authored
commit 7b226292 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:
-
Steven Whitehouse authored
commit ea0341e0 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:
-
Kuninori Morimoto authored
commit 357002b9 upstream. afa2c940 ("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:
-
Mark Langsdorf authored
commit fbbc5bfb 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:
-
Wei WANG authored
commit 26b81851 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:
-
James Ralston authored
commit 5e90169c 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:
-
Forest Bond authored
commit ae2aa3a5 upstream. The HID driver now handles these devices, regardless of what protocol the device claims it supports. Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Forest Bond authored
commit 95d50b6c 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 139ebe8d ("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: fe6065dc HID: add multi-input quirk for eGalax Touchcontroller 77933c35 Merge branch 'egalax' into for-linus ebd11fec HID: Add quirk for eGalax touch controler. d34c4aa4 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:
-
Tom Gundersen authored
commit 78551277 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:
-
Joseph Salisbury authored
commit 5df682b2 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/1229361Signed-off-by:
Joseph Salisbury <joseph.salisbury@canonical.com> Tested-by:
Kamal Mostafa <kamal@canonical.com> Signed-off-by:
-
Daniel Stone authored
commit 92eb77d0 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 authored
commit 93681616 upstream. This reverts commit 5beea882 as it breaks trackpoint operation on XT2. Signed-off-by:
-
Steven Rostedt (Red Hat) authored
commit 4e58e547 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: 9cbf1176 ("tracing/events: provide string with undefined size support") Signed-off-by:
Steven Rostedt <rostedt@goodmis.org> Signed-off-by:
-
Takashi Iwai authored
commit 2ded3e5b 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=65641Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit 1f0bbf03 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=65961Signed-off-by:
-
Takashi Iwai authored
commit ced4cefc 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=65681Signed-off-by:
-
Takashi Iwai authored
commit 16c0cefe 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=65681Signed-off-by:
-
